For the series:
Reviewed-by: Chris Forbes
On Tue, Jun 23, 2015 at 1:07 PM, Jason Ekstrand wrote:
> As of this commit, nothing actually needs the brw_context.
> ---
> src/mesa/drivers/dri/i965/brw_cs.cpp| 6 --
> src/mesa/drivers/dri/i965/brw_fs.cpp| 12
On 06/23/2015 08:57 AM, Michel Dänzer wrote:
On 23.06.2015 06:02, Samuel Pitoiset wrote:
On 06/22/2015 10:52 PM, Ilia Mirkin wrote:
If query_create fails, why would any of these functions get called?
Because the HUD doesn't check if query_create() fails and it calls other
pipe_query functio
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 +
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/s
Sorry about the last patch, I sent a V3 of below.
/Marta
From: Lofstedt, Marta
Sent: Monday, June 15, 2015 1:36 PM
To: Ilia Mirkin; Marta Lofstedt
Cc: mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [PATCH] glsl/es31:Allow GL_ARB_TEXTURE_MULTISAMPLE
On Tue, 2015-06-23 at 08:54 +0200, Iago Toral wrote:
> On Mon, 2015-06-22 at 12:35 -0700, Anuj Phogat wrote:
> > On Sun, Jun 21, 2015 at 11:25 PM, Iago Toral wrote:
> > > On Fri, 2015-06-19 at 13:32 -0700, Anuj Phogat wrote:
> > >> On Thu, Jun 18, 2015 at 11:41 PM, Iago Toral wrote:
> > >> > On T
On Thu, Jun 18, 2015 at 05:51:35PM -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(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git
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/i965/brw_fs.cpp | 52 ++
> src/mesa/drivers/dri/i
On Thu, Jun 18, 2015 at 05:51:39PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs
On Thu, Jun 18, 2015 at 05:51:43PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_builder.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_builder.h
> b/src/mesa/drivers/dri/i965/brw_fs_builder.h
> index 7d
On Thu, Jun 18, 2015 at 05:51:37PM -0700, Jason Ekstrand wrote:
> Previously, we were just depending on register widths to ensure that
> various things were exec_size of 1 etc. Now, we do so explicitly using the
> builder.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
> 1 file
https://bugs.freedesktop.org/show_bug.cgi?id=91034
Daniel Stone changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
---
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
---
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_
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
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
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/
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_
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
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 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
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
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 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 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
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_zero_sample-
>
> A call to glTexStorageMultisample with target
> GL_TEXTUR
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.
> APIGLGetTexLevelParameterifv.
> invalid_texture_target_rejected:
>
> GL_INVALID_ENUM should be generated when
> glGetTexLevelParameteriv is c
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
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
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 +
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 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.
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 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
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 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 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 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
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
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
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'
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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=90797
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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 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
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
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)
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
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
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
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 |
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 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 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 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 ++--
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 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
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 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_
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 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
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
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 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
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
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.
___
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
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
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
---
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 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
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
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
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
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
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.
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
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
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 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
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 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 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 :
>>
>
> 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 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
>> 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
1 - 100 of 110 matches
Mail list logo
