On Mon, 19 May 2008 03:49:04 -0700 (PDT) Keith Whitwell <[EMAIL PROTECTED]> wrote: > > > 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 radeon the plan was to return error from superioctl as during superioctl and validation i do know if there is enough gart/vram to do the things. Then i think it's up to upper level to properly handle such failure from superioctl > The only real way to solve it is to move to a page-based virtualizaization of > GPU memory, which requires hardware support and isn't possible on most cards. > Note that this is different from per-process GPU address spaces, and is a > signficantly tougher problem even on supporting hardware. > > Note there are two concepts with similar common names: > > - virtual GPU memory -- ie per-context page tables, but still a > buffer-based memory manager, textures pre-loaded into GPU memory prior to > command execution > > - virtualized GPU memory -- as above, but with page faulting, typically > IRQ-driven with kernel assistance. Parts of textures may be paged in/out as > required, according to the "memory access" patterns of active shaders. > > It's not clear to me which of the above the r300 & nv people are aiming at, > but in my opinion the latter is such a significant departure from what we > have been thinking about that I have always believed it should be addressed > by a new set of interfaces. > My understanding of future hw is that we are heading to virtualized GPU memory (IRQ assistance for page fault). Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
