-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Romanick wrote:
| I've read the GEM documentation several times, and I think I have a good | grasp of it. I don't have any non-trivial complaints about GEM, but I | do have a couple comments / observations: | | - 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. | | - I suspect that in the (near) future we may want multiple read_domains. | ~ I can envision cases where applications using, for example, vertex | feedback mode would want to read from a buffer while the GPU is also | reading from the buffer. | | - 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. Another question occurred to me. What happens on over-commit? Meaning, in order to draw 1 polygon more memory must be accessible to the GPU than exists. This was a problem that I never solved in my 2004 proposal. At the time on R200 it was possible to have 6 maximum size textures active which would require more than the possible on-card + AGP memory. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMUKGX1gOwKyEAw8RAqGGAJ95wX42j7vQPPsOggwWDiR9L+mPrACfZ9GV EZClpUDfr035nlt+s78bKY8= =zfbH -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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
