Re: CVS commit: src/sys/dev/wsfb
Hi, On 2020/10/21 15:42, Michael wrote: Hello, On Sun, 18 Oct 2020 11:54:21 + "Rin Okuyama" wrote: Module Name:src Committed By: rin Date: Sun Oct 18 11:54:21 UTC 2020 Modified Files: src/sys/dev/wsfb: genfb.c Log Message: For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags when shadow FB is used. This flag is a hint for X, telling it that the memory used as framebuffer is regular RAM ( where using a shadowfb in X would be a waste of time and RAM ), not for example PCI RAM ( where a shadowfb would be faster ). In other words, it's supposed to tell X not to shadow the framebuffer. This is why it's not set by genfb itself, which doesn't have such knowledge about the hardware, but by drivers which do. Shadow fb use in wsdisplay is completely private and mapping the framebuffer through genfb will always give you whatever genfb thinks is the actual device framebuffer. Thank you for detailed explanation! I already reverted this commit as jmcneill@ advised me: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/wsfb/genfb.c#rev1.77 Thanks, rin
Re: CVS commit: src/sys/dev/wsfb
Hello, On Sun, 18 Oct 2020 11:54:21 + "Rin Okuyama" wrote: > Module Name: src > Committed By: rin > Date: Sun Oct 18 11:54:21 UTC 2020 > > Modified Files: > src/sys/dev/wsfb: genfb.c > > Log Message: > For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags > when shadow FB is used. This flag is a hint for X, telling it that the memory used as framebuffer is regular RAM ( where using a shadowfb in X would be a waste of time and RAM ), not for example PCI RAM ( where a shadowfb would be faster ). In other words, it's supposed to tell X not to shadow the framebuffer. This is why it's not set by genfb itself, which doesn't have such knowledge about the hardware, but by drivers which do. Shadow fb use in wsdisplay is completely private and mapping the framebuffer through genfb will always give you whatever genfb thinks is the actual device framebuffer. have fun Michael
Re: CVS commit: src/sys/dev/wsfb
On 2020/10/18 21:18, Jared McNeill wrote: I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get when you mmap the device. When shadow FB is used, that is generally only used for rasops and mmap bypasses the shadow and uses device memory directly. So I think this could cause performance regressions on such hardware where shadow FB is enabled and reading VRAM is slow. What problem are you attempting to solve with this change? Ah, I misunderstood its intention. I will revert this commit. Thank you for pointing out! PS I came across this flag bit when I was examining byte-order problems of framebuffer on aarch64eb. I'm just going to send a message to you. I will soon! Thanks, rin
Re: CVS commit: src/sys/dev/wsfb
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get when you mmap the device. When shadow FB is used, that is generally only used for rasops and mmap bypasses the shadow and uses device memory directly. So I think this could cause performance regressions on such hardware where shadow FB is enabled and reading VRAM is slow. What problem are you attempting to solve with this change? On Sun, 18 Oct 2020, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Sun Oct 18 11:54:21 UTC 2020 Modified Files: src/sys/dev/wsfb: genfb.c Log Message: For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags when shadow FB is used. To generate a diff of this commit: cvs rdiff -u -r1.74 -r1.75 src/sys/dev/wsfb/genfb.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
