This patch is still unreviewed.
Sam
On Tue, 2015-12-15 at 12:51 +0100, Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> Commit 5bb5eeea fix a bug indicating that the surfaces should have
> the
> API buffer size. Hovewer it picked the wrong value.
>
> This patch adds a new variab
On Tue, Dec 22, 2015 at 3:25 AM, Jason Ekstrand wrote:
>
> As with Michel, I'd rather have my "personal" e-mail as the cannonical one.
> That said, I vote we just merge this as-is and let everyone go fix their own
> e-mail address.
I have yours and Michel fixed locally now. I can resend one last
https://bugs.freedesktop.org/show_bug.cgi?id=89018
Ernst Sjöstrand changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, 2015-12-21 at 19:24 +0200, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > On Haswell we need to set the UAV_ONLY WM state bit when there are
> > no colour
> > or depth buffer writes and on all hardware we should set the early
> > depth/stencil control field to PSEXEC unless ear
On Tue, 2015-12-22 at 17:01 +1100, Timothy Arceri wrote:
> Previously we would pack varyings before trying to remove them, this
> meant the varying would only be removed if all the varyings in the
> packed
> location were unused.
I forgot to update this commit message as per:
http://lists.freedesk
Thanks for the most comprehensive cleanup Roland and fixing that
minor regression we discussed. Happy holiday's.
Reviewed-by: Edward O'Callaghan
On 2015-12-22 14:00, srol...@vmware.com wrote:
From: Roland Scheidegger
Previously the code would just redirect requests for attributes which
don'
On Tue, 2015-12-22 at 17:02 +1100, Timothy Arceri wrote:
> Rather than passing in the vertex count to the packing pass just us
> the outermost array size to get the count.
>
> Also teach lower_packed_varyings() about the tessellation shader
> varyings.
>
> Note: This patch doesn't really work for
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 5ec3613..6411ab2 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -182,7 +182,7 @@ GL 4.4, GLSL 4.40:
- compile-time constant expressions DONE
- explicit byt
This actually tries to pack any output with an explicit location we
just let the optimisiation passes clean up the extra assignments if
there was no actual packing done.
---
src/glsl/link_varyings.cpp | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/glsl/link_varyings.cpp
From Section 7.3.1.1 (Naming Active Resources) of the OpenGL 4.5 spec:
"For the property LOCATION_COMPONENT, a single integer indicating the first
component of the location assigned to an active input or output variable is
written to params. For input and output variables with a component
Rather than passing in the vertex count to the packing pass just us
the outermost array size to get the count.
Also teach lower_packed_varyings() about the tessellation shader
varyings.
Note: This patch doesn't really work for tessellation shaders because
of the shared store for varyings. For tes
---
src/glsl/lower_packed_varyings.cpp | 45 +++---
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/src/glsl/lower_packed_varyings.cpp
b/src/glsl/lower_packed_varyings.cpp
index d91aa22..2899846 100644
--- a/src/glsl/lower_packed_varyings.cpp
+++ b/
This is needed now that we pack these type of varyings when they have a
component layout qualifier.
---
src/glsl/linker.cpp | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 4c2f24b..f1cdfd0 100644
--- a/src/glsl/lin
---
src/glsl/linker.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 657d294..827d07f 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -990,6 +990,13 @@ cross_validate_globals(struct gl_shader_program *prog,
This actually tries to pack any input with an explicit location we
just let the optimisiation passes clean up the extra assignments if
there was no actual packing done.
---
src/glsl/ir_optimization.h | 1 +
src/glsl/link_varyings.cpp | 33 ++---
src/gls
This will allow us to choose to ignore the disable which will be
useful for allowing support of the component layout qualifier while
still disabling packing for varyings without an explicit component.
---
src/glsl/ir_optimization.h | 3 ++-
src/glsl/link_varyings.cpp | 26
---
src/glsl/ir_optimization.h | 3 ++-
src/glsl/link_varyings.cpp | 6 --
src/glsl/lower_packed_varyings.cpp | 33 -
3 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index
---
src/glsl/linker.cpp | 56 -
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 827d07f..4c2f24b 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2411,7 +2411,12 @@ assig
Previously we would pack varyings before trying to remove them, this
meant the varying would only be removed if all the varyings in the packed
location were unused.
---
src/glsl/link_varyings.cpp | 39
src/glsl/linker.cpp| 50 ---
This count is used by the packing pass and we need to include
varying with explicit locations to be able to pack varyings
with explicit components.
---
src/glsl/link_varyings.cpp | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link
---
src/glsl/ast.h | 14 ++
src/glsl/ast_type.cpp | 3 +++
src/glsl/glsl_parser.yy | 11 +++
3 files changed, 28 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index f8ab0b7..e22deed 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -490,6 +490,12 @@
Cc: Kenneth Graunke
Cc: 11.1
---
src/glsl/link_varyings.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 100eff9..fd4b27c 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1526,7 +1
This will be used in the following patch for calculating array sizes correctly
when reserving explicit varying locations.
Cc: Kenneth Graunke
Cc: 11.1
---
src/glsl/link_varyings.cpp | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/gl
I've bounced back and forward between adding this support in the nir/i965
backend or adding it in the varying packing pass in GLSL IR a couple of times,
so I wanted to get some feedback on how others think it should be done. This
series adds support to the varying packing pass.
This series adds su
This change checks for component overlap, including handling overlap of
locations and components by doubles. Previously there was no validation
for assigning explicit locations to a location used by the second half
of a double.
---
src/glsl/link_varyings.cpp | 72 ++
We make use of the existing IR field location_frac used for tracking
component locations.
---
src/glsl/ast_to_hir.cpp | 38 ++
src/glsl/ir.h | 5 +
2 files changed, 43 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
i
---
src/glsl/link_varyings.cpp | 53 --
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index fd4b27c..06882fc 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cp
Previously we were only reserving a single location for arrays and
structs.
We also didn't take into account implicit locations clashing with
explicit locations when assigning locations for their arrays or
structs.
This patch fixes both issues.
V4: just use count_attribute_slots() to get the num
This is needed so we don't optimise away the varying when more than
one shares the same location.
---
src/glsl/linker.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 17450b8..657d294 100644
--- a/src/glsl/linker.cpp
+
On 22.12.2015 07:35, Marek Olšák wrote:
> Hi,
>
> This patch series adds more flexibility to u_upload_mgr. First, it
> adds the ability to specify the alignment per suballocation. The idea
> is that several users can use the same upload buffer, but each may
> need a different alignment. Finally, i
On 22.12.2015 07:36, Marek Olšák wrote:
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index 484f5c8..21fe498 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_commo
On Mon, Dec 21, 2015 at 2:54 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> This field is used as a flag to optimise out any varyings that don't have
> matching varying on the other side of the interface.
>
> The value should be the same for all varyings (except for SSO but we can't
>
From: Roland Scheidegger
Previously the code would just redirect requests for attributes which
don't exist to use output 0. Rework this to output all zeros instead which
seems more useful - in particular some extensions like
ARB_fragment_layer_viewport require 0 in the fs even if it wasn't output
From: Roland Scheidegger
draw emit couldn't care less what the interpolation mode is...
This somehow looked like it would matter, all drivers more or less
dutifully filled that in correctly. But this is only used for emit,
if draw needs to know about interpolation mode (for clipping for instance)
From: Roland Scheidegger
They can't actually be 0 (as position is there) but should avoid confusion.
This was supposed to have been done by af7ba989fb5a39925a0a1261ed281fe7f48a16cf
but I accidentally pushed an older version of the patch in the end...
Also prettify slightly. And make some notes a
From: Roland Scheidegger
softpipe would calculate two "vertex layouts". The second one was however
just used for internal purposes, draw would know nothing about it even though
it looked exactly the same as the other one we tell draw about.
So, store that information separately as this was just c
From: Roland Scheidegger
This makes it more similar to llvmpipe. It also allows us to let draw emit
code handle things like getting zeros for non-existing vs outputs
automatically. There probably isn't really any overhead either way, there isn't
really any "simply copy everything" code in the emi
From: Roland Scheidegger
The vertex size can change in fetch_pipeline_prepare, if drivers use
the draw_prepare_shader_outputs hook (similar to what the llvm path already
does). Albeit this is hugely confusing and very error prone.
Also sort-of prepare the wide point stage for using draw_prepare_s
From: Roland Scheidegger
It was actually slightly buggy (missing initialization / setup not dependent
on new vs albeit I didn't see issues), but the case of non-existing attributes
is now handled by draw emit code so don't need that anymore.
---
src/gallium/drivers/llvmpipe/lp_bld_interp.h|
From: Roland Scheidegger
Unlike llvmpipe, softpipe always tells draw to emit the vertices as-is.
The two vertex layouts it calculates are a bit confusing, one which is just
used to tell draw to emit vertices as-is, and the other which has draw written
all over it but draw is completely unaware of
On Sun, Dec 20, 2015 at 6:41 AM, Giuseppe Bilotta <
giuseppe.bilo...@gmail.com> wrote:
> This adds a first tentative .mailmap file, to canonicize contributor
> name/emails in shortlogs and other statistical endeavours, for all git
> internal toosl and tools that make use of it. Additional informat
Am 22.12.2015 um 02:56 schrieb Marek Olšák:
> On Tue, Dec 22, 2015 at 12:10 AM, Roland Scheidegger
> wrote:
>> Am 21.12.2015 um 20:59 schrieb Jose Fonseca:
>>> On 16/12/15 16:18, Roland Scheidegger wrote:
Am 16.12.2015 um 12:52 schrieb Marek Olšák:
> This is not well defined in gallium,
On Mon, Dec 21, 2015 at 2:24 PM, Marek Olšák wrote:
> On Mon, Dec 21, 2015 at 11:20 PM, Jason Ekstrand
> wrote:
> >
> > On Dec 21, 2015 1:37 PM, "Marek Olšák" wrote:
> >>
> >> On Mon, Dec 21, 2015 at 7:48 PM, Jason Ekstrand
> >> wrote:
> >> >
> >> > On Dec 21, 2015 9:09 AM, "Connor Abbott" wr
When buffer size is less than 16, zero ends up being programmed as
size, which prevents the hardware from fetching the correct values.
Fix it by combining shift and align so that the value is always
rounded up.
Cc: "11.1 11.0 10.6"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92229
Sign
On Dec 21, 2015 8:57 PM, "Marek Olšák" wrote:
>
> On Tue, Dec 22, 2015 at 12:10 AM, Roland Scheidegger
wrote:
> > Am 21.12.2015 um 20:59 schrieb Jose Fonseca:
> >> On 16/12/15 16:18, Roland Scheidegger wrote:
> >>> Am 16.12.2015 um 12:52 schrieb Marek Olšák:
> This is not well defined in gal
On Tue, Dec 22, 2015 at 12:10 AM, Roland Scheidegger wrote:
> Am 21.12.2015 um 20:59 schrieb Jose Fonseca:
>> On 16/12/15 16:18, Roland Scheidegger wrote:
>>> Am 16.12.2015 um 12:52 schrieb Marek Olšák:
This is not well defined in gallium, but r600g and radeonsi use these
default swizzle
On Mon, Dec 21, 2015 at 10:51 AM, Jose Fonseca wrote:
> On 19/12/15 22:39, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> We are going to start using nir_builder.h from some gallium code, which
>> is currently only C90.
>
>
> Which parts of gallium are you referring to?
gallium/auxiliary/nir
Alth
On Tue, 2015-12-22 at 11:25 +1100, Timothy Arceri wrote:
> Previously we would pack varyings before trying to remove them, this
> meant the varying would only be removed if all the varyings in the
> packed
> location were unused or if the varying wasn't packed.
>
> This change makes no difference
Previously we would pack varyings before trying to remove them, this
meant the varying would only be removed if all the varyings in the packed
location were unused or if the varying wasn't packed.
This change makes no difference to the public shader-db.
---
src/glsl/link_varyings.cpp | 43 +++
On Dec 21, 2015 6:10 PM, "Roland Scheidegger" wrote:
>
> Am 21.12.2015 um 20:59 schrieb Jose Fonseca:
> > On 16/12/15 16:18, Roland Scheidegger wrote:
> >> Am 16.12.2015 um 12:52 schrieb Marek Olšák:
> >>> This is not well defined in gallium, but r600g and radeonsi use these
> >>> default swizzles
Am 21.12.2015 um 20:59 schrieb Jose Fonseca:
> On 16/12/15 16:18, Roland Scheidegger wrote:
>> Am 16.12.2015 um 12:52 schrieb Marek Olšák:
>>> This is not well defined in gallium, but r600g and radeonsi use these
>>> default swizzles for depth and stencil surfaces and it's probably the
>>> only rea
This field is used as a flag to optimise out any varyings that don't have
matching varying on the other side of the interface.
The value should be the same for all varyings (except for SSO but we can't
optimise those) by the time they reach nir and are no longer be needed.
---
src/glsl/nir/glsl_t
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #53 from Nicolai Hähnle ---
The 'FBO incomplete' message is something that is often seen with apitrace. Not
sure where it actually comes from, but in other cases it doesn't cause
problems.
Do you get a crash when you replay that trac
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 5 +
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gal
From: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 2 +-
src/gallium/auxiliary/indices/u_primconvert.c| 2 +-
src/gallium/auxiliary/util/u_blitter.c | 2 +-
src/gallium/auxiliary/util/u_upload_mgr.c| 3 ---
src/gallium/auxiliary/util/u_upload_mgr.h
Hi,
This patch series adds more flexibility to u_upload_mgr. First, it adds the
ability to specify the alignment per suballocation. The idea is that several
users can use the same upload buffer, but each may need a different alignment.
Finally, it allows specifying PIPE_USAGE, which usually aff
From: Marek Olšák
The function only aligned the size, but not the offset.
The offset was aligned only when the previous suballocation was aligned.
That yielded the correct offset alignment if the alignment was constant
for all suballocations.
Instead, directly align the offset, but allow an unal
From: Marek Olšák
The fixed alignment of u_upload_mgr will go away.
This is the first step.
The motivation is that one u_upload_mgr can have multiple users,
each allocating from the same buffer, but requiring a different alignment.
---
src/gallium/auxiliary/util/u_blitter.c| 4 ++--
src
From: Marek Olšák
The fixed alignment of u_upload_mgr will go away.
This is the first step.
The motivation is that one u_upload_mgr can have multiple users,
each allocating from the same buffer, but requiring a different alignment.
---
src/gallium/auxiliary/hud/hud_context.c | 2 +-
s
From: Marek Olšák
The fixed alignment of u_upload_mgr will go away.
This is the first step.
The motivation is that one u_upload_mgr can have multiple users,
each allocating from the same buffer, but requiring a different alignment.
---
src/gallium/auxiliary/util/u_upload_mgr.c | 4 ++--
src/gal
From: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 2 +-
src/gallium/auxiliary/indices/u_primconvert.c| 3 ++-
src/gallium/auxiliary/util/u_blitter.c | 3 ++-
src/gallium/auxiliary/util/u_upload_mgr.c| 10 ++
src/gallium/auxiliary/util/u_upl
On Mon, Dec 21, 2015 at 11:20 PM, Jason Ekstrand wrote:
>
> On Dec 21, 2015 1:37 PM, "Marek Olšák" wrote:
>>
>> On Mon, Dec 21, 2015 at 7:48 PM, Jason Ekstrand
>> wrote:
>> >
>> > On Dec 21, 2015 9:09 AM, "Connor Abbott" wrote:
>> >>
>> >> On Mon, Dec 21, 2015 at 11:45 AM, Marek Olšák wrote:
>
On Dec 21, 2015 1:37 PM, "Marek Olšák" wrote:
>
> On Mon, Dec 21, 2015 at 7:48 PM, Jason Ekstrand
wrote:
> >
> > On Dec 21, 2015 9:09 AM, "Connor Abbott" wrote:
> >>
> >> On Mon, Dec 21, 2015 at 11:45 AM, Marek Olšák wrote:
> >> > On Mon, Dec 21, 2015 at 4:38 PM, Connor Abbott
> >> > wrote:
>
On Mon, Dec 21, 2015 at 7:48 PM, Jason Ekstrand wrote:
>
> On Dec 21, 2015 9:09 AM, "Connor Abbott" wrote:
>>
>> On Mon, Dec 21, 2015 at 11:45 AM, Marek Olšák wrote:
>> > On Mon, Dec 21, 2015 at 4:38 PM, Connor Abbott
>> > wrote:
>> >> On Mon, Dec 21, 2015 at 6:39 AM, Marek Olšák wrote:
>> >>>
Christian König wrote:
Slightly unrelated question = with vaapi using mpeg2 do you get the
same result as vdpau or s/w?
Well MPEG2 actually defines that the resulting image doesn't need to
be 100% bit identical on all decoders. H.264 and others are way more
strict regarding this.
Do you also
From: Nicolai Hähnle
This changes the count slightly (because of si_generate_gs_copy_shader), but
this is only relevant for the driver-specific num-compilations query. It sets
the stage for the next commit.
Reviewed-by: Marek Olšák
---
(unchanged from v1)
src/gallium/drivers/radeonsi/si_shade
From: Nicolai Hähnle
This option allows replacing a single shader by a pre-compiled ELF object
as generated by LLVM's llc, for example. This can be useful for debugging a
deterministically occuring error in shaders (and has in fact helped find
the causes of https://bugs.freedesktop.org/show_bug.c
From: Nicolai Hähnle
This is analogous to the alreading existing macros for BOOL, NUM, and FLAGS.
---
(commit added in v2 of the series)
src/gallium/auxiliary/util/u_debug.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_debug.h
b/src/gallium/au
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #52 from bellamort...@gmail.com ---
Of course I used the latest mesa git.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
m
On 16/12/15 16:18, Roland Scheidegger wrote:
Am 16.12.2015 um 12:52 schrieb Marek Olšák:
This is not well defined in gallium, but r600g and radeonsi use these
default swizzles for depth and stencil surfaces and it's probably the
only reasonable thing to do:
Format = Default swizzle
Z24X8 =
On Sat, Dec 19, 2015 at 6:06 PM, Ilia Mirkin wrote:
> On Sat, Dec 19, 2015 at 1:53 PM, Ilia Mirkin wrote:
>> These are supported on GK20A and GM107.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> Was a bit torn on where to place the enums... we're about to gut all
>> the xml definitions so this s
On Dec 21, 2015 9:09 AM, "Connor Abbott" wrote:
>
> On Mon, Dec 21, 2015 at 11:45 AM, Marek Olšák wrote:
> > On Mon, Dec 21, 2015 at 4:38 PM, Connor Abbott
wrote:
> >> On Mon, Dec 21, 2015 at 6:39 AM, Marek Olšák wrote:
> >>> On Mon, Dec 21, 2015 at 6:48 AM, Jason Ekstrand
wrote:
>
>
Iago Toral Quiroga writes:
> On Haswell we need to set the UAV_ONLY WM state bit when there are no colour
> or depth buffer writes and on all hardware we should set the early
> depth/stencil control field to PSEXEC unless early fragment tests are enabled
> to make sure that the fragment shader is
On Mon, Dec 21, 2015 at 11:45 AM, Marek Olšák wrote:
> On Mon, Dec 21, 2015 at 4:38 PM, Connor Abbott wrote:
>> On Mon, Dec 21, 2015 at 6:39 AM, Marek Olšák wrote:
>>> On Mon, Dec 21, 2015 at 6:48 AM, Jason Ekstrand
>>> wrote:
On Dec 20, 2015 7:43 PM, "Rob Clark" wrote:
>
>
Reviewed-by: Marek Olšák
On Mon, Dec 21, 2015 at 5:57 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This rather silly mistake was introduced by commit 01910676.
>
> Cc: "11.1"
> ---
> src/gallium/drivers/radeon/r600_query.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
On Mon, Dec 21, 2015 at 11:57 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This rather silly mistake was introduced by commit 01910676.
>
> Cc: "11.1"
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/r600_query.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #51 from har...@gmx.de ---
This bug is still present with latest master and still depends on compiler
optimization as described. I have done a run with valgrind, but the results are
not very helpful, WT is not open source and there are
From: Nicolai Hähnle
This rather silly mistake was introduced by commit 01910676.
Cc: "11.1"
---
src/gallium/drivers/radeon/r600_query.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #50 from Nicolai Hähnle ---
We clearly need more info. Please try with latest Mesa master. Does the crash
still depend on compiler optimizations? Have you tried running in Valgrind as
Roland suggested?
--
You are receiving this mail
On Mon, Dec 21, 2015 at 4:38 PM, Connor Abbott wrote:
> On Mon, Dec 21, 2015 at 6:39 AM, Marek Olšák wrote:
>> On Mon, Dec 21, 2015 at 6:48 AM, Jason Ekstrand wrote:
>>>
>>> On Dec 20, 2015 7:43 PM, "Rob Clark" wrote:
On Sun, Dec 20, 2015 at 10:29 PM, Connor Abbott
wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #49 from bellamort...@gmail.com ---
Still occurs with GCC 5.3
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mail
On 21/12/15 03:12, Connor Abbott wrote:
NIR has never been built with MSVC2008, so we shouldn't add
MSVC_2008_COMPAT_CFLAGS to anything that uses it. This allows us to get
rid of the pragma in tgsi_to_nir.c.
Yes, this is much cleaner.
Build tested with freedreno.
Signed-off-by: Connor Abbott
On 19/12/15 22:39, Rob Clark wrote:
From: Rob Clark
We are going to start using nir_builder.h from some gallium code, which
is currently only C90.
Which parts of gallium are you referring to?
> Which results in:
In file included from nir/nir_emulate.c:26:0:
../../../src/glsl/nir/ni
On Mon, Dec 21, 2015 at 6:39 AM, Marek Olšák wrote:
> On Mon, Dec 21, 2015 at 6:48 AM, Jason Ekstrand wrote:
>>
>> On Dec 20, 2015 7:43 PM, "Rob Clark" wrote:
>>>
>>> On Sun, Dec 20, 2015 at 10:29 PM, Connor Abbott
>>> wrote:
>>> > On Sun, Dec 20, 2015 at 10:04 PM, Rob Clark wrote:
>>> >> On S
On 21.12.2015 11:05, Andy Furniss wrote:
Julien Isorce wrote:
Hi Christian,
I have 2 remarks:
1: I am sure you have the clear answer to the following questions, so
maybe add a comment in the commit message: Isn't the thread safety
delegated to the application that use vaapi ? like it is design
On Sun, Dec 20, 2015 at 10:51 PM, Connor Abbott wrote:
> On Sun, Dec 20, 2015 at 10:43 AM, Rob Clark wrote:
>> On Sun, Dec 20, 2015 at 12:25 AM, Connor Abbott wrote:
But, this would still be an issue for tgsi_to_nir, which I guess
wouldn't make sense in glsl/nir. Although turns out we
For the series:
Reviewed-by: Marek Olšák
Marek
On Sun, Dec 20, 2015 at 12:01 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If oViewport is written, vertex reuse need to be turned off.
> If oViewport is constant, vertex reuse is fine, and VPORT_PROVOKE_DISABLE
> need to be set. (we don't have
On Mon, Dec 21, 2015 at 6:48 AM, Jason Ekstrand wrote:
>
> On Dec 20, 2015 7:43 PM, "Rob Clark" wrote:
>>
>> On Sun, Dec 20, 2015 at 10:29 PM, Connor Abbott
>> wrote:
>> > On Sun, Dec 20, 2015 at 10:04 PM, Rob Clark wrote:
>> >> On Sun, Dec 20, 2015 at 9:12 PM, Jason Ekstrand
>> >> wrote:
>> >
Mesa 11.0.8 is now available.
This release brings a significant amount of fixes - from radeonsi
(Fiji, Hyper-Z), r600 (geom. shaders), nouveau (ir), freedreno (piglits),
i965 (UBOs) and a few patches for "GRID Autosport" (i965 and glsl).
Last but not least - a few more BSD related build fixes ar
Julien Isorce wrote:
Hi Christian,
I have 2 remarks:
1: I am sure you have the clear answer to the following questions, so
maybe add a comment in the commit message: Isn't the thread safety
delegated to the application that use vaapi ? like it is designed for
many libraries. I tried to find ans
Hi Christian,
I have 2 remarks:
1: I am sure you have the clear answer to the following questions, so maybe
add a comment in the commit message:
Isn't the thread safety delegated to the application that use vaapi ? like
it is designed for many libraries. I tried to find answer in
vaapi-intel-driv
91 matches
Mail list logo
