Re: DRI2 and lock-less operation

On Nov 28, 2007 6:15 AM, Stephane Marchesin <[EMAIL PROTECTED]> wrote: > On 11/28/07, Keith Packard <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-11-28 at 00:52 +0100, Stephane Marchesin wrote: > > > > > The third case obviously will never require any kind of state > > > re-emitting. > > > > Unless y

Re: DRI2 and lock-less operation

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 >

Re: DRI2 and lock-less operation

On Nov 26, 2007 6:51 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: ... > > Sounds like this will all work out after all :) > > Kristian > > Yes, between i started looking at your dri2 branch and didn't find dri2 > branch in your intel ddx repository did you pushed the code anywhere else ? > Would he

Re: DRI2 and lock-less operation

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

Re: Swapbuffers [was: Re: DRI2 and lock-less operation]

On Wed, Nov 28, 2007 at 12:43:18PM +0100, Stephane Marchesin wrote: > > This is what I want to do too. Especially since in the nvidia case we don't > have the issue of routing vblank interrupts to user space for that. > > So, the only issue I'm worried about is the latency induced by this > appro

Re: Swapbuffers [was: Re: DRI2 and lock-less operation]

Stephane Marchesin wrote: > On 11/28/07, *Keith Whitwell* <[EMAIL PROTECTED] > > wrote: > > > In my ideal world, the entity which knows and cares about cliprects > should be the one that does the swapbuffers, or at least is in control > of the process. That

Re: Swapbuffers [was: Re: DRI2 and lock-less operation]

On 11/28/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > > In my ideal world, the entity which knows and cares about cliprects > should be the one that does the swapbuffers, or at least is in control > of the process. That entity is the X server. > > Instead of tying ourselves into knots trying

Re: DRI2 and lock-less operation

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. >

Re: DRI2 and lock-less operation

On Tue, 2007-11-27 at 16:50 -0500, Kristian Høgsberg wrote: > > [...] I'm starting to doubt the "cliprects and swapbuffer > in the kernel" design anyhow. I wasn't going this route originally, > but since we already had that in place for i915 vblank buffer swaps, I > figured we might as well go t

Re: DRI2 and lock-less operation

On 11/28/07, Keith Packard <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-11-28 at 00:52 +0100, Stephane Marchesin wrote: > > > > The third case obviously will never require any kind of state > > re-emitting. > > Unless you run out of hardware contexts. Well, in that case we (plan to) bang the sta

Swapbuffers [was: Re: DRI2 and lock-less operation]

Kristian Høgsberg wrote: > On Nov 27, 2007 11:48 AM, Stephane Marchesin > <[EMAIL PROTECTED]> wrote: >> On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > ... >>> It's all delightfully simple, but I'm starting to reconsider whether >>> the "lockless" bullet point is realistic. Note, the

Re: DRI2 and lock-less operation

Michel Dänzer wrote: > On Wed, 2007-11-28 at 09:30 +, Keith Whitwell wrote: >> Kristian Høgsberg wrote: >> >>> Another problem is that it's not just swapbuffer - anything that >>> touches the front buffer have to respect the cliprects - glCopyPixels >>> and glXCopySubBufferMESA - and thus have

Re: DRI2 and lock-less operation

On Wed, 2007-11-28 at 09:30 +, Keith Whitwell wrote: > Kristian Høgsberg wrote: > > > Another problem is that it's not just swapbuffer - anything that > > touches the front buffer have to respect the cliprects - glCopyPixels > > and glXCopySubBufferMESA - and thus have to happen in the kernel

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > Another problem is that it's not just swapbuffer - anything that > touches the front buffer have to respect the cliprects - glCopyPixels > and glXCopySubBufferMESA - and thus have to happen in the kernel. These don't touch the real swapbuffer, just the fake one. Hence

Re: DRI2 and lock-less operation

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-s

Re: DRI2 and lock-less operation

On Wed, Nov 28, 2007 at 12:43:41AM +0100, Stephane Marchesin wrote: > On 11/27/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > > > On Nov 27, 2007 11:48 AM, Stephane Marchesin > > <[EMAIL PROTECTED]> wrote: > > > On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > ... > > > > It's al

Re: DRI2 and lock-less operation

On Tue, Nov 27, 2007 at 03:44:48PM -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 argume

Re: DRI2 and lock-less operation

On Wed, 2007-11-28 at 00:52 +0100, Stephane Marchesin wrote: > The third case obviously will never require any kind of state > re-emitting. Unless you run out of hardware contexts. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -

Re: DRI2 and lock-less operation

On Tue, 2007-11-27 at 15:44 -0500, Kristian Høgsberg wrote: > 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? For that, you'd either want 'switch context' ioctls, or conte

Re: DRI2 and lock-less operation

On 11/27/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > > Yeah - I'm trying to limit the scope of DRI2 so that we can have > redirected direct rendering and GLX1.4 in the tree sooner rather than > later (before the end of the year). Maybe the best way to do that is > to keep the lock around

Re: DRI2 and lock-less operation

On 11/27/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > On Nov 27, 2007 11:48 AM, Stephane Marchesin > <[EMAIL PROTECTED]> wrote: > > On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > ... > > > It's all delightfully simple, but I'm starting to reconsider whether > > > the "lockless"

Re: DRI2 and lock-less operation

Packard <[EMAIL PROTECTED]> Cc: Jerome Glisse <[EMAIL PROTECTED]>; Dave Airlie <[EMAIL PROTECTED]>; dri-devel@lists.sourceforge.net; Keith Whitwell <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2007 8:44:48 PM Subject: Re: DRI2 and lock-less operation On Nov 27, 2007 2:30 PM,

