I've been looking at and thinking about some of the difficulties we had with implementing the SVGA driver under gallium, and areas where gallium doesn't match the behaviour of the main graphics APIs.
It turns out that one of the main divergences between gallium and other APIs also was an area that caused us significant pain in constructing the driver -- specifically the gallium resource model. Even more specifically, the way textures and buffers are managed in gallium is fairly divergent from GL, and as so often turns out, not an improvement. We can't interleave uploads and drawing, don't have an obvious answer for many resource sharing questions, and have two different resource abstractions with two different upload paths. Things I'd like to improve are: a) Be able to interleave texture/buffer uploads and rendering into a single command buffer. b) Clarify cross-context update semantics for view and transfer entities. c) Make clearer distinction between GPU-side entities such as textures and vertex buffers, and the mechanism for transferring between CPU and GPU (or guest and host). d) Make sharing of buffers and/or textures an explicit operation, be able to know when a buffer/texture is context-private. e) Improved up/download path for 3D textures, cubemaps, etc. f) Implement new concepts such as array textures, buffer render targets and/or sampling from buffers as well as textures. I can't do all of this at once. In the first phase I'd like to eliminate some of the worst problems with the current model, then look to extend it in subsequent phases. To that end, this is what I'm planning on doing in the current round of changes: Step 1: Make transfers and views per-context ============================================ By making transfers context-private and non-shareable, it becomes possible for a driver to implement interleaved drawing and dma-uploads within a single command buffer. By making views context-private, difficult questions about what happens when two contexts share a view are eliminated, and sensible rules about visibility of changes to resources between contexts can be established - most likely by following the existing GL conventions. Step 2: Unify buffers and textures, have a single upload path ============================================================= Several linked changes: a) Remove pipe_buffer map/unmap facilities b) Unify pipe_buffer and pipe_texture, perhaps underneath new pipe_resource c) Extend transfers to be able to target buffers as well as textures Currently pipe_buffers are both a cpu/gpu transfer mechanism and a gpu-side rendering entity. Would like to be able to treat these two roles separately. Contrast with textures which are purely gpu-side abstractions, with all cpu interactions funneled through the tex_transfer mechanism. Step 3: Add immediate/interleaved upload data transfer ====================================================== A very common usage for interleaved drawing and uploads relates to constant buffers. In particular, imagine the modelview and projection matrices living in a constant buffer. Typical GL rendering might then map onto: - update modelview in constant buffer - draw - update modelview in constant buffer - draw ... As the modelview is already available in user memory and we would like to be able to let the driver decide for itself the most efficient path for small, interleaved uploads, it would be preferable to simply pass a pointer to the data directly to the driver and allow it to implement the upload internally. Thoughts, feedback? Keith ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
