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
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
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.
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
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
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
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
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
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
Stephane Marchesin wrote:
On 11/28/07, *Keith Whitwell* [EMAIL PROTECTED]
mailto:[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
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.
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
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
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
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
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
attracting one.
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.
For i915-type
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 already for
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
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 hardware
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
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
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 only code that
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
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, Keith Packard [EMAIL PROTECTED] wrote:
...
I
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 bullet point is
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 for now
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 context
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
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 arguments.
We
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 all delightfully
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 actually work
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..
The way
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
where
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 state is
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 to where
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 which need
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 different contexts and
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
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
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 guessing the
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 guessing the
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 ffb uses
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
http://wiki.x.org/wiki/DRI2
which upon re-reading is still pretty much
44 matches
Mail list logo
