[Bug 13409] Killing compiz crashes Xorg

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13409





--- Comment #3 from [EMAIL PROTECTED]  2007-11-28 00:48 PST ---
(In reply to comment #2)
> Once again, does anyone have a clue why there are no line numbers in my
> stacktraces?

See comment #4 of bug 13391.

Can you still reproduce this bug with current mesa Git master?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

Re: DRI2 and lock-less operation

[Keith Whitwell]

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?
> 
>>> I imagine one optimiation you could do with a fixed number of contexts
>>> is to assume that loosing the context will be very rare, and just fail
>>> the super-ioctl when it happens, and then expect user space to
>>> resubmit with state emission preamble.  In fact it may work well for
>>> single context hardware...
>> I recall having the same discussion in the past; have the superioctl
>> fail so that the client needn't constantly compute the full state
>> restore on every submission may be a performance win for some hardware.
>> All that this requires is a flag to the kernel that says 'this
>> submission reinitializes the hardware', and an error return that says
>> 'lost context'.
> 
> Exactly.
> 
>>> But the super-ioctl is chipset specific and we can decide on the
>>> details there on a chipset to chipset basis.  If you have input to how
>>> the super-ioctl for intel should look like to support lockless
>>> operation for current and future intel chipset, I'd love to hear it.
>>> And of course we can version our way out of trouble as a last resort.
>> We should do the lockless and context stuff at the same time; doing
>> re-submit would be a bunch of work in the driver that would be wasted.
> 
> Is it that bad? We will still need the resubmit code for older
> chipsets that dont have the hardware context support.  The drivers
> already have the code to emit state in case of context loss, that code
> just needs to be repurposed to generate a batch buffer to prepend to
> the rendering code.  And the rendering code doesn't need to change
> when resubmitting.  Will that work?
> 
>> Right now, we're just trying to get 965 running with ttm; once that's
>> limping along, figuring out how to make it reasonable will be the next
>> task, and hardware context support is clearly a big part of that.
> 
> 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 for now and punt on the lock-less super-ioctl
> if that really blocks on hardware context support.  How far back is
> hardware contexts supported?

There are three ways to support lockless operation
- hardware contexts
- a full preamble emit per batchbuffer
- passing a pair of preamble, payload batchbuffers per ioctl

I think all hardware is capable of supporting at least one of these.

That said, if the super-ioctl is per-device, then you can make a choice 
per-device in terms of whether the lock is required or not, which makes 
things easier.  The reality is that most ttm based drivers will do very 
little differently on a regular lock compared to a contended one -- at 
most they could decide whether or not to emit a preamble they computed 
earlier.

Keith




-
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

Re: DRI2 and lock-less operation

[Keith Whitwell]

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 they 
don't care about cliprects and certainly don't have to happen in the 
kernel...

Keith



-
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

Re: DRI2 and lock-less operation

[Michel Dänzer]

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.
> 
> These don't touch the real swapbuffer, just the fake one.  Hence they 
> don't care about cliprects and certainly don't have to happen in the 
> kernel...

I'm not sure about glCopyPixels, but glXCopySubBufferMESA would most
definitely be useless if it didn't copy to the real frontbuffer.


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

Re: DRI2 and lock-less operation

[Keith Whitwell]

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 to happen in the kernel.
>> These don't touch the real swapbuffer, just the fake one.  Hence they 
>> don't care about cliprects and certainly don't have to happen in the 
>> kernel...
> 
> I'm not sure about glCopyPixels, but glXCopySubBufferMESA would most
> definitely be useless if it didn't copy to the real frontbuffer.

Yes, wasn't paying attention...  glxCopySubBufferMESA would do both - 
copy to the fake front buffer and then trigger a damage-induced update 
of the real frontbuffer.  Neither operation requires the 3d driver know 
about cliprects, and the damage operation is basically a generalization 
of the swapbuffer stuff we've been talking about.

Keith


-
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

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

[Keith Whitwell]

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 drawable lock is
>>> gone, we always render to private back buffers and do swap buffers in
>>> the kernel, so I'm "only" concerned with the DRI lock here.  The idea
>>> is that since we have the memory manager and the super-ioctl and the X
>>> server now can push cliprects into the kernel in one atomic operation,
>>> we would be able to get rid of the DRI lock.  My overall question,
>>> here is, is that feasible?
>> How do you plan to ensure that X didn't change the cliprects after you
>> emitted them to the DRM ?
> 
> The idea was that the buffer swap happens in the kernel, triggered by
> an ioctl. The kernel generates the command stream to execute the swap
> against the current set of cliprects.  The back buffers are always
> private so the cliprects only come into play when copying from the
> back buffer to the front buffer.  Single buffered visuals are secretly
> double buffered and implemented the same way.
> 
> I'm trying to figure now whether it makes more sense to keep cliprects
> and swapbuffer out of the kernel, which wouldn't change the above
> much, except the swapbuffer case.  I described the idea for swapbuffer
> in this case in my reply to Thomas: the X server publishes cliprects
> to the clients through a shared ring buffer, and clients parse the
> clip rect changes out of this buffer as they need it.  When posting a
> swap buffer request, the buffer head should be included in the
> super-ioctl so that the kernel can reject stale requests.  When that
> happens, the client must parse the new cliprect info and resubmit an
> updated swap buffer request.

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 to figure out how to get 
some other entity a sufficiently up-to-date set of cliprects to make 
this work (which is what was wrong with DRI 1.0), maybe we should try 
and figure out how to get the X server to efficiently orchestrate 
swapbuffers.

In particular it seems like we have:

1) The X server knows about cliprects.
2) The kernel knows about IRQ reception.
3) The kernel knows how to submit rendering commands to hardware.
4) Userspace is where we want to craft rendering commands.

