Re: Re: waitforVBlank, how does this even work?

["Ville Syrjälä" <syrjala@sci.fi>]

On Sat, Mar 05, 2005 at 09:35:00AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2005-03-04 at 15:18 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote:
> > > 
> > > > > Oh, but I was not suggesting that. I just meant that interrupt handling 
> > > > > code is self-contained and can easily serve several consumers.
> > > > 
> > > > I'm with you here. And the same should IMHO hold for DMA handling. And for 
> > > > memory management of course.
> > > 
> > > DMA handling is the main piece of what the DRM does,
> > 
> > The actual bits that feed DMA buffers to the hardware are very small. And 
> > I just meant that like the IRQ code those need to be easily accessible 
> > from other components (fbdev, video capture module etc.)
> 
> "Feeding DMA buffers" in what sense ? The buffers are matches with
> various functions. For AGP buffers, you have to get into the whole
> allocation mecanism, pure PCI DMA isn't always possible on some hosts.

Allocating buffers should IMO belong to the memory management part.

If DMA isn't possible then I suppose the comammands/data would have to fed 
via MMIO. But that is a detail only the DMA component would have to know.

> Also, those buffers are what ? Data for blits ? textures ? they always
> belong to some sort of command, which we want to eventually validate in
> a way by the kernel unless you want your client to be root...

Usually the buffers are series of commands. And they don't need to 
validated when they come from the kernel. Validating buffers from 
userspace is done by the DRM.

> No, honestly, I don't see the point in breaking up our current DRM/fbdev
> thing.

From the userspace perspective nothing should change.


For the memory management I have some rough ideas but I'm not an expert 
here so let me know if I'm talking out of my ass...

The GART (be it AGP, PCI or some other mechanism) should be only used by 
the memory management part to dynamically map required bits of system RAM 
for the graphics hardware to access. Clients of the memory management 
system should only have to ask thing like "give me a buffer of size x with 
priority y". Those buffers could then exist in system or video memory and 
the memory manager could actaully dynamically move them around without the 
clients even knowing about it. At one point the buffer could be in video 
memory and in system memory the next. If the hardware can render to system 
RAM then it could be totally transparent to the user. With hardware that 
can't render to system RAM I suppose the best idea would be to always move 
the buffers to system RAM when software access is required. That way the 
software could lock the buffer for any period of time without disturbing 
the memory managers work.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click