Re: [Mesa-dev] r600g on rv635 and broken mipmaps
2011/5/5 Mathias Fröhlich mathias.froehl...@gmx.net: Hi all, On Thursday, May 05, 2011 04:32:03 you wrote: Okay my guess at the problem is that: the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely on the base in the CB being the same as the texture BASE which it won't be in the case where we are rendering to mip sublevels. Though I've no idea how to workaround this without explicit flushes. Hmm, may be. I also thought that the surface sync packet has some special case optimzations for some of the probably often used flags that lead to that kind of behaviour. May be that 'flush all' in case of a new framebuffer target for these kind of chips is again a good idea instead of the finegrained flush dest caches. May be Alex finds some undocumented ideas somewhere in his bag :). Apparently the CB/DB surface sync stuff has a number of issues on r6xx, so we should just use event_write flushes for CB/DB. A single event write flush takes care of all dst caches. Something like this untested patch perhaps: http://people.freedesktop.org/~agd5f/r600g_event_flush.diff Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA - GL_RGB
On Mit, 2011-05-04 at 11:22 -0700, Tristan Schmelcher wrote: Interestingly I have just found out that this issue only happens after the machine has done a suspend/resume. On a fresh boot prior to the suspend/resume the performance is good. So I guess somehow the driver is forgetting that it can take a faster path that doesn't go through _mesa_texstore. Which means that it could easily be fixed in a later version. But now that I have worked around the problem I probably won't have time to delve any further. The Mesa driver is blissfully oblivious of suspend/resume. It sounds like you may be hitting something like the recent Linux kernel bug where it didn't properly restore PAT attributes on all CPUs on resume. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
2011/5/5 Alex Deucher alexdeuc...@gmail.com:
2011/5/5 Mathias Fröhlich mathias.froehl...@gmx.net:
Hi all,
On Thursday, May 05, 2011 04:32:03 you wrote:
Okay my guess at the problem is that:
the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
on the base in the CB being the same as the texture BASE which it won't
be in the case where we are rendering to mip sublevels. Though I've no idea
how to workaround this without explicit flushes.
Hmm, may be.
I also thought that the surface sync packet has some special case
optimzations
for some of the probably often used flags that lead to that kind of
behaviour.
May be that 'flush all' in case of a new framebuffer target for these kind of
chips is again a good idea instead of the finegrained flush dest caches.
May be Alex finds some undocumented ideas somewhere in his bag :).
Apparently the CB/DB surface sync stuff has a number of issues on
r6xx, so we should just use event_write flushes for CB/DB. A single
event write flush takes care of all dst caches. Something like this
untested patch perhaps:
http://people.freedesktop.org/~agd5f/r600g_event_flush.diff
The attached patch seems to work for me.
Alex
From 0d4362817adf4d119acf4d370b14be97de2af5a3 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 5 May 2011 03:17:16 -0400
Subject: [PATCH] r600g: fix cache flushes on r6xx
r6xx asics have some problems with the surface
sync logic for the CB and DB. It's recommended
to use the event write interface for flushing
the DB/CB caches rather than the sync packets.
A single event write flush flushes all dst
caches, so we only need one for all CBs and DB.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=35312
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
src/gallium/drivers/r600/r600.h |1 +
src/gallium/winsys/r600/drm/r600_hw_context.c | 36 ++--
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 0b0df9d..33aa450 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -235,6 +235,7 @@ struct r600_query {
#define R600_CONTEXT_DRAW_PENDING (1 0)
#define R600_CONTEXT_DST_CACHES_DIRTY (1 1)
+#define R600_CONTEXT_CHECK_EVENT_FLUSH (1 2)
struct r600_context {
struct radeon *radeon;
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c b/src/gallium/winsys/r600/drm/r600_hw_context.c
index 150485d..b8a8108 100644
--- a/src/gallium/winsys/r600/drm/r600_hw_context.c
+++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
@@ -797,19 +797,33 @@ void r600_context_bo_flush(struct r600_context *ctx, unsigned flush_flags,
unsigned flush_mask, struct r600_bo *rbo)
{
struct radeon_bo *bo;
+ boolean use_event_flush = FALSE;
+
bo = rbo-bo;
/* if bo has already been flushed */
if (!(~bo-last_flush flush_flags)) {
bo-last_flush = flush_mask;
return;
}
- ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_SURFACE_SYNC, 3, ctx-predicate_drawing);
- ctx-pm4[ctx-pm4_cdwords++] = flush_flags;
- ctx-pm4[ctx-pm4_cdwords++] = (bo-size + 255) 8;
- ctx-pm4[ctx-pm4_cdwords++] = 0x;
- ctx-pm4[ctx-pm4_cdwords++] = 0x000A;
- ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, ctx-predicate_drawing);
- ctx-pm4[ctx-pm4_cdwords++] = bo-reloc_id;
+
+ if ((ctx-radeon-family CHIP_RV770)
+ (G_0085F0_CB_ACTION_ENA(flush_flags) ||
+ G_0085F0_DB_ACTION_ENA(flush_flags)))
+ use_event_flush = TRUE;
+
+ if (use_event_flush (ctx-flags R600_CONTEXT_CHECK_EVENT_FLUSH)) {
+ ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_EVENT_WRITE, 0, ctx-predicate_drawing);
+ ctx-pm4[ctx-pm4_cdwords++] = EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT) | EVENT_INDEX(0);
+ ctx-flags = ~R600_CONTEXT_CHECK_EVENT_FLUSH;
+ } else {
+ ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_SURFACE_SYNC, 3, ctx-predicate_drawing);
+ ctx-pm4[ctx-pm4_cdwords++] = flush_flags;
+ ctx-pm4[ctx-pm4_cdwords++] = (bo-size + 255) 8;
+ ctx-pm4[ctx-pm4_cdwords++] = 0x;
+ ctx-pm4[ctx-pm4_cdwords++] = 0x000A;
+ ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, ctx-predicate_drawing);
+ ctx-pm4[ctx-pm4_cdwords++] = bo-reloc_id;
+ }
bo-last_flush = (bo-last_flush | flush_flags) flush_mask;
}
@@ -1119,6 +1133,7 @@ void r600_context_block_emit_dirty(struct r600_context *ctx, struct r600_block *
goto out;
}
+ ctx-flags |= R600_CONTEXT_CHECK_EVENT_FLUSH;
for (int j = 0; j block-nreg; j++) {
if (block-pm4_bo_index[j]) {
/* find relocation */
@@ -1132,6 +1147,7 @@ void r600_context_block_emit_dirty(struct r600_context *ctx, struct r600_block *
block-reloc[id].bo);
}
}
+ ctx-flags = ~R600_CONTEXT_CHECK_EVENT_FLUSH;
memcpy(ctx-pm4[ctx-pm4_cdwords], block-pm4, block-pm4_ndwords * 4);
ctx-pm4_cdwords += block-pm4_ndwords;
@@ -1155,6 +1171,7 @@ void r600_context_flush_dest_caches(struct r600_context *ctx)
{
struct r600_bo *cb[8];
struct
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
Andy Furniss wrote:
There has been a regression though -
[g3dvl] remove resource_format workaround
causes quite bad artifacts on newmobcal.
I can get rid of the new artifacts for xvmc with the patch below.
ffmpeg12vdpau shows the same new artifacts, but is not fixed by this.
diff --git a/src/gallium/auxiliary/vl/vl_context.c
b/src/gallium/auxiliary/vl/vl_context.c
index be28bb5..34381f9 100644
--- a/src/gallium/auxiliary/vl/vl_context.c
+++ b/src/gallium/auxiliary/vl/vl_context.c
@@ -36,9 +36,9 @@
#include vl_mpeg12_decoder.h
const enum pipe_format const_resource_formats_YV12[3] = {
- PIPE_FORMAT_R8_UNORM,
- PIPE_FORMAT_R8_UNORM,
- PIPE_FORMAT_R8_UNORM
+ PIPE_FORMAT_R8_SNORM,
+ PIPE_FORMAT_R8_SNORM,
+ PIPE_FORMAT_R8_SNORM
};
const enum pipe_format const_resource_formats_NV12[3] = {
diff --git a/src/gallium/state_trackers/xorg/xvmc/surface.c
b/src/gallium/state_trackers/xorg/xvmc/surface.c
index da41a18..0677cea 100644
--- a/src/gallium/state_trackers/xorg/xvmc/surface.c
+++ b/src/gallium/state_trackers/xorg/xvmc/surface.c
@@ -313,7 +313,7 @@ Status XvMCCreateSurface(Display *dpy, XvMCContext
*context, XvMCSurface *surfac
surface_priv-decode_buffer =
context_priv-decoder-create_buffer(context_priv-decoder);
surface_priv-mv_stride =
surface_priv-decode_buffer-get_mv_stream_stride(surface_priv-decode_buffer);
- surface_priv-video_buffer = vpipe-create_buffer(vpipe,
PIPE_FORMAT_NV12,
+ surface_priv-video_buffer = vpipe-create_buffer(vpipe,
PIPE_FORMAT_YV12,
context_priv-decoder-chroma_format,
context_priv-decoder-width,
context_priv-decoder-height);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36792] [PATCH] link to shared LLVM library
https://bugs.freedesktop.org/show_bug.cgi?id=36792 --- Comment #1 from Alan Swanson swan...@ukfsn.org 2011-05-05 05:27:51 PDT --- Actually it's LLVM itself that causes linking to static libraries via llvm-config even when built with enable shared due to LLVM bug 6823. http://llvm.org/bugs/show_bug.cgi?id=6823 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glproto changes
On Wed, 4 May 2011 18:21:20 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 5 May 2011 11:17:02 +1000 Dave Airlie airl...@gmail.com wrote: So I wasn't watching and glproto broke its interface, and I think its bad. Why? You can no longer bisect things across this point without now moving glproto. glxproto.h:xGLXBufferSwapComplete was a released header file definition, you cannot go back and change history. This should have been handled with xGLXBufferSwapComplete2 struct that newer mesa and X server could would use instead of the older code. Old code would build against the old broken defintion but since its broken it wouldn't matter, and new code would build against the new fixed definition. This doesn't address the I need the latest glproto to build mesa and my distro doesn't have which concerns me less than the I can't bisect anymore and I fully agree with Jesse that the last time we tried using #ifdef for this sort of thing it led to a number of untested combos resulting in impossible to debug issues. Yes, in hindsight I was too shellshocked by our previous experience with dri2 invalidate, ifdefs, and untested paths to even consider allowing new code to build with old proto. But breaking bisect is bad, no doubt. But in this case adding a separate struct is probably the right thing to do, and I'd be happy to do it if people are willing to put up with the churn (glproto 1.4.14, dri2proto 2.5 plus changes to Mesa and X to use the new struct). Yes, please do a new struct. I'm happy to see the churn to make it happen if it means developers are likely to do better at testing stable branches. pgpKAFiQS4QuT.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36307] libGL segfault with gnome-shell/mutter (using intel-dri)
https://bugs.freedesktop.org/show_bug.cgi?id=36307 Robert Hooker (Sarvatt) sarv...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Robert Hooker (Sarvatt) sarv...@gmail.com 2011-05-05 08:19:23 PDT --- This segfault is fixed by 6ae9e8cbabdc8a18a821ea3f716b18b3eb82a495 in mesa 7.11, it doesn't fix why you were trying to run mutter indirect though which is a local configuration problem on your system. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36307] libGL segfault with gnome-shell/mutter (using intel-dri)
https://bugs.freedesktop.org/show_bug.cgi?id=36307 --- Comment #2 from d...@tzib.net 2011-05-05 08:24:18 PDT --- Thanks for the fix :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glproto changes
On Wed, 4 May 2011 21:29:23 -0700
Jeremy Huddleston jerem...@freedesktop.org wrote:
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we
need to brownbag retract and rethink this.
Damnit; right when Dave mentioned this last night I knew I had gone too
far in trying to make sure the fix was propagated. I hate it when he's
right!
Yeah, having a rule that we can't touch existing proto structs makes
sense unless we want to do a major break. It certainly makes pushing
out updates eaiser and preserves bisection...
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, protocol) certainly warrants much more than the +0.0.1
version bump. This also makes it impossible to build the current dev and
current stable with the same protos installed. I haven't looked at the
details specifically, but I suspect that it also changes what is on the wire,
meaning clients and the server may disagree depending on which glproto
version they were using. Is that the case? If not, can't we solve this with
some creative union{}ing?
In this case, what's on the wire is pretty much the same; if the client
and server don't match, you may get a different kind of corruption in
the affected field (0 vs some other value), but things are no worse.
Either way, I think we should retract the glproto 1.4.13 release until we can
get this straightened out.
Ok; fwiw my rationale was twofold:
1) make sure master requires the new proto headers to avoid some of
the trouble we've had in the past with ifdefs and untested paths
(though again, the failure mode is benign in this case)
2) make the proto breakage obvious even for older code; the fix is
trivial
But I guess (2) is a bit much... after pushing I started having
nightmares about the input proto changes from awhile back.
Here are what the backwards compatible changes look like... Look
better?
Thanks,
--
Jesse Breaker of Builds Barnes
diff --git a/configure.ac b/configure.ac
index 9505f56..297be0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([DRI2Proto], [2.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([DRI2Proto], [2.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/dri2proto.h b/dri2proto.h
index ff76355..ab25565 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -290,6 +290,21 @@ typedef struct {
CARD8 pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD32 drawable B32;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xDRI2BufferSwapComplete;
+#define sz_xDRI2BufferSwapComplete 32
+
+typedef struct {
+CARD8 type;
+CARD8 pad;
+CARD16 sequenceNumber B16;
+CARD16 event_type B16;
CARD16 pad2;
CARD32 drawable B32;
CARD32 ust_hi B32;
@@ -297,7 +312,7 @@ typedef struct {
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc B32;
-} xDRI2BufferSwapComplete;
+} xDRI2BufferSwapComplete2;
#define sz_xDRI2BufferSwapComplete 32
typedef struct {
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.14], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index dfa0647..3f9e837 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1375,6 +1375,20 @@ typedef struct {
BYTE pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD32 drawable;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xGLXBufferSwapComplete;
+
+typedef struct {
+BYTE type;
+BYTE pad;
+CARD16 sequenceNumber B16;
+CARD16 event_type B16;
CARD16 pad2;
CARD32 drawable;
CARD32 ust_hi B32;
@@ -1382,7 +1396,8 @@ typedef struct {
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc B32;
-} xGLXBufferSwapComplete;
+} xGLXBufferSwapComplete2;
+
//
diff --git a/configure.ac b/configure.ac
index 54d9c29..fb38a4e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,8 +21,8 @@ dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRED=2.4.24
LIBDRM_INTEL_REQUIRED=2.4.24
-DRI2PROTO_REQUIRED=2.1
-GLPROTO_REQUIRED=1.4.11
+DRI2PROTO_REQUIRED=2.5
+GLPROTO_REQUIRED=1.4.14
LIBDRM_XORG_REQUIRED=2.4.24
LIBKMS_XORG_REQUIRED=1.0.0
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index
Re: [Mesa-dev] glproto changes
Why is sbc a 32bit field in xGLXBufferSwapComplete2 and
xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete?
The hunk at the bottom will result in casting a 64bit int to a 32bit int. If
you're going to change this, shouldn't you also change GLXBufferSwapComplete,
DRI2SwapEvent() and everything else that has a 64bit swap count?
Isn't it easier to correct the spec to match reality?
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -359,7 +359,7 @@ static void
DRI2SwapEvent(ClientPtr client, void *data, int type, CARD64 ust, CARD64 msc,
CARD64 sbc)
{
-xDRI2BufferSwapComplete event;
+xDRI2BufferSwapComplete2 event;
DrawablePtr pDrawable = data;
event.type = DRI2EventBase + DRI2_BufferSwapComplete;
@@ -369,8 +369,7 @@ DRI2SwapEvent(ClientPtr client, void *data, int type,
CARD64 ust, CARD64 msc,
event.ust_lo = ust 0x;
event.msc_hi = (CARD64)msc 32;
event.msc_lo = msc 0x;
-event.sbc_hi = (CARD64)sbc 32;
-event.sbc_lo = sbc 0x;
+event.sbc = sbc;
WriteEventsToClient(client, 1, (xEvent *)event);
}
On May 5, 2011, at 08:28, Jesse Barnes wrote:
On Wed, 4 May 2011 21:29:23 -0700
Jeremy Huddleston jerem...@freedesktop.org wrote:
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we
need to brownbag retract and rethink this.
Damnit; right when Dave mentioned this last night I knew I had gone too
far in trying to make sure the fix was propagated. I hate it when he's
right!
Yeah, having a rule that we can't touch existing proto structs makes
sense unless we want to do a major break. It certainly makes pushing
out updates eaiser and preserves bisection...
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, protocol) certainly warrants much more than the +0.0.1
version bump. This also makes it impossible to build the current dev and
current stable with the same protos installed. I haven't looked at the
details specifically, but I suspect that it also changes what is on the
wire, meaning clients and the server may disagree depending on which glproto
version they were using. Is that the case? If not, can't we solve this
with some creative union{}ing?
In this case, what's on the wire is pretty much the same; if the client
and server don't match, you may get a different kind of corruption in
the affected field (0 vs some other value), but things are no worse.
Either way, I think we should retract the glproto 1.4.13 release until we
can get this straightened out.
Ok; fwiw my rationale was twofold:
1) make sure master requires the new proto headers to avoid some of
the trouble we've had in the past with ifdefs and untested paths
(though again, the failure mode is benign in this case)
2) make the proto breakage obvious even for older code; the fix is
trivial
But I guess (2) is a bit much... after pushing I started having
nightmares about the input proto changes from awhile back.
Here are what the backwards compatible changes look like... Look
better?
Thanks,
--
Jesse Breaker of Builds Barnes
dri2proto-compat-fix.patchglproto-compat-fix.patchmesa-glx-compat-fix.patchxserver-glproto-compat-fix.patch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glproto changes
On Thu, 5 May 2011 10:07:24 -0700 Jeremy Huddleston jerem...@freedesktop.org wrote: Why is sbc a 32bit field in xGLXBufferSwapComplete2 and xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete? The hunk at the bottom will result in casting a 64bit int to a 32bit int. If you're going to change this, shouldn't you also change GLXBufferSwapComplete, DRI2SwapEvent() and everything else that has a 64bit swap count? Isn't it easier to correct the spec to match reality? No because XEvents are only 32 bytes. We actually noticed that when publishing the spec, but we never updated the code. And yes, I should change the CARD64s to CARD32s as in the previous patch. Accidentally dropped that part when reverting. Thanks, Jesse ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 --- Comment #5 from Iaroslav pontost...@gmail.com 2011-05-05 10:47:10 PDT --- Created an attachment (id=46368) -- (https://bugs.freedesktop.org/attachment.cgi?id=46368) llvm 3.0 svn + r300g llvm 3.0 svn + r300g with GALLIVM_DEBUG=tgsi,ir,asm -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 --- Comment #6 from Iaroslav pontost...@gmail.com 2011-05-05 10:51:31 PDT --- Created an attachment (id=46369) -- (https://bugs.freedesktop.org/attachment.cgi?id=46369) llvm 3.0 svn + swrast llvm 3.0 svn + swrast with GALLIVM_DEBUG=tgsi,ir,asm -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 --- Comment #7 from Iaroslav pontost...@gmail.com 2011-05-05 12:13:29 PDT --- Created an attachment (id=46371) -- (https://bugs.freedesktop.org/attachment.cgi?id=46371) llvm28-r300.log with GALLIVM_DEBUG=tgsi,ir,asm game crash before the menu, without GALLIVM_DEBUG all work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 --- Comment #8 from Iaroslav pontost...@gmail.com 2011-05-05 12:14:40 PDT --- Created an attachment (id=46372) -- (https://bugs.freedesktop.org/attachment.cgi?id=46372) llvm28-swrast with GALLIVM_DEBUG=tgsi,ir,asm game crash before the menu, without GALLIVM_DEBUG all work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 --- Comment #9 from Iaroslav pontost...@gmail.com 2011-05-05 12:17:52 PDT --- r300g + llvm 3.0 + UrbanTerror Program received signal SIGSEGV, Segmentation fault. 0xa40cd27c in ?? () (gdb) bt #0 0xa40cd27c in ?? () #1 0xa5cd1211 in llvm_pipeline_generic (middle=0x8c3a210, fetch_info=optimized out, prim_info=0xbfff7e6c) at draw/draw_pt_fetch_shade_pipeline_llvm.c:246 #2 0xa5cd13b0 in llvm_middle_end_linear_run_elts (middle=0x8ac7e80, start=0, count=4, draw_elts=0x8ac6284, draw_count=6, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline_llvm.c:395 #3 0xa5c6db7e in vsplit_primitive_uint (icount=6, istart=0, vsplit=0x8ac5260) at draw/draw_pt_vsplit_tmp.h:112 #4 vsplit_run_uint (frontend=0x8ac5260, start=0, count=6) at draw/draw_split_tmp.h:51 #5 0xa5c63fa5 in draw_pt_arrays (draw=optimized out, prim=4, start=0, count=6) at draw/draw_pt.c:113 #6 0xa5c6433d in draw_vbo (draw=0x8a415e8, info=0xbfff8194) at draw/draw_pt.c:491 #7 0xa5a6f4ce in r300_swtcl_draw_vbo (pipe=0x8a40870, info=0xbfff8194) at r300_render.c:870 #8 0xa5a72076 in r300_stencilref_draw_vbo (pipe=0x8a40870, info=0xbfff8194) at r300_render_stencilref.c:110 #9 0xa5b5657f in st_draw_vbo (ctx=0x8b2a478, arrays=0x8b6c4a0, prims=0xbfff8228, nr_prims=1, ib=0xbfff823c, index_bounds_valid=0 '\000', min_index=0, max_index=3) at state_tracker/st_draw.c:756 #10 0xa5b5067a in vbo_validated_drawrangeelements (ctx=0x8b2a478, mode=4, index_bounds_valid=0 '\000', start=4294967295, end=4294967295, count=6, type=5125, indices=0x89ca3e0, basevertex=0, numInstances=1) at vbo/vbo_exec_array.c:846 #11 0xa5b508b5 in vbo_exec_DrawElements (mode=4, count=6, type=5125, indices=0x89ca3e0) at vbo/vbo_exec_array.c:1005 #12 0x08169485 in RB_StageIteratorGeneric () #13 0x0065 in ?? () #14 0x in ?? () -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 --- Comment #10 from Iaroslav pontost...@gmail.com 2011-05-05 12:25:08 PDT --- Created an attachment (id=46373) -- (https://bugs.freedesktop.org/attachment.cgi?id=46373) llvm28-r300 with GALLIVM_DEBUG=tgsi,ir with GALLIVM_DEBUG=tgsi,ir all work -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Compatible GLX swap event fixes
This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). I won't push until I get at least a couple of reviewed-by and at least one tested-by from people. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.14],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index dfa0647..3f9e837 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1375,6 +1375,20 @@ typedef struct {
BYTE pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD32 drawable;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xGLXBufferSwapComplete;
+
+typedef struct {
+BYTE type;
+BYTE pad;
+CARD16 sequenceNumber B16;
+CARD16 event_type B16;
CARD16 pad2;
CARD32 drawable;
CARD32 ust_hi B32;
@@ -1382,7 +1396,8 @@ typedef struct {
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc B32;
-} xGLXBufferSwapComplete;
+} xGLXBufferSwapComplete2;
+
//
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] dri2proto: add new DRI2BufferSwapComplete struct to match spec
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index 9505f56..297be0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([DRI2Proto], [2.4],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([DRI2Proto], [2.5],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/dri2proto.h b/dri2proto.h
index 9708a4a..ae7701b 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -304,6 +304,21 @@ typedef struct {
CARD8 type;
CARD8 pad;
CARD16 sequenceNumber B16;
+CARD16 event_type B16;
+CARD16 pad2;
+CARD32 drawable B32;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc B32;
+} xDRI2BufferSwapComplete2;
+#define sz_xDRI2BufferSwapComplete2 32
+
+typedef struct {
+CARD8 type;
+CARD8 pad;
+CARD16 sequenceNumber B16;
CARD32 drawable B32;
CARD32 pad1 B32;
CARD32 pad2 B32;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/glx/dri2: use new GLX/DRI2 swap event types
Use the new swap event type so we get valid SBC values.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index 54d9c29..fb38a4e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,8 +21,8 @@ dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRED=2.4.24
LIBDRM_INTEL_REQUIRED=2.4.24
-DRI2PROTO_REQUIRED=2.1
-GLPROTO_REQUIRED=1.4.11
+DRI2PROTO_REQUIRED=2.5
+GLPROTO_REQUIRED=1.4.14
LIBDRM_XORG_REQUIRED=2.4.24
LIBKMS_XORG_REQUIRED=1.0.0
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index adfd3d1..8654a37 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -97,7 +97,7 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
case DRI2_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
- xDRI2BufferSwapComplete *awire = (xDRI2BufferSwapComplete *)wire;
+ xDRI2BufferSwapComplete2 *awire = (xDRI2BufferSwapComplete2 *)wire;
/* Ignore swap events if we're not looking for them */
aevent-type = dri2GetSwapEventType(dpy, awire-drawable);
@@ -124,7 +124,7 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
}
aevent-ust = ((CARD64)awire-ust_hi 32) | awire-ust_lo;
aevent-msc = ((CARD64)awire-msc_hi 32) | awire-msc_lo;
- aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
+ aevent-sbc = awire-sbc;
return True;
}
#endif
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 278c719..02652cb 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -133,12 +133,12 @@ __glXWireToEvent(Display *dpy, XEvent *event, xEvent
*wire)
case GLX_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
- xGLXBufferSwapComplete *awire = (xGLXBufferSwapComplete *)wire;
+ xGLXBufferSwapComplete2 *awire = (xGLXBufferSwapComplete2 *)wire;
aevent-event_type = awire-event_type;
aevent-drawable = awire-drawable;
aevent-ust = ((CARD64)awire-ust_hi 32) | awire-ust_lo;
aevent-msc = ((CARD64)awire-msc_hi 32) | awire-msc_lo;
- aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
+ aevent-sbc = awire-sbc;
return True;
}
default:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
Use the new event types so we can pass a valid SBC value to clients.
Fix up the completion calls to use CARD32 instead of CARD64 to match
the new field size.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index 6eb780c..3e0ed5d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -771,11 +771,11 @@ RECORDPROTO=recordproto = 1.13.99.1
SCRNSAVERPROTO=scrnsaverproto = 1.1
RESOURCEPROTO=resourceproto
DRIPROTO=xf86driproto = 2.1.0
-DRI2PROTO=dri2proto = 2.3
+DRI2PROTO=dri2proto = 2.5
XINERAMAPROTO=xineramaproto
BIGFONTPROTO=xf86bigfontproto = 1.2.0
DGAPROTO=xf86dgaproto = 2.0.99.1
-GLPROTO=glproto = 1.4.10
+GLPROTO=glproto = 1.4.14
DMXPROTO=dmxproto = 2.2.99.1
VIDMODEPROTO=xf86vidmodeproto = 2.2.99.1
WINDOWSWMPROTO=windowswmproto
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 93c5e5b..e872258 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -163,10 +163,10 @@ __glXDRIdrawableWaitGL(__GLXdrawable *drawable)
static void
__glXdriSwapEvent(ClientPtr client, void *data, int type, CARD64 ust,
- CARD64 msc, CARD64 sbc)
+ CARD64 msc, CARD32 sbc)
{
__GLXdrawable *drawable = data;
-xGLXBufferSwapComplete wire;
+xGLXBufferSwapComplete2 wire;
if (!(drawable-eventMask GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
return;
@@ -192,8 +192,7 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type,
CARD64 ust,
wire.ust_lo = ust 0x;
wire.msc_hi = msc 32;
wire.msc_lo = msc 0x;
-wire.sbc_hi = sbc 32;
-wire.sbc_lo = sbc 0x;
+wire.sbc = sbc;
WriteEventsToClient(client, 1, (xEvent *) wire);
}
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index fe0bf6c..2a41ead 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -51,7 +51,7 @@ extern CARD8 dri2_minor;
typedef DRI2BufferRec DRI2Buffer2Rec, *DRI2Buffer2Ptr;
typedef void (*DRI2SwapEventPtr)(ClientPtr client, void *data, int type,
-CARD64 ust, CARD64 msc, CARD64 sbc);
+CARD64 ust, CARD64 msc, CARD32 sbc);
typedef DRI2BufferPtr (*DRI2CreateBuffersProcPtr)(DrawablePtr pDraw,
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 4e48e65..552b26b 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -357,9 +357,9 @@ vals_to_card64(CARD32 lo, CARD32 hi)
static void
DRI2SwapEvent(ClientPtr client, void *data, int type, CARD64 ust, CARD64 msc,
- CARD64 sbc)
+ CARD32 sbc)
{
-xDRI2BufferSwapComplete event;
+xDRI2BufferSwapComplete2 event;
DrawablePtr pDrawable = data;
event.type = DRI2EventBase + DRI2_BufferSwapComplete;
@@ -369,8 +369,7 @@ DRI2SwapEvent(ClientPtr client, void *data, int type,
CARD64 ust, CARD64 msc,
event.ust_lo = ust 0x;
event.msc_hi = (CARD64)msc 32;
event.msc_lo = msc 0x;
-event.sbc_hi = (CARD64)sbc 32;
-event.sbc_lo = sbc 0x;
+event.sbc = sbc;
WriteEventsToClient(client, 1, (xEvent *)event);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Compatible GLX swap event fixes
On Thu, 5 May 2011 12:38:24 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). Correction, new clients with old servers will generally see a 0 SBC count; they're no longer reading a value beyond the 32 byte XEvent, and old servers send the high 32 bits of the SBC count at the end. So they'll get 0 until the SBC exceeds 32 bits on the server side (which will take a long time). -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
On Thu, 05 May 2011 12:59:50 -0700 Jeremy Huddleston jerem...@apple.com wrote: For *proto/mesa: Reviewed-by: Jeremy Huddleston jerem...@apple.com Thanks. For xserver: This looks incomplete. You also need to update swap_count in DRI2DrawableRec to be CARD32. That value is used in other places that actually preserve the full 64 bits. I could add an explicit cast in the few places where we pass it to the swap completion though if you think that's better... -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
On Thu, 05 May 2011 13:17:13 -0700 Jeremy Huddleston jerem...@apple.com wrote: On May 5, 2011, at 1:09 PM, Jesse Barnes wrote: On Thu, 05 May 2011 12:59:50 -0700 Jeremy Huddleston jerem...@apple.com wrote: For *proto/mesa: Reviewed-by: Jeremy Huddleston jerem...@apple.com Thanks. For xserver: This looks incomplete. You also need to update swap_count in DRI2DrawableRec to be CARD32. That value is used in other places that actually preserve the full 64 bits. I could add an explicit cast in the few places where we pass it to the swap completion though if you think that's better... Yes, I realize that there are some areas that use 64bit for sbc. Do we really need 64bits for this? If so, how do we properly to communicate the 64bit value between server/client? Currently, your changes result in an implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause problems if we really do need those extra bits: if (swap_complete) swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count); It looks to me like much more of DRI2 should be rewritten to use 32bit swap counts, or there should be some other mechanism in place to communicate the full 64bit value. Yeah there are other mechanisms (the OML sync extension) for communicating the whole 64 bits. Both the swap reply and msc reply deal in the full 64 bits, just the swap event (an unrelated extension) truncates to 32 bits. (Also I think the 64 bit size for swap count in the OML extension is just inertia; getting to a count that high even at 120Hz is going to take awhile.) -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: don't touch git_sha1.h if sha1 didn't change
Reviewed-by: Dan Nicholson dbn.li...@gmail.com Reviewed-by: Ian Romanick ian.d.roman...@intel.com --- bin/extract_git_sha1 | 10 -- src/mesa/main/.gitignore |1 + 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..5e635d4 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,16 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h +if [ ! -f src/mesa/main/git_sha1.h ]; then + touch src/mesa/main/git_sha1.h +fi + if which git /dev/null; then # Extract the 7-digit short SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 git-\1/' \ -src/mesa/main/git_sha1.h +src/mesa/main/git_sha1.h.tmp +if ! cmp -s src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h +fi fi diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore index e48030e..2575f44 100644 --- a/src/mesa/main/.gitignore +++ b/src/mesa/main/.gitignore @@ -3,3 +3,4 @@ api_exec_es2.c get_es1.c get_es2.c git_sha1.h +git_sha1.h.tmp -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: don't call git if it's not git repository
Reviewed-by: Dan Nicholson dbn.li...@gmail.com Reviewed-by: Ian Romanick ian.d.roman...@intel.com --- bin/extract_git_sha1 |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index 5e635d4..8283870 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -3,6 +3,10 @@ if [ ! -f src/mesa/main/git_sha1.h ]; then touch src/mesa/main/git_sha1.h fi +if [ ! -d .git ]; then + exit +fi + if which git /dev/null; then # Extract the 7-digit short SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: don't touch git_sha1.h if sha1 didn't change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 01:37 PM, Marcin Slusarz wrote: Reviewed-by: Dan Nicholson dbn.li...@gmail.com Reviewed-by: Ian Romanick ian.d.roman...@intel.com I pushed both patches to Mesa master. Thanks. --- bin/extract_git_sha1 | 10 -- src/mesa/main/.gitignore |1 + 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..5e635d4 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,16 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h +if [ ! -f src/mesa/main/git_sha1.h ]; then + touch src/mesa/main/git_sha1.h +fi + if which git /dev/null; then # Extract the 7-digit short SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 git-\1/' \ - src/mesa/main/git_sha1.h + src/mesa/main/git_sha1.h.tmp +if ! cmp -s src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h +fi fi diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore index e48030e..2575f44 100644 --- a/src/mesa/main/.gitignore +++ b/src/mesa/main/.gitignore @@ -3,3 +3,4 @@ api_exec_es2.c get_es1.c get_es2.c git_sha1.h +git_sha1.h.tmp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3DDaQACgkQX1gOwKyEAw9JiQCfX/m+F4JCHd1wAmuvdXbzohW1 RikAn0C8fFd0nCZPVdWYowSlXmAYJQza =7hUZ -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
if (swap_complete) {
if (pPriv-swap_count 0x)
ErrorF(something appropriate);
swap_complete(client, swap_data, type, ust, frame,
(CARD32)pPriv-swap_count);
}
Yeah, it's annoying. How about I leave out the error message and handle
wrapping on the client side instead? That way at least the client code
won't notice that the server is only transmitting 32 bits...
Nevermind, that can't work generally since clients are free to
mask/unmask the events, so we could miss a 0 count and thus a wrap. We
just have to live with the fact that swap events have a 32 bit sbc and
OML uses 64 bit counts. I'll add the warning though; if it becomes a
real issue we can potentially add another round trip to get the value
using OML instead.
--
Jesse Barnes, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
Andy Furniss wrote:
There has been a regression though -
[g3dvl] remove resource_format workaround
causes quite bad artifacts on newmobcal.
I can get rid of the new artifacts for xvmc with the patch below.
ffmpeg12vdpau shows the same new artifacts, but is not fixed by this.
The problem is more complicated than this, using a signed buffer format
is just a workaround, the real solution is to implement blender clamping
in r600g. You could try this (temporary) patch until I figured out how
to do this correctly on all supported hardware:
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -786,10 +786,10 @@ static void r600_cb(struct r600_pipe_context *rctx,
struct r600_pipe_state *rsta
if BLEND_FLOAT32 is set of 11 bits in a UNORM or SNORM */
if (desc-colorspace != UTIL_FORMAT_COLORSPACE_ZS
desc-channel[i].size 12) {
//TODO: Seems to work on RV710, but i have no idea what to do
between R600-RV710
- if (rctx-family CHIP_RV710) {
- color_info |= S_0280A0_BLEND_CLAMP(1);
- color_info_mask |= S_0280A0_BLEND_CLAMP(1);
- }
+ //if (rctx-family CHIP_RV710) {
+ // color_info |= S_0280A0_BLEND_CLAMP(1);
+ // color_info_mask |= S_0280A0_BLEND_CLAMP(1);
+ //}
color_info |= S_0280A0_SOURCE_FORMAT(V_0280A0_EXPORT_NORM);
}
I'm currently focusing more on the variable length decoding part of the
vdpau mpeg2, by the way: How is well does this work on your hardware?
Regards,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 01:25 PM, Jesse Barnes wrote: On Thu, 05 May 2011 13:17:13 -0700 Jeremy Huddleston jerem...@apple.com wrote: Yes, I realize that there are some areas that use 64bit for sbc. Do we really need 64bits for this? If so, how do we properly to communicate the 64bit value between server/client? Currently, your changes result in an implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause problems if we really do need those extra bits: if (swap_complete) swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count); It looks to me like much more of DRI2 should be rewritten to use 32bit swap counts, or there should be some other mechanism in place to communicate the full 64bit value. Yeah there are other mechanisms (the OML sync extension) for communicating the whole 64 bits. Both the swap reply and msc reply deal in the full 64 bits, just the swap event (an unrelated extension) truncates to 32 bits. (Also I think the 64 bit size for swap count in the OML extension is just inertia; getting to a count that high even at 120Hz is going to take awhile.) But it could happen on, say, a desktop compositor that's been logged in for a month. I think the main reason is that the other two values really need to be 64-bits, so you might as well make all three be 64-bits. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3DEsoACgkQX1gOwKyEAw/a3gCePneowulpZhTz88vmU4DRr22K D20An35ff4MD3uuDUfJXNxE5m+wtsm1m =bzXJ -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Compatible GLX swap event fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 12:38 PM, Jesse Barnes wrote: This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). I won't push until I get at least a couple of reviewed-by and at least one tested-by from people. Thanks, This looks more like the changeset I was expecting. For the series, Reviewed-by: Ian Romanick ian.d.roman...@intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3DE3UACgkQX1gOwKyEAw+bnwCfetNHCC9tVmfMwEG1rftt0ooH oXsAn0eryd+YZCS8S5hsVQq/ILEtzX5A =T9g0 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Compatible GLX swap event fixes
On Thu, 05 May 2011 14:15:33 -0700 Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 12:38 PM, Jesse Barnes wrote: This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). I won't push until I get at least a couple of reviewed-by and at least one tested-by from people. Thanks, This looks more like the changeset I was expecting. For the series, Reviewed-by: Ian Romanick ian.d.roman...@intel.com Thanks. -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
2011/5/5 Christian König deathsim...@vodafone.de:
Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
Andy Furniss wrote:
There has been a regression though -
[g3dvl] remove resource_format workaround
causes quite bad artifacts on newmobcal.
I can get rid of the new artifacts for xvmc with the patch below.
ffmpeg12vdpau shows the same new artifacts, but is not fixed by this.
The problem is more complicated than this, using a signed buffer format
is just a workaround, the real solution is to implement blender clamping
in r600g. You could try this (temporary) patch until I figured out how
to do this correctly on all supported hardware:
Something like the attached patch should work.
Alex
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -786,10 +786,10 @@ static void r600_cb(struct r600_pipe_context *rctx,
struct r600_pipe_state *rsta
if BLEND_FLOAT32 is set of 11 bits in a UNORM or SNORM */
if (desc-colorspace != UTIL_FORMAT_COLORSPACE_ZS
desc-channel[i].size 12) {
//TODO: Seems to work on RV710, but i have no idea what to do
between R600-RV710
- if (rctx-family CHIP_RV710) {
- color_info |= S_0280A0_BLEND_CLAMP(1);
- color_info_mask |= S_0280A0_BLEND_CLAMP(1);
- }
+ //if (rctx-family CHIP_RV710) {
+ // color_info |= S_0280A0_BLEND_CLAMP(1);
+ // color_info_mask |= S_0280A0_BLEND_CLAMP(1);
+ //}
color_info |= S_0280A0_SOURCE_FORMAT(V_0280A0_EXPORT_NORM);
}
I'm currently focusing more on the variable length decoding part of the
vdpau mpeg2, by the way: How is well does this work on your hardware?
Regards,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From cf459847da193c103bc34fea6a789373dee63568 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 5 May 2011 17:47:44 -0400
Subject: [PATCH] r600g: fix up the rules for enabling SOURCE_FORMAT(EXPORT_NORM)
Setting SOURCE_FORMAT to EXPORT_NORM is an optimization.
Leaving SOURCE_FORMAT at 0 will work in all cases, but is less
efficient. The conditions for the setting the EXPORT_NORM
optimization are as follows:
R600/RV6xx:
BLEND_CLAMP is enabled
BLEND_FLOAT32 is disabled
11-bit or smaller UNORM/SNORM/SRGB
R7xx/evergreen:
11-bit or smaller UNORM/SNORM/SRGB
16-bit or smaller FLOAT
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
src/gallium/drivers/r600/evergreen_state.c | 15 ---
src/gallium/drivers/r600/r600_state.c | 35
2 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c
index e325361..7a4d625 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -707,11 +707,18 @@ static void evergreen_cb(struct r600_pipe_context *rctx, struct r600_pipe_state
S_028C70_ENDIAN(endian);
- /* we can only set the export size if any thing is snorm/unorm component is 11 bits,
- if we aren't a float, sint or uint */
+ /* EXPORT_NORM is an optimzation that can be enabled for better
+ * performance in certain cases.
+ * EXPORT_NORM can be enabled if:
+ * - 11-bit or smaller UNORM/SNORM/SRGB
+ * - 16-bit or smaller FLOAT
+ */
if (desc-colorspace != UTIL_FORMAT_COLORSPACE_ZS
- desc-channel[i].size 12 desc-channel[i].type != UTIL_FORMAT_TYPE_FLOAT
- ntype != V_028C70_NUMBER_UINT ntype != V_028C70_NUMBER_SINT)
+ ((desc-channel[i].size 12
+ desc-channel[i].type != UTIL_FORMAT_TYPE_FLOAT
+ ntype != V_028C70_NUMBER_UINT ntype != V_028C70_NUMBER_SINT) ||
+ (desc-channel[i].size 17
+ desc-channel[i].type == UTIL_FORMAT_TYPE_FLOAT)))
color_info |= S_028C70_SOURCE_FORMAT(V_028C70_EXPORT_4C_16BPC);
if (rtex-array_mode[level] V_028C70_ARRAY_LINEAR_ALIGNED) {
diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c
index 1c27f88..fbf2c84 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -767,11 +767,36 @@ static void r600_cb(struct r600_pipe_context *rctx, struct r600_pipe_state *rsta
S_0280A0_NUMBER_TYPE(ntype) |
S_0280A0_ENDIAN(endian);
- /* on R600 this can't be set if BLEND_CLAMP isn't set,
- if BLEND_FLOAT32 is set of 11 bits in a UNORM or SNORM */
- if (desc-colorspace != UTIL_FORMAT_COLORSPACE_ZS
- desc-channel[i].size 12)
- color_info |= S_0280A0_SOURCE_FORMAT(V_0280A0_EXPORT_NORM);
+ /* EXPORT_NORM is an optimzation that can be enabled for better
+ * performance in certain cases
+ */
+ if (rctx-family CHIP_RV770) {
+ /* EXPORT_NORM can be enabled if:
+ * - 11-bit
[Mesa-dev] [PATCH] configure: Don't use $CLANG since it will collide with the static analyzer.
We just prefix the $CLANG environment variable in configure.ac with acv_mesa_ Found by: tinderbox Signed-off-by: Jeremy Huddleston jerem...@apple.com --- configure.ac |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 54d9c29..f3f0fda 100644 --- a/configure.ac +++ b/configure.ac @@ -64,13 +64,13 @@ AC_COMPILE_IFELSE( not clang #endif ]])], -[CLANG=yes], [CLANG=no]) +[acv_mesa_CLANG=yes], [acv_mesa_CLANG=no]) -AC_MSG_RESULT([$CLANG]) +AC_MSG_RESULT([$acv_mesa_CLANG]) dnl If we're using GCC, make sure that it is at least version 3.3.0. Older dnl versions are explictly not supported. -if test x$GCC = xyes -a x$CLANG = xno; then +if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then AC_MSG_CHECKING([whether gcc version is sufficient]) major=0 minor=0 @@ -144,7 +144,7 @@ esac dnl Add flags for gcc and g++ if test x$GCC = xyes; then CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 -if test x$CLANG = xno; then +if test x$acv_mesa_CLANG = xno; then CFLAGS=$CFLAGS -ffast-math fi -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600
On May 5, 2011 5:10pm, Christian König deathsim...@vodafone.de wrote: I'm currently focusing more on the variable length decoding part of the vdpau mpeg2, by the way: How is well does this work on your hardware? Regards, Christian. I have a somewhat working VLD implementation that I haven't had time to go back to if it's helpful. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
2011/5/5 Alex Deucher alexdeuc...@gmail.com:
2011/5/5 Alex Deucher alexdeuc...@gmail.com:
2011/5/5 Mathias Fröhlich mathias.froehl...@gmx.net:
Hi all,
On Thursday, May 05, 2011 04:32:03 you wrote:
Okay my guess at the problem is that:
the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
on the base in the CB being the same as the texture BASE which it won't
be in the case where we are rendering to mip sublevels. Though I've no idea
how to workaround this without explicit flushes.
Hmm, may be.
I also thought that the surface sync packet has some special case
optimzations
for some of the probably often used flags that lead to that kind of
behaviour.
May be that 'flush all' in case of a new framebuffer target for these kind
of
chips is again a good idea instead of the finegrained flush dest caches.
May be Alex finds some undocumented ideas somewhere in his bag :).
Apparently the CB/DB surface sync stuff has a number of issues on
r6xx, so we should just use event_write flushes for CB/DB. A single
event write flush takes care of all dst caches. Something like this
untested patch perhaps:
http://people.freedesktop.org/~agd5f/r600g_event_flush.diff
The attached patch seems to work for me.
Updated patch with Fredrik's suggestion.
Alex
Alex
From 1b115f465787d583c8f06d1f59f1cf0a7a20a20c Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 5 May 2011 18:37:42 -0400
Subject: [PATCH] r600g: fix cache flushes on r6xx (v2)
r6xx asics have some problems with the surface
sync logic for the CB and DB. It's recommended
to use the event write interface for flushing
the DB/CB caches rather than the sync packets.
A single event write flush flushes all dst
caches, so we only need one for all CBs and DB.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=35312
v2: don't emit sync packets for other cbs or db.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
src/gallium/drivers/r600/r600.h |1 +
src/gallium/winsys/r600/drm/r600_hw_context.c | 34 ++--
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 0b0df9d..33aa450 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -235,6 +235,7 @@ struct r600_query {
#define R600_CONTEXT_DRAW_PENDING (1 0)
#define R600_CONTEXT_DST_CACHES_DIRTY (1 1)
+#define R600_CONTEXT_CHECK_EVENT_FLUSH (1 2)
struct r600_context {
struct radeon *radeon;
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c b/src/gallium/winsys/r600/drm/r600_hw_context.c
index 150485d..3e0ff6b 100644
--- a/src/gallium/winsys/r600/drm/r600_hw_context.c
+++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
@@ -797,19 +797,31 @@ void r600_context_bo_flush(struct r600_context *ctx, unsigned flush_flags,
unsigned flush_mask, struct r600_bo *rbo)
{
struct radeon_bo *bo;
+
bo = rbo-bo;
/* if bo has already been flushed */
if (!(~bo-last_flush flush_flags)) {
bo-last_flush = flush_mask;
return;
}
- ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_SURFACE_SYNC, 3, ctx-predicate_drawing);
- ctx-pm4[ctx-pm4_cdwords++] = flush_flags;
- ctx-pm4[ctx-pm4_cdwords++] = (bo-size + 255) 8;
- ctx-pm4[ctx-pm4_cdwords++] = 0x;
- ctx-pm4[ctx-pm4_cdwords++] = 0x000A;
- ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, ctx-predicate_drawing);
- ctx-pm4[ctx-pm4_cdwords++] = bo-reloc_id;
+
+ if ((ctx-radeon-family CHIP_RV770)
+ (G_0085F0_CB_ACTION_ENA(flush_flags) ||
+ G_0085F0_DB_ACTION_ENA(flush_flags))) {
+ if (ctx-flags R600_CONTEXT_CHECK_EVENT_FLUSH) {
+ ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_EVENT_WRITE, 0, ctx-predicate_drawing);
+ ctx-pm4[ctx-pm4_cdwords++] = EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT) | EVENT_INDEX(0);
+ ctx-flags = ~R600_CONTEXT_CHECK_EVENT_FLUSH;
+ }
+ } else {
+ ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_SURFACE_SYNC, 3, ctx-predicate_drawing);
+ ctx-pm4[ctx-pm4_cdwords++] = flush_flags;
+ ctx-pm4[ctx-pm4_cdwords++] = (bo-size + 255) 8;
+ ctx-pm4[ctx-pm4_cdwords++] = 0x;
+ ctx-pm4[ctx-pm4_cdwords++] = 0x000A;
+ ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, ctx-predicate_drawing);
+ ctx-pm4[ctx-pm4_cdwords++] = bo-reloc_id;
+ }
bo-last_flush = (bo-last_flush | flush_flags) flush_mask;
}
@@ -1119,6 +1131,7 @@ void r600_context_block_emit_dirty(struct r600_context *ctx, struct r600_block *
goto out;
}
+ ctx-flags |= R600_CONTEXT_CHECK_EVENT_FLUSH;
for (int j = 0; j block-nreg; j++) {
if (block-pm4_bo_index[j]) {
/* find relocation */
@@ -1132,6 +1145,7 @@ void r600_context_block_emit_dirty(struct r600_context *ctx, struct r600_block *
block-reloc[id].bo);
}
}
+ ctx-flags = ~R600_CONTEXT_CHECK_EVENT_FLUSH;
memcpy(ctx-pm4[ctx-pm4_cdwords], block-pm4, block-pm4_ndwords * 4);
ctx-pm4_cdwords += block-pm4_ndwords;
@@ -1155,6 +1169,7 @@ void
Re: [Mesa-dev] [PATCH 1/2] mesa: implement AMD_seamless_cubemap_per_texture
A new patch is attached.
Marek
On Tue, May 3, 2011 at 11:21 PM, Brian Paul bri...@vmware.com wrote:
On 05/03/2011 01:24 PM, Brian Paul wrote:
On 05/03/2011 07:55 AM, Marek Olšák wrote:
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 2 ++
src/mesa/main/texobj.c | 2 ++
src/mesa/main/texparam.c | 32
4 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 1062cde..a9ef8fa 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -260,6 +260,7 @@ static const struct extension extension_table[] = {
{ GL_3DFX_texture_compression_FXT1,
o(TDFX_texture_compression_FXT1), GL, 1999 },
{ GL_AMD_conservative_depth,
o(AMD_conservative_depth), GL, 2009 },
{ GL_AMD_draw_buffers_blend,
o(ARB_draw_buffers_blend), GL, 2009 },
+ { GL_AMD_seamless_cubemap_per_texture,
o(AMD_seamless_cubemap_per_texture), GL, 2009 },
{ GL_AMD_shader_stencil_export,
o(ARB_shader_stencil_export), GL, 2009 },
{ GL_APPLE_client_storage,
o(APPLE_client_storage), GL, 2002 },
{ GL_APPLE_object_purgeable,
o(APPLE_object_purgeable), GL, 2006 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index fba65e8..ad65b55 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1370,6 +1370,7 @@ struct gl_texture_object
GLint CropRect[4]; /** GL_OES_draw_texture */
GLenum Swizzle[4]; /** GL_EXT_texture_swizzle */
GLuint _Swizzle; /** same as Swizzle, but SWIZZLE_*
format */
+ GLboolean CubeMapSeamless; /**
GL_AMD_seamless_cubemap_per_texture */
I'm wondering if this field should be per-texture object or per-sampler
object. I've sent an email to someone at AMD to find out. I'll let you
know.
It's supposed to be per sampler object.
-Brian
From a0187f7e97f1d30463ffe2b086e8e9657d9d498f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Tue, 3 May 2011 11:37:25 +0200
Subject: [PATCH 1/2] mesa: implement AMD_seamless_cubemap_per_texture
---
src/mesa/main/extensions.c |1 +
src/mesa/main/mtypes.h |2 ++
src/mesa/main/samplerobj.c | 21 +
src/mesa/main/texobj.c |2 ++
src/mesa/main/texparam.c | 32
5 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 1062cde..a9ef8fa 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -260,6 +260,7 @@ static const struct extension extension_table[] = {
{ GL_3DFX_texture_compression_FXT1, o(TDFX_texture_compression_FXT1), GL, 1999 },
{ GL_AMD_conservative_depth, o(AMD_conservative_depth), GL, 2009 },
{ GL_AMD_draw_buffers_blend, o(ARB_draw_buffers_blend), GL, 2009 },
+ { GL_AMD_seamless_cubemap_per_texture,o(AMD_seamless_cubemap_per_texture),GL, 2009 },
{ GL_AMD_shader_stencil_export, o(ARB_shader_stencil_export), GL, 2009 },
{ GL_APPLE_client_storage,o(APPLE_client_storage),GL, 2002 },
{ GL_APPLE_object_purgeable, o(APPLE_object_purgeable), GL, 2006 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index fba65e8..29c8cfd 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1339,6 +1339,7 @@ struct gl_sampler_object
GLenum CompareFunc; /** GL_ARB_shadow */
GLfloat CompareFailValue;/** GL_ARB_shadow_ambient */
GLenum sRGBDecode; /** GL_DECODE_EXT or GL_SKIP_DECODE_EXT */
+ GLboolean CubeMapSeamless; /** GL_AMD_seamless_cubemap_per_texture */
/* deprecated sampler state */
GLenum DepthMode; /** GL_ARB_depth_texture */
@@ -2885,6 +2886,7 @@ struct gl_extensions
GLboolean OES_standard_derivatives;
/* vendor extensions */
GLboolean AMD_conservative_depth;
+ GLboolean AMD_seamless_cubemap_per_texture;
GLboolean APPLE_client_storage;
GLboolean APPLE_packed_pixels;
GLboolean APPLE_vertex_array_object;
diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
index 4a28c91..6e53f64 100644
--- a/src/mesa/main/samplerobj.c
+++ b/src/mesa/main/samplerobj.c
@@ -133,6 +133,7 @@ _mesa_init_sampler_object(struct gl_sampler_object *sampObj, GLuint name)
sampObj-CompareFunc = GL_LEQUAL;
sampObj-CompareFailValue = 0.0;
sampObj-sRGBDecode = GL_FALSE;
+ sampObj-CubeMapSeamless = GL_FALSE;
sampObj-DepthMode =
Re: [Mesa-dev] [PATCH 2/2] gallium: implement seamless cubemap extensions
A new patch is attached.
Marek
On Tue, May 3, 2011 at 9:31 PM, Brian Paul bri...@vmware.com wrote:
On 05/03/2011 11:55 AM, Roland Scheidegger wrote:
Am 03.05.2011 15:55, schrieb Marek Olšák:
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 250cbb2..ac6d76a 100644
--- a/src/mesa/state_tracker/st_atom_rasterizer.c
+++ b/src/mesa/state_tracker/st_atom_rasterizer.c
@@ -257,6 +257,9 @@ static void update_raster_state( struct st_context
*st )
/* _NEW_FRAG_CLAMP */
raster-clamp_fragment_color = ctx-Color._ClampFragmentColor;
+ /* _NEW_TEXTURE */
+ raster-seamless_cube_map = ctx-Texture.CubeMapSeamless != GL_FALSE;
+
raster-gl_rasterization_rules = 1;
cso_set_rasterizer(st-cso_context, raster);
@@ -273,7 +276,8 @@ const struct st_tracked_state st_update_rasterizer =
{
_NEW_POLYGON |
_NEW_PROGRAM |
_NEW_SCISSOR |
- _NEW_FRAG_CLAMP), /* mesa state dependencies*/
+ _NEW_FRAG_CLAMP |
+ _NEW_TEXTURE), /* mesa state dependencies */
ST_NEW_VERTEX_PROGRAM, /* state tracker dependencies */
},
update_raster_state /* update function */
Hmm seems rather unfortunate that this is _NEW_TEXTURE - looks like all
the rest of the bits are likely much lower frequency (and of course the
seamless bit itself probably only ever changes once). I can see now why
you made that a new bit. I'll defer that to Brian though.
Marek, are you sure it's too hard to check the currently bound samplers in
the driver to check for global seamless cube map there?
I'm still not too satisfied with having this state in two places. It feels
shoehorned into the rasterizer state.
But I don't want to hold this up too long. It could be changed in the
future if we change our minds.
-Brian
From 54dd3ffe211b98df6b40201f1ae8944b6549d363 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Mon, 2 May 2011 02:37:46 +0200
Subject: [PATCH 2/2] gallium: implement seamless cubemap extensions
---
src/gallium/docs/source/cso/sampler.rst |4
src/gallium/include/pipe/p_defines.h |2 ++
src/gallium/include/pipe/p_state.h |1 +
src/mesa/state_tracker/st_atom_sampler.c |3 +++
src/mesa/state_tracker/st_extensions.c |8
5 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/src/gallium/docs/source/cso/sampler.rst b/src/gallium/docs/source/cso/sampler.rst
index 9bbb784..648b5cc 100644
--- a/src/gallium/docs/source/cso/sampler.rst
+++ b/src/gallium/docs/source/cso/sampler.rst
@@ -107,3 +107,7 @@ max_anisotropy
Set to zero to disable anisotropic filtering. Any other setting enables
anisotropic filtering, however it's not unexpected some drivers only will
change their filtering with a setting of 2 and higher.
+seamless_cube_map
+If set, the bilinear filter of a cube map may take samples from adjacent
+cube map faces when sampled near a texture border to produce a seamless
+look.
\ No newline at end of file
diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
index 431a7fb..3c0f9bf 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -465,6 +465,8 @@ enum pipe_cap {
PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR = 44,
PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL = 45,
PIPE_CAP_MIXED_COLORBUFFER_FORMATS = 46,
+ PIPE_CAP_SEAMLESS_CUBE_MAP = 47,
+ PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE = 48,
};
/* Shader caps not specific to any single stage */
diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h
index 0c1f509..86ef255 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -269,6 +269,7 @@ struct pipe_sampler_state
unsigned compare_func:3; /** PIPE_FUNC_x */
unsigned normalized_coords:1; /** Are coords normalized to [0,1]? */
unsigned max_anisotropy:6;
+ unsigned seamless_cube_map:1;
float lod_bias; /** LOD/lambda bias */
float min_lod, max_lod; /** LOD clamp range, after bias */
float border_color[4];
diff --git a/src/mesa/state_tracker/st_atom_sampler.c b/src/mesa/state_tracker/st_atom_sampler.c
index 56da010..e3d6cbb 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -201,6 +201,9 @@ update_samplers(struct st_context *st)
= st_compare_func_to_pipe(msamp-CompareFunc);
}
+ sampler-seamless_cube_map =
+ st-ctx-Texture.CubeMapSeamless || msamp-CubeMapSeamless;
+
st-state.num_samplers = su + 1;
/*printf(%s su=%u non-null\n, __FUNCTION__, su);*/
diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index 030bbc7..ad8e6bb 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++
[Mesa-dev] [PATCH 1/3] glx: Check flush DRI extension version at runtime
The DRI driver itself might not have version 3 of the DRI2 flush extension, in which case this would've pointed to out of bounds memory... --- src/glx/dri2_glx.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c index ff48c79..179b7d7 100644 --- a/src/glx/dri2_glx.c +++ b/src/glx/dri2_glx.c @@ -640,7 +640,7 @@ dri2InvalidateBuffers(Display *dpy, XID drawable) struct dri2_drawable *pdp = (struct dri2_drawable *) pdraw; Date: Sun, 5 Sep 2010 19:10:58 + #if __DRI2_FLUSH_VERSION = 3 - if (pdraw psc-f) + if (pdraw psc-f psc-f-base.version = 3 psc-f-invalidate) psc-f-invalidate(pdp-driDrawable); #endif } @@ -663,7 +663,8 @@ dri2_bind_tex_image(Display * dpy, psc = (struct dri2_screen *) base-psc; #if __DRI2_FLUSH_VERSION = 3 - if (!pdp-invalidateAvailable psc-f) + if (!pdp-invalidateAvailable psc-f + psc-f-base.version = 3 psc-f-invalidate) psc-f-invalidate(pdraw-driDrawable); #endif -- 1.7.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] glx: Add teximage vfuncs to drisw
Copied the implementation from dri2_glx.c.
---
src/glx/drisw_glx.c | 51 ---
1 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index c5b1791..81fd188 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -46,8 +46,10 @@ struct drisw_screen
__DRIscreen *driScreen;
__GLXDRIscreen vtable;
- const __DRIcoreExtension *core;
const __DRIswrastExtension *swrast;
+ const __DRIcoreExtension *core;
+
+ const __DRItexBufferExtension *texBuffer;
const __DRIconfig **driver_configs;
void *driver;
@@ -287,6 +289,49 @@ drisw_unbind_context(struct glx_context *context,
struct glx_context *new)
(*psc-core-unbindContext) (pcp-driContext);
}
+static void
+drisw_bind_tex_image(Display * dpy,
+ GLXDrawable drawable,
+ int buffer, const int *attrib_list)
+{
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct drisw_context *pcp = (struct drisw_context *) gc;
+ __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+ struct drisw_drawable *pdraw = (struct drisw_drawable *) base;
+ struct glx_display *dpyPriv = __glXInitialize(dpy);
+ struct drisw_display *pdp =
+ (struct drisw_display *) dpyPriv-dri2Display;
+ struct drisw_screen *psc;
+
+ if (pdraw != NULL) {
+ psc = (struct drisw_screen *) base-psc;
+
+/* FIXME: copied from dri2_glx.c. Can, should drisw do something like this? */
+#if 0 __DRI2_FLUSH_VERSION = 3
+ if (!pdp-invalidateAvailable psc-f)
+psc-f-invalidate(pdraw-driDrawable);
+#endif
+
+ if (psc-texBuffer-base.version = 2
+ psc-texBuffer-setTexBuffer2 != NULL) {
+(*psc-texBuffer-setTexBuffer2) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-base.textureFormat,
+ pdraw-driDrawable);
+ }
+ else {
+(*psc-texBuffer-setTexBuffer) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-driDrawable);
+ }
+ }
+}
+
+static void
+drisw_release_tex_image(Display * dpy, GLXDrawable drawable, int buffer)
+{
+}
+
static const struct glx_context_vtable drisw_context_vtable = {
drisw_destroy_context,
drisw_bind_context,
@@ -294,8 +339,8 @@ static const struct glx_context_vtable
drisw_context_vtable = {
NULL,
NULL,
DRI_glXUseXFont,
- NULL,
- NULL,
+ drisw_bind_tex_image,
+ drisw_release_tex_image,
};
static struct glx_context *
--
1.7.0.4
From 2242a735c1e78f740a054e9b7a40c356b9505377 Mon Sep 17 00:00:00 2001
From: nobled nob...@dreamwidth.org
Date: Sun, 5 Sep 2010 16:14:01 +
Subject: [PATCH 2/4] glx: Add teximage vfuncs to drisw
Copied the implementation from dri2_glx.c.
---
src/glx/drisw_glx.c | 51 ---
1 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index c5b1791..81fd188 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -46,8 +46,10 @@ struct drisw_screen
__DRIscreen *driScreen;
__GLXDRIscreen vtable;
- const __DRIcoreExtension *core;
const __DRIswrastExtension *swrast;
+ const __DRIcoreExtension *core;
+
+ const __DRItexBufferExtension *texBuffer;
const __DRIconfig **driver_configs;
void *driver;
@@ -287,6 +289,49 @@ drisw_unbind_context(struct glx_context *context, struct glx_context *new)
(*psc-core-unbindContext) (pcp-driContext);
}
+static void
+drisw_bind_tex_image(Display * dpy,
+ GLXDrawable drawable,
+ int buffer, const int *attrib_list)
+{
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct drisw_context *pcp = (struct drisw_context *) gc;
+ __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+ struct drisw_drawable *pdraw = (struct drisw_drawable *) base;
+ struct glx_display *dpyPriv = __glXInitialize(dpy);
+ struct drisw_display *pdp =
+ (struct drisw_display *) dpyPriv-dri2Display;
+ struct drisw_screen *psc;
+
+ if (pdraw != NULL) {
+ psc = (struct drisw_screen *) base-psc;
+
+/* FIXME: copied from dri2_glx.c. Can, should drisw do something like this? */
+#if 0 __DRI2_FLUSH_VERSION = 3
+ if (!pdp-invalidateAvailable psc-f)
+ psc-f-invalidate(pdraw-driDrawable);
+#endif
+
+ if (psc-texBuffer-base.version = 2
+ psc-texBuffer-setTexBuffer2 != NULL) {
+ (*psc-texBuffer-setTexBuffer2) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-base.textureFormat,
+ pdraw-driDrawable);
+ }
+ else {
+ (*psc-texBuffer-setTexBuffer) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-driDrawable);
+ }
+ }
+}
+
+static void
+drisw_release_tex_image(Display * dpy, GLXDrawable drawable, int buffer)
+{
+}
+
static const struct
[Mesa-dev] [PATCH 2/3 v2] glx: Add teximage vfuncs to drisw
Copied the implementation from dri2_glx.c.
---
Sorry, accidentally sent an old version that didn't apply and was
missing the release() code that got added between then and now. This
one should work.
src/glx/drisw_glx.c | 77 +--
1 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 5c7f40c..04c68e2 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -46,8 +46,10 @@ struct drisw_screen
__DRIscreen *driScreen;
__GLXDRIscreen vtable;
- const __DRIcoreExtension *core;
const __DRIswrastExtension *swrast;
+ const __DRIcoreExtension *core;
+
+ const __DRItexBufferExtension *texBuffer;
const __DRIconfig **driver_configs;
void *driver;
@@ -287,6 +289,75 @@ drisw_unbind_context(struct glx_context *context,
struct glx_context *new)
driReleaseDrawables(pcp-base);
}
+static void
+drisw_bind_tex_image(Display * dpy,
+ GLXDrawable drawable,
+ int buffer, const int *attrib_list)
+{
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct drisw_context *pcp = (struct drisw_context *) gc;
+ __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+ struct glx_display *dpyPriv = __glXInitialize(dpy);
+ struct drisw_drawable *pdraw = (struct drisw_drawable *) base;
+ struct drisw_display *pdp =
+ (struct drisw_display *) dpyPriv-dri2Display;
+ struct drisw_screen *psc;
+
+ if (pdraw != NULL) {
+ psc = (struct drisw_screen *) base-psc;
+
+ if (!psc-texBuffer)
+ return;
+
+/* FIXME: copied from dri2_glx.c. Can, should drisw do something like this? */
+#if 0 __DRI2_FLUSH_VERSION = 3
+ if (!pdp-invalidateAvailable psc-f
+psc-f-base.version = 3 psc-f-invalidate)
+psc-f-invalidate(pdraw-driDrawable);
+#endif
+
+ if (psc-texBuffer-base.version = 2
+ psc-texBuffer-setTexBuffer2 != NULL) {
+(*psc-texBuffer-setTexBuffer2) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-base.textureFormat,
+ pdraw-driDrawable);
+ }
+ else {
+(*psc-texBuffer-setTexBuffer) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-driDrawable);
+ }
+ }
+}
+
+static void
+drisw_release_tex_image(Display * dpy, GLXDrawable drawable, int buffer)
+{
+#if __DRI_TEX_BUFFER_VERSION = 3
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct dri2_context *pcp = (struct dri2_context *) gc;
+ __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+ struct glx_display *dpyPriv = __glXInitialize(dpy);
+ struct dri2_drawable *pdraw = (struct dri2_drawable *) base;
+ struct dri2_screen *psc;
+
+ if (pdraw != NULL) {
+ psc = (struct dri2_screen *) base-psc;
+
+ if (!psc-texBuffer)
+ return;
+
+ if (psc-texBuffer-base.version = 3
+ psc-texBuffer-releaseTexBuffer != NULL) {
+ (*psc-texBuffer-releaseTexBuffer) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-driDrawable);
+ }
+ }
+#endif
+}
+
static const struct glx_context_vtable drisw_context_vtable = {
drisw_destroy_context,
drisw_bind_context,
@@ -294,8 +365,8 @@ static const struct glx_context_vtable
drisw_context_vtable = {
NULL,
NULL,
DRI_glXUseXFont,
- NULL,
- NULL,
+ drisw_bind_tex_image,
+ drisw_release_tex_image,
};
static struct glx_context *
--
1.7.0.4
From b4ebb03ac6d9d50d9184609a72f16f7343f9ff6b Mon Sep 17 00:00:00 2001
From: nobled nob...@dreamwidth.org
Date: Sun, 5 Sep 2010 16:14:01 +
Subject: [PATCH 2/3] glx: Add teximage vfuncs to drisw
Copied the implementation from dri2_glx.c.
---
src/glx/drisw_glx.c | 77 +--
1 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 5c7f40c..04c68e2 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -46,8 +46,10 @@ struct drisw_screen
__DRIscreen *driScreen;
__GLXDRIscreen vtable;
- const __DRIcoreExtension *core;
const __DRIswrastExtension *swrast;
+ const __DRIcoreExtension *core;
+
+ const __DRItexBufferExtension *texBuffer;
const __DRIconfig **driver_configs;
void *driver;
@@ -287,6 +289,75 @@ drisw_unbind_context(struct glx_context *context, struct glx_context *new)
driReleaseDrawables(pcp-base);
}
+static void
+drisw_bind_tex_image(Display * dpy,
+ GLXDrawable drawable,
+ int buffer, const int *attrib_list)
+{
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct drisw_context *pcp = (struct drisw_context *) gc;
+ __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+ struct
[Mesa-dev] [PATCH 3/3] glx: Enable GLX_EXT_texture_from_pixmap in software
Now if a software DRI driver advertises it, we can use it
in direct-rendering contexts--without this, only the server
took advantage of it for indirect contexts.
This follows up on these commits:
8d789be03430b80e0ba2fef19d56dd0b8e699ea2
c14b4371ed58859d264b7b2581cfedc9cfd8401f
2b64886c817ffa2d86abb9b4a5d79d1e2451
---
Like I commented below, are there any other extensions that it makes
sense to port to software drivers? Would invalidate be generally
useful there?
src/glx/drisw_glx.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index d9f47db..aea853d 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -487,6 +487,20 @@ static const struct glx_screen_vtable
drisw_screen_vtable = {
drisw_create_context
};
+static void
+driswBindExtensions(struct drisw_screen *psc, const __DRIextension
**extensions)
+{
+ int i;
+
+ /* FIXME: Figure out what other extensions can be ported here from dri2. */
+ for (i = 0; extensions[i]; i++) {
+ if ((strcmp(extensions[i]-name, __DRI_TEX_BUFFER) == 0)) {
+psc-texBuffer = (__DRItexBufferExtension *) extensions[i];
+__glXEnableDirectExtension(psc-base, GLX_EXT_texture_from_pixmap);
+ }
+ }
+}
+
static struct glx_screen *
driCreateScreen(int screen, struct glx_display *priv)
{
@@ -536,6 +550,9 @@ driCreateScreen(int screen, struct glx_display *priv)
goto handle_error;
}
+ extensions = psc-core-getExtensions(psc-driScreen);
+ driswBindExtensions(psc, extensions);
+
psc-base.configs =
driConvertConfigs(psc-core, psc-base.configs, driver_configs);
psc-base.visuals =
--
1.7.0.4
From f8827527efcd0c6cef8f42ac9ebb74a48f092006 Mon Sep 17 00:00:00 2001
From: nobled nob...@dreamwidth.org
Date: Sun, 5 Sep 2010 16:21:03 +
Subject: [PATCH 3/3] glx: Enable GLX_EXT_texture_from_pixmap in software
Now if a software DRI driver advertises it, we can use it
in direct-rendering contexts--without this, only the server
took advantage of it for indirect contexts.
This follows up on these commits:
8d789be03430b80e0ba2fef19d56dd0b8e699ea2
c14b4371ed58859d264b7b2581cfedc9cfd8401f
2b64886c817ffa2d86abb9b4a5d79d1e2451
---
src/glx/drisw_glx.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index d9f47db..aea853d 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -487,6 +487,20 @@ static const struct glx_screen_vtable drisw_screen_vtable = {
drisw_create_context
};
+static void
+driswBindExtensions(struct drisw_screen *psc, const __DRIextension **extensions)
+{
+ int i;
+
+ /* FIXME: Figure out what other extensions can be ported here from dri2. */
+ for (i = 0; extensions[i]; i++) {
+ if ((strcmp(extensions[i]-name, __DRI_TEX_BUFFER) == 0)) {
+ psc-texBuffer = (__DRItexBufferExtension *) extensions[i];
+ __glXEnableDirectExtension(psc-base, GLX_EXT_texture_from_pixmap);
+ }
+ }
+}
+
static struct glx_screen *
driCreateScreen(int screen, struct glx_display *priv)
{
@@ -536,6 +550,9 @@ driCreateScreen(int screen, struct glx_display *priv)
goto handle_error;
}
+ extensions = psc-core-getExtensions(psc-driScreen);
+ driswBindExtensions(psc, extensions);
+
psc-base.configs =
driConvertConfigs(psc-core, psc-base.configs, driver_configs);
psc-base.visuals =
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
2011/4/27 Christian König deathsim...@vodafone.de Regarding the not working idct on nvidia hardware I would guess that we use something that the driver currently doesn't supports, like multiple render targets, disabled opengl rasterisation rules, unsupported intermediate buffer format or something else. Hi Christian, I found out the other day that nv50 doesn't support disabled GL rasterization rules, and doesn't plan to. Could iDCT be changed to work with GL rasterization rules enabled, or is there a reason that it can't or shouldn't use them? Regards, Bryan. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
