Bug 281252 - Framebuffer writes are very slow on BeagleBone Black
Summary: Framebuffer writes are very slow on BeagleBone Black
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 13.4-STABLE
Hardware: arm Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-03 19:37 UTC by Maciej Sobczak
Modified: 2024-09-03 20:04 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Sobczak 2024-09-03 19:37:36 UTC
A simple test with video framebuffer, composed of just:

1. open("/dev/fb0", ...)
2. mmap(...) on the file descriptor
3. memset(buf, ...) over any portion of the framebuffer area,

is very slow, compared to Linux Debian on the same board.

While the above test operates within a blink of an eye on Linux, its execution on FreeBSD 13.x runs in apparently constant, but very low speed - taking about 2s to fill the whole framebuffer of reasonable size (whether 1280x1024 or 1024x768). Such timings make the whole concept of framebuffer somewhat useless.

While the test runs, the main console also displays a number of messages as already reported in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241428

It looks as if there is some checking/monitoring/etc. of every single write while they traverse through the VM layers. Or, perhaps, a misconfigured orchestration with the underlying hardware (framer DMA, etc.).
Comment 1 John F. Carr 2024-09-03 20:04:25 UTC
My first guess is the frame buffer is mapped as simple device memory.  Frame buffers should use what x86 calls write combining memory, or possibly write-through cached in the case of a dumb frame buffer.