On 12/16/2012 07:49 AM, Brian Paul wrote:
On Sat, Dec 15, 2012 at 11:09 PM, Paul Berry wrote:
The rather unweildy logic for determining this condition was repeated
in a large number of places. This patch consolidates it to a single
inline function.
@@ -111,4 +113,11 @@ _mesa_PauseTransfor
Writemask was XY instead of YZ (thanks to calim for spotting it).
The pixel calculation resulted in the pixel always being off by one.
If y was .5:
y' = round(y) + 0.5 = 1.5
Fixing this also means the LRP function has to swap the pixels it, since
it's now the other way around for top/bottom.
WI
Looks fine.
I'm curious, what does this fix in practice?
Jose
- Original Message -
> NOTE: This is a candidate for the stable branches.
> ---
> src/gallium/drivers/llvmpipe/lp_texture.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/llvm
On 18.12.2012 09:18, Maarten Lankhorst wrote:
Writemask was XY instead of YZ (thanks to calim for spotting it).
The pixel calculation resulted in the pixel always being off by one.
If y was .5:
y' = round(y) + 0.5 = 1.5
Fixing this also means the LRP function has to swap the pixels it, since
i
Add support for cube map arrays, TEX2, TXB2, TXL2, fix SHADOWCUBE.
Signed-off-by: Vadim Girlin
---
The patch includes minimal fix for radeonsi to avoid breaking the build or
introducing regressions, but probably some additional changes are required
to make new features really work on SI.
src/g
Hi,
Something that hit me in GLSL Optimizer (which is based on Mesa's GLSL).
Cloning ir_loop just sets "counter" to the old counter. So in situations
like:
1) loop controls are set,
2) and after that inlining happens, cloning the instructions including
original variable
It ends up in a situation
Op 18-12-12 11:42, Christian König schreef:
> On 18.12.2012 09:18, Maarten Lankhorst wrote:
>> Writemask was XY instead of YZ (thanks to calim for spotting it).
>>
>> The pixel calculation resulted in the pixel always being off by one.
>> If y was .5:
>>
>> y' = round(y) + 0.5 = 1.5
>>
>> Fixing th
It seems the other code expects surface[0..1] to be the luma field in
interlaced case.
See for example vdpau/surface.c vlVdpVideoSurfaceClear and
vlVdpVideoSurfacePutBitsYCbCr.
Signed-off-by: Maarten Lankhorst
---
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxilia
Op 18-12-12 13:04, Maarten Lankhorst schreef:
> Op 18-12-12 11:42, Christian König schreef:
>> On 18.12.2012 09:18, Maarten Lankhorst wrote:
>>> Writemask was XY instead of YZ (thanks to calim for spotting it).
>>>
>>> The pixel calculation resulted in the pixel always being off by one.
>>> If y wa
On Die, 2012-12-18 at 14:24 +0400, Vadim Girlin wrote:
> Add support for cube map arrays, TEX2, TXB2, TXL2, fix SHADOWCUBE.
>
> Signed-off-by: Vadim Girlin
> ---
>
> The patch includes minimal fix for radeonsi to avoid breaking the build or
> introducing regressions, but probably some additiona
On Tue, Dec 18, 2012 at 11:20 AM, Jose Fonseca wrote:
> Looks fine.
>
> I'm curious, what does this fix in practice?
It fixes Weston crashing when running with llvmpipe.
>
> Jose
>
> - Original Message -
>> NOTE: This is a candidate for the stable branches.
>> ---
>> src/gallium/drivers/
On 18.12.2012 13:21, Maarten Lankhorst wrote:
Op 18-12-12 13:04, Maarten Lankhorst schreef:
Op 18-12-12 11:42, Christian König schreef:
On 18.12.2012 09:18, Maarten Lankhorst wrote:
Writemask was XY instead of YZ (thanks to calim for spotting it).
The pixel calculation resulted in the pixel a
I'm not very familiar with these features, but if this passes piglit tests then
it sounds good to me FWIW.
It's however weird that using draw->pt.max_index + 1 (i.e., maximum fecthed
vertex) for count_from_stream_output works in general. I'd imagine it to be
some sort of runtime determined amou
Ian Romanick writes:
> I think we need a flag to select this behavior. There are some meta ops
> that *do* generate fragments (e.g., _mesa_meta_DrawPixels), and this
> will prevent them from being counted.
OK. Today I'm writing new piglit tests for all of this. I'll try to get
coverage over al
From: Jerome Glisse
This force surface allocated from ddx to be consider as height
aligned on 8 and fix 1D->2D tiling transition that result from
this.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_texture.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
d
Reviewed-by: Marek Olšák
Thank you!
Marek
On Tue, Dec 18, 2012 at 6:50 PM, wrote:
> From: Jerome Glisse
>
> This force surface allocated from ddx to be consider as height
> aligned on 8 and fix 1D->2D tiling transition that result from
> this.
>
> Signed-off-by: Jerome Glisse
> ---
> src/g
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..9e32836 100644
--- a/src/mesa/main/fbobject.c
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..9e32836 100644
--- a/src/mesa/main/fbobject.c
On 12/17/2012 07:33 PM, Anuj Phogat wrote:
This patch rewrites _mesa_meta_BlitFrameBuffer() function to add support
for blitting with GLSL/GLSL ES shaders. These changes were required to
support glBlitFrameBuffer() in gles3. This patch, along with other patches
in this series, make 16 failing fra
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dr
On 12/18/2012 11:20 AM, Ian Romanick wrote:
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
Signed-o
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv()
for gles3. Fixes unexpected GL errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
Signed-off-by: Anuj Phogat
Re
On 12/17/2012 07:35 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
It also fixes a blitting case when drawAttachment->Te
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dr
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv()
for gles3. Fixes unexpected GL errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
Signed-off-by: Anuj Phogat
---
On 12/15/2012 10:09 PM, Paul Berry wrote:
This patch implements the following behaviours, which are mandated by
the GL 4.3 and GLES3 specs.
1. Regarding the GL_TRANSFORM_FEEDBACK_BUFFER_SIZE query: "If the
... size was not specified when the buffer object was bound
(e.g. if it was bound
On 12/17/2012 07:35 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
It also fixes a blitting case when drawAttachment->Te
On Tue, Dec 18, 2012 at 11:09 AM, Kenneth Graunke wrote:
> On 12/12/2012 03:25 PM, Anuj Phogat wrote:
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/main/fbobject.c | 10 +-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/mesa/main/fbobject.c b/src/mes
On 12/18/2012 12:05 PM, Anuj Phogat wrote:
On Tue, Dec 18, 2012 at 11:09 AM, Kenneth Graunke wrote:
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/me
On Tue, Dec 18, 2012 at 12:12 PM, Kenneth Graunke wrote:
> On 12/18/2012 12:05 PM, Anuj Phogat wrote:
>>
>> On Tue, Dec 18, 2012 at 11:09 AM, Kenneth Graunke
>> wrote:
>>>
>>> On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbob
In ES 3.0, when calling glDrawBuffers() on the window system
framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
is no stereo rendering in ES 3.0, this is a single buffer, unlike
desktop where it may be two (and thus isn't allowed).
For single-buffered configs, GL_BACK ironica
Nothing was explicitly checking this.
---
src/mesa/main/buffers.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 244f4de..065ef2a 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -316,6 +316,16 @@ _mesa_D
Relayout is expensive, so it's something developers (both us and others)
should know about when it happens.
---
src/mesa/drivers/dri/intel/intel_tex_validate.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c
b/src/mesa/drivers/dri/intel/
The ETC1 changes failed at this, so let's make sure it will be caught in
testing next time.
---
src/mesa/drivers/dri/intel/intel_tex_validate.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c
b/src/mesa/drivers/dri/intel/intel_tex_valid
This was caught by the assertion in the next commit. This causes 8
depthstencil cases to start passing (presumably because of fewer broken
texture validates happening) while regressing 3. Given that this causes
there to be no more failures at the 585 and 146 sizes while only
introducing failures
When comparing to the teximage's format, we have to look at the
format-the-mt-was-created-for not the format-actually-stored-in-the-mt.
Improves glbenchmark 2.1 offscreen test performance 159% +/- 17% (n=3).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54582
---
src/mesa/drivers/dri/in
Fixes all the remaining non-Z32F_S8 depthstencil-render-miplevels
tests in piglit.
---
This causes the other Z32F change in the series I sent out earlier
today to result in all depthstencil-render-miplevels tests passing.
My plan is to push this series before that one.
src/mesa/drivers/dri/i965
Fixing these rendering bugs has been implicated in performance
regressions (which may be unfixable), but at least knowing that it's
happening should help diagnose those regressions.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 16
1 file changed, 16 insertions(+)
diff --git
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h |5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index 3a465da..eb4ad7f 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/sr
On Tue, Dec 18, 2012 at 11:35 AM, Kenneth Graunke wrote:
> On 12/12/2012 03:25 PM, Anuj Phogat wrote:
>>
>> This allows query on default framebuffer in
>> glGetFramebufferAttachmentParameteriv()
>> for gles3. Fixes unexpected GL errors in gles3 conformance test case:
>> framebuffer_blit_functional
The new VS uploads clip planes like any other parameters; this extra
allocation was for the old VS which uploaded them specially. With the
old VS gone, this just wastes space and bandwidth.
---
src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
On Tue, Dec 18, 2012 at 1:26 PM, Kenneth Graunke wrote:
> In ES 3.0, when calling glDrawBuffers() on the window system
> framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
> is no stereo rendering in ES 3.0, this is a single buffer, unlike
> desktop where it may be two (and t
On Tue, Dec 18, 2012 at 1:26 PM, Kenneth Graunke wrote:
> Nothing was explicitly checking this.
> ---
> src/mesa/main/buffers.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 244f4de..065ef2a 100644
> --- a/src/mesa/m
On Tue, Dec 18, 2012 at 4:35 PM, Anuj Phogat wrote:
> On Tue, Dec 18, 2012 at 1:26 PM, Kenneth Graunke
> wrote:
>> In ES 3.0, when calling glDrawBuffers() on the window system
>> framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
>> is no stereo rendering in ES 3.0, this is
V2:
If mask has GL_STENCIL_BUFFER_BIT set, the depth formats for readRenderBuffer
and drawRenderBuffer must match unless one of the two buffers doesn't have
depth, in which case it's not blitted, so the format check should be ignored.
Same comment goes for stencil formats in depth renderbuffers if
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv()
for gles3. Fixes unexpected GL errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
V2: Use _mesa_is_gles3() check to restrict allowed attachment types to
specif
Paul Berry writes:
> This patch implements the following behaviours, which are mandated by
> the GL 4.3 and GLES3 specs.
>
> 1. Regarding the GL_TRANSFORM_FEEDBACK_BUFFER_SIZE query: "If the
>... size was not specified when the buffer object was bound
>(e.g. if it was bound with BindBuffe
47 matches
Mail list logo