Given the above, what do we think about swapbuffers:

a) Swapbuffers is a rendering command
b) which depends on cliprect information
c) that needs to be fired as soon as possible after an IRQ receipt.

So:
swapbuffers should be crafted from userspace (a, 4)
... by the X server (b, 1)
... and should be actually fired by the kernel (c, 2, 3)


I propose something like:

0) 3D client submits rendering to the kernel and receives back a fence.

1) 3D client wants to do swapbuffers.  It sends a message to the X 
server asking it "please do me a swapbuffers after this fence has 
completed".

2) X server crafts (somehow) commands implementing swapbuffers for this 
drawable under the current set of cliprects and passes it to the kernel 
along with the fence.

3) The kernel keeps that batchbuffer to the side until
a) the commands associated with the fence have been submitted to 
hardware.
b) the next vblank IRQ arrives.

when both of these are true, the kernel simply submits the prepared 
swapbuffer commands through the lowest latency path to hardware.

But what happens if the cliprects change?  The 100% perfect solution 
looks like:

The X server knows all about cliprect changes, and can use fences or 
other mechanisms to keep track of which swapbuffers are outstanding.  At 
the time of a cliprect change, it must create new swapbuffer commandsets 
for all pending swapbuffers and re-submit those to the kernel.

These new sets of commands must be tied to the progress of the X 
server's own rendering command stream so that the kernel fires the 
appropriate one to land the swapbuffers to the correct destination as 
the X server's own rendering flies by.

In the simplest case, where the kernel puts commands onto the one true 
ring as it receives them, the kernel can simply discard the old 
swapbuffer command.  Indeed this is true also if the kernel has a 
ring-per-context and uses one of those rings to serialize the X server 
rendering and swapbuffers commands.

Note that condition 3a) above is always true in the current i915.o 
one-true-ring/single-fifo approach to hardware serialization.

I think the above can work and seems more straight-forward than many of 
the proposed alternatives.

Keith



-
SF.Net email is spo

Re: Clip Lists

[Stephane Marchesin]

