On Wed, 2007-11-28 at 15:07 +0100, Thomas Hellström wrote: > Michel Dänzer wrote: > > >On Tue, 2007-11-27 at 15:44 -0500, Kristian Høgsberg wrote: > > > > > >>On Nov 27, 2007 2:30 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > >>... > >> > >> > >>>> I both cases, the kernel will need to > >>>>know how to activate a given context and the context handle should be > >>>>part of the super ioctl arguments. > >>>> > >>>> > >>>We needn't expose the contexts to user-space, just provide a virtual > >>>consistent device and manage contexts in the kernel. We could add the > >>>ability to manage contexts from user space for cases where that makes > >>>sense (like, perhaps, in the X server where a context per client may be > >>>useful). > >>> > >>> > >>Oh, right we don't need one per GLContext, just per DRI client, mesa > >>handles switching between GL contexts. What about multithreaded > >>rendering sharing the same drm fd? > >> > >> > > > >That's not supported, every GLX context has its own DRM context. > > > > > > > > > It needs to be. DRI applications should have a single fd open to drm, > otherwise shared buffer operation will be problematic.
Yeah, I misremembered and thought there was a 1:1 correspondence between DRM contexts and fds. Sorry for the confusion. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
