On Mit, 2014-01-15 at 01:27 -0800, Eric Anholt wrote: > Michel Dänzer <[email protected]> writes: > > > On Die, 2014-01-14 at 05:34 -0800, Keith Packard wrote: > >> Michel Dänzer <[email protected]> writes: > >> > >> > Didn't SNA prove though that sharing the same pixel storage for GPU and > >> > CPU doesn't give the overall best performance even with Intel GPUs? It > >> > certainly doesn't with most other GPUs. > >> > >> Yes, and strangely enough, this change is designed to *help* with that > >> transition. We want to switch to a pure hardware accelerated design, but > >> current hardware can't deal with 1bpp surfaces. That leaves us with two > >> choices for depth 1 objects: > >> > >> 1) Never draw them with the GPU and leave them formatted 1bpp. > >> > >> 2) Always draw them with the GPU and format them 8bpp. > > > > 3) Given there is no point in sharing storage between CPU and GPU, keep > > them formatted 1bpp for the CPU and convert them to >1bpp for the GPU > > (and back to 1bpp for CPU readback). > > One of keithp's assumptions has been that you have > reasonable-performance access to the texture memory for doing fallbacks. > It's how intel's uxa/glamor code manages decent performance with glamor > without running into some of the problems that radeon has faced (Like, > wow, diagonal lines. That was amazingly bad). > > 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. There are a couple of GL extensions related to this, such as > GL_INTEL_map_texture (which does't solve telling you how the texture > data is laid out in memory, plus has some very divergent mapping behavor > to the GL_ARB_mbr/GL_ARB_vbo-related MapTextureImage hook we have in > Mesa right now), or EGL_KHR_lock_surface3 (why EGL? I want to map GL > textures, not EGL crap). I think the right answer is to define a spec > that basically gives you Mesa's MapTextureImage hook, with format > definitions.
What's the plan for dealing with GPU tiling in this scheme? Disabling tiling for all textures which could be hit by software fallbacks seems like a bad plan for GPU performance. > If you assume native mapping of texture buffers for fallbacks, then > having the X Server be able to operate directly on those textures makes > sense. But why are you putting so much effort into trying to share storage between GPU and CPU for bitmaps, given that SNA has apparently proved such sharing is not beneficial overall even on Intel GPUs? It seems more useful to spend effort on maintaining separate persistent CPU storage for software fallbacks, which has proven effective in EXA and SNA. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
