date:20120126

On Wed, Jan 25, 2012 at 09:40, Jose Fonseca jfons...@vmware.com wrote:
 Thanks Stephane.  Much better.

 I still think the flush flags semantics are quite confusing, but the problem 
 comes from way before this change. Take e.g. the chunk:

 +      /* don't prepare if we only are flushing the backend */
 +      if (!(flags  DRAW_FLUSH_BACKEND))
 +         draw-pt.frontend = NULL;

 Why are we looking at the backend flush flag to determine whether to flush 
 the frontend?

 Shouldn't it be

 +      /* prepare on state changes */
 +      if (flags  DRAW_FLUSH_STATE_CHANGE)
 +         draw-pt.frontend = NULL;

 Or maybe

  #define DRAW_FLUSH_FRONTEND 0x1
  #define DRAW_FLUSH_BACKEND  0x2

  // Flush all
  #define DRAW_FLUSH_STATE_CHANGE  (DRAW_FLUSH_FRONTEND | DRAW_FLUSH_BACKEND)

 +      /* prepare only when we are flushing the frontend */
 +      if (flags  DRAW_FLUSH_FRONTEND)
 +         draw-pt.frontend = NULL;

 But I guess this doesn't need to be fixed now -- we can fix this when we feel 
 the need to add more flush flags -- then it should be clearer what to do.


Right, it is odd, but then we don't have the right flags... since it
seemed touchy I wanted to do it separately. I'll handle it next.

Stéphane
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): automake: src/egl/wayland

2012-01-26 Thread Benjamin Franzke

Sorry, guys.

The wayland macros is missing, but i'm not sure how to properly solve this.
We could use m4_ifdef to include it only when wayland is actually available,
but that will require that the packager has it available when creating
the tarballs.

Attaching a patch for that, have you got better ideas?

2012/1/26 Stéphane Marchesin stephane.marche...@gmail.com:
 Fails here too (fedora 15).

 Stéphane


 On Thu, Jan 26, 2012 at 01:35, Jose Fonseca jfons...@vmware.com wrote:
 Benjamin,

 I'm getting build failures with your commit:

 + ./autogen.sh --prefix=/usr --enable-gles1 --enable-gles2 --enable-openvg 
 --enable-xorg --enable-xa --disable-glut --enable-gallium-egl 
 --enable-gallium-llvm --with-dri-drivers=swrast 
 --with-gallium-drivers=i915,nouveau,r300,r600,svga,swrast
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal
 configure.ac:15: warning: AC_INIT: not a literal: 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
 autoreconf: configure.ac: tracing
 configure.ac:15: warning: AC_INIT: not a literal: 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
 autoreconf: running: libtoolize --install --copy
 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `bin'.
 libtoolize: copying file `bin/config.guess'
 libtoolize: copying file `bin/config.sub'
 libtoolize: copying file `bin/install-sh'
 libtoolize: copying file `bin/ltmain.sh'
 libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
 libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
 libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
 configure.ac:15: warning: AC_INIT: not a literal: 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
 autoreconf: running: /usr/bin/autoconf
 configure.ac:15: warning: AC_INIT: not a literal: 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
 autoreconf: configure.ac: not using Autoheader
 autoreconf: running: automake --add-missing --copy --no-force
 configure.ac:15: warning: AC_INIT: not a literal: 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
 configure.ac:19: installing `bin/missing'
 src/egl/wayland/wayland-drm/Makefile.am: installing `bin/depcomp'
 autoreconf: Leaving directory `.'
 configure: WARNING: unrecognized options: --disable-glut
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... no
 checking for mawk... mawk
 checking whether make sets $(MAKE)... yes
 checking for style of include used by make... GNU
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables...
 checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking for a sed that does not truncate output... /bin/sed
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for fgrep... /bin/grep -F
 checking for ld used by gcc... /usr/bin/ld
 checking if the linker (/usr/bin/ld) is GNU ld... yes
 checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
 checking the name lister (/usr/bin/nm -B) interface... BSD nm
 checking whether ln -s works... yes
 checking the maximum length of command line arguments... 1572864
 checking whether the shell understands some XSI constructs... yes
 checking whether the shell understands +=... yes
 checking for /usr/bin/ld option to reload object files... -r
 checking for objdump... objdump
 checking how to recognize dependent libraries... pass_all
 checking for ar... ar
 checking for strip... strip
 checking for ranlib... ranlib
 checking command to parse /usr/bin/nm -B output from gcc object... ok
 checking how to run the C preprocessor... gcc -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking for dlfcn.h... yes
 checking for objdir... .libs
 checking if gcc supports -fno-rtti -fno-exceptions... no
 checking for gcc option to produce PIC... -fPIC -DPIC
 checking if gcc PIC flag -fPIC -DPIC works... yes
 checking if gcc static flag -static works... yes
 checking if gcc supports -c -o file.o... yes
 checking if gcc supports -c -o file.o... (cached) yes
 checking whether the gcc linker (/usr/bin/ld -m elf_x86_64)

Re: [Mesa-dev] Mesa (master): automake: src/egl/wayland

2012-01-26 Thread Jose Fonseca

Thanks. Your patch lets me build successfully. I can't install wayland 
development packages on ubuntu 11.10 due to package conflicts, so there's no 
alternative for me here.

I'm not sure about the tarball case. Perhaps you could disable/fail tarball 
creation when these macros are missing. But for the time being, please commit 
your patch as is.

Jose

