>> No impact whatsoever. I specifically didn't touch ANY device >> independent code. It is all contained within the i810's driver.
>Have you gotten any feedback from developers working with any other UMA >architectures (Sis or Savage for example)? The only feedback I've gotten is from this list. Is there another/better place I should solicit further feedback? >> I will post a patch shortly. >We look forward to seeing it. I'll get to it today :) >My second question is can this kind of shared AGP memory be extended, >at least on Intel to all the memory for the graphics subsystem that >isn't share across contexts? I'm thinking about private backbuffers, >textures, command buffers, etc. The main purpose would be to maximize >the available memory in the AGP aperture, which would be especially >usefull for a 3D tiling window system. This is what I'm currently doing with the framebuffer driver I'm finishing up. I have fixed areas within the Gart for different uses. All new drivers would use these fixed offsets to maximize alignment for things that need to be aligned, Minimize the number of tiles needed to cover the things that should be tiled, and allow for totally dynamic memory based on need. Currently I have this for i810: Use Offset Size FB 0x0 5MB (Best mode is really 16x12 which fits here) BB 5MB 5MB DB 10MB 5MB (1MB hole, could be moved up to FB) Video 16MB 8MB IRing 24MB 512k LRing 24.5MB 512k Scratch 8MB 8MB Scratch 32MB 32MB So I expect that the first 24MB of memory would all be shared between all clients. The rings are shared as well but only the memory is shared, the clients need to work out a way to shared the USE of the rings. The rest of the memory would be used for any scratch purpose including memory that isn't shared. Although I didn't fully implement it yet (I don't have a use case) I did add an EXCLUSIVE type which basically means !shared. This would make sure to return -EBUSY if any overlap happened. >Imagine a UMA system with lots of available memory but only a 64M >graphics window. Display memory and enough memory for each >applications front buffer would be permanently allocated from the >64M window. The remainder could be shared as 3D context specific >memory that utilized a high speed context switch method (shared >AGP memory). I didn't quite get what you were asking here... Are you suggesting tying the agp resources to the DRM context such that whenever a context is active it's memory is automatically mapped into the gart so it doesn't have to worry about textures going away and such? Certainly sounds interesting and I think the existing alloc/bind/unbind/free method works just fine for doing that. You just need to have a per context agp_mem handle and have the DRM switch the memory on the fly. I'm not sure if the overhead of the memory switch would be higher than the overhead of managing textures in a shared buffer but it is probably worth investigation. One of the things I've disliked about the DRM is the locking rather than full transparent virtualization, the way it currently is a poorly designed client can hold the lock too long and badly impact the rest of the system. Sort of like cooperative multitasking... it CAN work but only if everyone plays the game well. Having context specific agp resources gets us one step closer to real transparent virtualization. I was planning on experimenting with the reverse. Having per context shared agp memory that was reference counted so that when a drm context is created the memory pops into existence and is shared by all current drm contexts just as it is now. But when the last drm context goes away so does the memory. This hold for back buffers and depth buffers too. Wasting all that memory when 3d isn't in use is quite an impact to a system with say 64MB ram or less. -Matt _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
