]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Quick fix for slow clearing and context switches of large frame buffers
authorbde <bde@FreeBSD.org>
Tue, 16 Apr 2019 15:31:23 +0000 (15:31 +0000)
committerbde <bde@FreeBSD.org>
Tue, 16 Apr 2019 15:31:23 +0000 (15:31 +0000)
commiteb6045021e6fa8b3baf891ad0f3d23fd0714864e
tree611e202115d4e81bec83cfe1ca9762683a29fc0a
parent0ad6103555d081fef25e7c12595eebbef5bbcdb8
Quick fix for slow clearing and context switches of large frame buffers
with old kernels, by breaking the support for large frame buffers in the
same way as for current kernels.

Large frame buffers may be too large to map into kva, and the kernel
(syscons) only uses the first screen page anyway, so r203535, r205557
and 248799 limit the buffer size in VESA modes to the first screen
page, apparently without noticing that this breaks applications by
using the same limit for user mappings as for kernel mappings.  In
vgl, this makes the virtual screen the same as the physical screen.

However, this is almost a feature since clearing and switching large
(usually mostly unused) frame buffers takes too long.  E.g., on a 16
year old low-end AGP card it takes about 12 seconds to clear the 128MB
frame buffer in old kernels that map it all and also map it with slow
attributes (e.g., uncacheable).  Older PCI cards are even slower, but
usually have less memory.  Newer PCIe cards are faster, but may have
many GB of memory.  Also, vgl malloc()s a shadow buffer with the same
size as the frame buffer, so large frame buffers are even more wasteful
in applications than in the kernel.

Use the same limit in vgl as in newer kernels.

Virtual screens and panning still work in non-VESA modes that have
more than 1 page.  The reduced buffer size in the kernel also breaks
mmap() of the last physical page in modes where the reduced size is
not a multiple of the physical page size.  The same reduction in vgl
only reduces the virtual screen size.
lib/libvgl/main.c