On Tue, 2010-12-14 at 15:30 +0000, Robert Bragg wrote: > On Mon, Dec 13, 2010 at 6:24 PM, Owen Taylor <[email protected]> wrote: [...] > > This is surprisingly GPU intensive - say if you have a stack of 8 > > fullscreen 1920x1200 windows - not a weird situation - then at the > > beginning you are drawing: > > > > 8 * 1920 * 1200 * 60 = 1.1Gpix/sec > > Right, this is a tricky issue that pops its head up every now and > then; we've also had others come and ask similar questions. I think > quite a lot of applications would like to take better advantage of the > depth buffer to avoid overdraw. > > The "renderlist" work that we started designing a while back was meant > to take us in a direction that would let Clutter be able to > automatically use the depth buffer to avoid overdraw of actors with no > work from the application. Ref: > http://wiki.clutter-project.org/wiki/Cogl_Render_Lists > > I think that the renderlist needs some further design iterations, but > actually at the low level Neil and I have been slowly putting the > building-blocks into Cogl to enable us to take another pass at this. > > I think perhaps we can find a shorter term solution for gnome-shell, > but it would be good to to have more input into a longer term > renderlist like approach too.
Interesting reading; I don't have a lot of immediate comments on it other than that it sounds like a lot of work :-) - Probably worth doing some micro-benchmarking on the approach of doing two passes with different alpha tests; I know that on older generation Radeons that conditional depth writes disables a lot of the Z buffer optimization so you won't get any sort of compression. (Obviously, any sort of complex approach is going to lose in simple cases - but by how much?) - It would be really useful to have some macro-benchmarks that represent "typical" usage of clutter. [...] > > * Make the Window actor (a custom actor) munge the x/y coordinates > > when painting with Cogl so after the perspective transform the x/y > > coordinates are the same independent of Z. > > > > * Use a vertex shader to adjust the z coordinates after the perspective > > transform. > Right, this is what we would have been doing with the renderlist > approach. After projecting the users geometry we would have replaced > the z with the painter's algorithm z and painted opaque geometry front > to back. > > So I guess the idea would be to use the cogl shader API to create a > glsl or arbfp vertex shader which can be associated with the materials > used by your window actors. (I wouldn't recommend using the Clutter > actor set shader mechanism for this.) > > Somehow then there needs to be some interaction between the container > that knows the stacking order of the windows and the window actors so > that the stacking-z gets set as a uniform on the shaders. Yeah, this is the hard part generally about figuring out a short-term solution - it's messy abstraction breaking to get stacking order to the actors. > One concern I have a.t.m is that we probably don't track custom > uniforms in a useful way a.t.m and likely you will end up with the > same program associated with all of your windows and when you change > the uniform for each window you'll in fact just end up changing the > uniform on the same program and then when you draw all windows will > end up with the same stacking-z. I wonder if we need to move the > ownership of uniforms from CoglProgram into CoglMaterial. It's not clear to me if uniforms are the right way to go - at least what Eric Anholt told me anyways is that there are strict limits to the number of uniform changes that can be pipelined on Intel gpu's. While that's probably not a big deal if we're drawing one full-screen window per z, it might be better to pass the painter's algorithm z into the shader as a vertex algorithm. > So I suppose when your window container paints it would: > 1) clear the Z for the bounds of the container (send a quad with z = 0 > using a material with depth writing enabled, depth testing disabled) > 2) paint opaque windows front to back (all with a special material > including the vertex program + with depth writing/testing enabled) > 3) paint semi-transparent windows back to front (also with a special > material including the vertex program + depth testing enabled) Yes, pretty much exactly. > Note: for now you'll probably need to use the > COGL_ENABLE_EXPERIMENTAL_API define to get the required control over > the depth writing/testing state, beyond the deprecated > cogl_set_depth_test_enabled function. > > > > > Any other ideas that I'm missing? > window containers could potentially build a mask up in the stencil > buffer as windows are drawn so stencil testing could be used to avoid > overdraw. This would rely on your container being able to do the depth > sorting and painting front to back. This approach wouldn't support > semi-transparent windows though. Similarly, I thought about the approach of drawing all the windows front-to-back with the same z and letting the default GL_LESS comparison take care of culling overdrawn, but then you can't do the subsequent back-to-front draw of elements with transparency. - Owen _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
