[Mesa-dev] [Bug 30261] New: [GLSL 1.20] allowing inconsistent invariant declaration between two vertex shaders

2010-09-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=30261

   Summary: [GLSL 1.20] allowing inconsistent invariant
declaration between two vertex shaders
   Product: Mesa
   Version: git
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: gordon@intel.com
CC: i...@freedesktop.org


Created an attachment (id=38793)
 View: https://bugs.freedesktop.org/attachment.cgi?id=38793
 Review: https://bugs.freedesktop.org/review?bug=30261&attachment=38793

new piglit case

GLSL 1.20 section 4.3.6 says:
The type and presence of the invariant qualifiers of varying variables with the
same name declared in linked vertex and fragments shaders must match, otherwise
the link command will fail.

GLSL 1.50 section 4.6.1 says more clearly:
For variables leaving one shader and coming into another shader, the invariant
keyword has to be used in both shaders, or a link error will result.

The mesa glsl compiler fails link correctly for one vertex shader and one
fragment shader.

But it links (incorrectly) successfully for two vertex shaders.

This also exists in the old glsl compiler. So I'm not marking this as release
blocker.

Tested on Piketon (i965) with mesa master
ca92ae2699c4aad21c0811b9a5562b9223816caf.

New piglit case attached.

(This issues also applies for centroid. I'll add a new case for it after this
one gets handled.)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] gallium/docs: Fixed a typo in the SCS opcode description.

2010-09-19 Thread Tilman Sauerbeck
Signed-off-by: Tilman Sauerbeck 
---
 src/gallium/docs/source/tgsi.rst |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index e588c5b..4c1f47a 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -726,7 +726,7 @@ This instruction replicates its result.
 
   dst.z = 0
 
-  dst.y = 1
+  dst.w = 1
 
 
 .. opcode:: TXB - Texture Lookup With Bias
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] tgsi: Actually care what check_soa_dependencies says

2010-09-19 Thread José Fonseca
Hi Jakob,

On Sat, 2010-09-18 at 07:30 -0700, Jakob Bornecrantz wrote:
> On Sat, Sep 18, 2010 at 4:26 PM, Jakob Bornecrantz  
> wrote:
> > Looking over some of the piglit failings that Vinsons have posted running
> > on softpipe (we are down to 3005/3048). At first I was just going to make
> > the output not turn into a warn, but looking at the function it looks like
> > it actually should return the status and fail.
> >
> > This fixes both.

This is a good idea IMO.  

Given the existing of gallivm and tgsi_exec.c, both being pretty
correct, and the former very fast, I'm not sure what use is tgsi_sse2
catering for anymore. So I think that at very least it should not make
things worse.

A few cleanups: MOV is being whilelisted twice -- the second one can be
removed, and the /* XXX: ... */ comment moved to the top of the
function.

> Ops, looks like I ctrl-z the tests this was happening in. Its warning
> on shaders/fp-abs-01 and the ouput is:
> Warning: src/dst aliasing in instruction is not handled:
>   1: COS TEMP[1], TEMP[1].
> 
> For those who where interested in it.

There are a bunch of opcodes for which tgsi_sse2 actually doesn't trip
over, but are not white-listed yet, like COS.  I went through the code
and added all I could find. 

Also, tgsi_check_soa_dependencies ignores indirect registers.

Patch attached.

Jose


diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 298f3d0..2609ea0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -605,8 +605,10 @@ tgsi_check_soa_dependencies(const struct tgsi_full_instruction *inst)
for (i = 0; i < inst->Instruction.NumSrcRegs; i++) {
   if ((inst->Src[i].Register.File ==
inst->Dst[0].Register.File) &&
-  (inst->Src[i].Register.Index ==
-   inst->Dst[0].Register.Index)) {
+  ((inst->Src[i].Register.Index ==
+inst->Dst[0].Register.Index) ||
+	   inst->Src[i].Register.Indirect ||
+	   inst->Dst[0].Register.Indirect)) {
  /* loop over dest channels */
  uint channelsWritten = 0x0;
  FOR_EACH_ENABLED_CHANNEL(*inst, chan) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_sse2.c b/src/gallium/auxiliary/tgsi/tgsi_sse2.c
index 785a9fb..379771c 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_sse2.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_sse2.c
@@ -2835,6 +2835,26 @@ check_soa_dependencies(const struct tgsi_full_instruction *inst)
case TGSI_OPCODE_MOV:
case TGSI_OPCODE_MUL:
case TGSI_OPCODE_XPD:
+   case TGSI_OPCODE_RCP:
+   case TGSI_OPCODE_RSQ:
+   case TGSI_OPCODE_EXP:
+   case TGSI_OPCODE_LOG:
+   case TGSI_OPCODE_DP3:
+   case TGSI_OPCODE_DP4:
+   case TGSI_OPCODE_DP2A:
+   case TGSI_OPCODE_EX2:
+   case TGSI_OPCODE_LG2:
+   case TGSI_OPCODE_POW:
+   case TGSI_OPCODE_XPD:
+   case TGSI_OPCODE_DPH:
+   case TGSI_OPCODE_COS:
+   case TGSI_OPCODE_SIN:
+   case TGSI_OPCODE_TEX:
+   case TGSI_OPCODE_TXB:
+   case TGSI_OPCODE_TXP:
+   case TGSI_OPCODE_NRM:
+   case TGSI_OPCODE_NRM4:
+   case TGSI_OPCODE_DP2:
   /* OK - these opcodes correctly handle SOA dependencies */
   break;
default:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Mesa (master): glsl2: Add pass to remove redundant jumps

2010-09-19 Thread Eric Anholt
On Tue, 14 Sep 2010 03:55:06 +0200, Luca Barbieri  
wrote:
> ir_lower_jumps should already do the jump unification, and
> could/should also remove the continue.
> It's probably best to put all jump manipulations there to avoid
> risking rerunning all passes a number of times linear in the program
> size.
> 
> Regarding ifs, it would be nice to also remove empty else branches,
> and possibly convert if(c) {} else {code()} to if(!c) {code()} or

I remember writing the code to do that, but now I don't see it anywhere.
It should happen in ir_if_simplification, I think.

> perhaps do the reverse canonicalization instead.
> And also things like "if(c) {if(c) {code()}}" to if(c) {code()}

We don't have anything for handling constraints on values, and it would
be nice if we did.

> as well as "if(1) {code()}" to "code()",

That's in ir_if_simplification.


pgpTmwRZ893Cx.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] r600g: Honour destination operand's writemask in the SCS implementation.

2010-09-19 Thread Tilman Sauerbeck
Signed-off-by: Tilman Sauerbeck 
---
 src/gallium/drivers/r600/r600_shader.c |   49 +--
 1 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 4da6850..7e51db6 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -932,32 +932,37 @@ static int tgsi_scs(struct r600_shader_ctx *ctx)
 
 
/* dst.x = COS */
-   memset(&alu, 0, sizeof(struct r600_bc_alu));
-   alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_COS);
-   r = tgsi_dst(ctx, &inst->Dst[0], 0, &alu.dst);
-   if (r)
-   return r;
+   if (inst->Dst[0].Register.WriteMask & TGSI_WRITEMASK_X) {
+   memset(&alu, 0, sizeof(struct r600_bc_alu));
+   alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_COS);
+   r = tgsi_dst(ctx, &inst->Dst[0], 0, &alu.dst);
+   if (r)
+   return r;
 
-   alu.src[0].sel = ctx->temp_reg;
-   alu.src[0].chan = 0;
-   alu.last = 1;
-   r = r600_bc_add_alu(ctx->bc, &alu);
-   if (r)
-   return r;
+   alu.src[0].sel = ctx->temp_reg;
+   alu.src[0].chan = 0;
+   alu.last = 1;
+   r = r600_bc_add_alu(ctx->bc, &alu);
+   if (r)
+   return r;
+   }
 
