On Mon, 2008-08-04 at 05:13 +0100, Dave Airlie wrote: > Well it can now, we just need to fix the X server :)
Yeah, I just discovered that today. Weird that the kernel was fixed between the last time I looked and now though; NR_OPEN had been 1024 for many years prior. However, it's not just fixing the X server -- we'd have to fix every GL application as well to not assume their fds were always in a narrow range. Anyone care to wager how many 3D apps still use select? We could get higher fds just by using dup2 and managing fds up in user space. Making sure we didn't step on valid fds would be a pain. Plus, we're still stuck with increasing the max fd for each DRI application. I'm sure a patch which had DRM increase this from inside the kernel with no protections would be welcome by the kernel community. > Well bit-31 is now a flag, just under an assumed named with a fake > passport. No argument; if there were a flag parameter to mmap, we'd just use it. Given that we're using ioctls instead of raw syscalls, it seems like we could just use a flag were it not for the lack of any additional parameter to the underlying mmap fop. Lacking this, we're stuck using a kludge (either fake linearized allocs from the drm fd, or bit 31 on the gem object), or creating a separate per-object fd (and underlying file/dentry/inode) for this other mapping. Of these, the kludge plan seems more efficient, and I do prefer the per-object kludge to the drm-fd kludge, but I'm not that tied to either; the underlying code would all be the same, except for how to identify which gem object the user was talking about. > The question is whether this matters at all, or whether Intel > driver can just do it that way and have intel specific hooks into the > shmem mmap/fault code. I don't think so; I can wrap the mmap fop easily enough and substitute my own vma initialization. To invalidate the mapping after pulling the object from the GTT, it looks like zap_page_range will work, then my fault handler would get called on access to bind back to the GTT and re-validate the map. Or so it seems to me; I haven't tried it yet, and I won't have time to do that for a couple of weeks. > For radeon this interface would suck, an > object can be VRAM, main RAM, GTT, tiled, endian swapped, etc. We pass tile information into the kernel for our objects now; we assume that the GTT map user wants a linear view of the object suitable for plain old fb drawing. The only semantic distinction between the regular mmap and the GTT mmap is this linearization of tiled objects; the WC mapping doesn't affect how things work, only how fast each read/write operation is, and whether the kernel will be doing additional CPU cache flushing. > but if I > don't care about that, if Intel were to use mmap2 then in theory you could > use an even higher bit than bit 31. Yeah, someday we'll need to deal with single objects larger than 2GB. -- [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
