Re: [Mesa-dev] Mesa (master): dri: make sure to build libdricommon.la
On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org (Matt Turner) wrote: Module: Mesa Branch: master Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=80aa78142d12b21dd7d4f0edc786af98a159a80f Author: Matt Turner matts...@gmail.com Date: Thu Jan 26 19:31:12 2012 -0500 dri: make sure to build libdricommon.la Ouch. Sorry about this, folks, I built with a dirty tree and didn't notice that the rebase off of the drirc changes wasn't good enough. pgp5IvVG6Atde.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: Fix handling of glCopyBufferSubData() for src == dst.
On Thu, 26 Jan 2012 13:58:43 -0800, Ian Romanick i...@freedesktop.org wrote:
On 01/25/2012 05:51 PM, Eric Anholt wrote:
Fixes piglit ARB_copy_buffer-overlap, which previously assertion failed.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
One other orthogonal question below...
---
src/mesa/main/bufferobj.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 5b6db78..e4f964f 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -526,11 +526,23 @@ _mesa_copy_buffer_subdata(struct gl_context *ctx,
assert(!_mesa_bufferobj_mapped(src));
assert(!_mesa_bufferobj_mapped(dst));
- srcPtr = ctx-Driver.MapBufferRange(ctx, readOffset, size,
- GL_MAP_READ_BIT, src);
- dstPtr = ctx-Driver.MapBufferRange(ctx, writeOffset, size,
- (GL_MAP_WRITE_BIT |
-GL_MAP_INVALIDATE_RANGE_BIT), dst);
+ if (src == dst) {
+ srcPtr = dstPtr = ctx-Driver.MapBufferRange(ctx, 0, src-Size,
+ GL_MAP_READ_BIT |
+ GL_MAP_WRITE_BIT, src);
+
+ if (!srcPtr)
+return;
+
+ srcPtr += readOffset;
+ dstPtr += writeOffset;
+ } else {
+ srcPtr = ctx-Driver.MapBufferRange(ctx, readOffset, size,
+ GL_MAP_READ_BIT, src);
+ dstPtr = ctx-Driver.MapBufferRange(ctx, writeOffset, size,
+ (GL_MAP_WRITE_BIT |
+ GL_MAP_INVALIDATE_RANGE_BIT), dst);
+ }
/* Note: the src and dst regions will never overlap. Trying to do so
* would generate GL_INVALID_VALUE earlier.
So we have a test for the assertion in this comment? That's the only
case that concerns me in this code.
Piglit ARB_copy_buffer/overlap is quite thorough: for a buffer of size 6
(arbitrary small number), per usage, try every
overlapping/non-overlapping copy, and make sure the right thing happens.
pgpyu1bgFVsky.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] intel: Don't try intel_miptree_map_blit if a region is already mapped
On Thu, 26 Jan 2012 18:29:30 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Eventually this path leads to _intel_batchbuffer_flush. The first thing there is an assertion that nothing is mapped. Fixes the afore mentioned assertion failure in piglit's fbo-mipmap-copypix, and is related to bug #43328. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328 I think the assert is invalid and should be dropped instead. (basically: the assert is assuming that if *anything* is mapped, the batch has been flushed, while the reasonable and more common thing to do, is to flush if your particular buffer was already in use). pgph76OSdh4oj.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Help required in configuring mesa 3d in non X environment.
Michel,
As per the below instructions i tried to compile mesa as follows. But i get
a compilation error in make process. Can you please help me out here ?
./configure --enable-gallium-egl --with-egl-platforms=drm --enable-shared-glapi
--with-gallium-drivers=r600 --enable-gles1
prefix: /usr/local
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: yes (ES1: yes ES2: no)
OpenVG: no
Driver: dri
OSMesa: no
DRI drivers: mach64 r128 r200 r300 r600 radeon tdfx swrast
DRI driver dir: ${libdir}/dri
Use XCB: no
Shared dricore: no
GLU: yes
GLw: yes (Motif: no)
glut:yes
EGL: yes
EGL platforms: drm
EGL drivers: builtin:egl_glx egl_gallium
EGL Gallium STs: $(GL_LIB)
llvm:no
Gallium: yes
Gallium dirs:auxiliary drivers state_trackers
Target dirs: egl-static gbm dri-r600
Winsys dirs: sw sw/xlib sw/dri i915/sw r600/drm
Driver dirs: softpipe failover galahad trace rbug noop identity
i915 i965 r300 svga r600
Trackers dirs: gbm egl dri
Shared libs: yes
Static libs: no
CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fno-strict-aliasing -fPIC
CXXFLAGS:-g -O2 -Wall -fno-strict-aliasing -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DUSE_PPC_ASM -DUSE_VMX_ASM
PYTHON2: python
Run 'make' to build Mesa
root@MPC8641HPCN:~/working/mesa-7.11# make
make[1]: Entering directory `/root/working/mesa-7.11/src'
Making sources for autoconf
make[2]: Entering directory `/root/working/mesa-7.11/src/mapi/shared-glapi'
make[3]: Entering directory `/root/working/mesa-7.11/src/mapi/glapi/gen-es'
make[3]: Nothing to be done for `shared-glapi'.
make[3]: Leaving directory `/root/working/mesa-7.11/src/mapi/glapi/gen-es'
gcc -c -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI
-DMAPI_ABI_HEADER=\shared-glapi/glapi_mapi_tmp.h\ -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC
-DUSE_PPC_ASM -DUSE_VMX_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -fvisibility=hidden
../../../src/mapi/mapi/entry.c -o entry.o
../../../src/mapi/mapi/entry.c: In function 'entry_get_public':
../../../src/mapi/mapi/entry.c:82: error: 'public_entries' undeclared (first
use in this function)
../../../src/mapi/mapi/entry.c:82: error: (Each undeclared identifier is
reported only once
../../../src/mapi/mapi/entry.c:82: error: for each function it appears in.)
make[2]: *** [entry.o] Error 1
make[2]: Leaving directory `/root/working/mesa-7.11/src/mapi/shared-glapi'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/root/working/mesa-7.11/src'
make: *** [default] Error 1
Thank You
Sanjoy Saha
From: Michel Dänzer [mic...@daenzer.net]
Sent: Wednesday, December 28, 2011 4:09 PM
To: Sanjoy Saha - ERS, HCL Tech
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Help required in configuring mesa 3d in non X
environment.
On Sam, 2011-12-24 at 22:52 +0530, Sanjoy Saha - ERS, HCL Tech wrote:
As per my project requirement (Safety critical DO-178B), i have a box
HPCN8641D (ppc) fitted with PCI-E radeon gpu e4690. I have already
back ported kernel DRM module from 2.6.35.3 to 2.6.23 (Pre-installed
in machine). I wanted to run mesa 3D application in it. While trying
to compile mesa 3d with config linux-fbdev (kernel 3d acceleration
enabled), it bails out giving X server libraries/header dependency.
Is it possible to compile mesa without X server libraries/header ?
I'm not sure offhand about compiling without any X headers / libraries
installed, but it's definitely possible to run hardware accelerated
OpenGL (or ES1/2) without X via EGL. The following options for the Mesa
7.11 configure script should help achieve this: --enable-gallium-egl
--with-egl-platforms=drm --enable-shared-glapi
--with-gallium-drivers=r600 (--enable-gles1/2)
Try running any *_screen EGL demo, e.g.
EGL_LOG_LEVEL=debug eglgears_screen
If there's a problem, the EGL_LOG_LEVEL=debug environment variable
should give some useful debugging output.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
::DISCLAIMER::
---
The contents of this
Re: [Mesa-dev] [PATCH] mesa: fix maximum supported texture size returned by glGetIntegrv
This doesn't make sense from a mathematical POV. If the allowable size is 2^floor(log2(MAX_XX_TEXTURE_SIZE)) + 2*bt then it doesn't matter whether MAX_XX_TEXTURE_SIZE has or not the border with, as the allowable size is still the same for all common values of MAX_XX_TEXTURE_SIZE. It would be very odd to define MAX_XX_TEXTURE_SIZE in terms of itself, as there would be a singularity for MAX_XX_TEXTURE_SIZE 4 : no value of MAX_XX_TEXTURE_SIZE under four will satisfy the equation: MAX_XX_TEXTURE_SIZE = 2^floor(log2(MAX_XX_TEXTURE_SIZE)) + 2 If hypothetically one day the spec allowed higher maximum border sizes, it would be even worse. My take is that the border does not need to be implicitly added to MAX_XX_TEXTURE_SIZE query, and the test/driver is wrong. Also it doesn't match what NVIDIA produces: $ glxinfo -l | grep SIZE GL_MAX_TEXTURE_SIZE = 16384 GL_MAX_3D_TEXTURE_SIZE = 2048 GL_ALIASED_POINT_SIZE_RANGE = 1, 63 GL_SMOOTH_POINT_SIZE_RANGE = 1, 63 GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 16384 GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 16384 Jose - Original Message - As per OpenGL 3.0 specification section 3.9, page 187 in pdf the maximum allowable width, height, or depth of a texel array must be at least 2^(k−lod) + 2*bt for image arrays of level-of-detail (lod) 0 through k, where k is the log base 2 of MAX_3D_TEXTURE_SIZE, and bt is the maximum border width Currently different values for maximum allowable texture size are returned by glGetIntegrv() and proxy textures. glGetIntegrv returns 2048 and proxy texture returns (2048 + 2) This patch fixes Intel oglconform test case: max_values Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970 Note: This is a candidate for mesa 8.0 branch. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com --- src/mesa/main/get.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index 5ad6012..4a70109 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -1507,7 +1507,8 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu case GL_MAX_3D_TEXTURE_SIZE: case GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB: p = (GLuint *) ((char *) ctx + d-offset); - v-value_int = 1 (*p - 1); + /* GL 3.0: Add 2 pixels to accmodate border */ + v-value_int = 1 (*p - 1) + 2; break; case GL_SCISSOR_BOX: -- 1.7.7.4 ___ 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 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: case MESA_FORMAT_RGBA: if (format == GL_RGBA type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8 : GL_UNSIGNED_INT_8_8_8_8_REV)) return GL_TRUE; if (format == GL_ABGR_EXT type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8_REV : GL_UNSIGNED_INT_8_8_8_8)) return GL_TRUE; if (format == (!littleEndian ? GL_RGBA : GL_ABGR_EXT) type == GL_UNSIGNED_BYTE) return GL_TRUE; Jose - Original Message - This will let us use memcpy in more situations. We can also remove the checks for byte spapping that happen before the calls to _mesa_format_matches_format_and_type(). --- src/mesa/main/formats.c | 131 +-- 1 files changed, 93 insertions(+), 38 deletions(-) diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c index f352395..a52b38b 100644 --- a/src/mesa/main/formats.c +++ b/src/mesa/main/formats.c @@ -2545,13 +2545,21 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA: - if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8) + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV swapBytes) return GL_TRUE; if (format == GL_RGBA type == GL_UNSIGNED_BYTE !littleEndian) return GL_TRUE; - if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV) + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8 + swapBytes) return GL_TRUE; if (format == GL_ABGR_EXT type == GL_UNSIGNED_BYTE littleEndian) @@ -2560,10 +2568,35 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA_REV: - return format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV; + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_BYTE littleEndian) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8 + !swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV + swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_BYTE !littleEndian) + return GL_TRUE; + + return GL_FALSE; case MESA_FORMAT_ARGB: - if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV) + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8 swapBytes) return GL_TRUE; if (format == GL_BGRA type == GL_UNSIGNED_BYTE littleEndian) @@ -2572,7 +2605,11 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_ARGB_REV: - if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8) + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) + return GL_TRUE; + + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV + swapBytes) return GL_TRUE; if (format == GL_BGRA type == GL_UNSIGNED_BYTE !littleEndian) @@ -2595,7 +2632,8 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_RGB type == GL_UNSIGNED_BYTE littleEndian; case MESA_FORMAT_RGB565: - return format == GL_RGB type == GL_UNSIGNED_SHORT_5_6_5; + return format == GL_RGB type == GL_UNSIGNED_SHORT_5_6_5 !swapBytes; + case MESA_FORMAT_RGB565_REV: /* Some of the 16-bit MESA_FORMATs that would seem to correspond to * GL_UNSIGNED_SHORT_* are byte-swapped instead of channel-reversed, @@ -2604,15 +2642,20 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_ARGB: - return format == GL_BGRA type == GL_UNSIGNED_SHORT_4_4_4_4_REV; + return format == GL_BGRA type == GL_UNSIGNED_SHORT_4_4_4_4_REV +
Re: [Mesa-dev] Mesa (master): draw: Only run prepare when state, prim and opt changes
Ah. Thanks for investigating this Stephane. Garbagge collection happens infrequently, and it really needs to destroy everything. We should just make sure there are no dangling pointers when it does. I'll take a closer look. Jose - Original Message - Ok so I'm thinking of adding a refcount to the variant to know if they are bound, and not garbage collect them in that case. Let me know what you think. Stéphane 2012/1/26 Stéphane Marchesin stephane.marche...@gmail.com: So actually it's a case of a use-after free. The variant is freed with draw_llvm_destroy_variant and then reused through llvm_pipeline_generic after free_gallium_state (and llvm) reused the memory for something else. What prevents a variant bound to an fpme from being freed by the garbage collection? Stéphane 2012/1/26 Stéphane Marchesin stephane.marche...@gmail.com: I just took a look at it in gdb. Basically the jit_func pointer is corrupted by the free_gallivm_state function (in lp_bld_init.c). There is a comment to that effect already. It seems like the bug was always there but hidden because we regenerated state more than we had to. I'll keep digging... Stéphane 2012/1/26 Stéphane Marchesin stephane.marche...@gmail.com: Hmm, I'll take a look later today. Stéphane 2012/1/26 Jose Fonseca jfons...@vmware.com: Stephane, This commit caused a segmentation fault on glean texSwizzle test + llvmpipe: $ gdb --args glean --run results --overwrite --quick --tests texSwizzle (gdb) r Starting program: glean --run results --overwrite --quick --tests texSwizzle [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0xfffc in ?? () (gdb) bt #0 0xfffc in ?? () #1 0x76a26438 in llvm_pipeline_generic (middle=0x76e4a0, fetch_info=0x7fffd730, prim_info=0x7fffd700) at src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:240 #2 0x76a266fe in llvm_middle_end_linear_run (middle=0x76e4a0, start=0, count=4, prim_flags=0) at src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:358 #3 0x7697bf23 in vsplit_segment_simple_linear (vsplit=0x76b670, flags=0, istart=0, icount=4) at src/gallium/auxiliary/draw/draw_pt_vsplit_tmp.h:237 #4 0x7697c228 in vsplit_run_linear (frontend=0x76b670, start=0, count=4) at src/gallium/auxiliary/draw/draw_split_tmp.h:61 #5 0x7697224e in draw_pt_arrays (draw=0x762510, prim=6, start=0, count=4) at src/gallium/auxiliary/draw/draw_pt.c:142 #6 0x76972eb1 in draw_vbo (draw=0x762510, info=0x7fffd910) at src/gallium/auxiliary/draw/draw_pt.c:534 #7 0x76689f67 in llvmpipe_draw_vbo (pipe=0x72fa10, info=0x7fffd910) at src/gallium/drivers/llvmpipe/lp_draw_arrays.c:85 #8 0x768037f4 in st_draw_vbo (ctx=0x7c4b30, arrays=0x831c88, prims=0x7fffd9e0, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3, tfb_vertcount=0x0) at src/mesa/state_tracker/st_draw.c:1113 #9 0x7689d811 in vbo_draw_arrays (ctx=0x7c4b30, mode=6, start=0, count=4, numInstances=1) at src/mesa/vbo/vbo_exec_array.c:635 #10 0x7689d950 in vbo_exec_DrawArrays (mode=6, start=0, count=4) at src/mesa/vbo/vbo_exec_array.c:667 #11 0x00458205 in GLEAN::TexSwizzleTest::TestSwizzles (this=0x6f10e0) at /var/lib/hudson/jobs/glean-ubuntu64/workspace/src/glean/ttexswizzle.cpp:293 #12 0x00458558 in GLEAN::TexSwizzleTest::runOne (this=0x6f10e0, r=..., w=optimized out) at /var/lib/hudson/jobs/glean-ubuntu64/workspace/src/glean/ttexswizzle.cpp:387 #13 0x00458ec7 in GLEAN::BaseTestGLEAN::TexSwizzleResult::run (this=0x6f10e0, environment=optimized out) at /var/lib/hudson/jobs/glean-ubuntu64/workspace/src/glean/tbase.h:317 #14 0x004610b8 in main (argc=7, argv=0x7fffdec8) at /var/lib/hudson/jobs/glean-ubuntu64/workspace/src/glean/main.cpp:140 (gdb) Can you look into it? Jose - Original Message - Module: Mesa Branch: master Commit: b6d3a435a0e0e53a9e8cc4c4249dc7c2f897a83d URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6d3a435a0e0e53a9e8cc4c4249dc7c2f897a83d Author: Jakob Bornecrantz wallbra...@gmail.com Date: Mon Jan 24 02:11:59 2011 +0100 draw: Only run prepare when state, prim and opt changes In bad applications like ipers which does a lot of draw calls with no state changes this helps to greatly reduce time spent in prepare. In ipers around 7% of CPU was spent in various prepare functions, after this commit no prepare function show on the profile. This commit also has the added benefit of now grouping all pipelined drawing into a single draw call if the driver uses vbuf_render. Reviewed-by: Stéphane Marchesin marc...@chromium.org
Re: [Mesa-dev] [PATCH 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
Apart of this simplification suggestion, the series looks good to me AFAICT. Jose - Original Message - Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: case MESA_FORMAT_RGBA: if (format == GL_RGBA type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8 : GL_UNSIGNED_INT_8_8_8_8_REV)) return GL_TRUE; if (format == GL_ABGR_EXT type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8_REV : GL_UNSIGNED_INT_8_8_8_8)) return GL_TRUE; if (format == (!littleEndian ? GL_RGBA : GL_ABGR_EXT) type == GL_UNSIGNED_BYTE) return GL_TRUE; Jose - Original Message - This will let us use memcpy in more situations. We can also remove the checks for byte spapping that happen before the calls to _mesa_format_matches_format_and_type(). --- src/mesa/main/formats.c | 131 +-- 1 files changed, 93 insertions(+), 38 deletions(-) diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c index f352395..a52b38b 100644 --- a/src/mesa/main/formats.c +++ b/src/mesa/main/formats.c @@ -2545,13 +2545,21 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA: - if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8) + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV swapBytes) return GL_TRUE; if (format == GL_RGBA type == GL_UNSIGNED_BYTE !littleEndian) return GL_TRUE; - if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV) + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8 + swapBytes) return GL_TRUE; if (format == GL_ABGR_EXT type == GL_UNSIGNED_BYTE littleEndian) @@ -2560,10 +2568,35 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA_REV: - return format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV; + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_BYTE littleEndian) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8 + !swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV + swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_BYTE !littleEndian) + return GL_TRUE; + + return GL_FALSE; case MESA_FORMAT_ARGB: - if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV) + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8 swapBytes) return GL_TRUE; if (format == GL_BGRA type == GL_UNSIGNED_BYTE littleEndian) @@ -2572,7 +2605,11 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_ARGB_REV: - if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8) + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) + return GL_TRUE; + + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV + swapBytes) return GL_TRUE; if (format == GL_BGRA type == GL_UNSIGNED_BYTE !littleEndian) @@ -2595,7 +2632,8 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_RGB type == GL_UNSIGNED_BYTE littleEndian; case MESA_FORMAT_RGB565: - return format == GL_RGB type == GL_UNSIGNED_SHORT_5_6_5; + return format == GL_RGB type == GL_UNSIGNED_SHORT_5_6_5 !swapBytes; + case MESA_FORMAT_RGB565_REV: /* Some of the 16-bit MESA_FORMATs that would seem to correspond to * GL_UNSIGNED_SHORT_* are byte-swapped instead of channel-reversed,
Re: [Mesa-dev] [PATCH] automake: src/mesa/drivers/osmesa
On 27/01/2012 05:06, Matt Turner wrote: Please give this a try. OSMesa is broken with shared-glapi. I'll fix that (it'll be much easier) when I automake glapi. +libOSMesa_la_SOURCES = osmesa.c +libOSMesa_la_LDFLAGS = -version-info 8:0:0 #FIXME +libOSMesa_la_LIBADD = $(LIBADD) +endif You should use the libtool flag '-no-undefined' as well here, so libtool will attempt to build a shared library even on architectures which require that all symbols are resolved when the library is linked. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY
On Don, 2012-01-26 at 20:45 +0100, Marek Olšák wrote: On Tue, Jan 10, 2012 at 6:20 PM, Jose Fonseca jfons...@vmware.com wrote: On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca jfons...@vmware.com wrote: Also, please provide app name and performance figures w/ this change. OK. Torcs, the Forza track at the start. With u_upload_unmap before drawing: 21.4 - 22.1 fps Without u_upload_unmap: 22.7 - 23.1 fps The improvement is approximately 1.1 fps, which is probably too little for other people to care, but why throw it away? This is roughly 5%. It is still significant. But it surprises me it is so high. Perhaps we should have a couple of fast entrypoints for transfering to/from buffers without the overhead of creating transfer objects. Okay so the plan is to keep refactoring the transfer API until the overhead disappears? Sounds good. I propose these changes: 1) Merge get_transfer with transfer_map. 2) Merge transfer_unmap with transfer_destroy. AFAIR everybody agreed a while ago this should be done. 3) Make the pipe_transfer struct fully opaque, but then there must be another way to return the strides of mapped textures (out parameters of transfer_map?). Think of this as decoupling driver-private transfer objects from ordinary return values like the strides. 4) The drivers which don't need transfer objects (e.g. non-texture transfers) can return a NULL pipe_transfer struct, making transfer objects fully optional. Only the returned pointer into the resource determines whether transfer_map has been successful. (1) and (2) should help reduce the call overhead. (3) is a preparation for (4). (4) should help kill all the code required to allocate, initialize, and free the pipe_transfer struct when it's needed by neither a driver nor a state tracker. Sounds good to me. Something else that might be useful at some point would be another entrypoint which passes in a pointer to the data to be transferred. This could allow saving a CPU copy in cases where the state tracker already has the data in the form appropriate for the transfer. For drivers that can't take advantage of that, there could be a utility function which uses the get_transfer and transfer_destroy hooks. -- Earthling Michel Dänzer | http://www.amd.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] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45292] Compilation failure on d3d1x state tracker: ‘ID3D10Include’ has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=45292 Alex Deucher ag...@yahoo.com changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Other -- 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 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
On Fri, Jan 27, 2012 at 2:33 AM, Jose Fonseca jfons...@vmware.com wrote: Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: case MESA_FORMAT_RGBA: if (format == GL_RGBA type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8 : GL_UNSIGNED_INT_8_8_8_8_REV)) return GL_TRUE; if (format == GL_ABGR_EXT type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8_REV : GL_UNSIGNED_INT_8_8_8_8)) return GL_TRUE; if (format == (!littleEndian ? GL_RGBA : GL_ABGR_EXT) type == GL_UNSIGNED_BYTE) return GL_TRUE; Honestly, I find my approach easier to read and understand than that. I don't think there's an ideal way to express all the various combinations. I opted for simple (if verbose) logic over more sophisticated logic (which can be error-prone too). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
On Fri, Jan 27, 2012 at 7:40 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
Looks good to me.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Fri, Jan 27, 2012 at 7:40 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
Looks good to me.
Should probably be tagged for the 8.0 branch too.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
- Original Message - On Fri, Jan 27, 2012 at 2:33 AM, Jose Fonseca jfons...@vmware.com wrote: Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: case MESA_FORMAT_RGBA: if (format == GL_RGBA type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8 : GL_UNSIGNED_INT_8_8_8_8_REV)) return GL_TRUE; if (format == GL_ABGR_EXT type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8_REV : GL_UNSIGNED_INT_8_8_8_8)) return GL_TRUE; if (format == (!littleEndian ? GL_RGBA : GL_ABGR_EXT) type == GL_UNSIGNED_BYTE) return GL_TRUE; Honestly, I find my approach easier to read and understand than that. I don't think there's an ideal way to express all the various combinations. I opted for simple (if verbose) logic over more sophisticated logic (which can be error-prone too). Fair enough. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
- Original Message -
On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul brian.e.p...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 7:40 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
Looks good to me.
Thanks.
Should probably be tagged for the 8.0 branch too.
Good point.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] gallivm: Add a new interface for doing TGSI-LLVM conversions
On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca jfons...@vmware.com wrote: Tom, Looks good in principle! But I need to test this myself before I can be comfortable w/ merging it into master. Hi Jose, Have you had a chance to test this out yet? -Tom Just a few quick comments inline. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: src/mesa/drivers/osmesa
On Fri, Jan 27, 2012 at 7:57 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 27/01/2012 05:06, Matt Turner wrote: Please give this a try. OSMesa is broken with shared-glapi. I'll fix that (it'll be much easier) when I automake glapi. +libOSMesa_la_SOURCES = osmesa.c +libOSMesa_la_LDFLAGS = -version-info 8:0:0 #FIXME +libOSMesa_la_LIBADD = $(LIBADD) +endif You should use the libtool flag '-no-undefined' as well here, so libtool will attempt to build a shared library even on architectures which require that all symbols are resolved when the library is linked. Okay, will do. Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler
https://bugs.freedesktop.org/show_bug.cgi?id=44618 --- Comment #10 from Matt Turner matts...@gmail.com 2012-01-27 07:44:46 PST --- (In reply to comment #9) Thanks! Looks like I can do something similar! -- 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] Help required in configuring mesa 3d in non X environment.
2012/1/26 Sanjoy Saha - ERS, HCL Tech sanjoy.s...@hcl.com:
Michel,
As per the below instructions i tried to compile mesa as follows. But i
get a compilation error in make process. Can you please help me out here ?
./configure --enable-gallium-egl --with-egl-platforms=drm
--enable-shared-glapi --with-gallium-drivers=r600 --enable-gles1
Related to conversation in another thread -- did you realize that
without --with-dri-drivers= that you were building the i915, i965,
radeon, r200, nouveau, and swrast DRI drivers (see configure output
below)?
prefix: /usr/local
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: yes (ES1: yes ES2: no)
OpenVG: no
Driver: dri
OSMesa: no
DRI drivers: mach64 r128 r200 r300 r600 radeon tdfx swrast
DRI driver dir: ${libdir}/dri
Use XCB: no
Shared dricore: no
GLU: yes
GLw: yes (Motif: no)
glut: yes
EGL: yes
EGL platforms: drm
EGL drivers: builtin:egl_glx egl_gallium
EGL Gallium STs: $(GL_LIB)
llvm: no
Gallium: yes
Gallium dirs: auxiliary drivers state_trackers
Target dirs: egl-static gbm dri-r600
Winsys dirs: sw sw/xlib sw/dri i915/sw r600/drm
Driver dirs: softpipe failover galahad trace rbug noop identity
i915 i965 r300 svga r600
Trackers dirs: gbm egl dri
Shared libs: yes
Static libs: no
CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DUSE_PPC_ASM -DUSE_VMX_ASM
PYTHON2: python
Run 'make' to build Mesa
root@MPC8641HPCN:~/working/mesa-7.11# make
make[1]: Entering directory `/root/working/mesa-7.11/src'
Making sources for autoconf
make[2]: Entering directory `/root/working/mesa-7.11/src/mapi/shared-glapi'
make[3]: Entering directory `/root/working/mesa-7.11/src/mapi/glapi/gen-es'
make[3]: Nothing to be done for `shared-glapi'.
make[3]: Leaving directory `/root/working/mesa-7.11/src/mapi/glapi/gen-es'
gcc -c -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI
-DMAPI_ABI_HEADER=\shared-glapi/glapi_mapi_tmp.h\ -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC
-DUSE_PPC_ASM -DUSE_VMX_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -fvisibility=hidden
../../../src/mapi/mapi/entry.c -o entry.o
../../../src/mapi/mapi/entry.c: In function 'entry_get_public':
../../../src/mapi/mapi/entry.c:82: error: 'public_entries' undeclared (first
use in this function)
../../../src/mapi/mapi/entry.c:82: error: (Each undeclared identifier is
reported only once
../../../src/mapi/mapi/entry.c:82: error: for each function it appears in.)
make[2]: *** [entry.o] Error 1
make[2]: Leaving directory `/root/working/mesa-7.11/src/mapi/shared-glapi'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/root/working/mesa-7.11/src'
make: *** [default] Error 1
I tried to reproduce with Mesa from git, and could not. If the issue
is indeed fixed since 7.11, we might be able to apply it to the 7.11
branch if you could find the patch that fixes it.
Otherwise, Mesa-8.0 is right around the corner.
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler
https://bugs.freedesktop.org/show_bug.cgi?id=44618 --- Comment #11 from Thierry Reding thierry.red...@avionic-design.de 2012-01-27 07:55:01 PST --- Looks like I can do something similar! I've been seeing your automake related commits and I'm really glad to see someone working on this. Are there plans to actually get this done for 8.0 or will it only go into a later release? -- 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 44618] Cross-compilation broken by glsl builtin_compiler
https://bugs.freedesktop.org/show_bug.cgi?id=44618 --- Comment #12 from Matt Turner matts...@gmail.com 2012-01-27 08:10:00 PST --- (In reply to comment #11) I've been seeing your automake related commits and I'm really glad to see someone working on this. Are there plans to actually get this done for 8.0 or will it only go into a later release? With how easily a change and break a particular configuration, I wouldn't feel comfortable trying to get automake into 8.0. I'd rather have a release of Mesa where everything is working with automake, instead of ~half anyway. Sorry :( -- 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 6/6] gallivm: Add a new interface for doing TGSI-LLVM conversions
- Original Message - On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca jfons...@vmware.com wrote: Tom, Looks good in principle! But I need to test this myself before I can be comfortable w/ merging it into master. Hi Jose, Have you had a chance to test this out yet? Hi Tom, Sorry for dropping the ball. I just tried your branch now, and I'm hitting this segfault: #0 0x746ab3f9 in lp_build_emit_fetch (bld_base=0x7fffb010, inst=0xb36760, src_op=0, chan_index=4294967295) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:312 312assert(reg-Register.Index = bld_base-info-file_max[reg-Register.File]); (gdb) p bld_base-info $4 = (const struct tgsi_shader_info *) 0x0 (gdb) Apart of fixing this, I need to properly understand how aos is being changed. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
On Fri, Jan 27, 2012 at 07:28, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul brian.e.p...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 7:40 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
Looks good to me.
Thanks.
Should probably be tagged for the 8.0 branch too.
Good point.
Jose
You also might want to remove the workaround in free_gallivm_state. My
impression is that it works around that bug.
Stephane
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] gallivm: Add a new interface for doing TGSI-LLVM conversions
On Fri, Jan 27, 2012 at 09:17:54AM -0800, Jose Fonseca wrote: - Original Message - On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca jfons...@vmware.com wrote: Tom, Looks good in principle! But I need to test this myself before I can be comfortable w/ merging it into master. Hi Jose, Have you had a chance to test this out yet? Hi Tom, Sorry for dropping the ball. I just tried your branch now, and I'm hitting this segfault: #0 0x746ab3f9 in lp_build_emit_fetch (bld_base=0x7fffb010, inst=0xb36760, src_op=0, chan_index=4294967295) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:312 312 assert(reg-Register.Index = bld_base-info-file_max[reg-Register.File]); (gdb) p bld_base-info $4 = (const struct tgsi_shader_info *) 0x0 (gdb) Apart of fixing this, I need to properly understand how aos is being changed. Jose Hi Jose, Are you hitting that segfault with lp_build_tgsi_aos()? If so, the attached patch should fix it. Please note though, that the aos code has only been compile tested, since it isn't used anywhere in Mesa. -Tom From dbf0698d6e07bae0ead5365d39097d6c7032fff6 Mon Sep 17 00:00:00 2001 From: Tom Stellard thomas.stell...@amd.com Date: Fri, 27 Jan 2012 12:32:23 -0500 Subject: [PATCH] gallivm: lp_bld_tgsi_aos.c intialize tgsi_info --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c index 26cfffe..e9a433d 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c @@ -1003,6 +1003,7 @@ lp_build_tgsi_aos(struct gallivm_state *gallivm, bld.sampler = sampler; bld.indirect_files = info-indirect_files; bld.bld_base.emit_swizzle = swizzle_aos; + bld.bld_base.info = info; bld.bld_base.emit_fetch_funcs[TGSI_FILE_CONSTANT] = emit_fetch_constant; bld.bld_base.emit_fetch_funcs[TGSI_FILE_IMMEDIATE] = emit_fetch_immediate; -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Don't try intel_miptree_map_blit if a region is already mapped
On 01/27/2012 12:07 AM, Eric Anholt wrote:
On Thu, 26 Jan 2012 18:29:30 -0800, Ian Romanick i...@freedesktop.org
wrote:
From: Ian Romanick ian.d.roman...@intel.com
Eventually this path leads to _intel_batchbuffer_flush. The first
thing there is an assertion that nothing is mapped.
Fixes the afore mentioned assertion failure in piglit's
fbo-mipmap-copypix, and is related to bug #43328.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328
I think the assert is invalid and should be dropped instead.
(basically: the assert is assuming that if *anything* is mapped, the
batch has been flushed, while the reasonable and more common thing to
do, is to flush if your particular buffer was already in use).
I'm ok with removing the assertion as long its intent is satisfied:
/* No batch should be emitted that uses a mapped region, because that would
* cause the map to be incoherent with GPU rendering done by the
* batchbuffer.
Since intel_miptree_{map,unmap}_* are flushing at the right time to avoid that,
I think we are satisfying that condition, and it's safe to remove the assertion.
Chad Versace
chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] gallivm: Add a new interface for doing TGSI-LLVM conversions
- Original Message - On Fri, Jan 27, 2012 at 09:17:54AM -0800, Jose Fonseca wrote: - Original Message - On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca jfons...@vmware.com wrote: Tom, Looks good in principle! But I need to test this myself before I can be comfortable w/ merging it into master. Hi Jose, Have you had a chance to test this out yet? Hi Tom, Sorry for dropping the ball. I just tried your branch now, and I'm hitting this segfault: #0 0x746ab3f9 in lp_build_emit_fetch (bld_base=0x7fffb010, inst=0xb36760, src_op=0, chan_index=4294967295) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:312 312assert(reg-Register.Index = bld_base-info-file_max[reg-Register.File]); (gdb) p bld_base-info $4 = (const struct tgsi_shader_info *) 0x0 (gdb) Apart of fixing this, I need to properly understand how aos is being changed. Jose Hi Jose, Are you hitting that segfault with lp_build_tgsi_aos()? If so, the attached patch should fix it. Yep. That fixed it. Thanks. Please note though, that the aos code has only been compile tested, since it isn't used anywhere in Mesa. I was aware of that, but I still needed to ensure that it was not broken, or could be easily fixed later. But it seems to be producing exact the same LLVM IR as before so I'm happy. So this change is good by me. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] dri: Add a default drirc to be installed to provide application workarounds.
On 01/26/2012 03:58 PM, Marek Olšák wrote: Well, we'll see if they fix the benchmarks too. Anyway, I don't see how this series addresses the issue with gl_InstanceID. Right. I submitted a spec bug for that, and it should get resolved at the face-to-face meeting next week. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
- Original Message -
On Fri, Jan 27, 2012 at 07:28, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul
brian.e.p...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 7:40 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
Looks good to me.
Thanks.
Should probably be tagged for the 8.0 branch too.
Good point.
Jose
You also might want to remove the workaround in free_gallivm_state.
My
impression is that it works around that bug.
All those commented code in free_gallivm_state are workarounds for globals in
LLVM which can never be safely destroyed. These workarounds need to be
revisited for newer LLVM version, but I believe they are independent of the
issue we saw here. The fact that draw module crashed is because the underlying
LLVM structures were properly destroyed.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Ensure that prepare is always run after LLVM garbagge collection.
2012/1/27 Jose Fonseca jfons...@vmware.com:
- Original Message -
On Fri, Jan 27, 2012 at 07:28, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul
brian.e.p...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 7:40 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e71c802..b81c725 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -65,8 +65,13 @@ static void
draw_llvm_garbage_collect_callback(void *cb_data)
{
struct draw_llvm *llvm = (struct draw_llvm *) cb_data;
+ struct draw_context *draw = llvm-draw;
struct draw_llvm_variant_list_item *li;
+ /* Ensure prepare will be run and shaders recompiled */
+ assert(!draw-suspend_flushing);
+ draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
+
/* free all shader variants */
li = first_elem(llvm-vs_variants_list);
while (!at_end(llvm-vs_variants_list, li)) {
Looks good to me.
Thanks.
Should probably be tagged for the 8.0 branch too.
Good point.
Jose
You also might want to remove the workaround in free_gallivm_state.
My
impression is that it works around that bug.
All those commented code in free_gallivm_state are workarounds for globals in
LLVM which can never be safely destroyed. These workarounds need to be
revisited for newer LLVM version, but I believe they are independent of the
issue we saw here. The fact that draw module crashed is because the
underlying LLVM structures were properly destroyed.
Ok, it sounded to me like it might have worked around that bug,
because free_gallivm_state was the first one reusing the variant's
memory after it got freed in the garbage collection. But if you say
it's a coincidence then let's push the fix :)
Stéphane
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
On 01/27/2012 01:33 AM, Jose Fonseca wrote: Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: At the top of the function, why not just do: if (swapBytes type == GL_UNSIGNED_INT_8_8_8_8) type = GL_UNSIGNED_INT_8_8_8_8_REV; else if (swapBytes type == GL_UNSIGNED_INT_8_8_8_8_REV) type = GL_UNSIGNED_INT_8_8_8_8; Or something similar to remap type based on swapBytes. That would incur a lot less copy-and-paste. case MESA_FORMAT_RGBA: if (format == GL_RGBA type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8 : GL_UNSIGNED_INT_8_8_8_8_REV)) return GL_TRUE; if (format == GL_ABGR_EXT type == (!swapBytes ? GL_UNSIGNED_INT_8_8_8_8_REV : GL_UNSIGNED_INT_8_8_8_8)) return GL_TRUE; if (format == (!littleEndian ? GL_RGBA : GL_ABGR_EXT) type == GL_UNSIGNED_BYTE) return GL_TRUE; Jose - Original Message - This will let us use memcpy in more situations. We can also remove the checks for byte spapping that happen before the calls to _mesa_format_matches_format_and_type(). --- src/mesa/main/formats.c | 131 +-- 1 files changed, 93 insertions(+), 38 deletions(-) diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c index f352395..a52b38b 100644 --- a/src/mesa/main/formats.c +++ b/src/mesa/main/formats.c @@ -2545,13 +2545,21 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA: - if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8) + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV swapBytes) return GL_TRUE; if (format == GL_RGBA type == GL_UNSIGNED_BYTE !littleEndian) return GL_TRUE; - if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV) + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8 + swapBytes) return GL_TRUE; if (format == GL_ABGR_EXT type == GL_UNSIGNED_BYTE littleEndian) @@ -2560,10 +2568,35 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA_REV: - return format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV; + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 swapBytes) + return GL_TRUE; + + if (format == GL_RGBA type == GL_UNSIGNED_BYTE littleEndian) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8 + !swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_INT_8_8_8_8_REV + swapBytes) + return GL_TRUE; + + if (format == GL_ABGR_EXT type == GL_UNSIGNED_BYTE !littleEndian) + return GL_TRUE; + + return GL_FALSE; case MESA_FORMAT_ARGB: - if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV) + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV + !swapBytes) + return GL_TRUE; + + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8 swapBytes) return GL_TRUE; if (format == GL_BGRA type == GL_UNSIGNED_BYTE littleEndian) @@ -2572,7 +2605,11 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_ARGB_REV: - if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8) + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) + return GL_TRUE; + + if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV + swapBytes) return GL_TRUE; if (format == GL_BGRA type == GL_UNSIGNED_BYTE !littleEndian) @@ -2595,7 +2632,8 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_RGB type == GL_UNSIGNED_BYTE littleEndian; case MESA_FORMAT_RGB565: - return format == GL_RGB type == GL_UNSIGNED_SHORT_5_6_5; + return format == GL_RGB type == GL_UNSIGNED_SHORT_5_6_5 !swapBytes; + case MESA_FORMAT_RGB565_REV: /* Some of the 16-bit MESA_FORMATs that would seem to correspond to * GL_UNSIGNED_SHORT_* are byte-swapped instead of channel-reversed, @@ -2604,15 +2642,20 @@
Re: [Mesa-dev] [PATCH 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
- Original Message - On 01/27/2012 01:33 AM, Jose Fonseca wrote: Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: At the top of the function, why not just do: if (swapBytes type == GL_UNSIGNED_INT_8_8_8_8) type = GL_UNSIGNED_INT_8_8_8_8_REV; else if (swapBytes type == GL_UNSIGNED_INT_8_8_8_8_REV) type = GL_UNSIGNED_INT_8_8_8_8; I tought that too. But one would need to toggle swapBytes too, to avoid considering swapBytes twice (e.g., in BGRA vs RGBA), and then you'd also need to make sure that all paths can handle the toggled swapBytes... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix maximum supported texture size returned by glGetIntegrv
On 01/27/2012 12:57 AM, Jose Fonseca wrote: This doesn't make sense from a mathematical POV. If the allowable size is 2^floor(log2(MAX_XX_TEXTURE_SIZE)) + 2*bt then it doesn't matter whether MAX_XX_TEXTURE_SIZE has or not the border with, as the allowable size is still the same for all common values of MAX_XX_TEXTURE_SIZE. It would be very odd to define MAX_XX_TEXTURE_SIZE in terms of itself, as there would be a singularity for MAX_XX_TEXTURE_SIZE 4 : no value of MAX_XX_TEXTURE_SIZE under four will satisfy the equation: MAX_XX_TEXTURE_SIZE = 2^floor(log2(MAX_XX_TEXTURE_SIZE)) + 2 If hypothetically one day the spec allowed higher maximum border sizes, it would be even worse. Which it won't: borders are removed in OpenGL ES and in OpenGL 3.1+ Core profile. My take is that the border does not need to be implicitly added to MAX_XX_TEXTURE_SIZE query, and the test/driver is wrong. Also it doesn't match what NVIDIA produces: Thanks for checking this. I was going to check it, but I kept getting distracted. I think the proxy check needs to change. If the maximum texture size is 2048, then a texture with border should be limited to 2046+2. That is, when doing the size check, add the border size in first. I just tried the test on AMD and NVIDIA, and this appears to be what they both do. My recollection is also that the test just produces a warning in this case. $ glxinfo -l | grep SIZE GL_MAX_TEXTURE_SIZE = 16384 GL_MAX_3D_TEXTURE_SIZE = 2048 GL_ALIASED_POINT_SIZE_RANGE = 1, 63 GL_SMOOTH_POINT_SIZE_RANGE = 1, 63 GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 16384 GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 16384 Jose - Original Message - As per OpenGL 3.0 specification section 3.9, page 187 in pdf the maximum allowable width, height, or depth of a texel array must be at least 2^(k−lod) + 2*bt for image arrays of level-of-detail (lod) 0 through k, where k is the log base 2 of MAX_3D_TEXTURE_SIZE, and bt is the maximum border width Currently different values for maximum allowable texture size are returned by glGetIntegrv() and proxy textures. glGetIntegrv returns 2048 and proxy texture returns (2048 + 2) This patch fixes Intel oglconform test case: max_values Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970 Note: This is a candidate for mesa 8.0 branch. Signed-off-by: Anuj Phogatanuj.pho...@gmail.com --- src/mesa/main/get.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index 5ad6012..4a70109 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -1507,7 +1507,8 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu case GL_MAX_3D_TEXTURE_SIZE: case GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB: p = (GLuint *) ((char *) ctx + d-offset); - v-value_int = 1 (*p - 1); + /* GL 3.0: Add 2 pixels to accmodate border */ + v-value_int = 1 (*p - 1) + 2; break; case GL_SCISSOR_BOX: -- 1.7.7.4 ___ 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 6/6] gallivm: Add a new interface for doing TGSI-LLVM conversions
On Fri, Jan 27, 2012 at 10:13:54AM -0800, Jose Fonseca wrote: - Original Message - On Fri, Jan 27, 2012 at 09:17:54AM -0800, Jose Fonseca wrote: - Original Message - On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca jfons...@vmware.com wrote: Tom, Looks good in principle! But I need to test this myself before I can be comfortable w/ merging it into master. Hi Jose, Have you had a chance to test this out yet? Hi Tom, Sorry for dropping the ball. I just tried your branch now, and I'm hitting this segfault: #0 0x746ab3f9 in lp_build_emit_fetch (bld_base=0x7fffb010, inst=0xb36760, src_op=0, chan_index=4294967295) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:312 312 assert(reg-Register.Index = bld_base-info-file_max[reg-Register.File]); (gdb) p bld_base-info $4 = (const struct tgsi_shader_info *) 0x0 (gdb) Apart of fixing this, I need to properly understand how aos is being changed. Jose Hi Jose, Are you hitting that segfault with lp_build_tgsi_aos()? If so, the attached patch should fix it. Yep. That fixed it. Thanks. Please note though, that the aos code has only been compile tested, since it isn't used anywhere in Mesa. I was aware of that, but I still needed to ensure that it was not broken, or could be easily fixed later. But it seems to be producing exact the same LLVM IR as before so I'm happy. So this change is good by me. Great, I'll try to push these on Monday as long as no one else objects. -Tom Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()
On 01/27/2012 10:36 AM, Jose Fonseca wrote: - Original Message - On 01/27/2012 01:33 AM, Jose Fonseca wrote: Brian, This is probably right but a tad verbose, and error prone. I'm not sure what's the best way to simplify this though. It's not possible to canonize the comparisons because there are missing combinations. But I think that at least using ternary operators would make the code more compact and help ensuring thar cases don't follow through the cracks. For example: At the top of the function, why not just do: if (swapBytes type == GL_UNSIGNED_INT_8_8_8_8) type = GL_UNSIGNED_INT_8_8_8_8_REV; else if (swapBytes type == GL_UNSIGNED_INT_8_8_8_8_REV) type = GL_UNSIGNED_INT_8_8_8_8; I tought that too. But one would need to toggle swapBytes too, to avoid considering swapBytes twice (e.g., in BGRA vs RGBA), and then you'd also need to make sure that all paths can handle the toggled swapBytes... Right. Brian's patch probably is better, then. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/14] mesa: remove LSB-first pixel packing check in glReadPixels
For the series,
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 01/26/2012 07:04 PM, Brian Paul wrote:
GL_UNPACK_LSB_FIRST only applies to bitmap data, not glReadPixels.
---
src/mesa/main/readpix.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index c1489d2..84b5224 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -213,8 +213,7 @@ fast_read_rgba_pixels_memcpy( struct gl_context *ctx,
return GL_FALSE;
/* check for things we can't handle here */
- if (packing-SwapBytes ||
- packing-LsbFirst) {
+ if (packing-SwapBytes) {
return GL_FALSE;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Fix fixed-function fragment processing
On 01/26/2012 12:46 PM, Chad Versace wrote:
On i965, _mesa_ir_link_shader is never called. As a consequence, the
current fragment program (ctx-FragmentProgram-_Current) exists but does
not differ from the fixed function fragment program
(ctx-FragmentProgram-_TexEnvProgram). This confuses swrast.
To fix the confusion, this patch replaces checks of the form
if (ctx-FragmentProgram-_Current == NULL)
with
if (_swrast_use_fragment_program(ctx))
when appropriate.
Fixes the following oglconform regressions on i965/gen6:
api-fogcoord(basic.allCases.log)
api-mtexcoord(basic.allCases.log)
api-seccolor(basic.allCases.log)
api-texcoord(basic.allCases.log)
blend-separate(basic.allCases)
colorsum(basic.allCases.log)
The tests were ran with the GLXFBConfig:
visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat
0x021 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
(Note: I originally believed that the hunk in
_swrast_update_fragment_program was unnecessary. But it is required to fix
blend-separate.)
Note: This is a candidate for the 8.0 branch.
CC: Ian Romanicki...@freedesktop.org
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
CC: Eric Anholte...@anholt.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327
Signed-off-by: Chad Versacechad.vers...@linux.intel.com
---
Eric, I'm trusting your judgement here, since these parts of swrast are new to
me. I've replaced _swrast_fragment_program_is_empty with
_swrast_use_fragment_program.
src/mesa/swrast/s_aaline.c |2 +-
src/mesa/swrast/s_aalinetemp.h |2 +-
src/mesa/swrast/s_aatriangle.c |2 +-
src/mesa/swrast/s_context.c| 25 ++---
src/mesa/swrast/s_fragprog.c | 12
src/mesa/swrast/s_fragprog.h |2 ++
src/mesa/swrast/s_lines.c |2 +-
src/mesa/swrast/s_span.c | 38 +++---
src/mesa/swrast/s_triangle.c |4 ++--
9 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/src/mesa/swrast/s_aaline.c b/src/mesa/swrast/s_aaline.c
index d4b1805..d36d876 100644
--- a/src/mesa/swrast/s_aaline.c
+++ b/src/mesa/swrast/s_aaline.c
@@ -479,7 +479,7 @@ _swrast_choose_aa_line_function(struct gl_context *ctx)
ASSERT(ctx-Line.SmoothFlag);
if (ctx-Texture._EnabledCoordUnits != 0
- || ctx-FragmentProgram._Current
+ || _swrast_use_fragment_program(ctx)
|| (ctx-Light.Enabled
ctx-Light.Model.ColorControl == GL_SEPARATE_SPECULAR_COLOR)
|| ctx-Fog.ColorSumEnabled
diff --git a/src/mesa/swrast/s_aalinetemp.h b/src/mesa/swrast/s_aalinetemp.h
index 376ef32..ba9f8ab 100644
--- a/src/mesa/swrast/s_aalinetemp.h
+++ b/src/mesa/swrast/s_aalinetemp.h
@@ -67,7 +67,7 @@ NAME(plot)(struct gl_context *ctx, struct LineInfo *line, int
ix, int iy)
ATTRIB_LOOP_BEGIN
GLfloat (*attribArray)[4] = line-span.array-attribs[attr];
if (attr= FRAG_ATTRIB_TEX0 attr FRAG_ATTRIB_VAR0
- !ctx-FragmentProgram._Current) {
+ !_swrast_use_fragment_program(ctx)) {
/* texcoord w/ divide by Q */
const GLuint unit = attr - FRAG_ATTRIB_TEX0;
const GLfloat invQ = solve_plane_recip(fx, fy,
line-attrPlane[attr][3]);
diff --git a/src/mesa/swrast/s_aatriangle.c b/src/mesa/swrast/s_aatriangle.c
index c68fdf6..b59177f 100644
--- a/src/mesa/swrast/s_aatriangle.c
+++ b/src/mesa/swrast/s_aatriangle.c
@@ -299,7 +299,7 @@ _swrast_set_aa_triangle_function(struct gl_context *ctx)
ASSERT(ctx-Polygon.SmoothFlag);
if (ctx-Texture._EnabledCoordUnits != 0
- || ctx-FragmentProgram._Current
+ || _swrast_use_fragment_program(ctx)
|| swrast-_FogEnabled
|| _mesa_need_secondary_color(ctx)) {
SWRAST_CONTEXT(ctx)-Triangle = general_aa_tri;
diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
index 14cb9b1..cc304d7 100644
--- a/src/mesa/swrast/s_context.c
+++ b/src/mesa/swrast/s_context.c
@@ -105,7 +105,7 @@ _swrast_update_rasterflags( struct gl_context *ctx )
}
- if (ctx-FragmentProgram._Current) {
+ if (_swrast_use_fragment_program(ctx)) {
rasterMask |= FRAGPROG_BIT;
}
@@ -170,7 +170,7 @@ _swrast_update_fog_hint( struct gl_context *ctx )
{
SWcontext *swrast = SWRAST_CONTEXT(ctx);
swrast-_PreferPixelFog = (!swrast-AllowVertexFog ||
- ctx-FragmentProgram._Current ||
+ _swrast_use_fragment_program(ctx) ||
(ctx-Hint.Fog == GL_NICEST
swrast-AllowPixelFog));
}
@@ -220,13 +220,14 @@ _swrast_update_deferred_texture(struct gl_context *ctx)
swrast-_DeferredTexture = GL_FALSE;
}
else {
+ GLboolean use_fprog =
Re: [Mesa-dev] [PATCH] intel: Fix accum buffer mapping since the swrast rework.
On Tue, 24 Jan 2012 17:55:49 -0800, Ian Romanick i...@freedesktop.org wrote:
On 01/24/2012 03:59 PM, Eric Anholt wrote:
A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
in the clear-accum test. Just look at the swrast renderbuffer pointer
for handling swrast rbs.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 3a35a01..27b0bfc 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -128,15 +128,16 @@ intel_map_renderbuffer(struct gl_context *ctx,
GLint *out_stride)
{
struct intel_context *intel = intel_context(ctx);
+ struct swrast_renderbuffer *srb = (struct swrast_renderbuffer *)rb;
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
void *map;
int stride;
- if (!irb irb-Base.Buffer) {
- /* this is a malloc'd renderbuffer (accum buffer) */
+ if (srb-Buffer) {
+ /* this is a malloc'd renderbuffer (accum buffer), not an irb */
GLint bpp = _mesa_get_format_bytes(rb-Format);
- GLint rowStride = irb-Base.RowStride;
- *out_map = (GLubyte *) irb-Base.Buffer + y * rowStride + x * bpp;
+ GLint rowStride = srb-RowStride;
+ *out_map = (GLubyte *) srb-Buffer + y * rowStride + x * bpp;
Would it be better to use _swrast_pixel_address here?
Looks like no, because that uses srb-Map, which is not srb-Buffer and
gets set to a MapRenderbuffer returned pointer.
pgpwuaHam3fmy.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] mesa: fix maximum supported texture size returned by glGetIntegrv
On Fri, Jan 27, 2012 at 10:42 AM, Ian Romanick i...@freedesktop.org wrote: On 01/27/2012 12:57 AM, Jose Fonseca wrote: This doesn't make sense from a mathematical POV. If the allowable size is 2^floor(log2(MAX_XX_TEXTURE_**SIZE)) + 2*bt then it doesn't matter whether MAX_XX_TEXTURE_SIZE has or not the border with, as the allowable size is still the same for all common values of MAX_XX_TEXTURE_SIZE. It would be very odd to define MAX_XX_TEXTURE_SIZE in terms of itself, as there would be a singularity for MAX_XX_TEXTURE_SIZE 4 : no value of MAX_XX_TEXTURE_SIZE under four will satisfy the equation: MAX_XX_TEXTURE_SIZE = 2^floor(log2(MAX_XX_TEXTURE_**SIZE)) + 2 yes, this equation looks confusing. If hypothetically one day the spec allowed higher maximum border sizes, it would be even worse. Which it won't: borders are removed in OpenGL ES and in OpenGL 3.1+ Core profile. My take is that the border does not need to be implicitly added to MAX_XX_TEXTURE_SIZE query, and the test/driver is wrong. Also it doesn't match what NVIDIA produces: Thanks for checking this. I was going to check it, but I kept getting distracted. I think the proxy check needs to change. If the maximum texture size is 2048, then a texture with border should be limited to 2046+2. That is, when doing the size check, add the border size in first. I just tried the test on AMD and NVIDIA, and this appears to be what they both do. I initially made the changes in proxy check to fix the test failure. But changed my mind after looking at the GL 3.0 specification. Thanks for verifying on Nvidia and AMD. I'll post a new patch with suggested changes. My recollection is also that the test just produces a warning in this case. Yes, test produces a warning for mismatch of returned values by glGetIntegerv() and proxy texture. Currently texture_error_check() in glTexImage2D() doesn't complain if the texture width/height = 2050. This later causes an OUT_OF_MEMORY error and assertion failure when using texture with width/height 2048. $ glxinfo -l | grep SIZE GL_MAX_TEXTURE_SIZE = 16384 GL_MAX_3D_TEXTURE_SIZE = 2048 GL_ALIASED_POINT_SIZE_RANGE = 1, 63 GL_SMOOTH_POINT_SIZE_RANGE = 1, 63 GL_MAX_CUBE_MAP_TEXTURE_SIZE_**ARB = 16384 GL_MAX_RECTANGLE_TEXTURE_SIZE_**NV = 16384 Jose - Original Message - As per OpenGL 3.0 specification section 3.9, page 187 in pdf the maximum allowable width, height, or depth of a texel array must be at least 2^(k-lod) + 2*bt for image arrays of level-of-detail (lod) 0 through k, where k is the log base 2 of MAX_3D_TEXTURE_SIZE, and bt is the maximum border width Currently different values for maximum allowable texture size are returned by glGetIntegrv() and proxy textures. glGetIntegrv returns 2048 and proxy texture returns (2048 + 2) This patch fixes Intel oglconform test case: max_values Bugzilla: https://bugs.freedesktop.org/**show_bug.cgi?id=44970https://bugs.freedesktop.org/show_bug.cgi?id=44970 Note: This is a candidate for mesa 8.0 branch. Signed-off-by: Anuj Phogatanuj.pho...@gmail.com --- src/mesa/main/get.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index 5ad6012..4a70109 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -1507,7 +1507,8 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu case GL_MAX_3D_TEXTURE_SIZE: case GL_MAX_CUBE_MAP_TEXTURE_SIZE_**ARB: p = (GLuint *) ((char *) ctx + d-offset); - v-value_int = 1 (*p - 1); + /* GL 3.0: Add 2 pixels to accmodate border */ + v-value_int = 1 (*p - 1) + 2; break; case GL_SCISSOR_BOX: -- 1.7.7.4 __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] autoconf: Enable missing-prototypes errors when available.
After the removal of the dri driver link test, this should help avoid the original problem that it was designed to catch: The warning about a missing prototype due to typoing a function name scrolling by in the Mesa build spew, and you not noticing until you try to run an application and it falls back to swrast. --- configure.ac | 15 ++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 06d400f..0cd8421 100644 --- a/configure.ac +++ b/configure.ac @@ -176,7 +176,20 @@ esac dnl Add flags for gcc and g++ if test x$GCC = xyes; then -CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 +CFLAGS=$CFLAGS -Wall -std=c99 + +# Enable -Werror=implicit-function-declaration and +# -Werror=missing-prototypes, if available, or otherwise, just +# -Wmissing-prototypes. This is particularly useful to avoid +# generating a loadable driver module that has undefined symbols. +save_CFLAGS=$CFLAGS +AC_MSG_CHECKING([whether $CC supports -Werror=missing-prototypes]) +CFLAGS=$CFLAGS -Werror=implicit-function-declaration +CFLAGS=$CFLAGS -Werror=missing-prototypes +AC_LINK_IFELSE([AC_LANG_PROGRAM()], + AC_MSG_RESULT([yes]), + [CFLAGS=$save_CFLAGS -Wmissing-prototypes; + AC_MSG_RESULT([no])]); # Enable -fvisibility=hidden if using a gcc that supports it save_CFLAGS=$CFLAGS -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): dri: make sure to build libdricommon.la
On 27/01/2012 08:03, Eric Anholt wrote: On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org (Matt Turner) wrote: Module: Mesa Branch: master Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=80aa78142d12b21dd7d4f0edc786af98a159a80f Author: Matt Turner matts...@gmail.com Date: Thu Jan 26 19:31:12 2012 -0500 dri: make sure to build libdricommon.la Ouch. Sorry about this, folks, I built with a dirty tree and didn't notice that the rebase off of the drirc changes wasn't good enough. This commit breaks the ability to build when ./configured -with-driver=dri --disable-driglx-direct --with-dri-drivers=swrast for platforms which don't have DRM (See [1]), as it tries to build libdricommon.la even if we aren't building a dri driver which requires it. Attached is a patch which fixes this, although I'm not sure if that's the best way of solving this problem (it might make more sense to conditionalize on DRI_DIRS containing something other than swrast if all dri drivers are going to use libdricommon) [1] http://tinderbox.freedesktop.org/builds/2012-01-27-0017/logs/libGL-indirect-only/#build From c527ad8a315ffb34bfcb34053d41f39aa8011b7c Mon Sep 17 00:00:00 2001 From: Jon TURNEY jon.tur...@dronecode.org.uk Date: Fri, 27 Jan 2012 19:06:28 + Subject: [PATCH] dri: Don't build libdricommon.la if we don't need it Refine 80aa78142d12b21dd7d4f0edc786af98a159a80f dri: make sure to build libdricommon.la so we don't build libdricommon if we aren't building a dri driver which needs it (i.e. if we are just building swrast) Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- configure.ac |1 + src/mesa/drivers/dri/Makefile.am |6 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 06d400f..e173bcf 100644 --- a/configure.ac +++ b/configure.ac @@ -1289,6 +1289,7 @@ AM_CONDITIONAL(HAVE_NOUVEAU_DRI, test x$HAVE_NOUVEAU_DRI = xyes) AM_CONDITIONAL(HAVE_R200_DRI, test x$HAVE_R200_DRI = xyes) AM_CONDITIONAL(HAVE_RADEON_DRI, test x$HAVE_RADEON_DRI = xyes) AM_CONDITIONAL(HAVE_SWRAST_DRI, test x$HAVE_SWRAST_DRI = xyes) +AM_CONDITIONAL(HAVE_COMMON_DRI, test x$HAVE_I915_DRI = xyes || test x$HAVE_I965_DRI = xyes || test x$HAVE_NOUVEAU_DRI = xyes || test x$HAVE_R200_DRI = xyes || test x$HAVE_RADEON_DRI = xyes) dnl dnl OSMesa configuration diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/Makefile.am index 8b93582..48d3685 100644 --- a/src/mesa/drivers/dri/Makefile.am +++ b/src/mesa/drivers/dri/Makefile.am @@ -1,4 +1,8 @@ -SUBDIRS = common +SUBDIRS = + +if HAVE_COMMON_DRI +SUBDIRS+=common +endif if HAVE_I915_DRI SUBDIRS+=i915 -- 1.7.5.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): dri: make sure to build libdricommon.la
On Fri, Jan 27, 2012 at 8:11 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 27/01/2012 08:03, Eric Anholt wrote: On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org (Matt Turner) wrote: Module: Mesa Branch: master Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=80aa78142d12b21dd7d4f0edc786af98a159a80f Author: Matt Turner matts...@gmail.com Date: Thu Jan 26 19:31:12 2012 -0500 dri: make sure to build libdricommon.la Ouch. Sorry about this, folks, I built with a dirty tree and didn't notice that the rebase off of the drirc changes wasn't good enough. This commit breaks the ability to build when ./configured -with-driver=dri --disable-driglx-direct --with-dri-drivers=swrast for platforms which don't have DRM (See [1]), as it tries to build libdricommon.la even if we aren't building a dri driver which requires it. Attached is a patch which fixes this, although I'm not sure if that's the best way of solving this problem (it might make more sense to conditionalize on DRI_DIRS containing something other than swrast if all dri drivers are going to use libdricommon) [1] http://tinderbox.freedesktop.org/builds/2012-01-27-0017/logs/libGL-indirect-only/#build Please change test ... || test ... || ... into test ... -o ... -o ..., ie AM_CONDITIONAL(HAVE_COMMON_DRI, test x$HAVE_I915_DRI = xyes || test x$HAVE_I965_DRI = xyes || test x$HAVE_NOUVEAU_DRI = xyes || test x$HAVE_R200_DRI = xyes || test x$HAVE_RADEON_DRI = xyes) becomes AM_CONDITIONAL(HAVE_COMMON_DRI, test x$HAVE_I915_DRI = xyes -o x$HAVE_I965_DRI = xyes -o x$HAVE_NOUVEAU_DRI = xyes -o x$HAVE_R200_DRI = xyes -o x$HAVE_RADEON_DRI = xyes) and it looks like swrast is still broken anyway. It should have ../common/utils.c ../common/drisw_util.c in its sources. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering
So you want to get OSMesa from Mesa-7.11.2 working with VTK-5.8.0 on Fedora 15? You can do without the VTKData lines. They don't add as many tests as I thought. # Go somewhere to play around cd /tmp # get Mesa wget ftp://ftp.freedesktop.org/pub/mesa/7.11.2/MesaLib-7.11.2.tar.bz2 # get VTK and test data wget http://www.vtk.org/files/release/5.8/vtk-5.8.0.tar.gz wget http://www.vtk.org/files/release/5.8/vtkdata-5.8.0.tar.gz # untar Mesa tar -xjvf MesaLib-7.11.2.tar.bz2 # Configure and build mesa cd Mesa-7.11.2/ ./configure \ --with-driver=osmesa \ --with-gallium-drivers= \ --disable-egl make -j4 cd .. # Untar VTK and VTKData tar -xzvf vtk-5.8.0.tar.gz tar -xzvf vtkdata-5.8.0.tar.gz # Configure and build VTK mkdir VTK_Build cd VTK_Build/ cmake \ -DVTK_DATA_ROOT:PATH=/tmp/VTKData \ -DOPENGL_INCLUDE_DIR:PATH=/tmp/Mesa-7.11.2/include \ -DOPENGL_gl_LIBRARY:FILEPATH= \ -DOPENGL_glu_LIBRARY:FILEPATH=/tmp/Mesa-7.11.2/lib/libGLU.so \ -DVTK_OPENGL_HAS_OSMESA:BOOL=ON \ -DOSMESA_INCLUDE_DIR:PATH=/tmp/Mesa-7.11.2/include \ -DOSMESA_LIBRARY:FILEPATH=/tmp/Mesa-7.11.2/lib/libOSMesa.so \ -DVTK_USE_OFFSCREEN:BOOL=ON \ -DVTK_USE_X:BOOL=OFF \ /tmp/VTK make -j4 make test When I run this I get only three test failures out of 463. The following tests FAILED: 146 - TestTecplotReader (Failed) 203 - TestMultiTexturing (SEGFAULT) 204 - TestMultiTexturingTransform (SEGFAULT) signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autoconf: Enable missing-prototypes errors when available.
On 01/27/2012 11:58 AM, Eric Anholt wrote: After the removal of the dri driver link test, this should help avoid the original problem that it was designed to catch: The warning about a missing prototype due to typoing a function name scrolling by in the Mesa build spew, and you not noticing until you try to run an application and it falls back to swrast. --- configure.ac | 15 ++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 06d400f..0cd8421 100644 --- a/configure.ac +++ b/configure.ac @@ -176,7 +176,20 @@ esac dnl Add flags for gcc and g++ if test x$GCC = xyes; then -CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 +CFLAGS=$CFLAGS -Wall -std=c99 + +# Enable -Werror=implicit-function-declaration and +# -Werror=missing-prototypes, if available, or otherwise, just +# -Wmissing-prototypes. This is particularly useful to avoid +# generating a loadable driver module that has undefined symbols. +save_CFLAGS=$CFLAGS +AC_MSG_CHECKING([whether $CC supports -Werror=missing-prototypes]) +CFLAGS=$CFLAGS -Werror=implicit-function-declaration +CFLAGS=$CFLAGS -Werror=missing-prototypes +AC_LINK_IFELSE([AC_LANG_PROGRAM()], + AC_MSG_RESULT([yes]), + [CFLAGS=$save_CFLAGS -Wmissing-prototypes; + AC_MSG_RESULT([no])]); # Enable -fvisibility=hidden if using a gcc that supports it save_CFLAGS=$CFLAGS Looks OK to me. I've wondered whether we want to import the macro for checking these things from xorg-util-macros, since we'll probably want to do this for a few other ones too. Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autoconf: Enable missing-prototypes errors when available.
Looks OK to me. I've wondered whether we want to import the macro for checking these things from xorg-util-macros, since we'll probably want to do this for a few other ones too. I think that might be good eventually, but there's so much stuff in configure.ac to be cleaned, I think it should probably wait until after the transition to automake is finished. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autoconf: Enable missing-prototypes errors when available.
On 01/27/2012 12:53 PM, Matt Turner wrote: Looks OK to me. I've wondered whether we want to import the macro for checking these things from xorg-util-macros, since we'll probably want to do this for a few other ones too. I think that might be good eventually, but there's so much stuff in configure.ac to be cleaned, I think it should probably wait until after the transition to automake is finished. Fine by me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] dri: Add a default drirc to be installed to provide application workarounds.
On 01/27/2012 12:52 PM, Eric Anholt wrote: On Fri, 27 Jan 2012 00:58:45 +0100, Marek Olšákmar...@gmail.com wrote: On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanicki...@freedesktop.org wrote: It also appears the Unigen may be resolving some of these issues. That may make the work-arounds irrelevant. http://phoronix.com/forums/showthread.php?68411-Unigine-OilRush-Officially-Ships-Today-For-Linuxp=248294#post248294 Well, we'll see if they fix the benchmarks too. Anyway, I don't see how this series addresses the issue with gl_InstanceID. It would address it if EXT_gpu_shader4 was present, or you could come up with a similar driconf option if you want it before then. So far, I don't see any explicit reviews, acks, or nacks of this series. Are we agreed that this is the way to go? I also need the workaround for Tropics, but I'm fine with that being in a separate patch. Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] dri: Add a default drirc to be installed to provide application workarounds.
On Fri, Jan 27, 2012 at 9:52 PM, Eric Anholt e...@anholt.net wrote: On Fri, 27 Jan 2012 00:58:45 +0100, Marek Olšák mar...@gmail.com wrote: On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanick i...@freedesktop.org wrote: It also appears the Unigen may be resolving some of these issues. That may make the work-arounds irrelevant. http://phoronix.com/forums/showthread.php?68411-Unigine-OilRush-Officially-Ships-Today-For-Linuxp=248294#post248294 Well, we'll see if they fix the benchmarks too. Anyway, I don't see how this series addresses the issue with gl_InstanceID. It would address it if EXT_gpu_shader4 was present, or you could come up with a similar driconf option if you want it before then. So far, I don't see any explicit reviews, acks, or nacks of this series. Are we agreed that this is the way to go? The idea of using drirc for application workarounds is okay with me FWIW. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/fs: Fix rendering corruption in unigine tropics.
We were allocating registers into the MRF hack region, resulting in
sparkly renering in a few of the scenes. We could do better
allocation by making an MRF class, having MRFs conflict with the
corresponding GRFs, and tracking the live intervals of the MRFs and
setting up the conflicts. But this is way easier for the moment.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
src/mesa/drivers/dri/i965/brw_fs.h|2 ++
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |6 +++---
src/mesa/drivers/dri/i965/brw_structs.h | 11 +++
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 9929739..3347157 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -95,7 +95,7 @@ gen7_convert_mrf_to_grf(struct brw_compile *p, struct brw_reg
*reg)
struct intel_context *intel = p-brw-intel;
if (intel-gen == 7 reg-file == BRW_MESSAGE_REGISTER_FILE) {
reg-file = BRW_GENERAL_REGISTER_FILE;
- reg-nr += 112;
+ reg-nr += GEN7_MRF_HACK_START;
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index d623316..5fdc055 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -379,6 +379,7 @@ public:
this-frag_depth = NULL;
memset(this-outputs, 0, sizeof(this-outputs));
this-first_non_payload_grf = 0;
+ this-max_grf = intel-gen = 7 ? GEN7_MRF_HACK_START : BRW_MAX_GRF;
this-current_annotation = NULL;
this-base_ir = NULL;
@@ -583,6 +584,7 @@ public:
ir_variable *frag_depth;
fs_reg outputs[BRW_MAX_DRAW_BUFFERS];
int first_non_payload_grf;
+ int max_grf;
int urb_setup[FRAG_ATTRIB_MAX];
bool kill_emitted;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index d4dd124..0d1712e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -63,9 +63,9 @@ fs_visitor::assign_regs_trivial()
assign_reg(hw_reg_mapping, inst-src[1], reg_width);
}
- if (this-grf_used = BRW_MAX_GRF) {
+ if (this-grf_used = max_grf) {
fail(Ran out of regs on trivial allocator (%d/%d)\n,
- this-grf_used, BRW_MAX_GRF);
+ this-grf_used, max_grf);
}
}
@@ -156,7 +156,7 @@ fs_visitor::assign_regs()
int reg_width = c-dispatch_width / 8;
int hw_reg_mapping[this-virtual_grf_next];
int first_assigned_grf = ALIGN(this-first_non_payload_grf, reg_width);
- int base_reg_count = (BRW_MAX_GRF - first_assigned_grf) / reg_width;
+ int base_reg_count = (max_grf - first_assigned_grf) / reg_width;
int class_sizes[base_reg_count];
int class_count = 0;
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_structs.h
index aef5695..d23ad0d 100644
--- a/src/mesa/drivers/dri/i965/brw_structs.h
+++ b/src/mesa/drivers/dri/i965/brw_structs.h
@@ -37,6 +37,17 @@
/** Number of general purpose registers (VS, WM, etc) */
#define BRW_MAX_GRF 128
+/**
+ * First GRF used for the MRF hack.
+ *
+ * On gen7, MRFs are no longer used, and contiguous GRFs are used instead. We
+ * haven't converted our compiler to be aware of this, so it asks for MRFs and
+ * brw_eu_emit.c quietly converts them to be accesses of the top GRFs. The
+ * register allocators have to be careful of this to avoid corrupting the
MRFs
+ * with actual GRF allocations.
+ */
+#define GEN7_MRF_HACK_START 112.
+
/** Number of message register file registers */
#define BRW_MAX_MRF 16
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/vs: Avoid allocating registers in to the gen7 MRF hack region.
This is the corresponding fix to the previous one for the FS, but I
don't have a particular test for it.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/brw_vec4.h |1 +
.../drivers/dri/i965/brw_vec4_reg_allocate.cpp |6 +++---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |2 ++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 2555fa7..bc8b392 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -334,6 +334,7 @@ public:
int virtual_grf_count;
int virtual_grf_array_size;
int first_non_payload_grf;
+ unsigned int max_grf;
int *virtual_grf_def;
int *virtual_grf_use;
dst_reg userplane[MAX_CLIP_PLANES];
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index 2efe235..57b0519 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -87,9 +87,9 @@ vec4_visitor::reg_allocate_trivial()
assign(hw_reg_mapping, inst-src[2]);
}
- if (prog_data-total_grf BRW_MAX_GRF) {
+ if (prog_data-total_grf max_grf) {
fail(Ran out of regs on trivial allocator (%d/%d)\n,
- prog_data-total_grf, BRW_MAX_GRF);
+ prog_data-total_grf, max_grf);
}
}
@@ -144,7 +144,7 @@ vec4_visitor::reg_allocate()
{
int hw_reg_mapping[virtual_grf_count];
int first_assigned_grf = this-first_non_payload_grf;
- int base_reg_count = BRW_MAX_GRF - first_assigned_grf;
+ int base_reg_count = max_grf - first_assigned_grf;
int class_sizes[base_reg_count];
int class_count = 0;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 13ba18b..edb8b2a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2615,6 +2615,8 @@ vec4_visitor::vec4_visitor(struct brw_vs_compile *c,
this-virtual_grf_array_size = 0;
this-live_intervals_valid = false;
+ this-max_grf = intel-gen = 7 ? GEN7_MRF_HACK_START : BRW_MAX_GRF;
+
this-uniforms = 0;
}
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/fs: Fix rendering corruption in unigine tropics.
On 01/27/2012 01:16 PM, Eric Anholt wrote: We were allocating registers into the MRF hack region, resulting in sparkly renering in a few of the scenes. We could do better allocation by making an MRF class, having MRFs conflict with the corresponding GRFs, and tracking the live intervals of the MRFs and setting up the conflicts. But this is way easier for the moment. NOTE: This is a candidate for the 8.0 branch. Ugh. :( Thanks for taking care of this. I agree that this is the best approach for now. Reviewed-by: Kenneth Graunke kenn...@whitecape.org I am a bit concerned, though: why would it register allocate out of the top 16 GRFs unless it needed that many? By lowering the ceiling, won't we run out of registers entirely? We don't support spilling on Gen7 yet...I've been meaning to get around to implementing that. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45070] 'make linux-x86-64-debug' fails to build libGL.so.1.5.08000
https://bugs.freedesktop.org/show_bug.cgi?id=45070 Kenneth Graunke kenn...@whitecape.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- 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] swrast: Fix fixed-function fragment processing
Chad, I'm seeing a bunch of new warnings: In file included from swrast/s_aaline.c:470: swrast/s_aalinetemp.h: In function ‘aa_general_rgba_plot’: swrast/s_aalinetemp.h:70: warning: implicit declaration of function ‘_swrast_use_fragment_program’ swrast/s_aatriangle.c: In function ‘_swrast_set_aa_triangle_function’: swrast/s_aatriangle.c:302: warning: implicit declaration of function ‘_swrast_use_fragment_program’ swrast/s_context.c: In function ‘_swrast_update_rasterflags’: swrast/s_context.c:108: warning: implicit declaration of function ‘_swrast_use_fragment_program’ swrast/s_lines.c: In function ‘_swrast_choose_line’: swrast/s_lines.c:239: warning: implicit declaration of function ‘_swrast_use_fragment_program’ swrast/s_triangle.c: In function ‘_swrast_choose_triangle’: swrast/s_triangle.c:1041: warning: implicit declaration of function ‘_swrast_use_fragment_program’ -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45277] [bisected] Shading not working properly in Heroes of Newerth
https://bugs.freedesktop.org/show_bug.cgi?id=45277 --- Comment #1 from Rene Peinthor peint...@gmail.com 2012-01-27 15:37:42 PST --- can confirm this problem with my 5770, thanks for bisecting -- 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] mesa: fix maximum allowed proxy texture size condition
width, height parameter of glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type.
i.e. 1 (ctx-Const.MaxTextureLevels - 1)
This patch fixes Intel oglconform test case: max_values
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
Note: This is a candidate for mesa 8.0 branch.
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/teximage.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d11425d..018aca0 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1179,7 +1179,7 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum
target, GLint level,
switch (target) {
case GL_PROXY_TEXTURE_1D:
maxSize = 1 (ctx-Const.MaxTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
return GL_FALSE;
if (level = ctx-Const.MaxTextureLevels)
return GL_FALSE;
@@ -1191,9 +1191,9 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum
target, GLint level,
case GL_PROXY_TEXTURE_2D:
maxSize = 1 (ctx-Const.MaxTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
return GL_FALSE;
- if (height 2 * border || height 2 + maxSize)
+ if (height 2 * border || height maxSize)
return GL_FALSE;
if (level = ctx-Const.MaxTextureLevels)
return GL_FALSE;
@@ -1207,11 +1207,11 @@ _mesa_test_proxy_teximage(struct gl_context *ctx,
GLenum target, GLint level,
case GL_PROXY_TEXTURE_3D:
maxSize = 1 (ctx-Const.Max3DTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
return GL_FALSE;
- if (height 2 * border || height 2 + maxSize)
+ if (height 2 * border || height maxSize)
return GL_FALSE;
- if (depth 2 * border || depth 2 + maxSize)
+ if (depth 2 * border || depth maxSize)
return GL_FALSE;
if (level = ctx-Const.Max3DTextureLevels)
return GL_FALSE;
@@ -1237,9 +1237,9 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum
target, GLint level,
case GL_PROXY_TEXTURE_CUBE_MAP_ARB:
maxSize = 1 (ctx-Const.MaxCubeTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
return GL_FALSE;
- if (height 2 * border || height 2 + maxSize)
+ if (height 2 * border || height maxSize)
return GL_FALSE;
if (level = ctx-Const.MaxCubeTextureLevels)
return GL_FALSE;
@@ -1253,7 +1253,7 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum
target, GLint level,
case GL_PROXY_TEXTURE_1D_ARRAY_EXT:
maxSize = 1 (ctx-Const.MaxTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
return GL_FALSE;
if (height 1 || height ctx-Const.MaxArrayTextureLayers)
return GL_FALSE;
@@ -1267,9 +1267,9 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum
target, GLint level,
case GL_PROXY_TEXTURE_2D_ARRAY_EXT:
maxSize = 1 (ctx-Const.MaxTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
return GL_FALSE;
- if (height 2 * border || height 2 + maxSize)
+ if (height 2 * border || height maxSize)
return GL_FALSE;
if (depth 1 || depth ctx-Const.MaxArrayTextureLayers)
return GL_FALSE;
--
1.7.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/fs: Fix rendering corruption in unigine tropics.
On Fri, 27 Jan 2012 13:29:18 -0800, Kenneth Graunke kenn...@whitecape.org wrote: On 01/27/2012 01:16 PM, Eric Anholt wrote: We were allocating registers into the MRF hack region, resulting in sparkly renering in a few of the scenes. We could do better allocation by making an MRF class, having MRFs conflict with the corresponding GRFs, and tracking the live intervals of the MRFs and setting up the conflicts. But this is way easier for the moment. NOTE: This is a candidate for the 8.0 branch. Ugh. :( Thanks for taking care of this. I agree that this is the best approach for now. Reviewed-by: Kenneth Graunke kenn...@whitecape.org I am a bit concerned, though: why would it register allocate out of the top 16 GRFs unless it needed that many? By lowering the ceiling, won't we run out of registers entirely? We don't support spilling on Gen7 yet...I've been meaning to get around to implementing that. The register allocation isn't optimized to use the smallest possible number of registers, it just has a slight preference to use lower numbers. Changing the number of GRFs available should thoroughly change the register numbers chosen when you've got a big program with lots of interference that's just shy of spilling, which this one is (disable too many optimization passes in debugging, and you'll get failure to codegen). pgpN1ERTJXzkn.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Restore depth texture state on glPopAttrib(GL_TEXTURE_BIT).
According to Table 6.17 in the GL 2.1 specification, DEPTH_TEXTURE_MODE, TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC need to be restored on glPopAttrib(GL_TEXTURE_BIT). Makes oglconform's shad-compiler advanced.TestShadow2D_VertShader test a bit less grumbly. NOTE: This is a candidate for release branches. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/main/attrib.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c index 01e7945..07884c1 100644 --- a/src/mesa/main/attrib.c +++ b/src/mesa/main/attrib.c @@ -796,6 +796,9 @@ pop_texture_group(struct gl_context *ctx, struct texture_state *texstate) _mesa_TexParameterf(target, GL_TEXTURE_COMPARE_FAIL_VALUE_ARB, samp-CompareFailValue); } + _mesa_TexParameteri(target, GL_DEPTH_TEXTURE_MODE, samp-DepthMode); + _mesa_TexParameteri(target, GL_TEXTURE_COMPARE_MODE, samp-CompareMode); + _mesa_TexParameteri(target, GL_TEXTURE_COMPARE_FUNC, samp-CompareFunc); } /* remove saved references to the texture objects */ -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Removal of point size clamping in st/mesa
Hi everyone, the subject says it all. This series fixes gl_PointSize with transform feedback. There is a new piglit test to verify that a driver does clamping properly during rasterization: vs-point_size-zero I haven't changed Draw, because softpipe and llvmpipe do the clamping internally somewhere. (I didn't take a look where they do it, but they pass the test, which can't be said about r600 with point size clamping disabled) The only drivers I am not sure about are i915 and nouveau. Please review. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] svga: set POINTSIZEMIN to 1.0 for non-sprite non-aa points
---
src/gallium/drivers/svga/svga_state_rss.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_rss.c
b/src/gallium/drivers/svga/svga_state_rss.c
index af68d9c..43516fa 100644
--- a/src/gallium/drivers/svga/svga_state_rss.c
+++ b/src/gallium/drivers/svga/svga_state_rss.c
@@ -78,6 +78,7 @@ static int emit_rss( struct svga_context *svga,
unsigned dirty )
{
struct rs_queue queue;
+ float point_size_min;
queue.rs_count = 0;
@@ -211,14 +212,16 @@ static int emit_rss( struct svga_context *svga,
if (svga-state.sw.need_pipeline)
cullmode = SVGA3D_FACE_NONE;
+ point_size_min = curr-templ.point_quad_rasterization ||
+ curr-templ.point_smooth ? 0.0f : 1.0f;
+
EMIT_RS( svga, cullmode, CULLMODE, fail );
EMIT_RS( svga, curr-scissortestenable, SCISSORTESTENABLE, fail );
EMIT_RS( svga, curr-multisampleantialias, MULTISAMPLEANTIALIAS, fail );
EMIT_RS( svga, curr-lastpixel, LASTPIXEL, fail );
EMIT_RS( svga, curr-linepattern, LINEPATTERN, fail );
EMIT_RS_FLOAT( svga, curr-pointsize, POINTSIZE, fail );
- /* XXX still need to set this? */
- EMIT_RS_FLOAT( svga, 0.0, POINTSIZEMIN, fail );
+ EMIT_RS_FLOAT( svga, point_size_min, POINTSIZEMIN, fail );
EMIT_RS_FLOAT( svga, SVGA_MAX_POINTSIZE, POINTSIZEMAX, fail );
EMIT_RS( svga, curr-pointsprite, POINTSPRITEENABLE, fail);
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] r300g: set minimum point size to 1.0 for non-sprite non-aa points
---
src/gallium/drivers/r300/r300_state.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_state.c
b/src/gallium/drivers/r300/r300_state.c
index 33fdf3b..cf0c9d1 100644
--- a/src/gallium/drivers/r300/r300_state.c
+++ b/src/gallium/drivers/r300/r300_state.c
@@ -1017,7 +1017,6 @@ static void* r300_create_rs_state(struct pipe_context*
pipe,
const struct pipe_rasterizer_state* state)
{
struct r300_rs_state* rs = CALLOC_STRUCT(r300_rs_state);
-float psiz;
uint32_t vap_control_status;/* R300_VAP_CNTL_STATUS: 0x2140 */
uint32_t vap_clip_cntl; /* R300_VAP_CLIP_CNTL: 0x221C */
uint32_t point_size;/* R300_GA_POINT_SIZE: 0x421c */
@@ -1070,14 +1069,17 @@ static void* r300_create_rs_state(struct pipe_context*
pipe,
if (state-point_size_per_vertex) {
/* Per-vertex point size.
* Clamp to [0, max FB size] */
-psiz = pipe-screen-get_paramf(pipe-screen,
+float min_psiz = state-point_quad_rasterization ||
+ state-point_smooth ? 0.0f : 1.0f;
+float max_psiz = pipe-screen-get_paramf(pipe-screen,
PIPE_CAPF_MAX_POINT_WIDTH);
point_minmax =
-pack_float_16_6x(psiz) R300_GA_POINT_MINMAX_MAX_SHIFT;
+(pack_float_16_6x(min_psiz) R300_GA_POINT_MINMAX_MIN_SHIFT) |
+(pack_float_16_6x(max_psiz) R300_GA_POINT_MINMAX_MAX_SHIFT);
} else {
/* We cannot disable the point-size vertex output,
* so clamp it. */
-psiz = state-point_size;
+float psiz = state-point_size;
point_minmax =
(pack_float_16_6x(psiz) R300_GA_POINT_MINMAX_MIN_SHIFT) |
(pack_float_16_6x(psiz) R300_GA_POINT_MINMAX_MAX_SHIFT);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] r600g: set minimum point size to 1.0 for non-sprite non-aa points
---
src/gallium/drivers/r600/evergreen_state.c | 10 +-
src/gallium/drivers/r600/evergreend.h |6 ++
src/gallium/drivers/r600/r600_pipe.h |7 +++
src/gallium/drivers/r600/r600_state.c | 10 +-
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 69e3be9..243c490 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -896,6 +896,7 @@ static void *evergreen_create_rs_state(struct pipe_context
*ctx,
unsigned tmp;
unsigned prov_vtx = 1, polygon_dual_mode;
unsigned clip_rule;
+ float psize_min, psize_max;
if (rs == NULL) {
return NULL;
@@ -949,7 +950,14 @@ static void *evergreen_create_rs_state(struct pipe_context
*ctx,
/* point size 12.4 fixed point */
tmp = (unsigned)(state-point_size * 8.0);
r600_pipe_state_add_reg(rstate, R_028A00_PA_SU_POINT_SIZE,
S_028A00_HEIGHT(tmp) | S_028A00_WIDTH(tmp), 0x, NULL, 0);
- r600_pipe_state_add_reg(rstate, R_028A04_PA_SU_POINT_MINMAX,
0x8000, 0x, NULL, 0);
+
+ psize_min = state-point_quad_rasterization || state-point_smooth ?
0.0f : 1.0f;
+ psize_max = 8192;
+ /* Divide by two, because 0.5 = 1 pixel. */
+ r600_pipe_state_add_reg(rstate, R_028A04_PA_SU_POINT_MINMAX,
+
S_028A04_MIN_SIZE(r600_pack_float_12p4(psize_min/2)) |
+
S_028A04_MAX_SIZE(r600_pack_float_12p4(psize_max/2)),
+ 0x, NULL, 0);
tmp = (unsigned)state-line_width * 8;
r600_pipe_state_add_reg(rstate, R_028A08_PA_SU_LINE_CNTL,
S_028A08_WIDTH(tmp), 0x, NULL, 0);
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium/drivers/r600/evergreend.h
index d0c1130..3345ebf 100644
--- a/src/gallium/drivers/r600/evergreend.h
+++ b/src/gallium/drivers/r600/evergreend.h
@@ -1729,6 +1729,12 @@
#define R_028980_ALU_CONST_CACHE_VS_00x00028980
#define R_028984_ALU_CONST_CACHE_VS_10x00028984
#define R_028A04_PA_SU_POINT_MINMAX 0x00028A04
+#define S_028A04_MIN_SIZE(x) (((x) 0x) 0)
+#define G_028A04_MIN_SIZE(x) (((x) 0) 0x)
+#define C_028A04_MIN_SIZE0x
+#define S_028A04_MAX_SIZE(x) (((x) 0x) 16)
+#define G_028A04_MAX_SIZE(x) (((x) 16) 0x)
+#define C_028A04_MAX_SIZE0x
#define R_028A08_PA_SU_LINE_CNTL 0x00028A08
#define S_028A08_WIDTH(x)(((x) 0x) 0)
#define G_028A08_WIDTH(x)(((x) 0) 0x)
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 9de8e7e..f5efcdb 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -384,4 +384,11 @@ static inline unsigned r600_tex_aniso_filter(unsigned
filter)
/* else */return 4;
}
+/* 12.4 fixed-point */
+static INLINE unsigned r600_pack_float_12p4(float x)
+{
+ return x = 0? 0 :
+ x = 4096 ? 0x : x * 16;
+}
+
#endif
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index e093e50..cea31f2 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -948,6 +948,7 @@ static void *r600_create_rs_state(struct pipe_context *ctx,
unsigned prov_vtx = 1, polygon_dual_mode;
unsigned clip_rule;
unsigned sc_mode_cntl;
+ float psize_min, psize_max;
if (rs == NULL) {
return NULL;
@@ -1000,7 +1001,14 @@ static void *r600_create_rs_state(struct pipe_context
*ctx,
/* point size 12.4 fixed point */
tmp = (unsigned)(state-point_size * 8.0);
r600_pipe_state_add_reg(rstate, R_028A00_PA_SU_POINT_SIZE,
S_028A00_HEIGHT(tmp) | S_028A00_WIDTH(tmp), 0x, NULL, 0);
- r600_pipe_state_add_reg(rstate, R_028A04_PA_SU_POINT_MINMAX,
0x8000, 0x, NULL, 0);
+
+ psize_min = state-point_quad_rasterization || state-point_smooth ?
0.0f : 1.0f;
+ psize_max = 8192;
+ /* Divide by two, because 0.5 = 1 pixel. */
+ r600_pipe_state_add_reg(rstate, R_028A04_PA_SU_POINT_MINMAX,
+
S_028A04_MIN_SIZE(r600_pack_float_12p4(psize_min/2)) |
+
S_028A04_MAX_SIZE(r600_pack_float_12p4(psize_max/2)),
+ 0x, NULL, 0);
tmp = (unsigned)state-line_width * 8;
r600_pipe_state_add_reg(rstate, R_028A08_PA_SU_LINE_CNTL,
S_028A08_WIDTH(tmp), 0x, NULL, 0);
--
1.7.5.4
[Mesa-dev] [PATCH 4/4] st/mesa: kill off point size clamping in vertex shaders
This fixes the gl_PointSize transform feedback test.
---
src/mesa/program/prog_statevars.c | 27 ---
src/mesa/program/prog_statevars.h |1 -
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 49
src/mesa/state_tracker/st_mesa_to_tgsi.c | 49
4 files changed, 0 insertions(+), 126 deletions(-)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index f34a6d3..98ab9d0 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -495,29 +495,6 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
value[3] = ctx-Point.Threshold;
}
return;
- case STATE_POINT_SIZE_IMPL_CLAMP:
- {
- /* for implementation clamp only in vs */
-GLfloat minImplSize;
-GLfloat maxImplSize;
-if (ctx-Point.PointSprite) {
- minImplSize = ctx-Const.MinPointSizeAA;
- maxImplSize = ctx-Const.MaxPointSize;
-}
-else if (ctx-Point.SmoothFlag || ctx-Multisample._Enabled) {
- minImplSize = ctx-Const.MinPointSizeAA;
- maxImplSize = ctx-Const.MaxPointSizeAA;
-}
-else {
- minImplSize = ctx-Const.MinPointSize;
- maxImplSize = ctx-Const.MaxPointSize;
-}
-value[0] = ctx-Point.Size;
-value[1] = minImplSize;
-value[2] = maxImplSize;
-value[3] = ctx-Point.Threshold;
- }
- return;
case STATE_LIGHT_SPOT_DIR_NORMALIZED:
{
/* here, state[2] is the light number */
@@ -729,7 +706,6 @@ _mesa_program_state_flags(const gl_state_index
state[STATE_LENGTH])
case STATE_FOG_PARAMS_OPTIMIZED:
return _NEW_FOG;
case STATE_POINT_SIZE_CLAMPED:
- case STATE_POINT_SIZE_IMPL_CLAMP:
return _NEW_POINT | _NEW_MULTISAMPLE;
case STATE_LIGHT_SPOT_DIR_NORMALIZED:
case STATE_LIGHT_POSITION:
@@ -921,9 +897,6 @@ append_token(char *dst, gl_state_index k)
case STATE_POINT_SIZE_CLAMPED:
append(dst, pointSizeClamped);
break;
- case STATE_POINT_SIZE_IMPL_CLAMP:
- append(dst, pointSizeImplClamp);
- break;
case STATE_LIGHT_SPOT_DIR_NORMALIZED:
append(dst, lightSpotDirNormalized);
break;
diff --git a/src/mesa/program/prog_statevars.h
b/src/mesa/program/prog_statevars.h
index 8b731e1..65baa78 100644
--- a/src/mesa/program/prog_statevars.h
+++ b/src/mesa/program/prog_statevars.h
@@ -118,7 +118,6 @@ typedef enum gl_state_index_ {
STATE_TEXRECT_SCALE,
STATE_FOG_PARAMS_OPTIMIZED, /* for faster fog calc */
STATE_POINT_SIZE_CLAMPED,/* includes implementation dependent size
clamp */
- STATE_POINT_SIZE_IMPL_CLAMP, /* for implementation clamp only in vs */
STATE_LIGHT_SPOT_DIR_NORMALIZED, /* pre-normalized spot dir */
STATE_LIGHT_POSITION, /* object vs eye space */
STATE_LIGHT_POSITION_NORMALIZED, /* object vs eye space */
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 188e8d9..b15ea2c 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -3843,12 +3843,6 @@ struct st_translate {
struct ureg_src samplers[PIPE_MAX_SAMPLERS];
struct ureg_src systemValues[SYSTEM_VALUE_MAX];
- /* Extra info for handling point size clamping in vertex shader */
- struct ureg_dst pointSizeResult; /** Actual point size output register */
- struct ureg_src pointSizeConst; /** Point size range constant register */
- GLint pointSizeOutIndex; /** Temp point size output register */
- GLboolean prevInstWrotePointSize;
-
const GLuint *inputMapping;
const GLuint *outputMapping;
@@ -3970,9 +3964,6 @@ dst_register(struct st_translate *t,
return t-temps[index];
case PROGRAM_OUTPUT:
- if (t-procType == TGSI_PROCESSOR_VERTEX index == VERT_RESULT_PSIZ)
- t-prevInstWrotePointSize = GL_TRUE;
-
if (t-procType == TGSI_PROCESSOR_VERTEX)
assert(index VERT_RESULT_MAX);
else if (t-procType == TGSI_PROCESSOR_FRAGMENT)
@@ -4502,8 +4493,6 @@ st_translate_program(
t-inputMapping = inputMapping;
t-outputMapping = outputMapping;
t-ureg = ureg;
- t-pointSizeOutIndex = -1;
- t-prevInstWrotePointSize = GL_FALSE;
if (program-shader_program) {
for (i = 0; i program-shader_program-NumUserUniformStorage; i++) {
@@ -4597,25 +4586,6 @@ st_translate_program(
outputSemanticName[i],
outputSemanticIndex[i]);
}
- if ((outputSemanticName[i] == TGSI_SEMANTIC_PSIZE) proginfo-Id) {
-/* Writing to the point size result register requires special
- * handling to
Re: [Mesa-dev] [PATCH] swrast: Fix fixed-function fragment processing
On 01/27/2012 03:19 PM, Brian Paul wrote: Chad, I'm seeing a bunch of new warnings: Brian, sorry about that. I forgot a #include, of course. I just pushed the fix. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: simplify initialization of light_twoside
Core Mesa does this for us, see update_two_size in state.c.
---
src/mesa/state_tracker/st_atom_rasterizer.c | 24 +++-
1 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 25799bf..204f505 100644
--- a/src/mesa/state_tracker/st_atom_rasterizer.c
+++ b/src/mesa/state_tracker/st_atom_rasterizer.c
@@ -90,28 +90,10 @@ static void update_raster_state( struct st_context *st )
if (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION_EXT)
raster-flatshade_first = 1;
- /* _NEW_LIGHT | _NEW_PROGRAM
-*
-* Back-face colors can come from traditional lighting (when
-* GL_LIGHT_MODEL_TWO_SIDE is set) or from vertex programs/shaders (when
-* GL_VERTEX_PROGRAM_TWO_SIDE is set). Note the logic here.
-*/
- if (ctx-VertexProgram._Current) {
- if (ctx-VertexProgram._Enabled ||
- (ctx-Shader.CurrentVertexProgram
- ctx-Shader.CurrentVertexProgram-LinkStatus)) {
- /* user-defined vertex program or shader */
- raster-light_twoside = ctx-VertexProgram.TwoSideEnabled;
- }
- else {
- /* TNL-generated program */
- raster-light_twoside = ctx-Light.Enabled
ctx-Light.Model.TwoSide;
- }
- }
- else if (ctx-Light.Enabled ctx-Light.Model.TwoSide) {
- raster-light_twoside = 1;
- }
+ /* _NEW_LIGHT | _NEW_PROGRAM */
+ raster-light_twoside = ctx-VertexProgram._TwoSideEnabled;
+ /*_NEW_LIGHT | _NEW_BUFFERS */
raster-clamp_vertex_color = !st-clamp_vert_color_in_shader
ctx-Light._ClampVertexColor;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fixes for DrawRangeElements[BaseVertex] index validation
in check_index_bounds the comparison needs to be greater equal since
contrary to the name _MaxElement is the count of the array.
In vbo_exec_DrawRangeElementsBaseVertex, take into account the basevertex.
As far as I can tell it is completely ok (though maybe stupid) to have
start/end of 100/199, with _MaxElement being 100, if the basevertex
is -100 (since the start/end are prior to adding basevertex). The opposite
is also true (0/99 is not ok if _MaxElement is 100 and and basevertex is 100).
Previously we would have issued a warning in such cases and worse probably
fixed end to a bogus value.
Totally untested, found by code inspection when looking at bug 40361 (which
seems unrelated after all).
---
src/mesa/main/api_validate.c |2 +-
src/mesa/vbo/vbo_exec_array.c | 30 +++---
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index b6871d0..1ae491f 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -187,7 +187,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei count,
GLenum type,
vbo_get_minmax_indices(ctx, prim, ib, min, max, 1);
if ((int)(min + basevertex) 0 ||
- max + basevertex ctx-Array.ArrayObj-_MaxElement) {
+ max + basevertex = ctx-Array.ArrayObj-_MaxElement) {
/* the max element is out of bounds of one or more enabled arrays */
_mesa_warning(ctx, glDrawElements() index=%u is out of bounds (max=%u),
max, ctx-Array.ArrayObj-_MaxElement);
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 9861b21..3e0fe20 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -885,17 +885,18 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
end = MIN2(end, 0x);
}
- if (end = ctx-Array.ArrayObj-_MaxElement) {
+ if ((int)(start + basevertex) 0 ||
+ end + basevertex = ctx-Array.ArrayObj-_MaxElement) {
/* the max element is out of bounds of one or more enabled arrays */
warnCount++;
if (warnCount 10) {
- _mesa_warning(ctx, glDraw[Range]Elements(start %u, end %u, count %d,
- type 0x%x, indices=%p)\n
+ _mesa_warning(ctx, glDrawRangeElements[BaseVertex](start %u, end %u,
count %d,
+ type 0x%x, indices=%p, base %d)\n
\tend is out of bounds (max=%u)
Element Buffer %u (size %d)\n
\tThis should probably be fixed in the application.,
- start, end, count, type, indices,
+ start, end, count, type, indices, basevertex,
ctx-Array.ArrayObj-_MaxElement - 1,
ctx-Array.ArrayObj-ElementArrayBufferObj-Name,
(int) ctx-Array.ArrayObj-ElementArrayBufferObj-Size);
@@ -913,14 +914,14 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
if (0) {
GLuint max = _mesa_max_buffer_index(ctx, count, type, indices,
ctx-Array.ArrayObj-ElementArrayBufferObj);
- if (max = ctx-Array.ArrayObj-_MaxElement) {
+ if (max + basevertex = ctx-Array.ArrayObj-_MaxElement) {
if (warnCount 10) {
- _mesa_warning(ctx, glDraw[Range]Elements(start %u, end %u,
- count %d, type 0x%x, indices=%p)\n
+ _mesa_warning(ctx, glDrawRangeElements[BaseVertex](start %u,
end %u,
+ count %d, type 0x%x, indices=%p, base %d)\n
\tindex=%u is out of bounds (max=%u)
Element Buffer %u (size %d)\n
\tSkipping the glDrawRangeElements() call,
- start, end, count, type, indices, max,
+ start, end, count, type, indices, basevertex, max,
ctx-Array.ArrayObj-_MaxElement - 1,
ctx-Array.ArrayObj-ElementArrayBufferObj-Name,
(int)
ctx-Array.ArrayObj-ElementArrayBufferObj-Size);
@@ -928,13 +929,20 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
}
/* XXX we could also find the min index and compare to 'start'
* to see if start is correct. But it's more likely to get the
- * upper bound wrong.
+ * upper bound wrong, at least for the non-BaseVertex variant...
*/
}
/* Set 'end' to the max possible legal value */
assert(ctx-Array.ArrayObj-_MaxElement = 1);
- end = ctx-Array.ArrayObj-_MaxElement - 1;
+ /* XXX Could have positive uint overflow for both start and end too. */
+ if ((int)(ctx-Array.ArrayObj-_MaxElement - 1 - basevertex) 0) {
+ return;
+ }
+ end = ctx-Array.ArrayObj-_MaxElement - 1 - basevertex;
+ if
[Mesa-dev] Mesa 8.0 release candidate 2
Mesa 8.0-rc2 has been released. This is a release candidate for the 8.0 development release. The tag in the GIT repository for Mesa 8.0-rc2 is 'mesa-8.0-rc2'. Mesa 8.0-rc2 is available for download at ftp://freedesktop.org/pub/mesa/8.0/ md5sums: c2afdd52e138692db536645fa57f0c87 MesaLib-8.0-rc2.tar.gz 8fd3c3315b7b394b1225aaab5301f8dd MesaLib-8.0-rc2.tar.bz2 e9f167cacf94a8cf989d4c9fe37b83d4 MesaLib-8.0-rc2.zip ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/gen7: Always allocate push constant space before uploading.
It's not clear from the specs why this would be required, but it fixes
the regression in glean/fbo. My theory is that push constant uploads
incrementally fill up the allocated space (with wrapping), but don't
synchronize on previous constant buffers being dereferenced when
overwriting after a wrap (or possibly they just don't write at all),
and this packet synchronizes on all previous push constant buffer
usage in the space. Most applications don't run into trouble, because
some sort of nonpipelined update happens often enough to cause syncing
anyway.
But it's just a theory.
---
src/mesa/drivers/dri/i965/brw_state.h|1 -
src/mesa/drivers/dri/i965/brw_state_upload.c |1 -
src/mesa/drivers/dri/i965/gen7_urb.c | 25 +
src/mesa/drivers/dri/i965/gen7_vs_state.c|6 ++
src/mesa/drivers/dri/i965/gen7_wm_state.c|6 ++
5 files changed, 13 insertions(+), 26 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 2dd5665..fcfe79f 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -110,7 +110,6 @@ extern const struct brw_tracked_state gen7_clip_state;
extern const struct brw_tracked_state gen7_depth_stencil_state_pointer;
extern const struct brw_tracked_state gen7_disable_stages;
extern const struct brw_tracked_state gen7_ps_state;
-extern const struct brw_tracked_state gen7_push_constant_alloc;
extern const struct brw_tracked_state gen7_samplers;
extern const struct brw_tracked_state gen7_sbe_state;
extern const struct brw_tracked_state gen7_sf_clip_viewport;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index d071f87..c7b796c 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -188,7 +188,6 @@ const struct brw_tracked_state *gen7_atoms[] =
/* Command packets: */
brw_invariant_state,
- gen7_push_constant_alloc,
/* must do before binding table pointers, cc state ptrs */
brw_state_base_address,
diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c
b/src/mesa/drivers/dri/i965/gen7_urb.c
index e6cf1eb..419bdab 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -27,7 +27,7 @@
#include brw_state.h
#include brw_defines.h
-/**
+/*
* The following diagram shows how we partition the URB:
*
* 8kB 8kB Rest of the URB space
@@ -50,29 +50,6 @@
*
* See Volume 2a: 3D Pipeline, section 1.8.
*/
-static void
-gen7_allocate_push_constants(struct brw_context *brw)
-{
- struct intel_context *intel = brw-intel;
- BEGIN_BATCH(2);
- OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_VS 16 | (2 - 2));
- OUT_BATCH(8);
- ADVANCE_BATCH();
-
- BEGIN_BATCH(2);
- OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_PS 16 | (2 - 2));
- OUT_BATCH(8 | 8 GEN7_PUSH_CONSTANT_BUFFER_OFFSET_SHIFT);
- ADVANCE_BATCH();
-}
-
-const struct brw_tracked_state gen7_push_constant_alloc = {
- .dirty = {
- .mesa = 0,
- .brw = BRW_NEW_CONTEXT,
- .cache = 0,
- },
- .emit = gen7_allocate_push_constants,
-};
static void
gen7_upload_urb(struct brw_context *brw)
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 0746e6c..31fa060 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -46,6 +46,12 @@ upload_vs_state(struct brw_context *brw)
OUT_BATCH(brw-sampler.offset);
ADVANCE_BATCH();
+ /* See comment in gen7_urb.c to explain the allocation. */
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_VS 16 | (2 - 2));
+ OUT_BATCH(8);
+ ADVANCE_BATCH();
+
if (brw-vs.push_const_size == 0) {
/* Disable the push constant buffers. */
BEGIN_BATCH(7);
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index 3f9..a1035f3 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -131,6 +131,12 @@ upload_ps_state(struct brw_context *brw)
OUT_BATCH(brw-sampler.offset);
ADVANCE_BATCH();
+ /* See comment in gen7_urb.c to explain the allocation. */
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_PS 16 | (2 - 2));
+ OUT_BATCH(8 | 8 GEN7_PUSH_CONSTANT_BUFFER_OFFSET_SHIFT);
+ ADVANCE_BATCH();
+
/* CACHE_NEW_WM_PROG */
if (brw-wm.prog_data-nr_params == 0) {
/* Disable the push constant buffers. */
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] linker.cpp warning
On Tue, Jan 24, 2012 at 11:40 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 01/24/2012 10:08 AM, Brian Paul wrote: I've been seeing this error from linker.cpp for a few days now: linker.cpp: In function ‘gl_shader* link_intrastage_shaders(void*, gl_context*, gl_shader_program*, gl_shader**, unsigned int)’: linker.cpp:1008: warning: ‘link_intrastage_shaders(void*, gl_context*, gl_shader_program*, gl_shader**, unsigned int)::array_sizing_visitor’ declared with greater visibility than the type of its field ‘link_intrastage_shaders(void*, gl_context*, gl_shader_program*, gl_shader**, unsigned int)::array_sizing_visitor::anonymous’ linker.cpp:1008: warning: ‘link_intrastage_shaders(void*, gl_context*, gl_shader_program*, gl_shader**, unsigned int)::array_sizing_visitor’ declared with greater visibility than its base ‘ir_hierarchical_visitor’ ar: creating libglsl.a This is really weird...I've never seen this. What version of g++ are you using? Ian and I both use 4.6. I see the same warning on Lion. $ g++ --version i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: Remove unused variables.
Dave. Ping. On Mon, Jan 16, 2012 at 3:46 AM, Jose Fonseca jfons...@vmware.com wrote: Hi Vinson, These lines were added by Dave in commit 1865f341d8f45b389061fc08d2da90b7aa8a6099 Author: Dave Airlie airl...@redhat.com Date: Fri Jan 6 12:23:00 2012 + draw: clipdistance support (v2) Add support for using the clipdistance instead of clip plane. Passes all piglit clipdistance tests. v2: fixup some comments from Brian in review. Signed-off-by: Dave Airlie airl...@redhat.com So Dave should take a look, and determine whether this is really dead code, or code is missing. Jose - Original Message - Fix this GCC warning. draw_pipe_clip.c: In function ‘interp’: draw_pipe_clip.c:122:13: warning: variable ‘clip_dist’ set but not used [-Wunused-but-set-variable] Signed-off-by: Vinson Lee v...@freedesktop.org --- src/gallium/auxiliary/draw/draw_pipe_clip.c | 4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c b/src/gallium/auxiliary/draw/draw_pipe_clip.c index f701972..4da4d65 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_clip.c +++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c @@ -119,12 +119,8 @@ static void interp( const struct clip_stage *clip, const unsigned nr_attrs = draw_current_shader_outputs(clip-stage.draw); const unsigned pos_attr = draw_current_shader_position_output(clip-stage.draw); const unsigned clip_attr = draw_current_shader_clipvertex_output(clip-stage.draw); - unsigned clip_dist[2]; unsigned j; - clip_dist[0] = draw_current_shader_clipdistance_output(clip-stage.draw, 0); - clip_dist[1] = draw_current_shader_clipdistance_output(clip-stage.draw, 1); - /* Vertex header. */ dst-clipmask = 0; -- 1.7.8.3 ___ 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
[Mesa-dev] [PATCH] osmesa: Fix osmesa_context.DataType type.
Fixes these GCC warnings. osmesa.c: In function ‘osmesa_renderbuffer_storage’: osmesa.c:417: warning: comparison is always false due to limited range of data type osmesa.c:423: warning: comparison is always false due to limited range of data type osmesa.c:431: warning: comparison is always false due to limited range of data type osmesa.c:437: warning: comparison is always false due to limited range of data type osmesa.c:447: warning: comparison is always false due to limited range of data type osmesa.c:453: warning: comparison is always false due to limited range of data type osmesa.c:463: warning: comparison is always false due to limited range of data type osmesa.c:466: warning: comparison is always false due to limited range of data type osmesa.c:476: warning: comparison is always false due to limited range of data type osmesa.c:479: warning: comparison is always false due to limited range of data type Signed-off-by: Vinson Lee v...@freedesktop.org --- src/mesa/drivers/osmesa/osmesa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mesa/drivers/osmesa/osmesa.c index 0a42741..0ec2d37 100644 --- a/src/mesa/drivers/osmesa/osmesa.c +++ b/src/mesa/drivers/osmesa/osmesa.c @@ -75,7 +75,7 @@ struct osmesa_context GLvoid *rowaddr[MAX_HEIGHT];/* address of first pixel in each image row */ GLboolean yup; /* TRUE - Y increases upward */ /* FALSE - Y increases downward */ - GLboolean DataType; + GLenum DataType; }; -- 1.7.8.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
