On 11/13/2011 03:06 AM, Vadim Girlin wrote:
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:
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim Girlinvadimgir...@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
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #2 from Pavel Ondračka pavel.ondra...@email.cz 2011-11-15
04:53:16 PST ---
(In reply to comment #1)
The telling bit from the log is:
fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #1:
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #3 from Marek Olšák mar...@gmail.com 2011-11-15 05:20:10 PST ---
Please Ian, can we not report a failure when the max number of uniform
components is exceeded? The r300 compiler can do some elimination of unused
constants. This is
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim
Girlinvadimgir...@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:
- Original Message -
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
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 Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads
function.
It's replacing outputs with temps, producing incorrect results
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim
Girlinvadimgir...@gmail.com wrote:
On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
- Original
On 11/15/2011 12:11 AM, Yuanhan Liu wrote:
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
On 11/15/2011 12:51 AM, Yuanhan Liu wrote:
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 Liuyuanhan@linux.intel.com
---
src/mesa/main/light.c |3 +++
1
On 15 November 2011 14:52, Jose Fonseca jfons...@vmware.com wrote:
Developer time is important too. And having more code paths shared with other
drivers (even at the expense of a few extra CPU cycles every time a shader is
created) means that developers has more time to focus on features that
- Original Message -
On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads
function.
It's replacing outputs
On Tue, Nov 15, 2011 at 9:43 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
Hi,
I found some problem
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim
Girlinvadimgir...@gmail.com wrote:
On Mon, 2011-11-14 at 05:22 -0800, Jose
On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim
On Tue, Nov 15, 2011 at 9:27 AM, Ian Romanick i...@freedesktop.org wrote:
I guess I don't follow. Different hardware can do different things, and the
code for that hardware will look different. What's the problem?
Well, I guess you're right. We already make the GLSL compiler do
different
On 11/15/2011 04:11 PM, Vadim Girlin wrote:
On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM,
On Fre, 2011-11-11 at 21:25 +0100, Theiss, Ingo wrote:
Am Freitag, 11. November 2011 14:53 CET, Brian Paul brian.e.p...@gmail.com
schrieb:
Ingo, if you could find out what the format/type parameters to
glReadPixels are, we could look into some optimization in the state
tracker. I
These patches are adding new pipe shader cap to allow omitting
output-temp transformation when shader is reading output values.
v2: use pipe_shader_cap enum instead of pipe_cap
gallium: add PIPE_SHADER_CAP_OUTPUT_READ
st/mesa: use PIPE_SHADER_CAP_OUTPUT_READ
r600g: handle
It's intended to indicate whether the driver/hardware supports reading
of the values written into shader outputs.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |1 -
src/gallium/include/pipe/p_defines.h |3 ++-
2 files changed, 2
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 | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_pipe.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 243de14..3c19034 100644
---
Hey all,
I'm convinced that right now the pipe_video_decoder and pipe_video_buffer are
unnecessarily complicated, and require simplification.
struct pipe_video_decoder
{
struct pipe_context *context;
enum pipe_video_profile profile;
enum pipe_video_entrypoint entrypoint;
enum
On 11/14/11 03:28, Luc Verhaegen wrote:
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
blinking-teapot is an UBO demo.
---
src/glsl/CMakeLists.txt |1 +
src/glsl/Makefile.am |2 +
src/glsl/blinking-teapot.c| 233 +
src/glsl/blinking-teapot.frag | 31 ++
src/glsl/blinking-teapot.vert | 16 +++
5 files
On 11/15/2011 07:11 AM, Vadim Girlin wrote:
On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM,
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #4 from Ian Romanick i...@freedesktop.org 2011-11-15 10:49:37 PST
---
(In reply to comment #3)
Please Ian, can we not report a failure when the max number of uniform
components is exceeded? The r300 compiler can do some elimination
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #5 from Marek Olšák mar...@gmail.com 2011-11-15 11:19:51 PST ---
The r300 compiler looks for the constants which are used and allocates new
locations for them.
For example this:
DCL CONST[0..2000]
0: MAD OUT[0], CONST[3],
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #6 from Marek Olšák mar...@gmail.com 2011-11-15 11:28:55 PST ---
I think the optimization was written before GLSL2 was merged. It can happen at
a higher level (it may be even more efficient there), but the GLSL
infrastructure must be
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #7 from José Fonseca jfons...@vmware.com 2011-11-15 11:29:15 PST
---
IMO, MAX_xxx_UNIFORMS should be checked against the number of active uniforms,
and not all those declared. Otherwise it would be limiting beyond the
capabilities of
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #8 from Marek Olšák mar...@gmail.com 2011-11-15 11:38:47 PST ---
(In reply to comment #7)
But hopefully it shouldn't be hard to make the optimization in the GLSL, and
therefore avoid backward notificiation calls.
If only I had time
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #9 from Ian Romanick i...@freedesktop.org 2011-11-15 11:54:48 PST
---
(In reply to comment #5)
The r300 compiler looks for the constants which are used and allocates new
locations for them.
I think we could achieve most this
https://bugs.freedesktop.org/show_bug.cgi?id=42930
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Platform|Other |All
Fixes regression in piglit:
ARB_color_buffer_float/GL_RGBA16F-getteximage
ARB_color_buffer_float/GL_RGBA16F-readpixels
ARB_color_buffer_float/GL_RGBA32F-getteximage
ARB_color_buffer_float/GL_RGBA32F-readpixels
---
src/mesa/main/format_unpack.c | 22 +++---
1 files changed, 11
On 11/15/2011 01:24 PM, Eric Anholt wrote:
Fixes regression in piglit:
ARB_color_buffer_float/GL_RGBA16F-getteximage
ARB_color_buffer_float/GL_RGBA16F-readpixels
ARB_color_buffer_float/GL_RGBA32F-getteximage
ARB_color_buffer_float/GL_RGBA32F-readpixels
---
src/mesa/main/format_unpack.c | 22
There are a couple of core mesa fixes tucked in this series.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
We're going to want to provide different answers per chipset
generation.
---
src/mesa/drivers/dri/i915/i830_vtbl.c |2 +-
src/mesa/drivers/dri/i915/i915_vtbl.c |2 +-
src/mesa/drivers/dri/i965/brw_wm.h|2 +-
This moves any chipset-dependent logic we want for render target
format choices to init time as well. There is still logic left at
state update for SRGB handling, where format choices change based on
GL state.
The brw_render_target_supported() function should now return correct
results, instead
This will be used to drive chosing formats and determining framebuffer
completeness, instead of the bunch of ad-hoc checks we have had until
now.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 204 ++
1 files changed, 204 insertions(+), 0 deletions(-)
diff --git
We don't want to go writing GetRow/PutRow for every format required by
GL 3.0, when it's very hard to get those functions called, and in
every case we want to make swrast do direct mapping through
MapRenderbuffer anyway.
This causes MESA_FORMAT_R11_G11_B10_FLOAT to be considered complete on gen6.
I've never seen a use for the thread ID value, but knowing the format
being rendered is kind of a big deal.
---
src/mesa/drivers/dri/intel/intel_fbo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
This is a no-op change on gen6, but should result in some
actually-unsupported formats on gen4 (like RGBA_FLOAT32) no longer
being chosen.
---
src/mesa/drivers/dri/intel/intel_context.c | 87
1 files changed, 0 insertions(+), 87 deletions(-)
diff --git
We are already testing this if appropriate in
intel_validate_framebuffer (FBO completeness), so no need to avoid
attaching the texture to the renderbuffer here.
This causes MESA_FORMAT_R11_G11_B10_FLOAT to now be renderable as a texture
attachment on i965.
---
The i965 driver is now enabling all of these formats on its own from
the surface format table.
---
NOTE: I need to test this series on i915.
src/mesa/drivers/dri/i915/i830_context.c |2 +
src/mesa/drivers/dri/i915/i915_context.c | 49
This is currently duplicated with intel_context.c's setup of the
formats table, and sets true for exactly the same set of formats on
gen6.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git
GL 3.0 specifies GL_RGBA16 as a required sized format for rendering
and texturing.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
The i965 driver can't do RGB float16 at all.
---
src/mesa/main/texformat.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index aebe38e..ea42ced 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
This should be a no-op change. The initializers are reordered to
match the ordering of the enum, since there isn't a clearly sensible
ordering, but the order they were added to the driver, sort of is
definitely not one.
Also, the unsupported formats are explicitly initialized to 0, so it's
more
Now that all the rest of the driver is driven off of the surface
formats table, all we really need to do is add the mapping from
MESA_FORMAT to BRW_SURFACEFORMAT. However, we also add format
override for I16/L16 render targets at the same time, so that existing
users of I16 that were getting
Fixes failures in i965 on fbo-blending-formats when the format is enabled.
---
src/mesa/main/format_unpack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 6e2ce7a..ae7a04b 100644
---
GL 3.0 specifies GL_RGB10_A2 as a required sized format for rendering
and texturing.
This introduces two piglit regressions: one due to fbo-mipmap-copypix
hitting swrast GetRow (we want to convert swrast to MapRenderbuffer),
and one due to fbo-blending-formats being too picky while leaving
On Sun, 13 Nov 2011 22:32:15 -0800, Chad Versace chad.vers...@linux.intel.com
wrote:
In intel_map_renderbuffer_s8(), detile and copy the stencil buffer into
the temporary buffer only if the renderbuffer is mapped in read mode. If
the caller never going to read the bits but just clobber them,
On Tue, Nov 15, 2011 at 07:26:52AM -0700, Brian Paul wrote:
On 11/15/2011 12:51 AM, Yuanhan Liu wrote:
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
On Tue, Nov 15, 2011 at 07:22:29AM -0700, Brian Paul wrote:
On 11/15/2011 12:11 AM, Yuanhan Liu wrote:
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
54 matches
Mail list logo
