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
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 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
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
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
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
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
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
@@
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
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
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
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
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
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
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.
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
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
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
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
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/
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 +
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
https://bugs.freedesktop.org/show_bug.cgi?id=42930
Ian Romanick changed:
What|Removed |Added
Platform|Other |All
CC|
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
--- 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 #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 #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 #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 #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
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
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/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
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
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
+++
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
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(-)
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
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
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 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 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
> > > > >
- 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, 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, 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 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
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 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/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 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 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
- 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
- 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
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
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
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
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
56 matches
Mail list logo
