Fixes currently failing Piglit case
interface-blocks-name-reused-globally.vert
Signed-off-by: Tapani Pälli
---
src/glsl/ast_to_hir.cpp | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 811a955..13ddb00
https://bugs.freedesktop.org/show_bug.cgi?id=88275
--- Comment #22 from Ian Romanick ---
(In reply to Jason Ekstrand from comment #11)
> Could you go back to the semi-working configuration you had before and get a
> glxinfo from it. I can't tell what mesa driver is being called. We have
> two d
On 01/19/2015 03:31 PM, Matt Turner wrote:
> total instructions in shared programs: 5952059 -> 5951603 (-0.01%)
> instructions in affected programs: 138812 -> 138356 (-0.33%)
> GAINED:1
> LOST: 0
Does the "glsl: Rewrite (-abs(x)
On 01/17/2015 07:10 AM, Felix Janda wrote:
> Fixes compilation with musl libc.
> ---
> src/mesa/main/querymatrix.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c
> index eb36c76..57c536f 100644
>
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> Currently, we only consider precision qualifiers at compile-time. This patch
> adds precision information to ir_variable so we can also do link time checks.
> Specifically, from the GLSL ES3 spec, 4.5.3 Precision Qua
On 01/19/2015 04:41 AM, Erik Faye-Lund wrote:
> On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
>> From: Iago Toral Quiroga
>>
>> Fixes the following 2 dEQP tests:
>> dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_vertex
>> dEQP-GLES3.functional.shaders.keywords
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> From: Samuel Iglesias Gonsalvez
>
> Section 6.1.13 "Framebuffer Object Queries" of OpenGL ES 3.0 spec:
>
> "If the default framebuffer is bound to target, then attachment must be
> BACK, identifying the color buffer; DEPTH, identifying the d
On 20.01.2015 00:07, Marek Olšák wrote:
>
> 3) Since the CP runs in parallel with the graphics engine, shaders can
> be busy while WRITE_DATA is changing their code. (no good can come out
> of that) Therefore, the partial flushes (= partial "WAIT_UNTIL") must
> be emitted before the WRITE_DATA pac
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> Currently, Mesa uses the lowering pass MOD_TO_FRACT to implement
> mod(x,y) as y * fract(x/y). This implementation has a down side though:
> it introduces precision errors due to the fract() operation. Even worse,
>
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> GLES 3.0.0 spec introduces context state PRIMITIVE_RESTART_FIXED_INDEX
> (2.8.1 Transferring Array Elements, page 26) which is not currently
> possible to query using glGet*() funcs.
This should also be queryable when GL_ARB_ES3_compatibility is
On 01/19/2015 04:52 AM, Erik Faye-Lund wrote:
> On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
>> From: Iago Toral Quiroga
>>
>> So far we have only been emitting a warning.
>>
>> Fixes the following 2 dEQP tests:
>> dEQP-GLES3.functional.shaders.arrays.invalid.empty_declaration_with
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> Fixes the following 2 dEQP tests:
> dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_const_vertex
> dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_const_fra
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> Fixes the following 2 dEQP tests:
> dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_in_main_vertex
> dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_in_main
On 01/19/2015 04:35 AM, Erik Faye-Lund wrote:
> On Mon, Jan 19, 2015 at 1:31 PM, Erik Faye-Lund wrote:
>> On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev
>> wrote:
>>> The manual page for glGetAttachedShaders, glGetShaderSource,
>>> glGetActiveUniform and
>>> glGetActiveUniform state that
On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> The manual page for glGetAttachedShaders, glGetShaderSource,
> glGetActiveUniform and
> glGetActiveUniform state that a GL_INVALID_VALUE is returned if the maximum
> length
> argument is less than zero. For reference, see:
> https://www.opengl.o
On 01/15/2015 08:39 PM, Kenneth Graunke wrote:
> On Friday, January 16, 2015 04:54:44 PM Ian Romanick wrote:
>> On 01/16/2015 04:25 PM, Matt Turner wrote:
>>> On Thu, Jan 15, 2015 at 6:46 PM, Ian Romanick wrote:
On 01/16/2015 08:15 AM, Matt Turner wrote:
> From: Ian Romanick
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=87886
--- Comment #19 from Hohahiu ---
Maybe a wild guess, but what are the temperatures of the GPUs in your laptop?
Is this an overheating issue?
--
You are receiving this mail because:
You are the assignee for the bug.
_
On Mon, Jan 19, 2015 at 4:04 PM, Jason Ekstrand wrote:
> I've got some specific comments below, but I want to make some more general
> comments here. I like this in principle: having all the opcodes
> self-documenting is wonderful. However, I'm not terribly happy with the way
> it worked out. A
Nope. But feel free to do a piglit run to prove/disprove. The fragcoord
origin tests should start failing with your patch.
On Jan 19, 2015 3:41 PM, "Tiziano Bacocco" wrote:
> Could it be that it affects also fragcoord? because also on rnndb it says
> that
>
> 2015-01-20 0:17 GMT+01:00 Ilia Mirkin
Could it be that it affects also fragcoord? because also on rnndb it says
that
2015-01-20 0:17 GMT+01:00 Ilia Mirkin :
> Oops, dropped cc.
> On Jan 19, 2015 3:15 PM, "Ilia Mirkin" wrote:
>
>> Nope, that's for something else. This has to do with whether gl fragcoord
>> is at the integer or half i
---
src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
index 81be4de..d66808b 100644
--- a/src/mesa/drivers/dr
total instructions in shared programs: 5974160 -> 5959463 (-0.25%)
instructions in affected programs: 1743737 -> 1729040 (-0.84%)
GAINED:0
LOST: 12
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/d
Otherwise we'll apply the conditional mod to only one of SIMD8
instructions and trigger an assertion.
NoDDClr/NoDDChk have the same problem but we never apply those to these
instructions, so I'm leaving them for a later time.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 20 +++
total instructions in shared programs: 5959463 -> 5958900 (-0.01%)
instructions in affected programs: 70031 -> 69468 (-0.80%)
---
.../drivers/dri/i965/brw_fs_cmod_propagation.cpp | 16 +++--
.../drivers/dri/i965/test_fs_cmod_propagation.cpp | 41 ++
2 files changed,
For some reason, we occasionally write the flag register with a MOV.NZ
instruction:
add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F
cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F
mov.nz.f0(8)nullg26<8,8,1>D
A MOV.NZ instruction on the result of a CMP is li
total instructions in shared programs: 5952059 -> 5951603 (-0.01%)
instructions in affected programs: 138812 -> 138356 (-0.33%)
GAINED:1
LOST: 0
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
src/mesa/drivers/dri/i
---
src/mesa/drivers/dri/i965/Makefile.am | 7 +
.../drivers/dri/i965/test_fs_cmod_propagation.cpp | 271 +
2 files changed, 278 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
diff --git a/src/mesa/drivers/dri/i965/Make
3-src instructions can only have GRF/MRF destinations. It's really
difficult to deal with that restriction in dead code elimination (that
wants to give instructions null destinations to show that their result
isn't used) while allowing 3-src instructions to have conditional mod,
so don't, and just
This allows us to apply the optimization in cases where the CMP's
argument is negated, by flipping the conditional mod. For example, it
allows us to optimize this:
add(8) temp a b
cmp.l.f0(8) null -temp 0.0
into
add.ge.f0(8) temp a b
total instructions in shared
---
src/mesa/drivers/dri/i965/brw_shader.cpp| 10 ++
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 6 +-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i96
Now that we properly track accumulator dependencies, the scheduler is
able to schedule instructions between the mach and mov in the common
the integer multiplication pattern:
mul acc0, x, y
mach null, x, y
mov dest, acc0
Since a null destination implies no dependency on the destination
---
src/mesa/drivers/dri/i965/brw_cfg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 3b1bd16..0b60fec 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -297,6 +297
---
src/mesa/drivers/dri/i965/brw_cfg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 48bca9f..3b1bd16 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -314,6 +314
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 45
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
2 files changed, 46 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index d76134b..cbdf976 100644
--
---
src/mesa/drivers/dri/i965/brw_eu.c | 22 ++
src/mesa/drivers/dri/i965/brw_eu.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.c
b/src/mesa/drivers/dri/i965/brw_eu.c
index 9905972..9977eed 100644
--- a/src/mesa/drivers/dri/i965/brw_
---
src/glsl/list.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 330c17e..85368a4 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -636,6 +636,12 @@ inline void exec_node::insert_before(exec_list *before)
__next != NULL;
Oops, dropped cc.
On Jan 19, 2015 3:15 PM, "Ilia Mirkin" wrote:
> Nope, that's for something else. This has to do with whether gl fragcoord
> is at the integer or half integer coord. The other is a rasterizer setting.
> On Jan 19, 2015 3:06 PM, "Tiziano Bacocco" wrote:
>
>> On the commit
>> http
From: José Fonseca
The dri2_x11_add_configs_for_visuals() function happily matches a 32
bits EGLconfig with a 24 bits X visual. However it was passing 32bits
depth to xcb_put_image(), making X server unhappy:
https://github.com/apitrace/apitrace/issues/313#issuecomment-70571911
PS: I rarely
On the commit
http://cgit.freedesktop.org/mesa/mesa/commit/?id=aafd13027a38d5a2ab5d80019b282b8233c15a8a
, the part where the supported caps are added was missing
nv50,nvc0: Report correct caps for pixel center integer
Signed-off-by: Tiziano Bacocco
diff --git a/src/gallium/drivers/nouve
Reviewed-by: Marek Olšák
For the next time: It's customary to include "(v2)" on the first line
of the commit message and "v2: ... explanation" before the sign-off.
Marek
On Mon, Jan 19, 2015 at 11:17 PM, Axel Davy wrote:
> Resolving a multisampled depth texture into
> a single sampled texture
On 19/01/2015 23:23, Ilia Mirkin wrote :
On Mon, Jan 19, 2015 at 5:17 PM, Axel Davy wrote:
Resolving a multisampled depth texture into
a single sampled texture is supported on >= SM4.1
hw. It is possible some previous hw support it.
The ability was tested on radeonsi and nvc0.
I'm not aware o
On Mon, Jan 19, 2015 at 5:17 PM, Axel Davy wrote:
> Resolving a multisampled depth texture into
> a single sampled texture is supported on >= SM4.1
> hw. It is possible some previous hw support it.
>
> The ability was tested on radeonsi and nvc0.
I'm not aware of any issues in this regard on nv50
Resolving a multisampled depth texture into
a single sampled texture is supported on >= SM4.1
hw. It is possible some previous hw support it.
The ability was tested on radeonsi and nvc0.
Apparently is is also supported for radeon >= r700.
This patch adds the MULTISAMPLE_Z_RESOLVE cap and
adds it
Reviewed-by: Matt Turner
I'll commit this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I've got some specific comments below, but I want to make some more general
comments here. I like this in principle: having all the opcodes
self-documenting is wonderful. However, I'm not terribly happy with the
way it worked out. A lot of the codegen stuff is very confusing and its
not at all o
In general, I think I like this. The CPP was fine and I in general prefer
it when practical but this is probably justified in light of the constant
folding stuff. Good work on making of look very similar to the old
nir_opcodes.h. Only 1 comment below.
On Jan 16, 2015 3:46 PM, "Connor Abbott" w
https://bugs.freedesktop.org/show_bug.cgi?id=87886
--- Comment #18 from Stéphane Travostino ---
OK from further experiments this bug does NOT ONLY affect Source games, but any
3d/OpenGL application.
I've experienced the same issue with varying degrees of severity also on:
- Sauerbraten: average
https://bugs.freedesktop.org/show_bug.cgi?id=87886
Stéphane Travostino changed:
What|Removed |Added
Summary|constant fps drops with |constant fps drops with
Mac OS X XQuartz places X11 headers at /opt/X11/include.
This patch fixes this Mac OS X SCons build error.
Compiling src/gallium/state_trackers/glx/xlib/glx_api.c ...
In file included from src/gallium/state_trackers/glx/xlib/glx_api.c:34:
include/GL/glx.h:30:10: fatal error: 'X11/Xlib.h' file n
This fixes two problems reported by osc:
I: Program returns random data in a function
E: Mesa no-return-in-nonvoid-function ../../src/mesa/main/format_utils.c:180
E: Mesa no-return-in-nonvoid-function ../../src/mesa/main/glformats.c:2714
Signed-off-by: Tobias Klausmann
---
src/mesa/main/format_u
On 19.01.2015 19:54, Matt Turner wrote:
On Thu, Jan 15, 2015 at 10:26 AM, Tobias Klausmann
wrote:
I: Program returns random data in a function E: Mesa
no-return-in-nonvoid-function ../../src/mesa/main/format_utils.c:180
E: Mesa no-return-in-nonvoid-function
../../src/mesa/main/glformats.c:271
While previous code was having the correct behaviour in general,
this new code is more readable (without checking all gallium formats
manually) and has a more defined behaviour for depth stencil resources.
Reviewed-by: Tiziano Bacocco
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
Cc: "
On Sat, Jan 17, 2015 at 11:21 PM, Kenneth Graunke wrote:
> Gen4 hardware appears to GPU hang frequently when using Chromium, and
> also when running 'glmark2 -b ideas'. Most of the error states contain
> 3DPRIMITIVE commands in quick succession, with very few state packets
> between them - usuall
https://bugs.freedesktop.org/show_bug.cgi?id=88519
--- Comment #5 from Carl Worth ---
(In reply to Matt Turner from comment #4)
> Just a note: when you change the assignee make sure mesa-dev@ stays as the
> QA contact or in the Cc list. Otherwise we stop seeing updates to the bug.
Thanks for the
https://bugs.freedesktop.org/show_bug.cgi?id=88523
Carl Worth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=88523
--- Comment #5 from Carl Worth ---
commit 3b8ccca8a3b5e03829fba7cdb57b49fc10917954
Author: Carl Worth
Date: Mon Jan 19 10:49:41 2015 -0800
Rename sha1.c and sha1.h to mesa-sha1.c and mesa-sha1.h
The filename of sha1.h was conflicting
On Thu, Jan 15, 2015 at 10:26 AM, Tobias Klausmann
wrote:
> I: Program returns random data in a function
> E: Mesa no-return-in-nonvoid-function ../../src/mesa/main/format_utils.c:180
> E: Mesa no-return-in-nonvoid-function ../../src/mesa/main/glformats.c:2714
> ---
> src/mesa/main/format_utils.c
On 16.01.2015 15:05, Jan Vesely wrote:
On Thu, 2015-01-15 at 20:49 +0100, Tobias Klausmann wrote:
On 15.01.2015 19:35, Jan Vesely wrote:
On Thu, 2015-01-15 at 19:26 +0100, Tobias Klausmann wrote:
I: Program returns random data in a function E: Mesa
no-return-in-nonvoid-function
../../src/me
Ok a cap bit sounds reasonable then I guess.
Roland
Am 19.01.2015 um 16:41 schrieb Marek Olšák:
> Yes, but it's only supported on r700 and later. This is one of the
> things in OpenGL that a lot of hardware (r3xx-r6xx) cannot do.
> r300-r500 really doesn't support it. R6xx was designed to support
Yes, but it's only supported on r700 and later. This is one of the
things in OpenGL that a lot of hardware (r3xx-r6xx) cannot do.
r300-r500 really doesn't support it. R6xx was designed to support it,
but it doesn't work due to hw bugs.
Marek
On Mon, Jan 19, 2015 at 4:31 PM, Roland Scheidegger wr
Ah ok makes more sense that way. This is not really something I'd call
"resolve" though. (And isn't it already assumed drivers can do the
blitting of such buffers already for glBlitFramebuffer?)
Roland
Am 19.01.2015 um 16:10 schrieb Marek Olšák:
> BTW, this is the same as the glBlitFramebuffer be
Aside from a typo in a comment, this looks good to me (though I'm not
all that familiar with glsl code).
Roand
Am 19.01.2015 um 12:32 schrieb Eduardo Lima Mitev:
> From: Iago Toral Quiroga
>
> Currently, Mesa uses the lowering pass MOD_TO_FRACT to implement
> mod(x,y) as y * fract(x/y). This im
Am 12.01.2015 16:00, schrieb Marek Olšák:
From: Marek Olšák
This should fix this performance regression:
https://bugs.freedesktop.org/show_bug.cgi?id=88227
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/wins
BTW, this is the same as the glBlitFramebuffer behavior for MSAA depth buffers.
Marek
On Mon, Jan 19, 2015 at 2:18 PM, Axel Davy wrote:
> On 19/01/2015 11:59, Roland Scheidegger wrote :
>>
>> I always thought you can't resolve z because such an operation just
>> makes no sense at all. What the h
1) It's quite a lot of CPU work, so it shouldn't be done
unconditionally. Please see how si_pm4_state_changed is used to check
if a "shader variant" has been changed. I'd like to have an early exit
path for performance reasons, so:
a) If no shader state has been changed (see si_pm4_state_changed),
On Mon, Jan 19, 2015 at 11:00:40AM +, Chris Wilson wrote:
> @@ -1104,6 +1107,8 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
> CARD64 target_msc,
> * it as early as possible, just to be sure.
> */
> *swap_target = pPriv->swap_count + pPriv->swapsPending + 1;
> +i
On 19/01/2015 11:59, Roland Scheidegger wrote :
I always thought you can't resolve z because such an operation just
makes no sense at all. What the hell does it even mean and how do you do
it? Color resolve you just interpolate between the value to get rid of
the aliased edges. But in the depth b
Am 17.01.2015 um 14:44 schrieb Axel Davy:
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 6c5703a..351f3c2 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -573,6 +573,7 @@ enum pipe_cap {
>
On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> So far we have only been emitting a warning.
>
> Fixes the following 2 dEQP tests:
> dEQP-GLES3.functional.shaders.arrays.invalid.empty_declaration_without_var_name_vertex
> dEQP-GLES3.functional.shaders.ar
On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> Fixes the following 2 dEQP tests:
> dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_vertex
> dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_fragment
> ---
> src
On Mon, Jan 19, 2015 at 1:31 PM, Erik Faye-Lund wrote:
> On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
>> The manual page for glGetAttachedShaders, glGetShaderSource,
>> glGetActiveUniform and
>> glGetActiveUniform state that a GL_INVALID_VALUE is returned if the maximum
>> length
On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
> The manual page for glGetAttachedShaders, glGetShaderSource,
> glGetActiveUniform and
> glGetActiveUniform state that a GL_INVALID_VALUE is returned if the maximum
> length
> argument is less than zero. For reference, see:
> https://w
From: Iago Toral Quiroga
Fixes the following 2 dEQP tests:
dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_vertex
dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_fragment
---
src/glsl/glsl_parser.yy | 7 +++
1 file changed, 7 insertions(+)
diff --
GLES 3.0.0 spec introduces context state PRIMITIVE_RESTART_FIXED_INDEX
(2.8.1 Transferring Array Elements, page 26) which is not currently
possible to query using glGet*() funcs.
Fixes 4 dEQP tests:
*
dEQP-GLES3.functional.state_query.boolean.primitive_restart_fixed_index_getboolean
*
dEQP-GLES3
From: Iago Toral Quiroga
Fixes the following 2 dEQP tests:
dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_in_main_vertex
dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_in_main_fragment
---
src/glsl/ast_to_hir.cpp | 8
1 file
From: Samuel Iglesias Gonsalvez
Section 6.1.13 "Framebuffer Object Queries" of OpenGL ES 3.0 spec:
"If the default framebuffer is bound to target, then attachment must be
BACK, identifying the color buffer; DEPTH, identifying the depth buffer; or
STENCIL, identifying the stencil buffer."
B
From: Iago Toral Quiroga
So far we have only been emitting a warning.
Fixes the following 2 dEQP tests:
dEQP-GLES3.functional.shaders.arrays.invalid.empty_declaration_without_var_name_vertex
dEQP-GLES3.functional.shaders.arrays.invalid.empty_declaration_without_var_name_fragment
---
src/glsl/as
From: Iago Toral Quiroga
Currently, Mesa uses the lowering pass MOD_TO_FRACT to implement
mod(x,y) as y * fract(x/y). This implementation has a down side though:
it introduces precision errors due to the fract() operation. Even worse,
since the result of fract() is multiplied by y, the larger y g
The specification states that glTexImage2D and glTexImage3D should return
GL_INVALID_VALUE if the internal format is invalid, and GL_INVALID_ENUM is
the format type is invalid. However, current error check only considers the
combination of format, type and internal format; which returns a
GL_INVALI
From: Iago Toral Quiroga
Fixes the following 2 dEQP tests:
dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_const_vertex
dEQP-GLES3.functional.shaders.declarations.invalid_declarations.uniform_block_const_fragment
---
src/glsl/ast_to_hir.cpp | 7 +++
1 file chang
From: Iago Toral Quiroga
For code such as:
uint tmp1 = uint(in0);
uint tmp2 = -tmp1;
float out0 = float(tmp2);
We produce code like:
mov(8)g5<1>.xF-g9<4,4,1>.xUD
which does not produce correct results. This code produces the
results we would expect if tmp1 and tmp2 were signed integers
Hello,
Here goes another batch of fixes for dEQP failing tests. It fixes a total of 47
test cases.
The test failures were gathered on i965 (gen8) against 10.4.2, but there are
driver and version agnostic fixes.
A GIT tree with these patches based on git-d74a8 is available at:
https://github.co
The manual page for glGetAttachedShaders, glGetShaderSource, glGetActiveUniform
and
glGetActiveUniform state that a GL_INVALID_VALUE is returned if the maximum
length
argument is less than zero. For reference, see:
https://www.opengl.org/sdk/docs/man3/xhtml/glGetAttachedShaders.xml,
https://www.k
From: Iago Toral Quiroga
Currently, we only consider precision qualifiers at compile-time. This patch
adds precision information to ir_variable so we can also do link time checks.
Specifically, from the GLSL ES3 spec, 4.5.3 Precision Qualifiers:
"The same uniform declared in different shaders th
Available since the inclusion of dri2proto 1.4 is a DRI2 request to
query and set certain parameters about the X/DDX configuration. This
implements the getter request.
Signed-off-by: Chris Wilson
---
src/glx/dri2.c | 29 +
src/glx/dri2.h | 4
2 files changed, 33
As the SBC from the reply from SwapBuffers is not used immediately and
can be easily determined by counting the new of SwapBuffers requests
made by the client, we can defer the synchronisation point to the
pending GetBuffers round trip. (We force the invalidation event in order
to require the GetBu
For BufferAge support, we just have to guarrantee that we were not using
the DRI2Buffer->flags field for anything else (i.e. it is always 0) and
then to make sure that we exchange the flags field after buffer
exchanges. radeon does not support TripleBuffering so we do not have to
worry about perser
Since the introduction of DRI2GetBuffersWithFormat, the old
DRI2GetBuffers interface would always recreate all buffers all the time
as it was no longer agnostic to the format value being set by the DDXes.
This causes an issue with clients intermixing the two requests,
rendering any sharing or cachi
In order for X/DDX to reuse a driver specific field of the DRI2GetBuffers
reply, we need to declare the change in semantics. To indicate that the
flags field now continues the last swap buffers count instead, we
introduce the has-buffer-age parameter.
Signed-off-by: Chris Wilson
---
configure.ac
For enable BufferAge support, we just have to be not using the
DRI2Buffer->flags field for any purpose (i.e. it is always expected to
be 0, as it is now) and to be sure to swap the flags field whenever we
exchange buffers. As nouveau does not exactly support TripleBuffer, we
don't have to worry abo
Allow mesa/dri2 to implement GLX_EXT_buffer_age by reporting the sbc of
when the current back buffer was defined. As this may require ddx
support, only set the value if enabled by the ddx and report the new
semantics via a DRI2GetParam request.
Signed-off-by: Chris Wilson
---
configure.ac
Within the DRI2GetBuffers return packet there is a 4-byte field that is
currently unused by any driver, i.e. flags. With the co-operation of a
suitably modified X server, we can pass the last SBC on which the buffer
was defined (i.e. the last SwapBuffers for which it was used) and 0 if
it is fresh
In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the
last swap buffer count that the back buffer was defined for. For
simplicity, we can reuse an existing field in the DRI2GetBuffers reply
that is not used by current drivers, the flags. Since we change the
interpretation of this
Allow the DDXes to opt-in and handle swap-interval=0 requests for
themselves, for example by using asynchronous pageflips, rather than
forcing a blit. This has the important side-effect of also
disambiguating CopyRegion calls to always be client requests.
References: http://lists.x.org/archives/xo
I always thought you can't resolve z because such an operation just
makes no sense at all. What the hell does it even mean and how do you do
it? Color resolve you just interpolate between the value to get rid of
the aliased edges. But in the depth buffer, these values represent the
depth informatio
On 19/01/15 11:25, Kenneth Graunke wrote:
On Monday, January 19, 2015 10:52:05 AM Martin Peres wrote:
Signed-off-by: Martin Peres
---
src/mesa/main/feedback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/feedback.c b/src/mesa/main/feedback.c
index 9ea0b9
On Monday, January 19, 2015 10:52:05 AM Martin Peres wrote:
> Signed-off-by: Martin Peres
> ---
> src/mesa/main/feedback.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/feedback.c b/src/mesa/main/feedback.c
> index 9ea0b92..6bc4294 100644
> --- a/src/mesa
On Monday, January 19, 2015 11:06:44 AM Eero Tamminen wrote:
> Hi,
>
> On 01/16/2015 11:43 PM, Kenneth Graunke wrote:
> > On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote:
> >> On Jan 15, 2015 12:27 AM, "Eero Tamminen"
> >> wrote:
> ...
> >>> Any ideas how the loop unrolling could
Hi,
On 01/16/2015 11:43 PM, Kenneth Graunke wrote:
On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote:
On Jan 15, 2015 12:27 AM, "Eero Tamminen" wrote:
...
Any ideas how the loop unrolling could be reliably be taken into account
automatically in these statistics?
Maybe with so
On 19/01/15 10:52, Martin Peres wrote:
Signed-off-by: Martin Peres
---
src/mesa/main/feedback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/feedback.c b/src/mesa/main/feedback.c
index 9ea0b92..6bc4294 100644
--- a/src/mesa/main/feedback.c
+++ b/src/mesa/m
1 - 100 of 102 matches
Mail list logo
