Re: [Mesa-dev] libxml2 (python) dependency
Ian Romanick [2011-04-18 17:12]: On 04/18/2011 04:48 PM, tom fogal wrote: Hey all, We recently became more aware of a dependency on python's libxml2 for building Mesa. We're not as proactive as we should be, but tend to upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10. Anyway, libxml2 is a bit arduous for us because it's not installed by default on Linux or Mac. On Linux, it's easy to grab via a package manager, but still does not exist by default on some distros. In general, non-standard dependencies are difficult because they make our (already very large) software stack more complex. Is the package truly needed? I think it's used to parse spec files and autogenerate trampolines or callbacks or something like that. Didn't we used to have plain text files for that? Any reason we can't go back to something simpler? Does code speak loud than words, here? :) We haven't used plain-text for years. What has changed is that the generated files are no longer tracked in source control. They are generated at compile time because anything else is just nuts. :) I know What about generating them at 'make dist' time, too...? That way the Python dependency would only hit developers, but not people building from proper release tarballs. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpjx3PBUSH70.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r128: fix lockups (bug #9379)
Hi,
I found this patch by Andrew Péteri on the bugtracker (#9379), it seems
like it's still incomplete (projective textures were disabled), but it
fixes a lockup problems with r128 (like the game cube, some farbrausch
demos and gta vice city in wine (not very fast but meh) works now).
--- a/src/mesa/drivers/dri/r128/r128_span.c 2009-01-22
18:38:33.0 +0100
+++ b/src/mesa/drivers/dri/r128/r128_span.c 2009-04-19
13:24:48.0 +0200
@@ -122,12 +122,6 @@
* Depth buffer
*/
-/* These functions require locking */
-#undef HW_LOCK
-#undef HW_UNLOCK
-#define HW_LOCK()LOCK_HARDWARE(R128_CONTEXT(ctx));
-#define HW_UNLOCK() UNLOCK_HARDWARE(R128_CONTEXT(ctx));
-
/* 16-bit depth buffer functions
*/
#define VALUE_TYPE GLushort
--- a/src/mesa/drivers/dri/r128/r128_tris.c 2009-01-22
18:38:33.0 +0100
+++ b/src/mesa/drivers/dri/r128/r128_tris.c 2009-04-18
19:31:36.0 +0200
@@ -48,6 +48,7 @@
#include r128_state.h
#include r128_tex.h
#include r128_ioctl.h
+#include r128_lock.h
static const GLuint hw_prim[GL_POLYGON+1] = {
R128_CCE_VC_CNTL_PRIM_TYPE_POINT,
@@ -349,7 +350,9 @@
_swsetup_Translate( ctx, v0, v[0] );
_swsetup_Translate( ctx, v1, v[1] );
_swsetup_Translate( ctx, v2, v[2] );
+ LOCK_HARDWARE( rmesa );
_swrast_Triangle( ctx, v[0], v[1], v[2] );
+ UNLOCK_HARDWARE( rmesa );
}
@@ -362,7 +365,9 @@
SWvertex v[2];
_swsetup_Translate( ctx, v0, v[0] );
_swsetup_Translate( ctx, v1, v[1] );
+ LOCK_HARDWARE( rmesa );
_swrast_Line( ctx, v[0], v[1] );
+ UNLOCK_HARDWARE( rmesa );
}
@@ -373,7 +378,9 @@
GLcontext *ctx = rmesa-glCtx;
SWvertex v[1];
_swsetup_Translate( ctx, v0, v[0] );
+ LOCK_HARDWARE( rmesa );
_swrast_Point( ctx, v[0] );
+ UNLOCK_HARDWARE( rmesa );
}
@@ -661,7 +668,12 @@
}
/* projectivetextur es are not supported by the hardware */
- FALLBACK( rmesa, R128_FALLBACK_PROJTEX, fallback_projtex );
+ // FALLBACK( rmesa, R128_FALLBACK_PROJTEX, fallback_projtex );
+ //
+ // if (fallback_projtex) {
+ // tnl-Driver.Render.Start(ctx);
+ // return;
+ // }
/* Only need to change the vertex emit code if there has been a
* statechange to a TNL index.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36341] Mesa can't find ubuntu llvm
https://bugs.freedesktop.org/show_bug.cgi?id=36341 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #4 from Fabio Pedretti fabio@libero.it 2011-04-19 00:15:49 PDT --- (In reply to comment #3) Have you installed llvm package? It provides llvm-config (without suffix) and others as symlinks to llvm-2.8 versions on my ubuntu system. You are right here. Strange however that llvm-dev doesn't depend on it. -- 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] libxml2 (python) dependency
On Mon, Apr 18, 2011 at 4:48 PM, tom fogal tfo...@sci.utah.edu wrote: Hey all, We recently became more aware of a dependency on python's libxml2 for building Mesa. We're not as proactive as we should be, but tend to upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10. Anyway, libxml2 is a bit arduous for us because it's not installed by default on Linux or Mac. On Linux, it's easy to grab via a package manager, but still does not exist by default on some distros. In general, non-standard dependencies are difficult because they make our (already very large) software stack more complex. Is the package truly needed? I think it's used to parse spec files and autogenerate trampolines or callbacks or something like that. Didn't we used to have plain text files for that? Any reason we can't go back to something simpler? Does code speak loud than words, here? :) Python comes with three or four different XML parsers, and of those, etree is both relatively speedy and sane. Certainly easier to handle than libxml2 directly. If people want it to be even speedier, there's a libxml2 library for Python, lxml, which has the etree API and is quite nice. This has been on my TODO list for a year or so, but no real useful work has been made. Knowing that people actually care about it gives me some incentive, but I can't promise anything. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults (swrast, r600g, nouveau_vieux)
https://bugs.freedesktop.org/show_bug.cgi?id=36282 Marc marvi...@gmx.de changed: What|Removed |Added CC||marvi...@gmx.de --- Comment #11 from Marc marvi...@gmx.de 2011-04-19 01:40:14 PDT --- only happens here when shared-glapi is enabled (r600g) -- 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] RV730 support for Big Endian platforms
Hi Few days ago, I posted a couple of patches on dri-devel but it doesn't seem to be the correct place. Here you are 2 patches that adds support for RV730 in r600c and r600g. More details are available here : http://lists.freedesktop.org/archives/dri-devel/2011-April/010056.html http://lists.freedesktop.org/archives/dri-devel/2011-April/010281.html Regards, Cedric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms
Signed-off-by: Cedric Canoccano at interfaceconcept.com
---
diff -Naur Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h
Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h
--- Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h 2010-02-05
01:10:40.0 +0100
+++ Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h 2011-04-07
16:19:50.0 +0200
@@ -29,8 +29,8 @@
#define _DEFINEENDIAN_H_
//We have to choose a reg bits orientation if there is no compile flag for it.
-#if defined(LITTLEENDIAN_CPU)
-#elif defined(BIGENDIAN_CPU)
+#ifdef MESA_BIG_ENDIAN
+#define BIGENDIAN_CPU
#else
#define LITTLEENDIAN_CPU
#endif
diff -Naur Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c
Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c
--- Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c 2010-12-14
22:43:15.0 +0100
+++ Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c 2011-04-11
16:43:40.0 +0200
@@ -94,17 +94,17 @@
{
uint32_t cb_color0_base, cb_color0_size = 0, cb_color0_info = 0,
cb_color0_view = 0;
int id = 0;
-uint32_t comp_swap, format;
+uint32_t endian, comp_swap, format;
BATCH_LOCALS(context-radeon);
cb_color0_base = dst_offset / 256;
+ endian = ENDIAN_NONE;
SETfield(cb_color0_size, (nPitchInPixel / 8) - 1,
PITCH_TILE_MAX_shift, PITCH_TILE_MAX_mask);
SETfield(cb_color0_size, ((nPitchInPixel * h) / 64) - 1,
SLICE_TILE_MAX_shift, SLICE_TILE_MAX_mask);
-SETfield(cb_color0_info, ENDIAN_NONE, ENDIAN_shift, ENDIAN_mask);
SETfield(cb_color0_info, ARRAY_LINEAR_GENERAL,
CB_COLOR0_INFO__ARRAY_MODE_shift,
CB_COLOR0_INFO__ARRAY_MODE_mask);
@@ -112,24 +112,36 @@
switch(mesa_format) {
case MESA_FORMAT_RGBA:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN32;
+#endif
format = COLOR_8_8_8_8;
comp_swap = SWAP_STD_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_SIGNED_RGBA:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN32;
+#endif
format = COLOR_8_8_8_8;
comp_swap = SWAP_STD_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_SNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_RGBA_REV:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN32;
+#endif
format = COLOR_8_8_8_8;
comp_swap = SWAP_STD;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_SIGNED_RGBA_REV:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN32;
+#endif
format = COLOR_8_8_8_8;
comp_swap = SWAP_STD;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
@@ -137,6 +149,9 @@
break;
case MESA_FORMAT_ARGB:
case MESA_FORMAT_XRGB:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN32;
+#endif
format = COLOR_8_8_8_8;
comp_swap = SWAP_ALT;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
@@ -144,54 +159,81 @@
break;
case MESA_FORMAT_ARGB_REV:
case MESA_FORMAT_XRGB_REV:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN32;
+#endif
format = COLOR_8_8_8_8;
comp_swap = SWAP_ALT_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_RGB565:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN16;
+#endif
+ comp_swap = SWAP_STD_REV;
format = COLOR_5_6_5;
-comp_swap = SWAP_STD_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_RGB565_REV:
-format = COLOR_5_6_5;
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN16;
+#endif
comp_swap = SWAP_STD;
+format = COLOR_5_6_5;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_ARGB:
+#ifdef MESA_BIG_ENDIAN
+ endian = ENDIAN_8IN16;
+#endif
format = COLOR_4_4_4_4;
comp_swap = SWAP_ALT;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift,
NUMBER_TYPE_mask);
break;
case MESA_FORMAT_ARGB_REV:
+#ifdef MESA_BIG_ENDIAN
+
Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms
Signed-off-by: Cedric Canoccano at interfaceconcept.com
---
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index c22bd8e..7e854b1 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -22,6 +22,7 @@
*/
#include stdio.h
#include errno.h
+#include byteswap.h
#include util/u_format.h
#include util/u_memory.h
#include pipe/p_shader_tokens.h
@@ -32,6 +33,12 @@
#include r600_formats.h
#include r600d.h
+#ifdef PIPE_ARCH_BIG_ENDIAN
+#define CPU_TO_LE32(x)bswap_32(x)
+#else
+#define CPU_TO_LE32(x)(x)
+#endif
+
#define NUM_OF_CYCLES 3
#define NUM_OF_COMPONENTS 4
@@ -1383,6 +1390,7 @@ static int r600_bc_vtx_build(struct r600_bc *bc,
struct r600_bc_vtx *vtx, unsign
S_SQ_VTX_WORD1_SRF_MODE_ALL(vtx-srf_mode_all) |
S_SQ_VTX_WORD1_GPR_DST_GPR(vtx-dst_gpr);
bc-bytecode[id++] = S_SQ_VTX_WORD2_OFFSET(vtx-offset) |
+ S_SQ_VTX_WORD2_ENDIAN_SWAP(vtx-endian) |
S_SQ_VTX_WORD2_MEGA_FETCH(1);
bc-bytecode[id++] = 0;
return 0;
@@ -1917,6 +1925,7 @@ void r600_bc_dump(struct r600_bc *bc)
fprintf(stderr, MODE:%d)\n, vtx-srf_mode_all);
id++;
fprintf(stderr, %04d %08X , id, bc-bytecode[id]);
+fprintf(stderr, ENDIAN:%d , vtx-endian);
fprintf(stderr, OFFSET:%d\n, vtx-offset);
//TODO
id++;
@@ -1929,7 +1938,7 @@ void r600_bc_dump(struct r600_bc *bc)
}
static void r600_vertex_data_type(enum pipe_format pformat, unsigned
*format,
-unsigned *num_format, unsigned *format_comp)
+unsigned *num_format, unsigned *format_comp, unsigned
*endian)
{
const struct util_format_description *desc;
unsigned i;
@@ -1937,6 +1946,7 @@ static void r600_vertex_data_type(enum pipe_format
pformat, unsigned *format,
*format = 0;
*num_format = 0;
*format_comp = 0;
+*endian = ENDIAN_NONE;
desc = util_format_description(pformat);
if (desc-layout != UTIL_FORMAT_LAYOUT_PLAIN) {
@@ -1967,6 +1977,9 @@ static void r600_vertex_data_type(enum pipe_format
pformat, unsigned *format,
*format = FMT_16_16_16_16_FLOAT;
break;
}
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN16;
+#endif
break;
case 32:
switch (desc-nr_channels) {
@@ -1983,6 +1996,9 @@ static void r600_vertex_data_type(enum pipe_format
pformat, unsigned *format,
*format = FMT_32_32_32_32_FLOAT;
break;
}
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN32;
+#endif
break;
default:
goto out_unknown;
@@ -2020,6 +2036,9 @@ static void r600_vertex_data_type(enum pipe_format
pformat, unsigned *format,
*format = FMT_16_16_16_16;
break;
}
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN16;
+#endif
break;
case 32:
switch (desc-nr_channels) {
@@ -2036,6 +2055,9 @@ static void r600_vertex_data_type(enum pipe_format
pformat, unsigned *format,
*format = FMT_32_32_32_32;
break;
}
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN32;
+#endif
break;
default:
goto out_unknown;
@@ -2067,7 +2089,7 @@ int r600_vertex_elements_build_fetch_shader(struct
r600_pipe_context *rctx, stru
struct pipe_vertex_element *elements = ve-elements;
const struct util_format_description *desc;
unsigned fetch_resource_start = rctx-family = CHIP_CEDAR ? 0 : 160;
-unsigned format, num_format, format_comp;
+unsigned format, num_format, format_comp, endian;
u32 *bytecode;
int i, r;
@@ -2114,7 +2136,7 @@ int r600_vertex_elements_build_fetch_shader(struct
r600_pipe_context *rctx, stru
for (i = 0; i ve-count; i++) {
unsigned vbuffer_index;
-r600_vertex_data_type(ve-elements[i].src_format, format,
num_format, format_comp);
+r600_vertex_data_type(ve-elements[i].src_format, format,
num_format, format_comp, endian);
desc = util_format_description(ve-elements[i].src_format);
if (desc == NULL) {
r600_bc_clear(bc);
@@ -2140,6 +2162,7 @@ int r600_vertex_elements_build_fetch_shader(struct
r600_pipe_context *rctx, stru
vtx.format_comp_all = format_comp;
vtx.srf_mode_all = 1;
vtx.offset = elements[i].src_offset;
+vtx.endian = endian;
if ((r = r600_bc_add_vtx(bc, vtx))) {
r600_bc_clear(bc);
@@ -2179,7 +2202,9 @@ int r600_vertex_elements_build_fetch_shader(struct
r600_pipe_context *rctx, stru
return -ENOMEM;
}
-memcpy(bytecode, bc.bytecode, ve-fs_size);
+for(i = 0; i ve-fs_size / 4; i++) {
+*(bytecode + i) = CPU_TO_LE32(*(bc.bytecode + i));
+
[Mesa-dev] [Bug 36384] New: configure tips
https://bugs.freedesktop.org/show_bug.cgi?id=36384 Summary: configure tips Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: fabio@libero.it 1) what about renaming swrastg_dri.so to swrast_dri.so so that it is consistent with the other gallium drivers (r300/r600) and one doesn't need to rename it when installing? It is already clear it's a gallium driver since it's inside lib/gallium. 2) --enable-gallium-radeon should probably be changed to --enable-gallium-r300: --enable-gallium-r300 build gallium r300 [default=disabled] 3) this should say 'build gallium r600': --enable-gallium-r600 build gallium radeon [default=disabled] (Even better the gallium drivers should be enabled with something similar to --with-dri-drivers=... ) -- 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] Big endian support for RV730 (Gallium r600g)
[ Moving to the mesa-dev list ]
On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote:
Here you are a patch that adds big endian support for rv730 in r600
gallium driver.
I used the mesa-demos to test the driver status on big endian platform.
Except with demos using accumulation buffer, the rendering is the same
as on Intel platform. Albeit there are still some artefacts with some
demos.
I manage to fix accumulation buffer demos but then, glReadPixels demos
won't work. I still can figure out (like with r600c) what and when I
must enable swap. It will depends on object's domains. That's what I
tried to do in r600_cb and r600_create_sampler_view.
That's probably because it hasn't been fully thought through yet how to
deal with big endian CPUs vs. little endian GPUs in Gallium. When this
was discussed previously, the basic rule decided was that all data
passed across the Gallium driver interface was supposed to be little
endian. That should probably be feasible in general for at least
'standard' pixel formats, but I'm afraid it doesn't really work for
vertex data[0], which could be fed from the application (which will use
CPU native byte order) to the GPU more or less directly.
Maybe byte order should be handled explicitly by the Gallium format
definitions, and then it would be up to the state tracker to use the
appropriate byte order formats. José, have you had any further thoughts
on this?
[0] Though there might also be ambiguities e.g. with multi-byte
component pixel formats: Does the little endian rule apply to the pixel
value as a whole, or only for each component?
@@ -266,11 +268,31 @@ void r600_upload_const_buffer(struct r600_pipe_context
*rctx, struct r600_resour
uint8_t *ptr = (*rbuffer)-r.b.user_ptr;
unsigned size = (*rbuffer)-r.b.b.b.width0;
boolean flushed;
+#ifdef PIPE_ARCH_BIG_ENDIAN
+ int i;
+ uint32_t *tmpPtr;
+
+ *rbuffer = NULL;
+
+ tmpPtr = (uint32_t *)malloc(size);
+ /* big endian swap */
+ if(tmpPtr == NULL) {
+ return;
+ }
+ for(i = 0; i size / 4; i++) {
+ tmpPtr[i] = bswap_32(*((uint32_t *)ptr + i));
+ }
+
+ u_upload_data(rctx-vbuf_mgr-uploader, 0, size, tmpPtr,
const_offset,
+ (struct pipe_resource**)rbuffer, flushed);
Might be better to add a helper like u_upload_data_to_le32().
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment
On 16.04.2011 18:50, Christoph Bumiller wrote:
I hope the new version is correct, the commit message describes why I
did the first change, and the second change is described in a comment.
Note that the MAD for inversion uses Height - 1 instead of Height.
With this, piglit glsl-arb-fragment-coord-conventions and
fbo-depth-sample-compare pass on nvc0.
I was assuming that integer pixel centers for size 100 range from 0 to
99 and half-integer pixel centers from 0.5 to 99.5.
Attached a better version of the patch, potentially saving an
instruction and avoiding precision issues with NEAREST filtering that
made piglit's blending-in-shader fail.
The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was r600
classic, which should also work more correctly now since (at least
according to gallium caps) it uses half-integer pixel center, and for
H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5.
Please review.
Christoph
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From 0214363d8bfc1084b93f4c2541c483313caafbc4 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Tue, 19 Apr 2011 11:54:41 +0200
Subject: [PATCH] mesa,st/mesa: fix WPOS adjustment
---
src/mesa/program/prog_statevars.c|4 ++--
src/mesa/program/prog_statevars.h|2 +-
src/mesa/state_tracker/st_mesa_to_tgsi.c |4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index 1fd26f4..d94d7fe 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -602,11 +602,11 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
value[0] = 1.0F;
value[1] = 0.0F;
value[2] = -1.0F;
-value[3] = (GLfloat) (ctx-DrawBuffer-Height - 1);
+value[3] = (GLfloat) ctx-DrawBuffer-Height;
} else {
/* Flipping Y upside down (XY) followed by identity (ZW). */
value[0] = -1.0F;
-value[1] = (GLfloat) (ctx-DrawBuffer-Height - 1);
+value[1] = (GLfloat) ctx-DrawBuffer-Height;
value[2] = 1.0F;
value[3] = 0.0F;
}
diff --git a/src/mesa/program/prog_statevars.h
b/src/mesa/program/prog_statevars.h
index 9fe8d81..04af3f4 100644
--- a/src/mesa/program/prog_statevars.h
+++ b/src/mesa/program/prog_statevars.h
@@ -120,7 +120,7 @@ typedef enum gl_state_index_ {
STATE_PT_BIAS, /** Pixel transfer RGBA bias */
STATE_SHADOW_AMBIENT,/** ARB_shadow_ambient fail value; token[2]
is texture unit index */
STATE_FB_SIZE, /** (width-1, height-1, 0, 0) */
- STATE_FB_WPOS_Y_TRANSFORM, /** (1, 0, -1, height-1) if a FBO is bound,
(-1, height-1, 1, 0) otherwise */
+ STATE_FB_WPOS_Y_TRANSFORM, /** (1, 0, -1, height) if a FBO is bound,
(-1, height, 1, 0) otherwise */
STATE_ROT_MATRIX_0, /** ATI_envmap_bumpmap, rot matrix row 0 */
STATE_ROT_MATRIX_1, /** ATI_envmap_bumpmap, rot matrix row 1 */
STATE_INTERNAL_DRIVER /* first available state index for drivers
(must be last) */
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index c07739f..21c5c82 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -883,7 +883,7 @@ emit_wpos(struct st_context *st,
ureg_property_fs_coord_pixel_center(ureg,
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
else if (pscreen-get_param(pscreen,
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER))
/* the driver supports pixel center half integer, need to bias X,Y */
- emit_adjusted_wpos(t, program, 0.5f, invert ? 0.5f : -0.5f);
+ emit_adjusted_wpos(t, program, -0.5f, -0.5f);
else
assert(0);
}
@@ -895,7 +895,7 @@ emit_wpos(struct st_context *st,
else if (pscreen-get_param(pscreen,
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER)) {
/* the driver supports pixel center integer, need to bias X,Y */
ureg_property_fs_coord_pixel_center(ureg,
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
- emit_adjusted_wpos(t, program, 0.5f, invert ? -0.5f : 0.5f);
+ emit_adjusted_wpos(t, program, 0.5f, 0.5f);
}
else
assert(0);
--
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] r200: enable EXT_gpu_program_parameters
OK, thanks for testing. I have pushed the patch. Marek On Tue, Apr 19, 2011 at 11:54 AM, Nicolas Kaiser ni...@nikai.net wrote: * Ian Romanick i...@freedesktop.org: ./src/demos/vao_demo GL_RENDERER = Mesa DRI R200 (R200 514D) TCL DRI2 GL_VERSION = 1.3 Mesa 7.11-devel (git-4ee40c3) Do we have VAO (either ARB or APPLE) in piglit? That would actually be a more interesting test. The Mesa demos exercise extensions pretty minimally in most cases. I found two piglit tests, general/vao-01 and general/vao-02. ./piglit-run.py -t vao tests/all.tests results/vao.results With Marek's patch, they pass: ./piglit-run.py -t vao tests/all.tests results/vao.enabled.results ./piglit-summary-html.py summary/compare.vao results/vao.results results/vao.enabled.results vao.results vao.enabled.results All 0/0 2/2 general 0/0 2/2 vao-01 skippass vao-02 skippass Best regards, Nicolas Kaiser ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment
On Die, 2011-04-19 at 12:00 +0200, Christoph Bumiller wrote: On 16.04.2011 18:50, Christoph Bumiller wrote: I hope the new version is correct, the commit message describes why I did the first change, and the second change is described in a comment. Note that the MAD for inversion uses Height - 1 instead of Height. With this, piglit glsl-arb-fragment-coord-conventions and fbo-depth-sample-compare pass on nvc0. I was assuming that integer pixel centers for size 100 range from 0 to 99 and half-integer pixel centers from 0.5 to 99.5. Attached a better version of the patch, potentially saving an instruction and avoiding precision issues with NEAREST filtering that made piglit's blending-in-shader fail. The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was r600 classic, which should also work more correctly now since (at least according to gallium caps) it uses half-integer pixel center, and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5. FWIW, this fixes compiz alpha-blurred contents being off by one vertically on r300g. Thanks! -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36384] configure tips
https://bugs.freedesktop.org/show_bug.cgi?id=36384 --- Comment #1 from Marek Olšák mar...@gmail.com 2011-04-19 03:45:45 PDT --- (2) and (3) is done. I leave (1) to swrastg maintainers. -- 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] st/mesa: fix WPOS adjustment
2011/4/19 Michel Dänzer mic...@daenzer.net On Die, 2011-04-19 at 12:00 +0200, Christoph Bumiller wrote: On 16.04.2011 18:50, Christoph Bumiller wrote: I hope the new version is correct, the commit message describes why I did the first change, and the second change is described in a comment. Note that the MAD for inversion uses Height - 1 instead of Height. With this, piglit glsl-arb-fragment-coord-conventions and fbo-depth-sample-compare pass on nvc0. I was assuming that integer pixel centers for size 100 range from 0 to 99 and half-integer pixel centers from 0.5 to 99.5. Attached a better version of the patch, potentially saving an instruction and avoiding precision issues with NEAREST filtering that made piglit's blending-in-shader fail. The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was r600 classic, which should also work more correctly now since (at least according to gallium caps) it uses half-integer pixel center, and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5. FWIW, this fixes compiz alpha-blurred contents being off by one vertically on r300g. Thanks! If that's true, it should be a candidate for 7.10 as well. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: track dirty registers better.
Le 18/04/2011 16:37, Benjamin BELLEC a écrit : Le 18/04/2011 10:20, Dave Airlie a écrit : On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This is a first step to decreasing the CPU usage, by decreasing how much stuff we pass to the GPU and hence to the kernel CS checker. This adds a check to see if the values we need to write are actually dirty, and avoids writing if they are. However certain register need to always be written so we add a new flag to say which ones should be always written if used. (Note this could probably be done cleaner with a larger refactoring, since I think the CONST_BUFFER_SIZE_PS/VS and CONST_CACHE_PS/VS might be better off as a special state). It also moves the need_bo to be a flags on the register now. With this, a frame of gears goes from emitting 3k dwords to emitting 2k dwords, and I'm sure it could get a lot smaller. TODO: Currently we flush if we have a BO, this could probably be improved. Drop the special flush flag and move the buffer size ps/vs to a special state. I've pushed a v2 of this to the r600g-dirty branch in my repo with another couple of patches on top the v2 just fixes the evergreen paths. The other patches cause regressions, but decrease further the amount of dwords per frame which should decrease time in the kernel parser, just have to figure out the regressions. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Hello, I just test your branch, it breaks the 3 apps I tested : - glxgears, I do not see gears. I can see them quickly by moving the window at the border of my screen - nexuiz-sdl : the menu is break. (not tested ingame) - etqw : the menu is break too. In game, I have phantom frame. This is hard to describe, and I have no screenshots to show you exactly. To sum up, I have the impression that the frames are mixed. I will test your future patches (if any). Benjamin All is now fixed. Also, I have 15.50 % of framerate improvements in nexuiz-sdl on my system (x86 - RV770 - 1680*1050 - No HDR - No sound) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)
- Original Message - From: Michel Dänzer mic...@daenzer.net To: Cédric Cano cc...@interfaceconcept.com Cc: icthj tjour...@interfaceconcept.com, mesa-dev@lists.freedesktop.org Sent: Tuesday, April 19, 2011 10:39:41 AM Subject: Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g) [ Moving to the mesa-dev list ] On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote: Here you are a patch that adds big endian support for rv730 in r600 gallium driver. I used the mesa-demos to test the driver status on big endian platform. Except with demos using accumulation buffer, the rendering is the same as on Intel platform. Albeit there are still some artefacts with some demos. I manage to fix accumulation buffer demos but then, glReadPixels demos won't work. I still can figure out (like with r600c) what and when I must enable swap. It will depends on object's domains. That's what I tried to do in r600_cb and r600_create_sampler_view. That's probably because it hasn't been fully thought through yet how to deal with big endian CPUs vs. little endian GPUs in Gallium. When this was discussed previously, the basic rule decided was that all data passed across the Gallium driver interface was supposed to be little endian. That should probably be feasible in general for at least 'standard' pixel formats, but I'm afraid it doesn't really work for vertex data[0], which could be fed from the application (which will use CPU native byte order) to the GPU more or less directly. Maybe byte order should be handled explicitly by the Gallium format definitions, and then it would be up to the state tracker to use the appropriate byte order formats. José, have you had any further thoughts on this? I'm not sure either. The design principle we've used in the past for this in the past is to match what the hardware can and cannot do. It appears from Cédric's patch that r600 is able to toggle between bit/little ending values in vertices. Vertex/index buffers are indeed special because, unlike pixel data, the types can only be inferred at draw time, and not at data upload, so transcoding at BufferMap/BufferData is not really feasible. Does other hardware allow to toggle vertex data reads between little/big endian? If so then perhaps a per-vertex-element state bit indicating endianness might be sensible. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libxml2 (python) dependency
On Mon, Apr 18, 2011 at 11:14 PM, Tilman Sauerbeck til...@code-monkey.de wrote: Ian Romanick [2011-04-18 17:12]: On 04/18/2011 04:48 PM, tom fogal wrote: Hey all, We recently became more aware of a dependency on python's libxml2 for building Mesa. We're not as proactive as we should be, but tend to upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10. Anyway, libxml2 is a bit arduous for us because it's not installed by default on Linux or Mac. On Linux, it's easy to grab via a package manager, but still does not exist by default on some distros. In general, non-standard dependencies are difficult because they make our (already very large) software stack more complex. Is the package truly needed? I think it's used to parse spec files and autogenerate trampolines or callbacks or something like that. Didn't we used to have plain text files for that? Any reason we can't go back to something simpler? Does code speak loud than words, here? :) We haven't used plain-text for years. What has changed is that the generated files are no longer tracked in source control. They are generated at compile time because anything else is just nuts. :) I know What about generating them at 'make dist' time, too...? That way the Python dependency would only hit developers, but not people building from proper release tarballs. I think this is a good idea, but it might be a little difficult with the mesa build machinery. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36384] configure tips
https://bugs.freedesktop.org/show_bug.cgi?id=36384 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added CC||wallbra...@gmail.com --- Comment #2 from Brian Paul brian.e.p...@gmail.com 2011-04-19 06:54:55 PDT --- I believe George and Jakob should sign off on #1. Cc'ing them. -- 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 36384] configure tips
https://bugs.freedesktop.org/show_bug.cgi?id=36384 --- Comment #3 from Brian Paul brian.e.p...@gmail.com 2011-04-19 06:56:18 PDT --- Hmmm, I can't seem to add George Sapountzis gsapount...@gmail.com to the cc list. -- 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 05/10] mesa: Add renderbuffer accessors for A, I, L, FLOAT32.
On 04/18/2011 02:37 PM, Eric Anholt wrote:
Of these, intel will be using I and L initially, and A once we rewrite
fragment shaders and the CC for rendering to it as R.
---
src/mesa/main/renderbuffer.c | 218 ++
1 files changed, 218 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/renderbuffer.c b/src/mesa/main/renderbuffer.c
index 7826e44..2fa9e27 100644
--- a/src/mesa/main/renderbuffer.c
+++ b/src/mesa/main/renderbuffer.c
@@ -1114,6 +1114,194 @@ get_values_rg1616(struct gl_context *ctx, struct
gl_renderbuffer *rb,
}
/**
+ * Functions for MESA_FORMAT_INTENSITY_FLOAT32.
+ */
+static void
+get_row_i_float32(struct gl_context *ctx, struct gl_renderbuffer *rb,
+ GLuint count, GLint x, GLint y, void *values)
+{
+ const GLfloat *src = rb-GetPointer(ctx, rb, x, y);
+ GLfloat *dst = values;
+ GLuint i;
+
+ for (i = 0; i count; i++) {
+ dst[i * 4 + RCOMP] = src[i];
+ dst[i * 4 + GCOMP] = dst[i * 4 + RCOMP];
+ dst[i * 4 + BCOMP] = dst[i * 4 + RCOMP];
+ dst[i * 4 + ACOMP] = dst[i * 4 + RCOMP];
Just a small nit, but I'd write this as follows:
for (i = 0; i count; i++) {
dst[i * 4 + RCOMP] =
dst[i * 4 + GCOMP] =
dst[i * 4 + BCOMP] =
dst[i * 4 + ACOMP] = src[i];
}
It's less typing and seeing dst[] on the RHS is a little distracting
at first glance.
Otherwise, for the series:
Reviewed-by: Brian Paul bri...@vmware.com
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] docs: Update for Intel ARB_texture_float and ARB_color_buffer_float.
On 04/18/2011 02:53 PM, Eric Anholt wrote: --- docs/relnotes-7.11.html |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/relnotes-7.11.html b/docs/relnotes-7.11.html index 131fecd..2bd126c 100644 --- a/docs/relnotes-7.11.html +++ b/docs/relnotes-7.11.html @@ -36,21 +36,21 @@ tbd h2New features/h2 ul -liGL_ARB_color_buffer_float (gallium drivers) +liGL_ARB_color_buffer_float (gallium drivers, i965) liGL_ARB_draw_buffers_blend (gallium) liGL_ARB_draw_instanced extension (gallium drivers, swrast) liGL_ARB_instanced_arrays extension (gallium drivers) liGL_ARB_occlusion_query2 (gallium drivers, swrast) liGL_ARB_sampler_objects (gallium drivers) liGL_ARB_texture_compression_rgtc (gallium drivers, swrast) -liGL_ARB_texture_float (gallium) +liGL_ARB_texture_float (gallium, i965) liGL_EXT_texture_compression_latc (gallium drivers, swrast) liGL_EXT_texture_compression_rgtc (gallium drivers, swrast) liGL_EXT_texture_sRGB_decode (gallium drivers, swrast, i965) liGL_EXT_texture_snorm (gallium drivers) liGL_ATI_draw_buffers (all drivers) liGL_ATI_texture_compression_3dc (gallium drivers, swrast) -liGL_ATI_texture_float (gallium) +liGL_ATI_texture_float (gallium, i965) liGL_NV_texture_barrier (gallium drivers) /ul AFAIC, you don't have to post patches like this for review, but anyway, Reviewed-by: Brian Paul bri...@vmware.com -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment
On 04/19/2011 04:00 AM, Christoph Bumiller wrote: On 16.04.2011 18:50, Christoph Bumiller wrote: I hope the new version is correct, the commit message describes why I did the first change, and the second change is described in a comment. Note that the MAD for inversion uses Height - 1 instead of Height. With this, piglit glsl-arb-fragment-coord-conventions and fbo-depth-sample-compare pass on nvc0. I was assuming that integer pixel centers for size 100 range from 0 to 99 and half-integer pixel centers from 0.5 to 99.5. Attached a better version of the patch, potentially saving an instruction and avoiding precision issues with NEAREST filtering that made piglit's blending-in-shader fail. The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was r600 classic, which should also work more correctly now since (at least according to gallium caps) it uses half-integer pixel center, and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5. Please review. All the relevant piglit tests seem to pass with softpipe, llvmpipe and swrast. Tested-by: Brian Paul bri...@vmware.com -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults (swrast, r600g, nouveau_vieux)
https://bugs.freedesktop.org/show_bug.cgi?id=36282 --- Comment #12 from Alexandre Demers alexandre.f.dem...@gmail.com 2011-04-19 07:36:02 PDT --- (In reply to comment #11) only happens here when shared-glapi is enabled (r600g) Confirmed also here that the bug only appears when Mesa is compiled with --enable-shared-glapi. -- 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] KWin and Mesa
Hi Mesa-devs, yesterday I published a rant about Mesa breaking KWin and given some comments on Phoronix Forums it seems like there is the wish for more communication between our development groups and so I want to start it. Please note that I am not subscribed to this mailing list, so please keep me in CC (I might not be able to reply this week at all). It is my wish to never have to rant about the state of Linux drivers any more and that I never have to see Mesa breaking KWin again. First of all I want to give a little bit personal history to help you understand why I so far did not contact you and up to now wrote two rants about Mesa breaking KWin. Let's go back to 2010 and the 4.5 release. In March 2010 I finished my Master Thesis and in April 2010 I started my first job. KDE hat the feature freeze for the 4.5 release around End of April, beginning of May. All new functionality including the Blur and Lanczos filter were implemented at that time. Given the change in my life due to end of my studies I did not contribute much to the release. At the time when we implemented the features the current Mesa version was 7.7. Version 7.8 was under development and when it got released marked as a development version. I read this information and considered ok we don't have to deal with 7.8 - it is development. At that time I had a notebook with NVIDIA graphics and an old system with a rather modern Ati card, with a crashing X server if I tried to use the radeon driver. I had no chance to test Mesa drivers at that time! In the time leading to the 4.5 release KWin had no active maintainer. Lubos had been inactive for quite some time and made me maintainer in November. At that time I considered Lubos still to be the maintainer and to be responsible for decisions whether to ship the new features or not. I considered myself only responsible for my own code (which did not cause any problems in that release). I was also running the stable version of KDE (4.4) at that time and the development only for testing. During the beta phase we realized that we had a problem. Mesa 7.8.2 was marked as stable (which I did not expect due to the fact that 7.8.0 and 7.8.1 were unstable) and distributions started to include it. Users were complaining about broken features mostly concerning blur and lanczos filters and mostly with Ati and Intel drivers. Nobody in our development team had an Intel system at that time. I had had access to a system before through a friend of mine, but unfortunately it broke down in exactly that important time. Later on my friend got a new Intel powered device but run Debian Testing on it which did not show any of the problems the users reported with Mesa 7.7. Concerning Ati I knew that Fredrik had been in contact with Mesa developers and that all the new functionality had been implemented on his Ati systems. So we knew that the functionality worked at least with some systems. With the looming release and more and more obvious problems we faced two possible solutions: remove the code completely (disable by default would not have solved it) or try to get it working somehow. I did not see any reason why we should have punished the users of working drivers (e.g. NVIDIA) because other drivers did not work. After all the new functionality was an important feature for our provided user experience and our designers and the Plasma team were demanding it. So we had only the option to make it work. Now you can imagine how difficult it is to workaround bugs in hardware you do not have. My solution was to implement a black list and to crowd source the creation to all our users. Another of the changes was to have the test whether to use direct rendering in an external application (due to drivers crashing when trying to create a GLContext) and there the hack was introduced which now backfired. Now why did I not contact you when we were facing these problems? Given that I had a day job, 2 h travel each day and trying at the same time to make the experience as smooth as possible for our users in the evenings, I seriously had not the time to even think about it. And what would it have changed? We need to get KDE supporting the drivers out there and not the next version! I am sorry that I did not contact you at that time but I think everybody will understand that sometimes as a volunteer developer you don't have the time to do everything which would help. Last but not least I did not feel responsible as I was not the maintainer of KWin. When we released 4.5 I was positive that we had successfully established a black list which ensures that no user would face issues. Unfortunately I was wrong. Users still faced the issue and even worse: the desktop started to freeze if you changed settings in KWin. A problem which had been completely unknown to us before the release (there was a bug report by one user but it was unconfirmed). None of us was able to reproduce
[Mesa-dev] [Bug 36238] Mesa release files don't contain scons control files
https://bugs.freedesktop.org/show_bug.cgi?id=36238 --- Comment #1 from Brian Paul brian.e.p...@gmail.com 2011-04-19 08:13:32 PDT --- Ok, I've fixed this in git on master and the 7.10 branch. I did test builds and everything seems in order, but there's still a chance that I might have missed something. If I make some updated tarballs of 7.10.2 will you test them? -- 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] KWin and Mesa
Hello Martin, sorry for the kick-in, but I feel obligated to speak up here. First of all you wrote a rather long text, but you don't make a single point _how_ to make the collaboration between mesa and kwin devs any better. It seems you just want to explain why you are doing things the way you are doing them. Please understand that mesa is also a community driven project and many of the contributions (especially for hardware drivers) come from volunteers, too. What you are calling for is to make them watch for regressions in all applications using mesa. I don't see why those devs should have more time for such things than kwin devs. It just won't work out to let one side do all the work. Trying to setup an automated regression test together with the kwin devs sounds more like a plan. It would end up in some work for both sides, but in the end it will result in a better quality. Also as said half a year ago, blacklisting features in kwin based on some renderer string is a _very_ bad idea. OpenGL has ways standardized ways to query functionality. If advertised features do not work as expected this is a bug in mesa and should be reported, not silenced on the applications side. Writing and testing applications only against the proprietary drivers doesn't make the situation any better as these drivers let you get away with a pile of brainfuck, which you won't find in any OpenGL standard. I think in this respect kwin devs (as well as every other app developer) should also ask themselfes if their stuff is really valid OpenGL. It's not always mesa breaking stuff, sometimes it is also the application breaking mesa. You should really try to find a way which both sides can agree with. Demanding one-sided things is not the way to go. We can't take the hassle of testing your application from you. You will find many open minded people in the mesa community who will gladly help you if something breaks, but there is also some work you have to do. Real communication between devs of both sides is the way to go if you want to make for a better user experience. Regards, Lucas Am Dienstag, den 19.04.2011, 16:52 +0200 schrieb Martin Gräßlin: Hi Mesa-devs, yesterday I published a rant about Mesa breaking KWin and given some comments on Phoronix Forums it seems like there is the wish for more communication between our development groups and so I want to start it. Please note that I am not subscribed to this mailing list, so please keep me in CC (I might not be able to reply this week at all). It is my wish to never have to rant about the state of Linux drivers any more and that I never have to see Mesa breaking KWin again. First of all I want to give a little bit personal history to help you understand why I so far did not contact you and up to now wrote two rants about Mesa breaking KWin. Let's go back to 2010 and the 4.5 release. In March 2010 I finished my Master Thesis and in April 2010 I started my first job. KDE hat the feature freeze for the 4.5 release around End of April, beginning of May. All new functionality including the Blur and Lanczos filter were implemented at that time. Given the change in my life due to end of my studies I did not contribute much to the release. At the time when we implemented the features the current Mesa version was 7.7. Version 7.8 was under development and when it got released marked as a development version. I read this information and considered ok we don't have to deal with 7.8 - it is development. At that time I had a notebook with NVIDIA graphics and an old system with a rather modern Ati card, with a crashing X server if I tried to use the radeon driver. I had no chance to test Mesa drivers at that time! In the time leading to the 4.5 release KWin had no active maintainer. Lubos had been inactive for quite some time and made me maintainer in November. At that time I considered Lubos still to be the maintainer and to be responsible for decisions whether to ship the new features or not. I considered myself only responsible for my own code (which did not cause any problems in that release). I was also running the stable version of KDE (4.4) at that time and the development only for testing. During the beta phase we realized that we had a problem. Mesa 7.8.2 was marked as stable (which I did not expect due to the fact that 7.8.0 and 7.8.1 were unstable) and distributions started to include it. Users were complaining about broken features mostly concerning blur and lanczos filters and mostly with Ati and Intel drivers. Nobody in our development team had an Intel system at that time. I had had access to a system before through a friend of mine, but unfortunately it broke down in exactly that important time. Later on my friend got a new Intel powered device but run Debian Testing on it which did not show any of the problems the users reported with Mesa 7.7. Concerning Ati I knew
Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms
On Tue, Apr 19, 2011 at 4:06 AM, Cédric Cano cc...@interfaceconcept.com wrote: Hi Few days ago, I posted a couple of patches on dri-devel but it doesn't seem to be the correct place. Here you are 2 patches that adds support for RV730 in r600c and r600g. I've pushed the r600c patch. I'll take a look at the r600g patch later today. Thanks! Alex More details are available here : http://lists.freedesktop.org/archives/dri-devel/2011-April/010056.html http://lists.freedesktop.org/archives/dri-devel/2011-April/010281.html Regards, Cedric ___ 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] KWin and Mesa
On Tue, Apr 19, 2011 at 10:52 AM, Martin Gräßlin mgraess...@kde.org wrote: Hi Mesa-devs, yesterday I published a rant about Mesa breaking KWin and given some comments on Phoronix Forums it seems like there is the wish for more communication between our development groups and so I want to start it. Please note that I am not subscribed to this mailing list, so please keep me in CC (I might not be able to reply this week at all). It is my wish to never have to rant about the state of Linux drivers any more and that I never have to see Mesa breaking KWin again. First of all I want to give a little bit personal history to help you understand why I so far did not contact you and up to now wrote two rants about Mesa breaking KWin. Let's go back to 2010 and the 4.5 release. In March 2010 I finished my Master Thesis and in April 2010 I started my first job. KDE hat the feature freeze for the 4.5 release around End of April, beginning of May. All new functionality including the Blur and Lanczos filter were implemented at that time. Given the change in my life due to end of my studies I did not contribute much to the release. At the time when we implemented the features the current Mesa version was 7.7. Version 7.8 was under development and when it got released marked as a development version. I read this information and considered ok we don't have to deal with 7.8 - it is development. At that time I had a notebook with NVIDIA graphics and an old system with a rather modern Ati card, with a crashing X server if I tried to use the radeon driver. I had no chance to test Mesa drivers at that time! In the time leading to the 4.5 release KWin had no active maintainer. Lubos had been inactive for quite some time and made me maintainer in November. At that time I considered Lubos still to be the maintainer and to be responsible for decisions whether to ship the new features or not. I considered myself only responsible for my own code (which did not cause any problems in that release). I was also running the stable version of KDE (4.4) at that time and the development only for testing. During the beta phase we realized that we had a problem. Mesa 7.8.2 was marked as stable (which I did not expect due to the fact that 7.8.0 and 7.8.1 were unstable) and distributions started to include it. Users were complaining about broken features mostly concerning blur and lanczos filters and mostly with Ati and Intel drivers. Nobody in our development team had an Intel system at that time. I had had access to a system before through a friend of mine, but unfortunately it broke down in exactly that important time. Later on my friend got a new Intel powered device but run Debian Testing on it which did not show any of the problems the users reported with Mesa 7.7. Concerning Ati I knew that Fredrik had been in contact with Mesa developers and that all the new functionality had been implemented on his Ati systems. So we knew that the functionality worked at least with some systems. With the looming release and more and more obvious problems we faced two possible solutions: remove the code completely (disable by default would not have solved it) or try to get it working somehow. I did not see any reason why we should have punished the users of working drivers (e.g. NVIDIA) because other drivers did not work. After all the new functionality was an important feature for our provided user experience and our designers and the Plasma team were demanding it. So we had only the option to make it work. Now you can imagine how difficult it is to workaround bugs in hardware you do not have. My solution was to implement a black list and to crowd source the creation to all our users. Another of the changes was to have the test whether to use direct rendering in an external application (due to drivers crashing when trying to create a GLContext) and there the hack was introduced which now backfired. Now why did I not contact you when we were facing these problems? Given that I had a day job, 2 h travel each day and trying at the same time to make the experience as smooth as possible for our users in the evenings, I seriously had not the time to even think about it. And what would it have changed? We need to get KDE supporting the drivers out there and not the next version! I am sorry that I did not contact you at that time but I think everybody will understand that sometimes as a volunteer developer you don't have the time to do everything which would help. Last but not least I did not feel responsible as I was not the maintainer of KWin. When we released 4.5 I was positive that we had successfully established a black list which ensures that no user would face issues. Unfortunately I was wrong. Users still faced the issue and even worse: the desktop started to freeze if you changed settings in KWin. A problem which had been completely unknown to us before the release (there was a
Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms
On 19 April 2011 18:11, Alex Deucher alexdeuc...@gmail.com wrote:
I've pushed the r600c patch. I'll take a look at the r600g patch later today.
I'm without r600 hardware this week, but personally I think I'd be
happier with a helper function for the endian swap, instead of
sprinkling ifdefs all over the source code.
E.g., something along these lines:
static inline unsigned r600_endian_swap(unsigned size)
{
#ifdef PIPE_ARCH_BIG_ENDIAN
switch (size)
{
case 16:
return ENDIAN_8IN16;
case 32:
return ENDIAN_8IN32;
case 64:
return ENDIAN_8IN64;
default:
return ENDIAN_NONE;
}
#else
return ENDIAN_NONE;
#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] i915: Gut all remaining bits of hardware fog
On Fri, 15 Apr 2011 23:10:52 -0700, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com None of this ever gets used. Fog is always calculated by a fragment program. Even though the fixed-function fog unit is never used, state updates are still sent to the hardware. Removing those spurious state updates can't hurt performance. Looks like a couple of those statechange functions could get just removed now that they do nothing. Other than that, the series is: Reviewed-by: Eric Anholt e...@anholt.net pgpvZ43E4BOQx.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] RV730 support for Big Endian platforms
On Tue, Apr 19, 2011 at 12:11 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Apr 19, 2011 at 4:06 AM, Cédric Cano cc...@interfaceconcept.com wrote: Hi Few days ago, I posted a couple of patches on dri-devel but it doesn't seem to be the correct place. Here you are 2 patches that adds support for RV730 in r600c and r600g. I've pushed the r600c patch. I'll take a look at the r600g patch later today. I've gone ahead and pushed the r600g patches as well. thanks! Alex Thanks! Alex More details are available here : http://lists.freedesktop.org/archives/dri-devel/2011-April/010056.html http://lists.freedesktop.org/archives/dri-devel/2011-April/010281.html Regards, Cedric ___ 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] RV730 support for Big Endian platforms
On Tue, Apr 19, 2011 at 1:24 PM, Henri Verbeet hverb...@gmail.com wrote:
On 19 April 2011 18:11, Alex Deucher alexdeuc...@gmail.com wrote:
I've pushed the r600c patch. I'll take a look at the r600g patch later
today.
I'm without r600 hardware this week, but personally I think I'd be
happier with a helper function for the endian swap, instead of
sprinkling ifdefs all over the source code.
Yeah, that would probably be nicer. I'm not inclined to put more
effort into r600c. It might be a useful cleanup for r600g, but I'm
not sure it would make that much difference since the r600g code is
already pretty clean.
Alex
E.g., something along these lines:
static inline unsigned r600_endian_swap(unsigned size)
{
#ifdef PIPE_ARCH_BIG_ENDIAN
switch (size)
{
case 16:
return ENDIAN_8IN16;
case 32:
return ENDIAN_8IN32;
case 64:
return ENDIAN_8IN64;
default:
return ENDIAN_NONE;
}
#else
return ENDIAN_NONE;
#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/egl: expose EGL_MESA_drm_image on x11 displays
Date: Sun, 13 Feb 2011 23:45:47 +
This makes it useable with the egl_gallium driver in X11.
It only works for the DRI2 backend, not ximage.
---
src/gallium/state_trackers/egl/common/egl_g3d.c|3 ++
.../state_trackers/egl/common/native_buffer.h |3 +-
src/gallium/state_trackers/egl/x11/native_dri2.c | 24
3 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
b/src/gallium/state_trackers/egl/common/egl_g3d.c
index ddca140..f0fb22b 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
@@ -551,6 +551,9 @@ egl_g3d_initialize(_EGLDriver *drv, _EGLDisplay *dpy)
dpy-Extensions.MESA_drm_image = EGL_TRUE;
}
+ if (dpy-Platform == _EGL_PLATFORM_X11 gdpy-native-buffer)
+ dpy-Extensions.MESA_drm_image = EGL_TRUE;
+
if (dpy-Platform == _EGL_PLATFORM_WAYLAND gdpy-native-buffer)
dpy-Extensions.MESA_drm_image = EGL_TRUE;
diff --git a/src/gallium/state_trackers/egl/common/native_buffer.h
b/src/gallium/state_trackers/egl/common/native_buffer.h
index 5c29ab9..2c99381 100644
--- a/src/gallium/state_trackers/egl/common/native_buffer.h
+++ b/src/gallium/state_trackers/egl/common/native_buffer.h
@@ -41,7 +41,8 @@ struct pipe_resource;
* Just like a native window or a native pixmap, a native buffer is another
* native type. Its definition depends on the native display.
*
- * For DRM platform, the type of a native buffer is struct winsys_handle.
+ * For DRM, Wayland, and X11 platforms, the type of a native buffer
+ * is struct winsys_handle.
*/
struct native_display_buffer {
struct pipe_resource *(*import_buffer)(struct native_display *ndpy,
diff --git a/src/gallium/state_trackers/egl/x11/native_dri2.c
b/src/gallium/state_trackers/egl/x11/native_dri2.c
index b18c313..46c7bb9 100644
--- a/src/gallium/state_trackers/egl/x11/native_dri2.c
+++ b/src/gallium/state_trackers/egl/x11/native_dri2.c
@@ -789,6 +789,29 @@ dri2_display_init_screen(struct native_display *ndpy)
return TRUE;
}
+static struct pipe_resource *
+dri2_display_import_buffer(struct native_display *ndpy,
+ const struct pipe_resource *templ,
+ void *buf)
+{
+ return ndpy-screen-resource_from_handle(ndpy-screen,
+ templ, (struct winsys_handle *) buf);
+}
+
+static boolean
+dri2_display_export_buffer(struct native_display *ndpy,
+ struct pipe_resource *res,
+ void *buf)
+{
+ return ndpy-screen-resource_get_handle(ndpy-screen,
+ res, (struct winsys_handle *) buf);
+}
+
+static struct native_display_buffer dri2_display_buffer = {
+ dri2_display_import_buffer,
+ dri2_display_export_buffer
+};
+
static unsigned
dri2_display_hash_table_hash(void *key)
{
@@ -851,6 +874,7 @@ x11_create_dri2_display(Display *dpy,
dri2dpy-base.is_pixmap_supported = dri2_display_is_pixmap_supported;
dri2dpy-base.create_window_surface = dri2_display_create_window_surface;
dri2dpy-base.create_pixmap_surface = dri2_display_create_pixmap_surface;
+ dri2dpy-base.buffer = dri2_display_buffer;
return dri2dpy-base;
}
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] swrast: Add LUMINANCE, INTENSITY, LUMINANCE_ALPHA to span asserts.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/2011 08:43 PM, Brian Paul wrote: On Mon, Apr 18, 2011 at 8:10 PM, Eric Anholt e...@anholt.net wrote: On Mon, 18 Apr 2011 16:16:37 -0700, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/2011 01:37 PM, Eric Anholt wrote: Fixes ARB_texture_float/fbo-alphatest-formats. --- src/mesa/swrast/s_readpix.c |3 +++ src/mesa/swrast/s_span.c|3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c index 5604c2e..a201a63 100644 --- a/src/mesa/swrast/s_readpix.c +++ b/src/mesa/swrast/s_readpix.c @@ -195,6 +195,9 @@ fast_read_rgba_pixels( struct gl_context *ctx, rb-_BaseFormat == GL_RGB || rb-_BaseFormat == GL_RG || rb-_BaseFormat == GL_RED || + rb-_BaseFormat == GL_LUMINANCE || + rb-_BaseFormat == GL_INTENSITY || + rb-_BaseFormat == GL_LUMINANCE_ALPHA || rb-_BaseFormat == GL_ALPHA); At this point would it be easier to just assert the formats that are not allowed? Is there even anything that's left as a valid _BaseFormat that isn't allowed here? I keep wanting to remove asserts like this, and Brian says he likes them. I'm sorry you feel inconvenienced, but I'm a big believer in assertions. I don't think the problem is the existence of assertions. I think the problem is that the format assertions have gotten a bit out of control. They're increasingly difficult to maintain, and we often get false negatives. This diminishes their value significantly. That was my point in the initial review comment. Once the assertion is expanded to be correct, it basically asserts that _BaseFormat must have a value. Since this should have been handled elsewhere, does having it here add anything other than maintenance burden? I also think that many of these assertions could be improved by checking for the negative condition instead of the positive condition. There are far fewer values that cannot be used than there are values that can be used. When someone is adding support for formats GL_FOO, it is more clear that assert(x != GL_FOO x != GL_BAR); needs to be changed than assert(x == GL_ASDF || x == GL_QWERTY); In these recent cases, perhaps we just need a better, extendable assertion. Something like assert(_mesa_is_base_color_format(rb-_BaseFormat)); That would certainly be more maintainable for this case, but I don't think it's a general fix. I think someone will have to look over this code and come up with a plan. 1, 2, 3, not it! :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2t07YACgkQX1gOwKyEAw8IKACcCNkd99BcCttmiBq4ekDezSED fjkAniwnDIZPPjW1VPQNwKZyVO4xv1TK =mzoJ -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] swrast: Add LUMINANCE, INTENSITY, LUMINANCE_ALPHA to span asserts.
On 04/19/2011 12:25 PM, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/2011 08:43 PM, Brian Paul wrote: On Mon, Apr 18, 2011 at 8:10 PM, Eric Anholte...@anholt.net wrote: On Mon, 18 Apr 2011 16:16:37 -0700, Ian Romanicki...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/2011 01:37 PM, Eric Anholt wrote: Fixes ARB_texture_float/fbo-alphatest-formats. --- src/mesa/swrast/s_readpix.c |3 +++ src/mesa/swrast/s_span.c|3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c index 5604c2e..a201a63 100644 --- a/src/mesa/swrast/s_readpix.c +++ b/src/mesa/swrast/s_readpix.c @@ -195,6 +195,9 @@ fast_read_rgba_pixels( struct gl_context *ctx, rb-_BaseFormat == GL_RGB || rb-_BaseFormat == GL_RG || rb-_BaseFormat == GL_RED || + rb-_BaseFormat == GL_LUMINANCE || + rb-_BaseFormat == GL_INTENSITY || + rb-_BaseFormat == GL_LUMINANCE_ALPHA || rb-_BaseFormat == GL_ALPHA); At this point would it be easier to just assert the formats that are not allowed? Is there even anything that's left as a valid _BaseFormat that isn't allowed here? I keep wanting to remove asserts like this, and Brian says he likes them. I'm sorry you feel inconvenienced, but I'm a big believer in assertions. I don't think the problem is the existence of assertions. I think the problem is that the format assertions have gotten a bit out of control. They're increasingly difficult to maintain, and we often get false negatives. This diminishes their value significantly. Yes, I understand the downside of that. That was my point in the initial review comment. Once the assertion is expanded to be correct, it basically asserts that _BaseFormat must have a value. I'm sorry to be pedantic but that's not accurate. Illegal values for _BaseFormat at this point include GL_STENCIL_INDEX, GL_DEPTH_COMPONENT, GL_DEPTH_STENCIL, GL_COLOR_INDEX and GL_DUDV_ATI. That's 5 illegal cases vs. 8 legal so it's not a huge difference. Since this should have been handled elsewhere, does having it here add anything other than maintenance burden? That's just it, trying to read a non-color renderbuffer as a color format _should_ have been caught earlier (GL_INVALID_OPERATION). The point of the assertion is to double-check that proper error detection was done earlier - and, to tell the reader that the subsequent code is prepared to handle these formats only. If that assertions fails, the subsequent code should be reviewed to see if it can handle the new format. I also think that many of these assertions could be improved by checking for the negative condition instead of the positive condition. There are far fewer values that cannot be used than there are values that can be used. When someone is adding support for formats GL_FOO, it is more clear that assert(x != GL_FOO x != GL_BAR); needs to be changed than assert(x == GL_ASDF || x == GL_QWERTY); It could go either way. In the case above, if GL_FOO is a new non-color format you'd still need to update assertions. In these recent cases, perhaps we just need a better, extendable assertion. Something like assert(_mesa_is_base_color_format(rb-_BaseFormat)); That would certainly be more maintainable for this case, but I don't think it's a general fix. I think someone will have to look over this code and come up with a plan. 1, 2, 3, not it! :) I'd rather not make a mountain out of a molehill. We've already spent more time typing emails about the topic than just fixing the assertions. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): swrastg: Add __DRI_TEX_BUFFER support (patches}
http://cgit.freedesktop.org/mesa/mesa/commit/?id=2b64886c817ffa2d86abb9b4a5d79d1e2451
2011-03-11 19:49:28 (GMT)
Without this, EXT_texture_from_pixmap is trivially broken. With it,
it's merely subtly broken.
Signed-off-by: Adam Jackson a...@redhat.com
What does 'subtly broken' mean in this case? Is it related to this
backtrace from August? Or the lack of GLX direct-rendering support?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=c14b4371ed58859d264b7b2581cfedc9cfd8401f
2010-08-13 19:58:11 (GMT)
st/dri: move TFP code to dri_drawable.c
This is based on a patch by nobled nob...@dreamwidth.org and allows the TFP
extension to be enabled for DRISW also. This patch does not enable TFP for
DRISW
though, because testing on xephyr segfaults here (for both classic and
gallium):
Program received signal SIGSEGV, Segmentation fault.
0x00786a4a in _mesa_GenTextures (n=1, textures=0xbfffee4c) at
main/texobj.c:788
788 ASSERT_OUTSIDE_BEGIN_END(ctx);
(gdb)
(gdb) where
\#0 0x00786a4a in _mesa_GenTextures (n=1, textures=0xbfffee4c) at
main/texobj.c:788
\#1 0x0817a004 in __glXDisp_GenTextures ()
\#2 0x08168498 in __glXDispatch ()
\#3 0x0808b6ce in Dispatch ()
\#4 0x08084435 in main ()
The TFP code is generic except for the teximage call. We need to verify that
DRISW correclty implements whatever hook teximage finally calls.
Do we have a bug report about that somewhere? I'm wondering if it
happens with swrast-classic's TFP implementation, too...
Anyway, hey, anyone remember these GLX patches from September? Anyone
want to commit them? Because other bugs aside, indirect-only
texture-from-pixmap sucks.
From 8fd545534aab1e3f6641b37759d70cab1560d3fa Mon Sep 17 00:00:00 2001
From: nobled nob...@dreamwidth.org
Date: Sun, 5 Sep 2010 16:14:01 +
Subject: [PATCH 1/3] glx: Add teximage vfuncs to drisw
Copied the implementation from dri2_glx.c.
---
src/glx/drisw_glx.c | 51 ---
1 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 5c7f40c..9eb80e4 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -46,8 +46,10 @@ struct drisw_screen
__DRIscreen *driScreen;
__GLXDRIscreen vtable;
- const __DRIcoreExtension *core;
const __DRIswrastExtension *swrast;
+ const __DRIcoreExtension *core;
+
+ const __DRItexBufferExtension *texBuffer;
const __DRIconfig **driver_configs;
void *driver;
@@ -287,6 +289,49 @@ drisw_unbind_context(struct glx_context *context, struct glx_context *new)
driReleaseDrawables(pcp-base);
}
+static void
+drisw_bind_tex_image(Display * dpy,
+ GLXDrawable drawable,
+ int buffer, const int *attrib_list)
+{
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct drisw_context *pcp = (struct drisw_context *) gc;
+ __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+ struct drisw_drawable *pdraw = (struct drisw_drawable *) base;
+ struct glx_display *dpyPriv = __glXInitialize(dpy);
+ struct drisw_display *pdp =
+ (struct drisw_display *) dpyPriv-dri2Display;
+ struct drisw_screen *psc;
+
+ if (pdraw != NULL) {
+ psc = (struct drisw_screen *) base-psc;
+
+/* FIXME: copied from dri2_glx.c. Can, should drisw do something like this? */
+#if 0 __DRI2_FLUSH_VERSION = 3
+ if (!pdp-invalidateAvailable psc-f)
+ psc-f-invalidate(pdraw-driDrawable);
+#endif
+
+ if (psc-texBuffer-base.version = 2
+ psc-texBuffer-setTexBuffer2 != NULL) {
+ (*psc-texBuffer-setTexBuffer2) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-base.textureFormat,
+ pdraw-driDrawable);
+ }
+ else {
+ (*psc-texBuffer-setTexBuffer) (pcp-driContext,
+ pdraw-base.textureTarget,
+ pdraw-driDrawable);
+ }
+ }
+}
+
+static void
+drisw_release_tex_image(Display * dpy, GLXDrawable drawable, int buffer)
+{
+}
+
static const struct glx_context_vtable drisw_context_vtable = {
drisw_destroy_context,
drisw_bind_context,
@@ -294,8 +339,8 @@ static const struct glx_context_vtable drisw_context_vtable = {
NULL,
NULL,
DRI_glXUseXFont,
- NULL,
- NULL,
+ drisw_bind_tex_image,
+ drisw_release_tex_image,
};
static struct glx_context *
--
1.7.0.4
From ad0013ef4c24c931679eabb7aec8c9210c6b5868 Mon Sep 17 00:00:00 2001
From: nobled nob...@dreamwidth.org
Date: Sun, 5 Sep 2010 16:21:03 +
Subject: [PATCH 2/3] glx: Enable GLX_EXT_texture_from_pixmap in software
This makes commits 8d789be03430b80e0ba2fef19d56dd0b8e699ea2,
c14b4371ed58859d264b7b2581cfedc9cfd8401f,
and 2b64886c817ffa2d86abb9b4a5d79d1e2451 much more useful.
Now if a software DRI driver advertises it, we can use it in
direct-rendering contexts, instead of only indirect-rendering.
---
src/glx/drisw_glx.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 9eb80e4..cae4a6b 100644
Re: [Mesa-dev] [PATCHES] implement GL_ARB_robustness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/19/2011 12:23 PM, nobled wrote:
spec file:
http://www.opengl.org/registry/specs/ARB/robustness.txt
The first four parts of this series add infrastructure to support
bounds-checking client memory buffers by re-using the PBO
bounds-checking code; the fifth patch adds the actual functions of the
extension. However, the series is incomplete because I'm not sure how
to turn the spec file into an xml file for
src/mapi/glapi/gen/ARB_robustness.xml, and then generate the dispatch
stuff from it with the python script(*which* python script?) -- the
docs on this point seem to be a classic combination of completely
outdated and hey, can you vague that up for me?:
http://cgit.freedesktop.org/mesa/mesa/tree/docs/devinfo.html
In the src/mesa/glapi/ directory, add the new extension functions and
enums to the gl_API.xml file.
Then, a bunch of source files must be regenerated by executing the
corresponding Python scripts.
I think I covered all the other steps, though. At least enough to be
faithful to the spec, as long as these two aren't exposed yet on the
GLX side of things:
http://www.opengl.org/registry/specs/ARB/glx_create_context.txt
http://www.opengl.org/registry/specs/ARB/glx_create_context_robustness.txt
Still todo: adding piglit tests.
It's *REALLY* hard to review patches sent as attachments. It is much
better and easier for reviewers to put comments alongside the code they
are commenting about. In the future, could you please send patches
using git-send-email?
Patch 1/5 looks like it's doing to separate things. It renames / alters
_mesa_validate_pbo_access and it starts using _mesa_is_bufferobj in some
places. That should probably be split into two patches. First change
over to using _mesa_is_bufferobj, then make the other changes.
I'm also not sure _mesa_validate_buffer_access is a particularly good
name. This loses the information that the validation is for pixel
reads / writes. This also applies to _mesa_map_validate_buffer_dest and
friends in later patches.
For the internal Mesa functions, I think I might also change the
parameter bufSize to clientMemorySize or similar. Using bufSize in the
API functions (added in patch 5/5) matches the API definition and is fine.
The changes to readpix.c in patch 4/5 looks odd. If the access is
out-of-bounds and there is PBO, nothing happens but no error is
generated. Is that what the spec says to do?
It also looks like a lot of the checking for out-of-bounds followed by
checking for being mapped could be refactored.
Patch 5/5 also does two separate things. It adds data structure
infrastructure for the extension and it adds a bunch of entry points.
Usually gl_context::ResetStatus and gl_constants::ResetStratgy would be
added in a separate patch from adding all the new functions.
In patch 5/5 why
+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+ const GLsizei bufSize = INT_MAX;
+ _mesa_GetnMinmaxARB(target, reset, format, type, bufSize, values);
+}
instead of
+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+ _mesa_GetnMinmaxARB(target, reset, format, type, INT_MAX, values);
+}
On a different note, I explicitly *approve* of the use of 'goto
overflow'. :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2t8+oACgkQX1gOwKyEAw9wGQCgnMkLFee64zCdN/c1UutZ613x
4qIAn2ZKxnEuqClIzemoTuc98bewOY8X
=Qc3X
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHES] implement GL_ARB_robustness
On 04/19/2011 02:43 PM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/19/2011 12:23 PM, nobled wrote:
spec file:
http://www.opengl.org/registry/specs/ARB/robustness.txt
The first four parts of this series add infrastructure to support
bounds-checking client memory buffers by re-using the PBO
bounds-checking code; the fifth patch adds the actual functions of the
extension. However, the series is incomplete because I'm not sure how
to turn the spec file into an xml file for
src/mapi/glapi/gen/ARB_robustness.xml, and then generate the dispatch
stuff from it with the python script(*which* python script?) -- the
docs on this point seem to be a classic combination of completely
outdated and hey, can you vague that up for me?:
http://cgit.freedesktop.org/mesa/mesa/tree/docs/devinfo.html
In the src/mesa/glapi/ directory, add the new extension functions and
enums to the gl_API.xml file.
Then, a bunch of source files must be regenerated by executing the
corresponding Python scripts.
It's not too hard to write the xml file. Just use another extension
as an example (ex: ARB_sampler_objects.xml which was just recently
added). Then add the new filename to the Makefile and in gl_API.xml,
then run the Makefile. Make commits for the stuff you added/changed
and another for the regenerated files.
I think I covered all the other steps, though. At least enough to be
faithful to the spec, as long as these two aren't exposed yet on the
GLX side of things:
http://www.opengl.org/registry/specs/ARB/glx_create_context.txt
http://www.opengl.org/registry/specs/ARB/glx_create_context_robustness.txt
Still todo: adding piglit tests.
It's *REALLY* hard to review patches sent as attachments. It is much
better and easier for reviewers to put comments alongside the code they
are commenting about. In the future, could you please send patches
using git-send-email?
Patch 1/5 looks like it's doing to separate things. It renames / alters
_mesa_validate_pbo_access and it starts using _mesa_is_bufferobj in some
places. That should probably be split into two patches. First change
over to using _mesa_is_bufferobj, then make the other changes.
I'm also not sure _mesa_validate_buffer_access is a particularly good
name. This loses the information that the validation is for pixel
reads / writes. This also applies to _mesa_map_validate_buffer_dest and
friends in later patches.
I agree. I'd like to keep pbo in the name to indicate that we're
talking about pixel/image buffers. OpenGL has many kinds of buffers
and it's good to clarify what kind of buffer we're talking about here.
For the internal Mesa functions, I think I might also change the
parameter bufSize to clientMemorySize or similar. Using bufSize in the
API functions (added in patch 5/5) matches the API definition and is fine.
The changes to readpix.c in patch 4/5 looks odd. If the access is
out-of-bounds and there is PBO, nothing happens but no error is
generated. Is that what the spec says to do?
It also looks like a lot of the checking for out-of-bounds followed by
checking for being mapped could be refactored.
Patch 5/5 also does two separate things. It adds data structure
infrastructure for the extension and it adds a bunch of entry points.
Usually gl_context::ResetStatus and gl_constants::ResetStratgy would be
added in a separate patch from adding all the new functions.
I agree with these items too.
In patch 5/5 why
+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+ const GLsizei bufSize = INT_MAX;
+ _mesa_GetnMinmaxARB(target, reset, format, type, bufSize, values);
+}
instead of
+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+ _mesa_GetnMinmaxARB(target, reset, format, type, INT_MAX, values);
+}
I sometimes do that to convey what the argument is without having to
look at the prototype. In this case though, it doesn't add a lot.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: don't flush the dest caches on every draw
Keep track of when the caches are dirty, and only flush them when
the framebuffer state is set and when the context is flushed.
---
src/gallium/drivers/r600/evergreen_state.c | 19 +++-
src/gallium/drivers/r600/evergreend.h |1 +
src/gallium/drivers/r600/r600.h|6 +
src/gallium/drivers/r600/r600_pipe.h |2 -
src/gallium/drivers/r600/r600_state.c | 12 ++-
src/gallium/winsys/r600/drm/evergreen_hw_context.c | 86 +-
src/gallium/winsys/r600/drm/r600_hw_context.c | 122 ++--
7 files changed, 176 insertions(+), 72 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index febc613..a972f82 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -822,6 +822,9 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
if (rstate == NULL)
return;
+ evergreen_context_flush_dest_caches(rctx-ctx);
+ rctx-ctx.num_dest_buffers = state-nr_cbufs;
+
/* unreference old buffer and reference new one */
rstate-id = R600_PIPE_STATE_FRAMEBUFFER;
@@ -833,6 +836,7 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
}
if (state-zsbuf) {
evergreen_db(rctx, rstate, state);
+ rctx-ctx.num_dest_buffers++;
}
target_mask = 0x;
@@ -894,6 +898,19 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
}
}
+static void evergreen_texture_barrier(struct pipe_context *ctx)
+{
+ struct r600_pipe_context *rctx = (struct r600_pipe_context *)ctx;
+
+ r600_context_flush_all(rctx-ctx, S_0085F0_TC_ACTION_ENA(1) |
S_0085F0_CB_ACTION_ENA(1) |
+ S_0085F0_CB0_DEST_BASE_ENA(1) |
S_0085F0_CB1_DEST_BASE_ENA(1) |
+ S_0085F0_CB2_DEST_BASE_ENA(1) |
S_0085F0_CB3_DEST_BASE_ENA(1) |
+ S_0085F0_CB4_DEST_BASE_ENA(1) |
S_0085F0_CB5_DEST_BASE_ENA(1) |
+ S_0085F0_CB6_DEST_BASE_ENA(1) |
S_0085F0_CB7_DEST_BASE_ENA(1) |
+ S_0085F0_CB8_DEST_BASE_ENA(1) |
S_0085F0_CB9_DEST_BASE_ENA(1) |
+ S_0085F0_CB10_DEST_BASE_ENA(1) |
S_0085F0_CB11_DEST_BASE_ENA(1));
+}
+
void evergreen_init_state_functions(struct r600_pipe_context *rctx)
{
rctx-context.create_blend_state = evergreen_create_blend_state;
@@ -934,7 +951,7 @@ void evergreen_init_state_functions(struct
r600_pipe_context *rctx)
rctx-context.set_viewport_state = evergreen_set_viewport_state;
rctx-context.sampler_view_destroy = r600_sampler_view_destroy;
rctx-context.redefine_user_buffer = u_default_redefine_user_buffer;
- rctx-context.texture_barrier = r600_texture_barrier;
+ rctx-context.texture_barrier = evergreen_texture_barrier;
}
void evergreen_init_config(struct r600_pipe_context *rctx)
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium/drivers/r600/evergreend.h
index 8489c29..de445b8 100644
--- a/src/gallium/drivers/r600/evergreend.h
+++ b/src/gallium/drivers/r600/evergreend.h
@@ -43,6 +43,7 @@
#define EVERGREEN_CTL_CONST_OFFSET 0x0003CFF0
#define EVERGREEN_CTL_CONST_END 0x0003E200
+#define EVENT_TYPE_PS_PARTIAL_FLUSH0x10
#define EVENT_TYPE_ZPASS_DONE 0x15
#define EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT 0x16
#defineEVENT_TYPE(x) ((x) 0)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 41666f2..0b0df9d 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -233,6 +233,8 @@ struct r600_query {
#define R600_QUERY_STATE_ENDED (1 1)
#define R600_QUERY_STATE_SUSPENDED (1 2)
+#define R600_CONTEXT_DRAW_PENDING (1 0)
+#define R600_CONTEXT_DST_CACHES_DIRTY (1 1)
struct r600_context {
struct radeon *radeon;
@@ -255,6 +257,8 @@ struct r600_context {
unsignednum_query_running;
struct list_headfenced_bo;
unsignedmax_db; /* for OQ */
+ unsignednum_dest_buffers;
+ unsignedflags;
boolean predicate_drawing;
};
@@ -293,9 +297,11 @@ void r600_query_predication(struct r600_context *ctx,
struct r600_query *query,
void r600_context_emit_fence(struct r600_context *ctx, struct r600_bo *fence,
unsigned offset, unsigned value);
void r600_context_flush_all(struct r600_context *ctx, unsigned flush_flags);
+void r600_context_flush_dest_caches(struct r600_context *ctx);
int evergreen_context_init(struct r600_context *ctx, struct radeon *radeon);
void evergreen_context_draw(struct r600_context *ctx, const struct r600_draw
Re: [Mesa-dev] [PATCH 1/3] glsl: correctly handle conversions between int and uint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/18/2011 04:51 PM, Bryan Cain wrote:
This patch was revised several times before submitting, and even after
that I still wasn't sure that adding conversion operations was the right
solution. So I'm not really surprised that there are problems with this
one. :)
On 04/18/2011 06:36 PM, Ian Romanick wrote:
On 04/17/2011 11:39 PM, Bryan Cain wrote:
From the GLSL 1.30 specification, section 4.1.10 (Implicit
Conversions):
There are no implicit conversions between signed and unsigned
integers.
However, convert_component() was assuming that conversions between
int and uint were implicit.
The conversions applied in convert_component only apply to constructor
parameters. As Ken mentions, in those cases we want
Internally we treat signed and unsigned identically because the
representation is the same. There's no way for an application to
observe the difference between:
ivec4 a = ivec4(5 , 6 , 7 , 8 );
ivec4 b = ivec4(5 , 6 , 7 , 8u);
ivec4 c = ivec4(5 , 6 , 7u, 8 );
ivec4 d = ivec4(5 , 6 , 7u, 8u);
ivec4 e = ivec4(5 , 6u, 7 , 8 );
ivec4 f = ivec4(5 , 6u, 7 , 8u);
ivec4 g = ivec4(5 , 6u, 7u, 8 );
ivec4 h = ivec4(5 , 6u, 7u, 8u);
// etc.
The type checker ensures that operands to operations that could exhibit
differing behavior (e.g., ir_bin_mul) have identical types. That code
lives in arithmetic_result_type in ast_to_hir.cpp. There is similar
code in match_function_by_name in ast_function.cpp.
Do you have any specific test cases in mind that don't produce correct
results with the existing code?
Yes, usages like this:
int var1 = 7;
uint var2 = uint(var1);
They were causing a type mismatch error in ast_to_hir.cpp because
convert_component() was treating the uint(int) constructor as a no-op.
Ah, that makes sense. I just sent some patches to the piglit mailing
list with some tests in this vein.
You've convinced me that we need i2u and u2i unary operators. I don't
think we need b2u and u2b operators because we can just do (i2b(u2i
value)) and (i2u(b2i value)). Ditto for f2i. This should result in
less churn in the backends since u2i and i2u will universally be no-ops.
Almost every place that checks is_integer() will need to check for the
specific type, either GLSL_TYPE_UINT or GLSL_TYPE_INT, that it expects.
This means that your patch 2/3, which is already applied, will need to
be reverted.
---
src/glsl/ast_function.cpp | 16
src/glsl/ir.cpp |8
src/glsl/ir.h |2 ++
src/glsl/ir_constant_expression.cpp |8
src/glsl/ir_validate.cpp|8
5 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index e5cb873..cc3f032 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -267,17 +267,25 @@ convert_component(ir_rvalue *src, const
glsl_type *desired_type)
assert(a = GLSL_TYPE_BOOL);
assert(b = GLSL_TYPE_BOOL);
- if ((a == b) || (src-type-is_integer()
desired_type-is_integer()))
+ if (a == b)
return src;
switch (a) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
- if (b == GLSL_TYPE_FLOAT)
+ switch(b) {
+ case GLSL_TYPE_UINT:
+ result = new(ctx) ir_expression(ir_unop_u2i, desired_type,
src, NULL);
+ break;
+ case GLSL_TYPE_INT:
+ result = new(ctx) ir_expression(ir_unop_i2u, desired_type,
src, NULL);
+ break;
+ case GLSL_TYPE_FLOAT:
result = new(ctx) ir_expression(ir_unop_f2i, desired_type,
src, NULL);
With the other changes, leaving this as-is is kind of hinkey. Here the
result base type will be GLSL_TYPE_INT, but the desired based type could
be GLSL_TYPE_UINT.
Unless I'm missing something, that case is handled by the line if (a ==
b).
What I meant was uint(float) and int(float) will both generate an
ir_unop_f2i, which has type int. So, 'uint x = uint(5.2);' will result
in a type error. Right?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2uEBkACgkQX1gOwKyEAw8esQCdEawL5QiLogZuqLrstfyI7Dz9
ub0AoJuTNzMseA2K3vdrtSzjEQ8sLctO
=yFr3
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2011 09:45 AM, Corbin Simpson wrote: On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick i...@freedesktop.org wrote: This patch series cleans out the last vestiges of fixed-function fog support with ARB_fragment_program. We talked about doing this quite some time ago, but we decided to hold off. The thinking at the time was that there was still a chance that someone might add support for the fixed-function fog on either i915 or r300. Reality check: there is no chance because nobody cares. :) Patch 1/9 cleans up a couple minor bugs in the fixed-function fragment program code. Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to be non-GL_NONE. Thanks to the first patch, this can *never* happen. Patch 5/9 removes gl_fragment_program::FogOption. The remaining four patches remove all the dangling bits of support for fixed-function fog on i915. Since fog is (and always has been) handled by fragment programs on i915, this code is completely useless. I have tested this whole series on Ironlake (i965 driver) and G33 (i915 driver). There were no piglit or GTF regressions in either case. I believe that, at the very least, the first four patches are suitable for the stable branches (after a suitable settling period on master, of course). The remaining five patches may also be suitable. src/mesa/drivers/dri/i915/i915_context.c |8 +- src/mesa/drivers/dri/i915/i915_context.h | 15 -- src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +-- src/mesa/drivers/dri/i915/i915_state.c | 164 +--- src/mesa/drivers/dri/i915/i915_vtbl.c |9 - src/mesa/drivers/dri/i965/brw_program.c|5 - .../drivers/dri/r300/compiler/r300_fragprog_emit.c |2 - src/mesa/main/ff_fragment_shader.cpp | 44 +++--- src/mesa/main/mtypes.h |1 - src/mesa/program/arbprogparse.c| 18 +-- src/mesa/program/program.c |1 - src/mesa/program/programopt.c | 33 +++-- src/mesa/program/programopt.h |4 +- src/mesa/swrast/s_context.c| 15 +-- src/mesa/tnl/t_context.c | 12 +- 15 files changed, 70 insertions(+), 272 deletions(-) r300 *did* support FF fog at one point, but it got tossed out because we couldn't get it to work with fog coordinates. (Well, *I* couldn't get it to work; I think osiris got it mostly-working-sort-of at one point.) This code will not be missed. Right. I believe people eventually figured out that fglrx didn't use the fixed-function fog either. It seems likely that it was for the same reason. :) Looking at the i915 docs, there a bunch of restrictions and weird quirks that look like they'd make it more trouble that it's worth. Plus, I don't think a lot of applications use part shader / part fixed-function anyway. Can I call this an Acked-by? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb /swAnixkaFG6jKh0FrgPk3hoi6wFu+uY =p6R3 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/9] mesa: gl_fragment_program::FogOption is always GL_NONE so don't check it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/16/2011 06:48 AM, Brian Paul wrote:
On Sat, Apr 16, 2011 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/swrast/s_context.c | 15 ---
src/mesa/tnl/t_context.c| 12
2 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
index 491fcfc..b3e3968 100644
--- a/src/mesa/swrast/s_context.c
+++ b/src/mesa/swrast/s_context.c
@@ -248,18 +248,11 @@ _swrast_update_fog_state( struct gl_context *ctx )
SWcontext *swrast = SWRAST_CONTEXT(ctx);
const struct gl_fragment_program *fp = ctx-FragmentProgram._Current;
+ assert((fp == NULL) || (fp-Base.Target == GL_FRAGMENT_PROGRAM_ARB));
+
/* determine if fog is needed, and if so, which fog mode */
- swrast-_FogEnabled = GL_FALSE;
- if (fp fp-Base.Target == GL_FRAGMENT_PROGRAM_ARB) {
- if (fp-FogOption != GL_NONE) {
- swrast-_FogEnabled = GL_TRUE;
- swrast-_FogMode = fp-FogOption;
- }
- }
- else if (ctx-Fog.Enabled) {
- swrast-_FogEnabled = GL_TRUE;
- swrast-_FogMode = ctx-Fog.Mode;
- }
+ swrast-_FogEnabled = (fp == NULL ctx-Fog.Enabled);
+ swrast-_FogMode = ctx-Fog.Mode;
We might as well get rid of swrast-_FogMode and just use
ctx-Fog.Mode everywhere.
Yeah, that would probably work. I'll send that as a follow-on patch.
Can I call this a Reviewed-by on the patches that are here?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2uF1MACgkQX1gOwKyEAw8TqgCgnoC8rHdAeBJRPInR7xMqXPoe
EHkAn2s5UGSQVEmdcYqbb3joJzBB7RSc
=CUjP
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up
On Tue, Apr 19, 2011 at 7:13 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2011 09:45 AM, Corbin Simpson wrote: On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick i...@freedesktop.org wrote: This patch series cleans out the last vestiges of fixed-function fog support with ARB_fragment_program. We talked about doing this quite some time ago, but we decided to hold off. The thinking at the time was that there was still a chance that someone might add support for the fixed-function fog on either i915 or r300. Reality check: there is no chance because nobody cares. :) Patch 1/9 cleans up a couple minor bugs in the fixed-function fragment program code. Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to be non-GL_NONE. Thanks to the first patch, this can *never* happen. Patch 5/9 removes gl_fragment_program::FogOption. The remaining four patches remove all the dangling bits of support for fixed-function fog on i915. Since fog is (and always has been) handled by fragment programs on i915, this code is completely useless. I have tested this whole series on Ironlake (i965 driver) and G33 (i915 driver). There were no piglit or GTF regressions in either case. I believe that, at the very least, the first four patches are suitable for the stable branches (after a suitable settling period on master, of course). The remaining five patches may also be suitable. src/mesa/drivers/dri/i915/i915_context.c | 8 +- src/mesa/drivers/dri/i915/i915_context.h | 15 -- src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +-- src/mesa/drivers/dri/i915/i915_state.c | 164 +--- src/mesa/drivers/dri/i915/i915_vtbl.c | 9 - src/mesa/drivers/dri/i965/brw_program.c | 5 - .../drivers/dri/r300/compiler/r300_fragprog_emit.c | 2 - src/mesa/main/ff_fragment_shader.cpp | 44 +++--- src/mesa/main/mtypes.h | 1 - src/mesa/program/arbprogparse.c | 18 +-- src/mesa/program/program.c | 1 - src/mesa/program/programopt.c | 33 +++-- src/mesa/program/programopt.h | 4 +- src/mesa/swrast/s_context.c | 15 +-- src/mesa/tnl/t_context.c | 12 +- 15 files changed, 70 insertions(+), 272 deletions(-) r300 *did* support FF fog at one point, but it got tossed out because we couldn't get it to work with fog coordinates. (Well, *I* couldn't get it to work; I think osiris got it mostly-working-sort-of at one point.) This code will not be missed. Right. I believe people eventually figured out that fglrx didn't use the fixed-function fog either. It seems likely that it was for the same reason. :) Looking at the i915 docs, there a bunch of restrictions and weird quirks that look like they'd make it more trouble that it's worth. Plus, I don't think a lot of applications use part shader / part fixed-function anyway. Can I call this an Acked-by? Looks good to me. Acked-by: Alex Deucher alexdeuc...@gmail.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb /swAnixkaFG6jKh0FrgPk3hoi6wFu+uY =p6R3 -END PGP SIGNATURE- ___ 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 0/9] Big pile of fog clean up
Acked-by: Corbin Simpson mostawesomed...@gmail.com Sending from a mobile, pardon the brevity. ~ C. On Apr 19, 2011 4:13 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2011 09:45 AM, Corbin Simpson wrote: On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick i...@freedesktop.org wrote: This patch series cleans out the last vestiges of fixed-function fog support with ARB_fragment_program. We talked about doing this quite some time ago, but we decided to hold off. The thinking at the time was that there was still a chance that someone might add support for the fixed-function fog on either i915 or r300. Reality check: there is no chance because nobody cares. :) Patch 1/9 cleans up a couple minor bugs in the fixed-function fragment program code. Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to be non-GL_NONE. Thanks to the first patch, this can *never* happen. Patch 5/9 removes gl_fragment_program::FogOption. The remaining four patches remove all the dangling bits of support for fixed-function fog on i915. Since fog is (and always has been) handled by fragment programs on i915, this code is completely useless. I have tested this whole series on Ironlake (i965 driver) and G33 (i915 driver). There were no piglit or GTF regressions in either case. I believe that, at the very least, the first four patches are suitable for the stable branches (after a suitable settling period on master, of course). The remaining five patches may also be suitable. src/mesa/drivers/dri/i915/i915_context.c | 8 +- src/mesa/drivers/dri/i915/i915_context.h | 15 -- src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +-- src/mesa/drivers/dri/i915/i915_state.c | 164 +--- src/mesa/drivers/dri/i915/i915_vtbl.c | 9 - src/mesa/drivers/dri/i965/brw_program.c | 5 - .../drivers/dri/r300/compiler/r300_fragprog_emit.c | 2 - src/mesa/main/ff_fragment_shader.cpp | 44 +++--- src/mesa/main/mtypes.h | 1 - src/mesa/program/arbprogparse.c | 18 +-- src/mesa/program/program.c | 1 - src/mesa/program/programopt.c | 33 +++-- src/mesa/program/programopt.h | 4 +- src/mesa/swrast/s_context.c | 15 +-- src/mesa/tnl/t_context.c | 12 +- 15 files changed, 70 insertions(+), 272 deletions(-) r300 *did* support FF fog at one point, but it got tossed out because we couldn't get it to work with fog coordinates. (Well, *I* couldn't get it to work; I think osiris got it mostly-working-sort-of at one point.) This code will not be missed. Right. I believe people eventually figured out that fglrx didn't use the fixed-function fog either. It seems likely that it was for the same reason. :) Looking at the i915 docs, there a bunch of restrictions and weird quirks that look like they'd make it more trouble that it's worth. Plus, I don't think a lot of applications use part shader / part fixed-function anyway. Can I call this an Acked-by? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb /swAnixkaFG6jKh0FrgPk3hoi6wFu+uY =p6R3 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark
https://bugs.freedesktop.org/show_bug.cgi?id=36295 --- Comment #15 from Ian Romanick i...@freedesktop.org 2011-04-19 17:21:46 PDT --- (In reply to comment #14) (In reply to comment #13) The downside is that app developers never fix *THEIR* bugs. [...] And this is the disaster that we're trying to fix via conformance testing. This crap has to STOP. This is why people think OpenGL is joke. (This is slightly OT, but I'd argue that the OpenGL problem is not that spec conformance per se, but the proliferation of vendor specific extensions, and extensions in general; and the fix is not conformance testing but the ARB ratifying the extensions people care and lumping extensions in core versions. It looks things are moving on the right direction. That said, latest core version is 4.0 and we're still in 2.1, so I'm thankful for extensions that get us half way there.) Anyway, Ian, I see you strongly feel against the proposed patch, but I still am not sure exactly what you oppose: diverging the spec, or adding the extensions to meet an application's requirement? That is, would fully implementing NV_fragment_program2 to the spec and advertising it for SPECviewperf11's sake be OK with you or not, and why? I don't care too much what extensions we decide to support. We already support most of NV_fragment_program2. The primary missing bits are support for clip distance, and we need to add that for GLSL 1.30 anyway. I don't recall if the rest of the support is in master or on an old, dusty branch. It might be one one of my asm-shader-rework branches... I am strongly opposed to allowing an application to use functionality that is not advertised or, in the case of GLSL extensions, not enabled because it prevents us from removing those features in the future. Over the last 18 months we've removed a lot of old extensions that we did not want the on going burden of supporting. I fully expect that we will do more of this in the future. When applications either gracefully don't work or fallback to different rendering paths, this is fine. When apps start to explode, it's not fine. When we let applications use undocumented features or use documented features in illegal ways, we paint ourselves into a corner. We effectively trade short-term gain for long-term pain. -- 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/8] mesa: use is_bufferobj() helper function
---
src/mesa/drivers/x11/xm_dd.c |4 ++--
src/mesa/main/drawpix.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_dd.c b/src/mesa/drivers/x11/xm_dd.c
index 3031b7b..1369946 100644
--- a/src/mesa/drivers/x11/xm_dd.c
+++ b/src/mesa/drivers/x11/xm_dd.c
@@ -445,7 +445,7 @@ xmesa_DrawPixels_8R8G8B( struct gl_context *ctx,
if (swrast-NewState)
_swrast_validate_derived( ctx );
- if (unpack-BufferObj-Name) {
+ if (_mesa_is_bufferobj(unpack-BufferObj)) {
/* unpack from PBO */
GLubyte *buf;
if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
@@ -507,7 +507,7 @@ xmesa_DrawPixels_8R8G8B( struct gl_context *ctx,
XPutImage(dpy, xrb-pixmap, gc, ximage, 0, 0, dstX, dstY, w, h);
}
- if (unpack-BufferObj-Name) {
+ if (_mesa_is_bufferobj(unpack-BufferObj)) {
ctx-Driver.UnmapBuffer(ctx, GL_PIXEL_UNPACK_BUFFER_EXT,
unpack-BufferObj);
}
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index ee379f7..a8b948d 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -90,7 +90,7 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
GLint x = IROUND(ctx-Current.RasterPos[0]);
GLint y = IROUND(ctx-Current.RasterPos[1]);
- if (ctx-Unpack.BufferObj-Name) {
+ if (_mesa_is_bufferobj(ctx-Unpack.BufferObj)) {
/* unpack from PBO */
if (!_mesa_validate_pbo_access(2, ctx-Unpack, width, height, 1,
format, type, pixels)) {
@@ -249,7 +249,7 @@ _mesa_Bitmap( GLsizei width, GLsizei height,
GLint x = IFLOOR(ctx-Current.RasterPos[0] + epsilon - xorig);
GLint y = IFLOOR(ctx-Current.RasterPos[1] + epsilon - yorig);
- if (ctx-Unpack.BufferObj-Name) {
+ if (_mesa_is_bufferobj(ctx-Unpack.BufferObj)) {
/* unpack from PBO */
if (!_mesa_validate_pbo_access(2, ctx-Unpack, width, height, 1,
GL_COLOR_INDEX, GL_BITMAP,
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/8] mesa: add bounds-checking support for client memory buffers
This is the first step towards supporting the extension
GL_ARB_robustness.
---
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |2 +-
src/mesa/drivers/x11/xm_dd.c|6 +-
src/mesa/main/dlist.c |4 +-
src/mesa/main/drawpix.c | 10 ++--
src/mesa/main/pbo.c | 52 +--
src/mesa/main/pbo.h |3 +-
src/mesa/main/pixel.c |2 +-
src/mesa/main/readpix.c |2 +-
src/mesa/main/texgetimage.c |2 +-
9 files changed, 46 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
index 43cdd0d..e59b41d 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
@@ -68,7 +68,7 @@ static const GLubyte *map_pbo( struct gl_context *ctx,
if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
GL_COLOR_INDEX, GL_BITMAP,
- (GLvoid *) bitmap)) {
+ INT_MAX, (const GLvoid *) bitmap)) {
_mesa_error(ctx, GL_INVALID_OPERATION,glBitmap(invalid PBO access));
return NULL;
}
diff --git a/src/mesa/drivers/x11/xm_dd.c b/src/mesa/drivers/x11/xm_dd.c
index 1369946..81f48f9 100644
--- a/src/mesa/drivers/x11/xm_dd.c
+++ b/src/mesa/drivers/x11/xm_dd.c
@@ -449,7 +449,7 @@ xmesa_DrawPixels_8R8G8B( struct gl_context *ctx,
/* unpack from PBO */
GLubyte *buf;
if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
-format, type, pixels)) {
+format, type, INT_MAX, pixels)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glDrawPixels(invalid PBO access));
return;
@@ -580,11 +580,11 @@ xmesa_DrawPixels_5R6G5B( struct gl_context *ctx,
if (swrast-NewState)
_swrast_validate_derived( ctx );
- if (unpack-BufferObj-Name) {
+ if (_mesa_is_bufferobj(unpack-BufferObj)) {
/* unpack from PBO */
GLubyte *buf;
if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
-format, type, pixels)) {
+format, type, INT_MAX, pixels)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glDrawPixels(invalid PBO access));
return;
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index f66082e..63653df 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -859,8 +859,8 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
}
return image;
}
- else if (_mesa_validate_pbo_access(dimensions, unpack, width, height, depth,
- format, type, pixels)) {
+ else if (_mesa_validate_pbo_access(dimensions, unpack, width, height,
+ depth, format, type, INT_MAX, pixels)) {
const GLubyte *map, *src;
GLvoid *image;
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index a8b948d..89c2b26 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -92,8 +92,8 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
if (_mesa_is_bufferobj(ctx-Unpack.BufferObj)) {
/* unpack from PBO */
-if (!_mesa_validate_pbo_access(2, ctx-Unpack, width, height, 1,
- format, type, pixels)) {
+if (!_mesa_validate_pbo_access(2, ctx-Unpack, width, height,
+ 1, format, type, INT_MAX, pixels)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glDrawPixels(invalid PBO access));
goto end;
@@ -251,9 +251,9 @@ _mesa_Bitmap( GLsizei width, GLsizei height,
if (_mesa_is_bufferobj(ctx-Unpack.BufferObj)) {
/* unpack from PBO */
-if (!_mesa_validate_pbo_access(2, ctx-Unpack, width, height, 1,
- GL_COLOR_INDEX, GL_BITMAP,
- (GLvoid *) bitmap)) {
+if (!_mesa_validate_pbo_access(2, ctx-Unpack, width, height,
+ 1, GL_COLOR_INDEX, GL_BITMAP,
+ INT_MAX, (const GLvoid *) bitmap)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBitmap(invalid PBO access));
return;
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 56b26a9..0a686db 100644
--- a/src/mesa/main/pbo.c
+++ b/src/mesa/main/pbo.c
@@ -43,7 +43,7 @@
* When we're about to read pixel data out of a PBO (via glDrawPixels,
* glTexImage, etc) or
[Mesa-dev] [PATCH 3/8] mesa: add more bounds-checking support for client memory buffers
---
src/mesa/main/colortab.c |4 +-
src/mesa/main/pbo.c | 64 +++--
src/mesa/main/pbo.h |8 +++---
src/mesa/main/polygon.c |7 +++--
4 files changed, 48 insertions(+), 35 deletions(-)
diff --git a/src/mesa/main/colortab.c b/src/mesa/main/colortab.c
index 35b3096..5414acc 100644
--- a/src/mesa/main/colortab.c
+++ b/src/mesa/main/colortab.c
@@ -190,7 +190,7 @@ store_colortable_entries(struct gl_context *ctx,
struct gl_color_table *table,
{
data = _mesa_map_validate_pbo_source(ctx,
1, ctx-Unpack, count, 1, 1,
-format, type, data,
+format, type, INT_MAX, data,
glColor[Sub]Table);
if (!data)
return;
@@ -614,7 +614,7 @@ _mesa_GetColorTable( GLenum target, GLenum format,
data = _mesa_map_validate_pbo_dest(ctx,
1, ctx-Pack, table-Size, 1, 1,
- format, type, data,
+ format, type, INT_MAX, data,
glGetColorTable);
if (!data)
return;
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 0a686db..15e0480 100644
--- a/src/mesa/main/pbo.c
+++ b/src/mesa/main/pbo.c
@@ -155,26 +155,32 @@ _mesa_map_pbo_source(struct gl_context *ctx,
*/
const GLvoid *
_mesa_map_validate_pbo_source(struct gl_context *ctx,
- GLuint dimensions,
- const struct gl_pixelstore_attrib *unpack,
- GLsizei width, GLsizei height, GLsizei depth,
- GLenum format, GLenum type, const GLvoid *ptr,
- const char *where)
+ GLuint dimensions,
+ const struct gl_pixelstore_attrib *unpack,
+ GLsizei width, GLsizei height, GLsizei depth,
+ GLenum format, GLenum type, GLsizei
clientMemSize,
+ const GLvoid *ptr, const char *where)
{
ASSERT(dimensions == 1 || dimensions == 2 || dimensions == 3);
- if (!_mesa_is_bufferobj(unpack-BufferObj)) {
- /* non-PBO access: no validation to be done */
- return ptr;
- }
-
if (!_mesa_validate_pbo_access(dimensions, unpack, width, height, depth,
- format, type, INT_MAX, ptr)) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- %s(out of bounds PBO access), where);
+ format, type, clientMemSize, ptr)) {
+ if (_mesa_is_bufferobj(unpack-BufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(out of bounds PBO access), where);
+ } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(out of bounds access: bufSize (%d) is too small),
+ where, clientMemSize);
+ }
return NULL;
}
+ if (!_mesa_is_bufferobj(unpack-BufferObj)) {
+ /* non-PBO access: no further validation to be done */
+ return ptr;
+ }
+
if (_mesa_bufferobj_mapped(unpack-BufferObj)) {
/* buffer is already mapped - that's an error */
_mesa_error(ctx, GL_INVALID_OPERATION, %s(PBO is mapped), where);
@@ -245,26 +251,32 @@ _mesa_map_pbo_dest(struct gl_context *ctx,
*/
GLvoid *
_mesa_map_validate_pbo_dest(struct gl_context *ctx,
-GLuint dimensions,
-const struct gl_pixelstore_attrib *unpack,
-GLsizei width, GLsizei height, GLsizei depth,
-GLenum format, GLenum type, GLvoid *ptr,
-const char *where)
+ GLuint dimensions,
+ const struct gl_pixelstore_attrib *unpack,
+ GLsizei width, GLsizei height, GLsizei depth,
+ GLenum format, GLenum type, GLsizei
clientMemSize,
+ GLvoid *ptr, const char *where)
{
ASSERT(dimensions == 1 || dimensions == 2 || dimensions == 3);
- if (!_mesa_is_bufferobj(unpack-BufferObj)) {
- /* non-PBO access: no validation to be done */
- return ptr;
- }
-
if (!_mesa_validate_pbo_access(dimensions, unpack, width, height, depth,
- format, type, INT_MAX, ptr)) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- %s(out of bounds PBO access), where);
+ format, type, clientMemSize, ptr)) {
+ if (_mesa_is_bufferobj(unpack-BufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(out of bounds PBO access), where);
+ } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+
[Mesa-dev] [PATCH 4/8] mesa: standardize some bounds-checking error messages
---
src/mesa/main/pixel.c | 41 -
1 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/pixel.c b/src/mesa/main/pixel.c
index 6e4ed99..62dd13e 100644
--- a/src/mesa/main/pixel.c
+++ b/src/mesa/main/pixel.c
@@ -145,8 +145,9 @@ store_pixelmap(struct gl_context *ctx, GLenum map,
GLsizei mapsize,
* Convenience wrapper for _mesa_validate_pbo_access() for gl[Get]PixelMap().
*/
static GLboolean
-validate_pbo_access(struct gl_context *ctx, struct gl_pixelstore_attrib *pack,
-GLsizei mapsize, GLenum format, GLenum type,
+validate_pbo_access(struct gl_context *ctx,
+struct gl_pixelstore_attrib *pack, GLsizei mapsize,
+GLenum format, GLenum type, GLsizei clientMemSize,
const GLvoid *ptr)
{
GLboolean ok;
@@ -157,7 +158,7 @@ validate_pbo_access(struct gl_context *ctx, struct
gl_pixelstore_attrib *pack,
pack-BufferObj);
ok = _mesa_validate_pbo_access(1, ctx-DefaultPacking, mapsize, 1, 1,
- format, type, INT_MAX, ptr);
+ format, type, clientMemSize, ptr);
/* restore */
_mesa_reference_buffer_object(ctx,
@@ -165,8 +166,14 @@ validate_pbo_access(struct gl_context *ctx,
struct gl_pixelstore_attrib *pack,
ctx-Shared-NullBufferObj);
if (!ok) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- glPixelMap(invalid PBO access));
+ if (_mesa_is_bufferobj(pack-BufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ gl[Get]PixelMap*v(out of bounds PBO access));
+ } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glGetnPixelMap*vARB(out of bounds access:
+ bufSize (%d) is too small), clientMemSize);
+ }
}
return ok;
}
@@ -194,8 +201,8 @@ _mesa_PixelMapfv( GLenum map, GLsizei mapsize,
const GLfloat *values )
FLUSH_VERTICES(ctx, _NEW_PIXEL);
- if (!validate_pbo_access(ctx, ctx-Unpack, mapsize,
-GL_INTENSITY, GL_FLOAT, values)) {
+ if (!validate_pbo_access(ctx, ctx-Unpack, mapsize, GL_INTENSITY,
+GL_FLOAT, INT_MAX, values)) {
return;
}
@@ -236,8 +243,8 @@ _mesa_PixelMapuiv(GLenum map, GLsizei mapsize,
const GLuint *values )
FLUSH_VERTICES(ctx, _NEW_PIXEL);
- if (!validate_pbo_access(ctx, ctx-Unpack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_INT, values)) {
+ if (!validate_pbo_access(ctx, ctx-Unpack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_INT, INT_MAX, values)) {
return;
}
@@ -292,8 +299,8 @@ _mesa_PixelMapusv(GLenum map, GLsizei mapsize,
const GLushort *values )
FLUSH_VERTICES(ctx, _NEW_PIXEL);
- if (!validate_pbo_access(ctx, ctx-Unpack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_SHORT, values)) {
+ if (!validate_pbo_access(ctx, ctx-Unpack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_SHORT, INT_MAX, values)) {
return;
}
@@ -343,8 +350,8 @@ _mesa_GetPixelMapfv( GLenum map, GLfloat *values )
mapsize = pm-Size;
- if (!validate_pbo_access(ctx, ctx-Pack, mapsize,
-GL_INTENSITY, GL_FLOAT, values)) {
+ if (!validate_pbo_access(ctx, ctx-Pack, mapsize, GL_INTENSITY,
+GL_FLOAT, INT_MAX, values)) {
return;
}
@@ -387,8 +394,8 @@ _mesa_GetPixelMapuiv( GLenum map, GLuint *values )
}
mapsize = pm-Size;
- if (!validate_pbo_access(ctx, ctx-Pack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_INT, values)) {
+ if (!validate_pbo_access(ctx, ctx-Pack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_INT, INT_MAX, values)) {
return;
}
@@ -431,8 +438,8 @@ _mesa_GetPixelMapusv( GLenum map, GLushort *values )
}
mapsize = pm-Size;
- if (!validate_pbo_access(ctx, ctx-Pack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_SHORT, values)) {
+ if (!validate_pbo_access(ctx, ctx-Pack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_SHORT, INT_MAX, values)) {
return;
}
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/8] mesa: standardize more bounds-checking error messages
---
src/mesa/main/readpix.c | 25 ++---
src/mesa/main/texgetimage.c | 63 ++-
2 files changed, 53 insertions(+), 35 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index fd6752b..465be9f 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -224,19 +224,24 @@ _mesa_ReadPixels( GLint x, GLint y, GLsizei
width, GLsizei height,
if (width == 0 || height == 0)
return; /* nothing to do */
- if (_mesa_is_bufferobj(ctx-Pack.BufferObj)) {
- if (!_mesa_validate_pbo_access(2, ctx-Pack, width, height, 1,
- format, type, 0, pixels)) {
+ if (!_mesa_validate_pbo_access(2, ctx-Pack, width, height, 1,
+ format, type, INT_MAX, pixels)) {
+ if (_mesa_is_bufferobj(ctx-Pack.BufferObj)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glReadPixels(invalid PBO access));
- return;
+ glReadPixels(out of bounds PBO access));
+ } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glReadnPixelsARB(out of bounds access:
+ bufSize (%d) is too small), INT_MAX);
}
+ return;
+ }
- if (_mesa_bufferobj_mapped(ctx-Pack.BufferObj)) {
- /* buffer is mapped - that's an error */
- _mesa_error(ctx, GL_INVALID_OPERATION, glReadPixels(PBO is mapped));
- return;
- }
+ if (_mesa_is_bufferobj(ctx-Pack.BufferObj)
+ _mesa_bufferobj_mapped(ctx-Pack.BufferObj)) {
+ /* buffer is mapped - that's an error */
+ _mesa_error(ctx, GL_INVALID_OPERATION, glReadPixels(PBO is mapped));
+ return;
}
ctx-Driver.ReadPixels(ctx, x, y, width, height,
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 79af23f..581d7fd 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -623,11 +623,13 @@ _mesa_get_compressed_teximage(struct gl_context
*ctx, GLenum target, GLint level
*/
static GLboolean
getteximage_error_check(struct gl_context *ctx, GLenum target, GLint level,
-GLenum format, GLenum type, GLvoid *pixels )
+GLenum format, GLenum type, GLsizei clientMemSize,
+GLvoid *pixels )
{
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
const GLint maxLevels = _mesa_max_texture_levels(ctx, target);
+ const GLuint dimensions = (target == GL_TEXTURE_3D) ? 3 : 2;
GLenum baseFormat;
if (maxLevels == 0) {
@@ -730,17 +732,21 @@ getteximage_error_check(struct gl_context *ctx,
GLenum target, GLint level,
return GL_TRUE;
}
- if (_mesa_is_bufferobj(ctx-Pack.BufferObj)) {
- /* packing texture image into a PBO */
- const GLuint dimensions = (target == GL_TEXTURE_3D) ? 3 : 2;
- if (!_mesa_validate_pbo_access(dimensions, ctx-Pack, texImage-Width,
- texImage-Height, texImage-Depth,
- format, type, INT_MAX, pixels)) {
+ if (!_mesa_validate_pbo_access(dimensions, ctx-Pack, texImage-Width,
+ texImage-Height, texImage-Depth,
+ format, type, clientMemSize, pixels)) {
+ if (_mesa_is_bufferobj(ctx-Pack.BufferObj)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glGetTexImage(out of bounds PBO write));
- return GL_TRUE;
+ glGetTexImage(out of bounds PBO access));
+ } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glGetnTexImageARB(out of bounds access:
+ bufSize (%d) is too small), clientMemSize);
}
+ return GL_TRUE;
+ }
+ if (_mesa_is_bufferobj(ctx-Pack.BufferObj)) {
/* PBO should not be mapped */
if (_mesa_bufferobj_mapped(ctx-Pack.BufferObj)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
@@ -772,7 +778,8 @@ _mesa_GetTexImage( GLenum target, GLint level,
GLenum format,
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
- if (getteximage_error_check(ctx, target, level, format, type, pixels)) {
+ if (getteximage_error_check(ctx, target, level, format, type,
+ INT_MAX, pixels)) {
return;
}
@@ -809,11 +816,12 @@ _mesa_GetTexImage( GLenum target, GLint level,
GLenum format,
*/
static GLboolean
getcompressedteximage_error_check(struct gl_context *ctx, GLenum target,
- GLint level, GLvoid *img)
+ GLint level, GLsizei clientMemSize,
GLvoid *img)
{
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
const GLint maxLevels = _mesa_max_texture_levels(ctx, target);
+ GLuint compressedSize;
if (maxLevels == 0) {
_mesa_error(ctx, GL_INVALID_ENUM,
[Mesa-dev] [PATCH 6/8] mesa: add context fields for GL_ARB_robustness
---
src/mesa/main/context.c|4
src/mesa/main/extensions.c |1 +
src/mesa/main/get.c|3 +++
src/mesa/main/mtypes.h |6 ++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 8053edc..ea13bdd 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -658,6 +658,9 @@ _mesa_init_constants(struct gl_context *ctx)
/** GL_EXT_gpu_shader4 */
ctx-Const.MinProgramTexelOffset = -8;
ctx-Const.MaxProgramTexelOffset = 7;
+
+ /* GL_ARB_robustness */
+ ctx-Const.ResetStrategy = GL_NO_RESET_NOTIFICATION_ARB;
}
@@ -793,6 +796,7 @@ init_attrib_groups(struct gl_context *ctx)
/* Miscellaneous */
ctx-NewState = _NEW_ALL;
ctx-ErrorValue = (GLenum) GL_NO_ERROR;
+ ctx-ResetStatus = (GLenum) GL_NO_ERROR;
ctx-varying_vp_inputs = ~0;
return GL_TRUE;
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8a0ab96..b7ba7ed 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -107,6 +107,7 @@ static const struct extension extension_table[] = {
{ GL_ARB_point_parameters,
o(EXT_point_parameters),GL, 1997 },
{ GL_ARB_point_sprite,
o(ARB_point_sprite),GL, 2003 },
{ GL_ARB_provoking_vertex,
o(EXT_provoking_vertex),GL, 2009 },
+ { GL_ARB_robustness, o(dummy_false),
GL, 2010 },
{ GL_ARB_sampler_objects,
o(ARB_sampler_objects), GL, 2009 },
{ GL_ARB_seamless_cube_map,
o(ARB_seamless_cube_map), GL, 2009 },
{ GL_ARB_shader_objects,
o(ARB_shader_objects), GL, 2002 },
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index e188032..e933bbe 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1281,6 +1281,9 @@ static const struct value_desc values[] = {
/* GL 3.2 */
{ GL_CONTEXT_PROFILE_MASK, CONTEXT_INT(Const.ProfileMask),
extra_version_32 },
+
+ /* GL_ARB_robustness */
+ { GL_RESET_NOTIFICATION_STRATEGY_ARB,
CONTEXT_ENUM(Const.ResetStrategy), NO_EXTRA },
#endif /* FEATURE_GL */
};
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 5a25d64..63629fc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2739,6 +2739,9 @@ struct gl_constants
/* GL_EXT_framebuffer_sRGB */
GLboolean sRGBCapable; /* can enable sRGB blend/update on FBOs */
+
+ /* GL_ARB_robustness */
+ GLenum ResetStrategy;
};
@@ -3298,6 +3301,9 @@ struct gl_context
GLenum ErrorValue;/** Last error code */
+ /* GL_ARB_robustness */
+ GLenum ResetStatus;
+
/**
* Recognize and silence repeated error debug messages in buggy apps.
*/
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/8] mesa: implement GL_ARB_robustness functions
As long as GLX_ARB_create_context_robustness isn't
implemented yet, these function calls are all that's
needed to implement the spec.
The function pointers just need to be hooked up
to the GLAPI dispatch table and such.
---
src/mesa/main/colortab.c| 13 -
src/mesa/main/convolve.c| 27 ++--
src/mesa/main/eval.c| 90 +-
src/mesa/main/get.h |4 ++
src/mesa/main/getstring.c | 17 +++
src/mesa/main/histogram.c | 22 -
src/mesa/main/pixel.c | 34 +++---
src/mesa/main/polygon.c | 11 -
src/mesa/main/polygon.h |3 +
src/mesa/main/readpix.c | 16 +--
src/mesa/main/readpix.h |4 ++
src/mesa/main/texgetimage.c | 25 --
src/mesa/main/texgetimage.h |7 +++-
src/mesa/main/uniforms.c| 101 +--
src/mesa/main/uniforms.h| 17 +++-
15 files changed, 345 insertions(+), 46 deletions(-)
diff --git a/src/mesa/main/colortab.c b/src/mesa/main/colortab.c
index 5414acc..e3a77d8 100644
--- a/src/mesa/main/colortab.c
+++ b/src/mesa/main/colortab.c
@@ -509,8 +509,8 @@ _mesa_CopyColorSubTable(GLenum target, GLsizei start,
static void GLAPIENTRY
-_mesa_GetColorTable( GLenum target, GLenum format,
- GLenum type, GLvoid *data )
+_mesa_GetnColorTableARB( GLenum target, GLenum format, GLenum type,
+ GLsizei bufSize, GLvoid *data )
{
GET_CURRENT_CONTEXT(ctx);
struct gl_texture_unit *texUnit = _mesa_get_current_tex_unit(ctx);
@@ -614,7 +614,7 @@ _mesa_GetColorTable( GLenum target, GLenum format,
data = _mesa_map_validate_pbo_dest(ctx,
1, ctx-Pack, table-Size, 1, 1,
- format, type, INT_MAX, data,
+ format, type, bufSize, data,
glGetColorTable);
if (!data)
return;
@@ -630,6 +630,13 @@ _mesa_GetColorTable( GLenum target, GLenum format,
}
+static void GLAPIENTRY
+_mesa_GetColorTable( GLenum target, GLenum format,
+ GLenum type, GLvoid *data )
+{
+ _mesa_GetnColorTableARB(target, format, type, INT_MAX, data);
+}
+
static void GLAPIENTRY
_mesa_ColorTableParameterfv(GLenum target, GLenum pname, const GLfloat *params)
diff --git a/src/mesa/main/convolve.c b/src/mesa/main/convolve.c
index 5d286eb..d5b3d5b 100644
--- a/src/mesa/main/convolve.c
+++ b/src/mesa/main/convolve.c
@@ -115,8 +115,8 @@ _mesa_CopyConvolutionFilter2D(GLenum target,
GLenum internalFormat, GLint x, GLi
static void GLAPIENTRY
-_mesa_GetConvolutionFilter(GLenum target, GLenum format, GLenum type,
- GLvoid *image)
+_mesa_GetnConvolutionFilterARB(GLenum target, GLenum format, GLenum type,
+ GLsizei bufSize, GLvoid *image)
{
GET_CURRENT_CONTEXT(ctx);
@@ -125,6 +125,14 @@ _mesa_GetConvolutionFilter(GLenum target, GLenum
format, GLenum type,
static void GLAPIENTRY
+_mesa_GetConvolutionFilter(GLenum target, GLenum format, GLenum type,
+ GLvoid *image)
+{
+ _mesa_GetnConvolutionFilterARB(target, format, type, INT_MAX, image);
+}
+
+
+static void GLAPIENTRY
_mesa_GetConvolutionParameterfv(GLenum target, GLenum pname, GLfloat *params)
{
GET_CURRENT_CONTEXT(ctx);
@@ -143,8 +151,10 @@ _mesa_GetConvolutionParameteriv(GLenum target,
GLenum pname, GLint *params)
static void GLAPIENTRY
-_mesa_GetSeparableFilter(GLenum target, GLenum format, GLenum type,
- GLvoid *row, GLvoid *column, GLvoid *span)
+_mesa_GetnSeparableFilterARB(GLenum target, GLenum format, GLenum type,
+ GLsizei rowBufSize, GLvoid *row,
+ GLsizei columnBufSize, GLvoid *column,
+ GLvoid *span)
{
GET_CURRENT_CONTEXT(ctx);
@@ -153,6 +163,15 @@ _mesa_GetSeparableFilter(GLenum target, GLenum
format, GLenum type,
static void GLAPIENTRY
+_mesa_GetSeparableFilter(GLenum target, GLenum format, GLenum type,
+ GLvoid *row, GLvoid *column, GLvoid *span)
+{
+ _mesa_GetnSeparableFilterARB(target, format, type, INT_MAX, row,
+INT_MAX, column, span);
+}
+
+
+static void GLAPIENTRY
_mesa_SeparableFilter2D(GLenum target, GLenum internalFormat, GLsizei
width, GLsizei height, GLenum format, GLenum type, const GLvoid *row,
const GLvoid *column)
{
GET_CURRENT_CONTEXT(ctx);
diff --git a/src/mesa/main/eval.c b/src/mesa/main/eval.c
index 9ab5507..9eb4f67 100644
--- a/src/mesa/main/eval.c
+++ b/src/mesa/main/eval.c
@@ -545,7 +545,7 @@ _mesa_Map2d( GLenum target,
static void GLAPIENTRY
-_mesa_GetMapdv( GLenum target, GLenum query, GLdouble *v )
+_mesa_GetnMapdvARB( GLenum target, GLenum query, GLsizei bufSize, GLdouble *v )
{
GET_CURRENT_CONTEXT(ctx);
struct gl_1d_map *map1d;
@@ -553,6 +553,7 @@
[Mesa-dev] [PATCH 8/8] glapi: add ARB_robustness xml
--- src/mapi/glapi/gen/ARB_robustness.xml | 185 + src/mapi/glapi/gen/Makefile |1 + src/mapi/glapi/gen/gl_API.xml |2 + 3 files changed, 188 insertions(+), 0 deletions(-) create mode 100644 src/mapi/glapi/gen/ARB_robustness.xml diff --git a/src/mapi/glapi/gen/ARB_robustness.xml b/src/mapi/glapi/gen/ARB_robustness.xml new file mode 100644 index 000..07c87ac --- /dev/null +++ b/src/mapi/glapi/gen/ARB_robustness.xml @@ -0,0 +1,185 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +!-- Note: no GLX protocol info yet. -- + + +OpenGLAPI + +category name=GL_ARB_robustness number=105 + +enum name=GUILTY_CONTEXT_RESET_ARB value=0x8253/ +enum name=INNOCENT_CONTEXT_RESET_ARB value=0x8254/ +enum name=UNKNOWN_CONTEXT_RESET_ARBvalue=0x8255/ + +enum name=RESET_NOTIFICATION_STRATEGY_ARB count=1 value=0x8256 +size name=Get mode=get/ +/enum +enum name=LOSE_CONTEXT_ON_RESET_ARBvalue=0x8252/ +enum name=NO_RESET_NOTIFICATION_ARBvalue=0x8261/ + +enum name=CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB value=0x0004/ + +function name=GetGraphicsResetStatusARB offset=assign +return type=GLenum/ +/function + +!-- OpenGL 1.0 sized buffer queries -- +function name=GetnMapdvARB offset=assign +param name=target type=GLenum/ +param name=query type=GLenum/ +param name=bufSize type=GLsizei/ +param name=v type=GLdouble * output=true/ +/function + +function name=GetnMapfvARB offset=assign +param name=target type=GLenum/ +param name=query type=GLenum/ +param name=bufSize type=GLsizei/ +param name=v type=GLfloat * output=true/ +/function + +function name=GetnMapivARB offset=assign +param name=target type=GLenum/ +param name=query type=GLenum/ +param name=bufSize type=GLsizei/ +param name=v type=GLint * output=true/ +/function + + + +function name=GetnPixelMapfvARB offset=assign +param name=map type=GLenum/ +param name=bufSize type=GLsizei/ +param name=values type=GLfloat * output=true/ +/function + +function name=GetnPixelMapuivARB offset=assign +param name=map type=GLenum/ +param name=bufSize type=GLsizei/ +param name=values type=GLuint * output=true/ +/function + +function name=GetnPixelMapusvARB offset=assign +param name=map type=GLenum/ +param name=bufSize type=GLsizei/ +param name=values type=GLushort * output=true/ +/function + + + +function name=GetnPolygonStippleARB offset=assign +param name=bufSize type=GLsizei/ +param name=pattern type=GLubyte * output=true/ +/function + +function name=GetnTexImageARB offset=assign +param name=target type=GLenum/ +param name=level type=GLint/ +param name=format type=GLenum/ +param name=type type=GLenum/ +param name=bufSize type=GLsizei/ +param name=img type=GLvoid * output=true/ +/function + +function name=ReadnPixelsARB offset=assign +param name=x type=GLint/ +param name=y type=GLint/ +param name=width type=GLsizei/ +param name=height type=GLsizei/ +param name=format type=GLenum/ +param name=type type=GLenum/ +param name=bufSize type=GLsizei/ +param name=data type=GLvoid * output=true/ +/function + + +!-- ARB_imaging sized buffer queries -- +function name=GetnColorTableARB offset=assign +param name=target type=GLenum/ +param name=format type=GLenum/ +param name=type type=GLenum/ +param name=bufSize type=GLsizei/ +param name=table type=GLvoid * output=true/ +/function + +function name=GetnConvolutionFilterARB offset=assign +param name=target type=GLenum/ +param name=format type=GLenum/ +param name=type type=GLenum/ +param name=bufSize type=GLsizei/ +param name=image type=GLvoid * output=true/ +/function + +function name=GetnSeparableFilterARB offset=assign +param name=target type=GLenum/ +param name=format type=GLenum/ +param name=type type=GLenum/ +param name=rowBufSize type=GLsizei/ +param name=row type=GLvoid * output=true/ +param name=columnBufSize type=GLsizei/ +param name=column type=GLvoid * output=true/ +param name=span type=GLvoid * output=true/ +/function + +function name=GetnHistogramARB offset=assign +param name=target type=GLenum/ +param name=reset type=GLboolean/ +param name=format type=GLenum/ +param name=type type=GLenum/ +param name=bufSize type=GLsizei/ +param name=values type=GLvoid * output=true/ +/function + +function name=GetnMinmaxARB offset=assign +param name=target
Re: [Mesa-dev] [PATCH 1/3] glsl: correctly handle conversions between int and uint
On 04/19/2011 05:43 PM, Ian Romanick wrote:
On 04/18/2011 04:51 PM, Bryan Cain wrote:
This patch was revised several times before submitting, and even after
that I still wasn't sure that adding conversion operations was the right
solution. So I'm not really surprised that there are problems with this
one. :)
On 04/18/2011 06:36 PM, Ian Romanick wrote:
On 04/17/2011 11:39 PM, Bryan Cain wrote:
From the GLSL 1.30 specification, section 4.1.10 (Implicit
Conversions):
There are no implicit conversions between signed and unsigned
integers.
However, convert_component() was assuming that conversions between
int and uint were implicit.
The conversions applied in convert_component only apply to constructor
parameters. As Ken mentions, in those cases we want
Internally we treat signed and unsigned identically because the
representation is the same. There's no way for an application to
observe the difference between:
ivec4 a = ivec4(5 , 6 , 7 , 8 );
ivec4 b = ivec4(5 , 6 , 7 , 8u);
ivec4 c = ivec4(5 , 6 , 7u, 8 );
ivec4 d = ivec4(5 , 6 , 7u, 8u);
ivec4 e = ivec4(5 , 6u, 7 , 8 );
ivec4 f = ivec4(5 , 6u, 7 , 8u);
ivec4 g = ivec4(5 , 6u, 7u, 8 );
ivec4 h = ivec4(5 , 6u, 7u, 8u);
// etc.
The type checker ensures that operands to operations that could exhibit
differing behavior (e.g., ir_bin_mul) have identical types. That code
lives in arithmetic_result_type in ast_to_hir.cpp. There is similar
code in match_function_by_name in ast_function.cpp.
Do you have any specific test cases in mind that don't produce correct
results with the existing code?
Yes, usages like this:
int var1 = 7;
uint var2 = uint(var1);
They were causing a type mismatch error in ast_to_hir.cpp because
convert_component() was treating the uint(int) constructor as a no-op.
Ah, that makes sense. I just sent some patches to the piglit mailing
list with some tests in this vein.
You've convinced me that we need i2u and u2i unary operators. I don't
think we need b2u and u2b operators because we can just do (i2b(u2i
value)) and (i2u(b2i value)). Ditto for f2i. This should result in
less churn in the backends since u2i and i2u will universally be no-ops.
Almost every place that checks is_integer() will need to check for the
specific type, either GLSL_TYPE_UINT or GLSL_TYPE_INT, that it expects.
This means that your patch 2/3, which is already applied, will need to
be reverted.
Wouldn't it only apply to checks for destination types of most
operations, not source types?
In fact, if instructions store the destination type, what cases would
require the compiler beyond ast_to_hir to even care about the difference
between int and uint?
---
src/glsl/ast_function.cpp | 16
src/glsl/ir.cpp |8
src/glsl/ir.h |2 ++
src/glsl/ir_constant_expression.cpp |8
src/glsl/ir_validate.cpp|8
5 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index e5cb873..cc3f032 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -267,17 +267,25 @@ convert_component(ir_rvalue *src, const
glsl_type *desired_type)
assert(a = GLSL_TYPE_BOOL);
assert(b = GLSL_TYPE_BOOL);
- if ((a == b) || (src-type-is_integer()
desired_type-is_integer()))
+ if (a == b)
return src;
switch (a) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
- if (b == GLSL_TYPE_FLOAT)
+ switch(b) {
+ case GLSL_TYPE_UINT:
+ result = new(ctx) ir_expression(ir_unop_u2i, desired_type,
src, NULL);
+ break;
+ case GLSL_TYPE_INT:
+ result = new(ctx) ir_expression(ir_unop_i2u, desired_type,
src, NULL);
+ break;
+ case GLSL_TYPE_FLOAT:
result = new(ctx) ir_expression(ir_unop_f2i, desired_type,
src, NULL);
With the other changes, leaving this as-is is kind of hinkey. Here the
result base type will be GLSL_TYPE_INT, but the desired based type
could
be GLSL_TYPE_UINT.
Unless I'm missing something, that case is handled by the line if (a ==
b).
What I meant was uint(float) and int(float) will both generate an
ir_unop_f2i, which has type int. So, 'uint x = uint(5.2);' will result
in a type error. Right?
It's not resulting in one for me with the patch applied. Are the exact
source and destination types not stored as part of an expression in GLSL IR?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