On 28 Nov 2007 06:19:39 +0100, Soeren Sandmann <[EMAIL PROTECTED]> wrote:
>
> "Stephane Marchesin" <[EMAIL PROTECTED]> writes:
>
> > I fail to see how this works with a lockless design. How do you ensure
> the X
> > server doesn't change cliprects between the time it has written those in
> the
> > shared ring buffer and the time the DRI client picks them up and has the
> > command fired and actually executed ? Do you lock out the server during
> that
> > time ?
>
> The scheme I have been advocating is this:
>
> - A new extension is added to the X server, with a
>   PixmapFromBufferObject request.
>
> - Clients render into a private back buffer object, for which they
>   used the new extension to generate a pixmap.
>
> - When a client wishes to copy something to the frontbuffer (for
>   whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses
>   plain old XCopyArea() with the generated pixmap. The X server is
>   then responsible for any clipping necessary.
>
> This scheme puts all clip list management in the X server. No
> cliprects in shared memory or in the kernel would be required. And no
> locking is required since the X server is already processing requests
> in sequence.


Yes, that is the idea I want to do for nvidia hardware.
Although I'm not sure if we can/want to implement it in term of X primitives
or a new X extension.


To synchronize with vblank, a new SYNC counter is introduced that
> records the number of vblanks since some time in the past. The clients
> can then issue SyncAwait requests before any copy they want
> synchronized with vblank. This allows the client to do useful
> processing while it waits, which I don't believe is the case now.


Since we can put a "wait until vblank on crtc #X" command to a fifo on
nvidia hardware, the vblank issue is non-existent for us. We get precise
vblank without CPU intervention.

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

Re: DRI2 and lock-less operation

[Stephane Marchesin]

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 state registers from the kernel
directly and do a manual state swap.
So we still don't need state re-emitting.

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

Re: Clip Lists

[Keith Whitwell]

Stephane Marchesin wrote:
> 
> 
> On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* <[EMAIL PROTECTED] 
> > wrote:
> 
> "Stephane Marchesin" <[EMAIL PROTECTED]
> > writes:
> 
>  > I fail to see how this works with a lockless design. How do you
> ensure the X
>  > server doesn't change cliprects between the time it has written
> those in the
>  > shared ring buffer and the time the DRI client picks them up and
> has the
>  > command fired and actually executed ? Do you lock out the server
> during that
>  > time ?
> 
> The scheme I have been advocating is this:
> 
> - A new extension is added to the X server, with a
>   PixmapFromBufferObject request.
> 
> - Clients render into a private back buffer object, for which they
>   used the new extension to generate a pixmap.
> 
> - When a client wishes to copy something to the frontbuffer (for
>   whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses
>   plain old XCopyArea() with the generated pixmap. The X server is
>   then responsible for any clipping necessary.
> 
> This scheme puts all clip list management in the X server. No
> cliprects in shared memory or in the kernel would be required. And no
> locking is required since the X server is already processing requests
> in sequence. 
> 
> 
> Yes, that is the idea I want to do for nvidia hardware.
> Although I'm not sure if we can/want to implement it in term of X 
> primitives or a new X extension.
>  
> 
> To synchronize with vblank, a new SYNC counter is introduced that
> records the number of vblanks since some time in the past. The clients
> can then issue SyncAwait requests before any copy they want
> synchronized with vblank. This allows the client to do useful
> processing while it waits, which I don't believe is the case now.
> 
> 
> Since we can put a "wait until vblank on crtc #X" command to a fifo on 
> nvidia hardware, the vblank issue is non-existent for us. We get precise 
> vblank without CPU intervention.

You still have some issues...

The choice is: do you put the wait-until-vblank command in the same fifo 
as the X server rendering or not?

If yes -- you end up with nasty latency for X as its rendering is 
blocked by swapbuffers.

If no -- you face the question of what to do when cliprects change.

The only way to make 'no' work is to effectively block the X server from 
changing cliprects while such a command is outstanding -- which leads 
you back to latency issues - probably juddery window moves when 3d is 
active.

I don't think hardware gives you a way out of jail for swapbuffers in 
the presence of changing cliprects.

Keith

-
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

Re: DRI2 and lock-less operation

[Michel Dänzer]

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 that route.  I'm not sure the buffer swap
> from the vblank tasklet is really necessary to begin with... are there
> benchmarks showing that the irq->userspace latency was too big for
> this to work in userspace?

Yes, I implemented this on an i945 system where waiting for vertical
blank and then submitting the buffer swap blit from userspace resulted
in constant tearing.


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

Re: DRI2 and lock-less operation

[Michel Dänzer]

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.


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

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

[Stephane Marchesin]

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 to figure out how to get
> some other entity a sufficiently up-to-date set of cliprects to make
> this work (which is what was wrong with DRI 1.0), maybe we should try
> and figure out how to get the X server to efficiently orchestrate
> swapbuffers.
>
> In particular it seems like we have:
>
> 1) The X server knows about cliprects.
> 2) The kernel knows about IRQ reception.
> 3) The kernel knows how to submit rendering commands to hardware.
> 4) Userspace is where we want to craft rendering commands.
>
> Given the above, what do we think about swapbuffers:
>
> a) Swapbuffers is a rendering command
> b) which depends on cliprect information
> c) that needs to be fired as soon as possible after an IRQ
> receipt.
>
> So:
> swapbuffers should be crafted from userspace (a, 4)
> ... by the X server (b, 1)
> ... and should be actually fired by the kernel (c, 2, 3)


Well, on nvidia hw, you don't even need to fire from the kernel (thanks to a
special fifo command that waits for vsync).
So I'd love it if going through the kernel for swapbuffers was abstracted by
the interface.

I propose something like:
>
> 0) 3D client submits rendering to the kernel and receives back a fence.
>
> 1) 3D client wants to do swapbuffers.  It sends a message to the X
> server asking it "please do me a swapbuffers after this fence has
> completed".
>
> 2) X server crafts (somehow) commands implementing swapbuffers for this
> drawable under the current set of cliprects and passes it to the kernel
> along with the fence.
>
> 3) The kernel keeps that batchbuffer to the side until
> a) the commands associated with the fence have been submitted to
> hardware.
> b) the next vblank IRQ arrives.
>
> when both of these are true, the kernel simply submits the prepared
> swapbuffer commands through the lowest latency path to hardware.
>
> But what happens if the cliprects change?  The 100% perfect solution
> looks like:
>
> The X server knows all about cliprect changes, and can use fences or
> other mechanisms to keep track of which swapbuffers are outstanding.  At
> the time of a cliprect change, it must create new swapbuffer commandsets
> for all pending swapbuffers and re-submit those to the kernel.
>
> These new sets of commands must be tied to the progress of the X
> server's own rendering command stream so that the kernel fires the
> appropriate one to land the swapbuffers to the correct destination as
> the X server's own rendering flies by.


Yes that was the basis for my thinking as well. By inserting the swapbuffers
into the normal flow of X commands, we remove the need for syncing with the
X server at swapbuffer time.


