Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance
Helge Deller writes: > On 1/26/22 12:24, Daniel Vetter wrote: >> And that point was about 5 years ago, and has been discussed at some >> plumbers meanwhile, resulting in the staging TODO patches to make >> these drm drivers to destage them. >> >> Fixing bugs in fbdev is all fine, reopening it for merging new drivers is >> not. > > We are on the same page! > I'm not at all proposing to include new drivers for (relatively) new > hardware into fbdev, which is capable to be written as DRM driver. In my opinion that should be decided depending on the main usecase: If it's X11 or similar, it should go to DRM. If its main use case is kernel text console, it should go to fbdev. I think the main concern/trouble about fbdev is the userspace interface, and i personally would be totally fine seeing that go away (except the ability to change video mode with fbset). For me its important as kernel console for old systems, and don't want to run X11 on them. Given the ongoing discussion about performance and drm, i don't expect DRM gaining HW acceleration capabilities for text consoles. So i think both should exist, just for different usecases.
Re: fbdev: Garbage collect fbdev scrolling acceleration
Hi Daniel, Daniel Vetter writes: > On Wed, Jan 19, 2022 at 05:15:44PM +0100, Sven Schnelle wrote: >> Hi Daniel, >> >> Daniel Vetter writes: >> >> > On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote: >> >> Helge Deller writes: >> >> > Maybe on fast new x86 boxes the performance difference isn't huge, >> >> > but for all old systems, or when emulated in qemu, this makes >> >> > a big difference. >> >> > >> >> > Helge >> >> >> >> I second that. For most people, the framebuffer isn't important as >> >> they're mostly interested in getting to X11/wayland as fast as possible. >> >> But for systems like servers without X11 it's nice to have a fast >> >> console. >> > >> > Fast console howto: >> > - shadow buffer in cached memory >> > - timer based upload of changed areas to the real framebuffer >> > >> > This one is actually fast, instead of trying to use hw bltcopy and having >> > the most terrible fallback path if that's gone. Yes drm fbdev helpers has >> > this (but not enabled on most drivers because very, very few people care). >> >> Hmm Take my Laptop with a 4k (3180x2160) screen as an example: >> >> Lets say on average the half of every line is filled with text. >> >> So 3840/2*2160 pixels that change = 4147200 pixels. Every pixel takes 4 >> bytes = 16,588800 bytes per timer interrupt. In another Mail updating on >> vsync was mentioned, so multiply that by 60 and get ~927MB. And even if >> you only update the screen ony 4 times per second, that would be ~64MB >> of data. I'm likely missing something here. > > Since you say 4k it's a modern box, so you have on the order of 10GB/s of > write bandwidth. > > And around 100MB/s of read bandwidth. Both from the cpu. It all adds up. > It's that uncached read which kills you and means dmesg takes seconds to > display. > > Also since this is 4k looking at sales volume we're talking integrated, so > whether it's the gpu or the cpu that's doing the memcpy, it's the same > memory bw budget you're burning down. That might be true for integrated graphics, as said, i don't know the architecture. But saying it's good just because it's good on one architecture doesn't mean it's good for everyone. If you have an external GPU, than the memory/system bus BW would be different whether it's memcpy or the GPU doing the scrolling. And whether internal or external graphics - the CPU could do other stuff while the GPU scrolls stuff. Quite a lot of discussion for a revert of a patch that was already in the kernel for more than 20(?) years. /Sven
Re: fbdev: Garbage collect fbdev scrolling acceleration
Hi Daniel, Daniel Vetter writes: > On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote: >> Helge Deller writes: >> > Maybe on fast new x86 boxes the performance difference isn't huge, >> > but for all old systems, or when emulated in qemu, this makes >> > a big difference. >> > >> > Helge >> >> I second that. For most people, the framebuffer isn't important as >> they're mostly interested in getting to X11/wayland as fast as possible. >> But for systems like servers without X11 it's nice to have a fast >> console. > > Fast console howto: > - shadow buffer in cached memory > - timer based upload of changed areas to the real framebuffer > > This one is actually fast, instead of trying to use hw bltcopy and having > the most terrible fallback path if that's gone. Yes drm fbdev helpers has > this (but not enabled on most drivers because very, very few people care). Hmm Take my Laptop with a 4k (3180x2160) screen as an example: Lets say on average the half of every line is filled with text. So 3840/2*2160 pixels that change = 4147200 pixels. Every pixel takes 4 bytes = 16,588800 bytes per timer interrupt. In another Mail updating on vsync was mentioned, so multiply that by 60 and get ~927MB. And even if you only update the screen ony 4 times per second, that would be ~64MB of data. I'm likely missing something here.
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Daniel Vetter writes: > On Wed, Jan 19, 2022 at 3:01 PM Linus Torvalds > wrote: > Irrespective of this code being buggy or not buggy I think the bigger > pictures, and really the reason I want to see as much code ditched > from the fbdev/fbcon stack as we possible can, are very clear: > > - it's full of bugs > - there's no test coverage/CI to speak of > - it's very arcane code which is damn hard to understand and fix issues within > - the locking is busted (largely thanks to console_lock, and the > effort to make that reasonable from -rt folks has been slowly creeping > forward for years). > > Iow this subsystem is firmly stuck in the 90s, and I think it's best > to just leave it there. There's also not been anyone actually capable > and willing to put in the work to change this (pretty much all actual > changes/fixes have been done by drm folks anyway, like me having a > small pet project to make the fbdev vs fbcon locking slightly less > busted). Saying it's stuck in the 90ies, and actively trying to prevent Helge from taking over maintainership at the same time looks odd. I think Helge should at least get a chance to fix the issues. If the state is still the same in a year or so it should be discussed again. > The other side is that being a maintainer is about collaboration, and > this entire fbdev maintainership takeover has been a demonstration of > anything but that. MAINTAINERS entry was a bit confusing since defacto > drm has been maintaining it for years. It was marked as 'Orphaned'. Anyone is free to send a Patch/PR to take over maintainership. If you have strong opinions about that code (And you obviously have reading your mail, set it to 'maintained' and care about it. Everything else is just wrong in my opinion. /Sven
Re: [PATCH 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon
Helge Deller writes: > This series reverts two patches which disabled scrolling acceleration in > fbcon/fbdev. Those patches introduced a regression for fbdev-supported graphic > cards because of the performance penalty by doing screen scrolling by software > instead of using hardware acceleration. > > Console scrolling acceleration was disabled by dropping code which checked at > runtime the driver hardware possibilities for the BINFO_HWACCEL_COPYAREA or > FBINFO_HWACCEL_FILLRECT flags and if set, it enabled scrollmode SCROLL_MOVE > which uses hardware acceleration to move screen contents. After dropping > those > checks scrollmode was hard-wired to SCROLL_REDRAW instead, which forces all > graphic cards to redraw every character at the new screen position when > scrolling. > > This change effectively disabled all hardware-based scrolling acceleration for > ALL drivers, because now all kind of 2D hardware acceleration (bitblt, > fillrect) in the drivers isn't used any longer. > > The original commit message mentions that only 3 DRM drivers (nouveau, omapdrm > and gma500) used hardware acceleration in the past and thus code for checking > and using scrolling acceleration is obsolete. > > This statement is NOT TRUE, because beside the DRM drivers there are around 35 > other fbdev drivers which depend on fbdev/fbcon and still provide hardware > acceleration for fbdev/fbcon. > > The original commit message also states that syzbot found lots of bugs in > fbcon > and thus it's "often the solution to just delete code and remove features". > This is true, and the bugs - which actually affected all users of fbcon, > including DRM - were fixed, or code was dropped like e.g. the support for > software scrollback in vgacon (commit 973c096f6a85). > > So to further analyze which bugs were found by syzbot, I've looked through all > patches in drivers/video which were tagged with syzbot or syzkaller back to > year 2005. The vast majority fixed the reported issues on a higher level, e.g. > when screen is to be resized, or when font size is to be changed. The few ones > which touched driver code fixed a real driver bug, e.g. by adding a check. > > But NONE of those patches touched code of either the SCROLL_MOVE or the > SCROLL_REDRAW case. > > That means, there was no real reason why SCROLL_MOVE had to be ripped-out and > just SCROLL_REDRAW had to be used instead. The only reason I can imagine so > far > was that SCROLL_MOVE wasn't used by DRM and as such it was assumed that it > could go away. That argument completely missed the fact that SCROLL_MOVE is > still heavily used by fbdev (non-DRM) drivers. > > Some people mention that using memcpy() instead of the hardware acceleration > is > pretty much the same speed. But that's not true, at least not for older > graphic > cards and machines where we see speed decreases by factor 10 and more and thus > this change leads to console responsiveness way worse than before. > > That's why I propose to revert those patches, re-introduce hardware-based > scrolling acceleration and fix the performance-regression for fbdev drivers. > There isn't any impact on DRM when reverting those patches. > > Helge Deller (2): > Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 > (from TODO list)" > Revert "fbcon: Disable accelerated scrolling" > > Documentation/gpu/todo.rst | 24 -- > drivers/video/fbdev/core/bitblit.c | 16 + > drivers/video/fbdev/core/fbcon.c| 540 +++- > drivers/video/fbdev/core/fbcon.h| 59 +++ > drivers/video/fbdev/core/fbcon_ccw.c| 28 +- > drivers/video/fbdev/core/fbcon_cw.c | 28 +- > drivers/video/fbdev/core/fbcon_rotate.h | 9 + > drivers/video/fbdev/core/fbcon_ud.c | 37 +- > drivers/video/fbdev/core/tileblit.c | 16 + > drivers/video/fbdev/skeletonfb.c| 12 +- > include/linux/fb.h | 2 +- > 11 files changed, 703 insertions(+), 68 deletions(-) Thanks Helge! Feel free to add my: Acked-by: Sven Schnelle
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Hi Greg, Greg Kroah-Hartman writes: > On Wed, Jan 19, 2022 at 12:22:55PM +0100, Greg Kroah-Hartman wrote: >> On Wed, Jan 19, 2022 at 12:08:39PM +0100, Helge Deller wrote: >> > This reverts commit 39aead8373b3c20bb5965c024dfb51a94e526151. >> > >> > Revert this patch. This patch started to introduce the regression that >> > all hardware acceleration of more than 35 existing fbdev drivers were >> > bypassed and thus fbcon console output for those was dramatically slowed >> > down by factor of 10 and more. >> > >> > Reverting this commit has no impact on DRM, since none of the DRM drivers >> > are >> > tagged with the acceleration flags FBINFO_HWACCEL_COPYAREA, >> > FBINFO_HWACCEL_FILLRECT or others. >> > >> > Signed-off-by: Helge Deller >> > Cc: sta...@vger.kernel.org # v5.16 >> >> Why just 5.16? This commit came in on 5.11 and was backported to >> 5.10.5. >> >> As for "why", I think there was a number of private bugs that were >> reported in this code, which is why it was removed. I do not think it >> can be safely added back in without addressing them first. Let me go >> dig through my email to see if I can find them... > > Ah, no, that was just the soft scrollback code I was thinking of, which > was a different revert and is still gone, thankfully :) > > This one was just removed because Daniel noticed that only 3 drivers > used this (nouveau, omapdrm, and gma600), so this shouldn't have caused > any regressions in any other drivers like you are reporting here. I'm counting more than 3 drivers using this. I think one of the reasons why it was reverted was that no one is actively maintaining fbdev. With Helge now volunteering i don't see a reason why it should stay reverted. If there are issues coming up i'm pretty sure Helge would care, and i would probably also take a look. /Sven
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Michel, Michel Dänzer writes: > On 2022-01-17 19:47, Sven Schnelle wrote: >> >>> * There's no new development in fbdev and there are no new >>>drivers. Everyone works on DRM, which is better in most >>>regards. The consequence is that userspace is slowly loosing the >>> ability to use fbdev. >> >> That might be caused by the fact that no new drivers are accepted for >> fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last >> year which was rejected for inclusion into fbdev[1]. >> >> Based on your recommendation i re-wrote the whole thing in DRM. This >> works but has several drawbacks: >> >> - no modesetting. With fbdev, i can nicely switch resolutions with >> fbset. That doesn't work, and i've been told that this is not supported[2] >> >> - It is *much* slower than fbset with hardware blitting. I would have to >> dig out the numbers, but it's in the ratio of 1:15. The nice thing >> with fbdev blitting is that i get an array of pixels and the >> foreground/background colors all of these these pixels should have. >> With the help of the hardware blitting, i can write 32 pixels at once >> with every 32-bit transfer. >> >> With DRM, the closest i could find was DRM_FORMAT_C8, which means one >> byte per pixel. So i can put 4 pixels into one 32-bit transfer. >> >> fbdev also clears the lines with hardware blitting, which is much >> faster than clearing it with memcpy. >> >> Based on your recommendation i also verified that pci coalescing is >> enabled. >> >> These numbers are with DRM's unnatural scrolling behaviour - it seems >> to scroll several (text)lines at once if it takes to much time. I >> guess if DRM would scroll line by line it would be even slower. >> >> If DRM would add those things - hardware clearing of memory regions, >> hw blitting for text with a FG/BG color and modesetting i wouldn't >> care about fbdev at all. But right now, it's working way faster for me. > > A DRM driver can implement the same fbdev acceleration hooks as an fbdev > driver. But i guess i can still only use the DRM_FORMAT_* encodings with that? What i need is a pixel bitmap with separate FG/BG colors. Is that possible? /Sven
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Thomas, Thomas Zimmermann writes: > Hi > > Am 14.01.22 um 19:11 schrieb Helge Deller: >> The fbdev layer is orphaned, but seems to need some care. >> So I'd like to step up as new maintainer. >> Signed-off-by: Helge Deller > > First of all, thank you for stepping up to maintain the fbdev > codebase. It really needs someone actively looking after it. > > And now comes the BUT. > > I want to second everything said by Danial and Javier. In addition to > purely organizational topics (trees, PRs, etc), there are a number of > inherit problems with fbdev. > > * It's 90s technology. Neither does it fit today's userspace, not >hardware. If you have more than just the most trivial of graphical >output fbdev isn't for you. > > * There's no new development in fbdev and there are no new >drivers. Everyone works on DRM, which is better in most >regards. The consequence is that userspace is slowly loosing the > ability to use fbdev. That might be caused by the fact that no new drivers are accepted for fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last year which was rejected for inclusion into fbdev[1]. Based on your recommendation i re-wrote the whole thing in DRM. This works but has several drawbacks: - no modesetting. With fbdev, i can nicely switch resolutions with fbset. That doesn't work, and i've been told that this is not supported[2] - It is *much* slower than fbset with hardware blitting. I would have to dig out the numbers, but it's in the ratio of 1:15. The nice thing with fbdev blitting is that i get an array of pixels and the foreground/background colors all of these these pixels should have. With the help of the hardware blitting, i can write 32 pixels at once with every 32-bit transfer. With DRM, the closest i could find was DRM_FORMAT_C8, which means one byte per pixel. So i can put 4 pixels into one 32-bit transfer. fbdev also clears the lines with hardware blitting, which is much faster than clearing it with memcpy. Based on your recommendation i also verified that pci coalescing is enabled. These numbers are with DRM's unnatural scrolling behaviour - it seems to scroll several (text)lines at once if it takes to much time. I guess if DRM would scroll line by line it would be even slower. If DRM would add those things - hardware clearing of memory regions, hw blitting for text with a FG/BG color and modesetting i wouldn't care about fbdev at all. But right now, it's working way faster for me. I also tested the speed on my Thinkpad X1 with Intel graphics, and there a dmesg with 919 lines one the text console took about 2s to display. In x11, i measure 22ms. This might be unfair because encoding might be different, but i cannot confirm the 'memcpy' is faster than hardware blitting' point. I think if that would be the case, no-one would care about 2D acceleration. Don't get me wrong, i'm not saying there's no reason for DRM. I fully understand why it exists and think it's a good way to go. But for system where a (fast) local console is required without X11, fbdev might be the better choice at the moment. Regards Sven [1] https://lore.kernel.org/all/87ee7qvcc7@x1.stackframe.org/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302 [2] https://lore.kernel.org/all/87ee7qvcc7@x1.stackframe.org/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981
Re: fbdev: Garbage collect fbdev scrolling acceleration
Helge Deller writes:
> I may have missed some discussions, but I'm objecting against this patch:
>
> b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration,
> part 1 (from TODO list)")
>
> Can we please (partly) revert it and restore the scrolling behaviour,
> where fbcon uses fb_copyarea() to copy the screen contents instead of
> redrawing the whole screen?
>
> I'm fine with dropping the ypan-functionality.
>
> Maybe on fast new x86 boxes the performance difference isn't huge,
> but for all old systems, or when emulated in qemu, this makes
> a big difference.
>
> Helge
I second that. For most people, the framebuffer isn't important as
they're mostly interested in getting to X11/wayland as fast as possible.
But for systems like servers without X11 it's nice to have a fast
console.
Re: [PATCH/RFT] fbdev driver for HP Visualize FX cards
Thomas Zimmermann writes: > Hi > > Am 06.11.21 um 22:02 schrieb Sven Schnelle: >> Thomas Zimmermann writes: >> >>> Hi >>> >>> Am 01.11.21 um 09:54 schrieb Sven Schnelle: >>>> Hi Thomas, >>>> Thomas Zimmermann writes: >>>> Thanks, i wasn't aware as i normally don't do any graphics related >>>> development. I take a look at dri and port the driver, which is >>>> hopefully not too hard. >>> >>> Sounds good. >>> >>> The one big difference when converting is that DRM really wants >>> drivers to support 32-bit XRGB colors. It's not a DRM limitation per >>> se, but a requirement of today's userspace programs. AFAICS your fbdev >>> driver uses a 256-color palette format. So the DRM driver would have >>> to convert >>> XRGB to 8-bit RGB332 and install a corresponding palette. Don't >>> worry, it's easy. Take a look at the cirrus driver for a simple DRM >>> driver. [1] >> I have converted the driver, > > Cool! > >> but am using FORMAT_C8 because i haven't >> figured out yet how to switch the card to XRGB. That's still on the >> TODO list. > > Don't worry. As I outlined , you can still convert any image from > XRGB888 to RGB332 and display this instead. > >> One question about hw blitting: with the old fbdev framework one >> could >> replace the fb_imageblit function. For normal console text, this >> function gets called with a monochrome bitmap, and an fg/bg color value. >> This makes it easy to use HW accelerated blitting for text. In the >> gpu/drm drivers i think i found only one driver (nouveau) doing this and >> that was via the drm fbdev layer. >> Is that still the way to go, or is there a better way to do HW >> accelerated >> text blitting? > > Simply call drm_fbdev_generic_setup() after registering the > device. This should give you a console. Yes, that's what i have, and it works. The only thing that is odd (and i'm not sure whether that's a bug or not), is that fbset changes the resolution of the framebuffer, but doesn't reprogram the hardware to the new resolution. That means if i boot with 1920x1080 resolution, and do a fbset -a 640x480-60, only a small part of the screen is used now, but the physical resolution stays at 1920x1080. I first thought that's a bug in my driver, but my x86 Thinkpad X1 with nouveau behaves the same. > Don't bother about HW-accelerated blitting. From what I've heard, it > barely makes a difference nowadays. And our generic helpers have > plenty of features. Not using them to get a small benefit from HW > blitting isn't worth it. Not sure. With my first driver (the fbdev/fbcon one without drm), that made a big difference when scrolling or the whole screen was updated. I never measured it, but i would think it was a 1:10 ratio. Regards Sven
Re: [PATCH/RFT] fbdev driver for HP Visualize FX cards
Thomas Zimmermann writes: > Hi > > Am 01.11.21 um 09:54 schrieb Sven Schnelle: >> Hi Thomas, >> Thomas Zimmermann writes: >> Thanks, i wasn't aware as i normally don't do any graphics related >> development. I take a look at dri and port the driver, which is >> hopefully not too hard. > > Sounds good. > > The one big difference when converting is that DRM really wants > drivers to support 32-bit XRGB colors. It's not a DRM limitation per > se, but a requirement of today's userspace programs. AFAICS your fbdev > driver uses a 256-color palette format. So the DRM driver would have > to convert > XRGB to 8-bit RGB332 and install a corresponding palette. Don't > worry, it's easy. Take a look at the cirrus driver for a simple DRM > driver. [1] I have converted the driver, but am using FORMAT_C8 because i haven't figured out yet how to switch the card to XRGB. That's still on the TODO list. One question about hw blitting: with the old fbdev framework one could replace the fb_imageblit function. For normal console text, this function gets called with a monochrome bitmap, and an fg/bg color value. This makes it easy to use HW accelerated blitting for text. In the gpu/drm drivers i think i found only one driver (nouveau) doing this and that was via the drm fbdev layer. Is that still the way to go, or is there a better way to do HW accelerated text blitting? Thanks Sven
Re: [PATCH/RFT] fbdev driver for HP Visualize FX cards
Hi Thomas, Thomas Zimmermann writes: > Am 31.10.21 um 20:53 schrieb Sven Schnelle: >> Hi List(s), >> i wrote a fbdev driver for the HP Visualize FX cards used some of >> the >> PA-RISC workstations. It utilizes some of the 2D acceleration features >> present in the card. >> [..] > > Thanks for all the work you put into this. We welcome drivers even for > older hardware, but not for fbdev. DRM is all the rage now and has > been for a while. I'd like to ask you to convert the driver to DRM and > resubmit to . > > I while ago, I made conversion helpers for this. You can look at [1] > for a trivial DRM drivers that wraps existing fbdev drivers for use > with DRM. Once you have that, it turns into a refactoring job. Thanks, i wasn't aware as i normally don't do any graphics related development. I take a look at dri and port the driver, which is hopefully not too hard. Sven
Re: [PATCH/RFT] fbdev driver for HP Visualize FX cards
Hi Thomas, Thomas Zimmermann writes: > Am 01.11.21 um 09:54 schrieb Sven Schnelle: >> Thomas Zimmermann writes: >> Thanks, i wasn't aware as i normally don't do any graphics related >> development. I take a look at dri and port the driver, which is >> hopefully not too hard. > > Sounds good. > > The one big difference when converting is that DRM really wants > drivers to support 32-bit XRGB colors. It's not a DRM limitation per > se, but a requirement of today's userspace programs. AFAICS your fbdev > driver uses a 256-color palette format. So the DRM driver would have > to convert > XRGB to 8-bit RGB332 and install a corresponding palette. Right now the driver only supports 8 bit pseudocolor, because i wanted to start with something easy to get the kernel fbcon running. I have no idea (yet) how to switch the card into other color formats. And neither how to do pseudo color with drm. But i'll figure it out i guess. > Don't worry, it's easy. Take a look at the cirrus driver for a simple DRM > driver. [1] Great, i also picked that driver as a template. :-) Thanks for your help and pointers, much appreciated! Sven
