Suggested by Jason Ekstrand.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_opt_peephole_select.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/glsl/nir/nir_opt_peephole_select.c
b/src/glsl/nir/nir_opt_peephole_select.c
index ef7c977..6620e
On Tuesday 23 June 2015 21:17:23 Timothy Arceri wrote:
> ---
> src/gallium/drivers/freedreno/freedreno_screen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c index b3b5
https://bugs.freedesktop.org/show_bug.cgi?id=90797
wendy.w...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #11 from wend
On 23/06/15 17:30, Brian Paul wrote:
This caused us to always free the pipe_surface for the renderbuffer.
The subsequent call to st_update_renderbuffer_surface() would typically
just recreate it. Remove the call to pipe_surface_release() and let
st_update_renderbuffer_surface() take care of free
I would capitalize the hex strings, to match the rest of the file.
with that,
Reviewed-by: Mark Janes
Ben Widawsky writes:
> These match the ones defined in the kernel. The only one tested by us is
> 0x0a84.
>
> Signed-off-by: Ben Widawsky
> ---
> include/pci_ids/i965_pci_ids.h | 3 +++
>
On 24 June 2015 at 12:57, Michel Dänzer wrote:
> On 24.06.2015 11:39, Dave Airlie wrote:
>>>
>>> Actually, I'm almost 100% certain that there are lots of other strict
>>> aliasing violations in the Mesa code. That's why we've always disabled it.
>>>
>>> More generally, IMO it's unrealistic to rely
Hi. Feel free to Cc me on patches of this nature. I am far behind on mesa-dev,
and no longer read intel-gfx. I'm probably one of the sensible people to look at
this...
On Tue, Jun 23, 2015 at 01:21:27PM +0100, Michel Thierry wrote:
> Gen8+ supports 48-bit virtual addresses, but some objects must a
On Tue, Jun 23, 2015 at 7:57 PM, Michel Dänzer wrote:
> On 24.06.2015 11:39, Dave Airlie wrote:
>>>
>>> Actually, I'm almost 100% certain that there are lots of other strict
>>> aliasing violations in the Mesa code. That's why we've always disabled it.
>>>
>>> More generally, IMO it's unrealistic
On 24.06.2015 11:39, Dave Airlie wrote:
>>
>> Actually, I'm almost 100% certain that there are lots of other strict
>> aliasing violations in the Mesa code. That's why we've always disabled it.
>>
>> More generally, IMO it's unrealistic to rely on strict aliasing for
>> optimization, because very f
On Tue, Jun 23, 2015 at 6:44 PM, Ian Romanick wrote:
> Please quote the spec.
Section 6.5 Expressions of the draft C99 spec I have says (page 68, 80
of the pdf):
7 An object shall have its stored value accessed only by an lvalue
expression that has one of the following types: 76)
— a type compa
>> And do things with p2 and hope that p will get them, because
>> the compiler wants to store things its doing to p in registers,
>> and when you go and do something in p2 it can't work out it's the
>> same thing, so it has to spill/reload.
>
> Which I think is different from what Davin was saying
On 06/23/2015 04:56 PM, Brian Paul wrote:
On 06/23/2015 04:25 PM, Matt Turner wrote:
On Tue, Jun 23, 2015 at 3:04 PM, Brian Paul wrote:
Otherwise, if we're trying to build a 32-bit Mesa on a 64-bit host
we wind up with -DUSE_X86_64_ASM, which is incorrect.
---
configure.ac | 2 +-
1 file ch
>
> Actually, I'm almost 100% certain that there are lots of other strict
> aliasing violations in the Mesa code. That's why we've always disabled it.
>
> More generally, IMO it's unrealistic to rely on strict aliasing for
> optimization, because very few people really understand it (I'm not one
>
On 06/23/2015 07:01 PM, Dave Airlie wrote:
> On 24 June 2015 at 11:44, Ian Romanick wrote:
>> On 06/24/2015 03:59 PM, Davin McCall wrote:
>>> Hi Ian,
>>>
>>> On 23/06/15 23:26, Ian Romanick wrote:
On 06/23/2015 02:36 PM, Thomas Helland wrote:
> 2015-06-24 23:05 GMT+02:00 Davin McCall :
>>
On 24 June 2015 at 11:44, Ian Romanick wrote:
> On 06/24/2015 03:59 PM, Davin McCall wrote:
>> Hi Ian,
>>
>> On 23/06/15 23:26, Ian Romanick wrote:
>>> On 06/23/2015 02:36 PM, Thomas Helland wrote:
2015-06-24 23:05 GMT+02:00 Davin McCall :
> Hi - I'm new here.
>
> I've recently st
On Tue, Jun 23, 2015 at 08:18:45PM -0400, Rob Clark wrote:
> On Tue, Jun 23, 2015 at 7:27 PM, Dylan Baker wrote:
> > I have a couple of python pointers for you, feel free to take them or
> > leave them.
>
> cool, thanks..
>
> What do others think about including shadertoy in shader-db? If it is
On 06/24/2015 03:59 PM, Davin McCall wrote:
> Hi Ian,
>
> On 23/06/15 23:26, Ian Romanick wrote:
>> On 06/23/2015 02:36 PM, Thomas Helland wrote:
>>> 2015-06-24 23:05 GMT+02:00 Davin McCall :
Hi - I'm new here.
I've recently started poking the Mesa codebase for little reason other t
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Intruction State Heap (ISH) must be in a
32-bit range, because the General State
On 24.06.2015 06:35, Matt Turner wrote:
> On Wed, Jun 24, 2015 at 2:05 PM, Davin McCall wrote:
>
>> I've recently started poking the Mesa codebase for little reason other than
>> personal interest. In the "help wanted" section of the website it mentions
>> aliasing violations as a target for newc
On Tue, Jun 23, 2015 at 7:27 PM, Dylan Baker wrote:
> I have a couple of python pointers for you, feel free to take them or
> leave them.
cool, thanks..
What do others think about including shadertoy in shader-db? If it is
a useful thing, I'll clean up my script and re-submit..
And if we inclu
I have a couple of python pointers for you, feel free to take them or
leave them.
Dylan
On Tue, Jun 16, 2015 at 03:46:50PM -0400, Rob Clark wrote:
> Attached script grabs shaders from shadertoy, and dumps them out as
> .shader_test files which can be run through shader-db for compiler
> testing.
Hi Ian,
On 23/06/15 23:26, Ian Romanick wrote:
On 06/23/2015 02:36 PM, Thomas Helland wrote:
2015-06-24 23:05 GMT+02:00 Davin McCall :
Hi - I'm new here.
I've recently started poking the Mesa codebase for little reason other than
personal interest. In the "help wanted" section of the website
On 06/23/2015 04:25 PM, Matt Turner wrote:
On Tue, Jun 23, 2015 at 3:04 PM, Brian Paul wrote:
Otherwise, if we're trying to build a 32-bit Mesa on a 64-bit host
we wind up with -DUSE_X86_64_ASM, which is incorrect.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Reviewed-by: Jordan Justen
On 2015-06-23 15:40:00, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.c
Reviewed-by: Marek Olšák
Marek
On Tue, Jun 23, 2015 at 6:30 PM, Brian Paul wrote:
> This caused us to always free the pipe_surface for the renderbuffer.
> The subsequent call to st_update_renderbuffer_surface() would typically
> just recreate it. Remove the call to pipe_surface_release() and l
On 2015-06-22 23:38:14, Iago Toral wrote:
> On Mon, 2015-06-22 at 14:28 -0700, Jordan Justen wrote:
> > 24-26 once again makes me wonder if these optimization *can* be used
> > with SSBOs based on the same ext spec wording I referenced before:
> >
> > "The ability to write to buffer objects create
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index ea29341..9a4bad6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++
On 06/23/2015 02:36 PM, Thomas Helland wrote:
> 2015-06-24 23:05 GMT+02:00 Davin McCall :
>> Hi - I'm new here.
>>
>> I've recently started poking the Mesa codebase for little reason other than
>> personal interest. In the "help wanted" section of the website it mentions
>> aliasing violations as a
Hi Ilia (and Matt and Thomas)
On 23/06/15 22:30, Ilia Mirkin wrote:
The biggest part of the process is to send a proper commit to the
mailing list. There are two issues with your mailing (without
commenting on your actual changes) --
(a) The patch is attached, not inlined
(b) You sent a diff, n
On Tue, Jun 23, 2015 at 3:04 PM, Brian Paul wrote:
> Otherwise, if we're trying to build a 32-bit Mesa on a 64-bit host
> we wind up with -DUSE_X86_64_ASM, which is incorrect.
> ---
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
Otherwise, if we're trying to build a 32-bit Mesa on a 64-bit host
we wind up with -DUSE_X86_64_ASM, which is incorrect.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ddc757e..b12f5f9 100644
--- a/configure.ac
+++ b/configure
https://bugs.freedesktop.org/show_bug.cgi?id=91077
--- Comment #3 from Julien Isorce ---
Hi, I just sent a patch on the mailing list as I encountered the same problem
on darwin.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Fixes:
CCLD libGL.la
./.libs/libglx.a(dri2_glx.o): In function `dri2CreateScreen':
src/glx/dri2_glx.c:1186: undefined reference to `loader_open_device'
collect2: ld returned 1 exit status
CCLD libEGL.la
Undefined symbols for architecture x86_64:
"_loader_open_device", referenced from:
_dr
On Tue, Jun 23, 2015 at 01:23:05PM -0700, Anuj Phogat wrote:
> In case of I915_TILING_{X,Y} we need to pass tiling format to libdrm
> using drm_intel_bo_alloc_tiled(). But, In case of YF/YS tiled buffers
> libdrm need not know about the tiling format because these buffers
> don't have hardware supp
2015-06-24 23:05 GMT+02:00 Davin McCall :
> Hi - I'm new here.
>
> I've recently started poking the Mesa codebase for little reason other than
> personal interest. In the "help wanted" section of the website it mentions
> aliasing violations as a target for newcomers to fix, so with that in mind
>
On Wed, Jun 24, 2015 at 2:05 PM, Davin McCall wrote:
> Hi - I'm new here.
Welcome!
> I've recently started poking the Mesa codebase for little reason other than
> personal interest. In the "help wanted" section of the website it mentions
> aliasing violations as a target for newcomers to fix, so
On Wed, Jun 24, 2015 at 5:05 PM, Davin McCall wrote:
> Hi - I'm new here.
>
> I've recently started poking the Mesa codebase for little reason other than
> personal interest. In the "help wanted" section of the website it mentions
> aliasing violations as a target for newcomers to fix, so with tha
https://bugs.freedesktop.org/show_bug.cgi?id=91077
--- Comment #2 from Vinson Lee ---
Clean checkout and build on CentOS 6.
$ ./autogen.sh --disable-dri3 --enable-sysfs --with-dri-drivers=swrast
--with-gallium-drivers=
$ make
[...]
CC XF86dri.lo
dri_common.c: In function ‘dri2_convert_glx_
On Tue, Jun 23, 2015 at 4:30 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/get_hash_params.py | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/main/get_hash_params.py
> b/src/mesa/main/get_hash_
Hi - I'm new here.
I've recently started poking the Mesa codebase for little reason other
than personal interest. In the "help wanted" section of the website it
mentions aliasing violations as a target for newcomers to fix, so with
that in mind I've attached a patch (against git head) which re
On Tue, Jun 23, 2015 at 7:20 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> GL_ARB_compute_shader is limited for GLSL version 430.
> This enables for GLSL ES version 310.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/glsl/builtin_variables.cpp | 2 +-
> src/glsl/glsl_parser.yy| 3
I don't really think the "/es3.1" in the commit summary adds anything.
With that removed:
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jun 23, 2015 at 4:03 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> When a program is compiled, but linking failed the
> sh->InfoLog could be NULL. This is expoloited
> by OpenGL ES 3.1 conformance tests.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/shaderapi.c | 4 ++--
On Tue, Jun 23, 2015 at 4:03 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> When a program is compiled, but linking failed the
> sh->InfoLog could be NULL. This is expoloited
> by OpenGL ES 3.1 conformance tests.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/shaderapi.c | 4 ++--
On Tue, Jun 23, 2015 at 5:23 AM, Marta Lofstedt
wrote:
> This is a series of patches that solves a couple of
> API check and corner cases issues that the OpenGL ES 3.1
> CTS exploits.
>
> Marta Lofstedt (6):
> mesa/es3.1: Do not allow zero size multisampled textures
> mesa/es3.1: Correct error
On Tue, Jun 23, 2015 at 5:23 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to GLES 3.1 CTS test:
> ES31-CTS.texture_storage_multisample.
> APIGLGetTexLevelParameterifv.
> invalid_texture_target_rejected:
>
> GL_INVALID_ENUM should be generated when
> glGetTexLevelParameteriv is c
I should have also mentioned -- the commit titles need some
improvement. "Fix error code" isn't very descriptive of the change,
and the change isn't actually specific to es3.1. How about
> mesa: Raise INVALID_VALUE from glCreateShaderProgramv if count < 0.
_
On Tue, Jun 23, 2015 at 5:23 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to the OpenGL ES standard, 7.3.
> For a call to glCreateShaderProgram with count < 0,
> a GL_INVALID_VALUE error should be generated.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/shaderapi.c |
In case of I915_TILING_{X,Y} we need to pass tiling format to libdrm
using drm_intel_bo_alloc_tiled(). But, In case of YF/YS tiled buffers
libdrm need not know about the tiling format because these buffers
don't have hardware support to be tiled or detiled through a fenced
region. libdrm still need
Reviewed-by: Ilia Mirkin
On Tue, Jun 23, 2015 at 2:04 PM, Eric Anholt wrote:
> Noticed while trying to add GL_ARB_texture_multisample support to vc4.
> ---
> src/gallium/auxiliary/nir/tgsi_to_nir.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/galliu
https://bugs.freedesktop.org/show_bug.cgi?id=91077
--- Comment #1 from Derek Foreman ---
What configure options are you using?
Can you attach a build log?
Do you have any local changes?
Having a hard time figuring this out, I can't reproduce it here, and dri2_glx.c
uses other functions from lo
https://bugs.freedesktop.org/show_bug.cgi?id=91077
Bug ID: 91077
Summary: dri2_glx.c:1186: undefined reference to
`loader_open_device'
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Tue, Jun 23, 2015 at 1:39 AM, Pohjolainen, Topi
wrote:
> On Thu, Jun 18, 2015 at 05:51:36PM -0700, Jason Ekstrand wrote:
>> We want to move these into the builder so that they know the current
>> builder's dispatch width. This will be needed by a later commit.
>> ---
>> src/mesa/drivers/dri/i
On Tue, Jun 23, 2015 at 9:22 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> We want to move these into the builder so that they know the current
>> builder's dispatch width. This will be needed by a later commit.
>
> I very much like the idea of this series, but, why do you need to mov
Noticed while trying to add GL_ARB_texture_multisample support to vc4.
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 061f39a..065
On Monday, June 22, 2015 06:07:20 PM Jason Ekstrand wrote:
> I started working on this project some time ago to remove brw_context from
> the backend compiler. I got a bunch of refactoring done but eventualy got
> stuck up on shader_time and some debug logging stuff. I've finally gotten
> around
On Wed, Jun 3, 2015 at 9:35 PM, Ben Widawsky
wrote:
> While implementing the workaround in the previous patch I noticed things were
> starting to get a bit messy. Since gen8 works differently enough from gen7, I
> thought splitting it out with be good.
>
> While here, get rid of gen8 MOCS which do
https://bugs.freedesktop.org/show_bug.cgi?id=90797
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Monday, June 22, 2015 06:07:29 PM Jason Ekstrand wrote:
> This creates the options at screen cration time and then we just copy them
> into the context at context creation time. We also move is_scalar to the
> brw_compiler structure.
>
> We also end up manually setting some values that the cor
On Monday, June 22, 2015 06:07:25 PM Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 10 +-
> src/mesa/drivers/dri/i965/intel_debug.c | 13 ++---
> src/mesa/drivers/dri/i965/intel_debug.h | 4 ++--
> src/mesa/drivers/dri/i965/intel_screen.c | 2 ++
> 4
https://bugs.freedesktop.org/show_bug.cgi?id=91044
--- Comment #4 from Emil Velikov ---
Got confused there thinking that you're with Intel, sorry about that Boyan.
As expected we're missing the v15 update of the spec in our libEGL. I will try
to find some time and dig through the spec history la
On Tue 23 Jun 2015, Ilia Mirkin wrote:
> On Tue, Jun 23, 2015 at 12:05 PM, Chad Versace wrote:
> > On Fri 19 Jun 2015, Emil Velikov wrote:
> >> Cc: "10.5 10.6"
> >> Suggested-by: Ilia Mirkin
> >> Signed-off-by: Emil Velikov
> >
> >
> >> -urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug'
This caused us to always free the pipe_surface for the renderbuffer.
The subsequent call to st_update_renderbuffer_surface() would typically
just recreate it. Remove the call to pipe_surface_release() and let
st_update_renderbuffer_surface() take care of freeing the old surface
if it needs to be r
Jason Ekstrand writes:
> We want to move these into the builder so that they know the current
> builder's dispatch width. This will be needed by a later commit.
I very much like the idea of this series, but, why do you need to move
these register manipulators into the builder? The builder is a
On Tue, Jun 23, 2015 at 12:05 PM, Chad Versace wrote:
> On Fri 19 Jun 2015, Emil Velikov wrote:
>> Cc: "10.5 10.6"
>> Suggested-by: Ilia Mirkin
>> Signed-off-by: Emil Velikov
>
>
>> -urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e
>> $trim_before -e $trim_after -e $use_https
On Fri 19 Jun 2015, Emil Velikov wrote:
> Cc: "10.5 10.6"
> Suggested-by: Ilia Mirkin
> Signed-off-by: Emil Velikov
> -urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e
> $trim_before -e $trim_after -e $use_https | sort | uniq)
> +urls=$(git log $* | grep 'bugs.freedesktop.org
On 23/06/15 15:36, Jose Fonseca wrote:
On 22/06/15 17:14, Ian Romanick wrote:
On 06/19/2015 06:08 AM, Jose Fonseca wrote:
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input vary
On Thu, 2015-06-18 at 17:51 -0700, Jason Ekstrand wrote:
> We want to move these into the builder so that they know the current
> builder's dispatch width. This will be needed by a later commit.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 52 ++
> src/mesa/drivers/dri/i965/brw
On 22/06/15 17:14, Ian Romanick wrote:
On 06/19/2015 06:08 AM, Jose Fonseca wrote:
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input varyings for stages other than the fragment
From: Marta Lofstedt
According to the OpenGL ES standard, 7.3.
For a call to glCreateShaderProgram with count < 0,
a GL_INVALID_VALUE error should be generated.
Signed-off-by: Marta Lofstedt
---
src/mesa/main/shaderapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/mai
On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to the OpenGL ES standard, 7.3.
> For a call to glCreateShaderProgram with count < 0,
> a GL_INVALID_VALUE error should be generated.
>
OpenGL 4.5 defines it the same way.
On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Accoring to GLES 3.1 CTS:
> GLES 3.1 CTS: ES31-CTS.shader_atomic_counters.
> basic-buffer-bind.
>
> AtomicBufferBindings size and start should be initialized
> to zero.
>
OpenGL 3.1 says:
"Buffer variables in shad
On Tue, Jun 23, 2015 at 3:39 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Signed-off-by: Marta Lofstedt
> ---
> src/glsl/builtin_functions.cpp | 3 +--
> src/glsl/builtin_types.cpp | 2 +-
> src/glsl/glsl_lexer.ll | 13 +++--
> src/glsl/glsl_parser_extras.h | 5 +
Another option would be to provide (no-op) implementations for all
drivers. But I think generally we indeed check if the function is
available in the state tracker before calling it for such things.
Roland
Am 23.06.2015 um 06:11 schrieb Ilia Mirkin:
> This needs to be guarded on availability of t
Am 23.06.2015 um 07:53 schrieb Dave Airlie:
> On 22 June 2015 at 21:20, Roland Scheidegger wrote:
>> Should there be some clamping somewhere to prevent crashes due to
>> out-of-bound unit index?
>
> The spec says its undefined, I'm never sure if that means explode in
> any way whatsoever.
>
> Da
On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to GLES 3.1 CTS test:
> ES31-CTS.texture_storage_multisample.
> APIGLGetTexLevelParameterifv.
> invalid_texture_target_rejected:
>
> GL_INVALID_ENUM should be generated when
> glGetTexLevelParameteriv is c
On Tue, Jun 23, 2015 at 3:11 PM, Erik Faye-Lund wrote:
> On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> According to GLES 3.1 CTS test:
>> ES31-CTS.texture_storage_multisample.
>> APIGLTexStorage2DMultisample.
>> multisample_texture_tex_storage_2d_non_colo
On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to GLES 3.1 CTS test:
> ES31-CTS.texture_storage_multisample.
> APIGLTexStorage2DMultisample.
> multisample_texture_tex_storage_2d_zero_sample-
>
> A call to glTexStorageMultisample with target
> GL_TEXTUR
From: Rob Clark
Ok, so actually there is a ttn issue here to fix as well.. but it
brought up a question in my mind. When ttn sees something like
DCL IN[0..1]
it will treat that as an array (which in the end will result in
constraints about where the registers get allocated. Which is not
rea
On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to GLES 3.1 CTS test:
> ES31-CTS.texture_storage_multisample.
> APIGLTexStorage2DMultisample.
> multisample_texture_tex_storage_2d_non_color_depth_or_stencil_
> internal_formats_receted.
>
> An illegal int
On Tue, Jun 23, 2015 at 2:23 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> According to GLES 3.1 CTS test:
> ES31-CTS.texture_storage_multisample.
> APIGLTexStorage2DMultisample.
> multisample_texture_tex_storage_2d_
> invalid_and_border_case_texture_sizes.
>
> Textures of size 0x0 are not
On 22/06/15 19:51, Emil Velikov wrote:
On 22 June 2015 at 15:01, Jose Fonseca wrote:
On 19/06/15 23:09, Emil Velikov wrote:
On 19 June 2015 at 21:26, Jose Fonseca wrote:
On 19/06/15 20:56, Emil Velikov wrote:
Hi all,
A lovely series inspired (more like 'was awaken to send these out') b
On Mon, 2015-06-22 at 19:04 +0300, Eero Tamminen wrote:
> Hi,
>
> On 06/20/2015 03:32 PM, Timothy Arceri wrote:
> > The restrictions in ES make the extension easier to implement so
> > I thought I'd try get this stuff reviewed an committed before
> > finishing
> > up the full extension.
> > The b
From: Marta Lofstedt
According to the OpenGL ES standard, 7.3.
For a call to glCreateShaderProgram with count < 0,
a GL_INVALID_VALUE error should be generated.
Signed-off-by: Marta Lofstedt
---
src/mesa/main/shaderapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/mai
From: Marta Lofstedt
According to GLES 3.1 CTS test:
ES31-CTS.texture_storage_multisample.
APIGLGetTexLevelParameterifv.
invalid_texture_target_rejected:
GL_INVALID_ENUM should be generated when
glGetTexLevelParameteriv is called with a defect
texture target.
Signed-off-by: Marta Lofstedt
---
From: Marta Lofstedt
Accoring to GLES 3.1 CTS:
GLES 3.1 CTS: ES31-CTS.shader_atomic_counters.
basic-buffer-bind.
AtomicBufferBindings size and start should be initialized
to zero.
Signed-off-by: Marta Lofstedt
---
src/mesa/main/bufferobj.c | 11 ---
1 file changed, 8 insertions(+), 3
From: Marta Lofstedt
According to GLES 3.1 CTS test:
ES31-CTS.texture_storage_multisample.
APIGLTexStorage2DMultisample.
multisample_texture_tex_storage_2d_non_color_depth_or_stencil_
internal_formats_receted.
An illegal internal format should generate a
GL_INVALID_ENUM error.
Signed-off-by: Ma
From: Marta Lofstedt
According to GLES 3.1 CTS test:
ES31-CTS.texture_storage_multisample.
APIGLTexStorage2DMultisample.
multisample_texture_tex_storage_2d_zero_sample-
A call to glTexStorageMultisample with target
GL_TEXTURE_2D_MULTISAMPLE and zero samples,
should return GL_INVALID_VALUE.
Howe
From: Marta Lofstedt
According to GLES 3.1 CTS test:
ES31-CTS.texture_storage_multisample.
APIGLTexStorage2DMultisample.
multisample_texture_tex_storage_2d_
invalid_and_border_case_texture_sizes.
Textures of size 0x0 are not allowed for
GL_TEXTURE_2D_MULTISAMPLE.
Signed-off-by: Marta Lofstedt
This is a series of patches that solves a couple of
API check and corner cases issues that the OpenGL ES 3.1
CTS exploits.
Marta Lofstedt (6):
mesa/es3.1: Do not allow zero size multisampled textures
mesa/es3.1: Correct error code for illegal internal formats
mesa/es3.1 : Correct error code
Reviewed-by: Iago Toral Quiroga
On Thu, 2015-06-18 at 17:50 -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_
Reviewed-by: Iago Toral Quiroga
On Thu, 2015-06-18 at 17:51 -0700, Jason Ekstrand wrote:
> This doesn't affect instructions allocated using the builder.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/
From: Marta Lofstedt
Signed-off-by: Marta Lofstedt
---
src/mesa/main/get_hash_params.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 74ff3ba..f7134a9 100644
--- a/src/mesa/main/get_hash_para
From: Marta Lofstedt
GL_ARB_compute_shader is limited for GLSL version 430.
This enables for GLSL ES version 310.
Signed-off-by: Marta Lofstedt
---
src/glsl/builtin_variables.cpp | 2 +-
src/glsl/glsl_parser.yy| 3 +--
src/glsl/glsl_parser_extras.h | 5 +
3 files changed, 7 insert
---
src/gallium/drivers/freedreno/freedreno_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index b3b5462..7330cd9 100644
--- a/src/gallium/drivers/freedreno/freedreno_
---
src/glsl/glsl_parser_extras.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 9a0c24e..02ddbbd 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -129,7 +129,7
From: Marta Lofstedt
When a program is compiled, but linking failed the
sh->InfoLog could be NULL. This is expoloited
by OpenGL ES 3.1 conformance tests.
Signed-off-by: Marta Lofstedt
---
src/mesa/main/shaderapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa
readpixels_can_use_memcpy will later call _mesa_format_matches_format_and_type
which does much tighter checks than these to decide if we can use
memcpy for readpixels.
Also, the checks do not seem to be extensive enough anyway, since we are
checking for signed/unsigned conversion only when the fra
On Thu, Jun 18, 2015 at 05:51:46PM -0700, Jason Ekstrand wrote:
> As of now, the width field is no longer used for anything. The width field
> "seemed like a good idea at the time" but is actually entirely redundant
> with the instruction's execution size. Initially, it gave us the ability
> to e
https://bugs.freedesktop.org/show_bug.cgi?id=91034
Daniel Stone changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 110 matches
Mail list logo
