--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> > --- Ian Romanick <[EMAIL PROTECTED]> wrote:
> >>Michel Dänzer wrote:
> >>
> >>>It could waste a lot of RAM.
> >>
> >>Yup. This is one of the bad parts of the AGP implementation on Linux.
>
> >>Once the AGP aperture is setup, it always has non-swappable memory
> >>backing it. If you set a 256MB aperture, it is as if you took 256MB
> out
> >>
> >>of your computer. We really need a mechanism to say "This range of
> the
> >>aperture doesn't need any backing." This could have security
> >
> > The 'owner' of mapped AGP space would be the only one who could unmap.
> As
> > I see it contexts can't share AGP space so there is no sharing issue.
>
> In our case, I guess the owner is the X-server? Or is it the DRM?
> Hmm...
>
I realy don't think the X-server would use ANY memory exept the background
and mouse's icon. All images and textures are uploaded by some program,
not by the Xserver. Even window boaders belong to the window-manager.
The X-server may map the AGP memory, but it's not REALY the owner.
> >>implications. What if one process removes the backing from a region
> of
> >>the AGP aperture a the same instant another process tries to texture
> >>from that range? Random memory reads? System crash? Dunno...
> >
> > This just can't heppen, no sharing of AGP space, right?
>
> Video memory and AGP memory is accessed by all direct rendering
> processes and the X-server.
>
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.
THE END.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
