Dave Airlie wrote:
Since Poulsbo is CMA, to avoid the SMP ipi issue, it should be possible
to enclose the whole reloc fixup within a spinlock and use
kmap_atomic which should be faster than kmap.
Since within a spinlock, also preemption is disabled we can guarantee
that a batchbuffer write
Hi,
I have this branch with DRI interface changes that I've been
threatening to merge on several occasions:
http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2
I've just rebased to todays mesa and it's ready to merge. Ian
reviewed the changes a while back gave his ok, and from what we
http://bugs.freedesktop.org/show_bug.cgi?id=8292
--- Comment #9 from [EMAIL PROTECTED] 2007-10-11 13:19 PST ---
how do I use Mesa master? I am on a FC6 box, and am reletivly new to the linux
experience.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
Brian Paul wrote:
Kristian Høgsberg wrote:
Hi,
I have this branch with DRI interface changes that I've been
threatening to merge on several occasions:
http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2
I've just rebased to todays mesa and it's ready to merge. Ian
reviewed the changes a
On 10/11/07, Brian Paul [EMAIL PROTECTED] wrote:
Kristian Høgsberg wrote:
Hi,
I have this branch with DRI interface changes that I've been
threatening to merge on several occasions:
http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2
I've just rebased to todays mesa and it's ready
On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote:
| Suppose 2 clients render to the same backbuffer...
The (rare) cases in which I've seen this used, the clients are aware of
one another, and restrict their rendering to non-overlapping portions of
the drawable. A master client is
Keith Whitwell wrote:
Brian Paul wrote:
Kristian Høgsberg wrote:
Hi,
I have this branch with DRI interface changes that I've been
threatening to merge on several occasions:
http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2
I've just rebased to todays mesa and it's ready to merge. Ian
On 10/11/07, Keith Whitwell [EMAIL PROTECTED] wrote:
Brian Paul wrote:
...
If two GLX clients render to the same double-buffered GLX window, each
is going to have a different/private back color buffer, right? That
doesn't really obey the GLX spec. The renderbuffers which compose a GLX
Allen Akin wrote:
On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote:
| Suppose 2 clients render to the same backbuffer...
The (rare) cases in which I've seen this used, the clients are aware of
one another, and restrict their rendering to non-overlapping portions of
the
Kristian Høgsberg wrote:
On 10/11/07, Keith Whitwell [EMAIL PROTECTED] wrote:
Brian Paul wrote:
...
If two GLX clients render to the same double-buffered GLX window, each
is going to have a different/private back color buffer, right? That
doesn't really obey the GLX spec. The renderbuffers
On Fri, Oct 12, 2007 at 12:08:09AM +0100, Keith Whitwell wrote:
| Just to clarify, would things look a bit like this:
|
| Master:
| clear,
| glFlush,
| signal slaves somehow
|
| Slave0..n:
| wait for signal,
| don't clear, just draw triangles
| glFlush
|
I've checked in a new GLX test for rendering into one GLX window by two
processes. See comments in progs/xdemos/corender.c for instructions.
Two interlocking tori are drawn. The first process draws a red one, the
second process draws a blue one.
I'm getting mixed results.
With an old
On Thu, 2007-10-11 at 23:39 +0100, Keith Whitwell wrote:
Maybe we're examining the wrong spec here. My concerns are all about
what happens when the window changes size -- what does X tell us about
the contents of a window under those circumstances? Does the GLX spec
actually specify
On Fri, 2007-10-12 at 00:19 +0100, Keith Whitwell wrote:
Basically any API-generated event that implies a flush. Internally
generated events, like running out of some resource and having to fire
buffers to recover generally don't count.
If I understand this, then the only time you'll
14 matches
Mail list logo
