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 piglit test would be
good.
Sent from my phone.
---
src/glsl/linker.cpp |
On Sep 5, 2010, at 3:38 AM, Christoph Bumiller > wrote:
On 09/05/2010 01:59 AM, Luca Barbieri wrote:
Currently Mesa has a limit of 1024 temporaries.
Unfortunately, some GLSL shaders such as an SSAO fragment
post-processing shader in Unigine Tropics, go over this limit at
least before program o
Luca,
I'd rather use what the GLSL compiler provides since, as you say, the wider
community cares about it. Although the GLSL if/loop emulation hasn't been
tested on r300 yet, I think the r300 compiler will handle it just fine.
However shader compilation should not fail if it hits an unsupported
On Sun, Sep 5, 2010 at 10:35 PM, Ian Romanick wrote:
> On Sep 5, 2010, at 6:40 PM, Tom Stellard wrote:
>
>> Hi,
>>
>> 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
> ...but even with all those, glxinfo still doesn't show
> texture_from_pixmap with any of the software drivers loaded. (It shows
> under "client glx extensions" and "server glx extensions", but it
> *always* shows up there; it doesn't show in the third list of plain
> old "GLX extensions", which A
On Sep 5, 2010, at 6:40 PM, Tom Stellard wrote:
Hi,
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 caus
Currently each shader cap has FS and VS versions.
However, we want a version of them for geometry, tessellation control,
and tessellation evaluation shaders, and want to be able to easily
query a given cap type for a given shader stage.
Since having 5 duplicates of each shader cap is unmanageable
Hi,
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 some annoyances for me when I do commits or swit
This turns on if conversion and unlimited loop unrolling if control
flow is not supported.
Also, programs whose control flow cannot be emulated will now
fail GLSL linkage.
---
src/mesa/state_tracker/st_extensions.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/s
This purpose of this is so that loop/if emulation in the glsl compiler
doesn't get enabled in the next change.
Note that doing such emulation in driver-specific code is probably
a bad idea, especially since the result won't be exposed to further
generic optimizations, and the driver-specific code
Don't add the pipe_screen/pipe_context members yet, since no actual
implementation is planned right now.
DirectX 11 calls these "hull" and "domain" shaders.
Since we are already using "fragment" instead of "pixel", and the
OpenGL naming is much clearer, use it.
They are abbreviated to "tessctrl"
These didn't match PIPE_SHADER_*, and it seems much better to make
all such indices match.
Vertex is first because cards with vertex shaders came first.
---
src/gallium/include/pipe/p_shader_tokens.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/include/p
This increases the chance that GLSL programs will actually work.
Note that continues and returns are not yet lowered, so linking
will just fail if not supported.
---
src/glsl/glsl_parser_extras.cpp|4 ++--
src/glsl/ir_optimization.h |2 +-
src/glsl/linker.cpp
This allows us to specify different options, especially useful for chips
without unified shaders.
---
src/mesa/main/mtypes.h | 15 ---
src/mesa/main/nvprogram.c |4 +++-
src/mesa/main/shaderapi.c | 31 ---
sr
This includes tessellation shaders.
---
src/mesa/main/mtypes.h | 17 +
src/mesa/main/shaderobj.h | 39 +++
src/mesa/program/program.h | 38 ++
3 files changed, 94 insertions(+), 0 deletions(-)
diff
---
src/mesa/main/extensions.c |1 +
src/mesa/main/mtypes.h |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 50b97f5..2ab3801 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@
There is a published extension with a token, so let's use it.
---
src/mesa/main/context.c |4 ++--
src/mesa/main/mtypes.h |8
src/mesa/main/state.c |2 +-
src/mesa/program/prog_print.c |2 +-
src/mesa/program/pro
This patchset introduces several changes to shader code.
The most significant and potentially contentious issue is a change in
the pipe_screen interface to add a better mechanism to query capabilities
that can vary depending on the shader stage.
The basic idea is that instead of asking for PIPE_C
https://bugs.freedesktop.org/show_bug.cgi?id=30037
Summary: [i945] textures in wined3d+pixelshader broken with
commit 22cd6f2cb4996de0a30c8f865f7011898ac8b8e2
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (A
It was mentioned in commit 8d789be03430b80e0ba2fef19d56dd0b8e699ea2
that gnome-shell could run on the classic swrast driver with the
__DRItexBuffer extension added--but when I compile Mesa git and use
the swrast driver, glxinfo doesn't show GLX_EXT_texture_from_pixmap as
enabled, and Ubuntu 10.04 w
> How the ... is it using 1000 TEMPs ?
> Wait, does it have large arrays and are they accessed indirectly ?
No, it has a large unrolled (by the game) loop which generates
something like 1500 instructions, each creating a different value.
On first sight, the unrolled loop seems to be the sampling k
On 09/05/2010 01:59 AM, Luca Barbieri wrote:
> Currently Mesa has a limit of 1024 temporaries.
>
> 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.
>
> Instead of just enl
22 matches
Mail list logo
