[Mesa-dev] [PATCH] mesa: make sure all lighting tables are updated before the computation

Make sure all lighting tables are updated before using the table to calculate something, say using _SpotExpTable to calculate _VP_inf_spot_attenuation. Signed-off-by: Yuanhan Liu --- src/mesa/main/light.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/li

Re: [Mesa-dev] 7.11.1 release, and picking NormalMatrix fix

> -Original Message- > From: mesa-dev-bounces+gordon.jin=intel@lists.freedesktop.org > [mailto:mesa-dev-bounces+gordon.jin=intel@lists.freedesktop.org] On > Behalf Of Ian Romanick > Sent: Saturday, November 12, 2011 5:54 AM > To: tfo...@sci.utah.edu > Cc: mesa-dev@lists.freedesktop.

[Mesa-dev] [PATCH] mesa: do not skip att and spot calculation for infinite light

glspec doesn't say that we should skip the attenuation and spot calculation for infinite light(Ppli.w == 0). Instead, it gives a same formula to do the light calculation for both finite light and infinite light(see page 62 of glspec 2.1.pdf) Also from the formula (2.4) at page 62 of glspec 2.1.pdf

Re: [Mesa-dev] [PATCH 2/3] i965: Remove unused gen6+ code from brw_gs_emit.c.

On 11/14/2011 05:31 PM, Kenneth Graunke wrote: > This code is for decomposing certain primitive types pre-Gen6; the VF > already does that on Gen6. So, this code isn't good for anything. > > Plus, we'll want to use actual Gen6 geometry shader programs soon, so we > may as well just delete this re

Re: [Mesa-dev] [PATCH] mesa: Only update sampler uniforms that are used by the shader stage

