Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Keith Whitwell wrote: > |> 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. > | > | I don't actually think the problem is solvable for buffer-based memory > managers -- the best we can do is spot the failure and recover, either > early as the commands are submitted by the API, or some point later, and > for some meaning of 'recover' (eg - fail cleanly, fallback, > use-smaller-mipmaps, disable texturing, etc). > > For OpenGL, the only valid choice there is to fallback to software. > That was my question, actually. At what point does GEM detect the > over-commit and how is it communicated back to user mode? > > > Actually I think neither GEM nor TTM deals with this problem. GEM leaves everything up to the driver writer. TTM utility routines returns an -ENOMEM to the device driver, in which case the device driver should evict everything possible to get rid of fragmentation and retry.
At that point we can't even fall back to software, so user-space really needs to be able to assume a certain always-working space for texture. /Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFIMbhsX1gOwKyEAw8RApmPAKCIjLLH/RRHgCWOlwxCNj8Cug4NfQCbBeZQ > vEjqToEq75bAS/BYNh02OBs= > =UhzR > -----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 > ------------------------------------------------------------------------- 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
