"Sottek, Matthew J" wrote:
>
> >> 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?
Not that I know of, other than pinging the developers directly.
> >> 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)
with 16x12 padded out to 2k at 16bpp...this makes sense.
> BB 5MB 5MB
BB...Backbuffer?
> DB 10MB 5MB
DB...Doublebuffer? Frontbuffer?
> (1MB hole, could be moved up to FB)
> Video 16MB 8MB
8MB? Must be for 16x12 padded to 2K w/ 24bit YUV.
> IRing 24MB 512k
> LRing 24.5MB 512k
> Scratch 8MB 8MB
> Scratch 32MB 32MB
Why the seperate 8MB and 32MB Scratch? GART table setup requirements
maybe?
>
> 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.
This seams reasonable in the current implementation.
> 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?
Exactly.
> 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.
I agree, we would need to investigate whether invalidating the texture
cache wouldn't be faster. However, I'd like to point out that I'd even
like to switch out the back buffer and as much command processing as
possible and try for more transparent virtualization.
> 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.
Yes, this is the downside of explicit locking. Note however that the
DRM locking mechanisms are voluntary and a driver could be written
without them--provided you have enough hardware support to implement
asynchronous implicit locking.
> Having context specific agp resources gets us one step
> closer to real transparent virtualization.
Agreed, but there are more tough issues to address here. Would having
the command buffers in "shared AGP memory" be difficult to manage? A
memory faulting mechanism would also be needed as well as a reasonable
way to "take away" the HW from an existing context at switch time.
> 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.
Understood--you're really going after a low memory situation and I'm
talking about a very high memory situation. If this is a good mechanism
it should be usable for both.
Regards,
Jens
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