In the simplest case, where the kernel puts commands onto the one true
> ring as it receives them, the kernel can simply discard the old
> swapbuffer command.  Indeed this is true also if the kernel has a
> ring-per-context and uses one of those rings to serialize the X server
> rendering and swapbuffers commands.


Come on, admit that's a hack to get 100'000 fps in glxgears :)


Note that condition 3a) above is always true in the current i915.o
> one-true-ring/single-fifo approach to hardware serialization.


Yes, I think those details of how to wait should be left driver-dependent
and abstracted in user space. So that we have the choice of calling the
kernel, doing it from user space only, relying on a single fifo or whatever.


I think the above can work and seems more straight-forward than many of
> the proposed alternatives.


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
approach. When the DRM does the swaps you can ensure it'll get executed
pretty fast. If X has been stuffing piles of commands into its command
buffer, it might not be so fast. What this means is that 3D might be slowed
down by 2D rendering (think especially of the case of EXA fallbacks which
will sync your fifo). In that case, ensuring a no-fallback EXA would become
relevant in achieving smooth 3D performance. But at least it solves the
issue of sluggish OpenGL window moves and resizes (/me looks at the nvidia
binary driver behaviour).

Stephane
-
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-d

Re: Clip Lists

[Stephane Marchesin]

On 11/28/07, Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
> Stephane Marchesin wrote:
> >
> >
> > On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* <[EMAIL PROTECTED]
> > > wrote:
> >
> > "Stephane Marchesin" <[EMAIL PROTECTED]
> > > writes:
> >
> >  > I fail to see how this works with a lockless design. How do you
> > ensure the X
> >  > server doesn't change cliprects between the time it has written
> > those in the
> >  > shared ring buffer and the time the DRI client picks them up and
> > has the
> >  > command fired and actually executed ? Do you lock out the server
> > during that
> >  > time ?
> >
> > The scheme I have been advocating is this:
> >
> > - A new extension is added to the X server, with a
> >   PixmapFromBufferObject request.
> >
> > - Clients render into a private back buffer object, for which they
> >   used the new extension to generate a pixmap.
> >
> > - When a client wishes to copy something to the frontbuffer (for
> >   whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses
> >   plain old XCopyArea() with the generated pixmap. The X server is
> >   then responsible for any clipping necessary.
> >
> > This scheme puts all clip list management in the X server. No
> > cliprects in shared memory or in the kernel would be required. And
> no
> > locking is required since the X server is already processing
> requests
> > in sequence.
> >
> >
> > Yes, that is the idea I want to do for nvidia hardware.
> > Although I'm not sure if we can/want to implement it in term of X
> > primitives or a new X extension.
> >
> >
> > To synchronize with vblank, a new SYNC counter is introduced that
> > records the number of vblanks since some time in the past. The
> clients
> > can then issue SyncAwait requests before any copy they want
> > synchronized with vblank. This allows the client to do useful
> > processing while it waits, which I don't believe is the case now.
> >
> >
> > Since we can put a "wait until vblank on crtc #X" command to a fifo on
> > nvidia hardware, the vblank issue is non-existent for us. We get precise
> > vblank without CPU intervention.
>
> You still have some issues...
>
> The choice is: do you put the wait-until-vblank command in the same fifo
> as the X server rendering or not?
>
> If yes -- you end up with nasty latency for X as its rendering is
> blocked by swapbuffers.


Yes, I want to go for that simpler approach first and see if the blocking
gets bad (I can't really say until I've tried).

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

Re: Clip Lists

[Keith Whitwell]

Stephane Marchesin wrote:
> 
> 
> On 11/28/07, *Keith Whitwell* <[EMAIL PROTECTED] 
> > wrote:
> 
> Stephane Marchesin wrote:
>  >
>  >
>  > On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann*
> <[EMAIL PROTECTED] 
>  > mailto:[EMAIL PROTECTED]>>> wrote:
>  >
>  > "Stephane Marchesin" <[EMAIL PROTECTED]
> 
>  >  >> writes:
>  >
>  >  > I fail to see how this works with a lockless design. How
> do you
>  > ensure the X
>  >  > server doesn't change cliprects between the time it has
> written
>  > those in the
>  >  > shared ring buffer and the time the DRI client picks them
> up and
>  > has the
>  >  > command fired and actually executed ? Do you lock out the
> server
>  > during that
>  >  > time ?
>  >
>  > The scheme I have been advocating is this:
>  >
>  > - A new extension is added to the X server, with a
>  >   PixmapFromBufferObject request.
>  >
>  > - Clients render into a private back buffer object, for which
> they
>  >   used the new extension to generate a pixmap.
>  >
>  > - When a client wishes to copy something to the frontbuffer (for
>  >   whatever reason - glXSwapBuffers(), glCopyPixels(), etc),
> it uses
>  >   plain old XCopyArea() with the generated pixmap. The X
> server is
>  >   then responsible for any clipping necessary.
>  >
>  > This scheme puts all clip list management in the X server. No
>  > cliprects in shared memory or in the kernel would be
> required. And no
>  > locking is required since the X server is already processing
> requests
>  > in sequence.
>  >
>  >
>  > Yes, that is the idea I want to do for nvidia hardware.
>  > Although I'm not sure if we can/want to implement it in term of X
>  > primitives or a new X extension.
>  >
>  >
>  > To synchronize with vblank, a new SYNC counter is introduced that
>  > records the number of vblanks since some time in the past.
> The clients
>  > can then issue SyncAwait requests before any copy they want
>  > synchronized with vblank. This allows the client to do useful
>  > processing while it waits, which I don't believe is the case
> now.
>  >
>  >
>  > Since we can put a "wait until vblank on crtc #X" command to a
> fifo on
>  > nvidia hardware, the vblank issue is non-existent for us. We get
> precise
>  > vblank without CPU intervention.
> 
> You still have some issues...
> 
> The choice is: do you put the wait-until-vblank command in the same fifo
> as the X server rendering or not?
> 
> If yes -- you end up with nasty latency for X as its rendering is
> blocked by swapbuffers.
> 
> 
> Yes, I want to go for that simpler approach first and see if the 
> blocking gets bad (I can't really say until I've tried).

I'm all for experiments such as this.

Although I have a strong belief how it will turn out, nothing is better 
at changing these sorts of beliefs than actual results.

Keith

-
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

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

[Keith Whitwell]

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 entity is the X server.
> 
> Instead of tying ourselves into knots trying to figure out how to get
> some other entity a sufficiently up-to-date set of cliprects to make
> this work (which is what was wrong with DRI 1.0), maybe we should try
> and figure out how to get the X server to efficiently orchestrate
> swapbuffers.
> 
> In particular it seems like we have:
> 
> 1) The X server knows about cliprects.
> 2) The kernel knows about IRQ reception.
> 3) The kernel knows how to submit rendering commands to hardware.
> 4) Userspace is where we want to craft rendering commands.
> 
> Given the above, what do we think about swapbuffers:
> 
> a) Swapbuffers is a rendering command
> b) which depends on cliprect information
> c) that needs to be fired as soon as possible after an IRQ
> receipt.
> 
> So:
> swapbuffers should be crafted from userspace (a, 4)
> ... by the X server (b, 1)
> ... and should be actually fired by the kernel (c, 2, 3)
> 
> 
> Well, on nvidia hw, you don't even need to fire from the kernel (thanks 
> to a special fifo command that waits for vsync).
> So I'd love it if going through the kernel for swapbuffers was 
> abstracted by the interface.