/* dst.y = SIN */
-   memset(&alu, 0, sizeof(struct r600_bc_alu));
-   alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_SIN);
-   r = tgsi_dst(ctx, &inst->Dst[0], 1, &alu.dst);
-   if (r)
-   return r;
+   if (inst->Dst[0].Register.WriteMask & TGSI_WRITEMASK_Y) {
+   memset(&alu, 0, sizeof(struct r600_bc_alu));
+   alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_SIN);
+   r = tgsi_dst(ctx, &inst->Dst[0], 1, &alu.dst);
+   if (r)
+   return r;
+
+   alu.src[0].sel = ctx->temp_reg;
+   alu.src[0].chan = 0;
+   alu.last = 1;
+   r = r600_bc_add_alu(ctx->bc, &alu);
+   if (r)
+   return r;
+   }
 
-   alu.src[0].sel = ctx->temp_reg;
-   alu.src[0].chan = 0;
-   alu.last = 1;
-   r = r600_bc_add_alu(ctx->bc, &alu);
-   if (r)
-   return r;
return 0;
 }
 
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallium/docs: Fixed a typo in the SCS opcode description.

2010-09-19 Thread keith whitwell
Looks good, thanks Tilman.

Keith

On Sun, Sep 19, 2010 at 8:24 AM, Tilman Sauerbeck  wrote:
> Signed-off-by: Tilman Sauerbeck 
> ---
>  src/gallium/docs/source/tgsi.rst |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/docs/source/tgsi.rst 
> b/src/gallium/docs/source/tgsi.rst
> index e588c5b..4c1f47a 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -726,7 +726,7 @@ This instruction replicates its result.
>
>   dst.z = 0
>
> -  dst.y = 1
> +  dst.w = 1
>
>
>  .. opcode:: TXB - Texture Lookup With Bias
> --
> 1.7.2.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] draw_stream_output seems to be broken by design

2010-09-19 Thread Luca Barbieri
The current version of draw_stream_output in softpipe seems to attempt
to draw using the currently bound stream output buffer as input.

This does not match D3D10/11's DrawAuto, which instead draws with the
current vertex buffer (and requires having only one bound), but using
the primitive count from the latest stream output draw call.
MSDN says:
<>

It also doesn't match DrawTransformFeedback, which draws according to
the transform feedback object provided as a parameter.

In addition to that, the softpipe approach seems obviously wrong
because it makes it impossible to both draw the last stream output
buffer and also capture new stream output to another buffer (which is
common in the DirectX examples, flipping between two buffers).

I think a candidate for a Gallium design would be to add the stream
output "CSO" as a parameter to draw_stream_output.
If it is passed as NULL, then it draws according to the last draw with
stream output on the context (according to D3D10) and if not NULL
according to the draw with stream output with that specific CSO bound
(according to ARB_transform_feedback2).
Furthermore a flag in the CSO to enable/disable CSO-specific SO count
recording might allow some driver optimization in the D3D10 case.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Trivially enable GL_ARB_texture_border_clamp for nouveau_vieux

2010-09-19 Thread randrianasulu

Hi!

Patch was not exactly correct, pre-GeForce3 (pre nv20) cards can't do texture 
borders, even if said mode (CLAMP_TO_BORDER) listed in current headers 
(nouveau_class.h) and code has case switch for it.

But strangely, for me extension pop up in list just as i added it (i was 
played with cubemaps, got one face from  requred six in cubemap demo, highly 
corrupted, but it is another story), and Mesa  finally reported OpenGL 1.3/ 
of cource, it was lie (due to non-working cubemaps and useless 
clamp_to_border), but still .  make sure you have correct dri driver 
loaded, LIBGL_DEBUG=verbose usually will tell you from where it tried to load 
dri driver.


