On Mon, 2009-05-25 at 22:08 +0200, Nicolai Hähnle wrote: > > [ Even with the change, there still is a noticeable performance win from > > dropping the size of the DMA buffer in mesa - binding the 1M buffers > > into AGP space takes a measurable amount of time. ] > > Forgive me if you've mentioned it before, but what is your testcase? > > If I recall the discussions correctly (and admittedly I've been somewhat away > for a while), the idea was to have big buffers so that games can just keep > scheduling drawing commands virtually indefinitely (maybe even up to a full > frame worth of draw calls). Obviously, if your testcase is in fact not one of > those eyecandy-crazy shooters, then that's a bad idea for you.
I've been testing with mutter/gnome-shell (GL based compositor, with UI elements in the GL scene graph as well.) It certainly doesn't look that much like a game; the vertex/state-change ratio is probably lower than for most games since there are no complex 3D models - the most vertex intensive thing it's doing is text (quad per glyph). But on the other hand, it's using maybe 1/1000th of the vertex buffer before it fills its command buffer and releases the DMA buffer, so that's a pretty big gap to make up if games are that different. And my guess would be that modern eye-candy-crazy shooters are using VBO's, which, if I'm not mistaken are entirely independent of the DMA buffer mechanism. If you have a complex 3D model with thousands of vertices, you really don't want to re-emit it every frame. It should be noted that using smaller buffers doesn't prevent you from emitting way ahead of the GPU; it just increases the overhead if you need to create more buffers (syscall, buffer object structure allocation, SELinux, etc.) > Wouldn't the right approach to this problem then be to dynamically scale the > buffer size based on what the application actually does? You might have apps that are doing one thing for one part of the frame, and something quite different from another part of the frame. To me, it seems, that the first question is whether rcommonFlushCmdBuf() actually needs to call radeonReleaseDmaRegion(). Can multiple subsequent command buffers share the same DMA buffer? If so, that reduces the complexity here from: - How many vertices does the app emit per byte of state? To: - How many vertices does the app emit? You might even be able to keep using the same DMA buffer across multiple frames. Each 3D app would essentially have a permanent megabyte (or whatever) of buffer space allocated. Measurements of the amount of DMA buffer space being used per frame by different apps would, of course, be interesting. - Owen ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