As I suggested elsewhere, I think that you're probably going to need 
this even on nvidia hardware.

> I propose something like:
> 
> 0) 3D client submits rendering to the kernel and receives back a fence.
> 
> 1) 3D client wants to do swapbuffers.  It sends a message to the X
> server asking it "please do me a swapbuffers after this fence has
> completed".
> 
> 2) X server crafts (somehow) commands implementing swapbuffers for this
> drawable under the current set of cliprects and passes it to the kernel
> along with the fence.
> 
> 3) The kernel keeps that batchbuffer to the side until
> a) the commands associated with the fence have been
> submitted to hardware.
> b) the next vblank IRQ arrives.
> 
> when both of these are true, the kernel simply submits the prepared
> swapbuffer commands through the lowest latency path to hardware.
> 
> But what happens if the cliprects change?  The 100% perfect solution
> looks like:
> 
> The X server knows all about cliprect changes, and can use fences or
> other mechanisms to keep track of which swapbuffers are
> outstanding.  At
> the time of a cliprect change, it must create new swapbuffer commandsets
> for all pending swapbuffers and re-submit those to the kernel.
> 
> These new sets of commands must be tied to the progress of the X
> server's own rendering command stream so that the kernel fires the
> appropriate one to land the swapbuffers to the correct destination as
> the X server's own rendering flies by.
> 
> 
> Yes that was the basis for my thinking as well. By inserting the 
> swapbuffers into the normal flow of X commands, we remove the need for 
> syncing with the X server at swapbuffer time.

The very simplest way would be just to have the X server queue it up 
like normal blits and not even involve the kernel.  I'm not proposing 
this.  I believe such an approach will fail for the sync-to-vblank case 
due to latency issues - even (I suspect) with hardware-wait-for-vblank.

Rather, I'm describing a mechanism that allows a pre-prepared swapbuffer 
command to be injected into the X command stream (one way or another) 
with the guarantee that it will encode the correct cliprects, but which 
will avoid stalling the command queue in the meantime.


> In the simplest case, where the kernel puts commands onto the one true
> ring as it receives them, the kernel can simply discard the old
> swapbuffer command.  Indeed this is true also if the kernel has a
> ring-per-context and uses one of those rings to serialize the X server
> rendering and swapbuffers commands. 
> 
> 
> Come on, admit that's a hack to get 100'000 fps in glxgears :)

