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

On i965, _mesa_ir_link_shader is never called. As a consequence, ctx->FragmentProgram->_Current exists but contains no instructions. This greatly confuses swrast. To fix the confusion, this patch replaces checks of the form if (ctx->FragmentProgram->_Current == NULL) with if (_swrast_fragm

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

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/mes

[Mesa-dev] [PATCH 3/3] intel: Handle small linear blits using just the single-line code.

Fixes piglit ARB_copy_buffer/overlap, and glean bufferObject when run non-quick. NOTE: This is a candidate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44971 --- src/mesa/drivers/dri/intel/intel_blit.c | 40 +-- 1 files changed, 22 inser

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

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 tha

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

On Wed, 25 Jan 2012 23:56:27 +0100, Marek Olšák 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

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

On Wed, 25 Jan 2012 15:39:55 -0800, Kenneth Graunke wrote: > Another question: is it possible to determine whether libUnigine_xXX.so > is linked in? The driconf options today only seem to allow matching on > an application binary name. Running "strings" on the binaries does > mention libUnig

Re: [Mesa-dev] Assertion failure on SandyBridge

On Wed, Jan 25, 2012 at 3:41 PM, Kenneth Graunke wrote: > On 01/25/2012 02:10 PM, Anuj Phogat wrote: > >> On Wed, Jan 25, 2012 at 12:22 PM, Paul Berry > > wrote: >> >>On 25 January 2012 11:42, Anuj Phogat >**> wrote: >> >>

Re: [Mesa-dev] Assertion failure on SandyBridge

On 01/25/2012 02:10 PM, Anuj Phogat wrote: On Wed, Jan 25, 2012 at 12:22 PM, Paul Berry mailto:stereotype...@gmail.com>> wrote: On 25 January 2012 11:42, Anuj Phogat mailto:anuj.pho...@gmail.com>> wrote: Hi, I'm getting following assertion failure on executing any OpenGL

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

Re: [Mesa-dev] Should we fix Unigine apps?

On Wed, 2012-01-25 at 16:33 -0500, Matt Turner wrote: > On Wed, Jan 25, 2012 at 4:17 PM, Marek Olšák wrote: > > The only way to make it work seems to be to relax some requirements > of the GL spec and extensions (i.e. being non-compliant and > non-portable in theory, but actually being very portab

Re: [Mesa-dev] [PATCH 2/2] radeon: Fix missing dri common symbols after automake conversion.

On Wed, Jan 25, 2012 at 5:45 PM, Eric Anholt wrote: Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] radeon: Fix missing dri common symbols after automake conversion.

--- src/mesa/drivers/dri/r200/Makefile.am |3 ++- src/mesa/drivers/dri/radeon/Makefile.am |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/r200/Makefile.am b/src/mesa/drivers/dri/r200/Makefile.am index e83c5b7..d128dee 100644 --- a/src/mesa/dri

Re: [Mesa-dev] [PATCH 1/2] dri: Move the compile of the common files to a convenience library.

On Wed, Jan 25, 2012 at 5:45 PM, Eric Anholt wrote: > --- >  src/mesa/drivers/dri/common/Makefile.am |   17 + >  src/mesa/drivers/dri/i915/Makefile.am   |   13 +++-- >  src/mesa/drivers/dri/i965/Makefile.am   |   13 +++-- >  3 files changed, 23 insertions(+), 20 del

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

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") ||

[Mesa-dev] [PATCH 1/2] dri: Move the compile of the common files to a convenience library.

--- src/mesa/drivers/dri/common/Makefile.am | 17 + src/mesa/drivers/dri/i915/Makefile.am | 13 +++-- src/mesa/drivers/dri/i965/Makefile.am | 13 +++-- 3 files changed, 23 insertions(+), 20 deletions(-) diff --git a/src/mesa/drivers/dri/common/Makefile.am

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

On 1/25/12 2:29 PM, Kevin H. Hobbs wrote: On 01/24/2012 06:11 PM, Joshua Daniel Franklin (UW Seattle) wrote: The application works fine with an X11 DISPLAY using hardware GL but crashes when we try to use Mesa only. I decided to go to the very basic VTK_OPENGL_HAS_OSMESA OffScreenRendering.cxx e

Re: [Mesa-dev] [PATCH 1/4] i915: Fix driver after automakeification.

On Wed, Jan 25, 2012 at 5:29 PM, Eric Anholt wrote: > --- >  src/mesa/drivers/dri/i915/Makefile.am |   10 +- >  1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/drivers/dri/i915/Makefile.am > b/src/mesa/drivers/dri/i915/Makefile.am > index 6bc7061..5c44a9e 100644

[Mesa-dev] [PATCH 3/4] i965: Add a driconf option to force GLSL extension behavior to "warn".

This can be used to work around broken application behavior, like in Unigine where it attempts to use texture arrays without declaring either "#extension GL_EXT_texture_array : enable" or "#version 130". --- src/mesa/drivers/dri/common/xmlpool/options.h | 10 ++ src/mesa/drivers/dri/i965

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

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

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

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

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

On 01/24/2012 06:11 PM, Joshua Daniel Franklin (UW Seattle) wrote: > The application works fine with an X11 > DISPLAY using hardware GL but crashes when we try to use Mesa only. I > decided to go to the very basic VTK_OPENGL_HAS_OSMESA > OffScreenRendering.cxx example: > I will gladly help you,

[Mesa-dev] [PATCH 1/4] i915: Fix driver after automakeification.

--- src/mesa/drivers/dri/i915/Makefile.am | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i915/Makefile.am b/src/mesa/drivers/dri/i915/Makefile.am index 6bc7061..5c44a9e 100644 --- a/src/mesa/drivers/dri/i915/Makefile.am +++ b/src/mesa/driver

Re: [Mesa-dev] OSMesa glapi linlking

On 25/01/2012 21:54, Matt Turner wrote: > On Wed, Jan 25, 2012 at 4:45 PM, Kevin H. Hobbs wrote: >> On 01/25/2012 02:03 PM, Matt Turner wrote: >>> On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs wrote: >>> >>> Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2? >> >> >> So this change i

Re: [Mesa-dev] Assertion failure on SandyBridge

On Wed, Jan 25, 2012 at 12:22 PM, Paul Berry wrote: > On 25 January 2012 11:42, Anuj Phogat wrote: > >> Hi, >> >> I'm getting following assertion failure on executing any OpenGL >> application including glxinfo with mesa master (dc435ae): >> >> glxinfo: brw_program.c:261: brwInitFragProgFuncs: As

Re: [Mesa-dev] Should we fix Unigine apps?

On 01/25/2012 01:17 PM, Marek Olšák wrote: Hi everyone, If your Mesa driver supports GL3 or EXT_texture_array or ARB_draw_instanced, Unigine is broken for you. (I tested Unigine Sanctuary and Unigine Heaven, the others probably won't be any different) The only way to make it work seems to be

Re: [Mesa-dev] OSMesa glapi linlking

On Wed, Jan 25, 2012 at 4:45 PM, Kevin H. Hobbs wrote: > On 01/25/2012 02:03 PM, Matt Turner wrote: >> On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs wrote: >> >> Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2? > > > So this change is just the line > > OSMESA_LIB_DEPS := -L$(TOP)/$

Re: [Mesa-dev] OSMesa glapi linlking

On 01/25/2012 02:03 PM, Matt Turner wrote: > On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs wrote: > > Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2? So this change is just the line OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(OSMESA_LIB_DEPS) So I commented that out

Re: [Mesa-dev] Should we fix Unigine apps?

On Wed, Jan 25, 2012 at 4:17 PM, Marek Olšák wrote: > The only way to make it work seems to be to relax some requirements of the GL > spec and extensions (i.e. being non-compliant and non-portable in theory, but > actually being very portable in practice). There are probably more ways to go > a

[Mesa-dev] Should we fix Unigine apps?

Hi everyone, If your Mesa driver supports GL3 or EXT_texture_array or ARB_draw_instanced, Unigine is broken for you. (I tested Unigine Sanctuary and Unigine Heaven, the others probably won't be any different) The only way to make it work seems to be to relax some requirements of the GL spec an

[Mesa-dev] [Bug 45238] [regression] Unigine Heaven, OilRush broken in git

https://bugs.freedesktop.org/show_bug.cgi?id=45238 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Mesa-dev] [Bug 33220] Use of talloc_autofree_context causes segfault when dynamically loaded

https://bugs.freedesktop.org/show_bug.cgi?id=33220 Kenneth Graunke changed: What|Removed |Added AssignedTo|kenn...@whitecape.org |mesa-dev@lists.freedesktop.

Re: [Mesa-dev] Assertion failure on SandyBridge

On 25 January 2012 11:42, Anuj Phogat wrote: > Hi, > > I'm getting following assertion failure on executing any OpenGL > application including glxinfo with mesa master (dc435ae): > > glxinfo: brw_program.c:261: brwInitFragProgFuncs: Assertion > `functions->ProgramStringNotify == _tnl_program_stri

[Mesa-dev] Assertion failure on SandyBridge

Hi, I'm getting following assertion failure on executing any OpenGL application including glxinfo with mesa master (dc435ae): glxinfo: brw_program.c:261: brwInitFragProgFuncs: Assertion `functions->ProgramStringNotify == _tnl_program_string' failed. Program received signal SIGABRT, Aborted. 0x00

[Mesa-dev] [Bug 45238] New: [regression] Unigine Heaven, OilRush broken in git

https://bugs.freedesktop.org/show_bug.cgi?id=45238 Bug #: 45238 Summary: [regression] Unigine Heaven, OilRush broken in git Classification: Unclassified Product: Mesa Version: git Platform: Other URL: http://unigine.com/pro

Re: [Mesa-dev] OSMesa glapi linlking

On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs wrote: Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] OSMesa glapi linlking

On 01/25/2012 11:58 AM, Matt Turner wrote: > On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs wrote: >> My build of OSMesa from git is failing: >> >> ./autogen.sh \ >> --prefix=/home/kevin/mesa_osmesa/ \ >> --disable-dri \ >> --disable-glx \ >> --enable-osmesa > > Unrelated (related to anothe

Re: [Mesa-dev] [PATCH 0/6] Draw-optz changes

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

Re: [Mesa-dev] OSMesa glapi linlking

On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs wrote: > My build of OSMesa from git is failing: > > ./autogen.sh \ >  --prefix=/home/kevin/mesa_osmesa/ \ >  --disable-dri \ >  --disable-glx \ >  --enable-osmesa Unrelated (related to another thread recently) but, did you mean to build Gallium (a

Re: [Mesa-dev] [PATCH] automake: src/egl/wayland

On Wed, Jan 25, 2012 at 4:59 AM, Benjamin Franzke wrote: > So we can use the wayland scanner makro, which is way > better than our previous runtime-pkgconfig hack. > --- >  configs/autoconf.in                           |    7 --- >  configs/default                               |    7 --- >  confi

[Mesa-dev] OSMesa glapi linlking

My build of OSMesa from git is failing: ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --disable-dri \ --disable-glx \ --enable-osmesa /bin/sh ../../../../bin/mklib -o OSMesa -linker 'g++' -ldflags '' \ -major 8 -minor 0 -patch 0 \ -install ../../../../lib -cplusplus

Re: [Mesa-dev] [PATCH 2/2] i965: Drop the buggy, verbose link test for unresolved symbols.

On Tue, Jan 24, 2012 at 1:09 PM, Eric Anholt wrote: > This mostly existed to cause a build error when you typoed a function > name, didn't see the warning in the Mesa build spew, then some time > later tried to use your driver and it failed in a strange way.  Now > that we enable errors on missing

Re: [Mesa-dev] Mesa (master): st/mesa: inline if(1) conditional

Thanks! Marek On Wed, Jan 25, 2012 at 2:50 PM, Jose Fonseca wrote: > It was easy. It's fixed now. > > Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): st/mesa: inline if(1) conditional

It was easy. It's fixed now. Jose - Original Message - > Marek, > > I'm seeing the following assertion failure > >src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4032:src_register: >Assertion `t->inputMapping[index] < >(sizeof(t->inputs)/sizeof(*(t->inputs)))' failed. > > all ov

Re: [Mesa-dev] Mesa (master): st/mesa: inline if(1) conditional

Marek, I'm seeing the following assertion failure src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4032:src_register: Assertion `t->inputMapping[index] < (sizeof(t->inputs)/sizeof(*(t->inputs)))' failed. all over the place (conform, glean, piglit) since the commit below. For example, doing /v

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

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

Re: [Mesa-dev] [PATCH] intel: Fix accum buffer mapping since the swrast rework.

On Tue, Jan 24, 2012 at 10:33:07PM -0800, Eric Anholt wrote: > On Tue, 24 Jan 2012 23:52:57 -0500, nobled wrote: > > On Tue, Jan 24, 2012 at 6:59 PM, Eric Anholt wrote: > > > A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted > > > in the clear-accum test.  Just look at the swra

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

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. C90 and C99 require a

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

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

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

On Wed, Jan 25, 2012 at 4:04 AM, Brian Paul wrote: > On Tue, Jan 24, 2012 at 9:09 PM, Marek Olšák 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.

Re: [Mesa-dev] [PATCH 2/2] i965: Drop the buggy, verbose link test for unresolved symbols.

On 01/24/2012 10:09 AM, Eric Anholt wrote: This mostly existed to cause a build error when you typoed a function name, didn't see the warning in the Mesa build spew, then some time later tried to use your driver and it failed in a strange way. Now that we enable errors on missing prototypes, the

Re: [Mesa-dev] [PATCH] intel: Fix accum buffer mapping since the swrast rework.

On Tue, 24 Jan 2012 23:52:57 -0500, nobled wrote: > On Tue, Jan 24, 2012 at 6:59 PM, Eric Anholt wrote: > > A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted > > in the clear-accum test.  Just look at the swrast renderbuffer pointer > > for handling swrast rbs. > > --- > >  src

[Mesa-dev] [PATCH] automake: src/egl/wayland

So we can use the wayland scanner makro, which is way better than our previous runtime-pkgconfig hack. --- configs/autoconf.in |7 --- configs/default |7 --- configure.ac | 24 +++-- src/egl/dri

Re: [Mesa-dev] [PATCH 3/4] mesa: remove ctx->Const.sRGBCapable

On Wed, Jan 25, 2012 at 6:58 AM, Dave Airlie wrote: > On Wed, Jan 25, 2012 at 1:53 AM, Ian Romanick wrote: >> On 01/24/2012 04:39 PM, Marek Olšák wrote: >>> >>> It always had the same value as ctx->Extensions.EXT_framebuffer_sRGB. >> >> >> I'd be curious why Dave added this flag in the first plac