Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Sep 2019 14:07:02 -0000
From:      Bruce Evans <bde@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r346278 - head/lib/libvgl
Message-ID:  <201904161531.x3GFVNY3070468@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: bde
Date: Tue Apr 16 15:31:23 2019
New Revision: 346278
URL: https://svnweb.freebsd.org/changeset/base/346278

Log:
  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.

Modified:
  head/lib/libvgl/main.c

Modified: head/lib/libvgl/main.c
==============================================================================
--- head/lib/libvgl/main.c	Tue Apr 16 14:29:12 2019	(r346277)
+++ head/lib/libvgl/main.c	Tue Apr 16 15:31:23 2019	(r346278)
@@ -264,6 +264,19 @@ VGLInit(int mode)
   else
     VGLBufSize = max(VGLAdpInfo.va_line_width*VGLModeInfo.vi_height,
 		     VGLAdpInfo.va_window_size)*VGLModeInfo.vi_planes;
+  /*
+   * The above is for old -CURRENT.  Current -CURRENT since r203535 and/or
+   * r248799 restricts va_buffer_size to the displayed size in VESA modes to
+   * avoid wasting kva for mapping unused parts of the frame buffer.  But all
+   * parts were usable here.  Applying the same restriction to user mappings
+   * makes our virtualization useless and breaks our panning, but large frame
+   * buffers are also difficult for us to manage (clearing and switching may
+   * be too slow, and malloc() may fail).  Restrict ourselves similarly to
+   * get the same efficiency and bugs for all kernels.
+   */
+  if (0 && VGLModeInfo.vi_mode >= M_VESA_BASE)
+    VGLBufSize = 2*VGLAdpInfo.va_line_width*VGLModeInfo.vi_height*
+                 VGLModeInfo.vi_planes;
   VGLBuf = malloc(VGLBufSize);
   if (VGLBuf == NULL) {
     VGLEnd();





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904161531.x3GFVNY3070468>