https://bugs.freedesktop.org/show_bug.cgi?id=29718
Summary: glsl2: failing to compile a conditional assignment to
gl_Position
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=29644
Nicolas Kaiser changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Friday 20 August 2010 07:41:28 Luca Barbieri wrote:
> Are these patches correct?
>
> Should I push them?
They look great - thanks for the patches! I've pushed them, along with
another fix in that area.
___
mesa-dev mailing list
mesa-dev@lists.freed
ast_function.cpp seems to be mixing spaces and tabs.
attached 'fixes' a method I was interested in to use only spaces. might
be a better idea to just run indent on this stuff though.
-tom
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index f85b308..f022a66 100644
--- a/src/g
Kenneth Graunke writes:
> Hi Tom!
>
> We built a new standalone compiler as part of glsl2 - it should be
> built as src/glsl/glsl_compiler. You might want to take a look at
> that.
Ahh, okay, I see it.
> If you want to run piglit's glslparsertest using the standalone
> compiler,
[snip]
Thanks
https://bugs.freedesktop.org/show_bug.cgi?id=29684
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
--
Configure bugmail: htt
https://bugs.freedesktop.org/show_bug.cgi?id=29622
Nick Bowler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, 19 Aug 2010 12:19:55 -0400, Nick Bowler wrote:
> This function was apparently missing from the display list dispatch
> table, causing the generic no-op function to be called instead. To make
> matters worse, the no-op function is indistinguishable from a successful
> call to GetUniformLoc
On Mon, Aug 16, 2010 at 3:55 PM, Roland Scheidegger wrote:
> On 14.08.2010 17:47, Marek Olšák wrote:
> > If PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE is not advertised and there is
> > a D24S8 texture bound and the mask is
> BUFFER_BIT_DEPTH|BUFFER_BIT_STENCIL,
> > the state tracker always cleared the
On Fri, 2010-08-20 at 07:40 -0700, Luca Barbieri wrote:
> Does debug-refcnt-2 look good now?
Yes, looks good to me.
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Are these patches correct?
Should I push them?
On Wed, Aug 18, 2010 at 12:52 PM, Luca Barbieri wrote:
> According to both GLSL 1.20 and 4.0, these are a struct with one field
> called "sceneColor".
>
> Fixes a crash on loading in FlightGear.
> ---
> src/mesa/program/ir_to_mesa.cpp | 4 ++--
>
Does debug-refcnt-2 look good now?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
When Mesa is built with :
./autogen.sh \
--prefix=/home/kevin/mesa_xlib/ \
--with-driver=xlib \
--disable-gallium \
--disable-gl-osmesa
The libGL.so that is produced has undefined symbols from talloc but
talloc is not linked.
$ nm mesa_xlib/lib/libGL.so | grep talloc
001ac4a0 T _
https://bugs.freedesktop.org/show_bug.cgi?id=29683
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Three things.
MSVC sucks pretty hard at life. As long as Win32 is a target for Mesa
and Gallium, we might as well put in extra effort to keep ourselves
portable. However...
Currently, i915g, r300g, nvfx, etc. are not built for Win32/Win64
anyway, because they have no winsys/kernel piece on that p
On Fri, 2010-08-20 at 06:35 -0700, José Fonseca wrote:
> On Fri, 2010-08-20 at 06:17 -0700, Luca Barbieri wrote:
> > > And define magic is very brittle. Especially with C++: you #define
> > > printf to be something else, but nothing prevents a class or a namespace
> > > to have the printf symbol in
On Fri, 2010-08-20 at 06:17 -0700, Luca Barbieri wrote:
> > And define magic is very brittle. Especially with C++: you #define
> > printf to be something else, but nothing prevents a class or a namespace
> > to have the printf symbol in its scope.
>
> Yes, but hopefully that's going to be very rar
> And define magic is very brittle. Especially with C++: you #define
> printf to be something else, but nothing prevents a class or a namespace
> to have the printf symbol in its scope.
Yes, but hopefully that's going to be very rare.
Alternatively, you can do this:
1. Compile with cl /Dsprintf=d
On Fri, 2010-08-20 at 05:09 -0700, Luca Barbieri wrote:
> > The advantage of having a prefix is that it makes it easy to detect when
> > people don't include the proper headers such as u_string.h, and it
> > guarantees one can wrap around even buggy OS implementations without
> > doing #define magi
Pushed another version which uses the util_* wrappers (hopefully I
didn't miss anything).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> The advantage of having a prefix is that it makes it easy to detect when
> people don't include the proper headers such as u_string.h, and it
> guarantees one can wrap around even buggy OS implementations without
> doing #define magic. It also allows to easily add wrapping.
It is indeed possibly
On Fri, 2010-08-20 at 04:11 -0700, Luca Barbieri wrote:
> > Hasn't this already happened somewhere - util/u_snprintf.c ?
> Indeed, I'll fix it to use those.
>
> There's something (independent from this) that bugs me though.
>
> Why does Gallium feel the need to implement all this stuff with ad-ho
On Fri, 2010-08-20 at 04:11 -0700, Luca Barbieri wrote:
> > Hasn't this already happened somewhere - util/u_snprintf.c ?
> Indeed, I'll fix it to use those.
>
> There's something (independent from this) that bugs me though.
>
> Why does Gallium feel the need to implement all this stuff with ad-ho
> Hasn't this already happened somewhere - util/u_snprintf.c ?
Indeed, I'll fix it to use those.
There's something (independent from this) that bugs me though.
Why does Gallium feel the need to implement all this stuff with ad-hoc
names, instead of, for instance, just implementing a function call
On Fri, 2010-08-20 at 03:01 -0700, Luca Barbieri wrote:
> I pushed a new version as debug-refcnt-2, which uses os_stream instead of
> FILE*.
> A new commit adds a printf facility to os_stream to support this.
>
> It still uses the sprintf functions from stdio.h, but I suppose this is OK.
> If a p
I pushed a new version as debug-refcnt-2, which uses os_stream instead of FILE*.
A new commit adds a printf facility to os_stream to support this.
It still uses the sprintf functions from stdio.h, but I suppose this is OK.
If a platform doesn't have those, they can be taken from a BSD libc
(or gnu
On Fri, 2010-08-20 at 01:58 -0700, Luca Barbieri wrote:
> There is also another small issue: a new tool is necessary to
> post-process the traces, to resolve function names and line numbers.
> I put it a new directory called "src/gallium/tools" since none of the
> existing places seem appropriate.
There is also another small issue: a new tool is necessary to
post-process the traces, to resolve function names and line numbers.
I put it a new directory called "src/gallium/tools" since none of the
existing places seem appropriate.
Is this a good idea?
___
> Yes, definitely. Thanks again for your efforts on this, Luca.
No problem :)
> Sounds like a useful facility, I hadn't noticed these commits though -
> let me take a look.
>
> I see some direct header file inclusions, not sure if that's an issue
> for embedded platforms - maybe Jose can comment.
On Fri, 2010-08-20 at 00:45 -0700, Corbin Simpson wrote:
> I can't find the email where we were discussing TGSI sanity. Did we
> want to move the sanity checker to galahad?
It only makes sense to move it there if galahad will end up being the
only user of it -- I'm not sure we're ready to make tha
On Fri, 2010-08-20 at 00:59 -0700, Luca Barbieri wrote:
> gallium-rect-textures adds the PIPE_TEXTURE_RECT target as discussed
> in the "gallium & texture rectangles" thread.
> I tested nv30, nv40, softpipe and "softpipe with NPOT disabled" using piglit.
Yes, definitely. Thanks again for your ef
> Caveat emptor: so far I can't repro this on Linux via piglit <...>
> That is, I can only repro the crash in MSVC build of my GLSL2 fork.
FYI, I do get a segfault when running that shader via glsl_compiler on
Linux, so it looks like it's not something that's windows specific.
That is, "glsl_comp
gallium-rect-textures adds the PIPE_TEXTURE_RECT target as discussed
in the "gallium & texture rectangles" thread.
I tested nv30, nv40, softpipe and "softpipe with NPOT disabled" using piglit.
debug-refcnt adds the ability to log reference count modifications on
Gallium objects to a file, which al
Hi Tom!
We built a new standalone compiler as part of glsl2 - it should be built as
src/glsl/glsl_compiler. You might want to take a look at that. It takes a
few options:
--dump-ast...prints out the abstract syntax tree (GLSL source)
--dump-hir...prints out high level IR (before lo
On Fri, 2010-08-20 at 09:09 +0200, Luca Barbieri wrote:
> > configs: Add -lstdc++ to default.
>
> Does this actually work if the application itself links to a different
> version of libstdc++ such as libstdc++.so.5?
>
> If not, it might be necessary to use -lstdc++_pic to link to the PIC
> static
I can't find the email where we were discussing TGSI sanity. Did we
want to move the sanity checker to galahad?
Also should I be double-checking the documentation around galahad
tests and making the documentation specify some of these caveats? The
docs are currently really loose on specifying thin
> configs: Add -lstdc++ to default.
Does this actually work if the application itself links to a different
version of libstdc++ such as libstdc++.so.5?
If not, it might be necessary to use -lstdc++_pic to link to the PIC
static library version.
LLVM probably has the same problem too (but in this
37 matches
Mail list logo
