On Mon, 2008-05-19 at 00:14 -0700, Ian Romanick wrote: > - - I'm pretty sure that the read_domain = GPU, write_domain = CPU case > needs to be handled. I know of at least one piece of hardware with a > kooky command buffer that wants to be used that way.
Oh, so mapping the same command buffer for both activities. For Intel, we use batch buffers written with the CPU and queued to the GPU by the kernel, using suitable flushing to get data written to memory before the GPU is asked to read it. It could be that this 'command domain' just needs to be separate, and mapped coherent between GPU and CPU so that this works. However, instead of messing with the API on some theoretical hardware, I'm really only interested in seeing how the API fits to actual hardware. Having someone look at how a gem-like API would work on Radeon or nVidia hardware would go a long ways to exploring what pieces are general purpose and which are UMA- (or even Intel-) specific. > - - I suspect that in the (near) future we may want multiple read_domains. That's why the argument is called 'read_domains' and not 'read_domain'. We already have operations that read objects to both the sampler and render caches. > - - I think drm_i915_gem_relocation_entry should have a "size" field. > There are a lot of cases in the current GL API (and more to come) where > the entire object will trivially not be used. Clamped LOD on textures > is a trivial example, but others exist as well. There are a couple of places where this might be useful (presumably both offset and length); the 'set_domain' operation seems like one of them, and if we place it there, then other places where domain information is passed across the API might be good places to include that as well. The most obvious benefit here is reducing clflush action as we flip buffers from GPU to CPU for fallbacks; however, flipping objects back and forth should be avoided anyway, eliminating this kind of fallback would provide more performance benefit than making the fallback a bit faster. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