On 11/14/2011 11:25 AM, Ian Romanick wrote: > From: Ian Romanick > > Previously a vertex shader that used no samplers would get updated (by > calling the driver's ProgramStringNotify) when a sampler in the > fragment shader was updated. This was discovered while investigating > some spurious cod

[Mesa-dev] [Bug 42930] [r300g, bisected] EVE online only shows black screen

https://bugs.freedesktop.org/show_bug.cgi?id=42930 Ian Romanick changed: What|Removed |Added Keywords||NEEDINFO --- Comment #1 from Ian Romanick

[Mesa-dev] [PATCH 3/3] i965: Remove a few unused fields from struct brw_vs_compile.

We'll be able to kill more of these once the old VS backend is gone. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_vs.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) I could also kill r0 by changing brw_vs_emit to just use brw_vec8_grf(0,0) like everybody else,

[Mesa-dev] [PATCH 2/3] i965: Remove unused gen6+ code from brw_gs_emit.c.

This code is for decomposing certain primitive types pre-Gen6; the VF already does that on Gen6. So, this code isn't good for anything. Plus, we'll want to use actual Gen6 geometry shader programs soon, so we may as well just delete this red herring. Signed-off-by: Kenneth Graunke --- src/mesa

[Mesa-dev] [PATCH 1/3] i965: Fix inconsistent indentation in brw_gs_emit.c.

--- src/mesa/drivers/dri/i965/brw_gs_emit.c | 66 +++--- 1 files changed, 33 insertions(+), 33 deletions(-) Some of these were 3/4 spacing (first level 3, second 4), and others were 8+3 (first tab, 3 spaces after that). Confused my editor quite a bit. diff --git a/src/

[Mesa-dev] [PATCH] glsl: Add missing textureSize(samplerCubeShadow, int) variant.

Signed-off-by: Kenneth Graunke --- src/glsl/builtins/tools/texture_builtins.py |1 + 1 files changed, 1 insertions(+), 0 deletions(-) I really don't know how I keep missing these. :( diff --git a/src/glsl/builtins/tools/texture_builtins.py b/src/glsl/builtins/tools/texture_builtins.py inde

Re: [Mesa-dev] [PATCH 1/3] glsl: Add a new matching_signature() variant that returns exact/inexact.

On 11/14/2011 10:20 AM, Paul Berry wrote: > On 11 November 2011 02:56, Kenneth Graunke > wrote: > > When matching function signatures across multiple linked shaders, we > often want to see if the current shader has _any_ match, but also know > whether or

Re: [Mesa-dev] [PATCH 2/2] xlib: set alpha to 0xff when mapping RGB pixmaps

On Mon, 14 Nov 2011 09:29:48 -0700, Brian Paul wrote: > On 11/14/2011 09:25 AM, Eric Anholt wrote: > > On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paul wrote: > >> On 11/11/2011 09:34 AM, Eric Anholt wrote: > >>> On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paul wrote: > Fixes a bunch of confor

Re: [Mesa-dev] [PATCH 5/6] intel: Fix swrast_render_start() for depthstencil buffers with separate stencil

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2011 02:05 PM, Eric Anholt wrote: > On Sun, 13 Nov 2011 22:32:14 -0800, Chad Versace > wrote: >> This patch fixes three interrelated bugs. >> >> Fixes many depthstencil Piglit tests on gen7, too many to list. >> >> 1. Don't map the depthsten

Re: [Mesa-dev] [PATCH 4/6] intel: Fix intel_map_renderbuffer() for depthstencil buffers with separate stencil

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2011 01:55 PM, Eric Anholt wrote: > On Sun, 13 Nov 2011 22:32:13 -0800, Chad Versace > wrote: >> For a depthstencil buffer with separate stencil, >> intel_renderbuffer::region is null. (The regions are kept in hidden depth >> and stencil buf

Re: [Mesa-dev] [PATCH 5/6] intel: Fix swrast_render_start() for depthstencil buffers with separate stencil

On Sun, 13 Nov 2011 22:32:14 -0800, Chad Versace wrote: > This patch fixes three interrelated bugs. > > Fixes many depthstencil Piglit tests on gen7, too many to list. > > 1. Don't map the depthstencil buffer twice > -- > Place a guard in intel_renderbuff

Re: [Mesa-dev] [PATCH] softpipe: fix clamping when using unormalized coordinates

On 11/14/2011 6:40 PM, Brian Paul wrote: > On 11/14/2011 10:24 AM, Morgan Armand wrote: >> On 11/14/2011 3:44 PM, Brian Paul wrote: >>> On 11/13/2011 03:24 AM, Morgan Armand wrote: --- src/gallium/drivers/softpipe/sp_tex_sample.c |7 --- 1 files changed, 4 insertions(+),

Re: [Mesa-dev] [PATCH 4/6] intel: Fix intel_map_renderbuffer() for depthstencil buffers with separate stencil

On Sun, 13 Nov 2011 22:32:13 -0800, Chad Versace wrote: > For a depthstencil buffer with separate stencil, > intel_renderbuffer::region is null. (The regions are kept in hidden depth > and stencil buffers). Since the region is null, intel_map_renderbuffer() > assumed there was no data and returne

Re: [Mesa-dev] TGSI declarations missing type info

On 11/14/2011 10:36 PM, Christoph Bumiller wrote: > On 11/14/2011 10:13 PM, Jose Fonseca wrote: >> >> >> My other reply was about this particular case. >> >> But I'm not convinced we can ignore this case at all. I'm fine with drivers >> cutting corners. By I can't accept an interface that's b

Re: [Mesa-dev] TGSI declarations missing type info

On 11/14/2011 10:13 PM, Jose Fonseca wrote: > > > - Original Message - >> On 11/14/2011 09:48 PM, Christoph Bumiller wrote: >>> On 11/14/2011 09:24 PM, Jose Fonseca wrote: - Original Message - > On 11/14/2011 08:23 PM, Jose Fonseca wrote: >> >> >> --

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > On 11/14/2011 09:48 PM, Christoph Bumiller wrote: > > On 11/14/2011 09:24 PM, Jose Fonseca wrote: > >> > >> > >> - Original Message - > >>> On 11/14/2011 08:23 PM, Jose Fonseca wrote: > > > - Original Message - > > The next open qu

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > On 11/14/2011 09:24 PM, Jose Fonseca wrote: > > > > > > - Original Message - > >> On 11/14/2011 08:23 PM, Jose Fonseca wrote: > >>> > >>> > >>> - Original Message - > The next open question I have is whether this warrants additions > to >

Re: [Mesa-dev] TGSI declarations missing type info

On 11/14/2011 09:48 PM, Christoph Bumiller wrote: > On 11/14/2011 09:24 PM, Jose Fonseca wrote: >> >> >> - Original Message - >>> On 11/14/2011 08:23 PM, Jose Fonseca wrote: - Original Message - > The next open question I have is whether this warrants additions >>

Re: [Mesa-dev] TGSI declarations missing type info

On 11/14/2011 09:24 PM, Jose Fonseca wrote: > > > - Original Message - >> On 11/14/2011 08:23 PM, Jose Fonseca wrote: >>> >>> >>> - Original Message - The next open question I have is whether this warrants additions to the tgsi_opcode_info struct, mainly whether the

[Mesa-dev] [Bug 42930] [r300g, bisected] EVE online only shows black screen

https://bugs.freedesktop.org/show_bug.cgi?id=42930 Pavel Ondračka changed: What|Removed |Added Blocks||42514 URL|

[Mesa-dev] [Bug 42930] New: [r300g, bisected] EVE online only shows black screen

https://bugs.freedesktop.org/show_bug.cgi?id=42930 Bug #: 42930 Summary: [r300g, bisected] EVE online only shows black screen Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Stat

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > On 11/14/2011 08:23 PM, Jose Fonseca wrote: > > > > > > - Original Message - > >> The next open question I have is whether this warrants additions > >> to > >> the tgsi_opcode_info struct, mainly whether the return value is > >> uint/int/float, > >> and wh

Re: [Mesa-dev] [PATCH 7/7] st/mesa: remove st_cb_readpixels.[ch]

On 11/14/2011 01:20 PM, Brian Paul wrote: On 11/12/2011 01:25 PM, Brian Paul wrote: We now use the core Mesa code for glReadPixels. I found one regression with the switch to using core Mesa's glReadPixels: we need to flush the bitmap cache first. I'll post a couple new patches. Actually, it'

[Mesa-dev] [PATCH] st/mesa: remove most of the ReadPixels code

We can use the core Mesa code for glReadPixels now. We just have to flush the bitmap cache before reading. --- src/mesa/state_tracker/st_cb_readpixels.c | 633 + src/mesa/state_tracker/st_cb_readpixels.h |9 - 2 files changed, 6 insertions(+), 636 deletions(-) di

Re: [Mesa-dev] [PATCH 7/7] st/mesa: remove st_cb_readpixels.[ch]

On 11/12/2011 01:25 PM, Brian Paul wrote: We now use the core Mesa code for glReadPixels. I found one regression with the switch to using core Mesa's glReadPixels: we need to flush the bitmap cache first. I'll post a couple new patches. -Brian __

Re: [Mesa-dev] TGSI declarations missing type info

On 11/14/2011 08:23 PM, Jose Fonseca wrote: > > > - Original Message - >> The next open question I have is whether this warrants additions to >> the tgsi_opcode_info struct, mainly whether the return value is >> uint/int/float, >> and whether then src regs are uint/int/float, I'm not 100%

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > > > - Original Message - > > The next open question I have is whether this warrants additions to > > the tgsi_opcode_info struct, mainly whether the return value is > > uint/int/float, > > and whether then src regs are uint/int/float, I'm not 100% that all

[Mesa-dev] [PATCH] mesa: Only update sampler uniforms that are used by the shader stage

From: Ian Romanick Previously a vertex shader that used no samplers would get updated (by calling the driver's ProgramStringNotify) when a sampler in the fragment shader was updated. This was discovered while investigating some spurious code generation for shaders in Cogs. The behavior in Cogs

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > The next open question I have is whether this warrants additions to > the tgsi_opcode_info struct, mainly whether the return value is > uint/int/float, > and whether then src regs are uint/int/float, I'm not 100% that all > opcodes always take all int/uint/float src

Re: [Mesa-dev] TGSI declarations missing type info

> > Having type info in TGSI registers is useless for llvm/llvmpipe, spite what > initial appearances may be. > > Imagine indirect addressing on this hypothetical world with typed TGSI > declarations: > >  DCL_float TEMP[0] >  DCL_int   TEMP[1] >  DCL_float TEMP[2] >  DCL_int   TEMP[3] >  DCL_fl

Re: [Mesa-dev] [PATCH] mesa: convert unpack functions to operate on an array of values

On Sat, 12 Nov 2011 14:43:27 -0700, Brian Paul wrote: > --- > src/mesa/main/format_unpack.c | 1530 > - > 1 files changed, 900 insertions(+), 630 deletions(-) Most boring-to-review patch ever, but I made it. I figured I should since I was meaning to writ

Re: [Mesa-dev] [PATCH 2/3] glsl: Split code to generate an ir_call out from match_function_by_name.

On 11 November 2011 02:56, Kenneth Graunke wrote: > match_function_by_name performs two fairly separate tasks: > 1. Hunt down the appropriate ir_function_signature for the callee. > 2. Generate the actual ir_call (assuming we found the callee). > > Both of these are complicated. The first has to

Re: [Mesa-dev] [PATCH 1/3] glsl: Add a new matching_signature() variant that returns exact/inexact.

On 11 November 2011 02:56, Kenneth Graunke wrote: > When matching function signatures across multiple linked shaders, we > often want to see if the current shader has _any_ match, but also know > whether or not it was exact. (If not, we may want to keep looking.) > > This could be done via the e

Re: [Mesa-dev] [PATCH] i965/gen4: Fix sampling from integer textures.

On 9 November 2011 16:11, Eric Anholt wrote: > On original gen4, the surface format didn't determine the return data > type from sampling like it does on g45 and later. > > Fixes GL_EXT_texture_integer/texture_integer_glsl130 > --- > > The dst type in your patch has already been smashed to UW for

Re: [Mesa-dev] [PATCH 1/2] ir_to_mesa: don't init unfirom if link failed

On 9 November 2011 01:10, Yuanhan Liu wrote: > Don't call set_unfiform_initializers if link failed, or it would trigger > a GL_INVALID_OPERATION error. That's not an expected behavior of > glLinkProgram function. > > Signed-off-by: Yuanhan Liu > --- > src/mesa/program/ir_to_mesa.cpp |4 +++-

Re: [Mesa-dev] [PATCH] softpipe: fix clamping when using unormalized coordinates

On 11/14/2011 10:24 AM, Morgan Armand wrote: On 11/14/2011 3:44 PM, Brian Paul wrote: On 11/13/2011 03:24 AM, Morgan Armand wrote: --- src/gallium/drivers/softpipe/sp_tex_sample.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp

Re: [Mesa-dev] [PATCH] softpipe: fix clamping when using unormalized coordinates

On 11/14/2011 3:44 PM, Brian Paul wrote: > On 11/13/2011 03:24 AM, Morgan Armand wrote: >> --- >> src/gallium/drivers/softpipe/sp_tex_sample.c |7 --- >> 1 files changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c >> b/src/gallium/dri

Re: [Mesa-dev] [PATCH 1/7] st/mesa: check renderbuffer orientation in st_MapRenderbuffer()

On Sat, 12 Nov 2011 13:25:21 -0700, Brian Paul wrote: > We'll soon be able to use these for a core Mesa implementation of > glReadPixels. I think 2-4 should be squashed, but other than that, Acked-by: Eric Anholt pgpc4CE8DE4im.pgp Description: PGP signature ___

Re: [Mesa-dev] [PATCH] util/draw: replace assertions with conditionals in util_draw_max_index()

On 11/14/2011 09:47 AM, Jose Fonseca wrote: That's verbose enough thanks. BTW, just noticed another problem in the change, the line max_index = ~0; should be replaced with max_index = ~0U - 1; otherwise return max_index + 1; will overflow and return 0 when all elements have strid

Re: [Mesa-dev] [PATCH 1/4] mesa: consolidate cases in _mesa_components_in_format()

On 11/14/2011 10:01 AM, Eric Anholt wrote: On Sat, 12 Nov 2011 13:26:57 -0700, Brian Paul wrote: and _mesa_sizeof_packed_type() --- src/mesa/main/image.c | 40 +++- 1 files changed, 11 insertions(+), 29 deletions(-) diff --git a/src/mesa/main/image.c b/

Re: [Mesa-dev] [PATCH 4/4] mesa: new BYTE/SHORT_TO_FLOATZ() macros

On Sat, 12 Nov 2011 13:27:00 -0700, Brian Paul wrote: > Rather than redefining the BYTE/SHORT_TO_FLOAT macros, just define new > ones with different names. These macros preserve zero when converting. These last 3 in the series are Reviewed-by: Eric Anholt pgp1LDO8YGQNL.pgp Description: PGP s

Re: [Mesa-dev] [PATCH 1/4] mesa: consolidate cases in _mesa_components_in_format()

On Sat, 12 Nov 2011 13:26:57 -0700, Brian Paul wrote: > and _mesa_sizeof_packed_type() > --- > src/mesa/main/image.c | 40 +++- > 1 files changed, 11 insertions(+), 29 deletions(-) > > diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c > index 7d95dd

Re: [Mesa-dev] [PATCH 5/5] mesa: remove support for software alpha buffers

On Sat, 12 Nov 2011 13:24:29 -0700, Brian Paul wrote: > This was only used by the xlib driver to add an alpha channel to the > front/window color buffer. This was no longer going to work well with > the move to direct mapping of renderbuffers. While I think it should have been equally doable sti

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On 14 November 2011 17:29, Christoph Bumiller wrote: > And r600, I think, just stores them all in TEMP space and exports them > in the end, so it's rather a property of the shader backend that the > device (I may be wrong though). > Instructions generally all work on GPRs (and a couple of special

Re: [Mesa-dev] [PATCH] util/draw: replace assertions with conditionals in util_draw_max_index()

That's verbose enough thanks. BTW, just noticed another problem in the change, the line max_index = ~0; should be replaced with max_index = ~0U - 1; otherwise return max_index + 1; will overflow and return 0 when all elements have stride 0, or are per-instance, causing the draw to b

Re: [Mesa-dev] [PATCH 2/2] util/draw: replace assertions with conditionals in util_draw_max_index()

New patch posted. Let me know if that's what you have in mind. -Brian On 11/14/2011 04:00 AM, Jose Fonseca wrote: Looks good, but some warnings on util_draw_max_index would be useful, as this is not something apps normally do, so are much more often a symptom of a state tracker bug than apps

[Mesa-dev] [PATCH] util/draw: replace assertions with conditionals in util_draw_max_index()

Don't assert/die if a VBO is too small. Return zero instead. For debug builds, emit a warning message since this is an unusual situation that might indicate that there's a bug in the app. Note that util_draw_max_index() now returns max_index+1 instead of max_index. This lets us return zero to i

Re: [Mesa-dev] [PATCH 03/13] gallium: fix function description

On 11/12/2011 02:11 PM, vlj wrote: ureg_DECL_constant2D does not return anything. --- src/gallium/auxiliary/tgsi/tgsi_ureg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c b/src/gallium/auxiliary/tgsi/tgsi_ureg.c index ca

Re: [Mesa-dev] [PATCH 02/13] gallium: rework some utilities functions to support 2d indexing

On 11/12/2011 02:11 PM, vlj wrote: This patch adds a 2d ureg_src constructor, and add a field in st_src_reg inside glsl_to_tgsi that hold potential 2d index. 2d indexing is required at least for uniform buffer object support --- src/gallium/auxiliary/tgsi/tgsi_ureg.h | 12

Re: [Mesa-dev] [PATCH 2/2] xlib: set alpha to 0xff when mapping RGB pixmaps

On 11/14/2011 09:25 AM, Eric Anholt wrote: On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paul wrote: On 11/11/2011 09:34 AM, Eric Anholt wrote: On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paul wrote: Fixes a bunch of conform regressions. --- src/mesa/drivers/x11/xm_buffer.c | 11 +++

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On 11/14/2011 03:14 PM, Henri Verbeet wrote: > On 14 November 2011 14:49, Vadim Girlin wrote: >> By the way, which drivers do not support reading outputs? I haven't done >> a full piglit run with llvmpipe, but IIRR the single test mentioned >> above was also fixed for llvmpipe without this output

Re: [Mesa-dev] [PATCH 4/4] intel: Support native Z16 depth textures (including as renderbuffer) on i965.

On Fri, 11 Nov 2011 14:09:51 -0800, Ian Romanick wrote: > On 11/11/2011 10:57 AM, Eric Anholt wrote: > > This is required for GL 3.0. The old comment about Z24 is dropped, > > since we support X8_Z24 now. > > --- > > src/mesa/drivers/dri/intel/intel_context.c | 13 ++--- > > 1 files

Re: [Mesa-dev] [PATCH 2/2] xlib: set alpha to 0xff when mapping RGB pixmaps

On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paul wrote: > On 11/11/2011 09:34 AM, Eric Anholt wrote: > > On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paul wrote: > >> Fixes a bunch of conform regressions. > >> --- > >> src/mesa/drivers/x11/xm_buffer.c | 11 +++ > >> 1 files changed, 11 in

Re: [Mesa-dev] [PATCH 01/13] mesa : move bindbuffer{base,range} from transformfeedback.c BindBuffer* functions are part of tfb extension. They are however used by others extensions such as uniform buf

On 11/12/2011 02:11 PM, vlj wrote: --- src/mesa/main/api_exec.c |2 + src/mesa/main/bufferobj.c | 48 + src/mesa/main/bufferobj.h | 12 + src/mesa/main/transformfeedback.c | 22 src/mesa/main/tra

[Mesa-dev] Piglit runs for R700 hw with r600g

Dear Mesa devs, I'm not sure whether you're interested in semi-regular Piglit runs for a R700 chip with the r600g driver. But as I have now to comparable sets with some regressions showing [0] between 9ae10e9c and 6246c217, I thought I let you know. I'll do a Piglit run for every Mesa revision I b

[Mesa-dev] [PATCH] st/mesa: check for missing VBO in setup_interleaved_attribs()

This fixes a crash with the piglit vbo-too-small test. --- src/mesa/state_tracker/st_draw.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c index f2fbf48..cb518e1 100644 --- a/src/mesa/state_tracker/s

Re: [Mesa-dev] [PATCH 1/2] st/mesa: allow creating buffers of size = 0

OK, handling this in the st_draw.c code is trivial. That'll take care of the piglit test. I'll have to follow-up later with other state tracker changes for other cases. -Brian On 11/14/2011 08:13 AM, Jose Fonseca wrote: Is it really necessary to bother pipe drivers with zero size buffers?

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On Mon, Nov 14, 2011 at 2:49 PM, Vadim Girlin wrote: > On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote: >> >> - Original Message - >> > Hi, >> > >> > I found some problem with glsl_to_tgsi: remove_output_reads function. >> > It's replacing outputs with temps, producing incorrect resu

Re: [Mesa-dev] [PATCH 1/2] st/mesa: allow creating buffers of size = 0

Is it really necessary to bother pipe drivers with zero size buffers? It looks like a useless corner case, which will cause all sort of implementations problems (e.g., malloc(0) may return NULL; kernel drivers will likely refuse 0 size buffers), so pipe drivers will need a lot of if (buffer-

Re: [Mesa-dev] [PATCH 1/2] gallium: add TGSI_SEMANTIC_VERTEXID

On 11/14/2011 08:08 AM, Jose Fonseca wrote: - Original Message - On 12.11.2011 00:30, Brian Paul wrote: On 11/11/2011 04:18 PM, Christoph Bumiller wrote: On 11.11.2011 23:59, Brian Paul wrote: On 11/11/2011 03:18 PM, Christoph Bumiller wrote: --- src/gallium/auxiliary/tgsi/tgsi

Re: [Mesa-dev] [PATCH] mesa-demos: Add blinking-teapot demo.

On 11/12/2011 04:49 PM, vlj wrote: blinking-teapot is an UBO demo. --- src/glsl/CMakeLists.txt|1 + src/glsl/Makefile.am |2 + src/glsl/blinking-teapot.c | 233 src/glsl/shader.frag | 31 ++ src/glsl/shader.vert

Re: [Mesa-dev] [PATCH 1/2] gallium: add TGSI_SEMANTIC_VERTEXID

- Original Message - > On 12.11.2011 00:30, Brian Paul wrote: > > On 11/11/2011 04:18 PM, Christoph Bumiller wrote: > >> On 11.11.2011 23:59, Brian Paul wrote: > >>> On 11/11/2011 03:18 PM, Christoph Bumiller wrote: > --- > src/gallium/auxiliary/tgsi/tgsi_dump.c |1 +

Re: [Mesa-dev] [PATCH] softpipe: fix clamping when using unormalized coordinates

On 11/13/2011 03:24 AM, Morgan Armand wrote: --- src/gallium/drivers/softpipe/sp_tex_sample.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c b/src/gallium/drivers/softpipe/sp_tex_sample.c index 72629a0..9b0e54e1 1006

Re: [Mesa-dev] [PATCH 2/2] st/mesa: fix system value to semantic mapping

Looks good to me. Jose - Original Message - > Broken by addition of SYSTEM_VALUE_VERTEX_ID in > 919c53e87a1f6f5322bc1f1486bb3e6b954b00d5. > --- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp |1 + > src/mesa/state_tracker/st_mesa_to_tgsi.c |1 + > 2 files changed, 2 insertions(+)

[Mesa-dev] [Bug 42895] FreeDesktop account request

https://bugs.freedesktop.org/show_bug.cgi?id=42895 Brian Paul changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On 14 November 2011 14:49, Vadim Girlin wrote: > By the way, which drivers do not support reading outputs? I haven't done > a full piglit run with llvmpipe, but IIRR the single test mentioned > above was also fixed for llvmpipe without this output replacement. > IIRC both GLSL IR and Mesa IR took

Re: [Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_SHADER_OUTPUT_READ

On Mon, 2011-11-14 at 14:08 +0100, Marek Olšák wrote: > Hi Vadim, > > Shouldn't this be in the pipe_shader_cap enum instead? > Probably you are right. I'll fix it. Vadim > Marek > > On Mon, Nov 14, 2011 at 1:57 PM, Vadim Girlin wrote: > > It's intended to indicate whether the driver/hardware

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote: > > - Original Message - > > Hi, > > > > I found some problem with glsl_to_tgsi: remove_output_reads function. > > It's replacing outputs with temps, producing incorrect results with > > relative addressing. You can see it e.g. with >

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

- Original Message - > Hi, > > I found some problem with glsl_to_tgsi: remove_output_reads function. > It's replacing outputs with temps, producing incorrect results with > relative addressing. You can see it e.g. with > "vs-varying-array-mat2-col-rd.shader_test". Here is a dump: > > >

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > On 14.11.2011 12:28, Jose Fonseca wrote: > > > > - Original Message - > >> Indirect addressing on TEMP should be forbidden and only allowed > >> for > >> TEMPORARY_ARRAY, I'd very much like to know which values I can > >> keep > >> in > >> registers and which

Re: [Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_SHADER_OUTPUT_READ

Hi Vadim, Shouldn't this be in the pipe_shader_cap enum instead? Marek On Mon, Nov 14, 2011 at 1:57 PM, Vadim Girlin wrote: > It's intended to indicate whether the driver/hardware supports reading > of the values written into shader outputs. > > Also remove assert to allow using TGSI_FILE_OUTPU

[Mesa-dev] [PATCH 3/3] r600g: handle PIPE_CAP_SHADER_OUTPUT_READ

Signed-off-by: Vadim Girlin --- src/gallium/drivers/r600/r600_pipe.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 243de14..bc9bbca 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b

[Mesa-dev] [PATCH 2/3] st/mesa: use PIPE_CAP_SHADER_OUTPUT_READ

Don't replace outputs with temps when the driver supports reading outputs. Signed-off-by: Vadim Girlin --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tr

[Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_SHADER_OUTPUT_READ

It's intended to indicate whether the driver/hardware supports reading of the values written into shader outputs. Also remove assert to allow using TGSI_FILE_OUTPUT registers in the ureg_emit_src. Signed-off-by: Vadim Girlin --- src/gallium/auxiliary/tgsi/tgsi_ureg.c |1 - src/gallium/inclu

[Mesa-dev] [PATCH 0/3] [RFC] Allow the drivers to control output reads removal

These patches are adding new pipe cap to allow omitting output->temp transformation when shader is reading output values. gallium: add PIPE_CAP_SHADER_OUTPUT_READ st/mesa: use PIPE_CAP_SHADER_OUTPUT_READ r600g: handle PIPE_CAP_SHADER_OUTPUT_READ src/gallium/auxiliary/tgsi/tgsi_ureg.c |

Re: [Mesa-dev] TGSI declarations missing type info

On 14.11.2011 12:28, Jose Fonseca wrote: - Original Message - Indirect addressing on TEMP should be forbidden and only allowed for TEMPORARY_ARRAY, I'd very much like to know which values I can keep in registers and which ones I have to store to thread-local memory (I can't do things li

[Mesa-dev] FOSDEM 2012 DevRoom!

Great News! We got ourselves another devroom! We are sharing it with the openICC project, we have currently pencilled in Xorg/Mesa/Wayland for saturday (we should be able to get the devroom in the morning already this year!) and sunday morning, and sunday afternoon is (currently) dedicated to o

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > On 14.11.2011 11:33, Jose Fonseca wrote: > > > > - Original Message - > >> On 13.11.2011 17:32, Christoph Bumiller wrote: > >>> On 13.11.2011 17:10, Marek Olšák wrote: > I am guessing there is no type info because TGSI shaders are > allowed >

Re: [Mesa-dev] [PATCH 2/2] util/draw: replace assertions with conditionals in util_draw_max_index()

Looks good, but some warnings on util_draw_max_index would be useful, as this is not something apps normally do, so are much more often a symptom of a state tracker bug than apps bugs. Jose - Original Message - > Don't assert/die if a VBO is too small. Return zero instead. > > Note th

Re: [Mesa-dev] TGSI declarations missing type info

On 14.11.2011 11:33, Jose Fonseca wrote: > > - Original Message - >> On 13.11.2011 17:32, Christoph Bumiller wrote: >>> On 13.11.2011 17:10, Marek Olšák wrote: I am guessing there is no type info because TGSI shaders are allowed to use uint, sint, and float instructions on th

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > > > - Original Message - > > On 13.11.2011 17:32, Christoph Bumiller wrote: > > > On 13.11.2011 17:10, Marek Olšák wrote: > > >> I am guessing there is no type info because TGSI shaders are > > >> allowed > > >> to use uint, sint, and float instructions on

Re: [Mesa-dev] TGSI declarations missing type info

- Original Message - > On 13.11.2011 17:32, Christoph Bumiller wrote: > > On 13.11.2011 17:10, Marek Olšák wrote: > >> I am guessing there is no type info because TGSI shaders are > >> allowed > >> to use uint, sint, and float instructions on the same register > >> without > >> type conve

Re: [Mesa-dev] TGSI declarations missing type info

On Mon, 2011-11-14 at 09:42 +, Keith Whitwell wrote: > On Sun, 2011-11-13 at 14:43 -0600, Bryan Cain wrote: > > On 11/13/2011 09:06 AM, Dave Airlie wrote: > > > Hi guys, > > > > > > Just been looking at llvmpipe integer support and it seems like we > > > lose some information about the type of

Re: [Mesa-dev] TGSI declarations missing type info

On Sun, 2011-11-13 at 14:43 -0600, Bryan Cain wrote: > On 11/13/2011 09:06 AM, Dave Airlie wrote: > > Hi guys, > > > > Just been looking at llvmpipe integer support and it seems like we > > lose some information about the type of data stored into temporaries, > > > > after st_glsl_to_cpp we no long