On Mon, 2008-08-04 at 23:46 +0200, Ingo Oeser wrote:

quoted text
> Ok, how many need support for GEM? How many of them would change their
> event loop, if they can get better performance?

GEM will underlie the OpenGL implementation that applications use; we
aren't planning on writing two OpenGL implementations to work around
some file descriptor issues. And, even if we want to use fds for every
GEM object, we have a fairly simple way of moving them out of the way of
select -- dup2. Of course, it would be nice to have some way to get the
kernel to help allocate an unused fd 'up high', but=20

quoted text
> Really, the sleeping part of of event loops is usually hidden=20
> in some libraries and the applications have a big switch statement=20
> somewhere to dispatch the reasons for wakeup.

That's not historically true in desktop applications. Yes, most modern
open source applications are sensible and use a library-based event
loop, but we can't control what applications people use.

quoted text
> That is never required as long as only performance suffers,=20
> not functionality.

Alas, GEM offers a huge increase in functionality; performance is really
just a modest side benefit.

In reality, as I want to avoid problems caused by ulimit, I suspect I'd
end up treating most of these objects as just a bag of pages and close
the related fd after passing them to the driver, effectively turning the
whole exercise into a mechanism for passing the struct file from shmem
to GEM through user mode instead of directly across the kernel API. I'm
not sure this is a win.

--=20
keith.packard@intel.com