As for list of extensions blob exposed  

GL_ARB_pixel_buffer_object - need some work, i'm not sure what  this one want 
exactly

GL_ARB_point_parameters
GL_ARB_point_sprite - unfortunately not as trivial as they sounds  will 
look at them


GL_ARB_shader_objects
GL_ARB_shading_language_100 - sounds like software-emulated on nv17 :(


GL_ARB_texture_cube_map - hopefully soon.
GL_ARB_vertex_program - should be trivial, in software

GL_ARB_vertex_shader - this one harder, even if in sw.
GL_S3_s3tc - played with this one, no luck, due to my incapability to write 
non-trivial code

GL_EXT_clip_volume_hint - another one i don't know about  

GL_EXT_Cg_shader 
GL_EXT_gpu_program_parameters - - sounds like sw emulation again (nv17 has no 
advanced pixel processors, not even at GF3-level, so only very-very simple Cg 
(C-for-Graphics, if i remember correctly) programs will have very slim chance 
to run accelerated)


GL_EXT_paletted_texture - should be simple

GL_EXT_pixel_buffer_object - see GL_ARB_pixel_buffer_object
GL_EXT_point_parameters - see ARB variant 
GL_EXT_shared_texture_palette - not sure what this one mean at specification 
level ...
GL_EXT_texture_compression_s3tc - should be enabled automatically when s3tc 
support will be ready
GL_EXT_texture_cube_map - same here
GL_EXT_texture_env_dot3 - hopefully same here, but need to check 
GL_EXT_texture_lod - not sure, isn't it enabled already?
GL_KTX_buffer_region - something very specific to Autodesk, not sure if it 
will ever be supported, i even read this ext not recommended for  generic 
use.

GL_NV_fence - hopefully just need some path from kernel, but may be 
name 'fence' just mislead me. 

GL_NV_fog_distance - Francisco worked on fog sucessfully, hopefully he has 
something to add on this one.
GL_NV_pixel_data_range - i don't meet this one yet
GL_NV_point_sprite - nv version of point sprites ?

GL_NV_register_combiners - mesa lacks support for this one

GL_NV_vertex_array_range
GL_NV_vertex_array_range2 - hopefully someday ...

GL_NV_vertex_program
GL_NV_vertex_program1_1 - again, should be not too hard in sw.


GL_SGIS_multitexture - probably already enabled in hw, as  early version of  
ARB_multitexture, may be with some differencies.
GL_SUN_slice_accum - old extensions i  know very little about
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 29789] TALLOC_CFLAGS not used properly

2010-09-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29789

--- Comment #2 from David Ronis  2010-09-19 12:18:11 PDT 
---
Folks, this should be trivial to fix, but hasn't been.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 29789] TALLOC_CFLAGS not used properly

2010-09-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29789

David Ronis  changed:

   What|Removed |Added

   Severity|major   |critical

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] python/tests: Fixed tri.py for API and TGSI syntax changes.

2010-09-19 Thread Tilman Sauerbeck
Signed-off-by: Tilman Sauerbeck 
---

The same fix needs to be applied to a bunch of other Python scripts,
but tri.py seems to be a good starting point.

 src/gallium/tests/python/samples/tri.py |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/tests/python/samples/tri.py 
b/src/gallium/tests/python/samples/tri.py
index fed929d..6d17c88 100644
--- a/src/gallium/tests/python/samples/tri.py
+++ b/src/gallium/tests/python/samples/tri.py
@@ -88,8 +88,8 @@ def test(dev):
 
 # rasterizer
 rasterizer = Rasterizer()
-rasterizer.front_winding = PIPE_WINDING_CW
-rasterizer.cull_mode = PIPE_WINDING_NONE
+rasterizer.front_ccw = False
+rasterizer.cull_face = PIPE_FACE_NONE
 rasterizer.scissor = 1
 ctx.set_rasterizer(rasterizer)
 
@@ -161,8 +161,8 @@ def test(dev):
 # vertex shader
 vs = Shader('''
 VERT
-DCL IN[0], POSITION, CONSTANT
-DCL IN[1], COLOR, CONSTANT
+DCL IN[0]
+DCL IN[1]
 DCL OUT[0], POSITION, CONSTANT
 DCL OUT[1], COLOR, CONSTANT
 0:MOV OUT[0], IN[0]
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallium/docs: Fixed a typo in the SCS opcode description.

2010-09-19 Thread Tilman Sauerbeck
keith whitwell [2010-09-19 18:37]:
> Looks good, thanks Tilman.

Thanks, I've pushed the patch.

> On Sun, Sep 19, 2010 at 8:24 AM, Tilman Sauerbeck  
> wrote:
> > Signed-off-by: Tilman Sauerbeck 
> > ---
> >  src/gallium/docs/source/tgsi.rst |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/gallium/docs/source/tgsi.rst 
> > b/src/gallium/docs/source/tgsi.rst
> > index e588c5b..4c1f47a 100644
> > --- a/src/gallium/docs/source/tgsi.rst
> > +++ b/src/gallium/docs/source/tgsi.rst
> > @@ -726,7 +726,7 @@ This instruction replicates its result.
> >
> >   dst.z = 0
> >
> > -  dst.y = 1
> > +  dst.w = 1
> >
> >
> >  .. opcode:: TXB - Texture Lookup With Bias
> > --
> > 1.7.2.3
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpwLRr4Ae7q0.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 30124] Mesa 7.9 release tracker

2010-09-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=30124

Bug 30124 depends on bug 30231, which changed state.

Bug 30231 Summary: [i915g] undefined symbol: talloc_vasprintf_append
https://bugs.freedesktop.org/show_bug.cgi?id=30231

   What|Old Value   |New Value

 Resolution||FIXED
 Status|NEW |RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Removing ARB_imaging subset extensions

2010-09-19 Thread Eric Anholt
On our way to OpenGL 3.0, it would be nice to clean out some of the
optional deprecated features that Mesa supports.  The ARB_imaging subset
is the highest on my list -- it significantly clutters up the pixel
path, and has always been optional even though the specification text
got rolled into OpenGL 1.2.  ATI's proprietary driver never supported
the imaging subset, and what I've read of NVIDIA's implementation
online, its presence is a user trap.  Keeping an implementation of it is
not helping our users from a performance or portability perspective.

I've pushed a branch to my repo removing most of SGI_color_matrix,
SGI_color_table, EXT_histogram, and EXT_convolution.  Here's the
diffstat:

 drivers/common/driverfuncs.c  |2 
 drivers/common/meta.c |   82 --
 drivers/dri/i965/brw_state_upload.c   |1 
 drivers/dri/intel/intel_extensions.c  |2 
 drivers/dri/intel/intel_tex_image.c   |   20 
 drivers/dri/radeon/radeon_texture.c   |   16 
 drivers/dri/savage/savagetex.c|3 
 drivers/dri/unichrome/via_tex.c   |   22 
 main/attrib.c |   29 
 main/blend.c  |6 
 main/colortab.c   |  204 -
 main/colortab.h   |7 
 main/context.c|8 
 main/convolve.c   | 1307 --
 main/convolve.h   |   70 -
 main/dd.h |9 
 main/debug.c  |3 
 main/dlist.c  |2 
 main/enable.c |   89 --
 main/extensions.c |   17 
 main/get.c|   76 -
 main/histogram.c  |  971 -
 main/histogram.h  |2 
 main/image.c  |  141 ---
 main/image.h  |5 
 main/matrix.c |6 
 main/mfeatures.h  |1 
 main/mtypes.h |  125 ---
 main/pixel.c  |  170 
 main/querymatrix.c|4 
 main/texcompress_fxt1.c   |3 
 main/texcompress_s3tc.c   |5 
 main/teximage.c   |   62 -
 main/texstore.c   |  210 -
 program/prog_statevars.c  |   29 
 program/prog_statevars.h  |3 
 state_tracker/st_atom_pixeltransfer.c |  130 ---
 state_tracker/st_cb_readpixels.c  |3 
 state_tracker/st_cb_texture.c |6 
 state_tracker/st_extensions.c |1 
 swrast/s_copypix.c|  107 --
 swrast/s_drawpix.c|   92 --
 swrast/s_readpix.c|   59 -
 43 files changed, 96 insertions(+), 4014 deletions(-)

That's 2.7% of mesa/main/, and driver size dropped correspondingly.
Note that we don't get to completely drop histogram.c and convolve.c, as
we're supposed to have the entrypoints and just emit INVALID_OPERATION
for the missing extensions even if the ARB_imaging subset isn't present.

If we don't have any strong justification for keeping this code, I'd
like to merge this to master.


pgpJvdzyuOzOg.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Removing ARB_imaging subset extensions

2010-09-19 Thread Corbin Simpson
On Sun, Sep 19, 2010 at 5:59 PM, Eric Anholt  wrote:
> On our way to OpenGL 3.0, it would be nice to clean out some of the
> optional deprecated features that Mesa supports.  The ARB_imaging subset
> is the highest on my list -- it significantly clutters up the pixel
> path, and has always been optional even though the specification text
> got rolled into OpenGL 1.2.  ATI's proprietary driver never supported
> the imaging subset, and what I've read of NVIDIA's implementation
> online, its presence is a user trap.  Keeping an implementation of it is
> not helping our users from a performance or portability perspective.
>
> I've pushed a branch to my repo removing most of SGI_color_matrix,
> SGI_color_table, EXT_histogram, and EXT_convolution.  Here's the
> diffstat:
>
>  drivers/common/driverfuncs.c          |    2
>  drivers/common/meta.c                 |   82 --
>  drivers/dri/i965/brw_state_upload.c   |    1
>  drivers/dri/intel/intel_extensions.c  |    2
>  drivers/dri/intel/intel_tex_image.c   |   20
>  drivers/dri/radeon/radeon_texture.c   |   16
>  drivers/dri/savage/savagetex.c        |    3
>  drivers/dri/unichrome/via_tex.c       |   22
>  main/attrib.c                         |   29
>  main/blend.c                          |    6
>  main/colortab.c                       |  204 -
>  main/colortab.h                       |    7
>  main/context.c                        |    8
>  main/convolve.c                       | 1307 
> --
>  main/convolve.h                       |   70 -
>  main/dd.h                             |    9
>  main/debug.c                          |    3
>  main/dlist.c                          |    2
>  main/enable.c                         |   89 --
>  main/extensions.c                     |   17
>  main/get.c                            |   76 -
>  main/histogram.c                      |  971 -
>  main/histogram.h                      |    2
>  main/image.c                          |  141 ---
>  main/image.h                          |    5
>  main/matrix.c                         |    6
>  main/mfeatures.h                      |    1
>  main/mtypes.h                         |  125 ---
>  main/pixel.c                          |  170 
>  main/querymatrix.c                    |    4
>  main/texcompress_fxt1.c               |    3
>  main/texcompress_s3tc.c               |    5
>  main/teximage.c                       |   62 -
>  main/texstore.c                       |  210 -
>  program/prog_statevars.c              |   29
>  program/prog_statevars.h              |    3
>  state_tracker/st_atom_pixeltransfer.c |  130 ---
>  state_tracker/st_cb_readpixels.c      |    3
>  state_tracker/st_cb_texture.c         |    6
>  state_tracker/st_extensions.c         |    1
>  swrast/s_copypix.c                    |  107 --
>  swrast/s_drawpix.c                    |   92 --
>  swrast/s_readpix.c                    |   59 -
>  43 files changed, 96 insertions(+), 4014 deletions(-)
>
> That's 2.7% of mesa/main/, and driver size dropped correspondingly.
> Note that we don't get to completely drop histogram.c and convolve.c, as
> we're supposed to have the entrypoints and just emit INVALID_OPERATION
> for the missing extensions even if the ARB_imaging subset isn't present.
>
> If we don't have any strong justification for keeping this code, I'd
> like to merge this to master.

I am completely okay with this.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] draw_stream_output seems to be broken by design

2010-09-19 Thread Zack Rusin
On Sunday 19 September 2010 13:44:33 Luca Barbieri wrote:
> The current version of draw_stream_output in softpipe seems to attempt
> to draw using the currently bound stream output buffer as input.

It's because I never had the time to actually test it properly. The interface 
is right though, the implementation is supposed to follow the D3D semantics 
and we should stick with that, instead of passing cso's and making behavior 
switch based on magic null arguments.

z
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] draw_stream_output seems to be broken by design

2010-09-19 Thread Luca Barbieri
> It's because I never had the time to actually test it properly. The interface
> is right though, the implementation is supposed to follow the D3D semantics
> and we should stick with that, instead of passing cso's and making behavior
> switch based on magic null arguments.

I think you need that to implement ARB_transform_feedback2.

How would you implement this (note the id parameter) without a
corresponding CSO parameter in Gallium?
void DrawTransformFeedback(enum mode, uint id);

Of course you can do it with a SO_STATISTICS queries, but it's awkward
and requires the CPU to wait on the GPU (also, if the user is using
such a query himself, it might be an issue).

The NULL argument might be avoided, but that would cause D3D state
trackers to need to track and keep alive the last stream output CSO,
and might force the driver to unnecessarily write out the value to a
buffer instead of just keeping it in an hardware register.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] r300g: Always try to build libr300compiler.a

2010-09-19 Thread Tom Stellard
Make libr300compiler.a a PHONY target so that this library will always be
built.  This fixes the problem of libr300compiler.a not being updated
when r300g is being built and r300c is not.

This is a candidate for the Mesa 7.9 branch.
---
 src/gallium/drivers/r300/Makefile |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/r300/Makefile 
b/src/gallium/drivers/r300/Makefile
index 728bc40..66d900e 100644
--- a/src/gallium/drivers/r300/Makefile
+++ b/src/gallium/drivers/r300/Makefile
@@ -39,5 +39,6 @@ EXTRA_OBJECTS = \
 
 include ../../Makefile.template
 
+.PHONY: $(COMPILER_ARCHIVE)
 $(COMPILER_ARCHIVE):
$(MAKE) -C $(TOP)/src/mesa/drivers/dri/r300/compiler
-- 
1.7.2.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Correction about GL_SUN_slice_accum

2010-09-19 Thread randrianasulu
It is not as old  as I was thinking 

http://www.opengl.org/registry/specs/SUN/slice_accum.txt

$Date: 02/03/13 15:15:35  $Revision: 1.3 $


But extension itself talks about accumulation buffer(s)[0], they supported 
currently in software in mesa, and many old  consumer-level cards seems don't 
have them implemented in hardware, unfortunately including old (pre-nv30) 
Nvidia cards, as far as i know .

On nv30 and up accumulation buffer can be emulated, sort of. See [1], or [2] 
for 12-bit accumulation buffer.  There was some interest in implementing 
accum. buffer  in Mesa as metaop (?) or in mesa state tracker for Gallium 
drivers, but nothing come out, AFAIK. Sorry, can't find  links right now

[0] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.4497&rep=rep1&type=pdf
 - "The 
Accumulation Buffer: Hardware Support for High-Quality Rendering"

[1] http://www.petewarden.com/notes/archives/2005/05/fragment_progra.html
[2] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9136&rep=rep1&type=pdf
 - "Complex 
Water Effects at Interactive Frame Rates"
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev