headers
bugzilla-daemon | 1 Jan 2009 12:33

[Bug 11404] Nexuiz GLSL shader compilation fails

http://bugs.freedesktop.org/show_bug.cgi?id=11404

--- Comment #12 from Mateusz Kaduk <mateusz.kaduk <at> gmail.com>  2009-01-01 03:33:28 PST ---
(In reply to comment #11)
> > OK, I've raised the max samplers to 16 in Mesa.  However, different GPUs will
> > have different limits.  The i965 driver is limited to 8 at this time, but I
> > believe that could be increased.

After latest commit
mesa: increase max texture image units and GLSL samplers to 16

When I run nexuiz with "GLSL" and "GLSL color handling" I experience a freez.
When I run just "GLSL" without "GLSL color handling" I get the following log

====== Log started (Thu Jan 01 12:26:42 2009) ======
developer 1
r_glsl 1
from disk... GLSL shader glsl/default.glsl generic diffuse compiled.
from disk... GLSL shader glsl/default.glsl generic compiled.
from disk... program link log:
Too many texture samplers (9, max is 8)
GLSL shader glsl/default.glsl lightmap fog failed!  some features may not work
properly.
from disk... program link log:
Too many texture samplers (9, max is 8)
GLSL shader glsl/default.glsl lightmap failed!  some features may not work
properly.
OpenGL 2.0 shaders disabled - unable to find a working shader permutation
fallback on this driver (set r_glsl 1 if you want to try again)
Server can't keep up: 100.0% CPU, 24.00% lost, offset avg 17.0ms, max 100.0ms,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zack Rusin | 1 Jan 2009 20:14
Favicon

Re: [LLVMdev] Folding vector instructions

On Wednesday 31 December 2008 09:15:09 Alex wrote:
> Zack Rusin wrote:
> > I think Alex was referring here to a AOS layout which is completely not
> > ready.
> > Actually currently the plan is to have essentially a "two pass" LLVM IR.
> > I wanted the first one to never lower any of the GPU instructions so we'd
> > have intrinsics or maybe even just function calls like gallium.lit,
> > gallium.dot, gallium.noise and such. Then gallium should query the driver
> > to figure out which instructions the GPU supports and runs our custom
> > llvm lowering pass that decomposes those into things the GPU supports.
>
> If I understand correct, that is to say, the gallium will dynamically build
> a lowering pass by querying the capability (instructions supported by the
> GPU)? Instead, isn't it a better approach to have a lowering pass for each
> GPU and gallium simply uses it?

The whole point of Gallium is to make driver development as simple as 
possible. So while it's certainly harder to write this code in a way that 
could be generic it's essentially what Gallium is all about and it's at least 
worth a try. 

> What do you plan to do with SOA and AOS paths in the gallium?

For now we need to figure out whether we need all the layouts or whether one  
is enough for all the backends.

> (1) Will they eventually be developed independently? So that for a
> scalar/SIMD GPU, the SOA will be used to generate LLVM IR, and for a vector
> GPU, AOS is used?
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 22:09

[Bug 11404] Nexuiz GLSL shader compilation fails

http://bugs.freedesktop.org/show_bug.cgi?id=11404

--- Comment #13 from Brian Paul <brian.paul <at> tungstengraphics.com>  2009-01-01 13:09:55 PST ---
I don't understand your previous comment.  If you tested 'without "GLSL color
handling"' why is the shader being compiled?

In any case, I've raised the limit on texture samplers in the i965 driver to
16.  Seems to work with my test program.

I'm not sure which DRI driver you're using.

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Jan 2009 21:36

[Bug 11404] Nexuiz GLSL shader compilation fails

http://bugs.freedesktop.org/show_bug.cgi?id=11404

Mateusz Kaduk <mateusz.kaduk <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #14 from Mateusz Kaduk <mateusz.kaduk <at> gmail.com>  2009-01-02 12:36:06 PST ---
After latest commits in nexuiz

====== Log started (Fri Jan 02 21:33:19 2009) ======
log_file "test.txt"
developer 1
r_glsl 1
log_file ""
====== Log stopped (Fri Jan 02 21:33:27 2009) ======

Looks like the problem in Nexuiz with shader compilation failing due to
overcoming texture sampling limit is gone, so I am closing this report.
Thanks.

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 5 Jan 2009 00:07

[Bug 19189] Humus Domino demo does not render properly

http://bugs.freedesktop.org/show_bug.cgi?id=19189

--- Comment #2 from Sven Arvidsson <sa <at> whiz.se>  2009-01-04 15:07:46 PST ---
Using mesa master, commit bfebeffc0045266d354a36968336337e099a9f27 rendering is
still broken, and I get this warning:

Mesa 7.3-devel implementation error: Unsupported opcode 85 (TRUNC) in vertex
shader
Please report at bugzilla.freedesktop.org

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 5 Jan 2009 01:21

[Bug 19391] New: Irrlicht demo fails to compile shaders (invalid assignment )

http://bugs.freedesktop.org/show_bug.cgi?id=19391

           Summary: Irrlicht demo fails to compile shaders (invalid
                    assignment)
           Product: Mesa
           Version: CVS
          Platform: x86 (IA32)
               URL: http://irrlicht.sourceforge.net/
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: sa <at> whiz.se

One of the demos provided with the Irrlicht engine, 10.Shaders, fails to
compile the shaders:

You need to select y to use "high level shaders".

Visual chosen: : 33
Using renderer: OpenGL 2.1
Mesa DRI Intel(R) G45/G43 GEM 20080716 x86/MMX/SSE2: Tungsten Graphics, Inc
OpenGL driver version is 1.2 or better.
GLSL version: 1.2
GLSL shader failed to compile
Error: invalid assignment

GLSL shader failed to compile
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Adamczewski | 5 Jan 2009 01:23
Picon
Picon
Favicon
Gravatar

[PATCH] Store setup.span.{left,right} as a vec_uint4

- Replace int setup.span{left,right}[2] with vec_uint4 setup.span.quad
- SIMDize calculate_mask() and inline into into flush_spans()
- Set setup.span.quad members using spu_shuffle() or spu_sel().

(Reduces spu_tri.o by ~116 bytes)
---
 src/gallium/drivers/cell/spu/spu_tri.c |   94 ++++++++++++++++++--------------
 1 files changed, 52 insertions(+), 42 deletions(-)

diff --git a/src/gallium/drivers/cell/spu/spu_tri.c b/src/gallium/drivers/cell/spu/spu_tri.c
index 22e51a8..c08a94e 100644
--- a/src/gallium/drivers/cell/spu/spu_tri.c
+++ b/src/gallium/drivers/cell/spu/spu_tri.c
 <at>  <at>  -35,6 +35,7  <at>  <at> 
 #include "util/u_math.h"
 #include "spu_colorpack.h"
 #include "spu_main.h"
+#include "spu_shuffle.h"
 #include "spu_texture.h"
 #include "spu_tile.h"
 #include "spu_tri.h"
 <at>  <at>  -122,8 +123,7  <at>  <at>  struct setup_stage {
    struct interp_coef coef[PIPE_MAX_SHADER_INPUTS];

    struct {
-      int left[2];   /**≤ [0] = row0, [1] = row1 */
-      int right[2];
+      vec_int4 quad; /**≤ [0] = row0, [1] = row1; {left[0],left[1],right[0],right[1]} */
       int y;
       unsigned y_flags;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Adamczewski | 5 Jan 2009 01:23
Picon
Picon
Favicon
Gravatar

[PATCH] spu_shuffle.h - new utility header for SPU

Facilitates creation of shuffle patterns for use with spu_shuffle()
and si_shufb() intrinsics.

To be used by subsequent patches.

---
 src/gallium/drivers/cell/spu/spu_shuffle.h |  186 ++++++++++++++++++++++++++++
 1 files changed, 186 insertions(+), 0 deletions(-)
 create mode 100644 src/gallium/drivers/cell/spu/spu_shuffle.h

diff --git a/src/gallium/drivers/cell/spu/spu_shuffle.h b/src/gallium/drivers/cell/spu/spu_shuffle.h
new file mode 100644
index 0000000..7cbdb81
--- /dev/null
+++ b/src/gallium/drivers/cell/spu/spu_shuffle.h
 <at>  <at>  -0,0 +1,186  <at>  <at> 
+#ifndef SPU_SHUFFLE_H
+#define SPU_SHUFFLE_H
+
+/*
+ * Generate shuffle patterns with minimal fuss.
+ *
+ * Based on ideas from 
+ * http://www.insomniacgames.com/tech/articles/0408/files/shuffles.pdf
+ *
+ * A-P indicates 0-15th position in first vector
+ * a-p indicates 0-15th position in second vector
+ *
+ * +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ * |00|01|02|03|04|05|06|07|08|09|0a|0b|0c|0d|0e|0f|
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Adamczewski | 5 Jan 2009 04:52
Picon
Picon
Favicon
Gravatar

[PATCH] SIMDize sorting in setup_sort_vertices()

Put setup.v{min,mid,max,provoke} into a union with qword vertex_headers.

Rewrite vertex sorting to more efficiently handle the packed data items.

Reduces spu_tri.o by ~128 bytes.
---
 src/gallium/drivers/cell/spu/spu_tri.c |   97 ++++++++++++++------------------
 1 files changed, 42 insertions(+), 55 deletions(-)

diff --git a/src/gallium/drivers/cell/spu/spu_tri.c b/src/gallium/drivers/cell/spu/spu_tri.c
index 30531d3..c7ff75c 100644
--- a/src/gallium/drivers/cell/spu/spu_tri.c
+++ b/src/gallium/drivers/cell/spu/spu_tri.c
 <at>  <at>  -103,10 +103,15  <at>  <at>  struct setup_stage {
     * turn.  Currently fixed at 4 floats, but should change in time.
     * Codegen will help cope with this.
     */
-   const struct vertex_header *vmax;
-   const struct vertex_header *vmid;
-   const struct vertex_header *vmin;
-   const struct vertex_header *vprovoke;
+   union {
+      struct {
+         const struct vertex_header *vmin;
+         const struct vertex_header *vmid;
+         const struct vertex_header *vmax;
+         const struct vertex_header *vprovoke;
+      };
+      qword vertex_headers;
+   };
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan Adamczewski | 5 Jan 2009 05:13
Picon
Picon
Favicon
Gravatar

[PATCH] SIMDize some subtractions.

Put edge.{dx,dy} into a union with a vector and perform subtractions in
setup_sort_vertices() on vectors.

Reduces spu_tri.o by ~300 bytes.
---
 src/gallium/drivers/cell/spu/spu_tri.c |   18 ++++++++++--------
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/cell/spu/spu_tri.c b/src/gallium/drivers/cell/spu/spu_tri.c
index c7ff75c..322be12 100644
--- a/src/gallium/drivers/cell/spu/spu_tri.c
+++ b/src/gallium/drivers/cell/spu/spu_tri.c
 <at>  <at>  -77,8 +77,13  <at>  <at>  struct vertex_header {
  * Triangle edge info
  */
 struct edge {
-   float dx;		/**≤ X(v1) - X(v0), used only during setup */
-   float dy;		/**≤ Y(v1) - Y(v0), used only during setup */
+   union {
+      struct {
+         float dx;	/**≤ X(v1) - X(v0), used only during setup */
+         float dy;	/**≤ Y(v1) - Y(v0), used only during setup */
+      };
+      vec_float4 ds;    /**≤ vector accessor for dx and dy */
+   };
    float dxdy;		/**≤ dx/dy */
    float sx, sy;	/**≤ first sample point coord */
    int lines;		/**≤ number of lines on this edge */
 <at>  <at>  -506,12 +511,9  <at>  <at>  setup_sort_vertices(const struct vertex_header *v0,
        spu_extract(setup.vmax->data[0], 0) > setup.cliprect_maxx)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane