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 longer know what
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 data stored
- 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 conversions (it would
- 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 the same register
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 the same register
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 that
- 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
to use uint, sint, and
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
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 |
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 vadimgir...@gmail.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |
Don't replace outputs with temps when the driver supports reading outputs.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
---
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 vadimgir...@gmail.com wrote:
It's intended to indicate whether the driver/hardware supports reading
of the values written into shader outputs.
Also remove assert to allow
- 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 ones I have to store
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
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 vadimgir...@gmail.com wrote:
It's intended to indicate whether the
On 14 November 2011 14:49, Vadim Girlin vadimgir...@gmail.com 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
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(+), 0
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
- 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 +
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 ++
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:
---
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
On Mon, Nov 14, 2011 at 2:49 PM, Vadim Girlin vadimgir...@gmail.com 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
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?
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
---
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
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
On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paul bri...@vmware.com wrote:
On 11/11/2011 09:34 AM, Eric Anholt wrote:
On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paulbri...@vmware.com wrote:
Fixes a bunch of conform regressions.
---
src/mesa/drivers/x11/xm_buffer.c | 11 +++
1
On Fri, 11 Nov 2011 14:09:51 -0800, Ian Romanick i...@freedesktop.org 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 ++---
On 11/14/2011 03:14 PM, Henri Verbeet wrote:
On 14 November 2011 14:49, Vadim Girlin vadimgir...@gmail.com 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
On 11/14/2011 09:25 AM, Eric Anholt wrote:
On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paulbri...@vmware.com wrote:
On 11/11/2011 09:34 AM, Eric Anholt wrote:
On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paulbri...@vmware.com wrote:
Fixes a bunch of conform regressions.
---
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
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
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
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
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
On 14 November 2011 17:29, Christoph Bumiller
e0425...@student.tuwien.ac.at 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
On Sat, 12 Nov 2011 13:24:29 -0700, Brian Paul bri...@vmware.com 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
On Sat, 12 Nov 2011 13:26:57 -0700, Brian Paul bri...@vmware.com 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
On Sat, 12 Nov 2011 13:27:00 -0700, Brian Paul bri...@vmware.com 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 e...@anholt.net
On 11/14/2011 10:01 AM, Eric Anholt wrote:
On Sat, 12 Nov 2011 13:26:57 -0700, Brian Paulbri...@vmware.com wrote:
and _mesa_sizeof_packed_type()
---
src/mesa/main/image.c | 40 +++-
1 files changed, 11 insertions(+), 29 deletions(-)
diff --git
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
On Sat, 12 Nov 2011 13:25:21 -0700, Brian Paul bri...@vmware.com 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 e...@anholt.net
pgpc4CE8DE4im.pgp
Description: PGP signature
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
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
On 9 November 2011 01:10, Yuanhan Liu yuanhan@linux.intel.com 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 yuanhan@linux.intel.com
On 9 November 2011 16:11, Eric Anholt e...@anholt.net 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
On 11 November 2011 02:56, Kenneth Graunke kenn...@whitecape.org 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
On 11 November 2011 02:56, Kenneth Graunke kenn...@whitecape.org 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.
On Sat, 12 Nov 2011 14:43:27 -0700, Brian Paul bri...@vmware.com 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
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_float TEMP[4]
- 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 srcs,
From: Ian Romanick ian.d.roman...@intel.com
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
- 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
opcodes
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% that all
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
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(-)
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,
- 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 whether then src regs
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
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 return value is
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
to
the tgsi_opcode_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
the tgsi_opcode_info struct,
- 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 question I have is whether this
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:
- Original Message -
The next open
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 broken by
On Sun, 13 Nov 2011 22:32:13 -0800, Chad Versace chad.vers...@linux.intel.com
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
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(+), 3 deletions(-)
On Sun, 13 Nov 2011 22:32:14 -0800, Chad Versace chad.vers...@linux.intel.com
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
-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
chad.vers...@linux.intel.com wrote:
For a depthstencil buffer with separate stencil,
intel_renderbuffer::region is null. (The regions are kept in hidden
-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
chad.vers...@linux.intel.com wrote:
This patch fixes three interrelated bugs.
Fixes many depthstencil Piglit tests on gen7, too many to list.
1. Don't
On Mon, 14 Nov 2011 09:29:48 -0700, Brian Paul bri...@vmware.com wrote:
On 11/14/2011 09:25 AM, Eric Anholt wrote:
On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paulbri...@vmware.com wrote:
On 11/11/2011 09:34 AM, Eric Anholt wrote:
On Thu, 10 Nov 2011 18:01:47 -0700, Brian
On 11/14/2011 10:20 AM, Paul Berry wrote:
On 11 November 2011 02:56, Kenneth Graunke kenn...@whitecape.org
mailto:kenn...@whitecape.org wrote:
When matching function signatures across multiple linked shaders, we
often want to see if the current shader has _any_ match, but also know
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
---
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
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
We'll be able to kill more of these once the old VS backend is gone.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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)
https://bugs.freedesktop.org/show_bug.cgi?id=42930
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Keywords||NEEDINFO
--- Comment
On 11/14/2011 11:25 AM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
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 red
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
-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.org
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 yuanhan@linux.intel.com
---
src/mesa/main/light.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
84 matches
Mail list logo
