LWN.net Logo

GEM v. TTM

GEM v. TTM

Posted Dec 26, 2008 1:13 UTC (Fri) by dibbles_you (guest, #45004)
Parent article: GEM v. TTM

"The GEM API tries to do away with the mapping of buffers into user space. That mapping is expensive to do and brings all sorts of interesting issues with cache coherency between the CPU and GPU. So, instead, buffer objects are accessed with simple read() and write() calls. Or, at least, that's the way it would be if the GEM developers could attach a file descriptor to each buffer object. The kernel, however, does not make the management of that many file descriptors easy (yet), so the real API uses separate handles for buffer objects and a series of ioctl() calls."

Ok so open/read/write/seek/mmap would be great (if the kernel could efficiently handle that many objects), ok fine, use ioctls to emulate this behavior, but shouldn't we be adding in macros so they look like open, read, write, gopen, gread and gwrite? So when the kernel is ready, it's a simple change of a #define gwrite write ?


(Log in to post comments)

GEM v. TTM

Posted Dec 26, 2008 1:57 UTC (Fri) by quotemstr (subscriber, #45331) [Link]

Or, you know, fix whatever file descriptor infrastructure makes the management problematic.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds