Re: [Mesa-dev] [PATCH 09/14] i965: Remove brw_fs_precompile

2012-01-10 Thread Kenneth Graunke

On 01/09/2012 05:26 PM, Eric Anholt wrote:

On Fri,  6 Jan 2012 16:50:00 -0800, "Ian Romanick"  wrote:

From: Ian Romanick

There are several things that could cause the fragment shader
precompile to fail.  Looking for calls to 'fail' in brw_fs_visitor.cpp
finds three classes of things:

   * Trying to emit instructions that are invalid in 16-wide mode.

   * Trying to emit instructions that should have been lowered.

   * Register allocation failures.


I'm really sad to see this code go.  It's been incredibly useful for
tracking regressions in our code generation quality -- we have no other
current tool for doing so, since doing actual measurement requires
testing infrastructure we don't have.

Apitracing single frames of apps would get us close to this, but it will
miss shaders not involved in the frame you choose, the disk space cost
is still stunning, redistribution of a collection of traces is even more
difficult to accomplish while respecting copyright than shader-db, and
we don't have any current collection of traces at all.

If there's any way to retain this code, I'd like to.


Yeah...unfortunately, I agree with Eric on this one.  Ian, how hard 
would it be to keep it?  You could still remove the ability to raise 
link errors, as shader-db doesn't need that.


I am definitely no fan of the precompile in normal circumstances, but 
shader-db is immensely valuable when working on codegen optimizations, 
and without an up-front compile, I'm not sure how to make it happen.


Eric, how hard would it be to write a tool that, given a bunch of shader 
programs, compiled them, left all the non-orthogonal state at defaults, 
and did some dummy draw using the shaders so they actually get compiled 
all the way to assembly?  I'd estimate it as a day or two of work, but 
I'm probably missing something.  Then you wouldn't need this, and 
shader-db could still work.


An "apitrace dump-shaders" command that scraped GLSL and ARB programs 
from an app without actually writing a trace (for disk sake) would be 
useful as well.  Scraping from a trace would be nice, too.

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


Re: [Mesa-dev] [PATCH 00/14] Fix some linker stuff, kill one more user of ir_to_mesa

2012-01-10 Thread Kenneth Graunke

On 01/06/2012 04:49 PM, Ian Romanick wrote:

Patches 01/14 through 03/14 was previously sent to the list.  It
tickled a pre-existing bug (fixed by patch recently posted to the list
by Eric) on some Intel chipsets.

Patches 04/14 through 07/14 make the linker do some sampler tracking
that was previously done by ir_to_mesa.  I suspect that the same work
is duplicated by st_glsl_to_tgsi, so some refactoring could probably
happen there.

The remaining patches gut the pre-compile paths and the use of
ir_to_mesa from the i965 driver.  There are a couple state bits that
were previously calculated by ir_to_mesa that now must be tracked by
the driver (see patches 12/14 and 14/14).  It is arguable that these
two patches should be squashed into 13/14.  I sent them separately to
make the changes more explicit.

I observe no piglit regressions on SNB with this series.  I don't have
convenient access to other hardware, so I haven't tested that yet.  I
plan to do that testing before pushing.


If it's helpful, Dylan has G33, Pineview, G965, and GM45 set up in the 
lab and running tests.  You just drop in your git remote URL and branch 
name and it runs Piglit on all your platforms.  (No Ironlake or 
Sandybridge yet, unfortunately...we need to buy more machines.)


Patches 1, 3, and 13 are
Acked-by: Kenneth Graunke 

Patches 2, 4-7, and 11 are
Reviewed-by: Kenneth Graunke 

I am reluctant about 8-10 (replied separately); I also think 12 and 14 
could be done better but if there isn't time, then oh well.

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


[Mesa-dev] [Bug 44618] New: Cross-compilation broken by glsl builtin_compiler

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44618

 Bug #: 44618
   Summary: Cross-compilation broken by glsl builtin_compiler
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: thierry.red...@avionic-design.de


When cross-compiling Mesa 7.11 and later, it errors out when trying to generate
the glsl builtins. The reason is that the builtin_compiler binary is built for
the host system instead of the build system. This was already discussed after
the commit that introduced this error but was never solved:

http://lists.freedesktop.org/archives/mesa-dev/2011-January/004780.html

AFAICT there are two solutions:
  1) Fix the build system to generate the builtin_compiler for the build system
 using something like CC_FOR_BUILD (I don't know if SCons has an
equivalent)
 which will require pretty much all of the src/glsl subdirectory to be
built
 twice.
  2) Modify the build system to allow the builtin_compiler to be overridden,
 such that Mesa can be built once for the build host, and the resulting
 builtin_compiler binary can be used in the Mesa cross-build.

I believe 1) would be the best option. 2) is cumbersome and will require two
complete builds, while 1) would only require parts of the src/glsl directory
to be rebuilt. 1) also has the advantage that the build will work
out-of-the-box
without the user having to follow special instructions.

I'm willing to spend some time on this, but wanted to discuss things first.

-- 
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 44564] Fix build with LLVM -DLLVM_TARGETS_TO_BUILD=`native`

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44564

--- Comment #2 from ojab  2012-01-10 02:44:58 PST ---
Anyway, Mesa doesn't need LLVM libraries except in `$LLVM_CONFIG --libs engine`
to build/run?

-- 
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


Re: [Mesa-dev] Mesa (master): st/mesa: add support for clip vertex.

2012-01-10 Thread Christoph Bumiller
On 10.01.2012 04:52, Stéphane Marchesin wrote:
> Hi Dave,
>
> This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
> piglit test on i915g.

That's likely. You're probably not using the ClipVertex but instead
gl_Position for clipping since the prior was not identifiable before.

The only difference between them in this test is a projection
transformation, and since the projection transformation only changed for
the plane coefficients in i915 but not the vector you test it against,
the test naturally fails.

Christoph

> Stéphane
>
>
> On Sat, Jan 7, 2012 at 00:39, Dave Airlie
>  wrote:
>> Module: Mesa
>> Branch: master
>> Commit: a103c61d278b7f56208818c4b949c408c00286fa
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a103c61d278b7f56208818c4b949c408c00286fa
>>
>> Author: Dave Airlie 
>> Date:   Wed Jan  4 11:49:26 2012 +
>>
>> st/mesa: add support for clip vertex.
>>
>> We need to pass the pre-projection matrix clip planes into the driver,
>> instead of the post for the case we have a vertex shader that writes clip
>> vertex.
>>
>> Signed-off-by: Dave Airlie 
>>
>> ---
>>
>>  src/mesa/state_tracker/st_atom_clip.c |   20 ++--
>>  src/mesa/state_tracker/st_program.c   |4 
>>  2 files changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_atom_clip.c 
>> b/src/mesa/state_tracker/st_atom_clip.c
>> index 1330db8..236d3cf 100644
>> --- a/src/mesa/state_tracker/st_atom_clip.c
>> +++ b/src/mesa/state_tracker/st_atom_clip.c
>> @@ -34,7 +34,7 @@
>>  #include "st_context.h"
>>  #include "pipe/p_context.h"
>>  #include "st_atom.h"
>> -
>> +#include "st_program.h"
>>  #include "cso_cache/cso_context.h"
>>
>>
>> @@ -45,15 +45,23 @@ static void update_clip( struct st_context *st )
>>struct pipe_clip_state clip;
>>const struct gl_context *ctx = st->ctx;
>>GLuint i;
>> +   bool use_eye = FALSE;
>>
>>memset(&clip, 0, sizeof(clip));
>>
>> +   /* if we have a vertex shader that writes clip vertex we need to pass
>> +  the pre-projection transformed coordinates into the driver. */
>> +   if (st->vp) {
>> +  if (ctx->Shader.CurrentVertexProgram)
>> + use_eye = TRUE;
>> +   }
>> +
>>for (i = 0; i < PIPE_MAX_CLIP_PLANES; i++) {
>>   if (ctx->Transform.ClipPlanesEnabled & (1 << i)) {
>> -memcpy(clip.ucp[clip.nr],
>> -   ctx->Transform._ClipUserPlane[i],
>> -   sizeof(clip.ucp[0]));
>> -clip.nr++;
>> + memcpy(clip.ucp[clip.nr],
>> +use_eye ? ctx->Transform.EyeUserPlane[i] : 
>> ctx->Transform._ClipUserPlane[i],
>> +sizeof(clip.ucp[0]));
>> + clip.nr++;
>>   }
>>}
>>
>> @@ -69,7 +77,7 @@ static void update_clip( struct st_context *st )
>>  const struct st_tracked_state st_update_clip = {
>>"st_update_clip",   /* name */
>>{   /* dirty */
>> -  (_NEW_TRANSFORM),/* mesa */
>> +  (_NEW_TRANSFORM | _NEW_PROGRAM), /* mesa */
>>   0,   /* st */
>>},
>>update_clip /* update */
>> diff --git a/src/mesa/state_tracker/st_program.c 
>> b/src/mesa/state_tracker/st_program.c
>> index 35d0e0f..8d7469d 100644
>> --- a/src/mesa/state_tracker/st_program.c
>> +++ b/src/mesa/state_tracker/st_program.c
>> @@ -255,6 +255,10 @@ st_prepare_vertex_program(struct gl_context *ctx,
>>  case VERT_RESULT_EDGE:
>> assert(0);
>> break;
>> + case VERT_RESULT_CLIP_VERTEX:
>> +stvp->output_semantic_name[slot] = TGSI_SEMANTIC_CLIPVERTEX;
>> +stvp->output_semantic_index[slot] = 0;
>> +break;
>>
>>  case VERT_RESULT_TEX0:
>>  case VERT_RESULT_TEX1:
>>
>> ___
>> mesa-commit mailing list
>> mesa-com...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
> ___
> 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


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Jose Fonseca
Still catching up on email traffic during holidays...

I agree that user buffer uploads should be moved out of drivers, but I don't 
think this is the way to go. 

This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes the ability 
to transform this data in any way before reashing the GPU -- i.e., prevents any 
sort of workarounds -- something can't be always guaranteed. Flushing with map 
helps is also non-portable.


It looks to me that state trackers and/or drivers are not properly using 
PIPE_USAGE_STREAM flag.  As all cases where PIPE_TRANSFER_MAP_PERMANENTLY would 
be used, the right way to do it would be for the state tracker to set 
PIPE_USAGE_STREAM, the pipe driver to recognize PIPE_USAGE_STREAM, and keep the 
mapping permanently internally, making mapping/unmapping of such buffers mere 
no-ops.


In summary, for me PIPE_TRANSFER_MAP_PERMANENTLY is premature/bad optmization.  
Before we are worried about saving a couple of map/unmap calls, we should 
ensure that PIPE_USAGE_STREAM/PIPE_USAGE_DYNAMIC code paths are fully optimal.


Jose

- Original Message -
> Please see the diff for further info.
> 
> This paves the way for moving user buffer uploads out of drivers and
> should
> allow to clean up the mess in u_upload_mgr in the meantime.
> 
> For now only allowed for buffers on r300 and r600.
> ---
>  src/gallium/drivers/i915/i915_resource_buffer.c  |7 ++-
>  src/gallium/drivers/i915/i915_resource_texture.c |7 ++-
>  src/gallium/drivers/llvmpipe/lp_texture.c|4 
>  src/gallium/drivers/nouveau/nouveau_buffer.c |8 +++-
>  src/gallium/drivers/nv50/nv50_transfer.c |2 +-
>  src/gallium/drivers/nvc0/nvc0_transfer.c |2 +-
>  src/gallium/drivers/nvfx/nvfx_transfer.c |3 +++
>  src/gallium/drivers/r300/r300_transfer.c |4 
>  src/gallium/drivers/r600/r600_texture.c  |4 
>  src/gallium/drivers/svga/svga_resource_buffer.c  |4 
>  src/gallium/drivers/svga/svga_resource_texture.c |2 +-
>  src/gallium/include/pipe/p_defines.h |   16
>  
>  12 files changed, 57 insertions(+), 6 deletions(-)
> 
> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c
> b/src/gallium/drivers/i915/i915_resource_buffer.c
> index 77c0345..c54e481 100644
> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
> @@ -68,8 +68,13 @@ i915_get_transfer(struct pipe_context *pipe,
>const struct pipe_box *box)
>  {
> struct i915_context *i915 = i915_context(pipe);
> -   struct pipe_transfer *transfer =
> util_slab_alloc(&i915->transfer_pool);
> +   struct pipe_transfer *transfer;
>  
> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
> +  return NULL;
> +   }
> +
> +   transfer = util_slab_alloc(&i915->transfer_pool);
> if (transfer == NULL)
>return NULL;
>  
> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c
> b/src/gallium/drivers/i915/i915_resource_texture.c
> index 8ff733a..64d071c 100644
> --- a/src/gallium/drivers/i915/i915_resource_texture.c
> +++ b/src/gallium/drivers/i915/i915_resource_texture.c
> @@ -720,9 +720,14 @@ i915_texture_get_transfer(struct pipe_context
> *pipe,
>  {
> struct i915_context *i915 = i915_context(pipe);
> struct i915_texture *tex = i915_texture(resource);
> -   struct i915_transfer *transfer =
> util_slab_alloc(&i915->texture_transfer_pool);
> +   struct i915_transfer *transfer;
> boolean use_staging_texture = FALSE;
>  
> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
> +  return NULL;
> +   }
> +
> +   transfer = util_slab_alloc(&i915->texture_transfer_pool);
> if (transfer == NULL)
>return NULL;
>  
> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
> b/src/gallium/drivers/llvmpipe/lp_texture.c
> index ca38571..d86d493 100644
> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
> @@ -587,6 +587,10 @@ llvmpipe_get_transfer(struct pipe_context *pipe,
> assert(resource);
> assert(level <= resource->last_level);
>  
> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
> +  return NULL;
> +   }
> +
> /*
>  * Transfers, like other pipe operations, must happen in order,
>  so flush the
>  * context if necessary.
> diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
> b/src/gallium/drivers/nouveau/nouveau_buffer.c
> index f822625..02186ba 100644
> --- a/src/gallium/drivers/nouveau/nouveau_buffer.c
> +++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
> @@ -172,7 +172,13 @@ nouveau_buffer_transfer_get(struct pipe_context
> *pipe,
>  {
> struct nv04_resource *buf = nv04_resource(resource);
> struct nouveau_context *nv = nouveau_context(pipe);
> -   struct nouveau_transfer *xfr = CALLOC_STRUCT(nouveau_transfer);
> +   struct nouveau_transfer *xfr;
> +
> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
> +  return NU

Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Christoph Bumiller
On 10.01.2012 12:29, Jose Fonseca wrote:
> Still catching up on email traffic during holidays...
>
> I agree that user buffer uploads should be moved out of drivers, but I don't 
> think this is the way to go. 

I don't. If the state tracker uploads user buffers and presents them to
the driver as normal buffers, it will have to change the
pipe_vertex_buffers for each draw, causing annoying re-validation
overhead. This is very bad if there are a lot of small draw calls.
Unfortunately many applications do this, and we do care about these cases.

Also, another example I'm dealing with atm, it will be difficult to
extract a small set of wide-spread vertices from a user buffer into a
oneshot vertex buffer (there are apps where this really helps a lot)
because you're changing the vertex index / gl_VertexID.
I can do that, because I know the hw has a special vertex-index buffer
(nvc0) or manual VERTEX_ID attribute (nv50) that can be routed to the
VERTEXID system value so I don't need to modify the shader.

> This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes the 
> ability to transform this data in any way before reashing the GPU -- i.e., 
> prevents any sort of workarounds -- something can't be always guaranteed. 
> Flushing with map helps is also non-portable.
>
>
> It looks to me that state trackers and/or drivers are not properly using 
> PIPE_USAGE_STREAM flag.  As all cases where PIPE_TRANSFER_MAP_PERMANENTLY 
> would be used, the right way to do it would be for the state tracker to set 
> PIPE_USAGE_STREAM, the pipe driver to recognize PIPE_USAGE_STREAM, and keep 
> the mapping permanently internally, making mapping/unmapping of such buffers 
> mere no-ops.
>
>
> In summary, for me PIPE_TRANSFER_MAP_PERMANENTLY is premature/bad 
> optmization.  Before we are worried about saving a couple of map/unmap calls, 
> we should ensure that PIPE_USAGE_STREAM/PIPE_USAGE_DYNAMIC code paths are 
> fully optimal.
>
>
> Jose
>
> - Original Message -
>> Please see the diff for further info.
>>
>> This paves the way for moving user buffer uploads out of drivers and
>> should
>> allow to clean up the mess in u_upload_mgr in the meantime.
>>
>> For now only allowed for buffers on r300 and r600.
>> ---
>>  src/gallium/drivers/i915/i915_resource_buffer.c  |7 ++-
>>  src/gallium/drivers/i915/i915_resource_texture.c |7 ++-
>>  src/gallium/drivers/llvmpipe/lp_texture.c|4 
>>  src/gallium/drivers/nouveau/nouveau_buffer.c |8 +++-
>>  src/gallium/drivers/nv50/nv50_transfer.c |2 +-
>>  src/gallium/drivers/nvc0/nvc0_transfer.c |2 +-
>>  src/gallium/drivers/nvfx/nvfx_transfer.c |3 +++
>>  src/gallium/drivers/r300/r300_transfer.c |4 
>>  src/gallium/drivers/r600/r600_texture.c  |4 
>>  src/gallium/drivers/svga/svga_resource_buffer.c  |4 
>>  src/gallium/drivers/svga/svga_resource_texture.c |2 +-
>>  src/gallium/include/pipe/p_defines.h |   16
>>  
>>  12 files changed, 57 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c
>> b/src/gallium/drivers/i915/i915_resource_buffer.c
>> index 77c0345..c54e481 100644
>> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
>> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
>> @@ -68,8 +68,13 @@ i915_get_transfer(struct pipe_context *pipe,
>>const struct pipe_box *box)
>>  {
>> struct i915_context *i915 = i915_context(pipe);
>> -   struct pipe_transfer *transfer =
>> util_slab_alloc(&i915->transfer_pool);
>> +   struct pipe_transfer *transfer;
>>  
>> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
>> +  return NULL;
>> +   }
>> +
>> +   transfer = util_slab_alloc(&i915->transfer_pool);
>> if (transfer == NULL)
>>return NULL;
>>  
>> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c
>> b/src/gallium/drivers/i915/i915_resource_texture.c
>> index 8ff733a..64d071c 100644
>> --- a/src/gallium/drivers/i915/i915_resource_texture.c
>> +++ b/src/gallium/drivers/i915/i915_resource_texture.c
>> @@ -720,9 +720,14 @@ i915_texture_get_transfer(struct pipe_context
>> *pipe,
>>  {
>> struct i915_context *i915 = i915_context(pipe);
>> struct i915_texture *tex = i915_texture(resource);
>> -   struct i915_transfer *transfer =
>> util_slab_alloc(&i915->texture_transfer_pool);
>> +   struct i915_transfer *transfer;
>> boolean use_staging_texture = FALSE;
>>  
>> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
>> +  return NULL;
>> +   }
>> +
>> +   transfer = util_slab_alloc(&i915->texture_transfer_pool);
>> if (transfer == NULL)
>>return NULL;
>>  
>> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
>> b/src/gallium/drivers/llvmpipe/lp_texture.c
>> index ca38571..d86d493 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
>> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
>> @@ -587,6 +587,10 @@ llvm

[Mesa-dev] [PATCH 0/4] nvfx: rework render temps code and fixes

2012-01-10 Thread Lucas Stach
This patch series silences some unknown cap warnings and fixes up   
coding style (patch 1+4).

The most important part of this series are the two patches in the   
middle. They rework the state_fb code, so that we are able to   
render to not 64 byte aligned targets, as this is the only real
use-case for render temporaries this allows us to drop temp code
completely and simplifies a lot of cases.

This is only tested on nv49, but there should be nothing different
in this area for other nv3x or nv4x gpus.

I plan on working on top of that in the following days, so please
review and apply as time permits.

Thanks,
Lucas

Lucas Stach (4):
  nvfx: say no to stream output caps
  nvfx: rework state_fb code to get rid of render temps
  nvfx: drop render temporaries code
  nvfx: random cleanups of the state validation code

 src/gallium/drivers/nvfx/nvfx_context.h|2 +-
 src/gallium/drivers/nvfx/nvfx_fragtex.c|4 -
 src/gallium/drivers/nvfx/nvfx_miptree.c|   18 +---
 src/gallium/drivers/nvfx/nvfx_resource.h   |   30 +-
 src/gallium/drivers/nvfx/nvfx_screen.c |6 +-
 src/gallium/drivers/nvfx/nvfx_state_emit.c |   94 +
 src/gallium/drivers/nvfx/nvfx_state_fb.c   |  155 ++-
 src/gallium/drivers/nvfx/nvfx_surface.c|  136 +++--
 8 files changed, 108 insertions(+), 337 deletions(-)

-- 
1.7.7.5

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


[Mesa-dev] [PATCH 1/4] nvfx: say no to stream output caps

2012-01-10 Thread Lucas Stach
nvfx doesn't support any kind of stream out, so silence the
unused cap warnings.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/nvfx/nvfx_screen.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c 
b/src/gallium/drivers/nvfx/nvfx_screen.c
index b4a1b3a..938d67b 100644
--- a/src/gallium/drivers/nvfx/nvfx_screen.c
+++ b/src/gallium/drivers/nvfx/nvfx_screen.c
@@ -88,8 +88,12 @@ nvfx_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_MAX_TEXEL_OFFSET:
case PIPE_CAP_CONDITIONAL_RENDER:
case PIPE_CAP_TEXTURE_BARRIER:
-return 0;
case PIPE_CAP_MIXED_COLORBUFFER_FORMATS:
+   case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
+   case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
+   case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
+   case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
+   case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
 return 0;
default:
NOUVEAU_ERR("Warning: unknown PIPE_CAP %d\n", param);
-- 
1.7.7.5

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


[Mesa-dev] [PATCH 4/4] nvfx: random cleanups of the state validation code

2012-01-10 Thread Lucas Stach
Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/nvfx/nvfx_state_emit.c |   49 ---
 1 files changed, 22 insertions(+), 27 deletions(-)

diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c 
b/src/gallium/drivers/nvfx/nvfx_state_emit.c
index e2cfb76..a959015 100644
--- a/src/gallium/drivers/nvfx/nvfx_state_emit.c
+++ b/src/gallium/drivers/nvfx/nvfx_state_emit.c
@@ -200,7 +200,6 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
unsigned dirty;
unsigned still_dirty = 0;
boolean flush_tex_cache = FALSE;
-   unsigned render_temps;
 
if(nvfx != nvfx->screen->cur_ctx)
{
@@ -212,14 +211,6 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
nvfx->relocs_needed = NVFX_RELOCATE_ALL;
}
 
-   if(nvfx->dirty & NVFX_NEW_SAMPLER) {
-   nvfx->dirty &=~ NVFX_NEW_SAMPLER;
-   nvfx_fragtex_validate(nvfx);
-
-   // TODO: only set this if really necessary
-   flush_tex_cache = TRUE;
-   }
-
dirty = nvfx->dirty;
 
if(nvfx->render_mode == HW)
@@ -252,6 +243,13 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
}
}
 
+   if(dirty & NVFX_NEW_SAMPLER) {
+   nvfx_fragtex_validate(nvfx);
+
+   // TODO: only set this if really necessary
+   flush_tex_cache = TRUE;
+   }
+
if(dirty & NVFX_NEW_RAST)
sb_emit(chan, nvfx->rasterizer->sb, nvfx->rasterizer->sb_len);
 
@@ -264,10 +262,13 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
if(nvfx->dirty & (NVFX_NEW_UCP | NVFX_NEW_RAST))
   nvfx_ucp_validate(nvfx);
 
-   if(nvfx->use_vp_clipping && (nvfx->dirty & (NVFX_NEW_UCP | 
NVFX_NEW_VERTPROG | NVFX_NEW_RAST)))
+   if(nvfx->use_vp_clipping && (nvfx->dirty &
+(NVFX_NEW_UCP | NVFX_NEW_VERTPROG |
+ NVFX_NEW_RAST)))
nvfx_vertprog_ucp_validate(nvfx);
 
-   if(dirty & (NVFX_NEW_FRAGPROG | NVFX_NEW_FRAGCONST | NVFX_NEW_VERTPROG 
| NVFX_NEW_SPRITE))
+   if(dirty & (NVFX_NEW_FRAGPROG | NVFX_NEW_FRAGCONST |
+   NVFX_NEW_VERTPROG | NVFX_NEW_SPRITE))
{
nvfx_fragprog_validate(nvfx);
if(dirty & NVFX_NEW_FRAGPROG)
@@ -302,11 +303,7 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
if(dirty & NVFX_NEW_SR)
nvfx_state_sr_validate(nvfx);
 
-/* All these dependencies are wrong, but otherwise
-   etracer, neverball, foobillard, glest totally misrender
-   TODO: find the right fix
-*/
-   if(dirty & (NVFX_NEW_VIEWPORT | NVFX_NEW_RAST | NVFX_NEW_ZSA))
+   if(dirty & NVFX_NEW_VIEWPORT)
{
nvfx_state_viewport_validate(nvfx);
}
@@ -314,23 +311,21 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
if(dirty & (NVFX_NEW_ZSA | NVFX_NEW_FB))
{
BEGIN_RING(chan, eng3d, NV30_3D_DEPTH_WRITE_ENABLE, 2);
-   OUT_RING(chan, nvfx->framebuffer.zsbuf && 
nvfx->zsa->pipe.depth.writemask);
-   OUT_RING(chan, nvfx->framebuffer.zsbuf && 
nvfx->zsa->pipe.depth.enabled);
+   OUT_RING(chan, nvfx->framebuffer.zsbuf &&
+   nvfx->zsa->pipe.depth.writemask);
+   OUT_RING(chan, nvfx->framebuffer.zsbuf &&
+   nvfx->zsa->pipe.depth.enabled);
}
 
if(dirty & (NVFX_NEW_FRAGPROG | NVFX_NEW_FB))
nvfx_coord_conventions_validate(nvfx);
 
-   if(flush_tex_cache)
+   if(flush_tex_cache && nvfx->is_nv4x)
{
-   // TODO: what about nv30?
-   if(nvfx->is_nv4x)
-   {
-   BEGIN_RING(chan, eng3d, NV40_3D_TEX_CACHE_CTL, 1);
-   OUT_RING(chan, 2);
-   BEGIN_RING(chan, eng3d, NV40_3D_TEX_CACHE_CTL, 1);
-   OUT_RING(chan, 1);
-   }
+   BEGIN_RING(chan, eng3d, NV40_3D_TEX_CACHE_CTL, 1);
+   OUT_RING(chan, 2);
+   BEGIN_RING(chan, eng3d, NV40_3D_TEX_CACHE_CTL, 1);
+   OUT_RING(chan, 1);
}
 
nvfx->dirty = dirty & still_dirty;
-- 
1.7.7.5

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


[Mesa-dev] [PATCH 2/4] nvfx: rework state_fb code to get rid of render temps

2012-01-10 Thread Lucas Stach
This commit rewrites a lot of the state_fb code to support
rendering to targets not aligned to 64 byte.

This allows us to drop the render temporaries as unaligned
targets are the only use-case where they are really needed. The
temporaries code was used for a lot of things more, but apparently
those also work without temps.

There is one regression in piglit fbo-clear-formats, but this will
be fixed with the use of real hardware clears and doesn't matter in
practice as no real application tries to scissor clear a 2x2 pixel
render target.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/nvfx/nvfx_context.h|2 +-
 src/gallium/drivers/nvfx/nvfx_state_emit.c |   59 ++-
 src/gallium/drivers/nvfx/nvfx_state_fb.c   |  155 ++-
 src/gallium/drivers/nvfx/nvfx_surface.c|2 +
 4 files changed, 72 insertions(+), 146 deletions(-)

diff --git a/src/gallium/drivers/nvfx/nvfx_context.h 
b/src/gallium/drivers/nvfx/nvfx_context.h
index 09d394b..019be6c 100644
--- a/src/gallium/drivers/nvfx/nvfx_context.h
+++ b/src/gallium/drivers/nvfx/nvfx_context.h
@@ -247,7 +247,7 @@ extern void nvfx_vtxfmt_validate(struct nvfx_context *nvfx);
 
 /* nvfx_fb.c */
 extern int nvfx_framebuffer_prepare(struct nvfx_context *nvfx);
-extern void nvfx_framebuffer_validate(struct nvfx_context *nvfx, unsigned 
prepare_result);
+extern void nvfx_framebuffer_validate(struct nvfx_context *nvfx);
 void
 nvfx_framebuffer_relocate(struct nvfx_context *nvfx);
 
diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c 
b/src/gallium/drivers/nvfx/nvfx_state_emit.c
index 25da80e..e2cfb76 100644
--- a/src/gallium/drivers/nvfx/nvfx_state_emit.c
+++ b/src/gallium/drivers/nvfx/nvfx_state_emit.c
@@ -199,7 +199,6 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
struct nouveau_grobj *eng3d = nvfx->screen->eng3d;
unsigned dirty;
unsigned still_dirty = 0;
-   int new_fb_mode = -1; /* 1 = all swizzled, 0 = make all linear */
boolean flush_tex_cache = FALSE;
unsigned render_temps;
 
@@ -213,29 +212,12 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
nvfx->relocs_needed = NVFX_RELOCATE_ALL;
}
 
-   /* These can trigger use the of 3D engine to copy temporaries.
-* That will recurse here and thus dirty all 3D state, so we need to 
this before anything else, and in a loop..
-* This converges to having clean temps, then binding both fragtexes 
and framebuffers.
-*/
-   while(nvfx->dirty & (NVFX_NEW_FB | NVFX_NEW_SAMPLER))
-   {
-   if(nvfx->dirty & NVFX_NEW_SAMPLER)
-   {
-   nvfx->dirty &=~ NVFX_NEW_SAMPLER;
-   nvfx_fragtex_validate(nvfx);
-
-   // TODO: only set this if really necessary
-   flush_tex_cache = TRUE;
-   }
+   if(nvfx->dirty & NVFX_NEW_SAMPLER) {
+   nvfx->dirty &=~ NVFX_NEW_SAMPLER;
+   nvfx_fragtex_validate(nvfx);
 
-   if(nvfx->dirty & NVFX_NEW_FB)
-   {
-   nvfx->dirty &=~ NVFX_NEW_FB;
-   new_fb_mode = nvfx_framebuffer_prepare(nvfx);
-
-   // TODO: make sure this doesn't happen, i.e. fbs have 
matching formats
-   assert(new_fb_mode >= 0);
-   }
+   // TODO: only set this if really necessary
+   flush_tex_cache = TRUE;
}
 
dirty = nvfx->dirty;
@@ -305,8 +287,8 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
}
}
 
-   if(new_fb_mode >= 0)
-   nvfx_framebuffer_validate(nvfx, new_fb_mode);
+   if(dirty & NVFX_NEW_FB)
+   nvfx_framebuffer_validate(nvfx);
 
if(dirty & NVFX_NEW_BLEND)
sb_emit(chan, nvfx->blend->sb, nvfx->blend->sb_len);
@@ -324,19 +306,19 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
etracer, neverball, foobillard, glest totally misrender
TODO: find the right fix
 */
-   if(dirty & (NVFX_NEW_VIEWPORT | NVFX_NEW_RAST | NVFX_NEW_ZSA) || 
(new_fb_mode >= 0))
+   if(dirty & (NVFX_NEW_VIEWPORT | NVFX_NEW_RAST | NVFX_NEW_ZSA))
{
nvfx_state_viewport_validate(nvfx);
}
 
-   if(dirty & NVFX_NEW_ZSA || (new_fb_mode >= 0))
+   if(dirty & (NVFX_NEW_ZSA | NVFX_NEW_FB))
{
BEGIN_RING(chan, eng3d, NV30_3D_DEPTH_WRITE_ENABLE, 2);
OUT_RING(chan, nvfx->framebuffer.zsbuf && 
nvfx->zsa->pipe.depth.writemask);
-   OUT_RING(chan, nvfx->framebuffer.zsbuf && 
nvfx->zsa->pipe.depth.enabled);
+   OUT_RING(chan, nvfx->framebuffer.zsbuf && 
nvfx->zsa->pipe.depth.enabled);
}
 
-   if((new_fb_mode >= 0) || (dirty & NVFX_NEW_FRAGPROG))
+   if(dirty & (NVFX_NEW_FRAGPROG | NVFX_NEW_FB))
nvfx_coord_conventions_validate(nvfx);
 
if(flush_tex_cache)
@@ -353,25 +335,6

[Mesa-dev] [PATCH 3/4] nvfx: drop render temporaries code

2012-01-10 Thread Lucas Stach
This code is unneeded now, we don't use render temps any more.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/nvfx/nvfx_fragtex.c  |4 -
 src/gallium/drivers/nvfx/nvfx_miptree.c  |   18 +---
 src/gallium/drivers/nvfx/nvfx_resource.h |   30 +--
 src/gallium/drivers/nvfx/nvfx_surface.c  |  138 +++---
 4 files changed, 18 insertions(+), 172 deletions(-)

diff --git a/src/gallium/drivers/nvfx/nvfx_fragtex.c 
b/src/gallium/drivers/nvfx/nvfx_fragtex.c
index cb87539..036991e 100644
--- a/src/gallium/drivers/nvfx/nvfx_fragtex.c
+++ b/src/gallium/drivers/nvfx/nvfx_fragtex.c
@@ -189,10 +189,6 @@ nvfx_fragtex_validate(struct nvfx_context *nvfx)
samplers &= ~(1 << unit);
 
if(nvfx->fragment_sampler_views[unit] && 
nvfx->tex_sampler[unit]) {
-   util_dirty_surfaces_use_for_sampling(&nvfx->pipe,
-   &((struct 
nvfx_miptree*)nvfx->fragment_sampler_views[unit]->texture)->dirty_surfaces,
-   nvfx_surface_flush);
-
if(!nvfx->is_nv4x)
nv30_fragtex_set(nvfx, unit);
else
diff --git a/src/gallium/drivers/nvfx/nvfx_miptree.c 
b/src/gallium/drivers/nvfx/nvfx_miptree.c
index 8695aa3..dd9ad35 100644
--- a/src/gallium/drivers/nvfx/nvfx_miptree.c
+++ b/src/gallium/drivers/nvfx/nvfx_miptree.c
@@ -99,9 +99,7 @@ nvfx_miptree_layout(struct nvfx_miptree *mt)
 static void
 nvfx_miptree_surface_final_destroy(struct pipe_surface* ps)
 {
-   struct nvfx_surface* ns = (struct nvfx_surface*)ps;
pipe_resource_reference(&ps->texture, 0);
-   pipe_resource_reference((struct pipe_resource**)&ns->temp, 0);
FREE(ps);
 }
 
@@ -127,7 +125,6 @@ nvfx_miptree_create_skeleton(struct pipe_screen *pscreen, 
const struct pipe_reso
 return NULL;
 
 mt->base.base = *pt;
-util_dirty_surfaces_init(&mt->dirty_surfaces);
 
 pipe_reference_init(&mt->base.base.reference, 1);
 mt->base.base.screen = pscreen;
@@ -201,24 +198,17 @@ nvfx_miptree_surface_new(struct pipe_context *pipe, 
struct pipe_resource *pt,
if(util_surfaces_get(&mt->surfaces, sizeof(struct nvfx_surface), pipe,
  pt, level, surf_tmpl->u.tex.first_layer,
  surf_tmpl->usage, (struct pipe_surface **)&ns)) {
-util_dirty_surface_init(&ns->base);
 ns->pitch = nvfx_subresource_pitch(pt, level);
 ns->offset = nvfx_subresource_offset(pt, 
surf_tmpl->u.tex.first_layer, level, surf_tmpl->u.tex.first_layer);
}
 
-   return &ns->base.base;
+   return &ns->base;
 }
 
 void
 nvfx_miptree_surface_del(struct pipe_context *pipe, struct pipe_surface *ps)
 {
-   struct nvfx_surface* ns = (struct nvfx_surface*)ps;
-
-   if(!ns->temp)
-   {
-   assert(!util_dirty_surface_is_dirty(&ns->base));
-   util_surfaces_detach(&((struct 
nvfx_miptree*)ps->texture)->surfaces, ps);
-   pipe_resource_reference(&ps->texture, 0);
-   FREE(ps);
-   }
+   util_surfaces_detach(&((struct nvfx_miptree*)ps->texture)->surfaces, 
ps);
+   pipe_resource_reference(&ps->texture, 0);
+   FREE(ps);
 }
diff --git a/src/gallium/drivers/nvfx/nvfx_resource.h 
b/src/gallium/drivers/nvfx/nvfx_resource.h
index 6e0493f..4a66358 100644
--- a/src/gallium/drivers/nvfx/nvfx_resource.h
+++ b/src/gallium/drivers/nvfx/nvfx_resource.h
@@ -47,18 +47,6 @@ nvfx_resource_on_gpu(struct pipe_resource* pr)
 
 #define NVFX_MAX_TEXTURE_LEVELS  16
 
-/* We have the following invariants for render temporaries
- *
- * 1. Render temporaries are always linear
- * 2. Render temporaries are always up to date
- * 3. Currently, render temporaries are destroyed when the resource is used 
for sampling, but kept for any other use
- *
- * Also, we do NOT flush temporaries on any pipe->flush().
- * This is fine, as long as scanout targets and shared resources never need 
temps.
- *
- * TODO: we may want to also support swizzled temporaries to improve 
performance in some cases.
- */
-
 struct nvfx_miptree {
 struct nvfx_resource base;
 
@@ -67,15 +55,12 @@ struct nvfx_miptree {
 unsigned level_offset[NVFX_MAX_TEXTURE_LEVELS];
 
 struct util_surfaces surfaces;
-struct util_dirty_surfaces dirty_surfaces;
 };
 
 struct nvfx_surface {
-   struct util_dirty_surface base;
+   struct pipe_surface base;
unsigned pitch;
unsigned offset;
-
-   struct nvfx_miptree* temp;
 };
 
 static INLINE struct nouveau_bo *
@@ -86,13 +71,6 @@ nvfx_surface_buffer(struct pipe_surface *surf)
return mt->bo;
 }
 
-static INLINE struct util_dirty_surfaces*
-nvfx_surface_get_dirty_surfaces(struct pipe_surface* surf)
-{
-   struct nvfx_miptree *mt = (struct nvfx_miptree *)surf->texture;
-   return &mt->dirty_surfaces;
-}
-
 void
 nvfx_ini

[Mesa-dev] [PATCH 2/2] draw/softpipe: allow softpipe to set shader params depending on runtime llvm

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

If draw isn't using llvm we can support vertex texture and integers,
These will be fixed up later, but for now allow this check to happen
at run-time.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/draw/draw_context.c |   10 ++
 src/gallium/auxiliary/draw/draw_context.h |2 ++
 src/gallium/drivers/softpipe/sp_screen.c  |   12 +---
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_context.c 
b/src/gallium/auxiliary/draw/draw_context.c
index f91e408..f1c9eb8 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -106,6 +106,16 @@ err_out:
return NULL;
 }
 
+bool
+draw_using_llvm(void)
+{
+#if HAVE_LLVM
+   if (draw_get_option_use_llvm()) {
+ return TRUE;
+   }
+#endif
+   return FALSE;
+}
 
 /**
  * Create new draw module context, with LLVM JIT.
diff --git a/src/gallium/auxiliary/draw/draw_context.h 
b/src/gallium/auxiliary/draw/draw_context.h
index 7655ad0..63ba0de 100644
--- a/src/gallium/auxiliary/draw/draw_context.h
+++ b/src/gallium/auxiliary/draw/draw_context.h
@@ -56,6 +56,8 @@ struct draw_context *draw_create( struct pipe_context *pipe );
 
 struct draw_context *draw_create_no_llvm(struct pipe_context *pipe);
 
+bool draw_using_llvm(void);
+
 struct draw_context *
 draw_create_gallivm(struct pipe_context *pipe, struct gallivm_state *gallivm);
 
diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
b/src/gallium/drivers/softpipe/sp_screen.c
index 07f1970..090e8e5 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -141,11 +141,17 @@ softpipe_get_shader_param(struct pipe_screen *screen, 
unsigned shader, enum pipe
   switch (param) {
   case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
 #ifdef HAVE_LLVM
- /* Softpipe doesn't yet know how to tell draw/llvm about textures */
- return 0;
-#else
+ if (draw_using_llvm())
+/* Softpipe doesn't yet know how to tell draw/llvm about textures 
*/
+return 0;
+#endif
  return PIPE_MAX_VERTEX_SAMPLERS;
+  case PIPE_SHADER_CAP_INTEGERS:
+#ifdef HAVE_LLVM /* gallivm doesn't support integers yet */
+ if (draw_using_llvm())
+return 0;
 #endif
+ /* fallthrough */
   default:
  return draw_get_shader_param(shader, param);
   }
-- 
1.7.7.4

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


[Mesa-dev] [PATCH 1/2] st_extensions: fixup GLSL 1.30 related enables

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

This just fixes up the enables for native integers and EXT_texture_integer
support in st/mesa.

It also set the MaxClipPlanes to 8.

We should consider exposing caps for MCP vs MCD, but since core
mesa doesn't care yet maybe we can wait for now.

Signed-off-by: Dave Airlie 
---
 src/mesa/state_tracker/st_extensions.c |   31 +--
 1 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index a9d4054..d583c88 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -263,12 +263,6 @@ void st_init_extensions(struct st_context *st)
ctx->Const.GLSLVersion = 120;
_mesa_override_glsl_version(st->ctx);
 
-   /* Extensions that only depend on the GLSL version:
-*/
-   if (ctx->Const.GLSLVersion >= 130) {
-  ctx->Extensions.ARB_conservative_depth = GL_TRUE;
-   }
-
/*
 * Extensions that are supported by all Gallium drivers:
 */
@@ -587,6 +581,23 @@ void st_init_extensions(struct st_context *st)
 #endif
}
 
+   if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
+PIPE_SHADER_CAP_INTEGERS) &&
+   screen->get_shader_param(screen, PIPE_SHADER_FRAGMENT,
+PIPE_SHADER_CAP_INTEGERS)) {
+  ctx->Const.NativeIntegers = GL_TRUE;
+   }
+
+   if (ctx->Const.NativeIntegers)
+  ctx->Const.GLSLVersion = 130;
+
+   /* Extensions that only depend on the GLSL version:
+*/
+   if (ctx->Const.GLSLVersion >= 130) {
+  ctx->Extensions.ARB_conservative_depth = GL_TRUE;
+  ctx->Const.MaxClipPlanes = 8;
+   }
+
ctx->Extensions.NV_primitive_restart = GL_TRUE;
if (!screen->get_param(screen, PIPE_CAP_PRIMITIVE_RESTART)) {
   st->sw_primitive_restart = GL_TRUE;
@@ -703,4 +714,12 @@ void st_init_extensions(struct st_context *st)
  ctx->Extensions.ARB_transform_feedback2 = GL_TRUE;
   }
}
+
+   if (ctx->Const.NativeIntegers &&
+   screen->is_format_supported(screen, PIPE_FORMAT_R8G8B8A8_UINT, 
PIPE_TEXTURE_2D, 0,
+   PIPE_BIND_SAMPLER_VIEW | 
PIPE_BIND_RENDER_TARGET) &&
+   screen->is_format_supported(screen, PIPE_FORMAT_R8G8B8A8_SINT, 
PIPE_TEXTURE_2D, 0,
+   PIPE_BIND_SAMPLER_VIEW | 
PIPE_BIND_RENDER_TARGET))
+  ctx->Extensions.EXT_texture_integer = GL_TRUE;
+
 }
-- 
1.7.7.4

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


[Mesa-dev] [PATCH] [rfc] mesa: don't allow GLSL 1.30 without GL3.

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

Things can get confused if you expose one without the other which can happen
if you are missing one or two of the extensions (like say float textures).

Signed-off-by: Dave Airlie 
---
 src/mesa/main/version.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 49cdc30..57c8340 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -223,6 +223,9 @@ compute_version(struct gl_context *ctx)
ctx->VersionMajor = major;
ctx->VersionMinor = minor;
 
+   if (ctx->VersionMajor == 2 && ctx->Const.GLSLVersion >= 130)
+  ctx->Const.GLSLVersion = 120;
+
override_version(ctx, &ctx->VersionMajor, &ctx->VersionMinor);
 
ctx->VersionString = (char *) malloc(max);
-- 
1.7.7.3

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


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Jose Fonseca
- Original Message -
> On 10.01.2012 12:29, Jose Fonseca wrote:
> > Still catching up on email traffic during holidays...
> >
> > I agree that user buffer uploads should be moved out of drivers,
> > but I don't think this is the way to go.
> 
> I don't. If the state tracker uploads user buffers and presents them
> to
> the driver as normal buffers, it will have to change the
> pipe_vertex_buffers for each draw, causing annoying re-validation
> overhead. 

This is not strictly necessary.  We could simply use index_bias provided the 
vertex strides don't change (the likely scenario for the sort of cases you are 
talking here). Thomas did that something along those lines for the svga driver.

And we could do much better than that: I'm talking about proper 
reverse-engineering of the application intention, such as using one-shot 
dynamic vertex buffers for one-shot data, and reusable static vertex buffers 
for immutable data. Employing both heuristics like scanning the user memory for 
changes and end of data; and also get information from the OS virtual memory 
subsystem (e.g., if the user memory pointer is in a read-only segment then it 
won't likely change, if it's in a stack segment it will likely be one-off, if 
its in malloc, then we can get an upper bound from the OS).   This analysis / 
memory tracking is something too complex to do for each driver, but worthwhile 
if its done in the state tracker for all drivers benefit.

I honestly think that's unnecessary to bother pipe drivers with user pointers 
and that we should put our bets on solving this problem efficiently once for 
all -- but I'm fine leaving these user pointers in the interface eternally, for 
sake of both skeptics and software renderers (who can always benefit from 
accessing user memory directly). 


> This is very bad if there are a lot of small draw calls.
> Unfortunately many applications do this, and we do care about these
> cases.
> 
> Also, another example I'm dealing with atm, it will be difficult to
> extract a small set of wide-spread vertices from a user buffer into a
> oneshot vertex buffer (there are apps where this really helps a lot)
> because you're changing the vertex index / gl_VertexID.
> I can do that, because I know the hw has a special vertex-index
> buffer
> (nvc0) or manual VERTEX_ID attribute (nv50) that can be routed to the
> VERTEXID system value so I don't need to modify the shader.

Backing user buffers on hardware buffers does not necessary imply remapping 
vertices -- that's merely how it is implemented now. We could either create a 
one-shot hardware buffer with the same size and fill in just the necessary 
spots; or better to recognize the underlying user memory buffer start and size 
and track changes. We could also expose this vertex-index buffer in the 
interface (other drivers could implement it as vertex texture).


Probably the best approach is a mixture: back big dynamic/static user buffers 
in individual hardware buffers, back small dynamic user buffers in linearly 
suballocated ranges of coarse sized hardware buffers (i.e., what we do now).


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


Re: [Mesa-dev] Mesa (master): st/mesa: add support for clip vertex.

2012-01-10 Thread Kai Wasserbäch
Dear Stéphane,
Stéphane Marchesin schrieb am 10.01.2012 04:52:
> This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
> piglit test on i915g.

this looks like bz#44561 [0] to me. If so we should take the discussion there to
have it in one place.

Kind regards,
Kai Wasserbäch


[0] 



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] mesa/clear: fix crashes with illegal clear tests.

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

Mesa shouldn't call into the drivers if there are no renderbuffers
bound to the attachments for the buffers to be cleared.

Fixes a number of the clearbuffer-* tests on softpipe.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/clear.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index bd5c012..a340f99 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -338,7 +338,7 @@ _mesa_ClearBufferiv(GLenum buffer, GLint drawbuffer, const 
GLint *value)
  drawbuffer);
  return;
   }
