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:
VE
On 11/14/2011 07:16 AM, Marek Olšák wrote:
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, pr
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #2 from Pavel Ondračka 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:
> fixme:d3d_shader:print_glsl_info_log
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #3 from Marek Olšák 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 especially useful wi
- Original Message -
> On 11/14/2011 07:16 AM, Marek Olšák wrote:
> > 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_t
- 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
> > "vs-va
On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca 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 w
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
> > > Girlin wrote:
> > >> On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
> > >>>
> > >>> - Original Mess
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 t
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 Liu
---
src/mesa/main/light.c |3 +++
1 files changed, 3 insertions(+),
On 11/14/2011 03:03 PM, Morgan Armand wrote:
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 fi
On 15 November 2011 14:52, Jose Fonseca 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 can
> yield sub
- Original Message -
> On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca
> 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 replac
On Tue, Nov 15, 2011 at 9:43 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca
>> wrote:
>> >
>> >
>> > - Original Message -
>> >> On 11/13/2011 03:06 AM, Vadim Girlin wrote:
>> >> > Hi,
>> >> >
>> >> > I found some problem with gl
- 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
> > > > Girlin wrote:
> > > >> On Mon, 2011-11-14 at 05:22 -0800, Jose Fonse
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 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 things based on CAPs.
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, N
On Fre, 2011-11-11 at 21:25 +0100, Theiss, Ingo wrote:
> Am Freitag, 11. November 2011 14:53 CET, Brian Paul
> 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 wouldn't be surp
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 PIPE_SHADER_CAP_O
It's intended to indicate whether the driver/hardware supports reading
of the values written into shader outputs.
Signed-off-by: Vadim Girlin
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |1 -
src/gallium/include/pipe/p_defines.h |3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
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 | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/st
Signed-off-by: Vadim Girlin
---
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
--- a/src/gallium/drivers/r600/r600_pipe.c
+++
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 pipe_vi
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 chan
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, Va
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #4 from Ian Romanick 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 of unused
> consta
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #5 from Marek Olšák 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], CONST[550], CONST[1300]
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #6 from Marek Olšák 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 able to break arr
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #7 from José Fonseca 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 the cards. And if t
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #8 from Marek Olšák 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 to do this.
W
https://bugs.freedesktop.org/show_bug.cgi?id=42930
--- Comment #9 from Ian Romanick 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 pretty easily in the lin
https://bugs.freedesktop.org/show_bug.cgi?id=42930
Ian Romanick changed:
What|Removed |Added
Platform|Other |All
CC|
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 ins
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 +
On Mon, 14 Nov 2011 17:27:17 -0800, Kenneth Graunke
wrote:
> 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/
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 +-
src/mesa/drivers/dri/i965/brw_wm_surfa
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 o
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 a/src
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
b/src/mesa/drivers/dri/inte
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 a/src/mesa/dr
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.
---
src/mesa/drivers/dri/intel/intel_fbo
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
src/mesa/drivers/dri/i
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 a/src/mesa/drivers/dri
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
b/src/mesa/drivers/dri/i965/brw_wm_sur
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 promo
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
--- a/src/mesa/main/for
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
ditheri
On Sun, 13 Nov 2011 22:32:15 -0800, Chad Versace
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, then it's
> wasted effort t
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 Liu
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
56 matches
Mail list logo
