> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Keith Packard > Sent: Thursday, January 16, 2014 1:43 AM > To: Eric Anholt; Michel Dänzer > Cc: [email protected] > Subject: Re: [PATCH 0/4] fb support for 8bpp bitmaps > > Eric Anholt <[email protected]> writes: > > > One of keithp's assumptions has been that you have > > reasonable-performance access to the texture memory for doing fallbacks. > > It's actually a bit more subtle than that; what I want is to ensure that when we > switch to Glamor, we don't have any performance cliffs on existing systems. > The easiest way to ensure that is to make sure we can fall back to the existing > code without any performance penalty. I agree with this point. Current glamor will treat those pixmaps who have a valid drm buffer as a special type of pixmap which could be pass back to the DDX layer driver to do the rendering. Then for this type of pixmap, when hit fallback, we don't handle the fallback within glamor which is extreme slow currently. Instead, we just simply return a false to the DDX driver, and the DDX will take care of it.
At the time I implemented the above logic the KHR_gl_texture_2D_image extension was not ready, only a small set of pixmaps have a valid drm buffer attached, so the fallback is still painful sometimes. I think we can get a valid drm buffer for every texture on demand by using the KHR_gl_texture_2D_image extension now. Ideally, we may avoid any single fallback within glamor. > > For systems which currently depend for performance on using the CPU for > some rendering operations, that means continuing to use those same paths > until we create replacement code that offers comparable performance. > > Ideally, we'll eventually write code which makes all core operations faster with > the GPU than with the CPU. > > > I'd like to see glamor do better at rendering without fallbacks, and I > > think ajax is also interested in pushing on that front. It's > > certainly not there yet, though, so you need fallbacks and they need > > to be less awful if we want glamor to compare to native acceleration > > within this year. > > Ideally, fallback performance under Glamor will match fallback performance > under UXA. Then, we can replace fallbacks one at a time with even faster code > and keep everyone happy with the switch. > > -- > [email protected] _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