-  else if (!ctx->RasterDiscard) {
+  else if (ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer && 
!ctx->RasterDiscard) {
  /* Save current stencil clear value, set to 'value', do the
   * stencil clear and restore the clear value.
   * XXX in the future we may have a new ctx->Driver.ClearBuffer()
@@ -513,7 +513,7 @@ _mesa_ClearBufferfv(GLenum buffer, GLint drawbuffer, const 
GLfloat *value)
  drawbuffer);
  return;
   }
-  else if (!ctx->RasterDiscard) {
+  else if (ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer && 
!ctx->RasterDiscard) {
  /* Save current depth clear value, set to 'value', do the
   * depth clear and restore the clear value.
   * XXX in the future we may have a new ctx->Driver.ClearBuffer()
@@ -592,6 +592,8 @@ _mesa_ClearBufferfi(GLenum buffer, GLint drawbuffer,
 GLfloat depth, GLint stencil)
 {
GET_CURRENT_CONTEXT(ctx);
+   int mask = 0;
+
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
 
FLUSH_CURRENT(ctx, 0);
@@ -622,7 +624,12 @@ _mesa_ClearBufferfi(GLenum buffer, GLint drawbuffer,
   _mesa_update_state( ctx );
}
 
-   {
+   if (ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer)
+  mask |= BUFFER_BIT_DEPTH;
+   if (ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer)
+  mask |= BUFFER_BIT_STENCIL;
+
+   if (mask) {
   /* save current clear values */
   const GLclampd clearDepthSave = ctx->Depth.Clear;
   const GLuint clearStencilSave = ctx->Stencil.Clear;
@@ -636,7 +643,7 @@ _mesa_ClearBufferfi(GLenum buffer, GLint drawbuffer,
  ctx->Driver.ClearStencil(ctx, stencil);
 
   /* clear buffers */
-  ctx->Driver.Clear(ctx, BUFFER_BIT_DEPTH | BUFFER_BIT_STENCIL);
+  ctx->Driver.Clear(ctx, mask);
 
   /* restore */
   ctx->Depth.Clear = clearDepthSave;
-- 
1.7.7.4

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


Re: [Mesa-dev] [PATCH 2/2] draw/softpipe: allow softpipe to set shader params depending on runtime llvm

2012-01-10 Thread Jakob Bornecrantz
On Tue, Jan 10, 2012 at 12:49 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> If draw isn't using llvm we can support vertex texture and integers,
> These will be fixed up later, but for now allow this check to happen
> at run-time.

With my draw_create_no_llvm change this logic no longer holds true, you should
just look at the at the draw::llvm field, you probably still need that
function since
we are pretending the draw context is private.

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


Re: [Mesa-dev] [PATCH 2/2] draw/softpipe: allow softpipe to set shader params depending on runtime llvm

2012-01-10 Thread Dave Airlie
On Tue, Jan 10, 2012 at 1:08 PM, Jakob Bornecrantz  wrote:
> On Tue, Jan 10, 2012 at 12:49 PM, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> If draw isn't using llvm we can support vertex texture and integers,
>> These will be fixed up later, but for now allow this check to happen
>> at run-time.
>
> With my draw_create_no_llvm change this logic no longer holds true, you should
> just look at the at the draw::llvm field, you probably still need that
> function since
> we are pretending the draw context is private.

Ah yes, so we have a chick/egg problem, but I can fix it in softpipe
now with your changes.

The problem is we don't have a context only a screen at the time we
report the caps.

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


[Mesa-dev] [PATCH] softpipe: allow softpipe to set shader params depending on runtime llvm (v2)

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

If draw isn't using llvm we can support vertex texture and integers,
These will be fixed up later, but for now allow this check to happen
at run-time.

v2: since 3e22c7a25321554a32fa6254485912fd53deff3a we can ask draw for a 
non-llvm
context. Just track if ask and set the vars accordingly. This probably isn't 
perfect but should cover the cases we care about.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/softpipe/sp_context.c |2 +-
 src/gallium/drivers/softpipe/sp_screen.c  |   26 +++---
 src/gallium/drivers/softpipe/sp_screen.h  |3 ++-
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/softpipe/sp_context.c 
b/src/gallium/drivers/softpipe/sp_context.c
index e533e5a..779832e 100644
--- a/src/gallium/drivers/softpipe/sp_context.c
+++ b/src/gallium/drivers/softpipe/sp_context.c
@@ -304,7 +304,7 @@ softpipe_create_context( struct pipe_screen *screen,
/*
 * Create drawing context and plug our rendering stage into it.
 */
-   if (debug_get_bool_option("SOFTPIPE_USE_LLVM", FALSE))
+   if (softpipe_using_draw_llvm())
   softpipe->draw = draw_create(&softpipe->pipe);
else
   softpipe->draw = draw_create_no_llvm(&softpipe->pipe);
diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
b/src/gallium/drivers/softpipe/sp_screen.c
index 982af6b..bedf0b0 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -45,6 +45,20 @@
 #include "sp_fence.h"
 #include "sp_public.h"
 
+boolean
+softpipe_using_draw_llvm(void)
+{
+   static int using_draw_llvm = -1;
+
+   if (using_draw_llvm == -1) {
+  if (debug_get_bool_option("SOFTPIPE_USE_LLVM", FALSE))
+ using_draw_llvm = 1;
+  else
+ using_draw_llvm = 0;
+   }
+
+   return using_draw_llvm ? TRUE : FALSE;
+}
 
 static const char *
 softpipe_get_vendor(struct pipe_screen *screen)
@@ -144,11 +158,17 @@ softpipe_get_shader_param(struct pipe_screen *screen, 
unsigned shader, enum pipe
   switch (param) {
   case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
 #ifdef HAVE_LLVM
- /* Softpipe doesn't yet know how to tell draw/llvm about textures */
- return 0;
-#else
+ if (softpipe_using_draw_llvm())
+/* Softpipe doesn't yet know how to tell draw/llvm about textures 
*/
+return 0;
+#endif
  return PIPE_MAX_VERTEX_SAMPLERS;
+  case PIPE_SHADER_CAP_INTEGERS:
+#ifdef HAVE_LLVM /* gallivm doesn't support integers yet */
+ if (softpipe_using_draw_llvm())
+return 0;
 #endif
+ /* fallthrough */
   default:
  return draw_get_shader_param(shader, param);
   }
diff --git a/src/gallium/drivers/softpipe/sp_screen.h 
b/src/gallium/drivers/softpipe/sp_screen.h
index f741454..0a19bba 100644
--- a/src/gallium/drivers/softpipe/sp_screen.h
+++ b/src/gallium/drivers/softpipe/sp_screen.h
@@ -48,7 +48,8 @@ struct softpipe_screen {
unsigned timestamp;  
 };
 
-
+boolean
+softpipe_using_draw_llvm(void);
 
 
 static INLINE struct softpipe_screen *
-- 
1.7.7.3

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


[Mesa-dev] [PATCH 1/4] tgsi/softpipe: add VertexID support.

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

This required changing the system value semantics, so we stored
a system value per vertex, instance id is the only other system
value we currently support, so I span it across the channels.

This passes the 3 vertexid-* piglit tests + lots of instanceid tests.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/draw/draw_vs_exec.c |9 -
 src/gallium/auxiliary/tgsi/tgsi_exec.c|   14 ++
 src/gallium/auxiliary/tgsi/tgsi_exec.h|2 +-
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_vs_exec.c 
b/src/gallium/auxiliary/draw/draw_vs_exec.c
index 3f89881..bfe7aea 100644
--- a/src/gallium/auxiliary/draw/draw_vs_exec.c
+++ b/src/gallium/auxiliary/draw/draw_vs_exec.c
@@ -103,7 +103,8 @@ vs_exec_run_linear( struct draw_vertex_shader *shader,
if (shader->info.uses_instanceid) {
   unsigned i = machine->SysSemanticToIndex[TGSI_SEMANTIC_INSTANCEID];
   assert(i < Elements(machine->SystemValue));
-  machine->SystemValue[i][0] = shader->draw->instance_id;
+  for (j = 0; j < QUAD_SIZE; j++)
+ machine->SystemValue[i].i[j] = shader->draw->instance_id;
}
 
for (i = 0; i < count; i += MAX_TGSI_VERTICES) {
@@ -123,6 +124,12 @@ vs_exec_run_linear( struct draw_vertex_shader *shader,
  }
 #endif
 
+ if (shader->info.uses_vertexid) {
+unsigned vid = machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID];
+assert(vid < Elements(machine->SystemValue));
+machine->SystemValue[vid].i[j] = i + j;
+ }
+
  for (slot = 0; slot < shader->info.num_inputs; slot++) {
 #if 0
 assert(!util_is_inf_or_nan(input[slot][0]));
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 52d4ff4..3046656 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1037,6 +1037,7 @@ micro_sub(union tgsi_exec_channel *dst,
 
 static void
 fetch_src_file_channel(const struct tgsi_exec_machine *mach,
+   const uint chan_index,
const uint file,
const uint swizzle,
const union tgsi_exec_channel *index,
@@ -1097,7 +1098,7 @@ fetch_src_file_channel(const struct tgsi_exec_machine 
*mach,
* gl_FragCoord, for example, in a sys value register.
*/
   for (i = 0; i < QUAD_SIZE; i++) {
- chan->f[i] = mach->SystemValue[index->i[i]][0];
+ chan->u[i] = mach->SystemValue[index->i[i]].u[i];
   }
   break;
 
@@ -1221,6 +1222,7 @@ fetch_source(const struct tgsi_exec_machine *mach,
   /* get current value of address register[swizzle] */
   swizzle = tgsi_util_get_src_register_swizzle( ®->Indirect, CHAN_X );
   fetch_src_file_channel(mach,
+ chan_index,
  reg->Indirect.File,
  swizzle,
  &index2,
@@ -1280,6 +1282,7 @@ fetch_source(const struct tgsi_exec_machine *mach,
 
  swizzle = tgsi_util_get_src_register_swizzle( ®->DimIndirect, 
CHAN_X );
  fetch_src_file_channel(mach,
+chan_index,
 reg->DimIndirect.File,
 swizzle,
 &index2,
@@ -1314,6 +1317,7 @@ fetch_source(const struct tgsi_exec_machine *mach,
 
swizzle = tgsi_util_get_full_src_register_swizzle( reg, chan_index );
fetch_src_file_channel(mach,
+  chan_index,
   reg->Register.File,
   swizzle,
   &index,
@@ -1384,6 +1388,7 @@ store_dest(struct tgsi_exec_machine *mach,
 
   /* fetch values from the address/indirection register */
   fetch_src_file_channel(mach,
+ chan_index,
  reg->Indirect.File,
  swizzle,
  &index,
@@ -1433,6 +1438,7 @@ store_dest(struct tgsi_exec_machine *mach,
 
  swizzle = tgsi_util_get_src_register_swizzle( ®->DimIndirect, 
CHAN_X );
  fetch_src_file_channel(mach,
+chan_index,
 reg->DimIndirect.File,
 swizzle,
 &index2,
@@ -1995,11 +2001,11 @@ exec_txf(struct tgsi_exec_machine *mach,
if (inst->Texture.NumOffsets == 1) {
   union tgsi_exec_channel index;
   index.i[0] = index.i[1] = index.i[2] = index.i[3] = 
inst->TexOffsets[0].Index;
-  fetch_src_file_channel(mach, inst->TexOffsets[0].File,
+  fetch_src_file_channel(mach, 0, inst->TexOffsets[0].File,
  inst->TexOffsets[0].SwizzleX, &index, &ZeroVec, 
&offset[0]);
-  fetch_src_file_channel(mach, inst->TexOffsets[0].File,
+  fetch_src_file_channel(

[Mesa-dev] [PATCH 2/4] draw/softpipe: add clip vertex support. (v2)

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

softpipe always clipped using the position vector, however for unclipped
vertices it stored the position in window coordinates, however when position
and clipping are separated, we need to store the clip-space position and
the clip-space vertex clip, so we can interpolate both separately.

This means we have to take the clip space position and store it to use later.

This allows softpipe to pass all the clip-vertex piglit tests.

v2: fix llvm draw regression, the structure being passed into llvm needed
updating, remove some hardcoded ints that should have been enums while there.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/draw/draw_cliptest_tmp.h |   17 -
 src/gallium/auxiliary/draw/draw_context.c  |   10 ++
 src/gallium/auxiliary/draw/draw_llvm.c |   12 
 src/gallium/auxiliary/draw/draw_llvm.h |   10 +++---
 src/gallium/auxiliary/draw/draw_pipe_clip.c|9 ++---
 src/gallium/auxiliary/draw/draw_private.h  |4 +++-
 src/gallium/auxiliary/draw/draw_pt_fetch.c |4 ++--
 src/gallium/auxiliary/draw/draw_vs.c   |9 +
 src/gallium/auxiliary/draw/draw_vs.h   |1 +
 9 files changed, 58 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h 
b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
index 9e6827c..7dba49b 100644
--- a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
@@ -35,11 +35,13 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
const float *trans = pvs->draw->viewport.translate;
/* const */ float (*plane)[4] = pvs->draw->plane;
const unsigned pos = draw_current_shader_position_output(pvs->draw);
+   const unsigned cv = draw_current_shader_clipvertex_output(pvs->draw);
const unsigned ef = pvs->draw->vs.edgeflag_output;
const unsigned ucp_enable = pvs->draw->rasterizer->clip_plane_enable;
const unsigned flags = (FLAGS);
unsigned need_pipeline = 0;
unsigned j;
+   unsigned i;
 
for (j = 0; j < info->count; j++) {
   float *position = out->data[pos];
@@ -49,10 +51,15 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
 
   if (flags & (DO_CLIP_XY | DO_CLIP_XY_GUARD_BAND |
DO_CLIP_FULL_Z | DO_CLIP_HALF_Z | DO_CLIP_USER)) {
- out->clip[0] = position[0];
- out->clip[1] = position[1];
- out->clip[2] = position[2];
- out->clip[3] = position[3];
+ float *clipvertex = position;
+
+ if ((flags & DO_CLIP_USER) && cv != pos)
+clipvertex = out->data[cv];
+
+ for (i = 0; i < 4; i++) {
+out->clip[i] = clipvertex[i];
+out->pre_clip_pos[i] = position[i];
+ }
 
  /* Do the hardwired planes first:
   */
@@ -88,7 +95,7 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
ucp_mask &= ~(1 << plane_idx);
plane_idx += 6;
 
-   if (dot4(position, plane[plane_idx]) < 0) {
+   if (dot4(clipvertex, plane[plane_idx]) < 0) {
   mask |= 1 << plane_idx;
}
 }
diff --git a/src/gallium/auxiliary/draw/draw_context.c 
b/src/gallium/auxiliary/draw/draw_context.c
index 10a20f7..6d7075e 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -692,6 +692,16 @@ draw_current_shader_position_output(const struct 
draw_context *draw)
 
 
 /**
+ * Return the index of the shader output which will contain the
+ * vertex position.
+ */
+uint
+draw_current_shader_clipvertex_output(const struct draw_context *draw)
+{
+   return draw->vs.clipvertex_output;
+}
+
+/**
  * Return a pointer/handle for a driver/CSO rasterizer object which
  * disabled culling, stippling, unfilled tris, etc.
  * This is used by some pipeline stages (such as wide_point, aa_line
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index cf97e82..50c7e25 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -268,15 +268,16 @@ static LLVMTypeRef
 create_jit_vertex_header(struct gallivm_state *gallivm, int data_elems)
 {
LLVMTargetDataRef target = gallivm->target;
-   LLVMTypeRef elem_types[3];
+   LLVMTypeRef elem_types[4];
LLVMTypeRef vertex_header;
char struct_name[24];
 
util_snprintf(struct_name, 23, "vertex_header%d", data_elems);
 
-   elem_types[0]  = LLVMIntTypeInContext(gallivm->context, 32);
-   elem_types[1]  = LLVMArrayType(LLVMFloatTypeInContext(gallivm->context), 4);
-   elem_types[2]  = LLVMArrayType(elem_types[1], data_elems);
+   elem_types[DRAW_JIT_VERTEX_VERTEX_ID]  = 
LLVMIntTypeInContext(gallivm->context, 32);
+   elem_types[DRAW_JIT_VERTEX_CLIP]  = 
LLVMArrayType(LLVMFloatTypeInContext(gallivm->context), 4);
+   elem_types[DRAW_JIT_VERTEX_PRE_CLIP_POS]  = 
LLVMArrayType(LLVMFloatTypeIn

[Mesa-dev] [PATCH 3/4] tgsi_scan: add support to count number of output clip distances

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

Just add support to the scanner to count the number of clip distances.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/tgsi/tgsi_scan.c |4 
 src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 97d74e4..d81db89 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -191,6 +191,10 @@ tgsi_scan_shader(const struct tgsi_token *tokens,
   info->output_semantic_index[reg] = 
(ubyte)fulldecl->Semantic.Index;
   info->num_outputs++;
 
+  if (procType == TGSI_PROCESSOR_VERTEX &&
+  fulldecl->Semantic.Name == TGSI_SEMANTIC_CLIPDIST) {
+ info->num_clipdistance += 
util_bitcount(fulldecl->Declaration.UsageMask);
+  }
   /* extra info for special outputs */
   if (procType == TGSI_PROCESSOR_FRAGMENT &&
   fulldecl->Semantic.Name == TGSI_SEMANTIC_POSITION)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h 
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 482c106..a3d21b0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -75,6 +75,7 @@ struct tgsi_shader_info
boolean pixel_center_integer;
boolean color0_writes_all_cbufs;
 
+   unsigned num_clipdistance;
/**
 * Bitmask indicating which register files are accessed with
 * indirect addressing.  The bits are (1 << TGSI_FILE_x), etc.
-- 
1.7.7.3

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


[Mesa-dev] [PATCH 4/4] softpipe: clipdistance support (v1)

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

Add support for using the clipdistance instead of clip plane.

Passes all piglit clipdistance tests.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/draw/draw_cliptest_tmp.h |   25 ++--
 src/gallium/auxiliary/draw/draw_context.c  |6 
 src/gallium/auxiliary/draw/draw_pipe_clip.c|   36 ++--
 src/gallium/auxiliary/draw/draw_private.h  |5 ++-
 src/gallium/auxiliary/draw/draw_pt_post_vs.c   |4 +-
 src/gallium/auxiliary/draw/draw_vs.c   |7 
 src/gallium/auxiliary/draw/draw_vs.h   |2 +-
 7 files changed, 68 insertions(+), 17 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h 
b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
index 7dba49b..438d2d8 100644
--- a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
@@ -36,12 +36,19 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
/* const */ float (*plane)[4] = pvs->draw->plane;
const unsigned pos = draw_current_shader_position_output(pvs->draw);
const unsigned cv = draw_current_shader_clipvertex_output(pvs->draw);
+   unsigned cd[2];
const unsigned ef = pvs->draw->vs.edgeflag_output;
const unsigned ucp_enable = pvs->draw->rasterizer->clip_plane_enable;
const unsigned flags = (FLAGS);
unsigned need_pipeline = 0;
unsigned j;
unsigned i;
+   bool have_cd = false;
+   cd[0] = draw_current_shader_clipdistance_output(pvs->draw, 0);
+   cd[1] = draw_current_shader_clipdistance_output(pvs->draw, 1);
+  
+   if (cd[0] != pos || cd[1] != pos)
+ have_cd = true;
 
for (j = 0; j < info->count; j++) {
   float *position = out->data[pos];
@@ -89,14 +96,26 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
 
  if (flags & DO_CLIP_USER) {
 unsigned ucp_mask = ucp_enable;
-
+int num_clipdistance = 
pvs->draw->vs.vertex_shader->info.num_clipdistance;
 while (ucp_mask) {
unsigned plane_idx = ffs(ucp_mask)-1;
+   float clipval;
ucp_mask &= ~(1 << plane_idx);
plane_idx += 6;
 
-   if (dot4(clipvertex, plane[plane_idx]) < 0) {
-  mask |= 1 << plane_idx;
+   if (have_cd && num_clipdistance) {
+  i = plane_idx - 6;
+  out->have_clipdist = 1;
+  if (i < 4)
+ clipval = out->data[cd[0]][i];
+  else
+ clipval = out->data[cd[1]][i-4];
+  if (clipval < 0)
+ mask |= (1 << plane_idx);
+   } else {
+  if (dot4(clipvertex, plane[plane_idx]) < 0) {
+ mask |= 1 << plane_idx;
+  }
}
 }
  }
diff --git a/src/gallium/auxiliary/draw/draw_context.c 
b/src/gallium/auxiliary/draw/draw_context.c
index 6d7075e..7e554dc 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -701,6 +701,12 @@ draw_current_shader_clipvertex_output(const struct 
draw_context *draw)
return draw->vs.clipvertex_output;
 }
 
+uint
+draw_current_shader_clipdistance_output(const struct draw_context *draw, int 
index)
+{
+   return draw->vs.clipdistance_output[index];
+}
+
 /**
  * Return a pointer/handle for a driver/CSO rasterizer object which
  * disabled culling, stippling, unfilled tris, etc.
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c 
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index fbc8f67..265b755 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -119,13 +119,17 @@ static void interp( const struct clip_stage *clip,
const unsigned nr_attrs = draw_current_shader_outputs(clip->stage.draw);
const unsigned pos_attr = 
draw_current_shader_position_output(clip->stage.draw);
const unsigned clip_attr = 
draw_current_shader_clipvertex_output(clip->stage.draw);
+   unsigned clip_dist[2];
unsigned j;
 
+   clip_dist[0] = draw_current_shader_clipdistance_output(clip->stage.draw, 0);
+   clip_dist[1] = draw_current_shader_clipdistance_output(clip->stage.draw, 1);
+
/* Vertex header.
 */
dst->clipmask = 0;
dst->edgeflag = 0;/* will get overwritten later */
-   dst->pad = 0;
+   dst->have_clipdist = in->have_clipdist;
dst->vertex_id = UNDEFINED_VERTEX_ID;
 
/* Interpolate the clip-space coords.
@@ -241,6 +245,23 @@ dot4(const float *a, const float *b)
a[3] * b[3]);
 }
 
+static inline float getclipdist(const struct clip_stage *clipper,
+struct vertex_header *vert,
+int plane_idx)
+{
+   const float *plane;
+   float dp;
+   if (vert->have_clipdist && plane_idx >= 6) {
+  int _idx = plane_idx - 6;
+  int cdi = _idx >= 4;
+  int vidx = cdi ? _idx - 4 : _idx;
+ 

Re: [Mesa-dev] [PATCH] mesa/clear: fix crashes with illegal clear tests.

2012-01-10 Thread Jose Fonseca


- Original Message -
> From: Dave Airlie 
> 
> Mesa shouldn't call into the drivers if there are no renderbuffers
> bound to the attachments for the buffers to be cleared.
> 
> Fixes a number of the clearbuffer-* tests on softpipe.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/main/clear.c |   15 +++
>  1 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index bd5c012..a340f99 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
[...]
> @@ -592,6 +592,8 @@ _mesa_ClearBufferfi(GLenum buffer, GLint
> drawbuffer,
>  GLfloat depth, GLint stencil)
>  {
> GET_CURRENT_CONTEXT(ctx);
> +   int mask = 0;
> +

mask should be unsigned or GLbitfield.

Otherwise looks good to me.

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


Re: [Mesa-dev] [PATCH 3/4] tgsi_scan: add support to count number of output clip distances

2012-01-10 Thread Jose Fonseca
Dave,


- Original Message -
> From: Dave Airlie 
> 
> Just add support to the scanner to count the number of clip
> distances.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/tgsi/tgsi_scan.c |4 
>  src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
> b/src/gallium/auxiliary/tgsi/tgsi_scan.c
> index 97d74e4..d81db89 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
> @@ -191,6 +191,10 @@ tgsi_scan_shader(const struct tgsi_token
> *tokens,
>info->output_semantic_index[reg] =
>(ubyte)fulldecl->Semantic.Index;
>info->num_outputs++;
>  
> +  if (procType == TGSI_PROCESSOR_VERTEX &&
> +  fulldecl->Semantic.Name ==
> TGSI_SEMANTIC_CLIPDIST) {
> + info->num_clipdistance +=
> util_bitcount(fulldecl->Declaration.UsageMask);
> +  }
>/* extra info for special outputs */
>if (procType == TGSI_PROCESSOR_FRAGMENT &&
>fulldecl->Semantic.Name ==
>TGSI_SEMANTIC_POSITION)
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h
> b/src/gallium/auxiliary/tgsi/tgsi_scan.h
> index 482c106..a3d21b0 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
> @@ -75,6 +75,7 @@ struct tgsi_shader_info
> boolean pixel_center_integer;
> boolean color0_writes_all_cbufs;
>  
> +   unsigned num_clipdistance;

It would be more self documenting if the variable name implied that this is the 
number of clip distances written.

Maybe "num_output_clipdist" or "num_written_clipdist".

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


Re: [Mesa-dev] Mesa (master): gallium: introduce GLSL based interpolation rules. (v2)

2012-01-10 Thread Brian Paul

On 01/10/2012 04:56 AM, Dave Airlie wrote:

Module: Mesa
Branch: master
Commit: 67e3cbf1632e361220234013147331e4618b70cb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=67e3cbf1632e361220234013147331e4618b70cb

Author: Dave Airlie
Date:   Mon Jan  9 15:57:02 2012 +

gallium: introduce GLSL based interpolation rules. (v2)

This introduces an unspecified interpolation paramter that is only allowed for
color semantics, so a specified GLSL interpolation will override the ShadeModel
specified interpolation, but not vice-versa.

This fixes a lot of the interpolation tests in piglit.

v2: rename from unspecified to color

Signed-off-by: Dave Airlie

---

  src/gallium/auxiliary/tgsi/tgsi_exec.c  |4 
  src/gallium/auxiliary/tgsi/tgsi_exec.h  |2 +-
  src/gallium/auxiliary/tgsi/tgsi_strings.c   |3 ++-
  src/gallium/drivers/softpipe/sp_quad_fs.c   |1 +
  src/gallium/drivers/softpipe/sp_state_derived.c |   10 --
  src/gallium/include/pipe/p_shader_tokens.h  |3 ++-
  src/mesa/state_tracker/st_program.c |2 +-
  7 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 3e2b899..52d4ff4 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -2371,6 +2371,10 @@ exec_declaration(struct tgsi_exec_machine *mach,
 eval = eval_perspective_coef;
 break;

+case TGSI_INTERPOLATE_COLOR:
+   eval = mach->flatshade_color ? eval_constant_coef : 
eval_perspective_coef;
+   break;
+
  default:
 assert(0);
 return;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h 
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 223da2c..0817e14 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -263,7 +263,7 @@ struct tgsi_exec_machine
 const struct tgsi_interp_coef *InterpCoefs;
 struct tgsi_exec_vector   QuadPos;
 float Face;/**<  +1 if front facing, -1 if 
back facing */
-
+   bool  flatshade_color;
 /* Conditional execution masks */
 uint CondMask;  /**<  For IF/ELSE/ENDIF */
 uint LoopMask;  /**<  For BGNLOOP/ENDLOOP */
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index aa12493..de9152d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -117,7 +117,8 @@ const char *tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT] =
  {
 "CONSTANT",
 "LINEAR",
-   "PERSPECTIVE"
+   "PERSPECTIVE",
+   "COLOR"
  };

  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
diff --git a/src/gallium/drivers/softpipe/sp_quad_fs.c 
b/src/gallium/drivers/softpipe/sp_quad_fs.c
index 7b08cd0..7800ba8 100644
--- a/src/gallium/drivers/softpipe/sp_quad_fs.c
+++ b/src/gallium/drivers/softpipe/sp_quad_fs.c
@@ -74,6 +74,7 @@ shade_quad(struct quad_stage *qs, struct quad_header *quad)
 struct tgsi_exec_machine *machine = softpipe->fs_machine;

 /* run shader */
+   machine->flatshade_color = softpipe->rasterizer->flatshade ? TRUE : FALSE;
 return softpipe->fs_variant->run( softpipe->fs_variant, machine, quad );
  }

diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c 
b/src/gallium/drivers/softpipe/sp_state_derived.c
index 5685997..7b2b04e 100644
--- a/src/gallium/drivers/softpipe/sp_state_derived.c
+++ b/src/gallium/drivers/softpipe/sp_state_derived.c
@@ -100,6 +100,9 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe)
   case TGSI_INTERPOLATE_PERSPECTIVE:
  interp = INTERP_PERSPECTIVE;
  break;
+ case TGSI_INTERPOLATE_COLOR:
+assert(fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR);
+break;
   default:
  assert(0);
  interp = INTERP_LINEAR;
@@ -111,8 +114,11 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe)
  break;

   case TGSI_SEMANTIC_COLOR:
-if (softpipe->rasterizer->flatshade) {
-   interp = INTERP_CONSTANT;
+if (fsInfo->input_interpolate[i] == TGSI_INTERPOLATE_COLOR) {
+   if (softpipe->rasterizer->flatshade)
+  interp = INTERP_CONSTANT;
+   else
+  interp = INTERP_PERSPECTIVE;
  }
  break;
   }
diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
b/src/gallium/include/pipe/p_shader_tokens.h
index 2fbe1df..cb1e698 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -100,7 +100,8 @@ enum tgsi_file_type {
  #define TGSI_INTERPOLATE_CONSTANT  0
  #define TGSI_INTERPOLATE_LINEAR1
  #define TGSI_INTERPOLATE_PERSPECTIVE   2
-#define TGSI_INTERPOLATE_COUN

Re: [Mesa-dev] Mesa (master): gallium: introduce GLSL based interpolation rules. (v2)

2012-01-10 Thread Brian Paul

On 01/10/2012 08:34 AM, Brian Paul wrote:

On 01/10/2012 04:56 AM, Dave Airlie wrote:

Module: Mesa
Branch: master
Commit: 67e3cbf1632e361220234013147331e4618b70cb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=67e3cbf1632e361220234013147331e4618b70cb


Author: Dave Airlie
Date: Mon Jan 9 15:57:02 2012 +

gallium: introduce GLSL based interpolation rules. (v2)

This introduces an unspecified interpolation paramter that is only
allowed for
color semantics, so a specified GLSL interpolation will override the
ShadeModel
specified interpolation, but not vice-versa.

This fixes a lot of the interpolation tests in piglit.

v2: rename from unspecified to color

Signed-off-by: Dave Airlie

---

src/gallium/auxiliary/tgsi/tgsi_exec.c | 4 
src/gallium/auxiliary/tgsi/tgsi_exec.h | 2 +-
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/drivers/softpipe/sp_quad_fs.c | 1 +
src/gallium/drivers/softpipe/sp_state_derived.c | 10 --
src/gallium/include/pipe/p_shader_tokens.h | 3 ++-
src/mesa/state_tracker/st_program.c | 2 +-
7 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 3e2b899..52d4ff4 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -2371,6 +2371,10 @@ exec_declaration(struct tgsi_exec_machine *mach,
eval = eval_perspective_coef;
break;

+ case TGSI_INTERPOLATE_COLOR:
+ eval = mach->flatshade_color ? eval_constant_coef :
eval_perspective_coef;
+ break;
+
default:
assert(0);
return;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 223da2c..0817e14 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -263,7 +263,7 @@ struct tgsi_exec_machine
const struct tgsi_interp_coef *InterpCoefs;
struct tgsi_exec_vector QuadPos;
float Face; /**< +1 if front facing, -1 if back facing */
-
+ bool flatshade_color;
/* Conditional execution masks */
uint CondMask; /**< For IF/ELSE/ENDIF */
uint LoopMask; /**< For BGNLOOP/ENDLOOP */
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index aa12493..de9152d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -117,7 +117,8 @@ const char
*tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT] =
{
"CONSTANT",
"LINEAR",
- "PERSPECTIVE"
+ "PERSPECTIVE",
+ "COLOR"
};

const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
diff --git a/src/gallium/drivers/softpipe/sp_quad_fs.c
b/src/gallium/drivers/softpipe/sp_quad_fs.c
index 7b08cd0..7800ba8 100644
--- a/src/gallium/drivers/softpipe/sp_quad_fs.c
+++ b/src/gallium/drivers/softpipe/sp_quad_fs.c
@@ -74,6 +74,7 @@ shade_quad(struct quad_stage *qs, struct
quad_header *quad)
struct tgsi_exec_machine *machine = softpipe->fs_machine;

/* run shader */
+ machine->flatshade_color = softpipe->rasterizer->flatshade ? TRUE
: FALSE;
return softpipe->fs_variant->run( softpipe->fs_variant, machine,
quad );
}

diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c
b/src/gallium/drivers/softpipe/sp_state_derived.c
index 5685997..7b2b04e 100644
--- a/src/gallium/drivers/softpipe/sp_state_derived.c
+++ b/src/gallium/drivers/softpipe/sp_state_derived.c
@@ -100,6 +100,9 @@ softpipe_get_vertex_info(struct softpipe_context
*softpipe)
case TGSI_INTERPOLATE_PERSPECTIVE:
interp = INTERP_PERSPECTIVE;
break;
+ case TGSI_INTERPOLATE_COLOR:
+ assert(fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR);
+ break;
default:
assert(0);
interp = INTERP_LINEAR;
@@ -111,8 +114,11 @@ softpipe_get_vertex_info(struct
softpipe_context *softpipe)
break;

case TGSI_SEMANTIC_COLOR:
- if (softpipe->rasterizer->flatshade) {
- interp = INTERP_CONSTANT;
+ if (fsInfo->input_interpolate[i] == TGSI_INTERPOLATE_COLOR) {
+ if (softpipe->rasterizer->flatshade)
+ interp = INTERP_CONSTANT;
+ else
+ interp = INTERP_PERSPECTIVE;
}
break;
}
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 2fbe1df..cb1e698 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -100,7 +100,8 @@ enum tgsi_file_type {
#define TGSI_INTERPOLATE_CONSTANT 0
#define TGSI_INTERPOLATE_LINEAR 1
#define TGSI_INTERPOLATE_PERSPECTIVE 2
-#define TGSI_INTERPOLATE_COUNT 3
+#define TGSI_INTERPOLATE_COLOR 3 /* special color case for
smooth/flat */
+#define TGSI_INTERPOLATE_COUNT 4

#define TGSI_CYLINDRICAL_WRAP_X (1<< 0)
#define TGSI_CYLINDRICAL_WRAP_Y (1<< 1)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index 8d7469d..8d08b2b 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -441,7 +441,7 @@ st_translate_interp(enum glsl_interp_qualifier
glsl_qual, bool is_color)
switch (glsl_qual) {
case INTERP_QUALIFIER_NONE:
if (is_color)
- return TGSI_INTERPOLATE_LINEAR;
+ return TGSI_IN

[Mesa-dev] [PATCH] r600g: add support for virtual address space on cayman v10

2012-01-10 Thread j . glisse
From: Jerome Glisse 

Virtual address space put the userspace in charge of their GPU
address space. It's up to userspace to bind bo into the virtual
address space. Command stream can them be executed using the
IB_VM chunck.

This patch add support for this configuration. It doesn't remove
the 64K ib size limit thought this limit can be extanded up to
1M for IB_VM chunk.

v2: fix rendering
v3: fix rendering when using index buffer
v4: make vm conditional on kernel support add basic va management
v5: catch the case when we already have va for a bo
v6: agd5f: update on top of ioctl changes
v7: agd5f: further ioctl updates
v8: indentation cleanup + fix non cayman
v9: rebase against lastest mesa + improvement from Marek & Michel
v10: fix cut/paste bug

Signed-off-by: Jerome Glisse 
Signed-off-by: Alex Deucher 
---
 src/gallium/drivers/r600/evergreen_hw_context.c   |9 +-
 src/gallium/drivers/r600/evergreen_state.c|   49 --
 src/gallium/drivers/r600/r600_hw_context.c|   47 --
 src/gallium/drivers/r600/r600_pipe.h  |3 +-
 src/gallium/drivers/r600/r600_resource.c  |   11 ++
 src/gallium/drivers/r600/r600_resource.h  |2 +
 src/gallium/drivers/r600/r600_state_common.c  |   14 +-
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c |  177 +
 src/gallium/winsys/radeon/drm/radeon_drm_bo.h |2 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c |   21 ++-
 src/gallium/winsys/radeon/drm/radeon_drm_cs.h |4 +-
 src/gallium/winsys/radeon/drm/radeon_drm_winsys.c |   10 ++
 src/gallium/winsys/radeon/drm/radeon_winsys.h |   11 ++
 13 files changed, 312 insertions(+), 48 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
b/src/gallium/drivers/r600/evergreen_hw_context.c
index bd1d969..e75eaf2 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -1135,6 +1135,7 @@ void evergreen_context_draw(struct r600_context *ctx, 
const struct r600_draw *dr
struct r600_block *dirty_block = NULL;
struct r600_block *next_block;
uint32_t *pm4;
+   uint64_t va;
 
if (draw->indices) {
ndwords = 11;
@@ -1174,9 +1175,11 @@ void evergreen_context_draw(struct r600_context *ctx, 
const struct r600_draw *dr
pm4[2] = PKT3(PKT3_NUM_INSTANCES, 0, ctx->predicate_drawing);
pm4[3] = draw->vgt_num_instances;
if (draw->indices) {
-   pm4[4] = PKT3(PKT3_DRAW_INDEX, 3, ctx->predicate_drawing);
-   pm4[5] = draw->indices_bo_offset;
-   pm4[6] = 0;
+   va = r600_resource_va(&ctx->screen->screen, 
(void*)draw->indices);
+   va += draw->indices_bo_offset;
+   pm4[4] = PKT3(PKT3_DRAW_INDEX, 3, ctx->predicate_drawing);
+   pm4[5] = va;
+   pm4[6] = (va >> 32UL) & 0xFF;
pm4[7] = draw->vgt_num_indices;
pm4[8] = draw->vgt_draw_initiator;
pm4[9] = PKT3(PKT3_NOP, 0, ctx->predicate_drawing);
diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 7ded03d..aca6136 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1101,8 +1101,8 @@ static struct pipe_sampler_view 
*evergreen_create_sampler_view(struct pipe_conte
rstate->val[1] = (S_030004_TEX_HEIGHT(height - 1) |
  S_030004_TEX_DEPTH(depth - 1) |
  S_030004_ARRAY_MODE(array_mode));
-   rstate->val[2] = tmp->offset[0] >> 8;
-   rstate->val[3] = tmp->offset[1] >> 8;
+   rstate->val[2] = (tmp->offset[0] + r600_resource_va(ctx->screen, 
texture)) >> 8;
+   rstate->val[3] = (tmp->offset[1] + r600_resource_va(ctx->screen, 
texture)) >> 8;
rstate->val[4] = (word4 |
  
S_030010_SRF_MODE_ALL(V_030010_SRF_MODE_ZERO_CLAMP_MINUS_ONE) |
  S_030010_ENDIAN_SWAP(endian) |
@@ -1343,7 +1343,7 @@ static void evergreen_cb(struct r600_pipe_context *rctx, 
struct r600_pipe_state
unsigned pitch, slice;
unsigned color_info;
unsigned format, swap, ntype, endian;
-   unsigned offset;
+   uint64_t offset;
unsigned tile_type;
const struct util_format_description *desc;
int i;
@@ -1443,10 +1443,13 @@ static void evergreen_cb(struct r600_pipe_context 
*rctx, struct r600_pipe_state
} else /* workaround for linear buffers */
tile_type = 1;
 
+   offset += r600_resource_va(rctx->context.screen, 
state->cbufs[cb]->texture);
+   offset >>= 8;
+
/* FIXME handle enabling of CB beyond BASE8 which has different offset 
*/
r600_pipe_state_add_reg(rstate,
R_028C60_CB_COLOR0_BASE + cb * 0x3C,
-   offset >> 8, 0x, &rtex->resource, 
RADEON_USAGE_READWRITE);
+

Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Marek Olšák
On Tue, Jan 10, 2012 at 12:29 PM, Jose Fonseca  wrote:
> Still catching up on email traffic during holidays...
>
> I agree that user buffer uploads should be moved out of drivers, but I don't 
> think this is the way to go.
>
> This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes the 
> ability to transform this data in any way before reashing the GPU -- i.e., 
> prevents any sort of workarounds -- something can't be always guaranteed. 
> Flushing with map helps is also non-portable.

The flag is optional, it doesn't have to implemented by everybody. If
we do the uploads in the state tracker, we will also do any required
data transformation so that drivers don't have to do it at all.

>
>
> It looks to me that state trackers and/or drivers are not properly using 
> PIPE_USAGE_STREAM flag.  As all cases where PIPE_TRANSFER_MAP_PERMANENTLY 
> would be used, the right way to do it would be for the state tracker to set 
> PIPE_USAGE_STREAM, the pipe driver to recognize PIPE_USAGE_STREAM, and keep 
> the mapping permanently internally, making mapping/unmapping of such buffers 
> mere no-ops.

We were doing that already and it wasn't good enough. Avoiding
create+map+unmap+destroy *calls* have brought higher frame rates in
apps with lots of draw operations. It may not be the ideal
optimization, but so far it's the best we have.

Marek

>
>
> In summary, for me PIPE_TRANSFER_MAP_PERMANENTLY is premature/bad 
> optmization.  Before we are worried about saving a couple of map/unmap calls, 
> we should ensure that PIPE_USAGE_STREAM/PIPE_USAGE_DYNAMIC code paths are 
> fully optimal.
>
>
> Jose
>
> - Original Message -
>> Please see the diff for further info.
>>
>> This paves the way for moving user buffer uploads out of drivers and
>> should
>> allow to clean up the mess in u_upload_mgr in the meantime.
>>
>> For now only allowed for buffers on r300 and r600.
>> ---
>>  src/gallium/drivers/i915/i915_resource_buffer.c  |    7 ++-
>>  src/gallium/drivers/i915/i915_resource_texture.c |    7 ++-
>>  src/gallium/drivers/llvmpipe/lp_texture.c        |    4 
>>  src/gallium/drivers/nouveau/nouveau_buffer.c     |    8 +++-
>>  src/gallium/drivers/nv50/nv50_transfer.c         |    2 +-
>>  src/gallium/drivers/nvc0/nvc0_transfer.c         |    2 +-
>>  src/gallium/drivers/nvfx/nvfx_transfer.c         |    3 +++
>>  src/gallium/drivers/r300/r300_transfer.c         |    4 
>>  src/gallium/drivers/r600/r600_texture.c          |    4 
>>  src/gallium/drivers/svga/svga_resource_buffer.c  |    4 
>>  src/gallium/drivers/svga/svga_resource_texture.c |    2 +-
>>  src/gallium/include/pipe/p_defines.h             |   16
>>  
>>  12 files changed, 57 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c
>> b/src/gallium/drivers/i915/i915_resource_buffer.c
>> index 77c0345..c54e481 100644
>> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
>> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
>> @@ -68,8 +68,13 @@ i915_get_transfer(struct pipe_context *pipe,
>>                    const struct pipe_box *box)
>>  {
>>     struct i915_context *i915 = i915_context(pipe);
>> -   struct pipe_transfer *transfer =
>> util_slab_alloc(&i915->transfer_pool);
>> +   struct pipe_transfer *transfer;
>>
>> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
>> +      return NULL;
>> +   }
>> +
>> +   transfer = util_slab_alloc(&i915->transfer_pool);
>>     if (transfer == NULL)
>>        return NULL;
>>
>> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c
>> b/src/gallium/drivers/i915/i915_resource_texture.c
>> index 8ff733a..64d071c 100644
>> --- a/src/gallium/drivers/i915/i915_resource_texture.c
>> +++ b/src/gallium/drivers/i915/i915_resource_texture.c
>> @@ -720,9 +720,14 @@ i915_texture_get_transfer(struct pipe_context
>> *pipe,
>>  {
>>     struct i915_context *i915 = i915_context(pipe);
>>     struct i915_texture *tex = i915_texture(resource);
>> -   struct i915_transfer *transfer =
>> util_slab_alloc(&i915->texture_transfer_pool);
>> +   struct i915_transfer *transfer;
>>     boolean use_staging_texture = FALSE;
>>
>> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
>> +      return NULL;
>> +   }
>> +
>> +   transfer = util_slab_alloc(&i915->texture_transfer_pool);
>>     if (transfer == NULL)
>>        return NULL;
>>
>> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
>> b/src/gallium/drivers/llvmpipe/lp_texture.c
>> index ca38571..d86d493 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
>> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
>> @@ -587,6 +587,10 @@ llvmpipe_get_transfer(struct pipe_context *pipe,
>>     assert(resource);
>>     assert(level <= resource->last_level);
>>
>> +   if (usage & PIPE_TRANSFER_MAP_PERMANENTLY) {
>> +      return NULL;
>> +   }
>> +
>>     /*
>>      * Transfers, like other pipe operations, must happen in order,
>>      so flush the
>>      * context if necessary.
>> 

Re: [Mesa-dev] [PATCH 06/12] mesa: Ignores

2012-01-10 Thread Jakob Bornecrantz
2012/1/10 Michel Dänzer :
> On Mon, 2012-01-09 at 23:53 +0100, Jakob Bornecrantz wrote:
>> Signed-off-by: Jakob Bornecrantz 
>> ---
>>  src/mesa/.gitignore |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/.gitignore b/src/mesa/.gitignore
>> index ce83eaf..0cf001e 100644
>> --- a/src/mesa/.gitignore
>> +++ b/src/mesa/.gitignore
>> @@ -3,3 +3,4 @@
>>  depend.es*
>>  depend.es*
>>  objs-es*
>> +git_sha1.h.tmp
>
> This is in src/mesa/main/.gitignore . src/mesa/git_sha1.h.tmp really is
> stale.

Hmm you are right, dropping patch.

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


Re: [Mesa-dev] [PATCH 4/4] softpipe: clipdistance support (v1)

2012-01-10 Thread Brian Paul
The check-in message should probably be "draw: clipdistance support 
(v1)", not "softpipe".



On 01/10/2012 06:55 AM, Dave Airlie wrote:

From: Dave Airlie

Add support for using the clipdistance instead of clip plane.

Passes all piglit clipdistance tests.

Signed-off-by: Dave Airlie
---
  src/gallium/auxiliary/draw/draw_cliptest_tmp.h |   25 ++--
  src/gallium/auxiliary/draw/draw_context.c  |6 
  src/gallium/auxiliary/draw/draw_pipe_clip.c|   36 ++--
  src/gallium/auxiliary/draw/draw_private.h  |5 ++-
  src/gallium/auxiliary/draw/draw_pt_post_vs.c   |4 +-
  src/gallium/auxiliary/draw/draw_vs.c   |7 
  src/gallium/auxiliary/draw/draw_vs.h   |2 +-
  7 files changed, 68 insertions(+), 17 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h 
b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
index 7dba49b..438d2d8 100644
--- a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
@@ -36,12 +36,19 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
 /* const */ float (*plane)[4] = pvs->draw->plane;
 const unsigned pos = draw_current_shader_position_output(pvs->draw);
 const unsigned cv = draw_current_shader_clipvertex_output(pvs->draw);
+   unsigned cd[2];
 const unsigned ef = pvs->draw->vs.edgeflag_output;
 const unsigned ucp_enable = pvs->draw->rasterizer->clip_plane_enable;
 const unsigned flags = (FLAGS);
 unsigned need_pipeline = 0;
 unsigned j;
 unsigned i;
+   bool have_cd = false;
+   cd[0] = draw_current_shader_clipdistance_output(pvs->draw, 0);
+   cd[1] = draw_current_shader_clipdistance_output(pvs->draw, 1);
+
+   if (cd[0] != pos || cd[1] != pos)
+ have_cd = true;

 for (j = 0; j<  info->count; j++) {
float *position = out->data[pos];
@@ -89,14 +96,26 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,

   if (flags&  DO_CLIP_USER) {
  unsigned ucp_mask = ucp_enable;
-
+int num_clipdistance = 
pvs->draw->vs.vertex_shader->info.num_clipdistance;
  while (ucp_mask) {
 unsigned plane_idx = ffs(ucp_mask)-1;
+   float clipval;
 ucp_mask&= ~(1<<  plane_idx);
 plane_idx += 6;

-   if (dot4(clipvertex, plane[plane_idx])<  0) {
-  mask |= 1<<  plane_idx;


Could you add some comments on the following code?  Maybe it's just 
me, but I think it's a bit hard to follow.




+   if (have_cd&&  num_clipdistance) {
+  i = plane_idx - 6;
+  out->have_clipdist = 1;
+  if (i<  4)
+ clipval = out->data[cd[0]][i];
+  else
+ clipval = out->data[cd[1]][i-4];
+  if (clipval<  0)
+ mask |= (1<<  plane_idx);
+   } else {
+  if (dot4(clipvertex, plane[plane_idx])<  0) {
+ mask |= 1<<  plane_idx;
+  }
 }
  }
   }
diff --git a/src/gallium/auxiliary/draw/draw_context.c 
b/src/gallium/auxiliary/draw/draw_context.c
index 6d7075e..7e554dc 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -701,6 +701,12 @@ draw_current_shader_clipvertex_output(const struct 
draw_context *draw)
 return draw->vs.clipvertex_output;
  }

+uint
+draw_current_shader_clipdistance_output(const struct draw_context *draw, int 
index)
+{
+   return draw->vs.clipdistance_output[index];
+}
+
  /**
   * Return a pointer/handle for a driver/CSO rasterizer object which
   * disabled culling, stippling, unfilled tris, etc.
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c 
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index fbc8f67..265b755 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -119,13 +119,17 @@ static void interp( const struct clip_stage *clip,
 const unsigned nr_attrs = draw_current_shader_outputs(clip->stage.draw);
 const unsigned pos_attr = 
draw_current_shader_position_output(clip->stage.draw);
 const unsigned clip_attr = 
draw_current_shader_clipvertex_output(clip->stage.draw);
+   unsigned clip_dist[2];
 unsigned j;

+   clip_dist[0] = draw_current_shader_clipdistance_output(clip->stage.draw, 0);
+   clip_dist[1] = draw_current_shader_clipdistance_output(clip->stage.draw, 1);
+
 /* Vertex header.
  */
 dst->clipmask = 0;
 dst->edgeflag = 0;/* will get overwritten later */
-   dst->pad = 0;
+   dst->have_clipdist = in->have_clipdist;
 dst->vertex_id = UNDEFINED_VERTEX_ID;

 /* Interpolate the clip-space coords.
@@ -241,6 +245,23 @@ dot4(const float *a, const float *b)
 a[3] * b[3]);
  }




Comments on this function would be helpful too.  And we're still using 
INLIN

Re: [Mesa-dev] [PATCH 03/12] rbug: Silence warning

2012-01-10 Thread Jakob Bornecrantz
On Tue, Jan 10, 2012 at 2:40 AM, Jakob Bornecrantz  wrote:
> On Tue, Jan 10, 2012 at 12:01 AM, Alan Coopersmith
>  wrote:
>> On 01/ 9/12 02:53 PM, Jakob Bornecrantz wrote:
>>>
>>> -   struct pipe_shader_state pss = { 0 };
>>> +   struct pipe_shader_state pss;
>>> +   memset(&pss, 0, sizeof(pss));
>>
>>
>> Those do the same thing, just via a function call instead of compiler
>> builtin.
>> What warning is being silenced by that change?
>
> I don't have the build log with me right, but I think it was something
> about uninitialized field near "pss.tokens = tokens;", I will take a
> closer look. That struct has substruct it seems that GCC wants you to
> initialize all of them.

src/gallium/drivers/rbug/rbug_core.c: In function ‘rbug_shader_create_locked’:
src/gallium/drivers/rbug/rbug_core.c:107:11: warning: missing
initializer [-Wmissing-field-initializers]
src/gallium/drivers/rbug/rbug_core.c:107:11: warning: (near
initialization for ‘pss.stream_output’) [-Wmissing-field-initializers]

gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

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


[Mesa-dev] [PATCH 3/9] vl/video_buffer: add support for interlaced buffers

2012-01-10 Thread Christian König
Add the infrastructure, but not the decode implementation.

Signed-off-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_video_buffer.c |   35 ++-
 src/gallium/auxiliary/vl/vl_video_buffer.h |2 +-
 src/gallium/include/pipe/p_video_decoder.h |1 +
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c 
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 008186c..21a2a89 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -161,11 +161,14 @@ vl_video_buffer_destroy(struct pipe_video_buffer *buffer)
assert(buf);
 
for (i = 0; i < VL_MAX_PLANES; ++i) {
-  pipe_surface_reference(&buf->surfaces[i], NULL);
   pipe_sampler_view_reference(&buf->sampler_view_planes[i], NULL);
   pipe_sampler_view_reference(&buf->sampler_view_components[i], NULL);
   pipe_resource_reference(&buf->resources[i], NULL);
}
+
+   for (i = 0; i < VL_MAX_PLANES * 2; ++i)
+  pipe_surface_reference(&buf->surfaces[i], NULL);
+
vl_video_buffer_set_associated_data(buffer, NULL, NULL, NULL);
 
FREE(buffer);
@@ -251,27 +254,32 @@ vl_video_buffer_surfaces(struct pipe_video_buffer *buffer)
struct vl_video_buffer *buf = (struct vl_video_buffer *)buffer;
struct pipe_surface surf_templ;
struct pipe_context *pipe;
-   unsigned i;
+   unsigned i, j, surf;
 
assert(buf);
 
pipe = buf->base.context;
 
-   for (i = 0; i < buf->num_planes; ++i ) {
-  if (!buf->surfaces[i]) {
- memset(&surf_templ, 0, sizeof(surf_templ));
- surf_templ.format = buf->resources[i]->format;
- surf_templ.usage = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
- buf->surfaces[i] = pipe->create_surface(pipe, buf->resources[i], 
&surf_templ);
- if (!buf->surfaces[i])
-goto error;
+   for (i = 0, surf = 0; i < buf->num_planes; ++i ) {
+  for (j = 0; j < buf->resources[i]->depth0; ++j, ++surf) {
+ assert(surf < (VL_MAX_PLANES * 2));
+
+ if (!buf->surfaces[surf]) {
+memset(&surf_templ, 0, sizeof(surf_templ));
+surf_templ.format = buf->resources[i]->format;
+surf_templ.usage = PIPE_BIND_SAMPLER_VIEW | 
PIPE_BIND_RENDER_TARGET;
+surf_templ.u.tex.first_layer = surf_templ.u.tex.last_layer = j;
+buf->surfaces[i] = pipe->create_surface(pipe, buf->resources[i], 
&surf_templ);
+if (!buf->surfaces[i])
+   goto error;
+ }
   }
}
 
return buf->surfaces;
 
 error:
-   for (i = 0; i < buf->num_planes; ++i )
+   for (i = 0; i < (VL_MAX_PLANES * 2); ++i )
   pipe_surface_reference(&buf->surfaces[i], NULL);
 
return NULL;
@@ -305,10 +313,13 @@ vl_video_buffer_create(struct pipe_context *pipe,
templat.height = pot_buffers ? util_next_power_of_two(tmpl->height)
   : align(tmpl->height, MACROBLOCK_HEIGHT);
 
+   if (tmpl->interlaced)
+  templat.height /= 2;
+
return vl_video_buffer_create_ex
(
   pipe, &templat, resource_formats,
-  1, PIPE_USAGE_STATIC
+  tmpl->interlaced ? 2 : 1, PIPE_USAGE_STATIC
);
 }
 
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.h 
b/src/gallium/auxiliary/vl/vl_video_buffer.h
index 1329fbd..a323efd 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.h
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.h
@@ -45,7 +45,7 @@ struct vl_video_buffer
struct pipe_resource *resources[VL_MAX_PLANES];
struct pipe_sampler_view *sampler_view_planes[VL_MAX_PLANES];
struct pipe_sampler_view *sampler_view_components[VL_MAX_PLANES];
-   struct pipe_surface  *surfaces[VL_MAX_PLANES];
+   struct pipe_surface  *surfaces[VL_MAX_PLANES * 2];
 };
 
 /**
diff --git a/src/gallium/include/pipe/p_video_decoder.h 
b/src/gallium/include/pipe/p_video_decoder.h
index 69e59a6..62169ff 100644
--- a/src/gallium/include/pipe/p_video_decoder.h
+++ b/src/gallium/include/pipe/p_video_decoder.h
@@ -128,6 +128,7 @@ struct pipe_video_buffer
enum pipe_video_chroma_format chroma_format;
unsigned width;
unsigned height;
+   bool interlaced;
 
/**
 * destroy this video buffer
-- 
1.7.5.4

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


[Mesa-dev] [PATCH 1/9] vl/video_buffer: use template style create params

2012-01-10 Thread Christian König
Just like in the rest of gallium, this reduces the
number of parameters significantly.

Signed-off-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.c   |   27 ++
 src/gallium/auxiliary/vl/vl_video_buffer.c |   47 ++--
 src/gallium/auxiliary/vl/vl_video_buffer.h |9 ++---
 src/gallium/drivers/nouveau/nouveau_video.c|   29 ++-
 src/gallium/include/pipe/p_context.h   |4 +--
 src/gallium/state_trackers/vdpau/surface.c |   10 --
 src/gallium/state_trackers/xorg/xvmc/surface.c |   14 ---
 7 files changed, 71 insertions(+), 69 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index cb55fa6..6341cc1 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -909,6 +909,7 @@ init_idct(struct vl_mpeg12_decoder *dec, const struct 
format_config* format_conf
 {
unsigned nr_of_idct_render_targets, max_inst;
enum pipe_format formats[3];
+   struct pipe_video_buffer templat;
 
struct pipe_sampler_view *matrix = NULL;
 
@@ -930,21 +931,28 @@ init_idct(struct vl_mpeg12_decoder *dec, const struct 
format_config* format_conf
   nr_of_idct_render_targets = 1;
 
formats[0] = formats[1] = formats[2] = format_config->idct_source_format;
+   memset(&templat, 0, sizeof(templat));
+   templat.width = dec->base.width / 4;
+   templat.height = dec->base.height;
+   templat.chroma_format = dec->base.chroma_format;
dec->idct_source = vl_video_buffer_create_ex
(
-  dec->base.context, dec->base.width / 4, dec->base.height, 1,
-  dec->base.chroma_format, formats, PIPE_USAGE_STATIC
+  dec->base.context, &templat,
+  formats, 1, PIPE_USAGE_STATIC
);
 
if (!dec->idct_source)
   goto error_idct_source;
 
formats[0] = formats[1] = formats[2] = format_config->mc_source_format;
+   memset(&templat, 0, sizeof(templat));
+   templat.width = dec->base.width / nr_of_idct_render_targets;
+   templat.height = dec->base.height / 4;
+   templat.chroma_format = dec->base.chroma_format;
dec->mc_source = vl_video_buffer_create_ex
(
-  dec->base.context, dec->base.width / nr_of_idct_render_targets,
-  dec->base.height / 4, nr_of_idct_render_targets,
-  dec->base.chroma_format, formats, PIPE_USAGE_STATIC
+  dec->base.context, &templat,
+  formats, nr_of_idct_render_targets, PIPE_USAGE_STATIC
);
 
if (!dec->mc_source)
@@ -985,12 +993,17 @@ static bool
 init_mc_source_widthout_idct(struct vl_mpeg12_decoder *dec, const struct 
format_config* format_config)
 {
enum pipe_format formats[3];
+   struct pipe_video_buffer templat;
 
formats[0] = formats[1] = formats[2] = format_config->mc_source_format;
+   memset(&templat, 0, sizeof(templat));
+   templat.width = dec->base.width;
+   templat.height = dec->base.height;
+   templat.chroma_format = dec->base.chroma_format;
dec->mc_source = vl_video_buffer_create_ex
(
-  dec->base.context, dec->base.width, dec->base.height, 1,
-  dec->base.chroma_format, formats, PIPE_USAGE_STATIC
+  dec->base.context, &templat,
+  formats, 1, PIPE_USAGE_STATIC
);
   
return dec->mc_source != NULL;
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c 
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 8ceb713..29d910e 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -253,17 +253,14 @@ error:
 
 struct pipe_video_buffer *
 vl_video_buffer_create(struct pipe_context *pipe,
-   enum pipe_format buffer_format,
-   enum pipe_video_chroma_format chroma_format,
-   unsigned width, unsigned height)
+   const struct pipe_video_buffer *tmpl)
 {
const enum pipe_format *resource_formats;
-   struct pipe_video_buffer *result;
-   unsigned buffer_width, buffer_height;
+   struct pipe_video_buffer templat;
bool pot_buffers;
 
assert(pipe);
-   assert(width > 0 && height > 0);
+   assert(tmpl->width > 0 && tmpl->height > 0);
 
pot_buffers = !pipe->screen->get_video_param
(
@@ -272,30 +269,28 @@ vl_video_buffer_create(struct pipe_context *pipe,
   PIPE_VIDEO_CAP_NPOT_TEXTURES
);
 
-   resource_formats = vl_video_buffer_formats(pipe->screen, buffer_format);
+   resource_formats = vl_video_buffer_formats(pipe->screen, 
tmpl->buffer_format);
if (!resource_formats)
   return NULL;
 
-   buffer_width = pot_buffers ? util_next_power_of_two(width) : align(width, 
MACROBLOCK_WIDTH);
-   buffer_height = pot_buffers ? util_next_power_of_two(height) : 
align(height, MACROBLOCK_HEIGHT);
+   templat = *tmpl;
+   templat.width = pot_buffers ? util_next_power_of_two(tmpl->width)
+ : align(tmpl->width, MACROBLOCK_WIDTH);
+   templat.height = pot_buffers ? util_next_power_of_two(tmpl->height)
+  : align(t

[Mesa-dev] [PATCH 2/9] vl/video_buffer: improve constructor

2012-01-10 Thread Christian König
Add a second extened constructor that takes plane
textures for the video buffer. Also provide a
function for texture templates.

Signed-off-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_video_buffer.c |  112 +---
 src/gallium/auxiliary/vl/vl_video_buffer.h |   17 
 2 files changed, 84 insertions(+), 45 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c 
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 29d910e..008186c 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -126,6 +126,32 @@ vl_video_buffer_get_associated_data(struct 
pipe_video_buffer *vbuf,
   return NULL;
 }
 
+void
+vl_vide_buffer_template(struct pipe_resource *templ,
+const struct pipe_video_buffer *tmpl,
+enum pipe_format resource_format,
+unsigned depth, unsigned usage, unsigned plane)
+{
+   memset(templ, 0, sizeof(*templ));
+   templ->target = depth > 1 ? PIPE_TEXTURE_3D : PIPE_TEXTURE_2D;
+   templ->format = resource_format;
+   templ->width0 = tmpl->width;
+   templ->height0 = tmpl->height;
+   templ->depth0 = depth;
+   templ->array_size = 1;
+   templ->bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
+   templ->usage = usage;
+
+   if (plane > 0) {
+  if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_420) {
+ templ->width0 /= 2;
+ templ->height0 /= 2;
+  } else if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_422) {
+ templ->height0 /= 2;
+  }
+   }
+}
+
 static void
 vl_video_buffer_destroy(struct pipe_video_buffer *buffer)
 {
@@ -292,71 +318,67 @@ vl_video_buffer_create_ex(struct pipe_context *pipe,
   const enum pipe_format 
resource_formats[VL_MAX_PLANES],
   unsigned depth, unsigned usage)
 {
-   struct vl_video_buffer *buffer;
-   struct pipe_resource templ;
+   struct pipe_resource res_tmpl, *resources[VL_MAX_PLANES] = {};
unsigned i;
 
assert(pipe);
 
-   buffer = CALLOC_STRUCT(vl_video_buffer);
-
-   buffer->base = *tmpl;
-   buffer->base.context = pipe;
-   buffer->base.destroy = vl_video_buffer_destroy;
-   buffer->base.get_sampler_view_planes = vl_video_buffer_sampler_view_planes;
-   buffer->base.get_sampler_view_components = 
vl_video_buffer_sampler_view_components;
-   buffer->base.get_surfaces = vl_video_buffer_surfaces;
-   buffer->num_planes = 1;
-
-   memset(&templ, 0, sizeof(templ));
-   templ.target = depth > 1 ? PIPE_TEXTURE_3D : PIPE_TEXTURE_2D;
-   templ.format = resource_formats[0];
-   templ.width0 = tmpl->width;
-   templ.height0 = tmpl->height;
-   templ.depth0 = depth;
-   templ.array_size = 1;
-   templ.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
-   templ.usage = usage;
-
-   buffer->resources[0] = pipe->screen->resource_create(pipe->screen, &templ);
-   if (!buffer->resources[0])
+   vl_vide_buffer_template(&res_tmpl, tmpl, resource_formats[0], depth, usage, 
0);
+   resources[0] = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+   if (!resources[0])
   goto error;
 
if (resource_formats[1] == PIPE_FORMAT_NONE) {
   assert(tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_444);
   assert(resource_formats[2] == PIPE_FORMAT_NONE);
-  return &buffer->base;
-   } else
-  buffer->num_planes = 2;
-
-   templ.format = resource_formats[1];
-   if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_420) {
-  templ.width0 /= 2;
-  templ.height0 /= 2;
-   } else if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_422) {
-  templ.height0 /= 2;
+  return vl_video_buffer_create_ex2(pipe, tmpl, resources);
}
 
-   buffer->resources[1] = pipe->screen->resource_create(pipe->screen, &templ);
-   if (!buffer->resources[1])
+   vl_vide_buffer_template(&res_tmpl, tmpl, resource_formats[1], depth, usage, 
1);
+   resources[1] = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+   if (!resources[1])
   goto error;
 
if (resource_formats[2] == PIPE_FORMAT_NONE)
-  return &buffer->base;
-   else
-  buffer->num_planes = 3;
+  return vl_video_buffer_create_ex2(pipe, tmpl, resources);
 
-   templ.format = resource_formats[2];
-   buffer->resources[2] = pipe->screen->resource_create(pipe->screen, &templ);
-   if (!buffer->resources[2])
+   vl_vide_buffer_template(&res_tmpl, tmpl, resource_formats[2], depth, usage, 
2);
+   resources[2] = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+   if (!resources[2])
   goto error;
 
-   return &buffer->base;
+   return vl_video_buffer_create_ex2(pipe, tmpl, resources);
 
 error:
for (i = 0; i < VL_MAX_PLANES; ++i)
-  pipe_resource_reference(&buffer->resources[i], NULL);
-   FREE(buffer);
+  pipe_resource_reference(&resources[i], NULL);
 
return NULL;
 }
+
+struct pipe_video_buffer *
+vl_video_buffer_create_ex2(struct pipe_context *pipe,
+   const struct pipe_vid

[Mesa-dev] [PATCH 5/9] vl: add h264 infrastructure

2012-01-10 Thread Christian König
No implementation so far, just the defines for
VDPAUs picture info structure.

Signed-off-by: Christian König 
---
 src/gallium/include/pipe/p_video_state.h  |   40 +++
 src/gallium/state_trackers/vdpau/decode.c |   61 +
 2 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/src/gallium/include/pipe/p_video_state.h 
b/src/gallium/include/pipe/p_video_state.h
index ad726d8..9503856 100644
--- a/src/gallium/include/pipe/p_video_state.h
+++ b/src/gallium/include/pipe/p_video_state.h
@@ -247,6 +247,46 @@ struct pipe_vc1_picture_desc
struct pipe_video_buffer *ref[2];
 };
 
+struct pipe_h264_picture_desc
+{
+   struct pipe_picture_desc base;
+
+   uint32_t slice_count;
+   int32_t  field_order_cnt[2];
+   bool is_reference;
+   uint16_t frame_num;
+   uint8_t  field_pic_flag;
+   uint8_t  bottom_field_flag;
+   uint8_t  num_ref_frames;
+   uint8_t  mb_adaptive_frame_field_flag;
+   uint8_t  constrained_intra_pred_flag;
+   uint8_t  weighted_pred_flag;
+   uint8_t  weighted_bipred_idc;
+   uint8_t  frame_mbs_only_flag;
+   uint8_t  transform_8x8_mode_flag;
+   int8_t   chroma_qp_index_offset;
+   int8_t   second_chroma_qp_index_offset;
+   int8_t   pic_init_qp_minus26;
+   uint8_t  num_ref_idx_l0_active_minus1;
+   uint8_t  num_ref_idx_l1_active_minus1;
+   uint8_t  log2_max_frame_num_minus4;
+   uint8_t  pic_order_cnt_type;
+   uint8_t  log2_max_pic_order_cnt_lsb_minus4;
+   uint8_t  delta_pic_order_always_zero_flag;
+   uint8_t  direct_8x8_inference_flag;
+   uint8_t  entropy_coding_mode_flag;
+   uint8_t  pic_order_present_flag;
+   uint8_t  deblocking_filter_control_present_flag;
+   uint8_t  redundant_pic_cnt_present_flag;
+   uint8_t  scaling_lists_4x4[6][16];
+   uint8_t  scaling_lists_8x8[2][64];
+
+   bool   is_long_term[16];
+   bool   top_is_reference[16];
+   bool   bottom_is_reference[16];
+   struct pipe_video_buffer *ref[16];
+};
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/gallium/state_trackers/vdpau/decode.c 
b/src/gallium/state_trackers/vdpau/decode.c
index 2870dc4..fccac4d 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -316,6 +316,63 @@ vlVdpDecoderRenderVC1(struct pipe_vc1_picture_desc 
*picture,
return VDP_STATUS_OK;
 }
 
+static VdpStatus
+vlVdpDecoderRenderH264(struct pipe_h264_picture_desc *picture,
+   VdpPictureInfoH264 *picture_info)
+{
+   unsigned i;
+
+   VDPAU_MSG(VDPAU_TRACE, "[VDPAU] Decoding H264\n");
+
+   picture->slice_count = picture_info->slice_count;
+   picture->field_order_cnt[0] = picture_info->field_order_cnt[0];
+   picture->field_order_cnt[1] = picture_info->field_order_cnt[1];
+   picture->is_reference = picture_info->is_reference;
+   picture->frame_num = picture_info->frame_num;
+   picture->field_pic_flag = picture_info->field_pic_flag;
+   picture->bottom_field_flag = picture_info->bottom_field_flag;
+   picture->num_ref_frames = picture_info->num_ref_frames;
+   picture->mb_adaptive_frame_field_flag = 
picture_info->mb_adaptive_frame_field_flag;
+   picture->constrained_intra_pred_flag = 
picture_info->constrained_intra_pred_flag;
+   picture->weighted_pred_flag = picture_info->weighted_pred_flag;
+   picture->weighted_bipred_idc = picture_info->weighted_bipred_idc;
+   picture->frame_mbs_only_flag = picture_info->frame_mbs_only_flag;
+   picture->transform_8x8_mode_flag = picture_info->transform_8x8_mode_flag;
+   picture->chroma_qp_index_offset = picture_info->chroma_qp_index_offset;
+   picture->second_chroma_qp_index_offset = 
picture_info->second_chroma_qp_index_offset;
+   picture->pic_init_qp_minus26 = picture_info->pic_init_qp_minus26;
+   picture->num_ref_idx_l0_active_minus1 = 
picture_info->num_ref_idx_l0_active_minus1;
+   picture->num_ref_idx_l1_active_minus1 = 
picture_info->num_ref_idx_l1_active_minus1;
+   picture->log2_max_frame_num_minus4 = 
picture_info->log2_max_frame_num_minus4;
+   picture->pic_order_cnt_type = picture_info->pic_order_cnt_type;
+   picture->log2_max_pic_order_cnt_lsb_minus4 = 
picture_info->log2_max_pic_order_cnt_lsb_minus4;
+   picture->delta_pic_order_always_zero_flag = 
picture_info->delta_pic_order_always_zero_flag;
+   picture->direct_8x8_inference_flag = 
picture_info->direct_8x8_inference_flag;
+   picture->entropy_coding_mode_flag = picture_info->entropy_coding_mode_flag;
+   picture->pic_order_present_flag = picture_info->pic_order_present_flag;
+   picture->deblocking_filter_control_present_flag = 
picture_info->deblocking_filter_control_present_flag;
+   picture->redundant_pic_cnt_present_flag = 
picture_info->redundant_pic_cnt_present_flag;
+
+   memcpy(picture->scaling_lists_4x4, picture_info->scaling_lists_4x4, 6*16);
+   memcpy(picture->scaling_lists_8x8, picture_info->scaling_lists_8x8, 2*64);
+
+   for (i = 0; i < 16; ++i) {
+  VdpStatus ret = vlVdpGetReferenceFrame
+  (
+ picture_info->referenceFrames[i].surface,
+ &picture->ref[i]
+

[Mesa-dev] [PATCH 6/9] vl: reintroduce PIPE_VIDEO_CAP_PREFERED_FORMAT

2012-01-10 Thread Christian König
Create the video buffers in the format the driver preffers.
This temporary creates problems with decoder less VDPAU video playback.

Signed-off-by: Christian König 
---
 src/gallium/drivers/nouveau/nouveau_video.c|2 ++
 src/gallium/drivers/nvfx/nvfx_screen.c |2 ++
 src/gallium/drivers/r300/r300_screen.c |2 ++
 src/gallium/drivers/r600/r600_pipe.c   |2 ++
 src/gallium/drivers/softpipe/sp_screen.c   |2 ++
 src/gallium/include/pipe/p_video_enums.h   |3 ++-
 src/gallium/state_trackers/vdpau/surface.c |7 ++-
 src/gallium/state_trackers/xorg/xvmc/surface.c |7 ++-
 8 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_video.c 
b/src/gallium/drivers/nouveau/nouveau_video.c
index 2f9f1ca..47d332a 100644
--- a/src/gallium/drivers/nouveau/nouveau_video.c
+++ b/src/gallium/drivers/nouveau/nouveau_video.c
@@ -835,6 +835,8 @@ nouveau_screen_get_video_param(struct pipe_screen *pscreen,
case PIPE_VIDEO_CAP_MAX_WIDTH:
case PIPE_VIDEO_CAP_MAX_HEIGHT:
   return vl_video_buffer_max_size(pscreen);
+   case PIPE_VIDEO_CAP_PREFERED_FORMAT:
+  return PIPE_FORMAT_NV12;
default:
   debug_printf("unknown video param: %d\n", param);
   return 0;
diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c 
b/src/gallium/drivers/nvfx/nvfx_screen.c
index b4a1b3a..85c5f1a 100644
--- a/src/gallium/drivers/nvfx/nvfx_screen.c
+++ b/src/gallium/drivers/nvfx/nvfx_screen.c
@@ -226,6 +226,8 @@ nvfx_screen_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_MAX_WIDTH:
case PIPE_VIDEO_CAP_MAX_HEIGHT:
return vl_video_buffer_max_size(screen);
+   case PIPE_VIDEO_CAP_PREFERED_FORMAT:
+   return PIPE_FORMAT_NV12;
default:
return 0;
}
diff --git a/src/gallium/drivers/r300/r300_screen.c 
b/src/gallium/drivers/r300/r300_screen.c
index 763321b..cd3c88d 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -307,6 +307,8 @@ static int r300_get_video_param(struct pipe_screen *screen,
   case PIPE_VIDEO_CAP_MAX_WIDTH:
   case PIPE_VIDEO_CAP_MAX_HEIGHT:
  return vl_video_buffer_max_size(screen);
+  case PIPE_VIDEO_CAP_PREFERED_FORMAT:
+ return PIPE_FORMAT_NV12;
   default:
  return 0;
}
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index e50b5cc..96ac687 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -528,6 +528,8 @@ static int r600_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_MAX_WIDTH:
case PIPE_VIDEO_CAP_MAX_HEIGHT:
return vl_video_buffer_max_size(screen);
+   case PIPE_VIDEO_CAP_PREFERED_FORMAT:
+   return PIPE_FORMAT_NV12;
default:
return 0;
}
diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
b/src/gallium/drivers/softpipe/sp_screen.c
index 982af6b..2652620 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -191,6 +191,8 @@ softpipe_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_MAX_WIDTH:
case PIPE_VIDEO_CAP_MAX_HEIGHT:
   return vl_video_buffer_max_size(screen);
+   case PIPE_VIDEO_CAP_PREFERED_FORMAT:
+  return PIPE_FORMAT_NV12;
default:
   return 0;
}
diff --git a/src/gallium/include/pipe/p_video_enums.h 
b/src/gallium/include/pipe/p_video_enums.h
index 1378606..3b61601 100644
--- a/src/gallium/include/pipe/p_video_enums.h
+++ b/src/gallium/include/pipe/p_video_enums.h
@@ -50,7 +50,8 @@ enum pipe_video_cap
PIPE_VIDEO_CAP_SUPPORTED = 0,
PIPE_VIDEO_CAP_NPOT_TEXTURES = 1,
PIPE_VIDEO_CAP_MAX_WIDTH = 2,
-   PIPE_VIDEO_CAP_MAX_HEIGHT = 3
+   PIPE_VIDEO_CAP_MAX_HEIGHT = 3,
+   PIPE_VIDEO_CAP_PREFERED_FORMAT = 4
 };
 
 enum pipe_video_codec
diff --git a/src/gallium/state_trackers/vdpau/surface.c 
b/src/gallium/state_trackers/vdpau/surface.c
index 206a839..60cbbed 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -74,7 +74,12 @@ vlVdpVideoSurfaceCreate(VdpDevice device, VdpChromaType 
chroma_type,
 
p_surf->device = dev;
memset(&tmpl, 0, sizeof(tmpl));
-   tmpl.buffer_format = PIPE_FORMAT_YV12;
+   tmpl.buffer_format = dev->context->pipe->screen->get_video_param
+   (
+  dev->context->pipe->screen,
+  PIPE_VIDEO_PROFILE_UNKNOWN,
+  PIPE_VIDEO_CAP_PREFERED_FORMAT
+   );
tmpl.chroma_format = ChromaToPipe(chroma_type);
tmpl.width = width;
tmpl.height = height;
diff --git a/src/gallium/state_trackers/xorg/xvmc/surface.c 
b/src/gallium/state_trackers/xorg/xvmc/surface.c
index 06a3eb9..f1c3271 100644
--- a/src/gallium/state_trackers/xorg/xvmc/surface.c
+++ b/src/gallium/state_trackers/xorg/xvmc/surface.c
@@ -175,7 +175,12 @@ Status XvMCCreateSurface(Disp

[Mesa-dev] [PATCH 7/9] st/vdpau: recreate video buffer if format doesn't match

2012-01-10 Thread Christian König
Recreate the video buffer in PutBitsYCbCr if the format doesn't match.

Signed-off-by: Christian König 
---
 src/gallium/state_trackers/vdpau/surface.c   |   54 ++---
 src/gallium/state_trackers/vdpau/vdpau_private.h |2 +-
 2 files changed, 37 insertions(+), 19 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/surface.c 
b/src/gallium/state_trackers/vdpau/surface.c
index 60cbbed..8fdfafc 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -44,7 +44,7 @@ vlVdpVideoSurfaceCreate(VdpDevice device, VdpChromaType 
chroma_type,
 uint32_t width, uint32_t height,
 VdpVideoSurface *surface)
 {
-   struct pipe_video_buffer tmpl;
+   struct pipe_context *pipe;
vlVdpSurface *p_surf;
VdpStatus ret;
 
@@ -73,21 +73,19 @@ vlVdpVideoSurfaceCreate(VdpDevice device, VdpChromaType 
chroma_type,
}
 
p_surf->device = dev;
-   memset(&tmpl, 0, sizeof(tmpl));
-   tmpl.buffer_format = dev->context->pipe->screen->get_video_param
+   pipe = dev->context->pipe;
+
+   memset(&p_surf->templat, 0, sizeof(p_surf->templat));
+   p_surf->templat.buffer_format = pipe->screen->get_video_param
(
-  dev->context->pipe->screen,
+  pipe->screen,
   PIPE_VIDEO_PROFILE_UNKNOWN,
   PIPE_VIDEO_CAP_PREFERED_FORMAT
);
-   tmpl.chroma_format = ChromaToPipe(chroma_type);
-   tmpl.width = width;
-   tmpl.height = height;
-   p_surf->video_buffer = dev->context->pipe->create_video_buffer
-   (
-  dev->context->pipe,
-  &tmpl
-   );
+   p_surf->templat.chroma_format = ChromaToPipe(chroma_type);
+   p_surf->templat.width = width;
+   p_surf->templat.height = height;
+   p_surf->video_buffer = pipe->create_video_buffer(pipe, &p_surf->templat);
 
*surface = vlAddDataHTAB(p_surf);
if (*surface == 0) {
@@ -143,9 +141,15 @@ vlVdpVideoSurfaceGetParameters(VdpVideoSurface surface,
if (!p_surf)
   return VDP_STATUS_INVALID_HANDLE;
 
-   *width = p_surf->video_buffer->width;
-   *height = p_surf->video_buffer->height;
-   *chroma_type = PipeToChroma(p_surf->video_buffer->chroma_format);
+   if (p_surf->video_buffer) {
+  *width = p_surf->video_buffer->width;
+  *height = p_surf->video_buffer->height;
+  *chroma_type = PipeToChroma(p_surf->video_buffer->chroma_format);
+   } else {
+  *width = p_surf->templat.width;
+  *height = p_surf->templat.height;
+  *chroma_type = PipeToChroma(p_surf->templat.chroma_format);
+   }
 
return VDP_STATUS_OK;
 }
@@ -200,9 +204,23 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
if (!pipe)
   return VDP_STATUS_INVALID_HANDLE;
 
-   if (p_surf->video_buffer == NULL || pformat != 
p_surf->video_buffer->buffer_format) {
-  assert(0); // TODO Recreate resource
-  return VDP_STATUS_NO_IMPLEMENTATION;
+   if (p_surf->video_buffer == NULL || p_surf->video_buffer->interlaced ||
+   pformat != p_surf->video_buffer->buffer_format) {
+
+  /* destroy the old one */
+  if (p_surf->video_buffer)
+ p_surf->video_buffer->destroy(p_surf->video_buffer);
+
+  /* adjust the template parameters */
+  p_surf->templat.buffer_format = pformat;
+  p_surf->templat.interlaced = false;
+
+  /* and try to create the video buffer with the new format */
+  p_surf->video_buffer = pipe->create_video_buffer(pipe, &p_surf->templat);
+
+  /* stil no luck? ok forget it we don't support it */
+  if (!p_surf->video_buffer)
+ return VDP_STATUS_NO_IMPLEMENTATION;
}
 
sampler_views = 
p_surf->video_buffer->get_sampler_view_planes(p_surf->video_buffer);
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h 
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 1bbbaa9..912f73d 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -316,7 +316,7 @@ typedef struct
 typedef struct
 {
vlVdpDevice *device;
-   struct pipe_video_buffer *video_buffer;
+   struct pipe_video_buffer templat, *video_buffer;
 } vlVdpSurface;
 
 typedef uint64_t vlVdpTime;
-- 
1.7.5.4

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


[Mesa-dev] [PATCH 8/9] st/vdpau: recreate video buffer if decode doesn't like it

2012-01-10 Thread Christian König
Recreate the video buffer if the decoder can't handle it.

Signed-off-by: Christian König 
---
 src/gallium/state_trackers/vdpau/decode.c |   22 +-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/decode.c 
b/src/gallium/state_trackers/vdpau/decode.c
index fccac4d..898faa9 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -388,6 +388,7 @@ vlVdpDecoderRender(VdpDecoder decoder,
vlVdpDecoder *vldecoder;
vlVdpSurface *vlsurf;
VdpStatus ret;
+   struct pipe_screen *screen;
struct pipe_video_decoder *dec;
unsigned i;
union {
@@ -407,6 +408,7 @@ vlVdpDecoderRender(VdpDecoder decoder,
if (!vldecoder)
   return VDP_STATUS_INVALID_HANDLE;
dec = vldecoder->decoder;
+   screen = dec->context->screen;
 
vlsurf = (vlVdpSurface *)vlGetDataHTAB(target);
if (!vlsurf)
@@ -415,10 +417,28 @@ vlVdpDecoderRender(VdpDecoder decoder,
if (vlsurf->device != vldecoder->device)
   return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
 
-   if (vlsurf->video_buffer->chroma_format != dec->chroma_format)
+   if (vlsurf->video_buffer != NULL && vlsurf->video_buffer->chroma_format != 
dec->chroma_format)
   // TODO: Recreate decoder with correct chroma
   return VDP_STATUS_INVALID_CHROMA_TYPE;
 
+   if (vlsurf->video_buffer == NULL ||
+   !screen->is_video_format_supported(screen, 
vlsurf->video_buffer->buffer_format, dec->profile)) {
+
+  /* destroy the old one */
+  if (vlsurf->video_buffer)
+ vlsurf->video_buffer->destroy(vlsurf->video_buffer);
+
+  /* set the buffer format to the prefered one */
+  vlsurf->templat.buffer_format = screen->get_video_param(screen, 
dec->profile, PIPE_VIDEO_CAP_PREFERED_FORMAT);
+
+  /* and recreate the video buffer */
+  vlsurf->video_buffer = dec->context->create_video_buffer(dec->context, 
&vlsurf->templat);
+
+  /* still no luck? get me out of here... */
+  if (!vlsurf->video_buffer)
+ return VDP_STATUS_NO_IMPLEMENTATION;
+   }
+
memset(&desc, 0, sizeof(desc));
desc.base.profile = dec->profile;
switch (u_reduce_video_profile(dec->profile)) {
-- 
1.7.5.4

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


[Mesa-dev] [PATCH 9/9] vl: fix YV12 handling

2012-01-10 Thread Christian König
We actually implemented YV21 instead of YV12, so fix the plane ordering.

Signed-off-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.c |   13 +---
 src/gallium/auxiliary/vl/vl_video_buffer.c   |   37 +++--
 src/gallium/auxiliary/vl/vl_video_buffer.h   |6 
 src/gallium/state_trackers/vdpau/surface.c   |2 +-
 4 files changed, 49 insertions(+), 9 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index bd98089..dae063e 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -678,6 +678,7 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
struct pipe_vertex_buffer vb[3];
struct vl_mpeg12_buffer *buf;
 
+   const unsigned *plane_order;
unsigned i, j, component;
unsigned nr_components;
 
@@ -731,24 +732,26 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
  vl_idct_flush(i ? &dec->idct_c : &dec->idct_y, &buf->idct[i], 
buf->num_ycbcr_blocks[i]);
}
 
+   plane_order = vl_video_buffer_plane_order(target->buffer_format);
mc_source_sv = dec->mc_source->get_sampler_view_planes(dec->mc_source);
for (i = 0, component = 0; i < VL_MAX_PLANES; ++i) {
   if (!target_surfaces[i]) continue;
 
   nr_components = 
util_format_get_nr_components(target_surfaces[i]->texture->format);
   for (j = 0; j < nr_components; ++j, ++component) {
- if (!buf->num_ycbcr_blocks[i]) continue;
+ unsigned plane = plane_order[component];
+ if (!buf->num_ycbcr_blocks[plane]) continue;
 
- vb[1] = vl_vb_get_ycbcr(&buf->vertex_stream, component);
+ vb[1] = vl_vb_get_ycbcr(&buf->vertex_stream, plane);
  dec->base.context->set_vertex_buffers(dec->base.context, 2, vb);
 
  if (dec->base.entrypoint <= PIPE_VIDEO_ENTRYPOINT_IDCT)
-vl_idct_prepare_stage2(i ? &dec->idct_c : &dec->idct_y, 
&buf->idct[component]);
+vl_idct_prepare_stage2(i ? &dec->idct_c : &dec->idct_y, 
&buf->idct[plane]);
  else {
-dec->base.context->set_fragment_sampler_views(dec->base.context, 
1, &mc_source_sv[component]);
+dec->base.context->set_fragment_sampler_views(dec->base.context, 
1, &mc_source_sv[plane]);
 dec->base.context->bind_fragment_sampler_states(dec->base.context, 
1, &dec->sampler_ycbcr);
  }
- vl_mc_render_ycbcr(i ? &dec->mc_c : &dec->mc_y, &buf->mc[i], j, 
buf->num_ycbcr_blocks[component]);
+ vl_mc_render_ycbcr(i ? &dec->mc_c : &dec->mc_y, &buf->mc[i], j, 
buf->num_ycbcr_blocks[plane]);
   }
}
++dec->current_buffer;
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c 
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 21a2a89..d4e453a 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -44,12 +44,24 @@ const enum pipe_format const_resource_formats_YV12[3] = {
PIPE_FORMAT_R8_UNORM
 };
 
+const unsigned const_resource_plane_order_YV12[3] = {
+   0,
+   2,
+   1
+};
+
 const enum pipe_format const_resource_formats_NV12[3] = {
PIPE_FORMAT_R8_UNORM,
PIPE_FORMAT_R8G8_UNORM,
PIPE_FORMAT_NONE
 };
 
+const unsigned const_resource_plane_order_NV12[3] = {
+   0,
+   1,
+   2
+};
+
 const enum pipe_format *
 vl_video_buffer_formats(struct pipe_screen *screen, enum pipe_format format)
 {
@@ -65,6 +77,21 @@ vl_video_buffer_formats(struct pipe_screen *screen, enum 
pipe_format format)
}
 }
 
+const unsigned *
+vl_video_buffer_plane_order(enum pipe_format format)
+{
+switch(format) {
+   case PIPE_FORMAT_YV12:
+  return const_resource_plane_order_YV12;
+
+   case PIPE_FORMAT_NV12:
+  return const_resource_plane_order_NV12;
+
+   default:
+  return NULL;
+   }
+}
+
 boolean
 vl_video_buffer_is_format_supported(struct pipe_screen *screen,
 enum pipe_format format,
@@ -215,24 +242,28 @@ vl_video_buffer_sampler_view_components(struct 
pipe_video_buffer *buffer)
struct vl_video_buffer *buf = (struct vl_video_buffer *)buffer;
struct pipe_sampler_view sv_templ;
struct pipe_context *pipe;
+   const unsigned *plane_order;
unsigned i, j, component;
 
assert(buf);
 
pipe = buf->base.context;
 
+   plane_order = vl_video_buffer_plane_order(buf->base.buffer_format);
+
for (component = 0, i = 0; i < buf->num_planes; ++i ) {
-  unsigned nr_components = 
util_format_get_nr_components(buf->resources[i]->format);
+  struct pipe_resource *res = buf->resources[plane_order[i]];
+  unsigned nr_components = util_format_get_nr_components(res->format);
 
   for (j = 0; j < nr_components; ++j, ++component) {
  assert(component < VL_MAX_PLANES);
 
  if (!buf->sampler_view_components[component]) {
 memset(&sv_templ, 0, sizeof(sv_templ));
-u_sampler_view_default_template(&sv_templ, buf->resources[i],

Re: [Mesa-dev] [PATCH 3/3] vl: replace decode_buffers with auxiliary data field

2012-01-10 Thread Christian König

Hi Maarten,

On 08.01.2012 14:09, Maarten Lankhorst wrote:
Ok. I wont block it any more then. Do you have a followup patch to get 
rid of quant matrix and separate reference pictures too? Or should I 
resend it, I kind of lost my rebased git tree, so if you already have 
the followup patches it would be nice if you could post them.


Cheers,
Acked-by: Maarten Lankhorst 

Yeah, I've just send a couple of patches to the list which includes 
parts of your patch and also a patch adding the H264 infrastructure.


Please take a look,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] softpipe GL3 status

2012-01-10 Thread Dave Airlie
>>
>> Something in Gallium is probably deciding that GL_DEPTH_COMPONENT is
>> invalid for a cubemap and marking it as incomplete.
>
>
> Hmmm, I'm not sure what would be preventing cube textures in gallium or the
> state tracker.

Something in Mesa is doing it,

texobj.c:_mesa_test_texobj_completeness

has a check for CUBE + DEPTH_COMPONENT on line 674.

How should we remove that with a GL3 version check?

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


Re: [Mesa-dev] softpipe GL3 status

2012-01-10 Thread Brian Paul

On 01/10/2012 09:06 AM, Dave Airlie wrote:


Something in Gallium is probably deciding that GL_DEPTH_COMPONENT is
invalid for a cubemap and marking it as incomplete.



Hmmm, I'm not sure what would be preventing cube textures in gallium or the
state tracker.


Something in Mesa is doing it,

texobj.c:_mesa_test_texobj_completeness

has a check for CUBE + DEPTH_COMPONENT on line 674.

How should we remove that with a GL3 version check?


My first inclination is:

 if (ctx->VersionMajor < 3 && t->Image[face][i]->_BaseFormat == 
GL_DEPTH_COMPONENT) {


So we basically assume that depth cubes work if all the other GL3 
features are available.


The other approach would be to define a (hidden) extension flag 
indicating support for depth cubes which GL3 would depend on.


I don't have a strong preference.

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


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Jose Fonseca
- Original Message -
> On Tue, Jan 10, 2012 at 12:29 PM, Jose Fonseca 
> wrote:
> > Still catching up on email traffic during holidays...
> >
> > I agree that user buffer uploads should be moved out of drivers,
> > but I don't think this is the way to go.
> >
> > This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes
> > the ability to transform this data in any way before reashing the
> > GPU -- i.e., prevents any sort of workarounds -- something can't
> > be always guaranteed. Flushing with map helps is also
> > non-portable.
> 
> The flag is optional, it doesn't have to implemented by everybody. If
> we do the uploads in the state tracker, we will also do any required
> data transformation so that drivers don't have to do it at all.

The same can be said for everything.

I don't object adding yet another code path specific to a subset of hardware, 
provided the benefits justify its existence.

But honestly I'm not yet convinced of this, as there was no attempt to backup 
with solid arguments why this matters.

Furthermore this violates one of the principles gallium (and all 3D apis) have 
of unmapping all resources when drawing.

> > It looks to me that state trackers and/or drivers are not properly
> > using PIPE_USAGE_STREAM flag.  As all cases where
> > PIPE_TRANSFER_MAP_PERMANENTLY would be used, the right way to do
> > it would be for the state tracker to set PIPE_USAGE_STREAM, the
> > pipe driver to recognize PIPE_USAGE_STREAM, and keep the mapping
> > permanently internally, making mapping/unmapping of such buffers
> > mere no-ops.
> 
> We were doing that already and it wasn't good enough. Avoiding
> create+map+unmap+destroy *calls* have brought higher frame rates in
> apps with lots of draw operations.

I understand the number map/unmap call is reduced. But how does this interface 
change affect in any way the number of create/destroy calls?

Also, please provide app name and performance figures w/ this change.

Jose

PS: Keith Whitwell de-fact no longer is the Gallium's "Benevolent Dictator for 
Life", but we'll need to institute/enforce more due process with Gallium 
interface changes to ensure that gallium doesn't become something radically 
different from its vision & future requirements.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Christoph Bumiller
On 01/10/2012 01:13 PM, Jose Fonseca wrote:
> - Original Message -
>> On 10.01.2012 12:29, Jose Fonseca wrote:
>>> Still catching up on email traffic during holidays...
>>>
>>> I agree that user buffer uploads should be moved out of drivers,
>>> but I don't think this is the way to go.
>>
>> I don't. If the state tracker uploads user buffers and presents them
>> to
>> the driver as normal buffers, it will have to change the
>> pipe_vertex_buffers for each draw, causing annoying re-validation
>> overhead. 
> 
> This is not strictly necessary.  We could simply use index_bias provided the 
> vertex strides don't change (the likely scenario for the sort of cases you 
> are talking here). Thomas did that something along those lines for the svga 
> driver.
> 
Changing the index bias changes the VertexID, so you can't. But I
suppose we could add a second index bias that doesn't affect it ...

> And we could do much better than that: I'm talking about proper 
> reverse-engineering of the application intention, such as using one-shot 
> dynamic vertex buffers for one-shot data, and reusable static vertex buffers 
> for immutable data. Employing both heuristics like scanning the user memory 
> for changes and end of data; and also get information from the OS virtual 
> memory subsystem (e.g., if the user memory pointer is in a read-only segment 
> then it won't likely change, if it's in a stack segment it will likely be 
> one-off, if its in malloc, then we can get an upper bound from the OS).   
> This analysis / memory tracking is something too complex to do for each 
> driver, but worthwhile if its done in the state tracker for all drivers 
> benefit.
> 
> I honestly think that's unnecessary to bother pipe drivers with user pointers 
> and that we should put our bets on solving this problem efficiently once for 
> all -- but I'm fine leaving these user pointers in the interface eternally, 
> for sake of both skeptics and software renderers (who can always benefit from 
> accessing user memory directly). 
> 
> 
>> This is very bad if there are a lot of small draw calls.
>> Unfortunately many applications do this, and we do care about these
>> cases.
>>
>> Also, another example I'm dealing with atm, it will be difficult to
>> extract a small set of wide-spread vertices from a user buffer into a
>> oneshot vertex buffer (there are apps where this really helps a lot)
>> because you're changing the vertex index / gl_VertexID.
>> I can do that, because I know the hw has a special vertex-index
>> buffer
>> (nvc0) or manual VERTEX_ID attribute (nv50) that can be routed to the
>> VERTEXID system value so I don't need to modify the shader.
> 
> Backing user buffers on hardware buffers does not necessary imply remapping 
> vertices -- that's merely how it is implemented now. We could either create a 
> one-shot hardware buffer with the same size and fill in just the necessary 
> spots; or better to recognize the underlying user memory buffer start and 
> size and track changes. We could also expose this vertex-index buffer in the 
> interface (other drivers could implement it as vertex texture).
> 

Filling in just the necessary spots wastes a lot of space, especially if
these spots are re-used with different data (you need to reallocate
space), and checking if the relevant data changed is a performance loss
in itself.

> 
> Probably the best approach is a mixture: back big dynamic/static user buffers 
> in individual hardware buffers, back small dynamic user buffers in linearly 
> suballocated ranges of coarse sized hardware buffers (i.e., what we do now).
> 

In the end, I'll only be convinced removing user buffers is good if the
new solution performs equally or better in all cases (or at least not
significantly worse in the ugliest of cases) ...

> 
> Jose

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


[Mesa-dev] [PATCH] mesa: fix cubemap depth completeness test

2012-01-10 Thread Dave Airlie
From: Dave Airlie 

This fixes the test to allow cube/depth combinations on GL3
or EXT_gpu_shader4.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/texobj.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 7ee2005..dc6e309 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -672,9 +672,11 @@ _mesa_test_texobj_completeness( const struct gl_context 
*ctx,
 return;
  }
  /* Don't support GL_DEPTH_COMPONENT for cube maps */
- if (t->Image[face][i]->_BaseFormat == GL_DEPTH_COMPONENT) {
-incomplete(t, "GL_DEPTH_COMPONENT only works with 1/2D 
tex");
-return;
+  if (ctx->VersionMajor < 3 && 
!ctx->Extensions.EXT_gpu_shader4) {
+ if (t->Image[face][i]->_BaseFormat == GL_DEPTH_COMPONENT) 
{
+incomplete(t, "GL_DEPTH_COMPONENT only works with 1/2D 
tex");
+return;
+ }
  }
  /* check that all six images have same size */
   if (t->Image[face][i]->Width2 != width || 
-- 
1.7.7.4

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


Re: [Mesa-dev] [PATCH 1/2] st_extensions: fixup GLSL 1.30 related enables

2012-01-10 Thread Marek Olšák
On Tue, Jan 10, 2012 at 12:49 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This just fixes up the enables for native integers and EXT_texture_integer
> support in st/mesa.
>
> It also set the MaxClipPlanes to 8.
>
> We should consider exposing caps for MCP vs MCD, but since core
> mesa doesn't care yet maybe we can wait for now.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/state_tracker/st_extensions.c |   31 +--
>  1 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index a9d4054..d583c88 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -263,12 +263,6 @@ void st_init_extensions(struct st_context *st)
>    ctx->Const.GLSLVersion = 120;
>    _mesa_override_glsl_version(st->ctx);
>
> -   /* Extensions that only depend on the GLSL version:
> -    */
> -   if (ctx->Const.GLSLVersion >= 130) {
> -      ctx->Extensions.ARB_conservative_depth = GL_TRUE;
> -   }
> -
>    /*
>     * Extensions that are supported by all Gallium drivers:
>     */
> @@ -587,6 +581,23 @@ void st_init_extensions(struct st_context *st)
>  #endif
>    }
>
> +   if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
> +                                PIPE_SHADER_CAP_INTEGERS) &&
> +       screen->get_shader_param(screen, PIPE_SHADER_FRAGMENT,
> +                                PIPE_SHADER_CAP_INTEGERS)) {
> +      ctx->Const.NativeIntegers = GL_TRUE;
> +   }
> +
> +   if (ctx->Const.NativeIntegers)
> +      ctx->Const.GLSLVersion = 130;
> +
> +   /* Extensions that only depend on the GLSL version:
> +    */
> +   if (ctx->Const.GLSLVersion >= 130) {
> +      ctx->Extensions.ARB_conservative_depth = GL_TRUE;
> +      ctx->Const.MaxClipPlanes = 8;
> +   }
> +
>    ctx->Extensions.NV_primitive_restart = GL_TRUE;
>    if (!screen->get_param(screen, PIPE_CAP_PRIMITIVE_RESTART)) {
>       st->sw_primitive_restart = GL_TRUE;
> @@ -703,4 +714,12 @@ void st_init_extensions(struct st_context *st)
>          ctx->Extensions.ARB_transform_feedback2 = GL_TRUE;
>       }
>    }
> +
> +   if (ctx->Const.NativeIntegers &&
> +       screen->is_format_supported(screen, PIPE_FORMAT_R8G8B8A8_UINT, 
> PIPE_TEXTURE_2D, 0,
> +                                   PIPE_BIND_SAMPLER_VIEW | 
> PIPE_BIND_RENDER_TARGET) &&
> +       screen->is_format_supported(screen, PIPE_FORMAT_R8G8B8A8_SINT, 
> PIPE_TEXTURE_2D, 0,
> +                                   PIPE_BIND_SAMPLER_VIEW | 
> PIPE_BIND_RENDER_TARGET))
> +      ctx->Extensions.EXT_texture_integer = GL_TRUE;

I think it would be better to require 32_32_32_32, because it may not
be correct to fallback into a lower-precision format. (imagine
somebody creates GL_RGBA32UI and wants to store 0x800 in it)

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


[Mesa-dev] [Bug 44561] Piglit: spec/glsl-1.10/execution/interpolation/interpolation-none-gl_*-vertex fail

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44561

--- Comment #2 from Christoph Bumiller  
2012-01-10 08:26:03 PST ---
Like I already mentioned on ML, i915g isn't using the ClipVertex for the
clipping calculation, but Position (ClipVertex didn't exist before, thus
whenever it was not equal to gl_Position things wouldn't have worked properly). 

The reason it worked before lies in the nature of the test.

The transformation done to the plane coefficients is the inverse of the
transformation from gl_ClipVertex and gl_Position; the prior is correctly
omitted now if a vertex shader is bound in OpenGL.

-- 
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


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Jose Fonseca


- Original Message -
> On 01/10/2012 01:13 PM, Jose Fonseca wrote:
> > - Original Message -
> >> On 10.01.2012 12:29, Jose Fonseca wrote:
> >>> Still catching up on email traffic during holidays...
> >>>
> >>> I agree that user buffer uploads should be moved out of drivers,
> >>> but I don't think this is the way to go.
> >>
> >> I don't. If the state tracker uploads user buffers and presents
> >> them
> >> to
> >> the driver as normal buffers, it will have to change the
> >> pipe_vertex_buffers for each draw, causing annoying re-validation
> >> overhead.
> > 
> > This is not strictly necessary.  We could simply use index_bias
> > provided the vertex strides don't change (the likely scenario for
> > the sort of cases you are talking here). Thomas did that something
> > along those lines for the svga driver.
> > 
> Changing the index bias changes the VertexID, so you can't. But I
> suppose we could add a second index bias that doesn't affect it ...
> 
> > And we could do much better than that: I'm talking about proper
> > reverse-engineering of the application intention, such as using
> > one-shot dynamic vertex buffers for one-shot data, and reusable
> > static vertex buffers for immutable data. Employing both
> > heuristics like scanning the user memory for changes and end of
> > data; and also get information from the OS virtual memory
> > subsystem (e.g., if the user memory pointer is in a read-only
> > segment then it won't likely change, if it's in a stack segment it
> > will likely be one-off, if its in malloc, then we can get an upper
> > bound from the OS).   This analysis / memory tracking is something
> > too complex to do for each driver, but worthwhile if its done in
> > the state tracker for all drivers benefit.
> > 
> > I honestly think that's unnecessary to bother pipe drivers with
> > user pointers and that we should put our bets on solving this
> > problem efficiently once for all -- but I'm fine leaving these
> > user pointers in the interface eternally, for sake of both
> > skeptics and software renderers (who can always benefit from
> > accessing user memory directly).
> > 
> > 
> >> This is very bad if there are a lot of small draw calls.
> >> Unfortunately many applications do this, and we do care about
> >> these
> >> cases.
> >>
> >> Also, another example I'm dealing with atm, it will be difficult
> >> to
> >> extract a small set of wide-spread vertices from a user buffer
> >> into a
> >> oneshot vertex buffer (there are apps where this really helps a
> >> lot)
> >> because you're changing the vertex index / gl_VertexID.
> >> I can do that, because I know the hw has a special vertex-index
> >> buffer
> >> (nvc0) or manual VERTEX_ID attribute (nv50) that can be routed to
> >> the
> >> VERTEXID system value so I don't need to modify the shader.
> > 
> > Backing user buffers on hardware buffers does not necessary imply
> > remapping vertices -- that's merely how it is implemented now. We
> > could either create a one-shot hardware buffer with the same size
> > and fill in just the necessary spots; or better to recognize the
> > underlying user memory buffer start and size and track changes. We
> > could also expose this vertex-index buffer in the interface (other
> > drivers could implement it as vertex texture).
> > 
> 
> Filling in just the necessary spots wastes a lot of space, especially
> if
> these spots are re-used with different data (you need to reallocate
> space), and checking if the relevant data changed is a performance
> loss
> in itself.

Don't forget that the alternative to checking is to copy blindly, which also 
implies reading the source.  If one uses hashes instead of compares, and one 
can determine statistically that certain contents is usually immutable, then 
one can guarantee that checking to be a win, especially considering the 
bandwidth difference on PCIe vs VRAM.

After a couple of frames it should be clear whether a user memory buffer at a 
given address is static or dynamic.

> 
> > 
> > Probably the best approach is a mixture: back big dynamic/static
> > user buffers in individual hardware buffers, back small dynamic
> > user buffers in linearly suballocated ranges of coarse sized
> > hardware buffers (i.e., what we do now).
> > 
> 
> In the end, I'll only be convinced removing user buffers is good if
> the
> new solution performs equally or better in all cases (or at least not
> significantly worse in the ugliest of cases) ...

Of course. As I said, I'm fine w/ leaving user buffers interface if just for 
software renderers sake. And this is all just an idea at this stage.

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


[Mesa-dev] [Bug 44564] Fix build with LLVM -DLLVM_TARGETS_TO_BUILD=`native`

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44564

--- Comment #3 from Vinson Lee  2012-01-10 08:56:58 PST 
---
(In reply to comment #2)
> Anyway, Mesa doesn't need LLVM libraries except in `$LLVM_CONFIG --libs 
> engine`
> to build/run?

I tried the SCons build using 'llvm-config --libs engine' and Mesa fails to
build.

$ scons
[...]
  Linking build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend ...
build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend.o: In function
`test_one':
mesa/src/gallium/drivers/llvmpipe/lp_test_blend.c:691: undefined reference to
`LLVMWriteBitcodeToFile'
build/linux-x86_64-debug/gallium/auxiliary/libgallium.a(lp_bld_debug.os): In
function `llvm::InitializeAllDisassemblers()':
/usr/lib/llvm-2.8/include/llvm/Config/Disassemblers.def:27: undefined reference
to `LLVMInitializeARMDisassembler'

-- 
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


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Marek Olšák
On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca  wrote:
> - Original Message -
>> The flag is optional, it doesn't have to implemented by everybody. If
>> we do the uploads in the state tracker, we will also do any required
>> data transformation so that drivers don't have to do it at all.
>
> The same can be said for everything.
>
> I don't object adding yet another code path specific to a subset of hardware, 
> provided the benefits justify its existence.
>
> But honestly I'm not yet convinced of this, as there was no attempt to backup 
> with solid arguments why this matters.
>
> Furthermore this violates one of the principles gallium (and all 3D apis) 
> have of unmapping all resources when drawing.

If my idea violates one principle of all 3D APIs, this violates them all:
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt

It allows reading user memory by hardware, and neither the driver nor
the hardware is notified when the memory contents are changed by the
user.

BTW, I don't insist on this. I thought it would be a nice addition
allowing user buffer uploads to be moved out of (especially radeon)
drivers. If you really believe it's a bad optimization, feel free to
revert. WIthout it, things wouldn't change for me at all...

>
>> > It looks to me that state trackers and/or drivers are not properly
>> > using PIPE_USAGE_STREAM flag.  As all cases where
>> > PIPE_TRANSFER_MAP_PERMANENTLY would be used, the right way to do
>> > it would be for the state tracker to set PIPE_USAGE_STREAM, the
>> > pipe driver to recognize PIPE_USAGE_STREAM, and keep the mapping
>> > permanently internally, making mapping/unmapping of such buffers
>> > mere no-ops.
>>
>> We were doing that already and it wasn't good enough. Avoiding
>> create+map+unmap+destroy *calls* have brought higher frame rates in
>> apps with lots of draw operations.
>
> I understand the number map/unmap call is reduced. But how does this 
> interface change affect in any way the number of create/destroy calls?

create = get_transfer
destroy = transfer_destroy

>
> Also, please provide app name and performance figures w/ this change.

OK. Torcs, the Forza track at the start.

With u_upload_unmap before drawing:
21.4 - 22.1 fps

Without u_upload_unmap:
22.7 - 23.1 fps

The improvement is approximately 1.1 fps, which is probably too little
for other people to care, but why throw it away?

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


[Mesa-dev] [Bug 44561] Piglit: spec/glsl-1.10/execution/interpolation/interpolation-none-gl_*-vertex fail

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44561

--- Comment #3 from Kai  2012-01-10 09:11:19 PST 
---
(In reply to comment #2)
So do I understand you correctly, that this bug is then no regression for r600g
and i915g (I'm seeing this on r600g)? If so, the "regression" keyword should
probably be deleted.

-- 
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


Re: [Mesa-dev] [PATCH 2/2] gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY

2012-01-10 Thread Jose Fonseca


- Original Message -
> On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca 
> wrote:
> > - Original Message -
> >> The flag is optional, it doesn't have to implemented by everybody.
> >> If
> >> we do the uploads in the state tracker, we will also do any
> >> required
> >> data transformation so that drivers don't have to do it at all.
> >
> > The same can be said for everything.
> >
> > I don't object adding yet another code path specific to a subset of
> > hardware, provided the benefits justify its existence.
> >
> > But honestly I'm not yet convinced of this, as there was no attempt
> > to backup with solid arguments why this matters.
> >
> > Furthermore this violates one of the principles gallium (and all 3D
> > apis) have of unmapping all resources when drawing.
> 
> If my idea violates one principle of all 3D APIs, this violates them
> all:
> http://www.opengl.org/registry/specs/AMD/pinned_memory.txt

Indeed.

> It allows reading user memory by hardware, and neither the driver nor
> the hardware is notified when the memory contents are changed by the
> user.
>
> BTW, I don't insist on this. I thought it would be a nice addition
> allowing user buffer uploads to be moved out of (especially radeon)
> drivers. If you really believe it's a bad optimization, feel free to
> revert. WIthout it, things wouldn't change for me at all...

Fair enough.

> >
> >> > It looks to me that state trackers and/or drivers are not
> >> > properly
> >> > using PIPE_USAGE_STREAM flag.  As all cases where
> >> > PIPE_TRANSFER_MAP_PERMANENTLY would be used, the right way to do
> >> > it would be for the state tracker to set PIPE_USAGE_STREAM, the
> >> > pipe driver to recognize PIPE_USAGE_STREAM, and keep the mapping
> >> > permanently internally, making mapping/unmapping of such buffers
> >> > mere no-ops.
> >>
> >> We were doing that already and it wasn't good enough. Avoiding
> >> create+map+unmap+destroy *calls* have brought higher frame rates
> >> in
> >> apps with lots of draw operations.
> >
> > I understand the number map/unmap call is reduced. But how does
> > this interface change affect in any way the number of
> > create/destroy calls?
> 
> create = get_transfer
> destroy = transfer_destroy

Ah. BTW, we should probably unify create+map and destroy+unmap to reduce 
overhead. I would probably helps here.

> > Also, please provide app name and performance figures w/ this
> > change.
> 
> OK. Torcs, the Forza track at the start.
> 
> With u_upload_unmap before drawing:
> 21.4 - 22.1 fps
> 
> Without u_upload_unmap:
> 22.7 - 23.1 fps


> The improvement is approximately 1.1 fps, which is probably too
> little
> for other people to care, but why throw it away?

This is roughly 5%. It is still significant.

But it surprises me it is so high.

Perhaps we should have a couple of fast entrypoints for transfering to/from 
buffers without the overhead of creating transfer objects.

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


[Mesa-dev] [Bug 44561] Piglit: spec/glsl-1.10/execution/interpolation/interpolation-none-gl_*-vertex fail

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44561

Christoph Bumiller  changed:

   What|Removed |Added

   Keywords|regression  |

--- Comment #4 from Christoph Bumiller  
2012-01-10 09:24:14 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> So do I understand you correctly, that this bug is then no regression for 
> r600g
> and i915g (I'm seeing this on r600g)? If so, the "regression" keyword should
> probably be deleted.

Correct, it's a glsl 1.2 feature that's not been implemented on these drivers
yet.

-- 
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 44561] Piglit: spec/glsl-1.10/execution/interpolation/interpolation-none-gl_*-vertex fail

2012-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44561

--- Comment #5 from Stephane Marchesin  2012-01-10 
10:33:00 PST ---
I don't think it's a bug in i915g proper, since we don't handle vertex shaders
in there, or any vertex stuff for that matter, but instead rely on draw. I'll
try Dave'd draw patches later and see if that fixes things.

-- 
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 1/2] util: use memset() to initialize surface, sampler_view templates

2012-01-10 Thread Brian Paul
These initialization functions weren't initializing all the fields so
some had undefined values.  The callers of these functions sometimes use
a structure assignment to initialize new objects from these templates
so we'd just propagate the undefined values.  That made for some confusing
info when debugging, plus it could lead to bugs.
---
 src/gallium/auxiliary/util/u_sampler.c |6 ++
 src/gallium/auxiliary/util/u_surface.c |   17 ++---
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_sampler.c 
b/src/gallium/auxiliary/util/u_sampler.c
index bb26099..227641b 100644
--- a/src/gallium/auxiliary/util/u_sampler.c
+++ b/src/gallium/auxiliary/util/u_sampler.c
@@ -30,12 +30,18 @@
 #include "u_sampler.h"
 
 
+/**
+ * Initialize a pipe_sampler_view.  'view' is considered to have
+ * uninitialized contents.
+ */
 static void
 default_template(struct pipe_sampler_view *view,
  const struct pipe_resource *texture,
  enum pipe_format format,
  unsigned expand_green_blue)
 {
+   memset(view, 0, sizeof(*view));
+
/* XXX: Check if format is compatible with texture->format.
 */
 
diff --git a/src/gallium/auxiliary/util/u_surface.c 
b/src/gallium/auxiliary/util/u_surface.c
index c7fbd36..6cbab65 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -42,17 +42,21 @@
 #include "util/u_surface.h"
 #include "util/u_pack_color.h"
 
+
+/**
+ * Initialize a pipe_surface object.  'view' is considered to have
+ * uninitialized contents.
+ */
 void
-u_surface_default_template(struct pipe_surface *view,
+u_surface_default_template(struct pipe_surface *surf,
const struct pipe_resource *texture,
unsigned bind)
 {
-   view->format = texture->format;
-   view->u.tex.level = 0;
-   view->u.tex.first_layer = 0;
-   view->u.tex.last_layer = 0;
+   memset(&surf, 0, sizeof(*surf));
+
+   surf->format = texture->format;
/* XXX should filter out all non-rt/ds bind flags ? */
-   view->usage = bind;
+   surf->usage = bind;
 }
 
 /**
@@ -108,7 +112,6 @@ util_create_rgba_surface(struct pipe_context *pipe,
   return FALSE;
 
/* create surface */
-   memset(&surf_templ, 0, sizeof(surf_templ));
u_surface_default_template(&surf_templ, *textureOut, bind);
/* create surface / view into texture */
*surfaceOut = pipe->create_surface(pipe,
-- 
1.7.3.4

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


[Mesa-dev] [PATCH 2/2] st/mesa: remove unnecessary memset()/zero call

2012-01-10 Thread Brian Paul
The u_surface_default_template() function does the memset()/zero now.
---
 src/mesa/state_tracker/st_manager.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index c0af3ce..b83cb23 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -222,7 +222,6 @@ st_framebuffer_validate(struct st_framebuffer *stfb,
  continue;
   }
 
-  memset(&surf_tmpl, 0, sizeof(surf_tmpl));
   u_surface_default_template(&surf_tmpl, textures[i],
  PIPE_BIND_RENDER_TARGET);
   ps = st->pipe->create_surface(st->pipe, textures[i], &surf_tmpl);
-- 
1.7.3.4

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


Re: [Mesa-dev] [PATCH 1/2] util: use memset() to initialize surface, sampler_view templates

2012-01-10 Thread Jakob Bornecrantz
- Original Message -
> These initialization functions weren't initializing all the fields so
> some had undefined values.  The callers of these functions sometimes
> use a structure assignment to initialize new objects from these
> templates so we'd just propagate the undefined values.  That made for
> some confusing info when debugging, plus it could lead to bugs.

Hmm, in theory doing "struct my_struct strct = { 0 };" should work but
as I noticed earlier at least gcc doesn't seem to do what we want in
this case.

Maybe we should try and standardize on one way to do struct
initialization in Gallium/Mesa?

struct my_struct strct = MY_STRUCT_STATIC_INIT;

Seems to be used by both pthreads and the kernel.

The change in of itself is good and have my RB, just wanted to take up
the discussion.

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


[Mesa-dev] [PATCH] util: use memset() to initialize surface, sampler_view templates

2012-01-10 Thread Brian Paul
These initialization functions weren't initializing all the fields so
some had undefined values.  The callers of these functions sometimes use
a structure assignment to initialize new objects from these templates
so we'd just propagate the undefined values.  That made for some confusing
info when debugging, plus it could lead to bugs.

v2: fix surf pointer mix-up: "&surf" -> "surf"
---
 src/gallium/auxiliary/util/u_sampler.c |6 ++
 src/gallium/auxiliary/util/u_surface.c |   17 ++---
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_sampler.c 
b/src/gallium/auxiliary/util/u_sampler.c
index bb26099..227641b 100644
--- a/src/gallium/auxiliary/util/u_sampler.c
+++ b/src/gallium/auxiliary/util/u_sampler.c
@@ -30,12 +30,18 @@
 #include "u_sampler.h"
 
 
+/**
+ * Initialize a pipe_sampler_view.  'view' is considered to have
+ * uninitialized contents.
+ */
 static void
 default_template(struct pipe_sampler_view *view,
  const struct pipe_resource *texture,
  enum pipe_format format,
  unsigned expand_green_blue)
 {
+   memset(view, 0, sizeof(*view));
+
/* XXX: Check if format is compatible with texture->format.
 */
 
diff --git a/src/gallium/auxiliary/util/u_surface.c 
b/src/gallium/auxiliary/util/u_surface.c
index c7fbd36..a541a38 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -42,17 +42,21 @@
 #include "util/u_surface.h"
 #include "util/u_pack_color.h"
 
+
+/**
+ * Initialize a pipe_surface object.  'view' is considered to have
+ * uninitialized contents.
+ */
 void
-u_surface_default_template(struct pipe_surface *view,
+u_surface_default_template(struct pipe_surface *surf,
const struct pipe_resource *texture,
unsigned bind)
 {
-   view->format = texture->format;
-   view->u.tex.level = 0;
-   view->u.tex.first_layer = 0;
-   view->u.tex.last_layer = 0;
+   memset(surf, 0, sizeof(*surf));
+
+   surf->format = texture->format;
/* XXX should filter out all non-rt/ds bind flags ? */
-   view->usage = bind;
+   surf->usage = bind;
 }
 
 /**
@@ -108,7 +112,6 @@ util_create_rgba_surface(struct pipe_context *pipe,
   return FALSE;
 
/* create surface */
-   memset(&surf_templ, 0, sizeof(surf_templ));
u_surface_default_template(&surf_templ, *textureOut, bind);
/* create surface / view into texture */
*surfaceOut = pipe->create_surface(pipe,
-- 
1.7.3.4

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


Re: [Mesa-dev] [PATCH 1/2] util: use memset() to initialize surface, sampler_view templates

2012-01-10 Thread Brian Paul

On 01/10/2012 11:48 AM, Jakob Bornecrantz wrote:

- Original Message -

These initialization functions weren't initializing all the fields so
some had undefined values.  The callers of these functions sometimes
use a structure assignment to initialize new objects from these
templates so we'd just propagate the undefined values.  That made for
some confusing info when debugging, plus it could lead to bugs.


Hmm, in theory doing "struct my_struct strct = { 0 };" should work but
as I noticed earlier at least gcc doesn't seem to do what we want in
this case.

Maybe we should try and standardize on one way to do struct
initialization in Gallium/Mesa?


Well, in this specific case, we're initializing the template object 
with a number of non-constant values coming from other objects.




struct my_struct strct = MY_STRUCT_STATIC_INIT;


There's probably some other places where that would make sense.



Seems to be used by both pthreads and the kernel.

The change in of itself is good and have my RB, just wanted to take up
the discussion.

Cheers, Jakob.


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


[Mesa-dev] [PATCH] i965/vs: Emit a MAC instead of a MUL+ADD combination when possible.

2012-01-10 Thread Eric Anholt
Fixes a regression in codegen quality from the old VS backend to the
new one, where matrix multiplies were more expensive in instruction
count.

shader-db results:
Total instructions: 58540 -> 55984
815/870 programs affected (93.7%)
57412 -> 54856 instructions in affected programs (4.5% reduction)
hurt programs:
shaders/gst-gl-mosaic-v.vert: 48.21%
shaders/gst-gl-cube-v.vert: 48.21%

Those two shaders are doing really silly things, and the core GLSL
compiler should really be optimizing those silly things away.
Instead, we now end up with MAC sequences involving 0.0 or 1.0, which
are trickier to optimize away than MUL+ADD sequences.
---
 src/mesa/drivers/dri/i965/brw_vec4.h   |4 ++
 .../drivers/dri/i965/brw_vec4_copy_propagation.cpp |1 +
 src/mesa/drivers/dri/i965/brw_vec4_emit.cpp|6 +++
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |   45 
 4 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 2555fa7..4922422 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -266,6 +266,7 @@ public:
 
bool saturate;
bool predicate_inverse;
+   bool update_accumulator;
uint32_t predicate;
 
int conditional_mod; /**< BRW_CONDITIONAL_* */
@@ -524,6 +525,9 @@ public:
int base_offset);
 
bool try_emit_sat(ir_expression *ir);
+   bool try_emit_mac(ir_expression *ir, int mul_op);
+
+
void resolve_ud_negate(src_reg *reg);
 
bool process_move_condition(ir_rvalue *ir);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
index 08d8f5b..1d1dd6f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
@@ -96,6 +96,7 @@ try_constant_propagation(vec4_instruction *inst, int arg, 
src_reg *values[4])
   return true;
 
case BRW_OPCODE_MUL:
+   case BRW_OPCODE_MAC:
case BRW_OPCODE_ADD:
   if (arg == 1) {
 inst->src[arg] = value;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
index a618614..af5069e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
@@ -831,6 +831,7 @@ vec4_visitor::generate_code()
   brw_set_predicate_control(p, inst->predicate);
   brw_set_predicate_inverse(p, inst->predicate_inverse);
   brw_set_saturate(p, inst->saturate);
+  brw_set_acc_write_control(p, inst->update_accumulator);
 
   switch (inst->opcode) {
   case BRW_OPCODE_MOV:
@@ -842,6 +843,11 @@ vec4_visitor::generate_code()
   case BRW_OPCODE_MUL:
 brw_MUL(p, dst, src[0], src[1]);
 break;
+
+  case BRW_OPCODE_MAC:
+brw_MAC(p, dst, src[0], src[1]);
+break;
+
   case BRW_OPCODE_MACH:
 brw_set_acc_write_control(p, 1);
 brw_MACH(p, dst, src[0], src[1]);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 5df2470..6d78ae9 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -156,6 +156,7 @@ ALU1(RNDE)
 ALU1(RNDZ)
 ALU2(ADD)
 ALU2(MUL)
+ALU2(MAC)
 ALU2(MACH)
 ALU2(AND)
 ALU2(OR)
@@ -998,6 +999,47 @@ vec4_visitor::visit(ir_function *ir)
 }
 
 bool
+vec4_visitor::try_emit_mac(ir_expression *ir, int mul_op)
+{
+   if (ir->operation != ir_binop_add || ir->type->base_type != GLSL_TYPE_FLOAT)
+  return false;
+
+   ir_expression *mul = ir->operands[mul_op]->as_expression();
+   if (!mul || mul->operation != ir_binop_mul)
+  return false;
+
+   ir_expression *nonmul = ir->operands[1 - mul_op]->as_expression();
+
+   /* We need an instruction to set update_accumulator on that we'll
+* MAC with, so just make sure it's one of the common expression
+* types used to generate a value we would want to accumulate with.
+*/
+   if (!nonmul || (nonmul->operation != ir_binop_add &&
+  nonmul->operation != ir_binop_mul)) {
+  return false;
+   }
+
+   /* Get the mul args before the nonmul, so that nonmul's
+* update_accumulator is the last thing before our MAC.
+*/
+   mul->operands[0]->accept(this);
+   src_reg mul_op0 = this->result;
+   mul->operands[1]->accept(this);
+   src_reg mul_op1 = this->result;
+
+   nonmul->accept(this);
+   vec4_instruction *last_nonmul_inst;
+   last_nonmul_inst = (vec4_instruction *)this->instructions.get_tail();
+   last_nonmul_inst->update_accumulator = true;
+   last_nonmul_inst->dst = dst_null_f();
+
+   this->result = src_reg(this, ir->type);
+   emit(MAC(dst_reg(this->result), mul_op0, mul_op1));
+
+   return true;
+}
+
+bool
 vec4_visitor::try_emit_sat(ir_expression *ir)
 {
ir_rvalue *sat_src = ir->as_rvalue_to_saturate();
@@ -1038,6 +1080,9 @@ vec4_visitor

Re: [Mesa-dev] [PATCH 2/3] mesa: add _mesa_unpack_ubyte_rgba_row() function

2012-01-10 Thread Eirik Byrkjeflot Anonsen
Brian Paul  writes:

> ---
>  src/mesa/main/format_unpack.c |  499 
> +
>  src/mesa/main/format_unpack.h |3 +
>  2 files changed, 502 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
> index c723e89..a7308a1 100644
> --- a/src/mesa/main/format_unpack.c
> +++ b/src/mesa/main/format_unpack.c
> @@ -29,6 +29,22 @@
>  #include "../../gallium/auxiliary/util/u_format_r11g11b10f.h"
>
>
> +
> +/* Expand 1, 2, 3, 4, 5, 6-bit values to fill 8 bits */
> +
> +#define EXPAND_1_8(X)  ( (X) ? 0xff : 0x0 )
> +
> +#define EXPAND_2_8(X)  ( ((X) << 6) | ((X) << 4) | ((X) << 2) | (X) )
> +
> +#define EXPAND_3_8(X)  ( ((X) << 5) | ((X) << 2) | ((X) > 1) )

I assume you meant ((X) >> 1) rather than ((X) > 1) here?

eirik

> +
> +#define EXPAND_4_8(X)  ( ((X) << 4) | (X) )
> +
> +#define EXPAND_5_8(X)  ( ((X) << 3) | ((X) >> 2) )
> +
> +#define EXPAND_6_8(X)  ( ((X) << 2) | ((X) >> 4) )
> +
[...]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] util: use memset() to initialize surface, sampler_view templates

2012-01-10 Thread Marek Olšák
On Tue, Jan 10, 2012 at 7:48 PM, Jakob Bornecrantz  wrote:
> - Original Message -
>> These initialization functions weren't initializing all the fields so
>> some had undefined values.  The callers of these functions sometimes
>> use a structure assignment to initialize new objects from these
>> templates so we'd just propagate the undefined values.  That made for
>> some confusing info when debugging, plus it could lead to bugs.
>
> Hmm, in theory doing "struct my_struct strct = { 0 };" should work but
> as I noticed earlier at least gcc doesn't seem to do what we want in
> this case.

Long ago I noticed that scons was throwing a warning that a variable
may have been uninitialized when using the empty initializer {}, but
it worked fine with make. It seems to be an issue with scons. I am not
a fan of memset. I prefer {} more, even though it may not be
C89-friendly.

Marek

>
> Maybe we should try and standardize on one way to do struct
> initialization in Gallium/Mesa?
>
> struct my_struct strct = MY_STRUCT_STATIC_INIT;
>
> Seems to be used by both pthreads and the kernel.
>
> The change in of itself is good and have my RB, just wanted to take up
> the discussion.
>
> Cheers, Jakob.
> ___
> 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


Re: [Mesa-dev] [PATCH] [rfc] mesa: don't allow GLSL 1.30 without GL3.

2012-01-10 Thread Eric Anholt
On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie  wrote:
> From: Dave Airlie 
> 
> Things can get confused if you expose one without the other which can happen
> if you are missing one or two of the extensions (like say float textures).

Can you clarify what "things can get confused" means?


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


Re: [Mesa-dev] [PATCH 2/3] mesa: add _mesa_unpack_ubyte_rgba_row() function

2012-01-10 Thread Brian Paul

On 01/10/2012 11:36 AM, Eirik Byrkjeflot Anonsen wrote:

Brian Paul  writes:


---
  src/mesa/main/format_unpack.c |  499 +
  src/mesa/main/format_unpack.h |3 +
  2 files changed, 502 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index c723e89..a7308a1 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -29,6 +29,22 @@
  #include "../../gallium/auxiliary/util/u_format_r11g11b10f.h"


+
+/* Expand 1, 2, 3, 4, 5, 6-bit values to fill 8 bits */
+
+#define EXPAND_1_8(X)  ( (X) ? 0xff : 0x0 )
+
+#define EXPAND_2_8(X)  ( ((X)<<  6) | ((X)<<  4) | ((X)<<  2) | (X) )
+
+#define EXPAND_3_8(X)  ( ((X)<<  5) | ((X)<<  2) | ((X)>  1) )


I assume you meant ((X)>>  1) rather than ((X)>  1) here?



Yes, thanks.  I'll fix that.

-Brian

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


Re: [Mesa-dev] [PATCH] mesa: fix cubemap depth completeness test

2012-01-10 Thread Eric Anholt
On Tue, 10 Jan 2012 16:14:05 +, Dave Airlie  wrote:
> From: Dave Airlie 
> 
> This fixes the test to allow cube/depth combinations on GL3
> or EXT_gpu_shader4.

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 0/3] i965/gen7: Enable HiZ

2012-01-10 Thread Eric Anholt
On Mon,  9 Jan 2012 14:30:55 -0800, Chad Versace  
wrote:
> Chad Versace (3):
>   i965: Fix misnamed GEN7_WM_DEPTH_RESOLVE
>   i965: Replace references to stencil region size with buffer size
>   i965/gen7: Enable HiZ

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH] [rfc] mesa: don't allow GLSL 1.30 without GL3.

2012-01-10 Thread Dave Airlie
On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt  wrote:
> On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> Things can get confused if you expose one without the other which can happen
>> if you are missing one or two of the extensions (like say float textures).
>
> Can you clarify what "things can get confused" means?

Well piglit starts to fail in wierd and wonderful way, I just don't
think we have any valid use cases for exposing GLSL1.30 without GL3
and I'd like to enforce that.

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


Re: [Mesa-dev] [PATCH 1/2] util: use memset() to initialize surface, sampler_view templates

2012-01-10 Thread Dave Airlie
On Tue, Jan 10, 2012 at 7:27 PM, Marek Olšák  wrote:
> On Tue, Jan 10, 2012 at 7:48 PM, Jakob Bornecrantz  wrote:
>> - Original Message -
>>> These initialization functions weren't initializing all the fields so
>>> some had undefined values.  The callers of these functions sometimes
>>> use a structure assignment to initialize new objects from these
>>> templates so we'd just propagate the undefined values.  That made for
>>> some confusing info when debugging, plus it could lead to bugs.
>>
>> Hmm, in theory doing "struct my_struct strct = { 0 };" should work but
>> as I noticed earlier at least gcc doesn't seem to do what we want in
>> this case.
>
> Long ago I noticed that scons was throwing a warning that a variable
> may have been uninitialized when using the empty initializer {}, but
> it worked fine with make. It seems to be an issue with scons. I am not
> a fan of memset. I prefer {} more, even though it may not be
> C89-friendly.

{0} isn't guaranteed to initialise padding in structs if memory serves.

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


Re: [Mesa-dev] [PATCH] [rfc] mesa: don't allow GLSL 1.30 without GL3.

2012-01-10 Thread Christoph Bumiller
On 01/10/2012 10:09 PM, Dave Airlie wrote:
> On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt  wrote:
>> On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie  wrote:
>>> From: Dave Airlie 
>>>
>>> Things can get confused if you expose one without the other which can happen
>>> if you are missing one or two of the extensions (like say float textures).
>>
>> Can you clarify what "things can get confused" means?
> 
> Well piglit starts to fail in wierd and wonderful way, I just don't
> think we have any valid use cases for exposing GLSL1.30 without GL3
> and I'd like to enforce that.
> 

Some tests only check for GLSL 1.3 and then use functions like
glUniform*ui that glew only sets up if GL_VERSION_3_0 and as a result
they call a NULL pointer.

> Dave.
> ___
> 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] [PATCH 1/3] xlib: call register_with_display() in Fake_glXChooseFBConfig()

2012-01-10 Thread Brian Paul
From: Brian Paul 

as we do in Fake_glXChooseVisual().  This registers the MesaGLX
extension on the display so we can clean up buffers, etc. when
the display connection is closed.

Fixes a bug reported by Wayne E. Robertz.

NOTE: This is a candidate for the 7.11 branch.
---
 src/mesa/drivers/x11/fakeglx.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 445d43b..916296d 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -1983,6 +1983,9 @@ Fake_glXChooseFBConfig( Display *dpy, int screen,
 {
XMesaVisual xmvis;
 
+   /* register ourselves as an extension on this display */
+   register_with_display(dpy);
+
if (!attribList || !attribList[0]) {
   /* return list of all configs (per GLX_SGIX_fbconfig spec) */
   return Fake_glXGetFBConfigs(dpy, screen, nitems);
-- 
1.7.1

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


[Mesa-dev] [PATCH 2/3] st/glx/xlib: call register_with_display() in Fake_glXChooseFBConfig()

2012-01-10 Thread Brian Paul
From: Brian Paul 

This is the same fix as the previous commit, except it's for the gallium
glx/xlib state tracker.

NOTE: This is a candidate for the 7.11 branch.
---
 src/gallium/state_trackers/glx/xlib/glx_api.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c 
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index b68882b..d034fb5 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -1788,6 +1788,9 @@ glXChooseFBConfig(Display *dpy, int screen,
 {
XMesaVisual xmvis;
 
+   /* register ourselves as an extension on this display */
+   register_with_display(dpy);
+
if (!attribList || !attribList[0]) {
   /* return list of all configs (per GLX_SGIX_fbconfig spec) */
   return glXGetFBConfigs(dpy, screen, nitems);
-- 
1.7.1

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


[Mesa-dev] [PATCH 3/3] xlib: use X error handler to catch XShmQueryVersion() failure

2012-01-10 Thread Brian Paul
From: Brian Paul 

This is a follow-on to the previous commits.  It seems that
XShmQueryVersion() can trigger an X error after the first X
connection is closed and we start using a new connection.

Fixes a bug found by Wayne E. Robertz.

NOTE: This is a candidate for the 7.11 branch.
---
 src/mesa/drivers/x11/xm_api.c |   28 +++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 81b2459..8c0e783 100644
--- a/src/mesa/drivers/x11/xm_api.c
+++ b/src/mesa/drivers/x11/xm_api.c
@@ -105,6 +105,19 @@ static int host_byte_order( void )
 }
 
 
+static GLboolean XShmErrorFlag;
+
+static int
+xshm_query_version_err_handler( XMesaDisplay* dpy, XErrorEvent* xerr )
+{
+   /* If this function gets called, it's because XShmQuerryVersion()
+* has failed.
+*/
+   XShmErrorFlag = True;
+   return 0;
+}
+
+
 /**
  * Check if the X Shared Memory extension is available.
  * Return:  0 = not available
@@ -118,7 +131,20 @@ static int check_for_xshm( XMesaDisplay *display )
Bool pixmaps;
 
if (XQueryExtension( display, "MIT-SHM", &ignore, &ignore, &ignore )) {
-  if (XShmQueryVersion( display, &major, &minor, &pixmaps )==True) {
+  int (*old_handler)(XMesaDisplay *, XErrorEvent *);
+  int ok;
+
+  /* Install X error handler before calling XShmQueryVersion() to catch
+   * a spurious X error.
+   */
+  XShmErrorFlag = False;
+  old_handler = XSetErrorHandler(xshm_query_version_err_handler);
+  ok = XShmQueryVersion( display, &major, &minor, &pixmaps );
+  XSetErrorHandler(old_handler);
+  if (XShmErrorFlag)
+ ok = False;
+
+  if (ok) {
 return (pixmaps==True) ? 2 : 1;
   }
   else {
-- 
1.7.1

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


Re: [Mesa-dev] [PATCH] vbo: introduce vbo_get_minmax_indices function

2012-01-10 Thread Yuanhan Liu
On Wed, Jan 04, 2012 at 07:23:24PM +0100, Roland Scheidegger wrote:
> Am 04.01.2012 04:59, schrieb Yuanhan Liu:
> > On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
> >> On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
> >>> Ah index scanning...
> >>> I don't like that this will map/unmap the ib once for each prim,
> >> Me either :)
> >>
> >>> though
> >>> I don't really see a nice way to avoid that (I think if you have to
> >>
> >> Well, I thought a while, we may do some combine to reduce some
> >> map/unmap.
> > 
> > Ok, here is the new patch, please help to review it.
> > 
> > And Brian, since it touches the mesa core, it would be nice if you'd
> > review it.

Hi Brian, any comments?

Thanks,
Yuanhan Liu

> Looks good to me.
> Reviewed-by: Roland Scheidegger 
> 

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


[Mesa-dev] [PATCH] st/dri: Remove useless flush front.

2012-01-10 Thread Stéphane Marchesin
In the following scenario:
- CreateContext C1
- MakeCurrent C1
- DestroyContext C1 (does not actually destroy the first context, postponed
  until the next MakeCurrent)
- CreateContext C2
- MakeCurrent C2

MakeCurrent will call flush on a context which might not even have had a front
buffer, leading to crashes. Since none of the dri drivers use the flush in
their unbind_context implementation either, we remove this useless flush front
call.

This fixes GPU crashes with Chrome and gallium drivers.
---
 .../state_trackers/dri/common/dri_context.c|1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_context.c 
b/src/gallium/state_trackers/dri/common/dri_context.c
index b47d8d9..226c630 100644
--- a/src/gallium/state_trackers/dri/common/dri_context.c
+++ b/src/gallium/state_trackers/dri/common/dri_context.c
@@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)
 
if (--ctx->bind_count == 0) {
   if (ctx->st == ctx->stapi->get_current(ctx->stapi)) {
- ctx->st->flush(ctx->st, ST_FLUSH_FRONT, NULL);
  stapi->make_current(stapi, NULL, NULL, NULL);
   }
}
-- 
1.7.5.3.367.ga9930

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


Re: [Mesa-dev] [PATCH] vbo: introduce vbo_get_minmax_indices function

2012-01-10 Thread Brian Paul
On Tue, Jan 3, 2012 at 8:59 PM, Yuanhan Liu  wrote:
> On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
>> On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
>> > Ah index scanning...
>> > I don't like that this will map/unmap the ib once for each prim,
>> Me either :)
>>
>> > though
>> > I don't really see a nice way to avoid that (I think if you have to
>>
>> Well, I thought a while, we may do some combine to reduce some
>> map/unmap.
>
> Ok, here is the new patch, please help to review it.
>
> And Brian, since it touches the mesa core, it would be nice if you'd
> review it.
>
> Thanks,
> Yuanhan Liu
>
>
> --
>
> From 7956b5c93bdfd0e94b6d3e25336c99cd7457f550 Mon Sep 17 00:00:00 2001
> From: Yuanhan Liu 
> Date: Sat, 31 Dec 2011 14:22:46 +0800
> Subject: [PATCH] vbo: introduce vbo_get_minmax_indices function
>
> Introduce vbo_get_minmax_indices() function to handle the min/max index
> computation for nr_prims(>= 1). The old code just compute the first
> prim's min/max index; this would results an error rendering if user
> called functions like glMultiDrawElements(). This patch servers as
> fixing this issue.
>
> As when nr_prims = 1, we can pass 1 to paramter nr_prims, thus I made
> vbo_get_minmax_index() static.
>
> v2: per Roland's suggestion, put the indices address compuation into
>    vbo_get_minmax_index() instead.
>
>    Also do comination if possible to reduce map/unmap count
>
> Signed-off-by: Yuanhan Liu 
> ---
>  src/mesa/drivers/dri/i965/brw_draw.c         |    2 +-
>  src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |    3 +-
>  src/mesa/main/api_validate.c                 |    2 +-
>  src/mesa/state_tracker/st_draw.c             |    3 +-
>  src/mesa/state_tracker/st_draw_feedback.c    |    2 +-
>  src/mesa/tnl/t_draw.c                        |    2 +-
>  src/mesa/vbo/vbo.h                           |    6 ++--
>  src/mesa/vbo/vbo_exec_array.c                |   49 +
>  8 files changed, 52 insertions(+), 17 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 621195d..f50fffd 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -586,7 +586,7 @@ void brw_draw_prims( struct gl_context *ctx,
>
>    if (!vbo_all_varyings_in_vbos(arrays)) {
>       if (!index_bounds_valid)
> -        vbo_get_minmax_index(ctx, prim, ib, &min_index, &max_index);
> +        vbo_get_minmax_indices(ctx, prim, ib, &min_index, &max_index, 
> nr_prims);
>
>       /* Decide if we want to rebase.  If so we end up recursing once
>        * only into this function.
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> index de04d18..59f1542 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> @@ -437,7 +437,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
>        struct nouveau_render_state *render = to_render_state(ctx);
>
>        if (!index_bounds_valid)
> -               vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> +               vbo_get_minmax_indices(ctx, prims, ib, &min_index, &max_index,
> +                                      nr_prims);
>
>        vbo_choose_render_mode(ctx, arrays);
>        vbo_choose_attrs(ctx, arrays);
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 945f127..b6871d0 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -184,7 +184,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei count, 
> GLenum type,
>    ib.ptr = indices;
>    ib.obj = ctx->Array.ArrayObj->ElementArrayBufferObj;
>
> -   vbo_get_minmax_index(ctx, &prim, &ib, &min, &max);
> +   vbo_get_minmax_indices(ctx, &prim, &ib, &min, &max, 1);
>
>    if ((int)(min + basevertex) < 0 ||
>        max + basevertex > ctx->Array.ArrayObj->_MaxElement) {
> diff --git a/src/mesa/state_tracker/st_draw.c 
> b/src/mesa/state_tracker/st_draw.c
> index 954f15a..6327a4c 100644
> --- a/src/mesa/state_tracker/st_draw.c
> +++ b/src/mesa/state_tracker/st_draw.c
> @@ -933,7 +933,8 @@ st_draw_vbo(struct gl_context *ctx,
>       /* Gallium probably doesn't want this in some cases. */
>       if (!index_bounds_valid)
>          if (!all_varyings_in_vbos(arrays))
> -            vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> +            vbo_get_minmax_indices(ctx, prims, ib, &min_index, &max_index,
> +                                   nr_prims);
>
>       for (i = 0; i < nr_prims; i++) {
>          num_instances = MAX2(num_instances, prims[i].num_instances);
> diff --git a/src/mesa/state_tracker/st_draw_feedback.c 
> b/src/mesa/state_tracker/st_draw_feedback.c
> index a99eb2b..f38f44c 100644
> --- a/src/mesa/state_tracker/st_draw_feedback.c
> +++ b/src/mesa/state_tracker/st_draw_feedback.c
> @@ -119,7 +119,7 @@ st_feedback_draw_vbo(struct gl_context *ctx,
>    st_validate_

Re: [Mesa-dev] [PATCH] mesa: fix situations where ffs or ffsl may not be defined

2012-01-10 Thread Brian Paul
On Mon, Jan 9, 2012 at 2:39 PM, Alexander von Gluck
 wrote:
>
> ---
>  src/mesa/main/imports.h |   16 
>  1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index b7e8743..522ffeb 100644
> --- a/src/mesa/main/imports.h
> +++ b/src/mesa/main/imports.h
> @@ -568,13 +568,19 @@ _mesa_init_sqrt_table(void);
>
>  #ifdef __GNUC__
>
> -#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID) ||
> defined(__APPLE__)
> +#if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
>  #define ffs __builtin_ffs
>  #define ffsll __builtin_ffsll
> +#define _mesa_ffs __builtin_ffs
> +#define _mesa_ffsll __builtin_ffsll
> +#else /* older GCC, no builtin */
> +#include 

string.h is already included via compiler.h above.


> +extern int
> +_mesa_ffs(int32_t i);
> +extern int
> +_mesa_ffsll(int64_t i);
>  #endif
>
> -#define _mesa_ffs(i)  ffs(i)
> -#define _mesa_ffsll(i)  ffsll(i)
>
>  #if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
>  #define _mesa_bitcount(i) __builtin_popcount(i)
> @@ -586,7 +592,9 @@ extern unsigned int
>  _mesa_bitcount_64(uint64_t n);
>  #endif
>
> -#else
> +#else /* non-GNUC */
> +#include 

Why include strings.h here?


> +
>  extern int
>  _mesa_ffs(int32_t i);
>
> --
> 1.7.7.2
>
> ___
> 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


Re: [Mesa-dev] [PATCH] mesa: fix situations where ffs or ffsl may not be defined

2012-01-10 Thread Alexander von Gluck

On 10.01.2012 21:53, Brian Paul wrote:

On Mon, Jan 9, 2012 at 2:39 PM, Alexander von Gluck
 wrote:


---
 src/mesa/main/imports.h |   16 
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index b7e8743..522ffeb 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -568,13 +568,19 @@ _mesa_init_sqrt_table(void);

 #ifdef __GNUC__

-#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID) ||
defined(__APPLE__)
+#if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
 #define ffs __builtin_ffs
 #define ffsll __builtin_ffsll
+#define _mesa_ffs __builtin_ffs
+#define _mesa_ffsll __builtin_ffsll
+#else /* older GCC, no builtin */
+#include 


string.h is already included via compiler.h above.


Good catch.  Reforming patch.


+extern int
+_mesa_ffs(int32_t i);
+extern int
+_mesa_ffsll(int64_t i);
 #endif

-#define _mesa_ffs(i)  ffs(i)
-#define _mesa_ffsll(i)  ffsll(i)

 #if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
 #define _mesa_bitcount(i) __builtin_popcount(i)
@@ -586,7 +592,9 @@ extern unsigned int
 _mesa_bitcount_64(uint64_t n);
 #endif

-#else
+#else /* non-GNUC */
+#include 


Why include strings.h here?


__mesa_ffs actually calls ffs if the OS is non-gnuc and not WIN32 or IBMC

This is because I was doing research on non-gnuc + ffs / ffsl and noticed
AIX and MacOS X have ffs / ffsl defined in strings.h vs string.h

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/ffsl.3.html

http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.basetechref/doc/basetrf1/bcopy.htm


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


[Mesa-dev] [PATCH] mesa: Make ffs/ffsl conditions match popcount ones.

2012-01-10 Thread Alexander von Gluck


- Ensure mesa code uses the _mesa_ffs(l) functions
  consistantly instead of jumping around between ffs
  and _mesa_ffs
- This makes ffs/ffsl behave more like the popcount code
- Better detects and handles edge cases of missing ffs/ffsl
- Use builtin ffs/ffsl more often as it may provide
  performance improvements
---
 src/mesa/drivers/dri/i915/i915_program.c|6 +++---
 src/mesa/drivers/dri/i965/brw_draw_upload.c |2 +-
 src/mesa/drivers/dri/i965/brw_vs_state.c|2 +-
 src/mesa/drivers/dri/i965/brw_wm_state.c|2 +-
 src/mesa/main/imports.c |3 ++-
 src/mesa/main/imports.h |   18 +++---
 6 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_program.c 
b/src/mesa/drivers/dri/i915/i915_program.c

index 0a600d3..0a544c7 100644
--- a/src/mesa/drivers/dri/i915/i915_program.c
+++ b/src/mesa/drivers/dri/i915/i915_program.c
@@ -75,7 +75,7 @@
 GLuint
 i915_get_temp(struct i915_fragment_program *p)
 {
-   int bit = ffs(~p->temp_flag);
+   int bit = _mesa_ffs(~p->temp_flag);
if (!bit) {
   fprintf(stderr, "%s: out of temporaries\n", __FILE__);
   exit(1);
@@ -89,7 +89,7 @@ i915_get_temp(struct i915_fragment_program *p)
 GLuint
 i915_get_utemp(struct i915_fragment_program * p)
 {
-   int bit = ffs(~p->utemp_flag);
+   int bit = _mesa_ffs(~p->utemp_flag);
if (!bit) {
   fprintf(stderr, "%s: out of temporaries\n", __FILE__);
   exit(1);
@@ -206,7 +206,7 @@ i915_emit_arith(struct i915_fragment_program * p,
 static GLuint get_free_rreg (struct i915_fragment_program *p,
  GLuint live_regs)
 {
-int bit = ffs(~live_regs);
+int bit = _mesa_ffs(~live_regs);
 if (!bit) {
 i915_program_error(p, "Can't find free R reg");
 return UREG_BAD;
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
b/src/mesa/drivers/dri/i965/brw_draw_upload.c

index 331f2a0..b4fd220 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -373,7 +373,7 @@ static void brw_prepare_vertices(struct brw_context 
*brw)

/* Accumulate the list of enabled arrays. */
brw->vb.nr_enabled = 0;
while (vs_inputs) {
-  GLuint i = ffsll(vs_inputs) - 1;
+  GLuint i = _mesa_ffsll(vs_inputs) - 1;
   struct brw_vertex_element *input = &brw->vb.inputs[i];

   vs_inputs &= ~BITFIELD64_BIT(i);
diff --git a/src/mesa/drivers/dri/i965/brw_vs_state.c 
b/src/mesa/drivers/dri/i965/brw_vs_state.c

index f572123..1283b73 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_state.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_state.c
@@ -77,7 +77,7 @@ brw_upload_vs_unit(struct brw_context *brw)
   vs->thread2.scratch_space_base_pointer =
 brw->vs.scratch_bo->offset >> 10; /* reloc */
   vs->thread2.per_thread_scratch_space =
-ffs(brw->vs.prog_data->total_scratch) - 11;
+_mesa_ffs(brw->vs.prog_data->total_scratch) - 11;
} else {
   vs->thread2.scratch_space_base_pointer = 0;
   vs->thread2.per_thread_scratch_space = 0;
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_state.c

index e1791c2..fca4d0c 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_state.c
@@ -119,7 +119,7 @@ brw_upload_wm_unit(struct brw_context *brw)
   wm->thread2.scratch_space_base_pointer =
 brw->wm.scratch_bo->offset >> 10; /* reloc */
   wm->thread2.per_thread_scratch_space =
-ffs(brw->wm.prog_data->total_scratch) - 11;
+_mesa_ffs(brw->wm.prog_data->total_scratch) - 11;
} else {
   wm->thread2.scratch_space_base_pointer = 0;
   wm->thread2.per_thread_scratch_space = 0;
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 2469e42..9e5f631 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -453,7 +453,8 @@ _mesa_inv_sqrtf(float n)
 #endif
 }

-#ifndef __GNUC__
+#if !defined(__GNUC__) ||\
+   ((__GNUC__ * 100 + __GNUC_MINOR__) < 304) /* Not gcc 3.4 or later */
 /**
  * Find the first bit set in a word.
  */
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index b7e8743..fab8b43 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -568,14 +568,16 @@ _mesa_init_sqrt_table(void);

 #ifdef __GNUC__

-#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID) || 
defined(__APPLE__)

-#define ffs __builtin_ffs
-#define ffsll __builtin_ffsll
+#if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
+#define _mesa_ffs __builtin_ffs
+#define _mesa_ffsll __builtin_ffsll
+#else /* older GCC, no builtin */
+extern int
+_mesa_ffs(int32_t i);
+extern int
+_mesa_ffsll(int64_t i);
 #endif

-#define _mesa_ffs(i)  ffs(i)
-#define _mesa_ffsll(i)  ffsll(i)
-
 #if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
 #define _mesa_bitcount(i) __builtin_popcount(i)
 #define _mesa_bitcount_64(i) __buil

[Mesa-dev] [PATCH] glx/dri2: fix use of uninitialized variable "api"

2012-01-10 Thread Vadim Girlin
Signed-off-by: Vadim Girlin 
---

Fixes unigine heaven startup problem for me.

 src/glx/dri2_glx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 10b6f52..b4efa40 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -240,7 +240,7 @@ dri2_create_context_attribs(struct glx_screen *base,
uint32_t minor_ver = 1;
uint32_t major_ver = 2;
uint32_t flags = 0;
-   unsigned api;
+   unsigned api = __DRI_API_OPENGL;
uint32_t ctx_attribs[2 * 4];
unsigned num_ctx_attribs = 0;
 
-- 
1.7.7.5

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


[Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-10 Thread Matt Turner
Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
easier while still specifically requiring bison and flex.

Based on bison.m4 and flex.m4 found in LLVM's tree.

Signed-off-by: Matt Turner 
---
 configure.ac |9 -
 m4/bison.m4  |   16 
 m4/flex.m4   |   16 
 3 files changed, 36 insertions(+), 5 deletions(-)
 create mode 100644 m4/bison.m4
 create mode 100644 m4/flex.m4

diff --git a/configure.ac b/configure.ac
index 511d147..c0abeb9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -45,11 +45,10 @@ if test "x$MKDEP" = "x"; then
 AC_MSG_ERROR([makedepend is required to build Mesa])
 fi
 
-AC_PATH_PROG([FLEX], [flex])
-test "x$FLEX" = "x" && AC_MSG_ERROR([flex is needed to build Mesa])
-
-AC_PATH_PROG([BISON], [bison])
-test "x$BISON" = "x" && AC_MSG_ERROR([bison is needed to build Mesa])
+m4_include([m4/bison.m4])
+AC_PROG_BISON
+m4_include([m4/flex.m4])
+AC_PROG_FLEX
 
 dnl Our fallback install-sh is a symlink to minstall. Use the existing
 dnl configuration in that case.
diff --git a/m4/bison.m4 b/m4/bison.m4
new file mode 100644
index 000..641d438
--- /dev/null
+++ b/m4/bison.m4
@@ -0,0 +1,16 @@
+#
+# Check for Bison.
+#
+# This macro verifies that Bison is installed.  If successful, then
+# 1) YACC is set to bison -y (to emulate YACC calls)
+# 2) BISON is set to bison
+#
+AC_DEFUN([AC_PROG_BISON],
+[AC_PROG_YACC()
+if test "$YACC" != "bison -y"; then
+  AC_SUBST(BISON,[])
+  AC_MSG_WARN([bison not found])
+else
+  AC_SUBST(BISON,[bison])
+fi
+])
diff --git a/m4/flex.m4 b/m4/flex.m4
new file mode 100644
index 000..6a2a004
--- /dev/null
+++ b/m4/flex.m4
@@ -0,0 +1,16 @@
+#
+# Check for FLEX.
+#
+# This macro verifies that flex is installed.  If successful, then
+# 1) LEX is set to flex (to emulate lex calls)
+# 2) FLEX is set to flex
+#
+AC_DEFUN([AC_PROG_FLEX],
+[AC_PROG_LEX()
+if test "$LEX" != "flex"; then
+  AC_SUBST(FLEX,[])
+  AC_MSG_ERROR([flex not found])
+else
+  AC_SUBST(FLEX,[flex])
+fi
+])
-- 
1.7.3.4

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


[Mesa-dev] [PATCH] configure.ac: use AC_PROG_SED

2012-01-10 Thread Matt Turner
AC_PROG_PATH was used in the original configure.ac (dca1b796b) and I
can't see any reason AC_PROG_SED wasn't used.

Signed-off-by: Matt Turner 
---
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index c0abeb9..08a0209 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,8 +38,8 @@ AC_PROG_CC
 AC_PROG_CXX
 AC_CHECK_PROGS([MAKE], [gmake make])
 AC_CHECK_PROGS([PYTHON2], [python2 python])
+AC_PROG_SED
 AC_PATH_PROG([MKDEP], [makedepend])
-AC_PATH_PROG([SED], [sed])
 
 if test "x$MKDEP" = "x"; then
 AC_MSG_ERROR([makedepend is required to build Mesa])
-- 
1.7.3.4

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


[Mesa-dev] [PATCH] configure.ac: don't set HAVE_GTEST twice

2012-01-10 Thread Matt Turner
Signed-off-by: Matt Turner 
---
 configure.ac |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 08a0209..d36901b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,7 +69,6 @@ AC_PATH_PROG([GTESTCONFIG], [gtest-config])
 if test "x$GTESTCONFIG" != "x"; then
 GTEST_CFLAGS=`gtest-config --cppflags --cxxflags`
 GTEST_LIBS=`gtest-config --ldflags --libs`
-HAVE_GTEST=1
 AC_SUBST([GTEST_CFLAGS])
 AC_SUBST([GTEST_LIBS])
 HAVE_GTEST=yes
-- 
1.7.3.4

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


[Mesa-dev] Getting patches applied

2012-01-10 Thread Kurt Roeckx
Hi,

I've send a few patches to the bug tracker, but get no reaction to
them.  They're very simple and fix problems found by piglit on
i830/i915.  I wonder why they don't get applied.  Should I send
them to the list instead?

Anyway, you can find them here:
https://bugs.freedesktop.org/show_bug.cgi?id=41372
https://bugs.freedesktop.org/show_bug.cgi?id=43250
https://bugs.freedesktop.org/show_bug.cgi?id=41495


Kurt

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


Re: [Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-10 Thread Matt Turner
On Wed, Jan 11, 2012 at 1:16 AM, Matt Turner  wrote:
> Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
> easier while still specifically requiring bison and flex.
>
> Based on bison.m4 and flex.m4 found in LLVM's tree.
>
> Signed-off-by: Matt Turner 
> ---
>  configure.ac |    9 -
>  m4/bison.m4  |   16 
>  m4/flex.m4   |   16 
>  3 files changed, 36 insertions(+), 5 deletions(-)
>  create mode 100644 m4/bison.m4
>  create mode 100644 m4/flex.m4
>
> diff --git a/configure.ac b/configure.ac
> index 511d147..c0abeb9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -45,11 +45,10 @@ if test "x$MKDEP" = "x"; then
>     AC_MSG_ERROR([makedepend is required to build Mesa])
>  fi
>
> -AC_PATH_PROG([FLEX], [flex])
> -test "x$FLEX" = "x" && AC_MSG_ERROR([flex is needed to build Mesa])
> -
> -AC_PATH_PROG([BISON], [bison])
> -test "x$BISON" = "x" && AC_MSG_ERROR([bison is needed to build Mesa])
> +m4_include([m4/bison.m4])
> +AC_PROG_BISON
> +m4_include([m4/flex.m4])
> +AC_PROG_FLEX
>
>  dnl Our fallback install-sh is a symlink to minstall. Use the existing
>  dnl configuration in that case.
> diff --git a/m4/bison.m4 b/m4/bison.m4
> new file mode 100644
> index 000..641d438
> --- /dev/null
> +++ b/m4/bison.m4
> @@ -0,0 +1,16 @@
> +#
> +# Check for Bison.
> +#
> +# This macro verifies that Bison is installed.  If successful, then
> +# 1) YACC is set to bison -y (to emulate YACC calls)
> +# 2) BISON is set to bison
> +#
> +AC_DEFUN([AC_PROG_BISON],
> +[AC_PROG_YACC()
> +if test "$YACC" != "bison -y"; then
> +  AC_SUBST(BISON,[])
> +  AC_MSG_WARN([bison not found])

This should be AC_MSG_ERROR.

> +else
> +  AC_SUBST(BISON,[bison])
> +fi
> +])
> diff --git a/m4/flex.m4 b/m4/flex.m4
> new file mode 100644
> index 000..6a2a004
> --- /dev/null
> +++ b/m4/flex.m4
> @@ -0,0 +1,16 @@
> +#
> +# Check for FLEX.
> +#
> +# This macro verifies that flex is installed.  If successful, then
> +# 1) LEX is set to flex (to emulate lex calls)
> +# 2) FLEX is set to flex
> +#
> +AC_DEFUN([AC_PROG_FLEX],
> +[AC_PROG_LEX()
> +if test "$LEX" != "flex"; then
> +  AC_SUBST(FLEX,[])
> +  AC_MSG_ERROR([flex not found])
> +else
> +  AC_SUBST(FLEX,[flex])
> +fi
> +])
> --
> 1.7.3.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Getting patches applied

2012-01-10 Thread Kenneth Graunke

On 01/10/2012 10:16 PM, Kurt Roeckx wrote:

Hi,

I've send a few patches to the bug tracker, but get no reaction to
them.  They're very simple and fix problems found by piglit on
i830/i915.  I wonder why they don't get applied.  Should I send
them to the list instead?


Ah!  This is the first time I've seen those patches...sorry.  It looks 
like those bugs were just assigned to Ian, and being the default 
bug-assignee, he gets a -lot- of bugzilla mail.  Easy to lose things in 
there.


It would be great if you could send them to the list for review.  It's 
harder to lose patches in there, and a lot more people will see them. 
Hopefully we can get them committed this week.



Anyway, you can find them here:
https://bugs.freedesktop.org/show_bug.cgi?id=41372


This one looks sensible to me.  You can add a:
Reviewed-by: Kenneth Graunke 


https://bugs.freedesktop.org/show_bug.cgi?id=43250


Likewise, this one seems sensible.  It also gets a:
Reviewed-by: Kenneth Graunke 


https://bugs.freedesktop.org/show_bug.cgi?id=41495


I'm going to defer to Eric's opinion on this one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-10 Thread Kenneth Graunke

On 01/10/2012 10:16 PM, Matt Turner wrote:

Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
easier while still specifically requiring bison and flex.

Based on bison.m4 and flex.m4 found in LLVM's tree.

Signed-off-by: Matt Turner
---
  configure.ac |9 -
  m4/bison.m4  |   16 
  m4/flex.m4   |   16 
  3 files changed, 36 insertions(+), 5 deletions(-)
  create mode 100644 m4/bison.m4
  create mode 100644 m4/flex.m4

diff --git a/configure.ac b/configure.ac
index 511d147..c0abeb9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -45,11 +45,10 @@ if test "x$MKDEP" = "x"; then
  AC_MSG_ERROR([makedepend is required to build Mesa])
  fi

-AC_PATH_PROG([FLEX], [flex])
-test "x$FLEX" = "x"&&  AC_MSG_ERROR([flex is needed to build Mesa])
-
-AC_PATH_PROG([BISON], [bison])
-test "x$BISON" = "x"&&  AC_MSG_ERROR([bison is needed to build Mesa])
+m4_include([m4/bison.m4])
+AC_PROG_BISON
+m4_include([m4/flex.m4])
+AC_PROG_FLEX

  dnl Our fallback install-sh is a symlink to minstall. Use the existing
  dnl configuration in that case.
diff --git a/m4/bison.m4 b/m4/bison.m4
new file mode 100644
index 000..641d438
--- /dev/null
+++ b/m4/bison.m4
@@ -0,0 +1,16 @@
+#
+# Check for Bison.
+#
+# This macro verifies that Bison is installed.  If successful, then
+# 1) YACC is set to bison -y (to emulate YACC calls)


I don't think we want to emulate POSIX yacc.  We're not using -y today, 
and I expect it'd only break things...



+# 2) BISON is set to bison
+#
+AC_DEFUN([AC_PROG_BISON],
+[AC_PROG_YACC()
+if test "$YACC" != "bison -y"; then
+  AC_SUBST(BISON,[])
+  AC_MSG_WARN([bison not found])
+else
+  AC_SUBST(BISON,[bison])
+fi
+])
diff --git a/m4/flex.m4 b/m4/flex.m4
new file mode 100644
index 000..6a2a004
--- /dev/null
+++ b/m4/flex.m4
@@ -0,0 +1,16 @@
+#
+# Check for FLEX.
+#
+# This macro verifies that flex is installed.  If successful, then
+# 1) LEX is set to flex (to emulate lex calls)
+# 2) FLEX is set to flex
+#
+AC_DEFUN([AC_PROG_FLEX],
+[AC_PROG_LEX()
+if test "$LEX" != "flex"; then
+  AC_SUBST(FLEX,[])
+  AC_MSG_ERROR([flex not found])
+else
+  AC_SUBST(FLEX,[flex])
+fi
+])


I like the idea of AC_PROG_FLEX and AC_PROG_BISON macros, but I don't 
care for this implementation.  I would expect them to perform some kind 
of feature check, or ask the program whether it's flex/bison.  This just 
matches on the name, so if I had flex installed only as "lex", or bison 
installed as "bison25" or such, this would break.


Maybe this is okay, but at least in my mind, only allowing one name 
seems to kind of defeat the point of a configure check.  Not entirely, 
but still.

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


Re: [Mesa-dev] [PATCH] configure.ac: use AC_PROG_SED

2012-01-10 Thread Kenneth Graunke

On 01/10/2012 10:16 PM, Matt Turner wrote:

AC_PROG_PATH was used in the original configure.ac (dca1b796b) and I
can't see any reason AC_PROG_SED wasn't used.


It looks like AC_PROG_SED was added in 2.59b, and wasn't in the original 
2.59.  Presumably that's why, though it could've been an oversight.


At any rate, I see no reason not to use it now.

Reviewed-by: Kenneth Graunke 


Signed-off-by: Matt Turner
---
  configure.ac |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index c0abeb9..08a0209 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,8 +38,8 @@ AC_PROG_CC
  AC_PROG_CXX
  AC_CHECK_PROGS([MAKE], [gmake make])
  AC_CHECK_PROGS([PYTHON2], [python2 python])
+AC_PROG_SED
  AC_PATH_PROG([MKDEP], [makedepend])
-AC_PATH_PROG([SED], [sed])

  if test "x$MKDEP" = "x"; then
  AC_MSG_ERROR([makedepend is required to build Mesa])

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


Re: [Mesa-dev] [PATCH] glx/dri2: fix use of uninitialized variable "api"

2012-01-10 Thread Stéphane Marchesin
What about initializing "api" earlier in dri2_convert_glx_attribs
instead? i.e. before the first return. That should fix it also and is
cleaner.

Stéphane


On Tue, Jan 10, 2012 at 21:32, Vadim Girlin  wrote:
> Signed-off-by: Vadim Girlin 
> ---
>
> Fixes unigine heaven startup problem for me.
>
>  src/glx/dri2_glx.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
> index 10b6f52..b4efa40 100644
> --- a/src/glx/dri2_glx.c
> +++ b/src/glx/dri2_glx.c
> @@ -240,7 +240,7 @@ dri2_create_context_attribs(struct glx_screen *base,
>    uint32_t minor_ver = 1;
>    uint32_t major_ver = 2;
>    uint32_t flags = 0;
> -   unsigned api;
> +   unsigned api = __DRI_API_OPENGL;
>    uint32_t ctx_attribs[2 * 4];
>    unsigned num_ctx_attribs = 0;
>
> --
> 1.7.7.5
>
> ___
> 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


Re: [Mesa-dev] [PATCH] glx/dri2: fix use of uninitialized variable "api"

2012-01-10 Thread Kenneth Graunke

On 01/10/2012 09:32 PM, Vadim Girlin wrote:

Signed-off-by: Vadim Girlin
---

Fixes unigine heaven startup problem for me.

  src/glx/dri2_glx.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 10b6f52..b4efa40 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -240,7 +240,7 @@ dri2_create_context_attribs(struct glx_screen *base,
 uint32_t minor_ver = 1;
 uint32_t major_ver = 2;
 uint32_t flags = 0;
-   unsigned api;
+   unsigned api = __DRI_API_OPENGL;
 uint32_t ctx_attribs[2 * 4];
 unsigned num_ctx_attribs = 0;


Ah, I see the problem now:

We pass &api to dri2_convert_glx_attribs, which is supposed to fill it 
in unless it returns false (failure).  However, in the case where 
num_attribs == 0, it does this:


   if (num_attribs == 0)
  return true;

...without setting *api.  I think it would be better to fix the bug in 
dri2_convert_glx_attribs() by changing that to


   if (num_attribs == 0) {
  *api = __DRI_API_OPENGL;
  return true;
   }

rather than working around the broken function here in the caller. 
Notably, drisw_create_context_attribs suffers from the exact same bug; 
fixing it in dri2_convert_glx_attribs would fix both.


Unfortunately, Heaven still gives me bizarre X errors, even with this 
patch.  I'll have to investigate further.

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


[Mesa-dev] [PATCH] glx/dri: Initialize api even if num_attribs == 0.

2012-01-10 Thread Kenneth Graunke
Both dri2_create_context_attribs and drisw_create_context_attribs call
dri2_convert_glx_attribs, expecting it to fill in *api on success.

However, when num_attribs == 0, it was returning true without setting
*api, causing the caller to use an uninitialized value.

Cc: Vadim Girlin 
Signed-off-by: Kenneth Graunke 
---
 src/glx/dri_common.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

Vadim, hopefully this should also fix Unigine Heaven for you.

diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 8feb587..ed0b134 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -429,8 +429,10 @@ dri2_convert_glx_attribs(unsigned num_attribs, const 
uint32_t *attribs,
uint32_t profile;
int render_type = GLX_RGBA_TYPE;
 
-   if (num_attribs == 0)
+   if (num_attribs == 0) {
+  *api = __DRI_API_OPENGL;
   return true;
+   }
 
/* This is actually an internal error, but what the heck.
 */
-- 
1.7.7.5

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


Re: [Mesa-dev] [PATCH] glx/dri: Initialize api even if num_attribs == 0.

2012-01-10 Thread Vadim Girlin
On Tue, 2012-01-10 at 23:36 -0800, Kenneth Graunke wrote:
> Both dri2_create_context_attribs and drisw_create_context_attribs call
> dri2_convert_glx_attribs, expecting it to fill in *api on success.
> 
> However, when num_attribs == 0, it was returning true without setting
> *api, causing the caller to use an uninitialized value.
> 
> Cc: Vadim Girlin 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/glx/dri_common.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> Vadim, hopefully this should also fix Unigine Heaven for you.

Yes, this patch works too, thanks.

By the way, to run Heaven I had to build the xserver with the patches
from xorg-devel:
http://lists.x.org/archives/xorg-devel/2011-December/028091.html

I'm not sure if there is another way.

Vadim

> 
> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
> index 8feb587..ed0b134 100644
> --- a/src/glx/dri_common.c
> +++ b/src/glx/dri_common.c
> @@ -429,8 +429,10 @@ dri2_convert_glx_attribs(unsigned num_attribs, const 
> uint32_t *attribs,
> uint32_t profile;
> int render_type = GLX_RGBA_TYPE;
>  
> -   if (num_attribs == 0)
> +   if (num_attribs == 0) {
> +  *api = __DRI_API_OPENGL;
>return true;
> +   }
>  
> /* This is actually an internal error, but what the heck.
>  */



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


Re: [Mesa-dev] [PATCH] glx/dri: Initialize api even if num_attribs == 0.

2012-01-10 Thread Kenneth Graunke

On 01/10/2012 11:47 PM, Vadim Girlin wrote:

On Tue, 2012-01-10 at 23:36 -0800, Kenneth Graunke wrote:

Both dri2_create_context_attribs and drisw_create_context_attribs call
dri2_convert_glx_attribs, expecting it to fill in *api on success.

However, when num_attribs == 0, it was returning true without setting
*api, causing the caller to use an uninitialized value.

Cc: Vadim Girlin
Signed-off-by: Kenneth Graunke
---
  src/glx/dri_common.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

Vadim, hopefully this should also fix Unigine Heaven for you.


Yes, this patch works too, thanks.

By the way, to run Heaven I had to build the xserver with the patches
from xorg-devel:
http://lists.x.org/archives/xorg-devel/2011-December/028091.html

I'm not sure if there is another way.

Vadim


Ah!  Of course.  I completely forgot that we needed X server patches. 
Thanks for solving that mystery.

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