On 04-Jun-2004, Mike Mestnik wrote: > Right, but thay must not EVER step on each other. From the time one > uploades a texture and then later unloads it, that space can't be used. > After an unload the memory can be maped back to system use. > > I think the kernel's memory subsystem should be the one to manage and > setup AGP memory. This way it can allocate unused AGP memory for ANY > other application. This is a long way away from where we are now but it > definatly is where we should be. On IGP systems it's even more important > that video ram is also manged by this subsystem.
Though I disagree with some of your conclusions, and why you think some things should be, I agree with you here. The kernel should manage video memory, X shouldnt. In many cases, it would be advantagious to have one outside system (the kernel); one being of which fbcon buffer usage, x buffer usage, and dri texture space/other buffer usage in and out of x all map memory, but may easily trip over each other if there are driver bugs; this readly shows itself when you try to run multiple X at once, dri wont let you have multiple contexts. Which brings me to mention something else: I fully believe that the kernel should be completely managing all aspects of memory and state management of both 2D and 3D hardware. The kernel's portion of DRI should be providing methods to allow multiple DRI using apps (such as multiple xservers running at once) and multiple opengl apps within a single DRI context to work flawlessly with each other. Currently, projects such as DirectFB suffer because there is really no unified method to do this. DirectFB nor xservers should ever be managing memory on their own, nor managing parts of the DRI context on their own. It becomes very easy to get different peices of software to break each other, or simply prevent each other from working at the same time. This, however, requires a more unified driver system (on platforms that support it) between DRI and fbcon. (Does BSD have an equivilent to this?) This new hybrid system would do all memory management, do the actual resolution and depth changes, expose 2D and 3D hardware acceleration functions, allow applications (DirectFB, xservers) to query the available acceleration methods, provide DRI contexts and help manage them so multiple GL apps would work on all drivers (which, afaik, few if any correctly support), and probably increase the over all quality of all software. keithp, if you're around, I would love to hear your thoughts on this, and may be would you be interested in implementing something like this? (It is waaaay beyond my ability to even think of developing.) -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
signature.asc
Description: Digital signature
