On 08/07/2018 07:58 AM, Eric Engestrom wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511
> Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)"
[snip]
> AM_CONDITIONAL(NEED_KHRPLATFORM, test "x$enable_egl" = xyes -o \
> + "x
On 12/18/2015 11:32 AM, Brad King wrote:
> Prior to this change the test renders what we expect. After the
> change the test renders *nothing* on top of the background.
Ugh, nevermind, sorry for the noise.
It turns out this was a branch-on-uninitialized-value bug in VTK
that happened to t
Hi Folks,
I run nightly testing of VTK with nightly 'master' of mesa.
For the last few days some tests have been failing. According to
`git bisect`, mesa commit 183c606066b1b260acb189e46a40cb71e63b44aa
(glsl: simplify interface matching, 2015-12-02) introduced the
regression.
For example, see th
On 05/10/2014 08:37 AM, Emil Velikov wrote:
> Reviewed-by: Emil Velikov
> FWIW unless someone has further feedback I'll push this ~mid of the upcoming
> week.
Excellent, thanks!
-Brad
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://li
Use "@GL_LIB@" in src/gallium/targets/libgl-xlib/Makefile.am to produce
the library name specified by the configure --with-gl-lib-name option.
---
src/gallium/targets/libgl-xlib/Makefile.am | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/targets/libgl
Hi Folks,
Since commit ee55500c (configure: cleanup classic dri drivers handling,
2014-02-04) when I build from source using
$ ./autogen.sh --disable-dri
it fails with this error message:
configure: error: classic DRI driver 'yes' does not exist
I'm not sure whether it is related but I also
On 07/24/2012 01:37 AM, Dan Nicholson wrote:
> Applied as 27382c0f. I had been hoping Eric would pick it up since I'm
> not really keeping up with master these days, but the change looked good
> enough to me. Thanks!
Great, thanks!
-Brad
___
mesa-dev ma
On 07/16/2012 09:10 AM, Brad King wrote:
> Use "@GL_LIB@" in src/mesa/drivers/x11/Makefile.am to configure the
> library name. Also use this approach to simplify src/glx/Makefile.am
> and drop the HAVE_MANGLED_GL conditional.
>
> On 07/11/2012 04:05 PM, Dan Nicholson w
or the software-only driver to
use version GL_MAJOR instead of hard-coding "1".
---
On 07/11/2012 04:05 PM, Dan Nicholson wrote:
> On 7/11/12, Brad King wrote:
>> On 07/11/2012 11:24 AM, Eric Anholt wrote:
>>> For the OSMesa changes, Laurent Carlier used @OSMESA_LIB@
L_MAJOR instead of hard-coding "1".
---
On 07/11/2012 11:24 AM, Eric Anholt wrote:
> Brad King writes:
>> Upon closer inspection it *does* obviously drop use of GL_LIB.
>> Now "libGL" is hard-coded in "Makefile.am". Naive replacement
>> li
On 07/09/2012 04:57 PM, Brad King wrote:
> Running "git bisect" points to commit 2d4b77c7 (automake:
> Convert src/mesa/drivers/x11/Makefile, 2012-06-12). The change
> made by the commit does not obviously drop use of GL_LIB.
Upon closer inspection it *does* obviously drop
On 06/11/2012 04:37 PM, Kenneth Graunke wrote:
> Oh, sorry! Lost track of this. It looks like Eric's pushed it now.
Yes, thanks Eric!
However, since then another commit broke the feature. The build
always produces "GL" no matter the --with-gl-lib-name given.
The GLU and OSMesa options still wo
On 06/05/2012 02:03 PM, Kenneth Graunke wrote:
> On 06/05/2012 10:59 AM, Brad King wrote:
>>> ./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU
>>> --with-osmesa-lib-name=OSMesa ...
>>
>> That looks cleaner to me. Here is a patch for it.
>
> Revi
> Reviewed-by: Kenneth Graunke
>
> If there are no objections, I'll push this tomorrow. Thanks!
Great, thanks. If you want it:
Signed-off-by: Brad King
-Brad
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
These allow one to mangle the library names, without also mangling the
symbol names, to make them distinct from other GL libraries on the
system.
---
On 06/05/2012 01:38 PM, Kenneth Graunke wrote:
> This looks good to me. The only real question I have is whether it
> makes sense to set them via e
On 06/05/2012 11:12 AM, Dan Nicholson wrote:
> Duh, you're right. I think this original patch is good to go.
Great, thanks!
> a quick grep
> shows that there are no remaining hardcoded -lGL around (I think).
I've built with a custom configs/current in the old pure-make
system that sets GL_LIB fo
On 06/04/2012 12:29 PM, Brian Paul wrote:
> On 06/01/2012 12:55 PM, Brad King wrote:
>> However, I still get the above undefined symbols on x86_64 when
>> linking to the resulting GL library. The patch below (also in
>> my previous post) solves it. It seems configs/* is st
On 06/01/2012 05:49 PM, Dan Nicholson wrote:
>> +AC_ARG_VAR([GL_LIB],[name of GL library @<:@default=GL@:>@])
>> +AC_ARG_VAR([GLU_LIB],[name of GLU library @<:@default=GLU@:>@])
>> +AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @<:@default=OSMesa@:>@])
>> +GL_LIB="${GL_LIB-GL}"
>> +GLU_LIB="${GLU
Teach 'configure' to read the default GL_LIB, GLU_LIB, and OSMESA_LIB
values from the environment. This allows one to mangle the library
names (without also mangling the symbol names) to make them distinct
from other GL libraries on the system.
---
On 06/01/2012 10:06 AM, Brian Paul wrote:
> You
On 06/01/2012 10:06 AM, Brian Paul wrote:
> On 06/01/2012 07:32 AM, Brad King wrote:
>> undefined reference to `_mesa_x86_64_transform_points4_3d'
>> undefined reference to `_mesa_3dnow_transform_points4_perspective'
>> undefined reference to `_mesa_x8
Hi Folks,
Since commit 0ce0f7c0 (mesa: Remove the generated glapi from source
control, and just build it, 2012-05-15) I get this:
$ make linux-x86-64
...
make[3]: Entering directory `.../src/mapi/glapi'
make[3]: *** No rule to make target `depend', needed by `default'. Stop.
make[3]: Leavin
Hi Brian,
Recently VTK's TestPieChartActor and similar tests started to fail on
our test machines that use nightly Mesa. For example, one that I run:
http://www.cdash.org/CDash/testDetails.php?test=133410913&build=1960175
and one that Kevin Hobbs runs:
http://www.cdash.org/CDash/testDetai
On 01/17/2011 11:46 AM, Brian Paul wrote:
> Does the attached patch help?
Yes, that fixes it. The assertion no longer fails and the test passes.
Total resulting patch on top of ef3b8042 appears below.
Thanks,
-Brad
diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c
index bdb893e..616ee
On 01/17/2011 11:18 AM, Brian Paul wrote:
> On Mon, Jan 17, 2011 at 8:58 AM, Brad King wrote:
>> I think a63486ac is the first commit that exhibits the behavior.
>
> Have you tried reversing that change?
I started at ef3b8042 and ran "git revert a63486ac". I resolve
Hi Brian,
One of your changes in commit range 21001d2b..652901e9 causes one of
the VTK tests to render an empty image:
http://www.cdash.org/CDash/testDetails.php?test=79911707&build=826979
I think a63486ac is the first commit that exhibits the behavior.
This particular test renders only *point
25 matches
Mail list logo
