On 08.01.2015 06:03, Tom Stellard wrote:
> @@ -75,6 +76,34 @@ static void parse_symbol_table(Elf_Data *symbol_table_data,
> }
> }
>
> +static void parse_relocs(Elf *elf, Elf_Data *relocs, Elf_Data *symbols,
> + unsigned symbol_sh_link,
> + struct rad
Hi,
In GLSL ES when the same uniform is declared in multiple shaders it must
have the same precision qualifier. There are a few dEQP tests that fail
because this is not checked in Mesa.
I think the right place to add this check would be in
cross_validate_globals(), but to do this we would need to
On 08.01.2015 06:03, Tom Stellard wrote:
> Instead of passing a pointer to the scratch buffer via user sgprs, we
> now patch the shader with the buffer address using reloc information
> from the LLVM generated ELF.
[...]
> @@ -174,6 +183,35 @@ static unsigned compute_num_waves_for_scratch(
>
On Thursday, January 08, 2015 10:21:45 AM Iago Toral wrote:
> Hi,
>
> In GLSL ES when the same uniform is declared in multiple shaders it must
> have the same precision qualifier. There are a few dEQP tests that fail
> because this is not checked in Mesa.
>
> I think the right place to add this c
On Wednesday, January 07, 2015 10:43:25 PM Kristian Høgsberg wrote:
> SKL+ overloads the SIMD4x2 SIMD mode to mean either SIMD8D or SIMD4x2
> depending on bit 22 in the message header. If the bit is 0 or there is
> no header we get SIMD8D. We always wand SIMD4x2 in vec4 and for fs pull
> constant
On Thu, 2015-01-08 at 01:49 -0800, Kenneth Graunke wrote:
> On Thursday, January 08, 2015 10:21:45 AM Iago Toral wrote:
> > Hi,
> >
> > In GLSL ES when the same uniform is declared in multiple shaders it must
> > have the same precision qualifier. There are a few dEQP tests that fail
> > because t
>
>
>
>
>
> *I see precision qualifiers being parsed and stored in the AST, but I
> don't see where this information is passed to the IR: ir_variable or
> glsl_type don't have this info, in fact, apply_type_qualifier_to_variable()
> in ast_to_hir.cpp seems to ignore the ast precision qualifier data
On Wed, Jan 7, 2015 at 7:09 PM, Ilia Mirkin wrote:
> On Wed, Jan 7, 2015 at 11:36 AM, Axel Davy wrote:
>> We should use the absolute value of the input as input to ureg_RSQ.
>>
>> Moreover, an input of 0.0 should return FLT_MAX.
>>
>> Reviewed-by: David Heidelberg
>> Signed-off-by: Axel Davy
>>
Please avoid TGSI_SAT_MINUS_PLUS_ONE. Nobody uses it, hardly anybody
implements it.
Marek
On Thu, Jan 8, 2015 at 1:49 AM, Ilia Mirkin wrote:
> On Wed, Jan 7, 2015 at 11:36 AM, Axel Davy wrote:
>> This is wine (and windows) behaviour.
>>
>> Signed-off-by: Axel Davy
>>
>> Cc: "10.4"
>> ---
>>
radeonsi supports DIV.
r600g and r300g don't.
There are 2 solutions:
1) Don't use DIV.
2) Add a cap and only use DIV on radeonsi.
Solution 2 is likely to be implemented for OpenGL eventually.
Marek
On Thu, Jan 8, 2015 at 1:56 AM, Ilia Mirkin wrote:
> On Wed, Jan 7, 2015 at 11:36 AM, Axel Davy
On 07/01/15 19:11, Carl Worth wrote:
On Wed, Jan 07 2015, Jose Fonseca wrote:
I lost bit track of email over the Christmas period. Just noticed I had
flagged this one for replay. Sorry.
No worries. Thanks for following up now. :-)
Do you still need me to test anything on Windows? If so are
From: José Fonseca
Trivial.
---
src/mesa/main/imports.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 6945c2f..4f5a2d1 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -94,7 +94,7 @@ _mesa_alig
From: José Fonseca
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1, so the handy trick of renaming Mesa's
ICDs as nvoglv32.dll on Windows machines with NVIDIA hardware for quick
testing of
On 01/08/2015 09:41 AM, Jose Fonseca wrote:
From: José Fonseca
Trivial.
---
src/mesa/main/imports.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 6945c2f..4f5a2d1 100644
--- a/src/mesa/main/imports.c
+++ b/src/
On 01/08/2015 09:41 AM, Jose Fonseca wrote:
From: José Fonseca
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1,
What version did they use before, zero?
so the handy trick of renaming
On Thu, Jan 8, 2015 at 8:41 AM, Jose Fonseca wrote:
> From: José Fonseca
Thanks José. I missed this because it's in an #ifdef that isn't
compiled on my system.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://l
All patches that I didn't respond to, except patches 27 and 53, which
were too long/involved for me, are Reviewed-by: Ilia Mirkin
I think you provided sufficient clarification on a few that I *did*
respond to as well, but I'll send separate R-b's for those.
On Wed, Jan 7, 2015 at 11:36 AM, Axel
Yes, I'm just trying to figure out if there's a design which easily
works both for d3d and opengl. Apparently, being per stage or global is
a difference which we just need to live with, so I don't have any
objections of making this more suited to GL. Using different types for
images and buffers is
On Wed, Jan 7, 2015 at 10:03 PM, Tom Stellard wrote:
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 40 ++
> src/gallium/drivers/radeonsi/si_shader.c| 69
> -
> src/gallium/drivers/radeonsi/si_shader.h| 7 ++-
> src/gallium/drivers/
On Wed, Jan 7, 2015 at 11:20 PM, Iago Toral Quiroga
wrote:
> From: Samuel Iglesias Gonsalvez
>
> This will be used to unify code in pack.c.
>
> v2:
> - Modify pack_int_*() function generator to use c.datatype() and
> f.datatype()
>
> Signed-off-by: Samuel Iglesias Gonsalvez
> ---
> src/mesa/
Everything except 17 is
Reviewed-by: Jason Ekstrand
When you rework 17, please just resend 17 and not the whole series.
Yeah, we should probably dig up another reviewer for 2 and 12.
--Jason
On Wed, Jan 7, 2015 at 11:28 PM, Iago Toral wrote:
> On Thu, 2015-01-08 at 08:20 +0100, Iago Toral Qu
On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
> On Wed, Jan 7, 2015 at 10:03 PM, Tom Stellard wrote:
> > ---
> > src/gallium/drivers/radeonsi/si_compute.c | 40 ++
> > src/gallium/drivers/radeonsi/si_shader.c| 69
> > -
> > src/gal
I've made some small patches to try using the blorp blitter on a branch
here:
https://github.com/bpeel/mesa/tree/texture-array-opt
I've also made a little standalone performance test here:
https://github.com/bpeel/glut-fato/blob/master/src/fato-texture-array.c
The test creates a 512x512x64 2D a
On Wed, Jan 7, 2015 at 11:21 PM, Iago Toral Quiroga
wrote:
> From: Jason Ekstrand
>
> v2 by Iago Toral :
>
> - When testing if we can directly pack we should use the src format to
> check
> if we are packing from an RGBA format. The original code used the dst
> format
> for the ubyte case by
On Wed, Jan 7, 2015 at 11:21 PM, Iago Toral Quiroga
wrote:
> This is the second of two series that aim to address:
> https://bugs.freedesktop.org/show_bug.cgi?id=84566
>
> This series requires the previous series that implements auto-generation of
> the pack/unpack functions. A branch with both s
DX11 can be supported very well with this interface. OpenGL has these
queries (from shader storage buffers
objects):
MAX_VERTEX_SHADER_STORAGE_BLOCKS (min: 0)
MAX_GEOMETRY_SHADER_STORAGE_BLOCKS (min: 0)
MAX_FRAGMENT_SHADER_STORAGE_BLOCKS (min: 8)
I guess the minimum values are DX11 requirements,
On Thu, Jan 8, 2015 at 7:17 PM, Tom Stellard wrote:
> On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
>> On Wed, Jan 7, 2015 at 10:03 PM, Tom Stellard
>> wrote:
>> > ---
>> > src/gallium/drivers/radeonsi/si_compute.c | 40 ++
>> > src/gallium/drivers/radeonsi/si_s
---
v2: Made some small changes to the surrounding vec4 code to better match
the fs code.
No shader-db changes.
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 14 ++
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 21 +++--
2 files changed, 25 insertions(+), 10 deletio
On 08/01/15 16:57, Brian Paul wrote:
On 01/08/2015 09:41 AM, Jose Fonseca wrote:
From: José Fonseca
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1,
What version did they use before,
On 07/01/2015 23:18, Axel Davy wrote :
On 07/01/2015 18:42, Ilia Mirkin wrote :
On Wed, Jan 7, 2015 at 11:36 AM, Axel Davy wrote:
Adds ATI1 and ATI2 support to nine.
They map to PIPE_FORMAT_RGTC1_UNORM and PIPE_FORMAT_RGTC2_UNORM,
but need special handling.
Reviewed-by: David Heidelberg
S
On Thu, Jan 08, 2015 at 07:51:58PM +0100, Marek Olšák wrote:
> On Thu, Jan 8, 2015 at 7:17 PM, Tom Stellard wrote:
> > On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
> >> On Wed, Jan 7, 2015 at 10:03 PM, Tom Stellard
> >> wrote:
> >> > ---
> >> > src/gallium/drivers/radeonsi/si_co
On Wed, Jan 7, 2015 at 11:20 PM, Iago Toral Quiroga wrote:
> From: Jason Ekstrand
>
> ---
> src/mesa/main/formats.c | 19 +++
> src/mesa/main/formats.h | 3 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
> index b10b628
On Wed, Jan 7, 2015 at 11:20 PM, Iago Toral Quiroga
wrote:
> From: Jason Ekstrand
>
> Aparently, the packing/unpacking functions for these formats have differed
> from the format description in formats.h. Instead of fixing this, people
> simply left a comment saying it was broken. Let's actuall
On Thursday, January 08, 2015 10:53:22 AM Matt Turner wrote:
> ---
> v2: Made some small changes to the surrounding vec4 code to better match
> the fs code.
>
> No shader-db changes.
>
> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 14 ++
> src/mesa/drivers/dri/i965/brw_vec4_cse.
On Thu, Jan 8, 2015 at 8:41 PM, Tom Stellard wrote:
> On Thu, Jan 08, 2015 at 07:51:58PM +0100, Marek Olšák wrote:
>> On Thu, Jan 8, 2015 at 7:17 PM, Tom Stellard wrote:
>> > On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
>> >> On Wed, Jan 7, 2015 at 10:03 PM, Tom Stellard
>> >> w
On Thu, Jan 8, 2015 at 3:37 PM, Marek Olšák wrote:
> On Thu, Jan 8, 2015 at 8:41 PM, Tom Stellard wrote:
>> On Thu, Jan 08, 2015 at 07:51:58PM +0100, Marek Olšák wrote:
>>> On Thu, Jan 8, 2015 at 7:17 PM, Tom Stellard wrote:
>>> > On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #23 from Kurzemnieks ---
I think I have run in the same problem.
Here is a screenshot with a simple double-sided cube whose backface seems to be
drawn incorrectly on the edge.
https://api1-ams2.monosnap.com/static/0kwtTWiNWJrcIXex8Bc
Move assertions after declarations and don't use void pointer arithmetic.
---
src/mesa/main/texgetimage.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 58d9cc5..96b019d 100644
--- a/src/mesa/main/texge
Can't do void pointer arithmetic with MSVC.
---
src/mesa/main/teximage.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e41ce32..b3c668f 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -354
On 08/01/15 21:10, Brian Paul wrote:
Can't do void pointer arithmetic with MSVC.
---
src/mesa/main/teximage.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e41ce32..b3c668f 100644
--- a/src/mesa/main/teximage
On 08/01/2015 05:08, Ilia Mirkin wrote :
On Wed, Jan 7, 2015 at 11:36 AM, Axel Davy wrote:
Signed-off-by: Axel Davy
Cc: "10.4"
---
src/gallium/state_trackers/nine/device9.c | 10 ++
src/gallium/state_trackers/nine/device9.h | 2 ++
src/gallium/state_trackers/nine/stateblo
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #24 from José Fonseca ---
(In reply to Kurzemnieks from comment #23)
> I think I have run in the same problem.
> Here is a screenshot with a simple double-sided cube whose backface seems to
> be drawn incorrectly on the edge.
> https
On Thu, Jan 8, 2015 at 12:02 PM, Anuj Phogat wrote:
>
>
> On Wed, Jan 7, 2015 at 11:20 PM, Iago Toral Quiroga
> wrote:
> > From: Jason Ekstrand
> >
> > Aparently, the packing/unpacking functions for these formats have
> differed
> > from the format description in formats.h. Instead of fixing t
This little series adds a PBO texture upload path based on meta. We do so
by adding a little driver hook for creating a 2D or 2D array texture from a
gl_buffer_object and then using this together with BlitFramebuffers to do
the upload. Since Intel hardware can take basically any buffer and treat
---
src/mesa/drivers/dri/i965/intel_tex.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c
b/src/mesa/drivers/dri/i965/intel_tex.c
index 3be72d5..fd2e003 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa
This improves texture upload performance on the PBO upload test available
at http://www.songho.ca/opengl/gl_pbo.html by 80% for the non-PBO case (due
to avoiding a buffer stall) and 500% for the PBO case.
---
src/mesa/drivers/dri/i965/intel_tex_image.c| 12 ++--
src/mesa/drivers/dri/i9
---
src/mesa/drivers/dri/i965/intel_fbo.c | 1 +
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 +++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 1 +
src/mesa/drivers/dri/i965/intel_pixel_draw.c | 2 +-
src/mesa/drivers/dri/i965/intel_pixel_read.c | 2 +-
src/mesa/drivers/dr
This meta path, designed for use with PBO's, creates a temporary texture
out of the PBO and uses BlitFramebuffers to do the actual texture upload.
---
src/mesa/Makefile.sources | 1 +
src/mesa/drivers/common/meta.h | 9 ++
src/mesa/drivers/common/meta_tex_subimag
---
src/mesa/main/dd.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 2f40915..72c87fe 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -415,6 +415,20 @@ struct dd_function_table {
struct gl_
On Tue, Jan 6, 2015 at 6:27 PM, Jason Ekstrand wrote:
>
>
> On Mon, Jan 5, 2015 at 11:26 PM, Connor Abbott wrote:
>>
>> Can you make the fields lowercase to match the algebraic properties
>> enum? Or did you make that uppercase? Lowercase feels better to me
>> since it's an enum, but I don't real
From: Mike Mason
Removes commit 7894278 changes and moves fix to _mesa_GetInternalformativ().
The original commit enabled the GL_RGB and GL_RGBA unsized internal formats
as valid for render buffers in GLES3, but this is incorrect. Page 204 of
the GLES 3.0.4 spec says render buffers "must be a siz
https://bugs.freedesktop.org/show_bug.cgi?id=88219
Bug ID: 88219
Summary: include/c11/threads_posix.h:197: undefined reference
to `pthread_mutex_lock'
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=88219
--- Comment #1 from Jonathan Gray ---
Created attachment 111987
--> https://bugs.freedesktop.org/attachment.cgi?id=111987&action=edit
Link glsl_test against $(PTHREAD_LIBS)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=88219
--- Comment #2 from Jonathan Gray ---
I've attached a patch that links glsl_test against the pthreads library which
should fix this. This is the same change that was done for glsl_compiler back
in 0d6f573f6e6785babe1e274697fdd315db95fb98.
--
Y
Thanks for the patch!
> Subject: [Mesa-dev] [mesa-dev][Bug 88079][PATCH] mesa: Enables GL_RGB/GL_RGBA
> in GLES3 glGetInternalformativ
No need to prefix your subject with these things. The mailing list
itself will add [Mesa-dev], and we don't put [Bug ...] in the subject.
Put
> Bugzilla: https
On 09.01.2015 04:41, Tom Stellard wrote:
> On Thu, Jan 08, 2015 at 07:51:58PM +0100, Marek Olšák wrote:
>> On Thu, Jan 8, 2015 at 7:17 PM, Tom Stellard wrote:
>>> On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
On Wed, Jan 7, 2015 at 10:03 PM, Tom Stellard
wrote:
>
>>>
On Sat, Jan 3, 2015 at 2:18 PM, Thomas Helland
wrote:
> Also handle undefined behaviour for sqrt(x) where x < 0
> and rsq(x) where x <= 0.
>
> This gives us some reduction in instruction count on three
> Dungeon Defenders shaders as they are doing: max(exp(x), 0)
So initially when you said that D
From: Dave Airlie
After much searching and empricial testing, and reading of
things I've no justifcation for this fix, other than it really
appears this is what the hw is doing or close enough.
It makes sense that each entry in the FMASK corresponds to
an entry in the CMASKm and the CMASK is org
On Thu, Jan 8, 2015 at 5:48 AM, Marek Olšák wrote:
> Please avoid TGSI_SAT_MINUS_PLUS_ONE. Nobody uses it, hardly anybody
> implements it.
I'm curious -- does any hardware implement it?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 9dfb7b7..b8f1f44 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3296,9
total instructions in shared programs: 5886767 -> 5881642 (-0.09%)
instructions in affected programs: 532199 -> 527074 (-0.96%)
GAINED:9
LOST: 6
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/b
The pattern
gl_FrontFacing ? -0.0 : -1.0
appears in many shaders, but there's no significance of the 0.0's sign
since it the result of the expression is always used in an addition.
Getting the sign bit right would be an extra OR instruction and seems
unnecessary.
total instructions in shared
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 7b4ac8d..d98a696 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src
On Thu, 2015-01-08 at 10:38 -0800, Jason Ekstrand wrote:
>
>
> On Wed, Jan 7, 2015 at 11:21 PM, Iago Toral Quiroga
> wrote:
> From: Jason Ekstrand
>
> v2 by Iago Toral :
>
> - When testing if we can directly pack we should use the src
> format t
On Thursday, January 08, 2015 10:13:11 AM Jason Ekstrand wrote:
> On Wed, Jan 7, 2015 at 11:20 PM, Iago Toral Quiroga
>
> wrote:
> > From: Samuel Iglesias Gonsalvez
> >
> > This will be used to unify code in pack.c.
> >
> > v2:
> > - Modify pack_int_*() function generator to use c.datatype() a
65 matches
Mail list logo
