From: Brian Paul
Per the GL spec, clamp incoming colors prior to blending depending on
whether the destination buffer stores normalized (non-float) values.
Note that the constant blend color needs to be clamped too (we always
get the unclamped color from Mesa).
Fixes https://bugs.freedesktop.org
The array_lvalue field was attempting to enforce the restriction that
whole arrays can't be used on the left-hand side of an assignment in
GLSL 1.10 or GLSL ES, and can't be used as out or inout parameters in
GLSL 1.10.
However, it was buggy (it didn't work properly for built-in arrays),
and it wa
- Original Message -
> On Mon, Sep 12, 2011 at 8:51 PM, Jose Fonseca
> wrote:
> >
> > This is what the OpenGL spec says about VertexAttribIPointer:
> >
> > Data for an array specified by VertexAttribPointer will
> > be converted to floating-point by normalizing if normalized is
> > TR
- Original Message -
> On 12.09.2011 21:14, Jose Fonseca wrote:
> >
> > - Original Message -
> >> Am 12.09.2011 19:05, schrieb Christoph Bumiller:
> >>> On 12.09.2011 18:41, Jose Fonseca wrote:
> - Original Message -
> > On Mon, Sep 12, 2011 at 5:48 PM, Roland Sch
Signed-off-by: Emeric Grange
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/presentation.c | 82 --
src/gallium/state_trackers/vdpau/vdpau_private.h |4 +
2 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/vd
Signed-off-by: Emeric Grange
Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/presentation.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/presentation.c
b/src/gallium/state_trackers/vdpau/presentation.c
index b
Signed-off-by: Emeric Grange
Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/presentation.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/presentation.c
b/src/gallium/state_trackers/vdpau/presentation.c
index
Signed-off-by: Emeric Grange
Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/bitmap.c| 13
src/gallium/state_trackers/vdpau/decode.c| 21 ++-
src/gallium/state_trackers/vdpau/device.c| 22 ++-
src/gallium/state_trackers/vdpau/mixer.c
Signed-off-by: Emeric Grange
Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/bitmap.c|4 ++--
src/gallium/state_trackers/vdpau/decode.c|6 +++---
src/gallium/state_trackers/vdpau/device.c|6 +++---
src/gallium/state_trackers/vdpau/ftab.c
Signed-off-by: Emeric Grange
---
src/gallium/drivers/nouveau/nouveau_video.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_video.c
b/src/gallium/drivers/nouveau/nouveau_video.c
index 75124e5..162e1aa 100644
--- a/src/gall
Signed-off-by: Emeric Grange
---
src/gallium/auxiliary/vl/vl_decoder.c |4 ++--
src/gallium/auxiliary/vl/vl_decoder.h |2 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c |3 ++-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |2 +-
src/gallium/include/pipe/p_co
Signed-off-by: Emeric Grange
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_compositor.c | 12
src/gallium/auxiliary/vl/vl_compositor.h |6 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gall
Signed-off-by: Emeric Grange
---
src/gallium/auxiliary/vl/vl_compositor.c | 16 +---
src/gallium/auxiliary/vl/vl_compositor.h | 12 ++--
src/gallium/auxiliary/vl/vl_video_buffer.c |2 +-
src/gallium/auxiliary/vl/vl_video_buffer.h |8
4 files changed, 2
Hi,
Here is a series of small patches to the g3dvl video decoding stack.
Most of these are extracted from my GSoC 2011 work and are not related
to VP8 decoding (http://cgit.freedesktop.org/~emericg/mesa-vp8/).
The third and fourth patches are only useful for codecs that use more
than 2 reference
On Mon, Sep 12, 2011 at 8:51 PM, Jose Fonseca wrote:
>
> This is what the OpenGL spec says about VertexAttribIPointer:
>
> Data for an array specified by VertexAttribPointer will
> be converted to floating-point by normalizing if normalized is TRUE, and
> converted
> directly to floating-point
On 12.09.2011 21:14, Jose Fonseca wrote:
>
> - Original Message -
>> Am 12.09.2011 19:05, schrieb Christoph Bumiller:
>>> On 12.09.2011 18:41, Jose Fonseca wrote:
- Original Message -
> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
> wrote:
>> Am 11.09.2011 1
- Original Message -
> Am 12.09.2011 19:05, schrieb Christoph Bumiller:
> > On 12.09.2011 18:41, Jose Fonseca wrote:
> >>
> >> - Original Message -
> >>> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
> >>> wrote:
> Am 11.09.2011 19:17, schrieb Dave Airlie:
> > On
- Original Message -
> On Mon, Sep 12, 2011 at 6:41 PM, Jose Fonseca
> wrote:
> >
> >
> > - Original Message -
> >> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
> >> wrote:
> >> > Am 11.09.2011 19:17, schrieb Dave Airlie:
> >> >> On Sun, Sep 11, 2011 at 10:11 AM, Dave Air
Am 12.09.2011 19:05, schrieb Christoph Bumiller:
> On 12.09.2011 18:41, Jose Fonseca wrote:
>>
>> - Original Message -
>>> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
>>> wrote:
Am 11.09.2011 19:17, schrieb Dave Airlie:
> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
>>>
- Original Message -
> On 12.09.2011 18:41, Jose Fonseca wrote:
> >
> > - Original Message -
> >> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
> >> wrote:
> >>> Am 11.09.2011 19:17, schrieb Dave Airlie:
> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
>
> wr
On Mon, Sep 12, 2011 at 6:41 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
>> wrote:
>> > Am 11.09.2011 19:17, schrieb Dave Airlie:
>> >> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
>> >> wrote:
>> >>> Hi guys,
>> >>>
>> >>> n
On 12.09.2011 18:41, Jose Fonseca wrote:
>
> - Original Message -
>> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
>> wrote:
>>> Am 11.09.2011 19:17, schrieb Dave Airlie:
On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
wrote:
> Hi guys,
>
> not really finding a g
On Tue, Sep 06, 2011 at 03:11:25PM -0300, Eugeni Dodonov wrote:
> On Mon, Sep 5, 2011 at 16:37, Alon Levy wrote:
>
> > Fixes three segmentation faults where it is wrongly assumed the depth
> > buffer's
> > renderbuffer's region is not NULL.
> >
> > 735794 - verified to be fixed by these three pat
- Original Message -
> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
> wrote:
> > Am 11.09.2011 19:17, schrieb Dave Airlie:
> >> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
> >> wrote:
> >>> Hi guys,
> >>>
> >>> not really finding a great explaination in my 2 minute search, of
>
On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger wrote:
> Am 11.09.2011 19:17, schrieb Dave Airlie:
>> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie wrote:
>>> Hi guys,
>>>
>>> not really finding a great explaination in my 2 minute search, of what
>>> the USCALED and SSCALED types are represen
On 12.09.2011 17:48, Roland Scheidegger wrote:
> Am 11.09.2011 19:17, schrieb Dave Airlie:
>> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie wrote:
>>> Hi guys,
>>>
>>> not really finding a great explaination in my 2 minute search, of what
>>> the USCALED and SSCALED types are representative of
>>>
Am 11.09.2011 19:17, schrieb Dave Airlie:
> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie wrote:
>> Hi guys,
>>
>> not really finding a great explaination in my 2 minute search, of what
>> the USCALED and SSCALED types are representative of
>>
>> On r600 hw at least we have a SCALED type, which se
On 09/12/2011 09:17 AM, Dave Airlie wrote:
From: Dave Airlie
The EXT_texture_integer issues says:
Should pixel transfer operations be defined for the integer pixel
path?
RESOLVED: No. Fragment shaders can achieve similar results
with more flexibility. There is no need to aggrandize this
lega
From: Dave Airlie
The EXT_texture_integer issues says:
Should pixel transfer operations be defined for the integer pixel
path?
RESOLVED: No. Fragment shaders can achieve similar results
with more flexibility. There is no need to aggrandize this
legacy mechanism.
v2: fix comments, fix unpack
From: Michel Dänzer
As already done in dri2CopySubBuffer().
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=36371
https://bugs.freedesktop.org/show_bug.cgi?id=40533
Might fix:
https://bugs.freedesktop.org/show_bug.cgi?id=32589
Signed-off-by: Michel Dänzer
---
src/glx/dri2_glx.c |
On 09/12/2011 07:46 AM, Dave Airlie wrote:
From: Dave Airlie
The EXT_texture_integer issues says:
Should pixel transfer operations be defined for the integer pixel
path?
RESOLVED: No. Fragment shaders can achieve similar results
with more flexibility. There is no need to aggrandize this
lega
On 09/12/2011 06:10 AM, Marek Olšák wrote:
Setting just MAX_PROGRAM_ENV_PARAMS to 4096 breaks everything,
so let's do this instead.
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40767
---
src/mesa/state_tracker/st_extensions.c |4 ++--
1 files changed, 2 insertions(+), 2 deleti
On Mon, Sep 12, 2011 at 6:17 AM, Dave Airlie wrote:
> Hi,
>
> So I was looking at EXT_texture_integer and realised our clear code was
> a bit rough wrt allowing drivers access to the native ints. Also the
> use of ClearColor vs ClearColorUnclamped meant that gallium never got the
> i/ui clear valu
From: Dave Airlie
The EXT_texture_integer issues says:
Should pixel transfer operations be defined for the integer pixel
path?
RESOLVED: No. Fragment shaders can achieve similar results
with more flexibility. There is no need to aggrandize this
legacy mechanism.
Signed-off-by: Dave Airlie
-
From: Dave Airlie
Signed-off-by: Dave Airlie
---
src/mesa/main/clear.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index cec0a57..3277a37 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@
From: Dave Airlie
this is still incorrect, because we need to pass the type + native values
down via gallium.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_cb_clear.c | 14 --
src/mesa/state_tracker/st_format.c | 29 +
src/mesa/state_tra
From: Dave Airlie
Add save/restore support around the GL3.0 clear APIs.
for the get.c change I'm not sure the spec says what we should do in this case,
couldn't find any mention in EXT_texture_integer at least, for now just convert
to float and return values.
Signed-off-by: Dave Airlie
---
From: Dave Airlie
This adds a clear color type and introduces setting it to GL_FLOAT
in the appropriate places.
Signed-off-by: Dave Airlie
---
src/mesa/main/blend.c |1 +
src/mesa/main/clear.c | 39 ++-
src/mesa/main/mtypes.h |2 +-
3 files chang
From: Dave Airlie
This introduces a new gl_clear_color union and moves the current
ClearColor and ClearColorUnclamped to use it, along with changing the
ClearColor API to device driver to include a new field for clear color type.
Signed-off-by: Dave Airlie
---
src/mesa/drivers/common/meta.c
Hi,
So I was looking at EXT_texture_integer and realised our clear code was
a bit rough wrt allowing drivers access to the native ints. Also the
use of ClearColor vs ClearColorUnclamped meant that gallium never got the
i/ui clear values at all (even as floats). These patches are my first attempt
a
Setting just MAX_PROGRAM_ENV_PARAMS to 4096 breaks everything,
so let's do this instead.
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40767
---
src/mesa/state_tracker/st_extensions.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_
On 12.09.2011 13:09, Dave Airlie wrote:
> At line 585 in st_cb_clear.c
>
> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_cb_clear.c#n585
>
> we translate the clear color, but never use the result, maybe someone
> knows what should have happened here.
The intention probably w
I didn't look at the diff in detail, but I'm fine with removing the inner
struct.
Jose
- Original Message -
> ---
> src/gallium/auxiliary/pipebuffer/pb_buffer.h | 24
> ++
> .../auxiliary/pipebuffer/pb_buffer_fenced.c| 32
> ++--
> .../aux
At line 585 in st_cb_clear.c
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_cb_clear.c#n585
we translate the clear color, but never use the result, maybe someone
knows what should have happened here.
Dave.
___
mesa-dev mailing lis
https://bugs.freedesktop.org/show_bug.cgi?id=39017
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--
Configure bugmail
45 matches
Mail list logo