I'm not talking about discarding the whole swap operation, just the 
version of the swap command buffer that pertained to the old cliprects. 
  Every swap is still being performed.

You do raise a good point though -- we currently throttle the 3d driver 
based on swapbuffer fences.  There would need to be some equivalent 
mechanism to achieve this.

> 
> Note that condition 3a) above is always true in the current i915.o
> one-true-ring/single-fifo approach to hardware serialization.
> 
> 
> Yes, I think those details of how to wait should be left 
> driver-dependent and abstracted in user space. So that we have the

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

[Jerome Glisse]

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
> approach. When the DRM does the swaps you can ensure it'll get executed
> pretty fast. If X has been stuffing piles of commands into its command
> buffer, it might not be so fast. What this means is that 3D might be slowed
> down by 2D rendering (think especially of the case of EXA fallbacks which
> will sync your fifo). In that case, ensuring a no-fallback EXA would become
> relevant in achieving smooth 3D performance. But at least it solves the
> issue of sluggish OpenGL window moves and resizes (/me looks at the nvidia
> binary driver behaviour).
> 
> Stephane

I likely got problem with my mail as i think my previous mail didn't get
through. Anyway i am all for having X server responsible for swapping
buffer. For solving a part of the above problem we might have two context
(fifo) for X server: one for X drawing, one for X swapping buffer.

The swap context (fifo) is a top priority things and should preempt others
context (fifo). An outcome of this is that we might like a simple gpu
scheduler for such case (and maybe other in the future) but obviously such
scheduler will be highly hw dependent.

Cheers,
Jerome Glisse

-
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

[PATCH] DRM: Standardize format of including linux header files with "<>".

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  outside of UML code, there are very few instances of including linux
header files that don't use the "<>" format, so it would be nice to
make everything completely standard.  and it makes my tree-scanning
scripts simpler, too.  :-)

diff --git a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c
index 3cbebf8..84a40f1 100644
--- a/drivers/char/drm/drm_ioctl.c
+++ b/drivers/char/drm/drm_ioctl.c
@@ -36,7 +36,7 @@
 #include "drmP.h"
 #include "drm_core.h"

-#include "linux/pci.h"
+#include 

 /**
  * Get the bus id.

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca


-
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

Re: DRI2 and lock-less operation

[Thomas Hellström]

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.

/Thomas






-
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

[Bug 13425] New: on intel 945GM, xorg hard-locks when having glxgears and a custom-glx-application running

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13425

   Summary: on intel 945GM, xorg hard-locks when having glxgears and
a custom-glx-application running
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM modules
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]


When having open glxgears and using another glx-application, xorg crashes hard
after a little while (amount differs and probability rises with actual
movements in other open glx-application), after which the system is hung (no
ssh, no power-off but by holding powerbutton down LONG).

This effect does not occur when the kernels drm-modules are used, but they are
unable to activate DRI with "everything-git".

conditions:
xorg-git from 2007-11-28 (drm, Mesa ,xserver, libs, drivers)
linux kernel 2.6.22.14

intel 945GM on latitude D820


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

Re: DRI2 and lock-less operation

[Kristian Høgsberg]

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 help me to see what i need to do for dri2 in ddx.

I didn't push that yet, but I've attached the patch as it looks right
now.  It's still very much work-in-progress.

Kristian
commit 3a16f83c278902ff673bc21272a3b95eb6237dab
Author: Kristian Høgsberg <[EMAIL PROTECTED]>
Date:   Mon Nov 19 17:31:02 2007 -0500

dri2 wip

diff --git a/src/i830.h b/src/i830.h
index 57f0544..ba20df8 100644
--- a/src/i830.h
+++ b/src/i830.h
@@ -295,6 +295,12 @@ enum last_3d {
 LAST_3D_ROTATION
 };
 
+enum dri_type {
+DRI_TYPE_NONE,
+DRI_TYPE_XF86DRI,
+DRI_TYPE_DRI2
+};
+
 typedef struct _I830Rec {
unsigned char *MMIOBase;
unsigned char *GTTBase;
@@ -456,7 +462,7 @@ typedef struct _I830Rec {
CARD32 samplerstate[6];
 
Bool directRenderingDisabled;	/* DRI disabled in PreInit. */
-   Bool directRenderingEnabled;		/* DRI enabled this generation. */
+   enum dri_type directRendering;	/* Type of DRI enabled this generation. */
 
 #ifdef XF86DRI
Bool directRenderingOpen;
diff --git a/src/i830_accel.c b/src/i830_accel.c
index 4d9ea79..e38897e 100644
--- a/src/i830_accel.c
+++ b/src/i830_accel.c
@@ -136,7 +136,7 @@ I830WaitLpRing(ScrnInfoPtr pScrn, int n, int timeout_millis)
 	 i830_dump_error_state(pScrn);
 	 ErrorF("space: %d wanted %d\n", ring->space, n);
 #ifdef XF86DRI
