On Wed, Jan 25, 2012 at 6:58 AM, Dave Airlie airl...@gmail.com wrote:
On Wed, Jan 25, 2012 at 1:53 AM, Ian Romanick i...@freedesktop.org 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
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 +++--
On Tue, 24 Jan 2012 23:52:57 -0500, nobled nob...@dreamwidth.org wrote:
On Tue, Jan 24, 2012 at 6:59 PM, Eric Anholt e...@anholt.net 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
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,
On Wed, Jan 25, 2012 at 4:04 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Tue, Jan 24, 2012 at 9:09 PM, 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
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
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
On Tue, Jan 24, 2012 at 10:33:07PM -0800, Eric Anholt wrote:
On Tue, 24 Jan 2012 23:52:57 -0500, nobled nob...@dreamwidth.org wrote:
On Tue, Jan 24, 2012 at 6:59 PM, Eric Anholt e...@anholt.net wrote:
A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
in the clear-accum
- 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
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
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 over the place
Thanks!
Marek
On Wed, Jan 25, 2012 at 2:50 PM, Jose Fonseca jfons...@vmware.com 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
On Tue, Jan 24, 2012 at 1:09 PM, Eric Anholt e...@anholt.net 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
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
On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs hob...@ohio.edu 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
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
On 01/25/2012 11:58 AM, Matt Turner wrote:
On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs hob...@ohio.edu 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
On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs hob...@ohio.edu wrote:
Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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:
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.
On 25 January 2012 11:42, Anuj Phogat anuj.pho...@gmail.com 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 ==
https://bugs.freedesktop.org/show_bug.cgi?id=33220
Kenneth Graunke kenn...@whitecape.org changed:
What|Removed |Added
AssignedTo|kenn...@whitecape.org
https://bugs.freedesktop.org/show_bug.cgi?id=45238
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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
On 01/25/2012 02:03 PM, Matt Turner wrote:
On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs hob...@ohio.edu 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
On Wed, Jan 25, 2012 at 4:45 PM, Kevin H. Hobbs hob...@ohio.edu wrote:
On 01/25/2012 02:03 PM, Matt Turner wrote:
On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs hob...@ohio.edu wrote:
Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2?
So this change is just the line
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
On Wed, Jan 25, 2012 at 12:22 PM, Paul Berry stereotype...@gmail.comwrote:
On 25 January 2012 11:42, Anuj Phogat anuj.pho...@gmail.com wrote:
Hi,
I'm getting following assertion failure on executing any OpenGL
application including glxinfo with mesa master (dc435ae):
glxinfo:
On 25/01/2012 21:54, Matt Turner wrote:
On Wed, Jan 25, 2012 at 4:45 PM, Kevin H. Hobbs hob...@ohio.edu wrote:
On 01/25/2012 02:03 PM, Matt Turner wrote:
On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs hob...@ohio.edu wrote:
Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2?
So
---
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
+++
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, but
---
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
+++
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
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 ++
On Wed, Jan 25, 2012 at 5:29 PM, Eric Anholt e...@anholt.net 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
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
---
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
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) ||
On Wed, Jan 25, 2012 at 5:45 PM, Eric Anholt e...@anholt.net 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
---
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
---
On Wed, Jan 25, 2012 at 5:45 PM, Eric Anholt e...@anholt.net wrote:
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, 2012-01-25 at 16:33 -0500, Matt Turner wrote:
On Wed, Jan 25, 2012 at 4:17 PM, Marek Olšák mar...@gmail.com 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
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
On 01/25/2012 02:10 PM, Anuj Phogat wrote:
On Wed, Jan 25, 2012 at 12:22 PM, Paul Berry stereotype...@gmail.com
mailto:stereotype...@gmail.com wrote:
On 25 January 2012 11:42, Anuj Phogat anuj.pho...@gmail.com
mailto:anuj.pho...@gmail.com wrote:
Hi,
I'm getting
On Wed, Jan 25, 2012 at 3:41 PM, Kenneth Graunke kenn...@whitecape.orgwrote:
On 01/25/2012 02:10 PM, Anuj Phogat wrote:
On Wed, Jan 25, 2012 at 12:22 PM, Paul Berry stereotype...@gmail.com
mailto:stereotype441@gmail.**com stereotype...@gmail.com wrote:
On 25 January 2012 11:42, Anuj
On Wed, 25 Jan 2012 15:39:55 -0800, Kenneth Graunke kenn...@whitecape.org
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
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
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
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
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
50 matches
Mail list logo
