Re: nv(4) acceleration disabled by default + enabling EXA
Hello! > I tried your config on an iMac G4 (Flat Panel) with "GeForce MX with > AGP8X (Mac)", but nv doesn't support EXA on this chipset, Unfortunately, looking into sources at /usr/xenocara/driver/xf86-video-nv/src it is clear that only nVidia G80 series support EXA acceleration (which is mine case with GT218). All other series support at most XAA which is today same as no acceleration at all - because XAA was removed from X-Server completely (but somehow was not removed from drivers). Best regards --Henryk Paluch Full conversation: On 7/22/23 07:23, George Koehler wrote: On Thu, 15 Jun 2023 20:26:43 +0200 Henryk Paluch wrote: To enable EXA acceleration (the only that is supported in current X-Window distribution) we can for example create file /etc/X11/xorg.conf.d/15-nv-exa.conf with contents: Section "Device" Identifier "nv" Driver "nv" Option "AccelMethod" "EXA" EndSection I tried your config on an iMac G4 (Flat Panel) with "GeForce MX with AGP8X (Mac)", but nv doesn't support EXA on this chipset, | [27.025] (WW) Warning, couldn't open module xaa | [27.025] (EE) NV: Failed to load module "xaa" (module does not exist, 0) | ... | [27.096] (WW) NV(0): Option "AccelMethod" is not used I suspect that few people use nv(4), because it only works with old nvidia cards. We might not find another nv(4) user. iMac's dmesg; Xorg.0.log (with your config); pcidumps -xxv are below. --George [ using 1332684 bytes of bsd ELF symbol table ] console out [NVDA,Display-A] console in [keyboard], using USB using parent NVDA,Parent:: memaddr 9800, size 800 : consaddr 98004000 : ioaddr 9100, size 100: width 1440 linebytes 1536 height 900 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (GENERIC) #140: Mon Jul 17 07:05:52 MDT 2023 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 2147483648 (2048MB) avail mem = 2070360064 (1974MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: model PowerMac6,1 cpu0 at mainbus0: 7455 (Revision 0x303): 999 MHz: 256KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 1GB DDR SDRAM non-parity PC2700CL2.5 spdmem1 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 memc0 at mainbus0: uni-n rev 0xd2 "hw-clock" at memc0 not configured kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 agp at pchb0 not configured vgafb0 at pci0 dev 16 function 0 vendor "NVIDIA", unknown product 0x0189 rev 0xa2 wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) mpcpcibr1 at mainbus0 pci: uni-north pci1 at mpcpcibr1 bus 0 macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE macgpio0 at macobio0 offset 0x50 macgpio1 at macgpio0 offset 0x9: irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio4" at macgpio0 offset 0x5c not configured "gpio11" at macgpio0 offset 0x75 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "extint-gpio16" at macgpio0 offset 0x68 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zs0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 snapper0 at macobio0 offset 0x1: irq 30,1,2 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 apm0 at adb0: battery flags 0x9, 0% charged piic0 at adb0 iic1 at piic0 "backlight" at macobio0 offset 0xf300 not configured kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x2 irq 24: DMA atapiscsi0 at wdc0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: removable cd0(wdc0:0:0): using BIOS timings, DMA mode 2 audio0 at snapper0 bwi0 at pci1 dev 18 function 0 "Broadcom BCM4306" rev 0x03: irq 52, address 00:11:24:28:c4:ef ohci0 at pci1 dev 24 function 0 "Apple Intrepid USB" rev 0x00: irq 27, version 1.0, legacy support ohci1 at pci1 dev 25 function 0 "Apple Intrepid USB" rev 0x00: irq 28, version 1.0, legacy support ohci2 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 configuration 1 interface 0 "Apple OHCI root hub" rev 1.00/1.00
nv(4) acceleration disabled by default + enabling EXA
Hello! I have found that for nv(4) nVidia driver the acceleration is disabled by default for historical reasons: As properly documented on: https://man.openbsd.org/nv.4 the: Option "AccelMethod" "string" has default value "XAA". However XAA was removed several years ago (in XServer 13, current version is 21). Therefore as we can verify in Xorg.0.log it has same effect as disabling acceleration entirely: (II) LoadModule: "xaa" (WW) Warning, couldn't open module xaa (EE) NV: Failed to load module "xaa" (module does not exist, 0) To enable EXA acceleration (the only that is supported in current X-Window distribution) we can for example create file /etc/X11/xorg.conf.d/15-nv-exa.conf with contents: Section "Device" Identifier "nv" Driver "nv" Option "AccelMethod" "EXA" EndSection Now again start X-Window and verify that EXA acceleration is enabled - in such case following messages should appear in Xorg.0.log: (**) NV(0): Option "AccelMethod" "EXA" ... (II) EXA(0): Offscreen pixmap area of 201320448 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) UploadToScreen I'm now curious if there are enough volunteers that are willing to test if EXA acceleration helps them noticeably with nVidia performance (personally I have nVidia GT218 - which is G80 Series). In case of positive reports we may think of enabling EXA acceleration as default (just swapping order of items in enum Accel in g80_type.h should do the trick, because the one that has 0 value is default), but considering if there are any cases where EXA causes regressions (crashes or rendering issues). Best regards --Henryk Paluch
patch: smooth ps/2 mouse movement on text wsconsole
Hello!
Here is early and *experimental* patch for wsmoused(8) that will
smoothly track PS/2 mouse movements (accumulating full delta events from
mouse) on text wsconsole. It is intentionally this simple PoC, because
I like to know few things first.
Here is patch for OpenBSD 7.3. release:
--- /usr/src/usr.sbin/wsmoused/wsmoused.c.orig Fri Jun 2 16:07:14 2023
+++ /usr/src/usr.sbin/wsmoused/wsmoused.c Fri Jun 2 17:34:56 2023
@@ -316,6 +316,46 @@
}
}
+// normalize mouse event but keep preserve full deltas
+static void
+normalize_event_fullres(struct wscons_event *event)
+{
+
+#define SCALE_FACTOR 8
+ // track mouse position with highest precision
+ // EXPERIMENTAL CODE - NOT thread/mp safe !!!
+ // Support only 1 mouse properly
+ static int px=0, py=0;
+ int npx,npy; // temporary store of new position
+
+ int dx, dy;
+
+ switch (event->type) {
+ case WSCONS_EVENT_MOUSE_DELTA_X:
+ dx = event->value;
+ // track mouse movements deltas with full precision
+ npx = px + dx;
+ // downscale result for wscons, ...
+ dx = npx / SCALE_FACTOR;
+ // subtract "overflowed" value from full position
+ npx -= dx * SCALE_FACTOR;
+ // preserve full delta precision internally
+ px = npx;
+ event->value = dx;
+ break;
+ case WSCONS_EVENT_MOUSE_DELTA_Y:
+ // same for dy
+ dy = event->value;
+ npy = py + dy;
+ dy = npy / SCALE_FACTOR;
+ npy -= dy * SCALE_FACTOR;
+ py = npy;
+ event->value = dy;
+ break;
+ }
+}
+
+
/* send a wscons_event to the kernel */
static void
treat_event(struct wscons_event *event)
@@ -410,6 +450,7 @@
if (mouse.proto == P_WSCONS) {
/* wsmouse supported mouse */
read(mouse.mfd, , sizeof(event));
+ normalize_event_fullres();
treat_event();
} else {
/* serial mouse (not supported by wsmouse) */
How to use:
1. apply this patch on 7.3-RELEASE source
2. for the 1st time ensure that obj is created:
cd /usr/src/usr.sbin/wsmoused
make obj
3. then build with just "make" command
4. kill existing wsmoused (as root) with: pkill wsmoused
5. run as root: /usr/src/usr.sbin/wsmoused/obj/wsmoused
6. try to move your PS/2 mouse in various directions and compare
difference when running with stock /usr/sbin/wsmoused
Explanation: Why is "normalize_event()" function wrong:
- existing function "normalize_event()" in wsmoused.c source
attempts to scale move deltas for Serial mouse
- but that function is incorrect because it simply drops too
small deltas
- so if user moves mouse too slowly (when deltas do not exceed
threshold) the mouse will *never* move on console (which is bug)
- the only way to move mouse on console is to move quickly enough
to exceed cut threshold - which make mouse movements again jumpy ...
- please be aware that PS/2 mouse (driver in
/usr/src/sys/dev/pckbc/pms.c) does *not* track absolute position,
but it reports only deltas on every movement. So we must accumulate
all deltas until they exceed our threshold to properly handle slow
mouse movements even on coarse text console.
Now I have following questions:
1. Is there any interest at all on such improvement? Are there
still enough users of PS/2 mouse on local wscons console
with wsmoused(8) daemon?
2. If yes, what parameters should be configurable by wsmoused(8)?
(probably enable/disable and scaling factor?)
3. Where is best place to store per-mouse data (that should be used
instead of "static int px=0, py=0;" in my patch)?
Best regards
--Henryk Paluch