-	 if (pI830->directRenderingEnabled) {
+	 if (pI830->directRendering == DRI_TYPE_XF86DRI) {
 	DRIUnlock(screenInfo.screens[pScrn->scrnIndex]);
 	DRICloseScreen(screenInfo.screens[pScrn->scrnIndex]);
 	 }
@@ -176,7 +176,7 @@ I830Sync(ScrnInfoPtr pScrn)
 #ifdef XF86DRI
/* VT switching tries to do this.
 */
-   if (!pI830->LockHeld && pI830->directRenderingEnabled) {
+   if (!pI830->LockHeld && pI830->directRendering != DRI_TYPE_NONE) {
   return;
}
 #endif
diff --git a/src/i830_display.c b/src/i830_display.c
index d988b86..8b07c51 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -408,7 +408,7 @@ i830PipeSetBase(xf86CrtcPtr crtc, int x, int y)
 }
 
 #ifdef XF86DRI
-if (pI830->directRenderingEnabled) {
+if (pI830->directRendering == DRI_TYPE_XF86DRI) {
 	drmI830Sarea *sPriv = (drmI830Sarea *) DRIGetSAREAPrivate(pScrn->pScreen);
 
 	if (!sPriv)
@@ -755,7 +755,7 @@ i830_crtc_dpms(xf86CrtcPtr crtc, int mode)
 intel_crtc->dpms_mode = mode;
 
 #ifdef XF86DRI
-if (pI830->directRenderingEnabled) {
+if (pI830->directRendering == DRI_TYPE_XF86DRI) {
 	drmI830Sarea *sPriv = (drmI830Sarea *) DRIGetSAREAPrivate(pScrn->pScreen);
 	Bool enabled = crtc->enabled && mode != DPMSModeOff;
 
diff --git a/src/i830_dri.c b/src/i830_dri.c
index 4d3458f..511b183 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -1236,6 +1236,10 @@ I830DRIInitBuffers(WindowPtr pWin, RegionPtr prgn, CARD32 index)
i830MarkSync(pScrn);
 }
 
+/* FIXME: fix this for real */
+#define ALLOCATE_LOCAL(size) xalloc(size)
+#define DEALLOCATE_LOCAL(ptr) xfree(ptr)
+
 /* This routine is a modified form of XAADoBitBlt with the calls to
  * ScreenToScreenBitBlt built in. My routine has the prgnSrc as source
  * instead of destination. My origin is upside down so the ydir cases
@@ -1748,7 +1752,7 @@ I830DRISetVBlankInterrupt (ScrnInfoPtr pScrn, Bool on)
 if (!pI830->want_vblank_interrupts)
 	on = FALSE;
 
-if (pI830->directRenderingEnabled && pI830->drmMinor >= 5) {
+if (pI830->directRendering == DRI_TYPE_XF86DRI && pI830->drmMinor >= 5) {
 	if (on) {
 	if (xf86_config->num_crtc > 1 && xf86_config->crtc[1]->enabled)
 		if (pI830->drmMinor >= 6)
@@ -1775,7 +1779,7 @@ I830DRILock(ScrnInfoPtr pScrn)
 {
I830Ptr pI830 = I830PTR(pScrn);
 
-   if (pI830->directRenderingEnabled && !pI830->LockHeld) {
+   if (pI830->directRendering == DRI_TYPE_XF86DRI && !pI830->LockHeld) {
   DRILock(screenInfo.screens[pScrn->scrnIndex], 0);
   pI830->LockHeld = 1;
   I830RefreshRing(pScrn);
@@ -1792,7 +1796,7 @@ I830DRIUnlock(ScrnInfoPtr pScrn)
 {
I830Ptr pI830 = I830PTR(pScrn);
 
-   if (pI830->directRenderingEnabled && pI830->LockHeld) {
+   if (pI830->directRendering == DRI_TYPE_XF86DRI && pI830->LockHeld) {
   DRIUnlock(screenInfo.screens[pScrn->scrnIndex]);
   pI830->LockHeld = 0;
}
diff --git a/src/i830_driver.c b/src/i830_driver.c
index eacaefc..08a5904 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -208,6 +208,10 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 #endif
 #endif
 
+#ifdef DRI2
+#include "dri2.h"
+#endif
+
 #ifdef I830_USE_EXA
 const char *I830exaSymbols[] = {
 "exaGetVersion",
@@ -1467,7 +1471,7 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
pI830->directRenderingDisabled =
 	!xf86ReturnOptValBool(pI830->Options, OPTION_DRI, TRUE);
 
-#ifdef XF86DRI
+#if defined(XF86DRI) || 

[Bug 13091] glean abort with "Segmentation fault" in GarbageCollectDRIDrawables

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13091





--- Comment #6 from [EMAIL PROTECTED]  2007-11-28 07:56 PST ---
Thanks for fixing this.  Brian, you're right this in only on mesa master, not
the 7.0 branch.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13427] New: Fix bsd build with drm_ati_pcigart_info

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13427

   Summary: Fix bsd build with drm_ati_pcigart_info
   Product: DRI
   Version: DRI CVS
  Platform: Other
OS/Version: FreeBSD
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM modules
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]


BSD build was broken when struct ati_pcigart_info was renamed.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13427] Fix bsd build with drm_ati_pcigart_info

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13427





--- Comment #1 from [EMAIL PROTECTED]  2007-11-28 08:27 PST ---
Created an attachment (id=12782)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=12782&action=view)
Patch to fix drm_ati_pcigart_info


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13409] Killing compiz crashes Xorg

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13409





--- Comment #4 from [EMAIL PROTECTED]  2007-11-28 09:07 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > Once again, does anyone have a clue why there are no line numbers in my
> > stacktraces?
> 
> See comment #4 of bug 13391.
> 
> Can you still reproduce this bug with current mesa Git master?
> 

Sorry about the repeated question. Didn't see your response. Any

Anyways, yes, I can still reproduce the problem. There is no change in
behavior. Thanks for your work!


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

Re: DRI2 and lock-less operation

[Michel Dänzer]

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

Re: DRI2 and lock-less operation

[Kristian Høgsberg]

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 you run out of hardware contexts.
>
> Well, in that case we (plan to) bang the state registers from the kernel
> directly and do a manual state swap.
> So we still don't need state re-emitting.

Well, banging the state registers from the kernel sounds like state
emission to me - you mean userspace state emission wont be needed?.
How does the kernel know how to restore the state? Can you swap a
previously set hardware state out to vram/hostmem?  I guess you can
always just read out the registers you need...

Kristian

-
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

Re: Clip Lists

[Soeren Sandmann]

Keith Packard <[EMAIL PROTECTED]> writes:

> On Wed, 2007-11-28 at 06:19 +0100, Soeren Sandmann wrote:
> 
> > - When a client wishes to copy something to the frontbuffer (for
> >   whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses
> >   plain old XCopyArea() with the generated pixmap. The X server is
> >   then responsible for any clipping necessary.
> 
> Using a plain old XCopyArea will make scheduling this in the kernel
> quite a bit harder; if the kernel knows it's doing a swap buffer, then
> it can interrupt ongoing rendering and do the copy at higher priority,
> precisely when the vblank interrupt lands. 

Waiting for vblank is only really interesting for full-screen,
non-clipped clients. In the non-fullscreen case, XCopyArea() type
blitting will actually look better than out-of-band blitting beit
avoids the strange effect where the contents of a window seems to lag
behind the frame when you drag it around. And the clipped case is
slowly going away as compositing becomes the norm.

So in the interesting case the X server would see a fullscreen
CopyArea that was preceded by some sort of wait-for-vblank request
(using SYNC or some other mechanism). The X server then calls a

copy_contents (buf_obj src, 
   buf_obj dest,
   bool wait_blank);

interface in the kernel which will schedule the blit at next vblank
and send a notification back to the server when the blit has finished
and the source buffer can be reused.

Page flipping could be done similarly. A new request

SwapArea (Drawable src, Drawable dest, 
  int src_x, int src_y,
  int width, int height,
  int dest_x, int dest_y)

would be added to the server, and a corresponding

swap_contents (buf_obj obj1, 
   buf_obj obj2,
   bool wait_blank);

to the kernel for the full-screen case. The kernel interface would use
pointer swizzling and page-flips if possible.

If clip rectangles appear while these commands are outstanding, the X
server would just wait for them to complete. Going from "no clip" to
"clip" will be much, much less common than going from "clip" to
"different clip".

So basically, using XCopyArea() doesn't rule out having the
implementation in the kernel.

> Plus, you've just added the latency of a pair of context switches to
> the frame update interval.

I don't think it is realistic to completely avoid switching to the
server in the course of a frame update for these reasons:

- If the client is a compositing manager, then it wouldn't be drawing
  at all unless it was getting damage events from the server

- Clients often get input events at a frequency on the order of 100Hz.

- GL pixel copying routines such as glXSwapBuffer() need to generate
  damage events. With XCopyArea() we get them almost for free.



Soren

-
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

[Bug 13427] Fix bsd build with drm_ati_pcigart_info

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13427


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 10002] problem 915gm with texturized video

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=10002


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13091] glean abort with "Segmentation fault" in GarbageCollectDRIDrawables

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13091


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED




--- Comment #7 from [EMAIL PROTECTED]  2007-11-28 17:17 PST ---
commit 16099c15f5495f22252c6bed655f7f598ebf8001


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13438] New: request commit access

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13438

   Summary: request commit access
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: FreeBSD
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM modules
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]


request commit access


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13438] request commit access

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13438





--- Comment #1 from [EMAIL PROTECTED]  2007-11-28 21:12 PST ---
Created an attachment (id=12818)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=12818&action=view)
ssh key


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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

[Bug 13438] request commit access

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=13438





--- Comment #2 from [EMAIL PROTECTED]  2007-11-28 21:13 PST ---
Created an attachment (id=12819)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=12819&action=view)
gpg key


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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