Matt,

I have two questions regarding shared AGP memory.  The first is
inline--the correlary to Ian's question.  The second question is at the
end--it's more open ended.

"Sottek, Matthew J" wrote:
> 
> >This seems reasonable enough, but I'll have to think about it more
> >and learn a bit more about the AGP implementation to fully grok it.
> >On question I do have is what impact will this have (if any) on
> >chipsets that aren't UMA?
> 
> 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)?

> Certainly if
> the behavior catches on we could move some of it "up" into the
> device independent layers so that there is less work to be done in
> the drivers. Also, I have been careful to make sure that existing
> X servers + DRM run on this without any modifications. Both WITH and
> WIHTOUT a framebuffer device having installed the shared memory.

Good.
 
> I will post a patch shortly.

We look forward to seeing it.
 
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.

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).

Regards,
Jens

--                             /\
         Jens Owen            /  \/\ _    
  [EMAIL PROTECTED]  /    \ \ \   Steamboat Springs, Colorado

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to