On Sun, 2008-08-03 at 08:07 +0100, Dave Airlie wrote:

> Isn't that also what you are trying to do with GEM though.. match GPU 
> objects to the file interface.

Yes, with a 1-1 mapping between GPU objects and file objects. You can
use the normal read/write/mmap API on them. The reason we aren't using
fds now is just that the kernel cannot handle this many fds per process.

>  Now the thing is if you don't consider GTT 
> mapping to be the same as normal mapping, you need an Intel specifc GTT 
> map call,

I want to map these pages in two different ways, the first way is
through normal WB mapping which provides the expected memory semantics
(cached reads and writes). The second is to map them through the GTT
which offers two important benefits:

 1) WC mapping which avoids the need to clflush when passing data from
    application to GPU.

 2) Linearized access to tiled surfaces. This uses the tile swizzling
    HW in the GPU to construct a synthetic linear view of the tiled
    surface which is currently required when doing SW rendering from
    inside the X server.

>  however that means a do_mmap you don't intend on ever changing 
> to a real mmap call. Now you need to justify that to the vfs people.

Nope, I can use a 'normal' mmap call and have two different address
ranges within my object, one which maps the pages directly and one which
maps them through the GTT. No flags needed here.

> I do wonder if you are better having an alternate open method that flags 
> the mmap different, but that doesn;'t make much sense to me either. 
> However creating new MAP_GTT means berakign the generic interface.

I want to allow the mapping type to be selected on a per-use basis, not
be an attribute of the file handle. I don't generally know up-front what
kind of mapping will be needed. I could have a magic 'dup' ioctl that
gave me a new FD that would do the new mapping type, and use that.

-- 
[EMAIL PROTECTED]

Attachment: signature.asc
Description: This is a digitally signed message part

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to