> > 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
You really want to work this out in advance, at superioctl stage it is too late, have a look at the changes I made to the dri_bufmgr.c classic memory manager case to deal with this for Intel hw, if you got to superioctl and failed unwrapping would be a real pain in the ass, you might have a number of pieces of app state you can't reconstruct. I think DirectX handled this with cut-points where with the buffer you passed the kernel a set of places it could break the batch without too much effort. I think we are better just giving the mesa driver a limit and when it hits that limit it submits the buffer. The kernel can give it a new optimal limit at any point and it should use that as soon as possible. Nothing can solve Ians problems where the app gives you a single working set that is too large at least with current GL. However you have to deal with the fact that batchbuffer has many operations and the total working set needs to fit in RAM to be relocated. I've added all the hooks in dri_bufmgr.c for non-TTM case, TTM shouldn't be a major effort to add. > > My understanding of future hw is that we are heading to virtualized GPU > memory (IRQ assistance for page fault). > I think we'll have this for r700, not sure i965 does this, r500 has I think per-process GART. Dave. ------------------------------------------------------------------------- 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
