On Fri, 2008-08-01 at 14:34 -0400, Kristian Høgsberg wrote: > Are you saying that you're not planning to make the mmap ioctl a real > mmap syscall when/if that's feasible or that it's okay to add > intel-gem specific bits to the mmap arguments? I recall Thomas asking > for a flags argument to the GEM create ioctl...
Note that there aren't intel specific bits here, the intel back-end just has two separate address space ranges which expose different mappings. So, it could still be managed through the regular mmap API. However, it does seem a bit kludgy, and it might be better to have separate flags. However, it also seems odd to create two different mappings to the same address, that have different cache behaviour -- technically, this isn't valid for Intel PTEs, but as one mapping goes through the GTT, the underlying physical address seen by the CPU differs. Also, I don't know enough about the linux mmap implementation to say whether it will do 'odd' things with vmas which map the same address range in a file. Using separate address ranges means I can see the difference down in my mmap driver entry point, which seems like a feature. Alternate suggestions are welcome, especially if they point to a potential underlying implementation. -- [EMAIL PROTECTED]
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
