[Mesa-dev] [Bug 39515] FTBFS: libEGL depends on libgbm, but libEGL builds first
https://bugs.freedesktop.org/show_bug.cgi?id=39515 --- Comment #1 from Benjamin Franzke 2011-07-25 00:52:24 PDT --- Thanks, should be fixes by 42cdf4074e0f7d561b03a86255fa8f916f906bf6. -- 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 39307] vdpau advertises support for MPEG1, but it's unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=39307 --- Comment #3 from almos 2011-07-25 01:46:15 PDT --- (In reply to comment #2) > Mhm, Emeric you patch looks quite right to me. > > But honestly, I couldn't find an MPEG1 to test it.Emeric you patch looks quite > right to me. > > But honestly, I couldn't find an MPEG1 to test it. > > So could anybody please confirm that it's right so we can push it? I have some MPEG1 videos, but I cannot test due to #39308 and #39309. -- 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] [PATCH] g3dvl: check for existence of header/libs
Christian König wrote: Hi, sorry for the late reply, have been in Canada on a team meeting. Did you got it working Andy or do you need some more help? It's OK, now thanks. I have started setting LDFLAGS as Dan suggested. I think the overall situation with finding libraries in the mesa makefiles is not the best, but that's not prio 1 at the moment. It should work with a standard installation (pkgconf based), but I don't think that it will work if you try something unusual, like cross compiling or having multiple versions of a lib installed in different directories... Yea - I usually disable llvm because it doesn't use pkgconf, but it usually seems to work apart from that. vdpau does have it's own .pc and my PKG_CONFIG_PATH is set - it's just that it wasn't checked for. For me it's probably safer using LDFLAGS and CPPFLAGS anyway as I have other things in abnormal places. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39307] vdpau advertises support for MPEG1, but it's unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=39307
--- Comment #4 from Andy Furniss 2011-07-25
05:00:05 PDT ---
(In reply to comment #2)
> Mhm, Emeric you patch looks quite right to me.
>
> But honestly, I couldn't find an MPEG1 to test it.Emeric you patch looks quite
> right to me.
>
> But honestly, I couldn't find an MPEG1 to test it.
http://www.linux-video.net/Samples/Mpeg1/
>
> So could anybody please confirm that it's right so we can push it?
Works OK for me on rv790 (OK meaning rendering with same issues as mpeg2), only
tested the space shuttle vid from above.
Had to edit by hand as master seems to have changed somewhat - for reference
here's the diff I tested with.
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index 269c7a4..931d62b 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -161,7 +161,7 @@ vlVdpDecoderGetParameters(VdpDecoder decoder,
}
static VdpStatus
-vlVdpDecoderRenderMpeg2(struct pipe_video_decoder *decoder,
+vlVdpDecoderRenderMpeg12(struct pipe_video_decoder *decoder,
struct pipe_video_decode_buffer *buffer,
struct pipe_video_buffer *target,
VdpPictureInfoMPEG1Or2 *picture_info,
@@ -256,11 +256,12 @@ vlVdpDecoderRender(VdpDecoder decoder,
// TODO: Right now only mpeg2 is supported.
switch (vldecoder->decoder->profile) {
+ case PIPE_VIDEO_PROFILE_MPEG1:
case PIPE_VIDEO_PROFILE_MPEG2_SIMPLE:
case PIPE_VIDEO_PROFILE_MPEG2_MAIN:
++vldecoder->cur_buffer;
vldecoder->cur_buffer %= VL_NUM_DECODE_BUFFERS;
- return vlVdpDecoderRenderMpeg2(vldecoder->decoder,
+ return vlVdpDecoderRenderMpeg12(vldecoder->decoder,
vldecoder->buffer[vldecoder->cur_buffer],
vlsurf->video_buffer,
(VdpPictureInfoMPEG1Or2 *)picture_info,
--
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] [PATCH 1/4] st/mesa: determine Const.MaxSamples in init_extensions
This only checks power of 2 sample counts for now, but maybe we would
like to probe the values in between too ...
nv50 for example can store 12 "coverage samples" in a depth surface, but
they have to be used in a hardware specific way together with
multisampled colour surfaces (which are always power of 2) which can
presently not be done through the gallium interface.
>From b35a1ce7248237ac0cf4209eb8703d13c380ff5a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Sat, 23 Jul 2011 00:55:20 +0200
Subject: [PATCH 3/6] st/mesa: determine Const.MaxSamples in init_extensions
---
src/mesa/state_tracker/st_extensions.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 99b231d..391ff1b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -219,6 +219,7 @@ void st_init_extensions(struct st_context *st)
{
struct pipe_screen *screen = st->pipe->screen;
struct gl_context *ctx = st->ctx;
+ int i;
/*
* Extensions that are supported by all Gallium drivers:
@@ -596,6 +597,14 @@ void st_init_extensions(struct st_context *st)
ctx->Extensions.EXT_packed_float = GL_TRUE;
}
+ /* Maximum sample count. */
+ for (i = 1; i <= 16; i <<= 1)
+ if (!screen->is_format_supported(screen, PIPE_FORMAT_B8G8R8A8_UNORM,
+ PIPE_TEXTURE_2D, i << 1,
+ PIPE_BIND_RENDER_TARGET))
+ break;
+ ctx->Const.MaxSamples = i;
+
if (screen->get_param(screen, PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE)) {
ctx->Extensions.ARB_seamless_cube_map = GL_TRUE;
ctx->Extensions.AMD_seamless_cubemap_per_texture = GL_TRUE;
--
1.7.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving only depth or only
stencil of a combined buffer is possible as well.
Copying from FBO to a window system buffer requires a vertical
so the yflip parameter was added.
The y-flip parameter could be left out if pipe_box was changed to
contain signed width/height or x0,y0,x1,y1 instead.
This might benefit other methods, such as resource_copy_region, where
some hw can easily do a backwards copy (yflip).
>From cc990d3a7a96c3b04939d21cba001d988ce43327 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 25 Jul 2011 14:11:38 +0200
Subject: [PATCH 4/6] gallium: extend resource_resolve to accommodate
BlitFramebuffer
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving only depth or only
stencil of a combined buffer is possible as well.
Copying from FBO to a window system buffer requires a vertical
so the yflip parameter was added.
Any kind of fallback instigated by a state tracker involving
temporary storage would be highly undesirable.
---
src/gallium/include/pipe/p_context.h | 20 +++-
src/gallium/include/pipe/p_defines.h |3 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index 3f6d90d..9376cdd 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -255,8 +255,7 @@ struct pipe_context {
/**
* Copy a block of pixels from one resource to another.
-* The resource must be of the same format.
-* Resources with nr_samples > 1 are not allowed.
+* The resources must be of the same format and sample count.
*/
void (*resource_copy_region)(struct pipe_context *pipe,
struct pipe_resource *dst,
@@ -267,14 +266,17 @@ struct pipe_context {
const struct pipe_box *src_box);
/**
-* Resolve a multisampled resource into a non-multisampled one.
-* Source and destination must have the same size and same format.
+* Resolve a multisampled resource into a non-multisampled one,
+* or vice versa (in the latter case, values are just replicated).
+* Source and destination must have the same format.
+* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
+* The mipmap level of the multisampled resource will be 0.
*/
- void (*resource_resolve)(struct pipe_context *pipe,
-struct pipe_resource *dst,
-unsigned dst_layer,
-struct pipe_resource *src,
-unsigned src_layer);
+ void (*resource_resolve)(struct pipe_context *pipe, unsigned mask,
+struct pipe_resource *dst, unsigned dst_level,
+unsigned dstx, unsigned dsty, unsigned dst_layer,
+struct pipe_resource *src, unsigned src_level,
+const struct pipe_box *src_box, boolean yflip);
/*@}*/
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 79b8969..080e6b9 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -99,6 +99,9 @@ enum pipe_error {
#define PIPE_MASK_B 0x4
#define PIPE_MASK_A 0x8
#define PIPE_MASK_RGBA 0xf
+#define PIPE_MASK_Z 0x10
+#define PIPE_MASK_S 0x20
+#define PIPE_MASK_ZS 0x30
/**
--
1.7.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4]: st/mesa: implement multisample resolve via BlitFramebuffer
...
>From 2d57a1ee06b9d370bae6f9b8d8e59de180d2584a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 25 Jul 2011 14:14:01 +0200
Subject: [PATCH 5/6] st/mesa: implement multisample resolve via BlitFramebuffer
---
src/gallium/auxiliary/util/u_box.h | 25 +
src/mesa/state_tracker/st_cb_blit.c | 95 +++
2 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_box.h
b/src/gallium/auxiliary/util/u_box.h
index 0b28d0f..3eb842e 100644
--- a/src/gallium/auxiliary/util/u_box.h
+++ b/src/gallium/auxiliary/util/u_box.h
@@ -77,4 +77,29 @@ void u_box_3d( unsigned x,
box->depth = d;
}
+/* Returns whether vertical flip is required. */
+static INLINE
+boolean u_box_2d_corners(unsigned x0, unsigned y0,
+ unsigned x1, unsigned y1, struct pipe_box *box)
+{
+ boolean yflip = FALSE;
+
+ if (y0 > y1) {
+ unsigned bt = y1;
+ y1 = y0;
+ y0 = bt;
+ yflip = TRUE;
+ }
+ assert(x1 >= x0);
+
+ box->x = x0;
+ box->y = y0;
+ box->z = 0;
+ box->width = x1 - x0;
+ box->height = y1 - y0;
+ box->depth = 1;
+
+ return yflip;
+}
+
#endif
diff --git a/src/mesa/state_tracker/st_cb_blit.c
b/src/mesa/state_tracker/st_cb_blit.c
index 416be19..57f8729 100644
--- a/src/mesa/state_tracker/st_cb_blit.c
+++ b/src/mesa/state_tracker/st_cb_blit.c
@@ -42,6 +42,7 @@
#include "st_atom.h"
#include "util/u_blit.h"
+#include "util/u_box.h"
void
@@ -62,6 +63,85 @@ st_destroy_blit(struct st_context *st)
#if FEATURE_EXT_framebuffer_blit
static void
+st_BlitFramebuffer_resolve(struct gl_context *ctx, GLbitfield mask,
+ GLint dstX, GLint dstY, struct pipe_box *box,
+ boolean yflip)
+{
+ const GLbitfield depthStencil = GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT;
+
+ struct st_context *st = st_context(ctx);
+
+ struct st_renderbuffer *srcRb, *dstRb;
+
+ if (mask & GL_COLOR_BUFFER_BIT) {
+ srcRb = st_renderbuffer(ctx->ReadBuffer->_ColorReadBuffer);
+ dstRb = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
+
+ box->z = srcRb->surface->u.tex.first_layer;
+
+ st->pipe->resource_resolve(st->pipe, PIPE_MASK_RGBA,
+ dstRb->texture,
+ dstRb->surface->u.tex.level, dstX, dstY,
+ dstRb->surface->u.tex.first_layer,
+ srcRb->texture,
+ srcRb->surface->u.tex.level, box, yflip);
+ }
+
+ if (mask & depthStencil) {
+ struct gl_renderbuffer_attachment *srcDepth, *srcStencil;
+ struct gl_renderbuffer_attachment *dstDepth, *dstStencil;
+
+ srcDepth = &ctx->ReadBuffer->Attachment[BUFFER_DEPTH];
+ dstDepth = &ctx->DrawBuffer->Attachment[BUFFER_DEPTH];
+ srcStencil = &ctx->ReadBuffer->Attachment[BUFFER_STENCIL];
+ dstStencil = &ctx->DrawBuffer->Attachment[BUFFER_STENCIL];
+
+ const boolean combined =
+ st_is_depth_stencil_combined(srcDepth, srcStencil) &&
+ st_is_depth_stencil_combined(dstDepth, dstStencil);
+
+ if ((mask & GL_DEPTH_BUFFER_BIT) || combined) {
+ /* resolve depth and, if combined and requested, stencil as well */
+ unsigned pipeMask = 0;
+
+ srcRb = st_renderbuffer(srcDepth->Renderbuffer);
+ dstRb = st_renderbuffer(dstDepth->Renderbuffer);
+
+ box->z = srcRb->surface->u.tex.first_layer;
+
+ if (mask & GL_DEPTH_BUFFER_BIT)
+pipeMask |= PIPE_MASK_Z;
+ if ((mask & GL_STENCIL_BUFFER_BIT) && combined) {
+mask = 0;
+pipeMask |= PIPE_MASK_S;
+ }
+
+ st->pipe->resource_resolve(st->pipe, pipeMask,
+dstRb->texture,
+dstRb->surface->u.tex.level, dstX, dstY,
+dstRb->surface->u.tex.first_layer,
+srcRb->texture,
+srcRb->surface->u.tex.level, box, yflip);
+ }
+
+ if (mask & GL_STENCIL_BUFFER_BIT) {
+ /* resolve separate stencil buffer */
+ srcRb = st_renderbuffer(srcStencil->Renderbuffer);
+ dstRb = st_renderbuffer(dstStencil->Renderbuffer);
+
+ box->z = srcRb->surface->u.tex.first_layer;
+
+ st->pipe->resource_resolve(st->pipe, PIPE_MASK_S,
+dstRb->texture,
+dstRb->surface->u.tex.level, dstX, dstY,
+dstRb->surface->u.tex.first_layer,
+srcRb->texture,
+srcRb->surface->u.tex.level, box, yflip);
+ }
+ }
+}
+
+static void
st_BlitFramebuffer(struct gl_context *ctx,
GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1,
GLint dstX0, GLint dstY0, GLint dstX1,
[Mesa-dev] [PATH 4/4]: nv50: implement resource_resolve with custom blit
...
>From 3a63ebc31e91d7bf927c55c7fca9fe190984b16c Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 25 Jul 2011 14:21:29 +0200
Subject: [PATCH 6/6] nv50: implement resource_resolve with custom blit
---
src/gallium/drivers/nv50/nv50_context.h|3 +-
src/gallium/drivers/nv50/nv50_formats.c|4 +-
src/gallium/drivers/nv50/nv50_screen.c |3 +
src/gallium/drivers/nv50/nv50_screen.h |6 +
src/gallium/drivers/nv50/nv50_shader_state.c | 11 +-
src/gallium/drivers/nv50/nv50_state_validate.c |4 +-
src/gallium/drivers/nv50/nv50_surface.c| 532 +++-
src/gallium/drivers/nv50/nv50_vbo.c|2 +-
8 files changed, 554 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_context.h
b/src/gallium/drivers/nv50/nv50_context.h
index c1226d5..284db69 100644
--- a/src/gallium/drivers/nv50/nv50_context.h
+++ b/src/gallium/drivers/nv50/nv50_context.h
@@ -171,7 +171,8 @@ void nv50_validate_derived_rs(struct nv50_context *);
extern void nv50_init_state_functions(struct nv50_context *);
/* nv50_state_validate.c */
-extern boolean nv50_state_validate(struct nv50_context *);
+/* @words: check for space before emitting relocs */
+extern boolean nv50_state_validate(struct nv50_context *, unsigned words);
/* nv50_surface.c */
extern void nv50_clear(struct pipe_context *, unsigned buffers,
diff --git a/src/gallium/drivers/nv50/nv50_formats.c
b/src/gallium/drivers/nv50/nv50_formats.c
index be43147..34502d0 100644
--- a/src/gallium/drivers/nv50/nv50_formats.c
+++ b/src/gallium/drivers/nv50/nv50_formats.c
@@ -116,7 +116,7 @@ const struct nv50_format
nv50_format_table[PIPE_FORMAT_COUNT] =
SAMPLER_VIEW | DEPTH_STENCIL },
[PIPE_FORMAT_Z24_UNORM_S8_USCALED] = { NV50_ZETA_FORMAT_Z24_S8_UNORM,
-B_(C0, C0, C0, ONE_FLOAT, UNORM, UINT, UINT, UINT, Z24_S8, 0),
+B_(C0, C1, C0, ONE_FLOAT, UNORM, UINT, UINT, UINT, Z24_S8, 0),
SAMPLER_VIEW | DEPTH_STENCIL },
[PIPE_FORMAT_Z24X8_UNORM] = { NV50_ZETA_FORMAT_Z24_X8_UNORM,
@@ -124,7 +124,7 @@ const struct nv50_format
nv50_format_table[PIPE_FORMAT_COUNT] =
SAMPLER_VIEW | DEPTH_STENCIL },
[PIPE_FORMAT_S8_USCALED_Z24_UNORM] = { NV50_ZETA_FORMAT_S8_Z24_UNORM,
-B_(C1, C1, C1, ONE_FLOAT, UINT, UNORM, UINT, UINT, S8_Z24, 0),
+B_(C1, C0, C1, ONE_FLOAT, UINT, UNORM, UINT, UINT, S8_Z24, 0),
SAMPLER_VIEW | DEPTH_STENCIL },
[PIPE_FORMAT_Z32_FLOAT] = { NV50_ZETA_FORMAT_Z32_FLOAT,
diff --git a/src/gallium/drivers/nv50/nv50_screen.c
b/src/gallium/drivers/nv50/nv50_screen.c
index 4139b85..eb08a42 100644
--- a/src/gallium/drivers/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nv50/nv50_screen.c
@@ -604,6 +604,9 @@ nv50_screen_create(struct pipe_winsys *ws, struct
nouveau_device *dev)
screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, 0xfe0);
+ if (!nv50_blitctx_create(screen))
+ goto fail;
+
nouveau_fence_new(&screen->base, &screen->base.fence.current, FALSE);
return pscreen;
diff --git a/src/gallium/drivers/nv50/nv50_screen.h
b/src/gallium/drivers/nv50/nv50_screen.h
index 64ad209..315ca80 100644
--- a/src/gallium/drivers/nv50/nv50_screen.h
+++ b/src/gallium/drivers/nv50/nv50_screen.h
@@ -21,6 +21,8 @@ struct nv50_context;
#define NV50_SCREEN_RESIDENT_BO_COUNT 5
+struct nv50_blitctx;
+
struct nv50_screen {
struct nouveau_screen base;
struct nouveau_winsys *nvws;
@@ -39,6 +41,8 @@ struct nv50_screen {
struct nouveau_resource *gp_code_heap;
struct nouveau_resource *fp_code_heap;
+ struct nv50_blitctx *blitctx;
+
struct {
void **entries;
int next;
@@ -71,6 +75,8 @@ nv50_screen(struct pipe_screen *screen)
return (struct nv50_screen *)screen;
}
+boolean nv50_blitctx_create(struct nv50_screen *);
+
void nv50_screen_make_buffers_resident(struct nv50_screen *);
int nv50_screen_tic_alloc(struct nv50_screen *, void *);
diff --git a/src/gallium/drivers/nv50/nv50_shader_state.c
b/src/gallium/drivers/nv50/nv50_shader_state.c
index e5b10c3..d73f7c7 100644
--- a/src/gallium/drivers/nv50/nv50_shader_state.c
+++ b/src/gallium/drivers/nv50/nv50_shader_state.c
@@ -130,13 +130,14 @@ nv50_program_validate(struct nv50_context *nv50, struct
nv50_program *prog)
int ret;
unsigned size;
- if (prog->translated)
+ if (!prog->translated) {
+ prog->translated = nv50_program_translate(prog);
+ if (!prog->translated)
+ return FALSE;
+ } else
+ if (prog->res)
return TRUE;
- prog->translated = nv50_program_translate(prog);
- if (!prog->translated)
- return FALSE;
-
if (prog->type == PIPE_SHADER_FRAGMENT) heap = nv50->screen->fp_code_heap;
else
if (prog->type == PIPE_SHADER_GEOMETRY) heap = nv50->screen->gp_code_heap;
diff --git a/src/gallium/drivers/nv50/nv50_state_validate.c
b/src/gallium/drivers/nv50/nv50_state_validate.c
index 8b0b08f..44f2d25 100644
--- a/src/gallium/drivers/nv50/nv50_state_validat
[Mesa-dev] [Bug 39527] New: 3D Driving-School - missing textures
https://bugs.freedesktop.org/show_bug.cgi?id=39527 Summary: 3D Driving-School - missing textures Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: d.ok...@gmail.com Created an attachment (id=49525) --> (https://bugs.freedesktop.org/attachment.cgi?id=49525) grapthic_bug.jpeg All textures are grey. x11-libs/libtxc_dxtn - 1.0.1 on both computers Tested on 64 bit -> 32bit emul -> r300/r300g (RS690) 32 bit -> nvfx (NV44A) nvfx compiled with debug option gives me this: state_tracker/st_atom_framebuffer.c:163:update_framebuffer_state: Assertion `framebuffer->cbufs[i]->texture->bind & (1 << 1)' I think it maybe related. I can test on 32 bit computer with nvfx, but not against 64bit (binary mesa package pack) -- 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 39527] 3D Driving-School - missing textures
https://bugs.freedesktop.org/show_bug.cgi?id=39527 --- Comment #1 from Marek Olšák 2011-07-25 07:00:20 PDT --- Please attach an apitrace file. Apitrace can record and replay opengl commands. You can get it here: https://github.com/apitrace/apitrace -- 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] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 07/25/2011 02:47 PM, Christoph Bumiller wrote:
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, therefore location and size parameters are needed.
>
> The mask parameter was added because resolving only depth or only
> stencil of a combined buffer is possible as well.
>
> Copying from FBO to a window system buffer requires a vertical
> so the yflip parameter was added.
>
> The y-flip parameter could be left out if pipe_box was changed to
> contain signed width/height or x0,y0,x1,y1 instead.
> This might benefit other methods, such as resource_copy_region, where
> some hw can easily do a backwards copy (yflip).
>
>
Actually, some modifications to the original change:
1. Let's not make it go both directions (ms -> ss and ss -> ms) but just
(ms -> ss) as it was originally.
The other direction can always be done with the usual util_blit_pixels path.
2. I'd like to add an auxiliary resource for multisample modes that
store additional data in another buffer, like nv's coverage sampling.
>From 2323041992f60830d63b3b88ce64ef037744b803 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 25 Jul 2011 17:30:40 +0200
Subject: [PATCH] gallium: different definition of resource_resolve function
---
src/gallium/include/pipe/p_context.h | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index 9376cdd..e038e12 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -266,16 +266,19 @@ struct pipe_context {
const struct pipe_box *src_box);
/**
-* Resolve a multisampled resource into a non-multisampled one,
-* or vice versa (in the latter case, values are just replicated).
+* Resolve a multisampled resource into a non-multisampled one.
+* The multisampled resource cannot have mipmaps.
* Source and destination must have the same format.
* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
-* The mipmap level of the multisampled resource will be 0.
+* The auxiliary resource (separate sample data) may be NULL.
*/
void (*resource_resolve)(struct pipe_context *pipe, unsigned mask,
-struct pipe_resource *dst, unsigned dst_level,
-unsigned dstx, unsigned dsty, unsigned dst_layer,
-struct pipe_resource *src, unsigned src_level,
+struct pipe_resource *dst,
+unsigned dst_level,
+unsigned dstx, unsigned dsty, unsigned dstz,
+struct pipe_resource *aux,
+unsigned aux_level, unsigned aux_layer,
+struct pipe_resource *src,
const struct pipe_box *src_box, boolean yflip);
/*@}*/
--
1.7.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39515] FTBFS: libEGL depends on libgbm, but libEGL builds first
https://bugs.freedesktop.org/show_bug.cgi?id=39515 Dave Witbrodt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Dave Witbrodt 2011-07-25 08:58:30 PDT --- Works great! Built, packaged, and installed perfectly. Tested with 'glxinfo' first, then a few 3D apps: all is well. Thanks for the quick response. -- 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] r300 problems in the 7.10.3 and 7.11 tarballs
Can we please get a 7.10.4 release with this fixed? It's not a bug in libarchive; you just get lucky that gnutar doesn't complain (which I think *is* a bug in gnutar). Some users are running into problems using gnutar with this archive, so that's not really a great fallback either: https://trac.macports.org/ticket/30058 There doesn't seem to be a good solution (I don't count zip) other than rolling a new tarball (which will be nice to collect the rest of the 7.10 branch patches anyway): $ tar -tvjf MesaLib-7.10.3.tar.bz2 | grep r300/compiler/memory_pool.c -rw-rw-r-- 0 idridr 2671 May 20 01:31 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c hrw-rw-r-- 0 idridr 0 May 20 01:31 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c The issue partly exists in 7.11-rc2, but we don't see it because it's just including the file twice rather than including a symlink to itself: $ tar -tjvf MesaLib-7.11-rc2.tar.bz2 | grep memory_pool.c -rw-rw-r-- 0 idridr 2671 Jul 8 18:37 Mesa-7.11-rc2/src/mesa/drivers/dri/r300/compiler/memory_pool.c -rw-rw-r-- 0 idridr 2671 Jul 8 18:37 Mesa-7.11-rc2/src/mesa/drivers/dri/r300/compiler/memory_pool.c On Jun 17, 2011, at 9:41 AM, Andreas Radke wrote: > If you'd check the output of the tar check you'd see files linked to > itself that seems to break it. That wasn't the case in the releases > before. It's all related to r300. > > There's probably something wrong with links pointing to the source file. > > BTW: I've used the 'zip' source to build our package. gz+bz2 are broken for > me. > > -Andy > > [andyrtr@workstation64 ~]$ LANG=C tar -tvf > ~/arch64/sources/MesaLib-7.10.3.tar.bz2 | grep ^h | sed -e "s: > Mesa-7.10.3/src/mesa/drivers/dri/: :g" > hrw-rw-r-- idr/idr 0 2011-05-20 10:31 r300/compiler/memory_pool.c > link to r300/compiler/memory_pool.c > hrw-r--r-- idr/idr 0 2010-10-05 18:56 r300/compiler/memory_pool.h > link to r300/compiler/memory_pool.h > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 r300/compiler/r300_fragprog.c > link to r300/compiler/r300_fragprog.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/r300_fragprog_emit.c link to r300/compiler/r300_fragprog_emit.c > hrw-r--r-- idr/idr 0 2010-10-19 19:58 r300/compiler/r300_fragprog.h > link to r300/compiler/r300_fragprog.h > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/r300_fragprog_swizzle.c link to > r300/compiler/r300_fragprog_swizzle.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/r300_fragprog_swizzle.h link to > r300/compiler/r300_fragprog_swizzle.h > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 r300/compiler/r3xx_fragprog.c > link to r300/compiler/r3xx_fragprog.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 r300/compiler/r3xx_vertprog.c > link to r300/compiler/r3xx_vertprog.c > hrw-r--r-- idr/idr 0 2010-10-19 19:58 > r300/compiler/r3xx_vertprog_dump.c link to r300/compiler/r3xx_vertprog_dump.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 r300/compiler/r500_fragprog.c > link to r300/compiler/r500_fragprog.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/r500_fragprog_emit.c link to r300/compiler/r500_fragprog_emit.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 r300/compiler/r500_fragprog.h > link to r300/compiler/r500_fragprog.h > hrw-r--r-- idr/idr 0 2010-12-14 22:43 r300/compiler/radeon_code.c > link to r300/compiler/radeon_code.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 r300/compiler/radeon_code.h > link to r300/compiler/radeon_code.h > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_compiler.c link to r300/compiler/radeon_compiler.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_compiler.h link to r300/compiler/radeon_compiler.h > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_compiler_util.c link to > r300/compiler/radeon_compiler_util.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_compiler_util.h link to > r300/compiler/radeon_compiler_util.h > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_dataflow.c link to r300/compiler/radeon_dataflow.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_dataflow_deadcode.c link to > r300/compiler/radeon_dataflow_deadcode.c > hrw-rw-r-- idr/idr 0 2011-05-20 10:33 > r300/compiler/radeon_dataflow.h link to r300/compiler/radeon_dataflow.h > hrw-r--r-- idr/idr 0 2011-01-02 23:58 > r300/compiler/radeon_dataflow_swizzles.c link to > r300/compiler/radeon_dataflow_swizzles.c > hrw-r--r-- idr/idr 0 2010-12-14 22:43 > r300/compiler/radeon_emulate_branches.c link to > r300/compiler/radeon_emulate_branches.c > hrw-r--r-- idr/idr 0 2010-10-19 19:58 > r300/compiler/
Re: [Mesa-dev] [PATCH 1/4] st/mesa: determine Const.MaxSamples in init_extensions
> This only checks power of 2 sample counts for now, but maybe we would > like to probe the values in between too ... Looks good to me. I don't think anyone ever supported odd sample counts (and no quincunx doesn't count...) though pre-r600 radeons supported 2,4,6. In any case if someone wants to implement this on radeon this can still be changed. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39307] vdpau advertises support for MPEG1, but it's unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=39307 Christian König changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Christian König 2011-07-25 10:29:58 PDT --- I can confirm that with this patch mpeg1 seems to work fine for most of the videos, but on some there are some major mc artefacts. That doesn't happen with XvMC, so it seems to be a bug inside the bitstream decoder. It's a surprise that this works anyway, I just copied over the code from xine and have never tested it. I pushed the patch anyway, so I think we can close the bug now. -- 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] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, therefore location and size parameters are needed.
>
> The mask parameter was added because resolving only depth or only
> stencil of a combined buffer is possible as well.
>
> Copying from FBO to a window system buffer requires a vertical
> so the yflip parameter was added.
>
> The y-flip parameter could be left out if pipe_box was changed to
> contain signed width/height or x0,y0,x1,y1 instead.
> This might benefit other methods, such as resource_copy_region, where
> some hw can easily do a backwards copy (yflip).
Hmm I'm not sure I like these interface changes too much. Individual comments
below.
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index 3f6d90d..9376cdd 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -255,8 +255,7 @@ struct pipe_context {
>
> /**
> * Copy a block of pixels from one resource to another.
> -* The resource must be of the same format.
> -* Resources with nr_samples > 1 are not allowed.
> +* The resources must be of the same format and sample count.
> */
> void (*resource_copy_region)(struct pipe_context *pipe,
> struct pipe_resource *dst,
I think the idea to restrict this to 1 sample was to keep it simple. I'm not
sure hw can always easily do this, depending on how it is implemented
(especially because there are regions involved). Might be ok though.
> @@ -267,14 +266,17 @@ struct pipe_context {
> const struct pipe_box *src_box);
>
> /**
> -* Resolve a multisampled resource into a non-multisampled one.
> -* Source and destination must have the same size and same format.
> +* Resolve a multisampled resource into a non-multisampled one,
> +* or vice versa (in the latter case, values are just replicated).
> +* Source and destination must have the same format.
> +* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
> +* The mipmap level of the multisampled resource will be 0.
> */
> - void (*resource_resolve)(struct pipe_context *pipe,
> -struct pipe_resource *dst,
> -unsigned dst_layer,
> -struct pipe_resource *src,
> -unsigned src_layer);
> + void (*resource_resolve)(struct pipe_context *pipe, unsigned mask,
> +struct pipe_resource *dst, unsigned dst_level,
> +unsigned dstx, unsigned dsty, unsigned dst_layer,
> +struct pipe_resource *src, unsigned src_level,
> +const struct pipe_box *src_box, boolean yflip);
This function was inspired by d3d10 and the wide variety of possible
implementations.
You cannot resolve depth and stencil buffers in d3d10/11 and I'm not convinced
it even makes a whole lot of sense (especially for the stencil buffer). Some hw
will potentially be unable to do this (I don't know how deferred renderers
would do that, for example).
Also, allowing regions might also be very difficult to do for some hardware,
and yes glBlitFramebuffer allows this but I'm not sure it's really worth having
this in the interface - I doubt anyone ever will use this anyway, so it would
be nice if we could keep that out of drivers. Just doing another copy for the
odd testcase trying this seems ok to me.
For the same reason I don't like the y-flip very much. I see though how that
could be very useful. I guess drivers not able to do this natively could just
do the copy themselves (ok they could do that with the regions too).
Frankly glBlitFrameBuffer can do a lot of things and I'm not sure it makes a
lot of sense to cram all that functionality into resource_resolve. Though if
other driver writers agree I could be convinced.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl/gallium: fix build without softpipe and llvmpipe
Signed-off-by: Tobias Droste Acked-by: Jakob Bornecrantz Reviewed-by: Marek Olšák --- src/gallium/targets/egl-static/Makefile | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/gallium/targets/egl-static/Makefile b/src/gallium/targets/egl-static/Makefile index 69e7eec..5b7b330 100644 --- a/src/gallium/targets/egl-static/Makefile +++ b/src/gallium/targets/egl-static/Makefile @@ -141,10 +141,18 @@ egl_LIBS += \ $(TOP)/src/gallium/drivers/svga/libsvga.a endif -# swrast +# softpipe +ifneq ($(findstring softpipe,$(GALLIUM_DRIVERS_DIRS)),) egl_CPPFLAGS += -DGALLIUM_SOFTPIPE -DGALLIUM_RBUG -DGALLIUM_TRACE egl_LIBS += $(TOP)/src/gallium/drivers/softpipe/libsoftpipe.a egl_SYS += -lm +endif + +# llvmpipe +ifneq ($(findstring llvmpipe,$(GALLIUM_DRIVERS_DIRS)),) +egl_CPPFLAGS += -DGALLIUM_LLVMPIPE +egl_LIBS += $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a +endif # sort to remove duplicates egl_CPPFLAGS := $(sort $(egl_CPPFLAGS)) @@ -158,8 +166,6 @@ st_GL_SYS := -lm -lpthread $(DLOPEN_LIBS) # LLVM ifeq ($(MESA_LLVM),1) -egl_CPPFLAGS += -DGALLIUM_LLVMPIPE -egl_LIBS += $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a egl_SYS += $(LLVM_LIBS) LDFLAGS += $(LLVM_LDFLAGS) -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
>> Resolve via glBlitFramebuffer allows resolving a sub-region of a
>> renderbuffer to a different location in any mipmap level of some
>> other texture, therefore location and size parameters are needed.
>>
>> The mask parameter was added because resolving only depth or only
>> stencil of a combined buffer is possible as well.
>>
>> Copying from FBO to a window system buffer requires a vertical
>> so the yflip parameter was added.
>>
>> The y-flip parameter could be left out if pipe_box was changed to
>> contain signed width/height or x0,y0,x1,y1 instead.
>> This might benefit other methods, such as resource_copy_region, where
>> some hw can easily do a backwards copy (yflip).
>
> Hmm I'm not sure I like these interface changes too much. Individual comments
> below.
>
>
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index 3f6d90d..9376cdd 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -255,8 +255,7 @@ struct pipe_context {
>>
>> /**
>> * Copy a block of pixels from one resource to another.
>> -* The resource must be of the same format.
>> -* Resources with nr_samples > 1 are not allowed.
>> +* The resources must be of the same format and sample count.
>> */
>> void (*resource_copy_region)(struct pipe_context *pipe,
>> struct pipe_resource *dst,
> I think the idea to restrict this to 1 sample was to keep it simple. I'm not
> sure hw can always easily do this, depending on how it is implemented
> (especially because there are regions involved). Might be ok though.
>
>> @@ -267,14 +266,17 @@ struct pipe_context {
>> const struct pipe_box *src_box);
>>
>> /**
>> -* Resolve a multisampled resource into a non-multisampled one.
>> -* Source and destination must have the same size and same format.
>> +* Resolve a multisampled resource into a non-multisampled one,
>> +* or vice versa (in the latter case, values are just replicated).
>> +* Source and destination must have the same format.
>> +* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
>> +* The mipmap level of the multisampled resource will be 0.
>> */
>> - void (*resource_resolve)(struct pipe_context *pipe,
>> -struct pipe_resource *dst,
>> -unsigned dst_layer,
>> -struct pipe_resource *src,
>> -unsigned src_layer);
>> + void (*resource_resolve)(struct pipe_context *pipe, unsigned mask,
>> +struct pipe_resource *dst, unsigned dst_level,
>> +unsigned dstx, unsigned dsty, unsigned
>> dst_layer,
>> +struct pipe_resource *src, unsigned src_level,
>> +const struct pipe_box *src_box, boolean yflip);
>
> This function was inspired by d3d10 and the wide variety of possible
> implementations.
> You cannot resolve depth and stencil buffers in d3d10/11 and I'm not
> convinced it even makes a whole lot of sense (especially for the stencil
> buffer).
Just because you cannot do something in D3D10 doesn't mean you have to
make it impossible in gallium if it can be done OpenGL.
If you resolve because you don't need/want multisampling for the rest of
the frame, but you still want the contents of the depth buffer, it does
very much make sense.
> Some hw will potentially be unable to do this (I don't know how deferred
> renderers would do that, for example).
> Also, allowing regions might also be very difficult to do for some hardware,
> and yes glBlitFramebuffer allows this but I'm not sure it's really worth
> having this in the interface - I doubt anyone ever will use this anyway, so
> it would be nice if we could keep that out of drivers. Just doing another
> copy for the odd testcase trying this seems ok to me.
There will always be at least 1 application that does something you
didn't expect, and it will be needlessly slow with our drivers.
> For the same reason I don't like the y-flip very much. I see though how that
> could be very useful. I guess drivers not able to do this natively could just
> do the copy themselves (ok they could do that with the regions too).
> Frankly glBlitFrameBuffer can do a lot of things and I'm not sure it makes a
> lot of sense to cram all that functionality into resource_resolve. Though if
> other driver writers agree I could be convinced.
>
nv50+ can happily do all of the above in one go.
Every fallback you can do in a state tracker can be done equally well
from within drivers through shared utility code, compare u_blit and
u_blitter.
The difference is, if a driver does *not* have to use the slow path, it
is, for a change, *not* *forced* to do so anyway by a state tracker.
Christoph
[Mesa-dev] [PATCH 0/2] Make Gallium drivers respect the force_s3tc_enable environment variable
This is a revised version of my previous patches. Patch 1 incorporates Brian's feedback, and patch 2 is unchanged from before. I did test patch 2 without patch 1, and found that both patches are neeeded for force_s3tc_enable to work. Both of these are candidates for 7.10 and 7.11, since games such as 0 A.D. expect drivers to support this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/mesa: respect force_s3tc_enable environment variable
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/mesa/state_tracker/st_extensions.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 99b231d..b5f6d35 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -208,6 +208,15 @@ void st_init_limits(struct st_context *st)
}
+static GLboolean st_get_s3tc_override(void)
+{
+ const char *override = _mesa_getenv("force_s3tc_enable");
+ if (override && !strcmp(override, "true"))
+ return GL_TRUE;
+ return GL_FALSE;
+}
+
+
/**
* Use pipe_screen::get_param() to query PIPE_CAP_ values to determine
* which GL extensions are supported.
@@ -426,7 +435,7 @@ void st_init_extensions(struct st_context *st)
if (screen->is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
PIPE_TEXTURE_2D, 0,
PIPE_BIND_SAMPLER_VIEW) &&
- ctx->Mesa_DXTn) {
+ (ctx->Mesa_DXTn || st_get_s3tc_override())) {
ctx->Extensions.EXT_texture_compression_s3tc = GL_TRUE;
ctx->Extensions.S3_s3tc = GL_TRUE;
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] util: enable S3TC support when the force_s3tc_enable env var is set to "true"
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/gallium/auxiliary/util/u_format_s3tc.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliary/util/u_format_s3tc.c
index bb989c2..d8a7c0d 100644
--- a/src/gallium/auxiliary/util/u_format_s3tc.c
+++ b/src/gallium/auxiliary/util/u_format_s3tc.c
@@ -119,8 +119,15 @@ util_format_s3tc_init(void)
library = util_dl_open(DXTN_LIBNAME);
if (!library) {
- debug_printf("couldn't open " DXTN_LIBNAME ", software DXTn "
- "compression/decompression unavailable\n");
+ if (getenv("force_s3tc_enable") &&
+ !strcmp(getenv("force_s3tc_enable"), "true")) {
+ debug_printf("couldn't open " DXTN_LIBNAME ", enabling DXTn due to "
+"force_s3tc_enable=true environment variable\n");
+ util_format_s3tc_enabled = TRUE;
+ } else {
+ debug_printf("couldn't open " DXTN_LIBNAME ", software DXTn "
+"compression/decompression unavailable\n");
+ }
return;
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Make Gallium drivers respect the force_s3tc_enable environment variable
I have no objection FWIW. Jose - Original Message - > This is a revised version of my previous patches. Patch 1 > incorporates > Brian's feedback, and patch 2 is unchanged from before. I did test > patch 2 > without patch 1, and found that both patches are neeeded for > force_s3tc_enable > to work. > > Both of these are candidates for 7.10 and 7.11, since games such as 0 > A.D. > expect drivers to support this. > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On Mon, Jul 25, 2011 at 7:54 PM, Roland Scheidegger wrote: > You cannot resolve depth and stencil buffers in d3d10/11 and I'm not > convinced it even makes a whole lot of sense (especially for the stencil > buffer). Some hw will potentially be unable to do this (I don't know how > deferred renderers would do that, for example). FWIW D3D 10.1 supports multi-sampled depth buffers. I think Radeon HD 3000 was the first hardware to be able to do that. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Check actual tile offsets in Gen4 miptree workaround.
The apitrace dump in bug #34009 managed to fool the draw_offset check
into thinking that we were tile aligned when we weren't. This led to an
assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
Simply compute tile_x and tile_y and check those, as that way both
places are checking the same thing.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_fbo.c | 53 +---
1 files changed, 28 insertions(+), 25 deletions(-)
For reviewers: Most of this patch is simply reindenting the code, as I added
pushed it inside a new if-statement.
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 35be325..6f65e2c 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -700,8 +700,7 @@ intel_render_texture(struct gl_context * ctx,
intel_image->used_as_render_target = GL_TRUE;
#ifndef I915
- if (!brw_context(ctx)->has_surface_tile_offset &&
- (irb->draw_offset & 4095) != 0) {
+ if (!brw_context(ctx)->has_surface_tile_offset) {
/* Original gen4 hardware couldn't draw to a non-tile-aligned
* destination in a miptree unless you actually setup your
* renderbuffer as a miptree and used the fragile
@@ -709,30 +708,34 @@ intel_render_texture(struct gl_context * ctx,
* instead, we just make a new single-level miptree and render
* into that.
*/
- struct intel_context *intel = intel_context(ctx);
- struct intel_mipmap_tree *old_mt = intel_image->mt;
- struct intel_mipmap_tree *new_mt;
-
- new_mt = intel_miptree_create(intel, image->TexObject->Target,
- intel_image->base.TexFormat,
- intel_image->level,
- intel_image->level,
- intel_image->base.Width,
- intel_image->base.Height,
- intel_image->base.Depth,
- GL_TRUE);
-
- intel_miptree_image_copy(intel,
- new_mt,
- intel_image->face,
- intel_image->level,
- old_mt);
-
- intel_miptree_release(intel, &intel_image->mt);
- intel_image->mt = new_mt;
- intel_renderbuffer_set_draw_offset(irb, intel_image, att->Zoffset);
+ uint32_t tile_x, tile_y;
+ intel_renderbuffer_tile_offsets(irb, &tile_x, &tile_y);
+ if (tile_x != 0 || tile_y != 0) {
+struct intel_context *intel = intel_context(ctx);
+struct intel_mipmap_tree *old_mt = intel_image->mt;
+struct intel_mipmap_tree *new_mt;
+
+new_mt = intel_miptree_create(intel, image->TexObject->Target,
+ intel_image->base.TexFormat,
+ intel_image->level,
+ intel_image->level,
+ intel_image->base.Width,
+ intel_image->base.Height,
+ intel_image->base.Depth,
+ GL_TRUE);
- intel_region_reference(&irb->region, intel_image->mt->region);
+intel_miptree_image_copy(intel,
+ new_mt,
+ intel_image->face,
+ intel_image->level,
+ old_mt);
+
+intel_miptree_release(intel, &intel_image->mt);
+intel_image->mt = new_mt;
+intel_renderbuffer_set_draw_offset(irb, intel_image, att->Zoffset);
+
+intel_region_reference(&irb->region, intel_image->mt->region);
+ }
}
#endif
/* update drawing region, etc */
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Remove the now unused intel_renderbuffer::draw_offset field.
The previous commit removed the last use of this field. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/intel/intel_fbo.c |1 - src/mesa/drivers/dri/intel/intel_fbo.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) Perhaps this should be squashed with patch 1? diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index 6f65e2c..4f0d1ba 100644 --- a/src/mesa/drivers/dri/intel/intel_fbo.c +++ b/src/mesa/drivers/dri/intel/intel_fbo.c @@ -606,7 +606,6 @@ intel_renderbuffer_set_draw_offset(struct intel_renderbuffer *irb, zoffset, &dst_x, &dst_y); - irb->draw_offset = (dst_y * mt->region->pitch + dst_x) * mt->cpp; irb->draw_x = dst_x; irb->draw_y = dst_y; } diff --git a/src/mesa/drivers/dri/intel/intel_fbo.h b/src/mesa/drivers/dri/intel/intel_fbo.h index f7f99a4..2487994 100644 --- a/src/mesa/drivers/dri/intel/intel_fbo.h +++ b/src/mesa/drivers/dri/intel/intel_fbo.h @@ -58,7 +58,6 @@ struct intel_renderbuffer /** \} */ - GLuint draw_offset; /**< Offset of drawing address within the region */ GLuint draw_x, draw_y; /**< Offset of drawing within the region */ }; -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
> >> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> >> renderbuffer to a different location in any mipmap level of some
> >> other texture, therefore location and size parameters are needed.
> >>
> >> The mask parameter was added because resolving only depth or only
> >> stencil of a combined buffer is possible as well.
> >>
> >> Copying from FBO to a window system buffer requires a vertical
> >> so the yflip parameter was added.
> >>
> >> The y-flip parameter could be left out if pipe_box was changed to
> >> contain signed width/height or x0,y0,x1,y1 instead.
> >> This might benefit other methods, such as resource_copy_region,
> >> where
> >> some hw can easily do a backwards copy (yflip).
> >
> > Hmm I'm not sure I like these interface changes too much.
> > Individual comments below.
> >
> >
> >> diff --git a/src/gallium/include/pipe/p_context.h
> >> b/src/gallium/include/pipe/p_context.h
> >> index 3f6d90d..9376cdd 100644
> >> --- a/src/gallium/include/pipe/p_context.h
> >> +++ b/src/gallium/include/pipe/p_context.h
> >> @@ -255,8 +255,7 @@ struct pipe_context {
> >>
> >> /**
> >> * Copy a block of pixels from one resource to another.
> >> -* The resource must be of the same format.
> >> -* Resources with nr_samples > 1 are not allowed.
> >> +* The resources must be of the same format and sample count.
> >> */
> >> void (*resource_copy_region)(struct pipe_context *pipe,
> >> struct pipe_resource *dst,
> > I think the idea to restrict this to 1 sample was to keep it
> > simple. I'm not sure hw can always easily do this, depending on
> > how it is implemented (especially because there are regions
> > involved). Might be ok though.
> >
> >> @@ -267,14 +266,17 @@ struct pipe_context {
> >> const struct pipe_box *src_box);
> >>
> >> /**
> >> -* Resolve a multisampled resource into a non-multisampled
> >> one.
> >> -* Source and destination must have the same size and same
> >> format.
> >> +* Resolve a multisampled resource into a non-multisampled
> >> one,
> >> +* or vice versa (in the latter case, values are just
> >> replicated).
> >> +* Source and destination must have the same format.
> >> +* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
> >> +* The mipmap level of the multisampled resource will be 0.
> >> */
> >> - void (*resource_resolve)(struct pipe_context *pipe,
> >> -struct pipe_resource *dst,
> >> -unsigned dst_layer,
> >> -struct pipe_resource *src,
> >> -unsigned src_layer);
> >> + void (*resource_resolve)(struct pipe_context *pipe, unsigned
> >> mask,
> >> +struct pipe_resource *dst, unsigned
> >> dst_level,
> >> +unsigned dstx, unsigned dsty,
> >> unsigned dst_layer,
> >> +struct pipe_resource *src, unsigned
> >> src_level,
> >> +const struct pipe_box *src_box,
> >> boolean yflip);
> >
> > This function was inspired by d3d10 and the wide variety of
> > possible implementations.
> > You cannot resolve depth and stencil buffers in d3d10/11 and I'm
> > not convinced it even makes a whole lot of sense (especially for
> > the stencil buffer).
> Just because you cannot do something in D3D10 doesn't mean you have
> to
> make it impossible in gallium if it can be done OpenGL.
> If you resolve because you don't need/want multisampling for the rest
> of
> the frame, but you still want the contents of the depth buffer, it
> does
> very much make sense.
Just think about it what this does: 2 out of 4 depth samples were from some
near object, the rest from some object back. I haven't looked at the details of
the spec too closely, what value are you even supposed to get there? A
meaningless "average depth"? Or just one of the values at random?
Resolving color buffers is pretty well defined (for standard msaa at least). I
have no idea how that's supposed to be defined for depth and stencil values.
Frankly I'm not sure what glBlitFramebuffer is supposed to do here, maybe it's
defined somewhere but even applying the term "resolve" to a depth buffer seems
very iffy. At the very least it needs to be documented in the gallium docs what
"resolving" a depth/stencil buffer really means.
I certainly agree just because it isn't in d3d doesn't mean it can't be in
gallium. But just because it maps well to OpenGL isn't a good reason to include
it neither.
>
> > Some hw will potentially be unable to do this (I don't know how
> > deferred renderers would do that, for example).
> > Also, allowing regions might also be very difficult to do for some
> > hardware, and yes glBlitFramebuffer allows this but I'm not sure
> > it's really worth having this in the interface - I doubt an
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
> On Mon, Jul 25, 2011 at 7:54 PM, Roland Scheidegger > wrote: > > You cannot resolve depth and stencil buffers in d3d10/11 and I'm > > not convinced it even makes a whole lot of sense (especially for > > the stencil buffer). Some hw will potentially be unable to do this > > (I don't know how deferred renderers would do that, for example). > > FWIW D3D 10.1 supports multi-sampled depth buffers. I think Radeon HD > 3000 was the first hardware to be able to do that. Yes, and the way this is exposed is you can access the individual samples through shaders accessing the buffer, resolve still won't work. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().
Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
{COLOR0}, {COLOR0, COLOR1}.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Henri Verbeet
---
src/mesa/main/buffers.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index a75c9c2..88fe0b1 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -445,7 +445,10 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n, const
GLenum *buffers,
fb->ColorDrawBuffer[buf] = GL_NONE;
buf++;
}
- fb->_NumColorDrawBuffers = count;
+ if (fb->_NumColorDrawBuffers != count) {
+ updated_drawbuffers(ctx);
+ fb->_NumColorDrawBuffers = count;
+ }
}
if (fb->Name == 0) {
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
>> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving only depth or only
stencil of a combined buffer is possible as well.
Copying from FBO to a window system buffer requires a vertical
so the yflip parameter was added.
The y-flip parameter could be left out if pipe_box was changed to
contain signed width/height or x0,y0,x1,y1 instead.
This might benefit other methods, such as resource_copy_region,
where
some hw can easily do a backwards copy (yflip).
>>>
>>> Hmm I'm not sure I like these interface changes too much.
>>> Individual comments below.
>>>
>>>
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index 3f6d90d..9376cdd 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -255,8 +255,7 @@ struct pipe_context {
/**
* Copy a block of pixels from one resource to another.
-* The resource must be of the same format.
-* Resources with nr_samples > 1 are not allowed.
+* The resources must be of the same format and sample count.
*/
void (*resource_copy_region)(struct pipe_context *pipe,
struct pipe_resource *dst,
>>> I think the idea to restrict this to 1 sample was to keep it
>>> simple. I'm not sure hw can always easily do this, depending on
>>> how it is implemented (especially because there are regions
>>> involved). Might be ok though.
>>>
@@ -267,14 +266,17 @@ struct pipe_context {
const struct pipe_box *src_box);
/**
-* Resolve a multisampled resource into a non-multisampled
one.
-* Source and destination must have the same size and same
format.
+* Resolve a multisampled resource into a non-multisampled
one,
+* or vice versa (in the latter case, values are just
replicated).
+* Source and destination must have the same format.
+* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
+* The mipmap level of the multisampled resource will be 0.
*/
- void (*resource_resolve)(struct pipe_context *pipe,
-struct pipe_resource *dst,
-unsigned dst_layer,
-struct pipe_resource *src,
-unsigned src_layer);
+ void (*resource_resolve)(struct pipe_context *pipe, unsigned
mask,
+struct pipe_resource *dst, unsigned
dst_level,
+unsigned dstx, unsigned dsty,
unsigned dst_layer,
+struct pipe_resource *src, unsigned
src_level,
+const struct pipe_box *src_box,
boolean yflip);
>>>
>>> This function was inspired by d3d10 and the wide variety of
>>> possible implementations.
>>> You cannot resolve depth and stencil buffers in d3d10/11 and I'm
>>> not convinced it even makes a whole lot of sense (especially for
>>> the stencil buffer).
>> Just because you cannot do something in D3D10 doesn't mean you have
>> to
>> make it impossible in gallium if it can be done OpenGL.
>> If you resolve because you don't need/want multisampling for the rest
>> of
>> the frame, but you still want the contents of the depth buffer, it
>> does
>> very much make sense.
> Just think about it what this does: 2 out of 4 depth samples were from some
> near object, the rest from some object back. I haven't looked at the details
> of the spec too closely, what value are you even supposed to get there? A
> meaningless "average depth"? Or just one of the values at random?
> Resolving color buffers is pretty well defined (for standard msaa at least).
> I have no idea how that's supposed to be defined for depth and stencil
> values. Frankly I'm not sure what glBlitFramebuffer is supposed to do here,
> maybe it's defined somewhere but even applying the term "resolve" to a depth
> buffer seems very iffy. At the very least it needs to be documented in the
> gallium docs what "resolving" a depth/stencil buffer really means.
> I certainly agree just because it isn't in d3d doesn't mean it can't be in
> gallium. But just because it maps well to OpenGL isn't a good reason to
> include it neither.
>
I had noticed that (and incorporated it into the nv50 patch), average
depth doesn't make much sense indeed.
That's why you can't use GL_LINEAR for depth resolve but only GL_NEAREST.
>From the GL spec:
"if mask includes DEPTH_BUFFER_BIT or STEN
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
>
> On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
> >> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, therefore location and size parameters are
> needed.
>
> The mask parameter was added because resolving only depth or
> only
> stencil of a combined buffer is possible as well.
>
> Copying from FBO to a window system buffer requires a vertical
> so the yflip parameter was added.
>
> The y-flip parameter could be left out if pipe_box was changed
> to
> contain signed width/height or x0,y0,x1,y1 instead.
> This might benefit other methods, such as resource_copy_region,
> where
> some hw can easily do a backwards copy (yflip).
> >>>
> >>> Hmm I'm not sure I like these interface changes too much.
> >>> Individual comments below.
> >>>
> >>>
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index 3f6d90d..9376cdd 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -255,8 +255,7 @@ struct pipe_context {
>
> /**
> * Copy a block of pixels from one resource to another.
> -* The resource must be of the same format.
> -* Resources with nr_samples > 1 are not allowed.
> +* The resources must be of the same format and sample
> count.
> */
> void (*resource_copy_region)(struct pipe_context *pipe,
> struct pipe_resource *dst,
> >>> I think the idea to restrict this to 1 sample was to keep it
> >>> simple. I'm not sure hw can always easily do this, depending on
> >>> how it is implemented (especially because there are regions
> >>> involved). Might be ok though.
> >>>
> @@ -267,14 +266,17 @@ struct pipe_context {
> const struct pipe_box
> *src_box);
>
> /**
> -* Resolve a multisampled resource into a non-multisampled
> one.
> -* Source and destination must have the same size and same
> format.
> +* Resolve a multisampled resource into a non-multisampled
> one,
> +* or vice versa (in the latter case, values are just
> replicated).
> +* Source and destination must have the same format.
> +* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
> +* The mipmap level of the multisampled resource will be 0.
> */
> - void (*resource_resolve)(struct pipe_context *pipe,
> -struct pipe_resource *dst,
> -unsigned dst_layer,
> -struct pipe_resource *src,
> -unsigned src_layer);
> + void (*resource_resolve)(struct pipe_context *pipe, unsigned
> mask,
> +struct pipe_resource *dst, unsigned
> dst_level,
> +unsigned dstx, unsigned dsty,
> unsigned dst_layer,
> +struct pipe_resource *src, unsigned
> src_level,
> +const struct pipe_box *src_box,
> boolean yflip);
> >>>
> >>> This function was inspired by d3d10 and the wide variety of
> >>> possible implementations.
> >>> You cannot resolve depth and stencil buffers in d3d10/11 and I'm
> >>> not convinced it even makes a whole lot of sense (especially for
> >>> the stencil buffer).
> >> Just because you cannot do something in D3D10 doesn't mean you
> >> have
> >> to
> >> make it impossible in gallium if it can be done OpenGL.
> >> If you resolve because you don't need/want multisampling for the
> >> rest
> >> of
> >> the frame, but you still want the contents of the depth buffer, it
> >> does
> >> very much make sense.
> > Just think about it what this does: 2 out of 4 depth samples were
> > from some near object, the rest from some object back. I haven't
> > looked at the details of the spec too closely, what value are you
> > even supposed to get there? A meaningless "average depth"? Or just
> > one of the values at random?
> > Resolving color buffers is pretty well defined (for standard msaa
> > at least). I have no idea how that's supposed to be defined for
> > depth and stencil values. Frankly I'm not sure what
> > glBlitFramebuffer is supposed to do here, maybe it's defined
> > somewhere but even applying the term "resolve" to a depth buffer
> > seems very iffy. At the very least it needs to be documented in
> > the gallium docs what "resolving" a depth/stencil buffer really
> > means.
> > I certainly agree just because it isn't in d3d doesn't mean it
> > can't be in gallium. But just because it maps well to OpenGL isn't
> > a
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 07/25/2011 10:43 PM, Roland Scheidegger wrote:
>>
>> On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
>> Resolve via glBlitFramebuffer allows resolving a sub-region of a
>> renderbuffer to a different location in any mipmap level of some
>> other texture, therefore location and size parameters are
>> needed.
>>
>> The mask parameter was added because resolving only depth or
>> only
>> stencil of a combined buffer is possible as well.
>>
>> Copying from FBO to a window system buffer requires a vertical
>> so the yflip parameter was added.
>>
>> The y-flip parameter could be left out if pipe_box was changed
>> to
>> contain signed width/height or x0,y0,x1,y1 instead.
>> This might benefit other methods, such as resource_copy_region,
>> where
>> some hw can easily do a backwards copy (yflip).
>
> Hmm I'm not sure I like these interface changes too much.
> Individual comments below.
>
>
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index 3f6d90d..9376cdd 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -255,8 +255,7 @@ struct pipe_context {
>>
>> /**
>> * Copy a block of pixels from one resource to another.
>> -* The resource must be of the same format.
>> -* Resources with nr_samples > 1 are not allowed.
>> +* The resources must be of the same format and sample
>> count.
>> */
>> void (*resource_copy_region)(struct pipe_context *pipe,
>> struct pipe_resource *dst,
> I think the idea to restrict this to 1 sample was to keep it
> simple. I'm not sure hw can always easily do this, depending on
> how it is implemented (especially because there are regions
> involved). Might be ok though.
>
>> @@ -267,14 +266,17 @@ struct pipe_context {
>> const struct pipe_box
>> *src_box);
>>
>> /**
>> -* Resolve a multisampled resource into a non-multisampled
>> one.
>> -* Source and destination must have the same size and same
>> format.
>> +* Resolve a multisampled resource into a non-multisampled
>> one,
>> +* or vice versa (in the latter case, values are just
>> replicated).
>> +* Source and destination must have the same format.
>> +* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
>> +* The mipmap level of the multisampled resource will be 0.
>> */
>> - void (*resource_resolve)(struct pipe_context *pipe,
>> -struct pipe_resource *dst,
>> -unsigned dst_layer,
>> -struct pipe_resource *src,
>> -unsigned src_layer);
>> + void (*resource_resolve)(struct pipe_context *pipe, unsigned
>> mask,
>> +struct pipe_resource *dst, unsigned
>> dst_level,
>> +unsigned dstx, unsigned dsty,
>> unsigned dst_layer,
>> +struct pipe_resource *src, unsigned
>> src_level,
>> +const struct pipe_box *src_box,
>> boolean yflip);
>
> This function was inspired by d3d10 and the wide variety of
> possible implementations.
> You cannot resolve depth and stencil buffers in d3d10/11 and I'm
> not convinced it even makes a whole lot of sense (especially for
> the stencil buffer).
Just because you cannot do something in D3D10 doesn't mean you
have
to
make it impossible in gallium if it can be done OpenGL.
If you resolve because you don't need/want multisampling for the
rest
of
the frame, but you still want the contents of the depth buffer, it
does
very much make sense.
>>> Just think about it what this does: 2 out of 4 depth samples were
>>> from some near object, the rest from some object back. I haven't
>>> looked at the details of the spec too closely, what value are you
>>> even supposed to get there? A meaningless "average depth"? Or just
>>> one of the values at random?
>>> Resolving color buffers is pretty well defined (for standard msaa
>>> at least). I have no idea how that's supposed to be defined for
>>> depth and stencil values. Frankly I'm not sure what
>>> glBlitFramebuffer is supposed to do here, maybe it's defined
>>> somewhere but even applying the term "resolve" to a depth buffer
>>> seems very iffy. At the very least it needs to be documented in
>>> the gallium docs what "resolving" a depth/stencil buffer really
>>> means.
>>> I certainly agree just because it isn't in d3d doesn't mean it
>>> can't be in gallium.
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
> On 07/25/2011 10:43 PM, Roland Scheidegger wrote:
> >>
> >> On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
> >> Resolve via glBlitFramebuffer allows resolving a sub-region of
> >> a
> >> renderbuffer to a different location in any mipmap level of
> >> some
> >> other texture, therefore location and size parameters are
> >> needed.
> >>
> >> The mask parameter was added because resolving only depth or
> >> only
> >> stencil of a combined buffer is possible as well.
> >>
> >> Copying from FBO to a window system buffer requires a vertical
> >> so the yflip parameter was added.
> >>
> >> The y-flip parameter could be left out if pipe_box was changed
> >> to
> >> contain signed width/height or x0,y0,x1,y1 instead.
> >> This might benefit other methods, such as
> >> resource_copy_region,
> >> where
> >> some hw can easily do a backwards copy (yflip).
> >
> > Hmm I'm not sure I like these interface changes too much.
> > Individual comments below.
> >
> >
> >> diff --git a/src/gallium/include/pipe/p_context.h
> >> b/src/gallium/include/pipe/p_context.h
> >> index 3f6d90d..9376cdd 100644
> >> --- a/src/gallium/include/pipe/p_context.h
> >> +++ b/src/gallium/include/pipe/p_context.h
> >> @@ -255,8 +255,7 @@ struct pipe_context {
> >>
> >> /**
> >> * Copy a block of pixels from one resource to another.
> >> -* The resource must be of the same format.
> >> -* Resources with nr_samples > 1 are not allowed.
> >> +* The resources must be of the same format and sample
> >> count.
> >> */
> >> void (*resource_copy_region)(struct pipe_context *pipe,
> >> struct pipe_resource *dst,
> > I think the idea to restrict this to 1 sample was to keep it
> > simple. I'm not sure hw can always easily do this, depending on
> > how it is implemented (especially because there are regions
> > involved). Might be ok though.
> >
> >> @@ -267,14 +266,17 @@ struct pipe_context {
> >> const struct pipe_box
> >> *src_box);
> >>
> >> /**
> >> -* Resolve a multisampled resource into a non-multisampled
> >> one.
> >> -* Source and destination must have the same size and same
> >> format.
> >> +* Resolve a multisampled resource into a non-multisampled
> >> one,
> >> +* or vice versa (in the latter case, values are just
> >> replicated).
> >> +* Source and destination must have the same format.
> >> +* Mask can be either PIPE_MASK_RGBA, Z, S or ZS.
> >> +* The mipmap level of the multisampled resource will be
> >> 0.
> >> */
> >> - void (*resource_resolve)(struct pipe_context *pipe,
> >> -struct pipe_resource *dst,
> >> -unsigned dst_layer,
> >> -struct pipe_resource *src,
> >> -unsigned src_layer);
> >> + void (*resource_resolve)(struct pipe_context *pipe,
> >> unsigned
> >> mask,
> >> +struct pipe_resource *dst,
> >> unsigned
> >> dst_level,
> >> +unsigned dstx, unsigned dsty,
> >> unsigned dst_layer,
> >> +struct pipe_resource *src,
> >> unsigned
> >> src_level,
> >> +const struct pipe_box *src_box,
> >> boolean yflip);
> >
> > This function was inspired by d3d10 and the wide variety of
> > possible implementations.
> > You cannot resolve depth and stencil buffers in d3d10/11 and
> > I'm
> > not convinced it even makes a whole lot of sense (especially
> > for
> > the stencil buffer).
> Just because you cannot do something in D3D10 doesn't mean you
> have
> to
> make it impossible in gallium if it can be done OpenGL.
> If you resolve because you don't need/want multisampling for the
> rest
> of
> the frame, but you still want the contents of the depth buffer,
> it
> does
> very much make sense.
> >>> Just think about it what this does: 2 out of 4 depth samples were
> >>> from some near object, the rest from some object back. I haven't
> >>> looked at the details of the spec too closely, what value are you
> >>> even supposed to get there? A meaningless "average depth"? Or
> >>> just
> >>> one of the values at random?
> >>> Resolving color buffers is pretty well defined (for standard msaa
> >>> at least). I have no idea how that's supposed to be defined for
> >>> depth and stencil values. Frankly I'm not sure what
> >>> glBlitFramebuffer is supposed to do here, maybe it's defined
> >>>
[Mesa-dev] [PATCH 4/8] i965/fs: Optimize a * 1.0 -> a.
This appears in our instruction stream as a result of the
brw_vs_constval.c handling.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 43 ++
src/mesa/drivers/dri/i965/brw_fs.h |1 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 6d91668..d072e22 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1069,6 +1069,7 @@ fs_visitor::propagate_constants()
if (inst->src[0].imm.f != 0.0f) {
scan_inst->opcode = BRW_OPCODE_MOV;
scan_inst->src[0] = inst->src[0];
+ scan_inst->src[0].imm.f = 1.0f / scan_inst->src[0].imm.f;
progress = true;
}
break;
@@ -1089,6 +1090,47 @@ fs_visitor::propagate_constants()
return progress;
}
+
+
+/**
+ * Attempts to move immediate constants into the immediate
+ * constant slot of following instructions.
+ *
+ * Immediate constants are a bit tricky -- they have to be in the last
+ * operand slot, you can't do abs/negate on them,
+ */
+
+bool
+fs_visitor::opt_algebraic()
+{
+ bool progress = false;
+
+ calculate_live_intervals();
+
+ foreach_iter(exec_list_iterator, iter, this->instructions) {
+ fs_inst *inst = (fs_inst *)iter.get();
+
+ switch (inst->opcode) {
+ case BRW_OPCODE_MUL:
+if (inst->src[1].file != IMM)
+ continue;
+
+/* a * 1.0 = a */
+if (inst->src[1].type == BRW_REGISTER_TYPE_F &&
+inst->src[1].imm.f == 1.0) {
+ inst->opcode = BRW_OPCODE_MOV;
+ inst->src[1] = reg_undef;
+ progress = true;
+ break;
+}
+
+break;
+ }
+ }
+
+ return progress;
+}
+
/**
* Must be called after calculate_live_intervales() to remove unused
* writes to registers -- register allocation will fail otherwise
@@ -1576,6 +1618,7 @@ fs_visitor::run()
progress = remove_duplicate_mrf_writes() || progress;
progress = propagate_constants() || progress;
+progress = opt_algebraic() || progress;
progress = register_coalesce() || progress;
progress = compute_to_mrf() || progress;
progress = dead_code_eliminate() || progress;
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 2bf850e..89d6cda 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -485,6 +485,7 @@ public:
void setup_pull_constants();
void calculate_live_intervals();
bool propagate_constants();
+ bool opt_algebraic();
bool register_coalesce();
bool compute_to_mrf();
bool dead_code_eliminate();
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/8] i965/fs: Port texture projection avoidance optimization from the old backend.
This is part of fixing a ~1% performance regression in OpenArena when
changing the fixed function fragment shader to using the new backend.
Right now this just avoids the LINTERP of the projector, not the math
using it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index b5ea943..7e9ce04 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -463,9 +463,21 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
} else {
/* Perspective interpolation case. */
for (unsigned int k = 0; k < type->vector_elements; k++) {
- struct brw_reg interp = interp_reg(location, k);
- emit(FS_OPCODE_LINTERP, attr,
- this->delta_x, this->delta_y, fs_reg(interp));
+ /* FINISHME: At some point we probably want to push
+ * this farther by giving similar treatment to the
+ * other potentially constant components of the
+ * attribute, as well as making brw_vs_constval.c
+ * handle varyings other than gl_TexCoord.
+ */
+ if (location >= FRAG_ATTRIB_TEX0 &&
+ location <= FRAG_ATTRIB_TEX7 &&
+ k == 3 && !(c->key.proj_attrib_mask & (1 << location))) {
+ emit(BRW_OPCODE_MOV, attr, fs_reg(1.0f));
+ } else {
+ struct brw_reg interp = interp_reg(location, k);
+ emit(FS_OPCODE_LINTERP, attr,
+ this->delta_x, this->delta_y, fs_reg(interp));
+ }
attr.reg_offset++;
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/8] i965/fs: Allow register coalescing where the source is a uniform.
Removes 0.8% of the fragment shader instructions on Unigine Tropics.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index d072e22..5cf6c14 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1198,7 +1198,8 @@ fs_visitor::register_coalesce()
if (inst->opcode != BRW_OPCODE_MOV ||
inst->predicated ||
inst->saturate ||
- inst->dst.file != GRF || inst->src[0].file != GRF ||
+ inst->dst.file != GRF || (inst->src[0].file != GRF &&
+ inst->src[0].file != UNIFORM)||
inst->dst.type != inst->src[0].type)
continue;
@@ -1221,7 +1222,8 @@ fs_visitor::register_coalesce()
interfered = true;
break;
}
- if (scan_inst->dst.reg == inst->src[0].reg &&
+ if (inst->src[0].file == GRF &&
+ scan_inst->dst.reg == inst->src[0].reg &&
(scan_inst->dst.reg_offset == inst->src[0].reg_offset ||
scan_inst->is_tex())) {
interfered = true;
@@ -1229,10 +1231,13 @@ fs_visitor::register_coalesce()
}
}
-/* The gen6 MATH instruction can't handle source modifiers, so avoid
- * coalescing those for now. We should do something more specific.
+/* The gen6 MATH instruction can't handle source modifiers or
+ * unusual register regions, so avoid coalescing those for
+ * now. We should do something more specific.
*/
-if (intel->gen >= 6 && scan_inst->is_math() && has_source_modifiers) {
+if (intel->gen >= 6 &&
+scan_inst->is_math() &&
+(has_source_modifiers || inst->src[0].file == UNIFORM)) {
interfered = true;
break;
}
@@ -1252,11 +1257,10 @@ fs_visitor::register_coalesce()
if (scan_inst->src[i].file == GRF &&
scan_inst->src[i].reg == inst->dst.reg &&
scan_inst->src[i].reg_offset == inst->dst.reg_offset) {
- scan_inst->src[i].reg = inst->src[0].reg;
- scan_inst->src[i].reg_offset = inst->src[0].reg_offset;
- scan_inst->src[i].abs |= inst->src[0].abs;
- scan_inst->src[i].negate ^= inst->src[0].negate;
- scan_inst->src[i].smear = inst->src[0].smear;
+ fs_reg new_src = inst->src[0];
+ new_src.negate ^= scan_inst->src[i].negate;
+ new_src.abs |= scan_inst->src[i].abs;
+ scan_inst->src[i] = new_src;
}
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/8] Revert "i965: Don't compute brw->wm.input_size_masks when it's unused."
This reverts commit 3412069e23b7fa5656262f3dd1aa86f66980594d. We're
about to start using it in fragment shaders to handle avoiding
projection for fixed function.
---
src/mesa/drivers/dri/i965/brw_vs_constval.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_constval.c
b/src/mesa/drivers/dri/i965/brw_vs_constval.c
index 9fdfebe..47cc0a7 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_constval.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_constval.c
@@ -194,19 +194,11 @@ static void calc_wm_input_sizes( struct brw_context *brw )
/* BRW_NEW_VERTEX_PROGRAM */
const struct brw_vertex_program *vp =
brw_vertex_program_const(brw->vertex_program);
- /* BRW_NEW_FRAGMENT_PROGRAM */
- struct gl_shader_program *prog = ctx->Shader.CurrentFragmentProgram;
/* BRW_NEW_INPUT_DIMENSIONS */
struct tracker t;
GLuint insn;
GLuint i;
- /* If we're going to go through brw_fs.cpp, we don't end up using
-* brw->wm.input_size_masks.
-*/
- if (prog && prog->_LinkedShaders[MESA_SHADER_FRAGMENT])
- return;
-
memset(&t, 0, sizeof(t));
/* _NEW_LIGHT */
@@ -246,9 +238,7 @@ static void calc_wm_input_sizes( struct brw_context *brw )
const struct brw_tracked_state brw_wm_input_sizes = {
.dirty = {
.mesa = _NEW_LIGHT,
- .brw = (BRW_NEW_FRAGMENT_PROGRAM |
- BRW_NEW_VERTEX_PROGRAM |
- BRW_NEW_INPUT_DIMENSIONS),
+ .brw = BRW_NEW_VERTEX_PROGRAM | BRW_NEW_INPUT_DIMENSIONS,
.cache = 0
},
.prepare = calc_wm_input_sizes
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/8] softpipe: When doing write_all_cbufs, don't stomp over the color.
We have to make it through this loop processing the color multiple
times, so we can't go overwriting it on our first color buffer.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/sp_quad_blend.c
index 82f9785..c881194 100644
--- a/src/gallium/drivers/softpipe/sp_quad_blend.c
+++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
@@ -817,17 +817,25 @@ blend_fallback(struct quad_stage *qs,
quads[0]->input.y0);
boolean has_dst_alpha
= util_format_has_alpha(softpipe->framebuffer.cbufs[cbuf]->format);
- uint q, i, j, qbuf;
-
- qbuf = write_all ? 0 : cbuf;
+ uint q, i, j;
for (q = 0; q < nr; q++) {
struct quad_header *quad = quads[q];
float (*quadColor)[4];
+ float temp_quad_color[QUAD_SIZE][4];
const int itx = (quad->input.x0 & (TILE_SIZE-1));
const int ity = (quad->input.y0 & (TILE_SIZE-1));
- quadColor = quad->output.color[qbuf];
+ if (write_all) {
+for (j = 0; j < QUAD_SIZE; j++) {
+ for (i = 0; i < 4; i++) {
+ temp_quad_color[i][j] = quad->output.color[0][i][j];
+ }
+}
+quadColor = temp_quad_color;
+ } else {
+quadColor = quad->output.color[cbuf];
+ }
/* get/swizzle dest colors
*/
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/8] i965/fs: If we see a RCP of a constant, try to constant fold it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 7e9ce04..6d91668 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1058,6 +1058,20 @@ fs_visitor::propagate_constants()
progress = true;
}
break;
+
+ case FS_OPCODE_RCP:
+ /* The hardware doesn't do math on immediate values
+ * (because why are you doing that, seriously?), but
+ * the correct answer is to just constant fold it
+ * anyway.
+ */
+ assert(i == 0);
+ if (inst->src[0].imm.f != 0.0f) {
+ scan_inst->opcode = BRW_OPCODE_MOV;
+ scan_inst->src[0] = inst->src[0];
+ progress = true;
+ }
+ break;
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/8] i965/fs: Fix MRT drawing since the m0->m2 move for shader debug.
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 1d89b8f..eecfc92 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -59,7 +59,8 @@ fs_visitor::generate_fb_write(fs_inst *inst)
if (inst->target > 0) {
/* Set the render target index for choosing BLEND_STATE. */
- brw_MOV(p, retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, 0, 2),
+ brw_MOV(p, retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE,
+ inst->base_mrf, 2),
BRW_REGISTER_TYPE_UD),
brw_imm_ud(inst->target));
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/8] mesa: Fix ff fragment shader inputs calculation when enabling a VS.
The FF VS generation happens just after the FF FS generation in
state.c, so the ctx->VP._Current value is for the previous state
update's vertex shader, not the one that will be chosen as a result of
this state update. The vertexShader and vertexProgram variables
should be accurately telling us whether there's going to be a
ctx->VP._Current (except on _MaintainTnlProgram drivers, where it's
always true).
---
src/mesa/main/ff_fragment_shader.cpp |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 0b53c28..dbfa6b5 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -330,8 +330,7 @@ static GLbitfield get_fp_input_mask( struct gl_context *ctx
)
/* _NEW_RENDERMODE */
fp_inputs = (FRAG_BIT_COL0 | FRAG_BIT_TEX0);
}
- else if (!(vertexProgram || vertexShader) ||
-!ctx->VertexProgram._Current) {
+ else if (!(vertexProgram || vertexShader)) {
/* Fixed function vertex logic */
/* _NEW_ARRAY */
GLbitfield varying_inputs = ctx->varying_vp_inputs;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Check actual tile offsets in Gen4 miptree workaround.
On Mon, 25 Jul 2011 21:13:42 -0700, Kenneth Graunke wrote: > The apitrace dump in bug #34009 managed to fool the draw_offset check > into thinking that we were tile aligned when we weren't. This led to an > assertion failure in brw_update_renderbuffer_surface with tile_y != 0. > > Simply compute tile_x and tile_y and check those, as that way both > places are checking the same thing. > > NOTE: This is a candidate for stable release branches. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009 > Signed-off-by: Kenneth Graunke These two are Reviewed-by: Eric Anholt pgppU8RzmKotI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().
On Mon, 25 Jul 2011 22:23:47 +0200, Henri Verbeet wrote:
> Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
> {COLOR0}, {COLOR0, COLOR1}.
I don't see that, because the while (buf < MaxDrawBuffers) loop would
notice the change from COLOR1 -> NONE. And on transition back, the
normal loop would see the change.
pgpLyWEdWvWoj.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] configure.ac: fix xlib-based softpipe build
--- configure.ac | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 5c832e6..40924a9 100644 --- a/configure.ac +++ b/configure.ac @@ -1936,11 +1936,12 @@ if test "x$with_gallium_drivers" != x; then gallium_check_st "nouveau/drm" "dri-nouveau" "xorg-nouveau" "" "xvmc-nouveau" ;; xswrast) +GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS softpipe" +if test "x$MESA_LLVM" = x1; then +GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" +fi + if test "x$HAVE_ST_DRI" = xyes; then -GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS softpipe" -if test "x$MESA_LLVM" = x1; then -GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" -fi GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS dri-swrast" fi if test "x$HAVE_ST_VDPAU" = xyes; then @@ -1958,9 +1959,6 @@ if test "x$with_gallium_drivers" != x; then if test "x$HAVE_WINSYS_XLIB" != xyes; then GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib" fi - if test "x$HAVE_ST_DRI" != xyes; then -GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS softpipe" - fi fi ;; *) -- 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] configure.ac: add DLOPEN_LIBS to xlib build
Otherwise xlib-based llvmpipe fails to link. NOTE: This is a candidate for the 7.11 branch. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 40924a9..1b1823a 100644 --- a/configure.ac +++ b/configure.ac @@ -951,7 +951,7 @@ xyesyes) GL_PC_LIB_PRIV="$GL_LIB_DEPS" GL_PC_CFLAGS="$X11_INCLUDES" fi -GL_LIB_DEPS="$GL_LIB_DEPS $SELINUX_LIBS -lm -lpthread" +GL_LIB_DEPS="$GL_LIB_DEPS $SELINUX_LIBS -lm -lpthread $DLOPEN_LIBS" GL_PC_LIB_PRIV="$GL_PC_LIB_PRIV $SELINUX_LIBS -lm -lpthread" # if static, move the external libraries to the programs -- 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] i965: Check actual tile offsets in Gen4 miptree workaround.
On 07/25/2011 09:13 PM, Kenneth Graunke wrote: > The apitrace dump in bug #34009 managed to fool the draw_offset check > into thinking that we were tile aligned when we weren't. This led to an > assertion failure in brw_update_renderbuffer_surface with tile_y != 0. > > Simply compute tile_x and tile_y and check those, as that way both > places are checking the same thing. > > NOTE: This is a candidate for stable release branches. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009 > Signed-off-by: Kenneth Graunke Scratch this patch, it breaks things on Gen7. Will rework and post an updated version soon. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): configure.ac: don' t build gallium driver libs just to see if there are no errors
Hi, sorry for the late reply. I have just sent a patch to ML which should fix this. See: http://lists.freedesktop.org/archives/mesa-dev/2011-July/009867.html Please let me know if that works for you. Marek On Mon, Jul 18, 2011 at 2:45 PM, Jon TURNEY wrote: > On 14/07/2011 02:05, Marek Olšák wrote: >> Module: Mesa >> Branch: master >> Commit: 02c8ee202f5a159659a027deae4721ff05cd1530 >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=02c8ee202f5a159659a027deae4721ff05cd1530 >> >> Author: Marek Olšák >> Date: Mon Jun 27 08:02:31 2011 +0200 >> >> configure.ac: don't build gallium driver libs just to see if there are no >> errors > [snip] >> diff --git a/configure.ac b/configure.ac >> index a586f0a..c3047d6 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -769,7 +769,7 @@ GLU_DIRS="sgi" >> GALLIUM_DIRS="auxiliary drivers state_trackers" >> GALLIUM_TARGET_DIRS="" >> GALLIUM_WINSYS_DIRS="sw" >> -GALLIUM_DRIVERS_DIRS="softpipe failover galahad trace rbug noop identity" >> +GALLIUM_DRIVERS_DIRS="failover galahad trace rbug noop identity" >> GALLIUM_STATE_TRACKERS_DIRS="" > [snip] >> xswrast) >> if test "x$HAVE_ST_DRI" = xyes; then >> + GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS softpipe" >> + if test "x$MESA_LLVM" = x1; then >> + GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" >> + fi >> GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS dri-swrast" >> fi >> if test "x$HAVE_ST_VDPAU" = xyes; then > > It looks like this changes (in the case where swrast is the only driver > selected) from always building softpipe to only building if the dri state > tracker is selected. > > Since, this change, building with ./configure --with-driver=xlib > --with-gallium-drivers=swrast fails, see [1] > >> mklib: Making CYGWIN shared library: cygGL-1.dll >> Creating library file: libGL-1.dll.a >> xlib.o: In function `sw_screen_create_named': >> /opt/jhbuild/git/mesa/mesa/src/gallium/targets/libgl-xlib/../../../../src/gallium/auxiliary/target-helpers/inline_sw_helper.h:44: >> undefined reference to `_softpipe_create_screen' > > inline_sw_helper.h conditionalizes the code which references softpipe on the > GALLIUM_SOFTPIPE define, but that is always set in > src/gallium/targets/libgl-xlib/Makefile without any reference to the > configuration. > > I'd appreciate some guidance as to the correct way to fix this :-) > > [1] http://tinderbox.freedesktop.org/builds/2011-07-17-0004/logs/libGL/#build > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().
On 26 July 2011 01:02, Eric Anholt wrote:
> I don't see that, because the while (buf < MaxDrawBuffers) loop would
> notice the change from COLOR1 -> NONE.
That loop doesn't happen because n == 1 for {COLOR0} (as opposed to
{COLOR0, NONE}). Perhaps we should always explicitly set any remaining
buffers to NONE though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
(Strange thought sent that before - mail client going crazy...) > Resolving color buffers is pretty well defined (for standard msaa at > least). I have no idea how that's supposed to be defined for depth > and stencil values. Frankly I'm not sure what glBlitFramebuffer is > supposed to do here, maybe it's defined somewhere but even applying > the term "resolve" to a depth buffer seems very iffy. At the very > least it needs to be documented in the gallium docs what "resolving" > a depth/stencil buffer really means. Hmm actually it must be like ReadPixels. So it is "recommended" that implementations just use the centermost sample, but this is not required. In particular "any function using depth/stencil values" is valid. Taking this to the extreme, this means just returning 0 is valid (f = 0*sample0 + 0*sample1...) though probably not recommended... Averaging would be allowed as would be any other crazy stuff. In any case calling this step, whatever it does, "resolve" seems abusive with results possibly quite implementation dependent. I have no idea what nv50 does here though I guess given the loose definition it should certainly fit the requirements. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3 v2] i965: Check actual tile offsets in Gen4 miptree workaround.
The apitrace dump in bug #34009 managed to fool the draw_offset check
into thinking that we were tile aligned when we weren't. This led to an
assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
Simply compute tile_x and tile_y and check those, as that way both
places are checking the same thing.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009
Cc: Chad Versace
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_fbo.c | 28 ++--
1 files changed, 26 insertions(+), 2 deletions(-)
v2 doesn't break the faked packed/depth stencil on Ivybridge (there is no
irb->region on the wrapper), and introduces a function (since I need to add
more conditions in a third patch.)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 35be325..90bfe96 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -647,6 +647,22 @@ intel_renderbuffer_tile_offsets(struct intel_renderbuffer
*irb,
}
}
+#ifndef I915
+static bool
+need_tile_offset_workaround(struct brw_context *brw,
+ struct intel_renderbuffer *irb)
+{
+ uint32_t tile_x, tile_y;
+
+ intel_renderbuffer_tile_offsets(irb, &tile_x, &tile_y);
+
+ if (!brw->has_surface_tile_offset)
+ return tile_x != 0 || tile_y != 0;
+
+ return false;
+}
+#endif
+
/**
* Called by glFramebufferTexture[123]DEXT() (and other places) to
* prepare for rendering into texture memory. This might be called
@@ -699,9 +715,17 @@ intel_render_texture(struct gl_context * ctx,
intel_renderbuffer_set_draw_offset(irb, intel_image, att->Zoffset);
intel_image->used_as_render_target = GL_TRUE;
+ bool is_depthbuffer = irb->Base._BaseFormat == GL_DEPTH_COMPONENT ||
+irb->Base._BaseFormat == GL_DEPTH_STENCIL;
+
+ /* Resolve combined depth/stencil wrapper to get at the real depth buffer.
+* Notably, we don't need the original irb after this point.
+*/
+ if (is_depthbuffer)
+ irb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
+
#ifndef I915
- if (!brw_context(ctx)->has_surface_tile_offset &&
- (irb->draw_offset & 4095) != 0) {
+ if (need_tile_offset_workaround(brw_context(ctx), irb)) {
/* Original gen4 hardware couldn't draw to a non-tile-aligned
* destination in a miptree unless you actually setup your
* renderbuffer as a miptree and used the fragile
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: Apply miptree workaround for very small depth buffers.
According to the documentation for 3DSTATE_DEPTH_BUFFER (G45 and
beyond), the 3 LSBs of "Depth Coordinate Offset X" (and Y) must be 0.
Detect this and apply the Gen4 miptree hack for working around
unsupported offsets.
Fixes piglit test fbo-clear-formats for GL_ARB_depth_texture and
GL_EXT_packed_depth_stencil on Ivybridge.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_fbo.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index f00943e..7ea81e0 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -649,7 +649,8 @@ intel_renderbuffer_tile_offsets(struct intel_renderbuffer
*irb,
#ifndef I915
static bool
need_tile_offset_workaround(struct brw_context *brw,
- struct intel_renderbuffer *irb)
+ struct intel_renderbuffer *irb,
+ bool is_depthbuffer)
{
uint32_t tile_x, tile_y;
@@ -658,6 +659,12 @@ need_tile_offset_workaround(struct brw_context *brw,
if (!brw->has_surface_tile_offset)
return tile_x != 0 || tile_y != 0;
+ /* In 3DSTATE_DEPTH_BUFFER, the 3 LSBs of Depth Coordinate Offset X/Y
+* must be zero. We need the workaround in those cases.
+*/
+ if (is_depthbuffer)
+ return (tile_x & 0x3) != 0 || (tile_y & 0x3) != 0;
+
return false;
}
#endif
@@ -724,7 +731,7 @@ intel_render_texture(struct gl_context * ctx,
irb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
#ifndef I915
- if (need_tile_offset_workaround(brw_context(ctx), irb)) {
+ if (need_tile_offset_workaround(brw_context(ctx), irb, is_depthbuffer)) {
/* Original gen4 hardware couldn't draw to a non-tile-aligned
* destination in a miptree unless you actually setup your
* renderbuffer as a miptree and used the fragile
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/25/2011 01:23 PM, Henri Verbeet wrote:
> Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
> {COLOR0}, {COLOR0, COLOR1}.
Is there a piglit test to reproduce this failure?
> NOTE: This is a candidate for the 7.10 and 7.11 branches.
>
> Signed-off-by: Henri Verbeet
> ---
> src/mesa/main/buffers.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index a75c9c2..88fe0b1 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -445,7 +445,10 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n,
> const GLenum *buffers,
> fb->ColorDrawBuffer[buf] = GL_NONE;
> buf++;
>}
> - fb->_NumColorDrawBuffers = count;
> + if (fb->_NumColorDrawBuffers != count) {
> + updated_drawbuffers(ctx);
> + fb->_NumColorDrawBuffers = count;
> + }
> }
>
> if (fb->Name == 0) {
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4uCIAACgkQX1gOwKyEAw/VgQCfVxBQwFzcyHf+k2fDf97r+PWF
fu0AoIQle0PGtvHCxtI16DgNqStW+1n8
=wMuo
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/8] i965/fs: Optimize a * 1.0 -> a.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/25/2011 03:39 PM, Eric Anholt wrote:
> This appears in our instruction stream as a result of the
> brw_vs_constval.c handling.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 43
> ++
> src/mesa/drivers/dri/i965/brw_fs.h |1 +
> 2 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 6d91668..d072e22 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -1069,6 +1069,7 @@ fs_visitor::propagate_constants()
> if (inst->src[0].imm.f != 0.0f) {
> scan_inst->opcode = BRW_OPCODE_MOV;
> scan_inst->src[0] = inst->src[0];
> + scan_inst->src[0].imm.f = 1.0f / scan_inst->src[0].imm.f;
> progress = true;
> }
> break;
> @@ -1089,6 +1090,47 @@ fs_visitor::propagate_constants()
>
> return progress;
> }
> +
> +
> +/**
> + * Attempts to move immediate constants into the immediate
> + * constant slot of following instructions.
> + *
> + * Immediate constants are a bit tricky -- they have to be in the last
> + * operand slot, you can't do abs/negate on them,
> + */
> +
> +bool
> +fs_visitor::opt_algebraic()
> +{
> + bool progress = false;
> +
> + calculate_live_intervals();
> +
> + foreach_iter(exec_list_iterator, iter, this->instructions) {
> + fs_inst *inst = (fs_inst *)iter.get();
foreach_list(node, this->instructions) {
fs_inst *inst = (fs_inst *) node;
We added these macros a long time ago because the iterators turned out
to be such fail.
> +
> + switch (inst->opcode) {
> + case BRW_OPCODE_MUL:
> + if (inst->src[1].file != IMM)
> + continue;
> +
> + /* a * 1.0 = a */
> + if (inst->src[1].type == BRW_REGISTER_TYPE_F &&
> + inst->src[1].imm.f == 1.0) {
> + inst->opcode = BRW_OPCODE_MOV;
> + inst->src[1] = reg_undef;
> + progress = true;
> + break;
> + }
> +
> + break;
> + }
> + }
> +
> + return progress;
> +}
> +
> /**
> * Must be called after calculate_live_intervales() to remove unused
> * writes to registers -- register allocation will fail otherwise
> @@ -1576,6 +1618,7 @@ fs_visitor::run()
>progress = remove_duplicate_mrf_writes() || progress;
>
>progress = propagate_constants() || progress;
> + progress = opt_algebraic() || progress;
>progress = register_coalesce() || progress;
>progress = compute_to_mrf() || progress;
>progress = dead_code_eliminate() || progress;
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 2bf850e..89d6cda 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -485,6 +485,7 @@ public:
> void setup_pull_constants();
> void calculate_live_intervals();
> bool propagate_constants();
> + bool opt_algebraic();
> bool register_coalesce();
> bool compute_to_mrf();
> bool dead_code_eliminate();
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4uHKAACgkQX1gOwKyEAw/pOACglSeXrx0tCrrsl6rlEtNX5z6p
vn4AoKCBsnI7sl1RwqE30VoclM/Zs/D/
=eeEb
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3 v2] Fix up some bits of GL_TEXTURE_INTERNAL_FORMAT interface
v2 fixes a spelling mistake in 3/3 noticed by Henri Verbeet. It also fixes the GL_COMPRESSED_RED and GL_COMPRESSED_RG base types, as pointed out by Brian Paul. Although these patches are going to miss the RC3 cut-off, I'd like to see them included in 7.11. They are pretty low impact. Opinions? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: Add utility function to get base format from a GL compressed format
From: Ian Romanick
---
src/mesa/main/texcompress.c | 88 +++
src/mesa/main/texcompress.h |3 +
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index d820ae9..040be94 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -40,6 +40,94 @@
/**
+ * Get the GL base format of a specified GL compressed texture format
+ *
+ * From page 232 of the OpenGL 3.3 (Compatiblity Profile) spec:
+ *
+ * "Compressed Internal Format Base Internal FormatType
+ * --- -
+ * COMPRESSED_ALPHAALPHA Generic
+ * COMPRESSED_LUMINANCELUMINANCE Generic
+ * COMPRESSED_LUMINANCE_ALPHA LUMINANCE_ALPHA Generic
+ * COMPRESSED_INTENSITYINTENSITY Generic
+ * COMPRESSED_RED RED Generic
+ * COMPRESSED_RG RG Generic
+ * COMPRESSED_RGB RGB Generic
+ * COMPRESSED_RGBA RGBAGeneric
+ * COMPRESSED_SRGB RGB Generic
+ * COMPRESSED_SRGB_ALPHA RGBAGeneric
+ * COMPRESSED_SLUMINANCE LUMINANCE Generic
+ * COMPRESSED_SLUMINANCE_ALPHA LUMINANCE_ALPHA Generic
+ * COMPRESSED_RED_RGTC1RED Specific
+ * COMPRESSED_SIGNED_RED_RGTC1 RED Specific
+ * COMPRESSED_RG_RGTC2 RG Specific
+ * COMPRESSED_SIGNED_RG_RGTC2 RG Specific"
+ *
+ * \return
+ * The base format of \c format if \c format is a compressed format (either
+ * generic or specific. Otherwise 0 is returned.
+ */
+GLenum
+_mesa_gl_compressed_format_base_format(GLenum format)
+{
+ switch (format) {
+ case GL_COMPRESSED_RED:
+ case GL_COMPRESSED_RED_RGTC1:
+ case GL_COMPRESSED_SIGNED_RED_RGTC1:
+ return GL_RED;
+
+ case GL_COMPRESSED_RG:
+ case GL_COMPRESSED_RG_RGTC2:
+ case GL_COMPRESSED_SIGNED_RG_RGTC2:
+ return GL_RG;
+
+ case GL_COMPRESSED_RGB:
+ case GL_COMPRESSED_SRGB:
+ case GL_COMPRESSED_RGB_S3TC_DXT1_EXT:
+ case GL_COMPRESSED_RGB_FXT1_3DFX:
+ case GL_COMPRESSED_SRGB_S3TC_DXT1_EXT:
+ return GL_RGB;
+
+ case GL_COMPRESSED_RGBA:
+ case GL_COMPRESSED_SRGB_ALPHA:
+ case GL_COMPRESSED_RGBA_BPTC_UNORM_ARB:
+ case GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB:
+ case GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB:
+ case GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB:
+ case GL_COMPRESSED_RGBA_S3TC_DXT1_EXT:
+ case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
+ case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
+ case GL_COMPRESSED_RGBA_FXT1_3DFX:
+ case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT:
+ case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT:
+ case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT:
+ return GL_RGBA;
+
+ case GL_COMPRESSED_ALPHA:
+ return GL_ALPHA;
+
+ case GL_COMPRESSED_LUMINANCE:
+ case GL_COMPRESSED_SLUMINANCE:
+ case GL_COMPRESSED_LUMINANCE_LATC1_EXT:
+ case GL_COMPRESSED_SIGNED_LUMINANCE_LATC1_EXT:
+ return GL_LUMINANCE;
+
+ case GL_COMPRESSED_LUMINANCE_ALPHA:
+ case GL_COMPRESSED_SLUMINANCE_ALPHA:
+ case GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT:
+ case GL_COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_EXT:
+ case GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI:
+ return GL_LUMINANCE_ALPHA;
+
+ case GL_COMPRESSED_INTENSITY:
+ return GL_INTENSITY;
+
+ default:
+ return 0;
+ }
+}
+
+/**
* Return list of (and count of) all specific texture compression
* formats that are supported.
*
diff --git a/src/mesa/main/texcompress.h b/src/mesa/main/texcompress.h
index 19b08bb..922da00 100644
--- a/src/mesa/main/texcompress.h
+++ b/src/mesa/main/texcompress.h
@@ -33,6 +33,9 @@ struct gl_context;
#if _HAVE_FULL_GL
+extern GLenum
+_mesa_gl_compressed_format_base_format(GLenum format);
+
extern GLuint
_mesa_get_compressed_formats(struct gl_context *ctx, GLint *formats, GLboolean
all);
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: Return the correct internal fmt when a generic compressed fmt was used
From: Ian Romanick
If an application requests a generic compressed format for a texture
and the driver does not pick a specific compressed format, return the
generic base format (e.g., GL_RGBA) for the GL_TEXTURE_INTERNAL_FORMAT
query.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3165
Cc: Brian Paul
---
src/mesa/main/texparam.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 4b9dcb5..c4ec295 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -915,9 +915,23 @@ _mesa_GetTexLevelParameteriv( GLenum target, GLint level,
*params = _mesa_compressed_format_to_glenum(ctx, texFormat);
}
else {
-/* return the user's requested internal format */
-*params = img->InternalFormat;
- }
+ /* If the true internal format is not compressed but the user
+* requested a generic compressed format, we have to return the
+* generic base format that matches.
+*
+* From page 119 (page 129 of the PDF) of the OpenGL 1.3 spec:
+*
+* "If no specific compressed format is available,
+* internalformat is instead replaced by the corresponding base
+* internal format."
+*
+* Otherwise just return the user's requested internal format
+*/
+ const GLenum f =
+ _mesa_gl_compressed_format_base_format(img->InternalFormat);
+
+ *params = (f != 0) ? f : img->InternalFormat;
+}
break;
case GL_TEXTURE_BORDER:
*params = img->Border;
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] mesa: Make _mesa_get_compressed_formats match the texture compression specs
From: Ian Romanick The implementation deviated slightly from the GL_EXT_texture_sRGB spec and from other implementations. A giant comment block was added to justify the somewhat odd behavior of this function. In addition, the interface had unnecessary cruft. The 'all' parameter was false at all callers, so it has been removed. --- src/mesa/main/get.c |4 +- src/mesa/main/texcompress.c | 117 +-- src/mesa/main/texcompress.h |2 +- 3 files changed, 93 insertions(+), 30 deletions(-) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index 0492e15..d32c68a 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -1569,11 +1569,11 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu break; case GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB: - v->value_int = _mesa_get_compressed_formats(ctx, NULL, GL_FALSE); + v->value_int = _mesa_get_compressed_formats(ctx, NULL); break; case GL_COMPRESSED_TEXTURE_FORMATS_ARB: v->value_int_n.n = -_mesa_get_compressed_formats(ctx, v->value_int_n.ints, GL_FALSE); +_mesa_get_compressed_formats(ctx, v->value_int_n.ints); ASSERT(v->value_int_n.n <= 100); break; diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c index 040be94..42bd1ee 100644 --- a/src/mesa/main/texcompress.c +++ b/src/mesa/main/texcompress.c @@ -131,16 +131,101 @@ _mesa_gl_compressed_format_base_format(GLenum format) * Return list of (and count of) all specific texture compression * formats that are supported. * + * Some formats are \b not returned by this function. The + * \c GL_COMPRESSED_TEXTURE_FORMATS query only returns formats that are + * "suitable for general-purpose usage." All texture compression extensions + * have taken this to mean either linear RGB or linear RGBA. + * + * The GL_ARB_texture_compress_rgtc spec says: + * + *"19) Should the GL_NUM_COMPRESSED_TEXTURE_FORMATS and + *GL_COMPRESSED_TEXTURE_FORMATS queries return the RGTC formats? + * + *RESOLVED: No. + * + *The OpenGL 2.1 specification says "The only values returned + *by this query [GL_COMPRESSED_TEXTURE_FORMATS"] are those + *corresponding to formats suitable for general-purpose usage. + *The renderer will not enumerate formats with restrictions that + *need to be specifically understood prior to use." + * + *Compressed textures with just red or red-green components are + *not general-purpose so should not be returned by these queries + *because they have restrictions. + * + *Applications that seek to use the RGTC formats should do so + *by looking for this extension's name in the string returned by + *glGetString(GL_EXTENSIONS) rather than + *what GL_NUM_COMPRESSED_TEXTURE_FORMATS and + *GL_COMPRESSED_TEXTURE_FORMATS return." + * + * There is nearly identical wording in the GL_EXT_texture_compression_rgtc + * spec. + * + * The GL_EXT_texture_rRGB spec says: + * + *"22) Should the new COMPRESSED_SRGB_* formats be listed in an + *implementation's GL_COMPRESSED_TEXTURE_FORMATS list? + * + *RESOLVED: No. Section 3.8.1 says formats listed by + *GL_COMPRESSED_TEXTURE_FORMATS are "suitable for general-purpose + *usage." The non-linear distribution of red, green, and + *blue for these sRGB compressed formats makes them not really + *general-purpose." + * + * The GL_EXT_texture_compression_latc spec says: + * + *"16) Should the GL_NUM_COMPRESSED_TEXTURE_FORMATS and + *GL_COMPRESSED_TEXTURE_FORMATS queries return the LATC formats? + * + *RESOLVED: No. + * + *The OpenGL 2.1 specification says "The only values returned + *by this query [GL_COMPRESSED_TEXTURE_FORMATS"] are those + *corresponding to formats suitable for general-purpose usage. + *The renderer will not enumerate formats with restrictions that + *need to be specifically understood prior to use." + * + *Historically, OpenGL implementation have advertised the RGB and + *RGBA versions of the S3TC extensions compressed format tokens + *through this mechanism. + * + *The specification is not sufficiently clear about what "suitable + *for general-purpose usage" means. Historically that seems to mean + *unsigned RGB or unsigned RGBA. The DXT1 format supporting alpha + *(GL_COMPRESSED_RGBA_S3TC_DXT1_EXT) is not exposed in the list (at + *least for NVIDIA drivers) because the alpha is always 1.0 expect + *when it is 0.0 when RGB is required to be black. NVIDIA's even + *limits itself to true linear RGB or RGBA formats, specifically + *not including EXT_texture_sRGB's sRGB S3TC compressed formats. + * + *Adding luminance and luminance-alpha texture formats (and + *
[Mesa-dev] [PATCH] i965/fs: Respect ARB_color_buffer_float clamping.
This was done in the old codegen path, but not the new one.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 9632aae..00f1e4a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1743,6 +1743,7 @@ void
fs_visitor::emit_color_write(int index, int first_color_mrf, fs_reg color)
{
int reg_width = c->dispatch_width / 8;
+ fs_inst *inst;
if (c->dispatch_width == 8 || intel->gen == 6) {
/* SIMD8 write looks like:
@@ -1761,8 +1762,10 @@ fs_visitor::emit_color_write(int index, int
first_color_mrf, fs_reg color)
* m + 6: a0
* m + 7: a1
*/
- emit(BRW_OPCODE_MOV, fs_reg(MRF, first_color_mrf + index * reg_width),
- color);
+ inst = emit(BRW_OPCODE_MOV,
+ fs_reg(MRF, first_color_mrf + index * reg_width),
+ color);
+ inst->saturate = c->key.clamp_fragment_color;
} else {
/* pre-gen6 SIMD16 single source DP write looks like:
* m + 0: r0
@@ -1780,16 +1783,22 @@ fs_visitor::emit_color_write(int index, int
first_color_mrf, fs_reg color)
* usual destination + 1 for the second half we get
* destination + 4.
*/
-emit(BRW_OPCODE_MOV,
- fs_reg(MRF, BRW_MRF_COMPR4 + first_color_mrf + index), color);
+inst = emit(BRW_OPCODE_MOV,
+fs_reg(MRF, BRW_MRF_COMPR4 + first_color_mrf + index),
+color);
+inst->saturate = c->key.clamp_fragment_color;
} else {
push_force_uncompressed();
-emit(BRW_OPCODE_MOV, fs_reg(MRF, first_color_mrf + index), color);
+inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, first_color_mrf + index),
+color);
+inst->saturate = c->key.clamp_fragment_color;
pop_force_uncompressed();
push_force_sechalf();
color.sechalf = true;
-emit(BRW_OPCODE_MOV, fs_reg(MRF, first_color_mrf + index + 4), color);
+inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, first_color_mrf + index + 4),
+color);
+inst->saturate = c->key.clamp_fragment_color;
pop_force_sechalf();
color.sechalf = false;
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3 v2] Fix up some bits of GL_TEXTURE_INTERNAL_FORMAT interface
On Mon, Jul 25, 2011 at 7:53 PM, Ian Romanick wrote: > v2 fixes a spelling mistake in 3/3 noticed by Henri Verbeet. It also fixes > the GL_COMPRESSED_RED and GL_COMPRESSED_RG base types, as pointed out by Brian > Paul. > > Although these patches are going to miss the RC3 cut-off, I'd like to see them > included in 7.11. They are pretty low impact. Opinions? OK by me. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().
On Tue, 26 Jul 2011 01:30:44 +0200, Henri Verbeet wrote:
> On 26 July 2011 01:02, Eric Anholt wrote:
> > I don't see that, because the while (buf < MaxDrawBuffers) loop would
> > notice the change from COLOR1 -> NONE.
> That loop doesn't happen because n == 1 for {COLOR0} (as opposed to
> {COLOR0, NONE}). Perhaps we should always explicitly set any remaining
> buffers to NONE though.
Ah, I see. I like this better than setting remaining buffers to NONE.
(and with this patch, we could avoid doing so, right?).
pgp7Zq7K4KAgG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] i965: Apply miptree workaround for very small depth buffers.
On Mon, 25 Jul 2011 17:07:09 -0700, Kenneth Graunke
wrote:
> According to the documentation for 3DSTATE_DEPTH_BUFFER (G45 and
> beyond), the 3 LSBs of "Depth Coordinate Offset X" (and Y) must be 0.
>
> Detect this and apply the Gen4 miptree hack for working around
> unsupported offsets.
>
> Fixes piglit test fbo-clear-formats for GL_ARB_depth_texture and
> GL_EXT_packed_depth_stencil on Ivybridge.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/intel/intel_fbo.c | 11 +--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
> b/src/mesa/drivers/dri/intel/intel_fbo.c
> index f00943e..7ea81e0 100644
> --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> @@ -649,7 +649,8 @@ intel_renderbuffer_tile_offsets(struct intel_renderbuffer
> *irb,
> #ifndef I915
> static bool
> need_tile_offset_workaround(struct brw_context *brw,
> - struct intel_renderbuffer *irb)
> + struct intel_renderbuffer *irb,
> + bool is_depthbuffer)
> {
> uint32_t tile_x, tile_y;
>
> @@ -658,6 +659,12 @@ need_tile_offset_workaround(struct brw_context *brw,
> if (!brw->has_surface_tile_offset)
>return tile_x != 0 || tile_y != 0;
>
> + /* In 3DSTATE_DEPTH_BUFFER, the 3 LSBs of Depth Coordinate Offset X/Y
> +* must be zero. We need the workaround in those cases.
> +*/
> + if (is_depthbuffer)
> + return (tile_x & 0x3) != 0 || (tile_y & 0x3) != 0;
> +
& 0x3 would be just checking 2 lsbs, right?
(which suggests that our analysis of this being the root cause of the
failure is wrong, since the 3rd lsb being set for the 2x2 mipmap didn't
fail)
pgppUULHOumeV.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 7.11 release candidate 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mesa 7.11-rc3 has been released. This is a release candidate for the 7.11 development release. The tag in the GIT repository for Mesa 7.11-rc3 is 'mesa-7.11-rc3'. Mesa 7.11-rc3 is available for download at ftp://freedesktop.org/pub/mesa/7.11/ md5sums: fb96d9bcd657b406e39bbf7f57a48a8e MesaLib-7.11-rc3.tar.gz af71accaed9059678c32e8ff1ba45423 MesaLib-7.11-rc3.tar.bz2 bfc6cfdb4322b822fcb0545954c3832c MesaLib-7.11-rc3.zip b37350115122531d7d59e4ca18b79759 MesaGLUT-7.11-rc3.tar.gz 4d1bbd3f5ea900aff6c8526b23261058 MesaGLUT-7.11-rc3.tar.bz2 9172cf0c82ecf4e610bc1947e0cd36b1 MesaGLUT-7.11-rc3.zip I have verified building from the .tar.bz2 file by doing: tar -xjf MesaLib-7.11-rc3.tar.bz2 cd Mesa-7.11-rc3 PKG_CONFIG_PATH=/opt/xorg-master-x86_64/lib64/pkgconfig/ ./configure PKG_CONFIG_PATH=/opt/xorg-master-x86_64/lib64/pkgconfig/ make -j6 The only changes in the 7.11 branch (until the final release) should be low-risk fixes for significant bugs. Other than updates to the release notes and changing the version, RC3 should represent 7.11 final. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4uLIAACgkQX1gOwKyEAw/VvgCfVf6Hb8lnMgHMajHZsvXla/P2 mGIAnjlAX6K65Xv0UG4OMtnCFP8sR4kj =n03a -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r300 problems in the 7.10.3 and 7.11 tarballs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2011 09:26 AM, Jeremy Huddleston wrote: > Can we please get a 7.10.4 release with this fixed? It's not a bug > in libarchive; you just get lucky that gnutar doesn't complain (which > I think *is* a bug in gnutar). Does this still occur in the 7.11-rc3 tarballs? I added the - --dereference option to tar to make it not include the symlinks. If that works, I'll cherry-pick the change to 7.10. If that doesn't work, can you suggest a better fix? I would like to do a 7.10.4, but I'm going to wait until after 7.11. There are some additional fixes in 7.11 that I'd like to pick over. > Some users are running into problems using gnutar with this archive, so > that's not really a great fallback either: > https://trac.macports.org/ticket/30058 > > There doesn't seem to be a good solution (I don't count zip) other than > rolling a new tarball (which will be nice to collect the rest of the 7.10 > branch patches anyway): > > $ tar -tvjf MesaLib-7.10.3.tar.bz2 | grep r300/compiler/memory_pool.c > -rw-rw-r-- 0 idridr 2671 May 20 01:31 > Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c > hrw-rw-r-- 0 idridr 0 May 20 01:31 > Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c link to > Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c > > The issue partly exists in 7.11-rc2, but we don't see it because it's just > including the file twice rather than including a symlink to itself: > > $ tar -tjvf MesaLib-7.11-rc2.tar.bz2 | grep memory_pool.c > -rw-rw-r-- 0 idridr 2671 Jul 8 18:37 > Mesa-7.11-rc2/src/mesa/drivers/dri/r300/compiler/memory_pool.c > -rw-rw-r-- 0 idridr 2671 Jul 8 18:37 > Mesa-7.11-rc2/src/mesa/drivers/dri/r300/compiler/memory_pool.c -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4uLikACgkQX1gOwKyEAw8IegCgkVE7XAIuytCViNYX9kZtPN0k P98AnjREk+DD3rY0qBXBDr2TDefvn+7a =+5Qd -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r300 problems in the 7.10.3 and 7.11 tarballs
On Jul 25, 2011, at 8:02 PM, Ian Romanick wrote: > >> Can we please get a 7.10.4 release with this fixed? It's not a bug >> in libarchive; you just get lucky that gnutar doesn't complain (which >> I think *is* a bug in gnutar). > > Does this still occur in the 7.11-rc3 tarballs? It's the same as the 7.11-rc2 tarballs. The files are included twice: $ tar -tjvf mesa/MesaLib-7.11-rc3.tar.bz2 | grep memory_pool.c -rw-rw-r-- 0 idridr 2671 Jul 8 18:37 Mesa-7.11-rc3/src/mesa/drivers/dri/r300/compiler/memory_pool.c -rw-rw-r-- 0 idridr 2671 Jul 8 18:37 Mesa-7.11-rc3/src/mesa/drivers/dri/r300/compiler/memory_pool.c > I added the > - --dereference option to tar to make it not include the symlinks. If > that works, I'll cherry-pick the change to 7.10. If that doesn't work, > can you suggest a better fix? That works to not include them as bogus symlinks, but why not just only include the files once? Why are they being listed twice? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 3
I see the tarballs, but there doesn't seem to be a mesa-7.11-rc3 tag in git and 7.11 branch doesn't seem to have had a version bump commit. Has someone forgotten to push? signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