- Original Message -
 Sorry, guys.
 
 The wayland macros is missing, but i'm not sure how to properly solve
 this.
 We could use m4_ifdef to include it only when wayland is actually
 available,
 but that will require that the packager has it available when
 creating
 the tarballs.
 
 Attaching a patch for that, have you got better ideas?
 
 2012/1/26 Stéphane Marchesin stephane.marche...@gmail.com:
  Fails here too (fedora 15).
 
  Stéphane
 
 
  On Thu, Jan 26, 2012 at 01:35, Jose Fonseca jfons...@vmware.com
  wrote:
  Benjamin,
 
  I'm getting build failures with your commit:
 
  + ./autogen.sh --prefix=/usr --enable-gles1 --enable-gles2
  --enable-openvg --enable-xorg --enable-xa --disable-glut
  --enable-gallium-egl --enable-gallium-llvm
  --with-dri-drivers=swrast
  --with-gallium-drivers=i915,nouveau,r300,r600,svga,swrast
  autoreconf: Entering directory `.'
  autoreconf: configure.ac: not using Gettext
  autoreconf: running: aclocal
  configure.ac:15: warning: AC_INIT: not a literal:
  https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
  autoreconf: configure.ac: tracing
  configure.ac:15: warning: AC_INIT: not a literal:
  https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
  autoreconf: running: libtoolize --install --copy
  libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `bin'.
  libtoolize: copying file `bin/config.guess'
  libtoolize: copying file `bin/config.sub'
  libtoolize: copying file `bin/install-sh'
  libtoolize: copying file `bin/ltmain.sh'
  libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to
  configure.ac and
  libtoolize: rerunning libtoolize, to keep the correct libtool
  macros in-tree.
  libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in
  Makefile.am.
  configure.ac:15: warning: AC_INIT: not a literal:
  https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
  autoreconf: running: /usr/bin/autoconf
  configure.ac:15: warning: AC_INIT: not a literal:
  https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
  autoreconf: configure.ac: not using Autoheader
  autoreconf: running: automake --add-missing --copy --no-force
  configure.ac:15: warning: AC_INIT: not a literal:
  https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
  configure.ac:19: installing `bin/missing'
  src/egl/wayland/wayland-drm/Makefile.am: installing `bin/depcomp'
  autoreconf: Leaving directory `.'
  configure: WARNING: unrecognized options: --disable-glut
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-unknown-linux-gnu
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... no
  checking for mawk... mawk
  checking whether make sets $(MAKE)... yes
  checking for style of include used by make... GNU
  checking for gcc... gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables...
  checking whether we are cross compiling... no
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking for gcc option to accept ISO C89... none needed
  checking dependency style of gcc... gcc3
  checking for a sed that does not truncate output... /bin/sed
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for fgrep... /bin/grep -F
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
  -B
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  checking whether ln -s works... yes
  checking the maximum length of command line arguments... 1572864
  checking whether the shell understands some XSI constructs... yes
  checking whether the shell understands +=... yes
  checking for /usr/bin/ld option to reload object files... -r
  checking for objdump... objdump
  checking how to recognize dependent libraries... pass_all
  checking for ar... ar
  checking for strip... strip
  checking for ranlib... ranlib
  checking command to parse /usr/bin/nm -B output from gcc object...
  ok
  checking how to run the C preprocessor... gcc -E
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes

Re: [Mesa-dev] [PATCH 4/4] dri: Add a default drirc to be installed to provide application workarounds.

On Thu, Jan 26, 2012 at 2:24 AM, Eric Anholt e...@anholt.net wrote:
 On Wed, 25 Jan 2012 23:56:27 +0100, Marek Olšák mar...@gmail.com wrote:
 Hi Eric,

 I don't like this, because I don't have drirc in my system. Obviously
 Canonical decided not to include it and that also means some of my
 users don't have it. Please can we add workarounds directly in the
 code and on a per-app basis? Something like:

 if (is_linked(libUnigine_x86.so) ||
     is_linked(libUnigine_x64.so))
    apply_workarounds_for_unigine();

 We've never shipped a drirc from Mesa before, which this patch changes,
 so I don't see how I don't have one installed yet matters.

 drirc is a great way to provide these application-specific workarounds,
 because it's flexible at runtime, so you can test if the app still needs
 the crap, or you can reuse the crap for some other app, or you can apply
 the crap to every app because you never want to be bothered.

OK. I googled some discussion where they decided not to ship it. It
took me a whlle to realize it hadn't been from Mesa. Sorry for the
noise.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45263] New: git mesa configure error

https://bugs.freedesktop.org/show_bug.cgi?id=45263

 Bug #: 45263
   Summary: git mesa configure error
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: wol...@onsneteindhoven.nl


The latest git mesa shows the following error:
---
./configure: line 21529:
syntax error near unexpected token
`'$(top_srcdir)/src/egl/wayland/wayland-drm/protocol''
./configure: line 21529: `   
WAYLAND_SCANNER_RULES('$(top_srcdir)/src/egl/wayland/wayland-drm/protocol')'
---

-- 
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 45263] git mesa configure error

https://bugs.freedesktop.org/show_bug.cgi?id=45263

José Fonseca jfons...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 CC||benjaminfranzke@googlemail.
   ||com, jfons...@vmware.com

--- Comment #1 from José Fonseca jfons...@vmware.com 2012-01-26 03:08:26 PST 
---
Just fixed w/

commit 412042523e80ddb19196851b6e729238b5cc0609
Author: Benjamin Franzke benjaminfran...@googlemail.com
Date:   Thu Jan 26 10:50:04 2012 +0100

configure: Use WAYLAND_SCANNER_RULES only if available

This has the drawback that when creating configure for
distribution, wayland needs to be available for the packager.

Also the the macros has the wayland prefix hardcoded, so
we cant copy it in mesa right now.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): draw: Only run prepare when state, prim and opt changes

2012-01-26 Thread Jose Fonseca

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
 Tested-by: Stéphane Marchesin marc...@chromium.org
 
 ---
 
  src/gallium/auxiliary/draw/draw_context.c   |6 +++
  src/gallium/auxiliary/draw/draw_private.h   |8 
  src/gallium/auxiliary/draw/draw_pt.c|   49
  ---
  src/gallium/auxiliary/draw/draw_pt.h|2 +-
  src/gallium/auxiliary/draw/draw_pt_vsplit.c |   11 --
  5 files changed, 66 insertions(+), 10 deletions(-)
 
 diff --git a/src/gallium/auxiliary/draw/draw_context.c
 b/src/gallium/auxiliary/draw/draw_context.c
 index 4ce4445..3c0b1aa 100644
 --- a/src/gallium/auxiliary/draw/draw_context.c
 +++ b/src/gallium/auxiliary/draw/draw_context.c
 @@ -355,6 +355,10 @@ draw_set_vertex_elements(struct draw_context
 *draw,
  {
 assert(count = PIPE_MAX_ATTRIBS);
  
 +   /* We could improve this by only flushing the frontend and the
 fetch part
 +* of the middle. This would avoid recalculating the emit keys.*/
 +   draw_do_flush( draw, DRAW_FLUSH_STATE_CHANGE );
 +
 memcpy(draw-pt.vertex_element, elements, count *
 sizeof(elements[0]));
 draw-pt.nr_vertex_elements = count;
  }
 @@ -654,6 +658,8 @@ void draw_do_flush( struct draw_context *draw,
 unsigned flags )
  
draw_pipeline_flush( draw, flags );
  
 +  draw_pt_flush( draw, flags );
 +
draw-flushing = FALSE;
 }
  }
 diff --git a/src/gallium/auxiliary/draw/draw_private.h
 b/src/gallium/auxiliary/draw/draw_private.h
 index 1a0286d..c3eca97 100644
 --- a/src/gallium/auxiliary/draw/draw_private.h
 +++

Re: [Mesa-dev] [PATCH 1/3] mesa: Fix handling of glCopyBufferSubData() for src == dst.

On Wed, Jan 25, 2012 at 8:51 PM, Eric Anholt e...@anholt.net wrote:
 Fixes piglit ARB_copy_buffer-overlap, which previously assertion failed.
 ---
  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.
 @@ -539,7 +551,8 @@ _mesa_copy_buffer_subdata(struct gl_context *ctx,
       memcpy(dstPtr, srcPtr, size);

    ctx-Driver.UnmapBuffer(ctx, src);
 -   ctx-Driver.UnmapBuffer(ctx, dst);
 +   if (dst != src)
 +      ctx-Driver.UnmapBuffer(ctx, dst);
  }


Looks good to me.  Though, when srcbuf==dstbuf it wouldn't be too hard
to compute the union region to avoid mapping the whole buffer.
There's some places in the swrast code where we could do that too for
renderbuffers.

Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: Fix the error for glCopyBufferSubData() with a buffer of 0.

On Wed, Jan 25, 2012 at 8:51 PM, Eric Anholt e...@anholt.net wrote:
 The INVALID_ENUM here may have been trying to catch someone passing
 something bogus as the target rather than having a non-buffer bound.
 The extension spec and the GL 3.2 specs doesn't say anything specific
 for error results for either bad target enums or things that aren't
 buffer objects other than 0.  Given that, provide at least correct
 behavior for the specified case.
 ---
  src/mesa/main/bufferobj.c |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] st/mesa: use table-driven approach to exposing extensions for formats (v3)

On Wed, Jan 25, 2012 at 8:22 AM, Marek Olšák mar...@gmail.com wrote:
 The check for ctx-API was unnecessary, because OES extensions are not exposed
 in desktop GL.

 Also require renderbuffer support for ARB_texture_rgb10_a2ui,
 as per the spec.

 Tested by comparing old and new glxinfo with softpipe and r600g.

 v2: fix bugs
 v3: rename need_only_one - need_at_least_one
    rename num_elements - num_mappings
    add comments
    use const when appropriate
 ---

Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: set clamp bit in glGetTexImage for GL_UNSIGNED_NORMALIZED

On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
 Color clamping should be enabled in glGetTexImage if texture dataType is
 GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA

 Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
 https://bugs.freedesktop.org/show_bug.cgi?id=40864

 NOTE: This is a candidate for the 8.0 branch

 Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
 ---
  src/mesa/main/texgetimage.c |    7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
 index 8c85c1e..f89b868 100644
 --- a/src/mesa/main/texgetimage.c
 +++ b/src/mesa/main/texgetimage.c
 @@ -415,7 +415,12 @@ get_tex_rgba(struct gl_context *ctx, GLuint dimensions,
          transferOps |= IMAGE_CLAMP_BIT;
       }
    }
 -
 +   else if ((format == GL_LUMINANCE ||
 +            format == GL_LUMINANCE_ALPHA) 
 +            dataType == GL_UNSIGNED_NORMALIZED) {
 +      transferOps |= IMAGE_CLAMP_BIT;
 +   }
 +
    if (_mesa_is_format_compressed(texImage-TexFormat)) {
       get_tex_rgba_compressed(ctx, dimensions, format, type,
                               pixels, texImage, transferOps);
 --

This looks OK.  However, we need to add more comments here.  I had to
do some digging to recall why luminance and lum/alpha are special.
The reason is if the source image is RGB, the returned luminance is
R+G+B and we need to clamp the sum to [0,1].

Would you please add a comment about that?  Thanks.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] scons: don't add -Wmissing-field-initializers

On Wed, Jan 25, 2012 at 2:34 PM, Jose Fonseca jfons...@vmware.com wrote:
 - Original Message -
 The warning is absolutely useless. It doesn't actually say that there
 are
 uninitialized variables. It points out the fact that there are
 missing
 initializers and that variables are initialized to zero implicitly,
 which is
 exactly what we want and what we commonly make use of.

 The warning has its uses. Imagine a structure is extended, but we forget to 
 add initializer to fields.

  struct bla {
     int foo;
     int boo;
     int doo;
  };

  const bla = {FOO, BOO};

 and 0 is not a valid balue for bla::doo.

 Perhaps this use is infrequent enough to no be worth the warning noise.

 I don't mind either way, and am happy to defer to the majority opinion.

The thing is the number of false positives I was getting with this was
huge and most were just {0} or {{0}}, etc. That outweighs any
usefulness of the warning.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): draw: Only run prepare when state, prim and opt changes

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
 Tested-by: Stéphane Marchesin marc...@chromium.org

 ---

  src/gallium/auxiliary/draw/draw_context.c   |    6 +++
  src/gallium/auxiliary/draw/draw_private.h   |    8 
  src/gallium/auxiliary/draw/draw_pt.c        |   49
  ---
  src/gallium/auxiliary/draw/draw_pt.h        |    2 +-
  src/gallium/auxiliary/draw/draw_pt_vsplit.c |   11 --
  5 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/src/gallium/auxiliary/draw/draw_context.c
 b/src/gallium/auxiliary/draw/draw_context.c
 index 4ce4445..3c0b1aa 100644
 --- a/src/gallium/auxiliary/draw/draw_context.c
 +++ b/src/gallium/auxiliary/draw/draw_context.c
 @@ -355,6 +355,10 @@ draw_set_vertex_elements(struct draw_context
 *draw,
  {
     assert(count = PIPE_MAX_ATTRIBS);

 +   /* We could improve this by only flushing the frontend and the
 fetch part
 +    * of the middle. This would avoid recalculating the emit keys.*/
 +   draw_do_flush( draw, DRAW_FLUSH_STATE_CHANGE );
 +
     memcpy(draw-pt.vertex_element, elements, count *
     sizeof(elements[0]));
     draw-pt.nr_vertex_elements = count;
  }
 @@ -654,6 +658,8 @@ void draw_do_flush( struct draw_context *draw,
 unsigned flags )

        draw_pipeline_flush( draw, flags );

 +      draw_pt_flush( draw, flags );
 +
        draw-flushing = FALSE;
     }
  }
 diff --git a/src/gallium/auxiliary/draw/draw_private.h

[Mesa-dev] [Bug 45277] New: [bisected] Shading not working properly in Heroes of Newerth

https://bugs.freedesktop.org/show_bug.cgi?id=45277

 Bug #: 45277
   Summary: [bisected] Shading not working properly in Heroes of
Newerth
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: dam...@grassart.com


Hi, a recent commit seems to have broken the fog of war shading in Heroes of
Newerth (with my Radeon HD 6850 at least). You can still see the players pop in
and out of the fog, but the entire map is shaded darker where there is no
longer any light/dark distinction between the parts of the map that are visible
and the parts that aren't.

I've bisected the issue and found the first bad commit to be:
bc1c8369384b5e16547c5bf9728aa78f8dfd66cc st/mesa: do vertex and fragment color
clamping in shaders

I've confirmed that building Mesa with the previous commit
(c2e2b58a58880c9b9f189fc154205e99144e9502) does fix the problem.

If you need to test it, the game is a free download from
www.heroesofnewerth.com

-- 
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] Should we fix Unigine apps?

2012-01-26 Thread Lauri Kasanen

Hi list

Just reporting that Unigine folks have already fixed the issue(s):
http://phoronix.com/forums/showthread.php?p=248294#post248294

- Lauri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965/vs: Use the sampler for VS pull constant loading on Ivybridge.

2012-01-26 Thread Eric Anholt

On Thu, 26 Jan 2012 08:32:08 -0800, Kenneth Graunke kenn...@whitecape.org 
wrote:
 Substantially increases performance in GLBenchmark PRO:
 - 320x240   = 3.28x
 - 1920x1080 = 1.47x
 - 2560x1440 = 1.27x
 
 The LD message ignores the sampler unit index and SAMPLER_STATE pointer,
 instead relying on hard-wired default state.  Thus, there's no need to
 worry about running out of sampler units or providing SAMPLER_STATE;
 this small patch should be all that's required.

This looks much nicer than the previous patchset :)

I do wonder about the args to ld, though.  In 4x2 mode, it's u v r
lod.  get_pull_constant_offset is filling .x with the dword offset, and
.yzw are undefined.  Is that what ld wants, or does it make use of v and
r (.y and .z)?


pgpKqhVqj9Ghc.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): 60 new commits

2012-01-26 Thread Kenneth Graunke


On 01/26/2012 11:23 AM, Ian Romanick wrote:

So far, I've only see cases that this series fixes. I have another patch
on top of this (that I'll send out today) that fixes a couple more cases
on i965. I'd like to nominate this entire series for inclusion in 8.0.
If there are no objections, I can cherry pick this Friday morning.
Friday afternoon (pacific time), I'd like to have another RC.

Opinions?


Please do.

___
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 Tue, Jan 10, 2012 at 6:20 PM, Jose Fonseca jfons...@vmware.com wrote:


 - Original Message -
 On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca jfons...@vmware.com
 wrote:
  - Original Message -
  The flag is optional, it doesn't have to implemented by everybody.
  If
  we do the uploads in the state tracker, we will also do any
  required
  data transformation so that drivers don't have to do it at all.
 
  The same can be said for everything.
 
  I don't object adding yet another code path specific to a subset of
  hardware, provided the benefits justify its existence.
 
  But honestly I'm not yet convinced of this, as there was no attempt
  to backup with solid arguments why this matters.
 
  Furthermore this violates one of the principles gallium (and all 3D
  apis) have of unmapping all resources when drawing.

 If my idea violates one principle of all 3D APIs, this violates them
 all:
 http://www.opengl.org/registry/specs/AMD/pinned_memory.txt

 Indeed.

 It allows reading user memory by hardware, and neither the driver nor
 the hardware is notified when the memory contents are changed by the
 user.

 BTW, I don't insist on this. I thought it would be a nice addition
 allowing user buffer uploads to be moved out of (especially radeon)
 drivers. If you really believe it's a bad optimization, feel free to
 revert. WIthout it, things wouldn't change for me at all...

 Fair enough.

 
   It looks to me that state trackers and/or drivers are not
   properly
   using PIPE_USAGE_STREAM flag.  As all cases where
   PIPE_TRANSFER_MAP_PERMANENTLY would be used, the right way to do
   it would be for the state tracker to set PIPE_USAGE_STREAM, the
   pipe driver to recognize PIPE_USAGE_STREAM, and keep the mapping
   permanently internally, making mapping/unmapping of such buffers
   mere no-ops.
 
  We were doing that already and it wasn't good enough. Avoiding
  create+map+unmap+destroy *calls* have brought higher frame rates
  in
  apps with lots of draw operations.
 
  I understand the number map/unmap call is reduced. But how does
  this interface change affect in any way the number of
  create/destroy calls?

 create = get_transfer
 destroy = transfer_destroy

 Ah. BTW, we should probably unify create+map and destroy+unmap to reduce 
 overhead. I would probably helps here.

  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.
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.

Comments welcome.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] swrast: Fix fixed-function fragment processing

2012-01-26 Thread Chad Versace

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 Romanick i...@freedesktop.org
CC: Eric Anholt e...@anholt.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327
Signed-off-by: Chad Versace chad.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 = _swrast_use_fragment_program(ctx);
   const struct gl_fragment_program *fprog
  = ctx-FragmentProgram._Current;
-  if

Re: [Mesa-dev] Mesa (master): 60 new commits

2012-01-26 Thread Eric Anholt

On Thu, 26 Jan 2012 11:23:24 -0800, Ian Romanick i...@freedesktop.org wrote:
 So far, I've only see cases that this series fixes.  I have another 
 patch on top of this (that I'll send out today) that fixes a couple more 
 cases on i965.  I'd like to nominate this entire series for inclusion in 
 8.0.  If there are no objections, I can cherry pick this Friday morning. 
   Friday afternoon (pacific time), I'd like to have another RC.

I'd be in favor as well.  It's a giant pile of code, but I think the
half-done state was worse.


pgpXE8qQeVfEI.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): 60 new commits

On Thu, Jan 26, 2012 at 2:23 PM, Ian Romanick i...@freedesktop.org wrote:
 So far, I've only see cases that this series fixes.  I have another patch on
 top of this (that I'll send out today) that fixes a couple more cases on
 i965.  I'd like to nominate this entire series for inclusion in 8.0.  If
 there are no objections, I can cherry pick this Friday morning.  Friday
 afternoon (pacific time), I'd like to have another RC.

It doesn't matter much to me either way.  Though, if there's any
regressions or surprises, I doubt that I'll have much time to help fix
them.  So hopefully you can cover that.

One other thing: I don't know if anyone has tested the radeon, r200 or
nouveau drivers since the branch was merged to master.  I hope someone
can test those drivers and that any fixes get ported to 8.0 as well.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: set clamp bit in glGetTexImage for GL_UNSIGNED_NORMALIZED


On 01/26/2012 06:40 AM, Brian Paul wrote:

On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogatanuj.pho...@gmail.com  wrote:

Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA

Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
https://bugs.freedesktop.org/show_bug.cgi?id=40864

NOTE: This is a candidate for the 8.0 branch

Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
---
  src/mesa/main/texgetimage.c |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 8c85c1e..f89b868 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -415,7 +415,12 @@ get_tex_rgba(struct gl_context *ctx, GLuint dimensions,
  transferOps |= IMAGE_CLAMP_BIT;
   }
}
-
+   else if ((format == GL_LUMINANCE ||
+format == GL_LUMINANCE_ALPHA)
+dataType == GL_UNSIGNED_NORMALIZED) {
+  transferOps |= IMAGE_CLAMP_BIT;
+   }
+
if (_mesa_is_format_compressed(texImage-TexFormat)) {
   get_tex_rgba_compressed(ctx, dimensions, format, type,
   pixels, texImage, transferOps);
--


This looks OK.  However, we need to add more comments here.  I had to
do some digging to recall why luminance and lum/alpha are special.
The reason is if the source image is RGB, the returned luminance is
R+G+B and we need to clamp the sum to [0,1].


When Anuj and I discussed this patch, I had another concern, but I'm not 
sure it matters.  If dataType is GL_SIGNED_NORMALIZED, it seems like the 
value should clamp to [-1,1].  We don't currently have a way to do that. 
 Does that seem right to you?



Would you please add a comment about that?  Thanks.


Good idea.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): 60 new commits


On 01/26/2012 01:53 PM, Brian Paul wrote:

On Thu, Jan 26, 2012 at 2:23 PM, Ian Romanicki...@freedesktop.org  wrote:

So far, I've only see cases that this series fixes.  I have another patch on
top of this (that I'll send out today) that fixes a couple more cases on
i965.  I'd like to nominate this entire series for inclusion in 8.0.  If
there are no objections, I can cherry pick this Friday morning.  Friday
afternoon (pacific time), I'd like to have another RC.


It doesn't matter much to me either way.  Though, if there's any
regressions or surprises, I doubt that I'll have much time to help fix
them.  So hopefully you can cover that.

One other thing: I don't know if anyone has tested the radeon, r200 or
nouveau drivers since the branch was merged to master.  I hope someone
can test those drivers and that any fixes get ported to 8.0 as well.


I can check r200, but I don't think I have any other relevant hardware 
in my boneyard anymore.

___
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 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.



@@ -539,7 +551,8 @@ _mesa_copy_buffer_subdata(struct gl_context *ctx,
memcpy(dstPtr, srcPtr, size);

 ctx-Driver.UnmapBuffer(ctx, src);
-   ctx-Driver.UnmapBuffer(ctx, dst);
+   if (dst != src)
+  ctx-Driver.UnmapBuffer(ctx, dst);
  }




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: Fix the error for glCopyBufferSubData() with a buffer of 0.


On 01/25/2012 05:51 PM, Eric Anholt wrote:

The INVALID_ENUM here may have been trying to catch someone passing
something bogus as the target rather than having a non-buffer bound.
The extension spec and the GL 3.2 specs doesn't say anything specific
for error results for either bad target enums or things that aren't
buffer objects other than 0.  Given that, provide at least correct
behavior for the specified case.


Page 16 (page 32 of the PDF) of the OpenGL 3.0 spec says:

If a command that requires an enumerated value is passed a
symbolic constant that is not one of those specified as
allowable for that command, the error INVALID ENUM is
generated. This is the case even if the argument is a
pointer to a symbolic constant, if the value pointed to is
not allowable for the given command.


---
  src/mesa/main/bufferobj.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index e4f964f..471442c 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1311,14 +1311,14 @@ _mesa_CopyBufferSubData(GLenum readTarget, GLenum 
writeTarget,

 src = get_buffer(ctx, readTarget);


I think putting

   if (src == NULL) {
  _mesa_error(ctx, GL_INVALID_ENUM,
  glCopyBuffserSubData(readTarget = 0x%x),
  readTarget);
  return;
   }

and a similar block after the next get_buffer maintains all the correct 
error generation behavior.



 if (!_mesa_is_bufferobj(src)) {
-  _mesa_error(ctx, GL_INVALID_ENUM,
+  _mesa_error(ctx, GL_INVALID_OPERATION,
glCopyBuffserSubData(readTarget = 0x%x), readTarget);
return;
 }

 dst = get_buffer(ctx, writeTarget);
 if (!_mesa_is_bufferobj(dst)) {
-  _mesa_error(ctx, GL_INVALID_ENUM,
+  _mesa_error(ctx, GL_INVALID_OPERATION,
glCopyBuffserSubData(writeTarget = 0x%x), writeTarget);
return;
 }


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: set clamp bit in glGetTexImage for GL_UNSIGNED_NORMALIZED

On Thu, Jan 26, 2012 at 4:55 PM, Ian Romanick i...@freedesktop.org wrote:
 On 01/26/2012 06:40 AM, Brian Paul wrote:

 On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogatanuj.pho...@gmail.com
  wrote:

 Color clamping should be enabled in glGetTexImage if texture dataType is
 GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA

 Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
 https://bugs.freedesktop.org/show_bug.cgi?id=40864

 NOTE: This is a candidate for the 8.0 branch

 Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
 ---
  src/mesa/main/texgetimage.c |    7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
 index 8c85c1e..f89b868 100644
 --- a/src/mesa/main/texgetimage.c
 +++ b/src/mesa/main/texgetimage.c
 @@ -415,7 +415,12 @@ get_tex_rgba(struct gl_context *ctx, GLuint
 dimensions,
          transferOps |= IMAGE_CLAMP_BIT;
       }
    }
 -
 +   else if ((format == GL_LUMINANCE ||
 +            format == GL_LUMINANCE_ALPHA)
 +            dataType == GL_UNSIGNED_NORMALIZED) {
 +      transferOps |= IMAGE_CLAMP_BIT;
 +   }
 +
    if (_mesa_is_format_compressed(texImage-TexFormat)) {
       get_tex_rgba_compressed(ctx, dimensions, format, type,
                               pixels, texImage, transferOps);
 --


 This looks OK.  However, we need to add more comments here.  I had to
 do some digging to recall why luminance and lum/alpha are special.
 The reason is if the source image is RGB, the returned luminance is
 R+G+B and we need to clamp the sum to [0,1].


 When Anuj and I discussed this patch, I had another concern, but I'm not
 sure it matters.  If dataType is GL_SIGNED_NORMALIZED, it seems like the
 value should clamp to [-1,1].  We don't currently have a way to do that.
  Does that seem right to you?

I would expect so too.  I'll put it on my to-do list, but it might be a while.

-Brian
___
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/25/2012 02:56 PM, Marek Olšák wrote:

Hi Eric,

I don't like this, because I don't have drirc in my system. Obviously


In addition to what Eric and Ken said, each user can have their own 
~/.drirc or can set the options via environment variables.


force_glsl_extensions_warn=true ./some_gl_application


Canonical decided not to include it and that also means some of my
users don't have it. Please can we add workarounds directly in the
code and on a per-app basis? Something like:

if (is_linked(libUnigine_x86.so) ||
 is_linked(libUnigine_x64.so))
apply_workarounds_for_unigine();


Putting different behavior based on hardcoded application names was such 
a good idea in the past. :)


http://www.nvnews.net/vbulletin/archive/index.php/t-11917.html

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


Marek

On Wed, Jan 25, 2012 at 11:29 PM, Eric Anholte...@anholt.net  wrote:

Specifially, this being present works around a bug in Unigine
Sanctuary on i965 which previously resulted in bad rendering.
---
  configure.ac  |1 +
  src/mesa/drivers/dri/Makefile.am  |2 +-
  src/mesa/drivers/dri/common/Makefile.am   |   22 ++
  src/mesa/drivers/dri/common/drirc |7 +++
  src/mesa/drivers/dri/common/xmlpool/options.h |   12 ++--
  5 files changed, 37 insertions(+), 7 deletions(-)
  create mode 100644 src/mesa/drivers/dri/common/Makefile.am
  create mode 100644 src/mesa/drivers/dri/common/drirc

diff --git a/configure.ac b/configure.ac
index 2472cc1..b3cdf13 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1948,6 +1948,7 @@ AC_CONFIG_FILES([configs/autoconf
src/gbm/main/gbm.pc
src/mesa/drivers/dri/dri.pc
src/mesa/drivers/dri/Makefile
+   src/mesa/drivers/dri/common/Makefile
src/mesa/drivers/dri/i915/Makefile
src/mesa/drivers/dri/i965/Makefile
src/mesa/drivers/dri/nouveau/Makefile
diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/Makefile.am
index 3722082..8dea0ac 100644
--- a/src/mesa/drivers/dri/Makefile.am
+++ b/src/mesa/drivers/dri/Makefile.am
@@ -1,4 +1,4 @@
-SUBDIRS=
+SUBDIRS=common

  if HAVE_I915_DRI
  SUBDIRS+=i915
diff --git a/src/mesa/drivers/dri/common/Makefile.am 
b/src/mesa/drivers/dri/common/Makefile.am
new file mode 100644
index 000..3b5324d
--- /dev/null
+++ b/src/mesa/drivers/dri/common/Makefile.am
@@ -0,0 +1,22 @@
+# Copyright © 2012 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+
+sysconf_DATA = drirc
diff --git a/src/mesa/drivers/dri/common/drirc 
b/src/mesa/drivers/dri/common/drirc
new file mode 100644
index 000..7abc646
--- /dev/null
+++ b/src/mesa/drivers/dri/common/drirc
@@ -0,0 +1,7 @@
+driconf
+device screen=0 driver=i965
+application name=Sanctuary
+option name=force_glsl_extensions_warn value=true /
+/application
+/device
+/driconf
diff --git a/src/mesa/drivers/dri/common/xmlpool/options.h 
b/src/mesa/drivers/dri/common/xmlpool/options.h
index a5890af..75c887e 100644
--- a/src/mesa/drivers/dri/common/xmlpool/options.h
+++ b/src/mesa/drivers/dri/common/xmlpool/options.h
@@ -629,10 +629,10 @@ DRI_CONF_OPT_END

  #define DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN(def) \
  DRI_CONF_OPT_BEGIN(force_glsl_extensions_warn,bool,def) \
-DRI_CONF_DESC(en,Force GLSL extension default behavior to \warn\) \
-DRI_CONF_DESC(de,Force GLSL extension default behavior to \warn\) \
-DRI_CONF_DESC(es,Force GLSL extension default behavior to \warn\) \
-DRI_CONF_DESC(nl,Force GLSL extension default behavior to \warn\) \
-DRI_CONF_DESC(fr,Force GLSL extension default behavior to \warn\) \
-

Re: [Mesa-dev] [PATCH 2/4] mesa: Add a flag for forcing all GLSL extensions to warn.


On 01/25/2012 02:29 PM, Eric Anholt wrote:

---
  src/glsl/glsl_parser_extras.cpp |3 +++
  src/mesa/main/mtypes.h  |6 ++
  2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 0b53232..7f8d47c 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -114,6 +114,9 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
gl_context *ctx,
 }

 this-supported_version_string = supported;
+
+   if (ctx-Const.ForceGLSLExtensionsWarn)
+  _mesa_glsl_process_extension(all, NULL, warn, NULL, this);


For what it's worth, I don't think we correctly generate these warnings. :(


  }

  const char *
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a2b01d0..99dcb38 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2772,6 +2772,12 @@ struct gl_constants
 GLuint GLSLVersion;  /**  GLSL version supported (ex: 120 = 1.20) */

 /**
+* Changes default GLSL extension behavior from error to warn.  It's out
+* of spec, but it can make some apps work that otherwise wouldn't.
+*/
+   GLboolean ForceGLSLExtensionsWarn;
+
+   /**
  * Does the driver support real 32-bit integers?  (Otherwise, integers are
  * simulated via floats.)
  */


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: set clamp bit in glGetTexImage for GL_UNSIGNED_NORMALIZED

2012-01-26 Thread Anuj Phogat

On Thu, Jan 26, 2012 at 2:56 PM, Brian Paul brian.e.p...@gmail.com wrote:

 On Thu, Jan 26, 2012 at 4:55 PM, Ian Romanick i...@freedesktop.org wrote:
  On 01/26/2012 06:40 AM, Brian Paul wrote:
 
  On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogatanuj.pho...@gmail.com
   wrote:
 
  Color clamping should be enabled in glGetTexImage if texture dataType
 is
  GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA
 
  Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
  https://bugs.freedesktop.org/show_bug.cgi?id=40864
 
  NOTE: This is a candidate for the 8.0 branch
 
  Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
  ---
   src/mesa/main/texgetimage.c |7 ++-
   1 files changed, 6 insertions(+), 1 deletions(-)
 
  diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
  index 8c85c1e..f89b868 100644
  --- a/src/mesa/main/texgetimage.c
  +++ b/src/mesa/main/texgetimage.c
  @@ -415,7 +415,12 @@ get_tex_rgba(struct gl_context *ctx, GLuint
  dimensions,
   transferOps |= IMAGE_CLAMP_BIT;
}
 }
  -
  +   else if ((format == GL_LUMINANCE ||
  +format == GL_LUMINANCE_ALPHA)
  +dataType == GL_UNSIGNED_NORMALIZED) {
  +  transferOps |= IMAGE_CLAMP_BIT;
  +   }
  +
 if (_mesa_is_format_compressed(texImage-TexFormat)) {
get_tex_rgba_compressed(ctx, dimensions, format, type,
pixels, texImage, transferOps);
  --
 
 
  This looks OK.  However, we need to add more comments here.  I had to
  do some digging to recall why luminance and lum/alpha are special.
  The reason is if the source image is RGB, the returned luminance is
  R+G+B and we need to clamp the sum to [0,1].
 
 
  When Anuj and I discussed this patch, I had another concern, but I'm not
  sure it matters.  If dataType is GL_SIGNED_NORMALIZED, it seems like the
  value should clamp to [-1,1].  We don't currently have a way to do that.
   Does that seem right to you?

 I would expect so too.  I'll put it on my to-do list, but it might be a
 while.

I can add clamp [-1, 1] . I'll send out a separate patch for that.
___
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 12:26 AM, Ian Romanick i...@freedesktop.org wrote:
On 01/25/2012 02:56 PM, Marek Olšák wrote:

Hi Eric,

I don't like this, because I don't have drirc in my system. Obviously

In addition to what Eric and Ken said, each user can have their own ~/.drirc
or can set the options via environment variables.

force_glsl_extensions_warn=true ./some_gl_application

Canonical decided not to include it and that also means some of my
users don't have it. Please can we add workarounds directly in the
code and on a per-app basis? Something like:

if (is_linked(libUnigine_x86.so) ||
is_linked(libUnigine_x64.so))
apply_workarounds_for_unigine();

Putting different behavior based on hardcoded application names was such a
good idea in the past. :)

http://www.nvnews.net/vbulletin/archive/index.php/t-11917.html

I didn't read the whole thread, but I don't think cheating in
benchmarks is any relevant to this. It's not like we're breaking what
is allowed to do by the spec, we only extend it.

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.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 44928] i965 build error on recent git

https://bugs.freedesktop.org/show_bug.cgi?id=44928

Eric Anholt e...@anholt.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Caleb Callaway enlightened.des...@gmail.com 2012-01-24 
22:39:26 PST ---
First patch works for me...the second patch doesn't :/

--- Comment #12 from Eric Anholt e...@anholt.net 2012-01-26 16:18:29 PST ---
commit c88503944234421ecb617001aad305ff3b1b83d2
Author: Eric Anholt e...@anholt.net
Date:   Thu Jan 26 16:11:12 2012 -0800

i965: Drop the missing symbols link test.

This was horribly broken and has cost everyone more time than we were
ever going to save using it.  It might have been fixable, but the
problem it was originally trying to solve can be better solved with
-Werror=missing-prototypes and -Werror=implicit-function-declaration.

Also, it was always producing a big scary warning about how the link
test was non-portable.

Reviewed-by: Matt Turner matts...@gmail.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44928

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list 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 supported texture size returned by glGetIntegrv

2012-01-26 Thread Anuj Phogat

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] [Bug 38970] [bisected]piglit glx/glx-pixmap-multi failed

https://bugs.freedesktop.org/show_bug.cgi?id=38970

--- Comment #16 from Ian Romanick i...@freedesktop.org 2012-01-26 17:22:05 
PST ---
The test fails because the second glXCreateGLXPixmap or glXCreatePixmap tries
to add the same drawable ID to priv-drawHash.  The call fails because the key
already exists.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list 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

2012-01-26 Thread Eric Anholt

On Thu, 26 Jan 2012 12:46:03 -0800, Chad Versace chad.vers...@linux.intel.com 
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.

I'd say As a consequence, the current gl_fragment_program exists but is
invalid because its instructions were never filled in.  Avoid using the
empty program when possible by checking that the fragment shader is not
a translation of the current fixed function state.  This should also
result in some performance improvement by taking advantage of custom
fixed function paths where previously the Mesa IR interpreter was used.

I think it makes sense to me how the _swrast_update_fragment_program
hunk is needed.  So:

Reviewed-by: Eric Anholt e...@anholt.net


pgpPA7rZNo07b.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: Don't try intel_miptree_map_blit if a region is already mapped

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
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index eae79c1..ae354cb 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -1055,7 +1055,8 @@ intel_miptree_map(struct intel_context *intel,
} else if (intel-gen = 6 
  !(mode  GL_MAP_WRITE_BIT) 
  !mt-compressed 
- mt-region-tiling == I915_TILING_X) {
+ mt-region-tiling == I915_TILING_X
+  intel-num_mapped_regions == 0) {
   intel_miptree_map_blit(intel, mt, map, level, slice);
} else {
   intel_miptree_map_gtt(intel, mt, map, level, slice);
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 44039] Mesa 7.12-devel implementation error: unexpected format 0x822e in _mesa_choose_tex_format()

https://bugs.freedesktop.org/show_bug.cgi?id=44039

Ian Romanick i...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Ian Romanick i...@freedesktop.org 2012-01-26 18:33:12 PST 
---
Closing as FIXED.  Please reopen if the problem persists.

-- 
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] intel: Don't try intel_miptree_map_blit if a region is already mapped

2012-01-26 Thread Chad Versace

On 01/26/2012 06:29 PM, Ian Romanick 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
 ---
  src/mesa/drivers/dri/intel/intel_mipmap_tree.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
 b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
 index eae79c1..ae354cb 100644
 --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
 +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
 @@ -1055,7 +1055,8 @@ intel_miptree_map(struct intel_context *intel,
 } else if (intel-gen = 6 
 !(mode  GL_MAP_WRITE_BIT) 
 !mt-compressed 
 -   mt-region-tiling == I915_TILING_X) {
 +   mt-region-tiling == I915_TILING_X
 +intel-num_mapped_regions == 0) {
intel_miptree_map_blit(intel, mt, map, level, slice);
 } else {
intel_miptree_map_gtt(intel, mt, map, level, slice);


I'm surprised that assertion did not happen more frequently.

Reviewed-by: 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 05/14] mesa: rewrite, simplify some of the logic in _mesa_format_matches_format_and_type()

In preparation for adding GL_PACK/UNPACK_SWAP_BYTES support.
---
 src/mesa/main/formats.c |   37 -
 1 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index d11b167..834d4c8 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2543,21 +2543,40 @@ _mesa_format_matches_format_and_type(gl_format 
gl_format,
   return GL_FALSE;
 
case MESA_FORMAT_RGBA:
-  return ((format == GL_RGBA  (type == GL_UNSIGNED_INT_8_8_8_8 ||
-(type == GL_UNSIGNED_BYTE  
!littleEndian))) ||
- (format == GL_ABGR_EXT  (type == GL_UNSIGNED_INT_8_8_8_8_REV ||
-(type == GL_UNSIGNED_BYTE  
littleEndian;
+  if (format == GL_RGBA  type == GL_UNSIGNED_INT_8_8_8_8)
+ 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)
+ return GL_TRUE;
+
+  if (format == GL_ABGR_EXT  type == GL_UNSIGNED_BYTE  littleEndian)
+ return GL_TRUE;
+
+  return GL_FALSE;
 
case MESA_FORMAT_RGBA_REV:
-  return ((format == GL_RGBA  type == GL_UNSIGNED_INT_8_8_8_8_REV));
+  return format == GL_RGBA  type == GL_UNSIGNED_INT_8_8_8_8_REV;
 
case MESA_FORMAT_ARGB:
-  return ((format == GL_BGRA  (type == GL_UNSIGNED_INT_8_8_8_8_REV ||
-(type == GL_UNSIGNED_BYTE  
littleEndian;
+  if (format == GL_BGRA  type == GL_UNSIGNED_INT_8_8_8_8_REV)
+ return GL_TRUE;
+
+  if (format == GL_BGRA  type == GL_UNSIGNED_BYTE  littleEndian)
+ return GL_TRUE;
+
+  return GL_FALSE;
 
case MESA_FORMAT_ARGB_REV:
-  return ((format == GL_BGRA  (type == GL_UNSIGNED_INT_8_8_8_8 ||
-(type == GL_UNSIGNED_BYTE  
!littleEndian;
+  if (format == GL_BGRA  type == GL_UNSIGNED_INT_8_8_8_8)
+ return GL_TRUE;
+
+  if (format == GL_BGRA  type == GL_UNSIGNED_BYTE  !littleEndian)
+ return GL_TRUE;
+
+  return GL_FALSE;
 
case MESA_FORMAT_RGBX:
case MESA_FORMAT_RGBX_REV:
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 06/14] mesa: added swapBytes parameter to _mesa_format_matches_format_and_type()

Not actually used yet though.
---
 src/mesa/main/formats.c |   10 ++
 src/mesa/main/formats.h |3 ++-
 src/mesa/main/readpix.c |3 ++-
 src/mesa/swrast/s_drawpix.c |3 ++-
 4 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index 834d4c8..f352395 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2516,14 +2516,16 @@ _mesa_format_to_type_and_comps(gl_format format,
 /**
  * Check if a gl_format exactly matches a GL formaat/type combination
  * such that we can use memcpy() from one to the other.
- *
- * Note: this matching assumes that GL_PACK/UNPACK_SWAP_BYTES is unset.
- *
+ * \param gl_format  a MESA_FORMAT_x value
+ * \param format  the user-specified image format
+ * \param type  the user-specified image datatype
+ * \param swapBytes  typically the current pixel pack/unpack byteswap state
  * \return GL_TRUE if the formats match, GL_FALSE otherwise.
  */
 GLboolean
 _mesa_format_matches_format_and_type(gl_format gl_format,
-GLenum format, GLenum type)
+GLenum format, GLenum type,
+ GLboolean swapBytes)
 {
const GLboolean littleEndian = _mesa_little_endian();
 
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 9609343..3a694a8 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -343,7 +343,8 @@ _mesa_format_num_components(gl_format format);
 
 GLboolean
 _mesa_format_matches_format_and_type(gl_format gl_format,
-GLenum format, GLenum type);
+GLenum format, GLenum type,
+ GLboolean swapBytes);
 
 
 #ifdef __cplusplus
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 84b5224..71de0b3 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -209,7 +209,8 @@ fast_read_rgba_pixels_memcpy( struct gl_context *ctx,
GLubyte *dst, *map;
int dstStride, stride, j, texelBytes;
 
-   if (!_mesa_format_matches_format_and_type(rb-Format, format, type))
+   if (!_mesa_format_matches_format_and_type(rb-Format, format, type,
+ ctx-Pack.SwapBytes))
   return GL_FALSE;
 
/* check for things we can't handle here */
diff --git a/src/mesa/swrast/s_drawpix.c b/src/mesa/swrast/s_drawpix.c
index c5466dd..c19808b 100644
--- a/src/mesa/swrast/s_drawpix.c
+++ b/src/mesa/swrast/s_drawpix.c
@@ -239,7 +239,8 @@ fast_draw_rgba_pixels(struct gl_context *ctx, GLint x, 
GLint y,
   return GL_TRUE;
}
 
-   if (_mesa_format_matches_format_and_type(rb-Format, format, type)) {
+   if (_mesa_format_matches_format_and_type(rb-Format, format, type,
+ctx-Unpack.SwapBytes)) {
   fast_draw_generic_pixels(ctx, rb, x, y, width, height,
format, type, unpack, pixels);
   return GL_TRUE;
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 07/14] mesa: use swapBytes parameter in _mesa_format_matches_format_and_type()

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 
+ !swapBytes;
+
case MESA_FORMAT_ARGB_REV:
   return GL_FALSE;
 
case MESA_FORMAT_RGBA5551:
-  return format == GL_RGBA  type == GL_UNSIGNED_SHORT_5_5_5_1;
+  return format == GL_RGBA  type == GL_UNSIGNED_SHORT_5_5_5_1 
+ !swapBytes;
 
case MESA_FORMAT_ARGB1555:
-  return format == GL_BGRA  type == GL_UNSIGNED_SHORT_1_5_5_5_REV;
+  return format == GL_BGRA  type == GL_UNSIGNED_SHORT_1_5_5_5_REV 
+ !swapBytes;
+
case MESA_FORMAT_ARGB1555_REV:
   return GL_FALSE;
 
@@ -2624,7 +2667,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
   return GL_FALSE;
 
case MESA_FORMAT_AL1616:
-  return format == GL_LUMINANCE_ALPHA  type == GL_UNSIGNED_SHORT  
littleEndian;
+  return format == GL_LUMINANCE_ALPHA  type == GL_UNSIGNED_SHORT  
littleEndian  !swapBytes;
case MESA_FORMAT_AL1616_REV:
   return GL_FALSE;
 
@@ -2634,15 +2677,18 @@ _mesa_format_matches_format_and_type(gl_format 
gl_format,
case MESA_FORMAT_A8:
   return format == GL_ALPHA  type ==

[Mesa-dev] [PATCH 08/14] mesa: implement more cases in _mesa_format_matches_format_and_type()

---
 src/mesa/main/formats.c |   24 ++--
 1 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index a52b38b..cecb70c 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2733,7 +2733,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
  !swapBytes;
 
case MESA_FORMAT_S8:
-  return GL_FALSE;
+  return format == GL_STENCIL_INDEX  type == GL_UNSIGNED_BYTE;
 
case MESA_FORMAT_SRGB8:
case MESA_FORMAT_SRGBA8:
@@ -2859,8 +2859,26 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
case MESA_FORMAT_SIGNED_R8:
case MESA_FORMAT_SIGNED_RG88_REV:
case MESA_FORMAT_SIGNED_RGBX:
+  return GL_FALSE;
+
case MESA_FORMAT_SIGNED_RGBA:
+  if (format == GL_RGBA  type == GL_BYTE  !littleEndian)
+ return GL_TRUE;
+
+  if (format == GL_ABGR_EXT  type == GL_BYTE  littleEndian)
+ return GL_TRUE;
+
+  return GL_FALSE;
+
case MESA_FORMAT_SIGNED_RGBA_REV:
+  if (format == GL_RGBA  type == GL_BYTE  littleEndian)
+ return GL_TRUE;
+
+  if (format == GL_ABGR_EXT  type == GL_BYTE  !littleEndian)
+ return GL_TRUE;
+
+  return GL_FALSE;
+
case MESA_FORMAT_SIGNED_R16:
case MESA_FORMAT_SIGNED_GR1616:
case MESA_FORMAT_SIGNED_RGB_16:
@@ -2896,7 +2914,9 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
   return GL_FALSE;
 
case MESA_FORMAT_ARGB2101010_UINT:
-  return GL_FALSE;
+  return (format == GL_BGRA_INTEGER_EXT 
+  type == GL_UNSIGNED_INT_2_10_10_10_REV 
+  !swapBytes);
 
case MESA_FORMAT_RGB9_E5_FLOAT:
   return format == GL_RGB  type == GL_UNSIGNED_INT_5_9_9_9_REV 
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 09/14] mesa: use _mesa_format_matches_format_and_type() in texstore code

This simplifies the code quite a bit, consolidates some cases and
possibly catches more cases for the memcpy path.

More such changes will follow.  Do just a few at a time to help bisect
any possible regressions.
---
 src/mesa/main/texstore.c |   48 +++--
 1 files changed, 4 insertions(+), 44 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 600dab3..a3f311a 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1243,30 +1243,9 @@ _mesa_texstore_rgba(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 4);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-  (dstFormat == MESA_FORMAT_RGBA ||
-   dstFormat == MESA_FORMAT_RGBX) 
-   baseInternalFormat == GL_RGBA 
-  ((srcFormat == GL_RGBA  srcType == GL_UNSIGNED_INT_8_8_8_8) ||
-   (srcFormat == GL_RGBA  srcType == GL_UNSIGNED_BYTE  !littleEndian) 
||
-   (srcFormat == GL_ABGR_EXT  srcType == GL_UNSIGNED_INT_8_8_8_8_REV) ||
-   (srcFormat == GL_ABGR_EXT  srcType == GL_UNSIGNED_BYTE  
littleEndian))) {
-   /* simple memcpy path */
-  memcpy_texture(ctx, dims,
- dstFormat,
- dstRowStride, dstSlices,
- srcWidth, srcHeight, srcDepth, srcFormat, srcType,
- srcAddr, srcPacking);
-   }
-   else if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-  (dstFormat == MESA_FORMAT_RGBA_REV ||
-   dstFormat == MESA_FORMAT_RGBX_REV) 
baseInternalFormat == GL_RGBA 
-  ((srcFormat == GL_RGBA  srcType == GL_UNSIGNED_INT_8_8_8_8_REV) ||
-   (srcFormat == GL_RGBA  srcType == GL_UNSIGNED_BYTE  littleEndian) ||
-   (srcFormat == GL_ABGR_EXT  srcType == GL_UNSIGNED_INT_8_8_8_8) ||
-   (srcFormat == GL_ABGR_EXT  srcType == GL_UNSIGNED_BYTE  
!littleEndian))) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -1367,28 +1346,9 @@ _mesa_texstore_argb(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 4);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   (dstFormat == MESA_FORMAT_ARGB ||
-dstFormat == MESA_FORMAT_XRGB) 
baseInternalFormat == GL_RGBA 
-   srcFormat == GL_BGRA 
-   ((srcType == GL_UNSIGNED_BYTE  littleEndian) ||
-srcType == GL_UNSIGNED_INT_8_8_8_8_REV)) {
-  /* simple memcpy path (little endian) */
-  memcpy_texture(ctx, dims,
- dstFormat,
- dstRowStride, dstSlices,
- srcWidth, srcHeight, srcDepth, srcFormat, srcType,
- srcAddr, srcPacking);
-   }
-   else if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   (dstFormat == MESA_FORMAT_ARGB_REV ||
-dstFormat == MESA_FORMAT_XRGB_REV) 
-   baseInternalFormat == GL_RGBA 
-   srcFormat == GL_BGRA 
-   ((srcType == GL_UNSIGNED_BYTE  !littleEndian) ||
-srcType == GL_UNSIGNED_INT_8_8_8_8)) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path (big endian) */
   memcpy_texture(ctx, dims,
  dstFormat,
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 10/14] mesa: more use of _mesa_format_matches_format_and_type() in texstore code

For rgb565, argb, rgb888, argb functions.
---
 src/mesa/main/texstore.c |   26 --
 1 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index a3f311a..ef8d097 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1139,11 +1139,9 @@ _mesa_texstore_rgb565(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 2);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_RGB565 
baseInternalFormat == GL_RGB 
-   srcFormat == GL_RGB 
-   srcType == GL_UNSIGNED_SHORT_5_6_5) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -1513,18 +1511,15 @@ _mesa_texstore_argb(TEXSTORE_PARAMS)
 static GLboolean
 _mesa_texstore_rgb888(TEXSTORE_PARAMS)
 {
-   const GLboolean littleEndian = _mesa_little_endian();
const GLenum baseFormat = _mesa_get_format_base_format(dstFormat);
 
ASSERT(dstFormat == MESA_FORMAT_RGB888);
ASSERT(_mesa_get_format_bytes(dstFormat) == 3);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
baseInternalFormat == GL_RGB 
-   srcFormat == GL_BGR 
-   srcType == GL_UNSIGNED_BYTE 
-   littleEndian) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -1630,18 +1625,15 @@ _mesa_texstore_rgb888(TEXSTORE_PARAMS)
 static GLboolean
 _mesa_texstore_bgr888(TEXSTORE_PARAMS)
 {
-   const GLboolean littleEndian = _mesa_little_endian();
const GLenum baseFormat = _mesa_get_format_base_format(dstFormat);
 
ASSERT(dstFormat == MESA_FORMAT_BGR888);
ASSERT(_mesa_get_format_bytes(dstFormat) == 3);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
baseInternalFormat == GL_RGB 
-   srcFormat == GL_RGB 
-   srcType == GL_UNSIGNED_BYTE 
-   littleEndian) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -1735,11 +1727,9 @@ _mesa_texstore_argb(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 2);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_ARGB 
baseInternalFormat == GL_RGBA 
-   srcFormat == GL_BGRA 
-   srcType == GL_UNSIGNED_SHORT_4_4_4_4_REV) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 11/14] mesa: more use of _mesa_format_matches_format_and_type() in texstore code

For rgba5551, argb1555, argb2101010 formats.
---
 src/mesa/main/texstore.c |   20 +++-
 1 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index ef8d097..3bfea8c 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1788,11 +1788,9 @@ _mesa_texstore_rgba5551(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 2);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_RGBA5551 
baseInternalFormat == GL_RGBA 
-   srcFormat == GL_RGBA 
-   srcType == GL_UNSIGNED_SHORT_5_5_5_1) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -1841,11 +1839,9 @@ _mesa_texstore_argb1555(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 2);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_ARGB1555 
baseInternalFormat == GL_RGBA 
-   srcFormat == GL_BGRA 
-   srcType == GL_UNSIGNED_SHORT_1_5_5_5_REV) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -1905,11 +1901,9 @@ _mesa_texstore_argb2101010(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 4);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_ARGB2101010 
-   srcFormat == GL_BGRA 
-   srcType == GL_UNSIGNED_INT_2_10_10_10_REV 
-   baseInternalFormat == GL_RGBA) {
+   baseInternalFormat == GL_RGBA 
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 12/14] mesa: more use of _mesa_format_matches_format_and_type() in texstore code

For rgb332, signed rgba, signed rgba888_rev functions.
---
 src/mesa/main/texstore.c |   23 ---
 1 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 3bfea8c..9a12cc1 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -2402,9 +2402,9 @@ _mesa_texstore_rgb332(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 1);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
baseInternalFormat == GL_RGB 
-   srcFormat == GL_RGB  srcType == GL_UNSIGNED_BYTE_3_3_2) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -2942,11 +2942,9 @@ _mesa_texstore_signed_rgba(TEXSTORE_PARAMS)
ASSERT(_mesa_get_format_bytes(dstFormat) == 4);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_SIGNED_RGBA 
baseInternalFormat == GL_RGBA 
-  ((srcFormat == GL_RGBA  srcType == GL_BYTE  !littleEndian) ||
-   (srcFormat == GL_ABGR_EXT  srcType == GL_BYTE  littleEndian))) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
/* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -2954,19 +2952,6 @@ _mesa_texstore_signed_rgba(TEXSTORE_PARAMS)
  srcWidth, srcHeight, srcDepth, srcFormat, srcType,
  srcAddr, srcPacking);
}
-   else if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_SIGNED_RGBA_REV 
-   baseInternalFormat == GL_RGBA 
-  ((srcFormat == GL_RGBA  srcType == GL_BYTE  littleEndian) ||
-   (srcFormat == GL_ABGR_EXT  srcType == GL_BYTE  !littleEndian))) {
-  /* simple memcpy path */
-  memcpy_texture(ctx, dims,
- dstFormat,
- dstRowStride, dstSlices,
- srcWidth, srcHeight, srcDepth, srcFormat, srcType,
- srcAddr, srcPacking);
-   }
else {
   /* general path */
   const GLfloat *tempImage = _mesa_make_temp_float_image(ctx, dims,
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 13/14] mesa: more use of _mesa_format_matches_format_and_type() in texstore code

For rgb9_e5, r11_g11_b10f, argb2101010_uint functions.
---
 src/mesa/main/texstore.c |   19 +++
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 9a12cc1..55156e7 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -2934,7 +2934,6 @@ _mesa_texstore_signed_rgbx(TEXSTORE_PARAMS)
 static GLboolean
 _mesa_texstore_signed_rgba(TEXSTORE_PARAMS)
 {
-   const GLboolean littleEndian = _mesa_little_endian();
const GLenum baseFormat = _mesa_get_format_base_format(dstFormat);
 
ASSERT(dstFormat == MESA_FORMAT_SIGNED_RGBA ||
@@ -3888,9 +3887,8 @@ _mesa_texstore_rgb9_e5(TEXSTORE_PARAMS)
ASSERT(baseInternalFormat == GL_RGB);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   srcFormat == GL_RGB 
-   srcType == GL_UNSIGNED_INT_5_9_9_9_REV) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -3937,9 +3935,8 @@ _mesa_texstore_r11_g11_b10f(TEXSTORE_PARAMS)
ASSERT(baseInternalFormat == GL_RGB);
 
if (!ctx-_ImageTransferState 
-   !srcPacking-SwapBytes 
-   srcFormat == GL_RGB 
-   srcType == GL_UNSIGNED_INT_10F_11F_11F_REV) {
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
@@ -4048,11 +4045,9 @@ _mesa_texstore_argb2101010_uint(TEXSTORE_PARAMS)
ASSERT(dstFormat == MESA_FORMAT_ARGB2101010_UINT);
ASSERT(_mesa_get_format_bytes(dstFormat) == 4);
 
-   if (!srcPacking-SwapBytes 
-   dstFormat == MESA_FORMAT_ARGB2101010_UINT 
-   srcFormat == GL_BGRA_INTEGER_EXT 
-   srcType == GL_UNSIGNED_INT_2_10_10_10_REV 
-   baseInternalFormat == GL_RGBA) {
+   if (baseInternalFormat == GL_RGBA 
+   _mesa_format_matches_format_and_type(dstFormat, srcFormat, srcType,
+srcPacking-SwapBytes)) {
   /* simple memcpy path */
   memcpy_texture(ctx, dims,
  dstFormat,
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 14/14] mesa: remove byteswap check in fast_read_rgba_pixels_memcpy()

It's handled by _mesa_format_matches_format_and_type() now.
---
 src/mesa/main/readpix.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 71de0b3..908a55e 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -213,11 +213,6 @@ fast_read_rgba_pixels_memcpy( struct gl_context *ctx,
  ctx-Pack.SwapBytes))
   return GL_FALSE;
 
-   /* check for things we can't handle here */
-   if (packing-SwapBytes) {
-  return GL_FALSE;
-   }
-
dstStride = _mesa_image_row_stride(packing, width, format, type);
dst = (GLubyte *) _mesa_image_address2d(packing, pixels, width, height,
   format, type, 0, 0);
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): draw: Only run prepare when state, prim and opt changes

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
 Tested-by: Stéphane Marchesin marc...@chromium.org

 ---

  src/gallium/auxiliary/draw/draw_context.c   |    6 +++
  src/gallium/auxiliary/draw/draw_private.h   |    8 
  src/gallium/auxiliary/draw/draw_pt.c        |   49
  ---
  src/gallium/auxiliary/draw/draw_pt.h        |    2 +-
  src/gallium/auxiliary/draw/draw_pt_vsplit.c |   11 --
  5 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/src/gallium/auxiliary/draw/draw_context.c
 b/src/gallium/auxiliary/draw/draw_context.c
 index 4ce4445..3c0b1aa 100644
 --- a/src/gallium/auxiliary/draw/draw_context.c
 +++ b/src/gallium/auxiliary/draw/draw_context.c
 @@ -355,6 +355,10 @@ draw_set_vertex_elements(struct draw_context
 *draw,
  {
     assert(count = PIPE_MAX_ATTRIBS);

 +   /* We could improve this by only flushing the frontend and the
 fetch part
 +    * of the middle. This would avoid recalculating the emit keys.*/
 +   draw_do_flush( draw, DRAW_FLUSH_STATE_CHANGE );
 +
     memcpy(draw-pt.vertex_element, elements, count *

Re: [Mesa-dev] Mesa (master): draw: Only run prepare when state, prim and opt changes

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
 Tested-by: Stéphane Marchesin marc...@chromium.org

 ---

  src/gallium/auxiliary/draw/draw_context.c   |    6 +++
  src/gallium/auxiliary/draw/draw_private.h   |    8 
  src/gallium/auxiliary/draw/draw_pt.c        |   49
  ---
  src/gallium/auxiliary/draw/draw_pt.h        |    2 +-
  src/gallium/auxiliary/draw/draw_pt_vsplit.c |   11 --
  5 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/src/gallium/auxiliary/draw/draw_context.c
 b/src/gallium/auxiliary/draw/draw_context.c
 index 4ce4445..3c0b1aa 100644
 --- a/src/gallium/auxiliary/draw/draw_context.c
 +++ b/src/gallium/auxiliary/draw/draw_context.c

Re: [Mesa-dev] Mesa (master): draw: Only run prepare when state, prim and opt changes

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
 Tested-by: Stéphane Marchesin marc...@chromium.org

 ---

  src/gallium/auxiliary/draw/draw_context.c   |    6 +++
  src/gallium/auxiliary/draw/draw_private.h   |    8 
  src/gallium/auxiliary/draw/draw_pt.c        |   49
  ---
  src/gallium/auxiliary/draw/draw_pt.h        |    2 +-
  src/gallium/auxiliary/draw/draw_pt_vsplit.c |   11 --
  5 files changed, 66 insertions(+), 10

[Mesa-dev] [PATCH] automake: src/mesa/drivers/osmesa

2012-01-26 Thread Matt Turner

---
Please give this a try.

OSMesa is broken with shared-glapi. I'll fix that (it'll be much
easier) when I automake glapi.

 configs/autoconf.in  |2 -
 configure.ac |   10 +++-
 src/mesa/Makefile|   17 +--
 src/mesa/drivers/osmesa/Makefile |   53 --
 src/mesa/drivers/osmesa/Makefile.am  |   82 ++
 src/mesa/drivers/osmesa/osmesa.pc.in |   12 +
 src/mesa/osmesa.pc.in|   12 -
 7 files changed, 103 insertions(+), 85 deletions(-)
 delete mode 100644 src/mesa/drivers/osmesa/Makefile
 create mode 100644 src/mesa/drivers/osmesa/Makefile.am
 create mode 100644 src/mesa/drivers/osmesa/osmesa.pc.in
 delete mode 100644 src/mesa/osmesa.pc.in

diff --git a/configs/autoconf.in b/configs/autoconf.in
index 3de3412..a8aa42dd 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -129,8 +129,6 @@ MOTIF_CFLAGS = @MOTIF_CFLAGS@
 
 # Library/program dependencies
 GL_LIB_DEPS = $(EXTRA_LIB_PATH) @GL_LIB_DEPS@
-OSMESA_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @OSMESA_MESA_DEPS@ \
-   $(EXTRA_LIB_PATH) @OSMESA_LIB_DEPS@
 EGL_LIB_DEPS = $(EXTRA_LIB_PATH) @EGL_LIB_DEPS@
 GLU_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @GLU_MESA_DEPS@ \
$(EXTRA_LIB_PATH) @GLU_LIB_DEPS@
diff --git a/configure.ac b/configure.ac
index 507cfff..d593a99 100644
--- a/configure.ac
+++ b/configure.ac
@@ -286,6 +286,8 @@ xnono )
 enable_static=yes
 ;;
 esac
+AM_CONDITIONAL(BUILD_STATIC, test x$enable_static = xyes)
+AM_CONDITIONAL(BUILD_SHARED, test x$enable_shared = xyes)
 
 dnl
 dnl mklib options
@@ -1318,6 +1320,9 @@ x16|x32)
 AC_MSG_ERROR([OSMesa bits '$osmesa_bits' is not a valid option])
 ;;
 esac
+AM_CONDITIONAL(HAVE_OSMESA8, test x$osmesa_bits = x8)
+AM_CONDITIONAL(HAVE_OSMESA16, test x$osmesa_bits = x16)
+AM_CONDITIONAL(HAVE_OSMESA32, test x$osmesa_bits = x32)
 
 if test x$enable_osmesa = xyes; then
 # only link libraries with osmesa if shared
@@ -1326,12 +1331,9 @@ if test x$enable_osmesa = xyes; then
 else
 OSMESA_LIB_DEPS=
 fi
-OSMESA_MESA_DEPS=
 OSMESA_PC_LIB_PRIV=-lm -lpthread $SELINUX_LIBS $DLOPEN_LIBS
 fi
 AC_SUBST([OSMESA_LIB_DEPS])
-AC_SUBST([OSMESA_MESA_DEPS])
-AC_SUBST([OSMESA_PC_REQ])
 AC_SUBST([OSMESA_PC_LIB_PRIV])
 
 dnl
@@ -1916,6 +1918,8 @@ AC_CONFIG_FILES([configs/autoconf
src/mesa/drivers/dri/r200/Makefile
src/mesa/drivers/dri/radeon/Makefile
src/mesa/drivers/dri/swrast/Makefile
+   src/mesa/drivers/osmesa/osmesa.pc
+   src/mesa/drivers/osmesa/Makefile
tests/Makefile
tests/glx/Makefile])
 
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index 0e15d61..80e9562 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -189,15 +189,6 @@ gl_pcedit = sed \
 gl.pc: gl.pc.in
$(gl_pcedit) $  $@
 
-osmesa_pcedit = sed \
-   $(pcedit) \
-   -e 's,@OSMESA_LIB@,$(OSMESA_LIB),' \
-   -e 's,@OSMESA_PC_REQ@,$(OSMESA_PC_REQ),' \
-   -e 's,@OSMESA_PC_LIB_PRIV@,$(OSMESA_PC_LIB_PRIV),'
-
-osmesa.pc: osmesa.pc.in
-   $(osmesa_pcedit) $  $@
-
 install-headers:
$(INSTALL) -d $(DESTDIR)$(INSTALL_INC_DIR)/GL
$(INSTALL) -m 644 $(TOP)/include/GL/*.h \
@@ -210,12 +201,8 @@ install-libgl: default gl.pc install-headers
$(DESTDIR)$(INSTALL_LIB_DIR)
$(INSTALL) -m 644 gl.pc $(DESTDIR)$(INSTALL_LIB_DIR)/pkgconfig
 
-install-osmesa: default osmesa.pc
-   $(INSTALL) -d $(DESTDIR)$(INSTALL_LIB_DIR)
-   $(INSTALL) -d $(DESTDIR)$(INSTALL_LIB_DIR)/pkgconfig
-   $(MINSTALL) $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_GLOB) \
-   $(DESTDIR)$(INSTALL_LIB_DIR)
-   $(INSTALL) -m 644 osmesa.pc $(DESTDIR)$(INSTALL_LIB_DIR)/pkgconfig
+install-osmesa: default
+   cd drivers/osmesa  $(MAKE) install
 
 install-dri: default
cd drivers/dri  $(MAKE) install
diff --git a/src/mesa/drivers/osmesa/Makefile b/src/mesa/drivers/osmesa/Makefile
deleted file mode 100644
index 005f4d5..000
--- a/src/mesa/drivers/osmesa/Makefile
+++ /dev/null
@@ -1,53 +0,0 @@
-# src/mesa/drivers/osmesa/Makefile for libOSMesa.so
-
-# Note that we may generate libOSMesa.so or libOSMesa16.so or libOSMesa32.so
-# with this Makefile
-
-
-TOP = ../../../..
-
-include $(TOP)/configs/current
-
-
-
-SOURCES = osmesa.c
-
-OBJECTS = $(SOURCES:.c=.o)
-
-INCLUDE_DIRS = \
-   -I$(TOP)/include \
-   -I$(TOP)/src/mapi \
-   -I$(TOP)/src/mesa \
-   -I$(TOP)/src/mesa/main
-
-CORE_MESA = \
-   $(TOP)/src/mesa/libmesa.a \
-   $(TOP)/src/mapi/glapi/libglapi.a \
-   $(TOP)/src/glsl/libglsl.a
-
-OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(OSMESA_LIB_DEPS)
-
-.c.o:
-   $(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $ -o $@
-
-
-default: $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME)
-
-
-# libOSMesa can be used in conjuction with libGL or with all other Mesa
-# sources. We can also build libOSMesa16/libOSMesa32 by setting
-#

[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler

https://bugs.freedesktop.org/show_bug.cgi?id=44618

Matt Turner matts...@gmail.com changed:

   What|Removed |Added

 CC||matts...@gmail.com

--- Comment #8 from Matt Turner matts...@gmail.com 2012-01-26 21:12:56 PST ---
I think I can partially fix this with automake.

Automake doesn't have a concept for host vs target $(CC)s, so you can't really
compile a single binary on the build system which is used to produce code
that'll be cross-compiled. So, that doesn't help, but:

I think I can add builtin_function.cpp to the BUILT_SOURCES or EXTRA_DIST
variables so that when you do `make dist` to generate the Mesa release tarball,
it'll build enough of src/glsl/* to generate builtin_function.cpp, which it'll
then include in the tarball. The cross-compiling system will then not have to
worry about generating it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler