Michel Dänzer <mic...@daenzer.net> writes: > On Die, 2014-01-14 at 05:34 -0800, Keith Packard wrote: >> Michel Dänzer <mic...@daenzer.net> 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. 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.
pgpfqBuodSQHb.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel