Ian Romanick writes:
>> These files generated by bison and flex are different for me than the
>> ones checked in to git:
>>
>> src/glsl/glcpp/glcpp-lex.c
>> src/glsl/glcpp/glcpp-parse.c
>> src/glsl/glcpp/glcpp-parse.h
>> src/glsl/glsl_lexer.cpp
>> src/glsl/glsl_parser.cpp
>>
>> This is causing som
After some changes in gallium nvfx I have a problem with classic dri
driver. When I try to compile I got these error message:
nv04_context.c:31:27: fatal error: nouveau_class.h: No such file or
directory
compilation terminated.
make[6]: *** [nv04_context.o] error 1
Can someone fix this ?
ch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
> This is a new pass that supersedes ir_if_return and "lowers" jumps
> to if/else structures.
One of the things we had done intention was keep individual passes
simple, even if that means doing more total work. The reason is that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
> This is just a subclass of ir_visitor with empty implementations of all
> the visit methods.
>
> Used to avoid duplicating that in ir_visitor subclasses.
NAK. The methods are missing intentionally. Refer to any documentation
---
src/mesa/program/ir_to_mesa.cpp |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 7ec883e..5346d8f 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2730,6 +2730
This is a new pass that supersedes ir_if_return and "lowers" jumps
to if/else structures.
Currently it causes no regressions on softpipe and nv40, but I'm not sure
whether the piglit glsl tests are thorough enough, so consider this
experimental.
It can be asked to:
1. Pull jumps out of ifs where
This is just a subclass of ir_visitor with empty implementations of all
the visit methods.
Used to avoid duplicating that in ir_visitor subclasses.
ir_hierarchical_visitor is another way to solve this, but is less natural
for some applications.
---
src/glsl/ir_visitor.h | 21 ++
https://bugs.freedesktop.org/show_bug.cgi?id=29460
Jure Repinc changed:
What|Removed |Added
CC||jlp.b...@gmail.com
--
Configure bugmail:
On Monday 06 September 2010 11:25:31 Luca Barbieri wrote:
> On Mon, Sep 6, 2010 at 4:45 PM, Zack Rusin wrote:
> > Maybe lets skip this and other tessellation patches until we have code
> > that actually does something. It's just going to be confusing to have
> > not finished (or really "not starte
On Monday 06 September 2010 11:19:40 Luca Barbieri wrote:
> > I'm not a fan of this patch. Technically the token is from a different
> > extension, one which we never supported. We use our own representation of
> > a geometry program, did you double check whether what we have is at all
> > compatib
> And prog_optimize can't do anything if there are temporaries with indirect
> addressing. We need either the temporary array file or to do register
> allocation in GLSL IR.
Sure, but I think this can/should be done on top of this change, and
thus isn't an argument against it.
Instead of a tempor
On Sun, 5 Sep 2010 09:48:22 -0700
Ian Romanick wrote:
> On Sep 4, 2010, at 3:48 AM, Török Edwin wrote:
>
> > From: Török Edvin
> >
> > Otherwise spring 0.82+.4.0 crashes when starting a game
> > because prog->_LinkedShaders[0] is NULL.
>
> Any idea what this app is doing to hit this? A pigli
On Mon, Sep 6, 2010 at 5:05 PM, Luca Barbieri wrote:
> >>> Unfortunately, some GLSL shaders such as an SSAO fragment
> >>> post-processing shader in Unigine Tropics, go over this limit at
> >>> least before program optimizations are applied.
> >
> > By the time we generate Mesa IR all the optimiza
José Fonseca writes:
> There were also some native ports of bison/flex, but I haven't
> researched on that recently.
I'm partial to the gnuwin32 packages:
http://gnuwin32.sourceforge.net/
I've not tried to use bison/flex on windows yet, but I use it for grep
and gawk and it's wonderful. Ver
https://bugs.freedesktop.org/show_bug.cgi?id=29460
Jon TURNEY changed:
What|Removed |Added
Blocks||27840
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=27840
Jon TURNEY changed:
What|Removed |Added
Depends on|29640 |29460
--- Comment #10 from Jon TURNEY 2010
https://bugs.freedesktop.org/show_bug.cgi?id=27840
Jon TURNEY changed:
What|Removed |Added
Depends on||29640
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=27840
Jon TURNEY changed:
What|Removed |Added
Attachment #37723|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=30045
--- Comment #1 from Jon TURNEY 2010-09-06
08:51:59 PDT ---
Created an attachment (id=38478)
View: https://bugs.freedesktop.org/attachment.cgi?id=38478
Review: https://bugs.freedesktop.org/review?bug=30045&attachment=38478
Some fixes for GLX_I
https://bugs.freedesktop.org/show_bug.cgi?id=30045
Summary: mesa fails to build when configured
--disable-driglx-direct
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: norm
> Furthermore, if the idea is to make PIPE_PROCESSOR_* and
> TGSI_PROCESSOR_* match, then the first thing that comes to mind is: why
> do we need two equal named enums? If we're going through the trouble of
> changing this, then IMO, the change should be to delete one of these
> enums.
Right, shou
On Mon, Sep 6, 2010 at 4:45 PM, Zack Rusin wrote:
> Maybe lets skip this and other tessellation patches until we have code that
> actually does something. It's just going to be confusing to have not finished
> (or really "not started" =) ) code that doesn't do anything.
The idea is that having it
> I'm not a fan of this patch. Technically the token is from a different
> extension, one which we never supported. We use our own representation of a
> geometry program, did you double check whether what we have is at all
> compatible with the NV extension?
I think this will not be visible from o
>>> Unfortunately, some GLSL shaders such as an SSAO fragment
>>> post-processing shader in Unigine Tropics, go over this limit at
>>> least before program optimizations are applied.
>
> By the time we generate Mesa IR all the optimizations should be done.
Are you sure?
As far as I could tell, ir
Maybe lets skip this and other tessellation patches until we have code that
actually does something. It's just going to be confusing to have not finished
(or really "not started" =) ) code that doesn't do anything.
Also in terms of naming, I severely dislike abbreviations because code tends
to
On Sunday 05 September 2010 21:30:43 Luca Barbieri wrote:
> There is a published extension with a token, so let's use it.
I'm not a fan of this patch. Technically the token is from a different
extension, one which we never supported. We use our own representation of a
geometry program, did you d
Luca,
I think this is not a worthwhile change, at least not by itself.
First, this will cause the binary TGSI representation to change, and can
break some code which expects this particular ordering. For example, you
forgot to update tgsi_dump.c's processor_type_names[] array. And there
might be
https://bugs.freedesktop.org/show_bug.cgi?id=29646
Milan Bouchet-Valat changed:
What|Removed |Added
CC||nalimi...@club.fr
--
Configure bu
28 matches
Mail list logo
