I've been working with Gallium for the last 3-4 months on the XvMC state tracker and I want to bring up some additions that I think are worthwhile, since I hear there might be some interface changes soon.
I think there need to be more texture usage flags, along the lines of D3D's static and dynamic, so I'm proposing PIPE_TEXTURE_USAGE_STATIC and PIPE_TEXTURE_USAGE_DYNAMIC, to allow the client to influence where the driver might place these textures. Right now with Nouveau there is no way to know if a texture would be better off in VRAM or GART, and for video we very much prefer GART, unless the texture has PIPE_TEXTURE_USAGE_RENDER_TARGET. Also, it would be nice if the mapping interface allowed for mapping a subset of a buffer, and accepted a PIPE_BUFFER_USAGE_DISCARD. The DISCARD flag would allow the driver to rename the buffer (create a new one and point to it, free the old one at a later time) if it was still in use when the map was requested, thereby not blocking on map. Locking a subset would allow for minimal read back from VRAM, and if the client locked the entire buffer _without_ PIPE_BUFFER_USAGE_CPU_READ the driver might also elect to rename the buffer, since the semantics would allow it. The driver might also map immediately if it could be determined that the mapped region was already read by the GPU and so could be written to. Right now for video we use triple or quadruple buffers just to keep parallelism going, it would be nice to let the driver handle it and use the minimum number of buffers at any given moment. Samplers could be allowed to hold texture format info, thereby allowing on the fly format switching. On Nvidia the texture format is a property of the sampler, so it's possible to read a texture as one format in one instance and another format in another instance. Likewise a render target's format is emitted when it is set as a target, so a format attached to pipe_framebuffer_state, or a new state object analogous to a sampler (e.g. an emitter) would be very handy. The format at creation time could be kept for hardware that can't do this, then it's just a matter of checking/requiring that format at use time matches format at creation time and signaling an error otherwise. This is to get around HW limitations on render targets, so we render to a texture in one format, and read from it in another format during the next pass. Thanks, Younes ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