Re: DRI2 and lock-less operation

On Nov 27, 2007 11:48 AM, Stephane Marchesin <[EMAIL PROTECTED]> wrote: > On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: ... > > It's all delightfully simple, but I'm starting to reconsider whether > > the "lockless" bullet point is realistic. Note, the drawable lock is > > gone, we al

Re: DRI2 and lock-less operation

On Nov 27, 2007 10:41 AM, Thomas Hellström <[EMAIL PROTECTED]> wrote: ... > >>However, there are cases where it is very difficult to use cliprects > >>from the drm, though I wouldn't say impossible. > > > >The idea is to keep the cliprects in the kernel and only render double > >buffered. The onl

Re: DRI2 and lock-less operation

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

Re: DRI2 and lock-less operation

On Tue, 2007-11-27 at 14:03 -0500, Kristian Høgsberg wrote: > As for hardware contexts, I guess there are two cases; hardware that > has a fixed set of contexts builtin and hardware where a context is > just a piece of video memory that you can point to (effectively an > unlimited number of conte

Re: DRI2 and lock-less operation

On Nov 26, 2007 11:15 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: > > > > -full state > > I assume you'll deal with hardware which supports multiple contexts and > avoid the need to include full state with each buffer? As for hardwar

Re: DRI2 and lock-less operation

On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > Hi all, > > I've been working on the DRI2 implementation recently and I'm starting > to get a little confused, so I figured I'd throw a couple of questions > out to the list. First of, I wrote up this summary shortly after XD > > ht

Re: DRI2 and lock-less operation

On 11/27/07, Keith Packard <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: > > > > -full state > > I assume you'll deal with hardware which supports multiple contexts and > avoid the need to include full state with each buffer? That's what we do alread

Re: DRI2 and lock-less operation

On 11/27/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: > > Kristian Høgsberg wrote: > > >On Nov 22, 2007 4:03 AM, Thomas Hellström <[EMAIL PROTECTED]> > wrote: > >... > > > > > >>There are probably various ways to do this, which is another argument > >>for keeping super-ioctls device-specific. >

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: >On Nov 22, 2007 4:03 AM, Thomas Hellström <[EMAIL PROTECTED]> wrote: >... > > >>There are probably various ways to do this, which is another argument >>for keeping super-ioctls device-specific. >>For i915-type hardware, Dave's approach above is probably the most >>attra

Re: DRI2 and lock-less operation

On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: > > -full state I assume you'll deal with hardware which supports multiple contexts and avoid the need to include full state with each buffer? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > On Nov 26, 2007 3:40 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: >> Kristian Høgsberg wrote: >>> On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote: >>> ... I will go this way too for r300/r400/r500 there is not so much registers change with diffe

Re: DRI2 and lock-less operation

On Nov 26, 2007 3:40 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > Kristian Høgsberg wrote: > > On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > > ... > >> I will go this way too for r300/r400/r500 there is not so much registers > >> change with different contexts and registers

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > ... >> I will go this way too for r300/r400/r500 there is not so much registers >> change with different contexts and registers which need special treatment >> will be handled by the drm (this boils down

Re: DRI2 and lock-less operation

On Nov 22, 2007 4:03 AM, Thomas Hellström <[EMAIL PROTECTED]> wrote: ... > There are probably various ways to do this, which is another argument > for keeping super-ioctls device-specific. > For i915-type hardware, Dave's approach above is probably the most > attracting one. > For Poulsbo, all stat

Re: DRI2 and lock-less operation

On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote: ... > I will go this way too for r300/r400/r500 there is not so much registers > change with different contexts and registers which need special treatment > will be handled by the drm (this boils down to where 3d get rendered and > w

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > On Nov 22, 2007 4:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote: > ... >>> My guess for one way is to store a buffer object with the current state >>> emission in it, and submit it with the superioctl maybe, and if we have >>> lost context emit it before the batchbuffer

Re: DRI2 and lock-less operation

On Nov 22, 2007 4:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote: ... > > My guess for one way is to store a buffer object with the current state > > emission in it, and submit it with the superioctl maybe, and if we have > > lost context emit it before the batchbuffer.. > > The way drivers actual

Re: DRI2 and lock-less operation

Keith Whitwell wrote: > Dave Airlie wrote: >>> I'm trying to figure out how context switches acutally work... the DRI >>> lock is overloaded as context switcher, and there is code in the >>> kernel to call out to a chipset specific context switch routine when >>> the DRI lock is taken... but only f

Re: DRI2 and lock-less operation

Dave Airlie wrote: >> I'm trying to figure out how context switches acutally work... the DRI >> lock is overloaded as context switcher, and there is code in the >> kernel to call out to a chipset specific context switch routine when >> the DRI lock is taken... but only ffb uses it... So I'm guessin

Re: DRI2 and lock-less operation

Dave Airlie wrote: >> I'm trying to figure out how context switches acutally work... the DRI >> lock is overloaded as context switcher, and there is code in the >> kernel to call out to a chipset specific context switch routine when >> the DRI lock is taken... but only ffb uses it... So I'm guessin

Re: DRI2 and lock-less operation

> > I'm trying to figure out how context switches acutally work... the DRI > lock is overloaded as context switcher, and there is code in the > kernel to call out to a chipset specific context switch routine when > the DRI lock is taken... but only ffb uses it... So I'm guessing the > way context