On Fri, 2016-01-15 at 16:36 +0900, Michel Dänzer wrote:
> On 15.01.2016 15:12, Samuel Iglesias =?UNKNOWN?Q?Gons=C3=A1lvez?=
> wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 781d2787bc1cf975757a95d0d9324f734fa61c09
> > URL:http://cgit.freedesktop.org/mesa/mesa/commit/?id=781d2787bc
> > 1
I guess some piglit tests also?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 15.01.2016 15:12, Samuel Iglesias =?UNKNOWN?Q?Gons=C3=A1lvez?= wrote:
> Module: Mesa
> Branch: master
> Commit: 781d2787bc1cf975757a95d0d9324f734fa61c09
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=781d2787bc1cf975757a95d0d9324f734fa61c09
>
> Author: Samuel Iglesias Gonsálvez
The ARB has decided that implicit conversions should be performed for
bitwise operators in future language revisions. Implementations of
current language revisions may or may not perform them.
This patch makes Mesa apply implicti conversions even on current
language versions. Applications appear
From: Michel Dänzer
And only call it from r600_invalidate_resource for buffer resources.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeon/r600_buffer_common.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common
From: Michel Dänzer
Fixes crash in 4 EGL piglit tests with radeonsi.
Signed-off-by: Michel Dänzer
---
src/gallium/state_trackers/dri/dri_drawable.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_drawable.c
b/src/gallium/state_track
On 01/06/2016 03:40 AM, Timothy Arceri wrote:
Even if re-linking fails rendering shouldn't fail as the previous
succesfully linked program will still be available. It also shouldn't
be possible to have an unlinked program as part of the current rendering
state.
This fixes a subtest in:
ES31-CT
Reviewed-by: Samuel Iglesias Gonsálvez
On Fri, 2016-01-15 at 13:45 +1100, Timothy Arceri wrote:
> Any duplicates in a single declaration will already fail the
> generic duplicates test due to the explicit_stream flag being set.
>
> Cc: Samuel Iglesias Gonsálvez
> ---
> src/glsl/ast_type.cpp |
Reviewed-by: Samuel Iglesias Gonsálvez
On Fri, 2016-01-15 at 13:45 +1100, Timothy Arceri wrote:
> This will allow the ARB_shading_language_420pack rules in
> glsl_parser.yy for catching duplicate layout qualifiers to be
> triggered for the stream identifier rather than relying on the
> code meant
On Jan 14, 2016 9:30 PM, "Jordan Justen" wrote:
>
> On 2016-01-14 20:43:17, Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/d
On 2016-01-14 20:43:17, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index eebb485..70ca7
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index eebb485..70ca7cd 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.c
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 6 --
src/mesa/drivers/dri/i965/brw_fs.h| 4 ++--
src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 7 ---
src/mesa/drivers/dri/i965/brw_shader.cpp |
On Thu, 2016-01-14 at 12:24 -0800, Anuj Phogat wrote:
> On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
> wrote:
> > 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
> >compone
On 15.01.2016 05:53, Gustaw Smolarczyk wrote:
> Hi,
>
> After playing CS: GO a bit I have found quite a few of these messages:
>
> Warning: Compiler emitted unknown config register: 0x286d0
>
> The register in question seems to be R_0286D0_SPI_PS_INPUT_ADDR. If I
> understand correctly, it is em
From: Michel Dänzer
Say "LLVM" instead of "Compiler" for clarity.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_shader.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/s
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_shader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 3ab054c..2de7def 100644
--- a/src/gallium/drivers/radeo
This is added by ARB_enhanced_layouts although it doesn't fit
into any of the six main changes so enable it independently.
From the ARB_enhanced_layouts spec:
"More than one layout qualifier may appear in a single
declaration. Additionally, the same layout-qualifier-name
can occur multip
Any duplicates in a single declaration will already fail the
generic duplicates test due to the explicit_stream flag being set.
Cc: Samuel Iglesias Gonsálvez
---
src/glsl/ast_type.cpp | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
index 19ff
This will allow the ARB_shading_language_420pack rules in
glsl_parser.yy for catching duplicate layout qualifiers to be
triggered for the stream identifier rather than relying on the
code meant to catch duplicates within a single layout(...)
Cc: Samuel Iglesias Gonsálvez
---
src/glsl/ast_type.cp
From the ARB_shading_language_420pack spec:
"More than one layout qualifier may appear in a single
declaration. If the same layout-qualifier-name occurs in
multiple layout qualifiers for the same declaration, the
last one overrides the former ones."
Full support will require merging t
From the ARB_shading_language_420pack spec:
"More than one layout qualifier may appear in a single
declaration. If the same layout-qualifier-name occurs in
multiple layout qualifiers for the same declaration, the
last one overrides the former ones."
The parser was already failing corr
The state cache is also L3-backed so it seems sensible to make sure
it's clean as we do for other RO caches before repartitioning the L3.
This wasn't part of my original L3 partitioning code because I was
able to reproduce hangs on Gen7 hardware when the state cache
invalidation happened asynchrono
We need to split the stalling flush from the RO cache invalidation
into a different PIPE_CONTROL command to make sure that the top of the
pipe invalidation happens after any previous rendering is complete.
Otherwise it's possible for previous rendering to pollute the L3 cache
in the short window of
Its previous name was somewhat misleading, this really behaves like a
RW cache flush rather than an invalidation.
---
src/mesa/drivers/dri/i965/brw_pipe_control.c | 2 +-
src/mesa/drivers/dri/i965/brw_program.c | 2 +-
src/mesa/drivers/dri/i965/gen7_l3_state.c| 4 ++--
src/mesa/drivers/dr
From: Roland Scheidegger
This was not really a leak per se, but we were referencing the textures for
longer than intended. If textures were set via llvmpipe_set_sampler_views()
(for fs) and then picked up by lp_setup_set_fragment_sampler_views(), they
were referenced in the setup state. However,
From: Roland Scheidegger
The cleaning up was quite a performance hog (making pipe_resource_reference
the number two in profilers on the vertex path, and 3rd overall, with its
cousin pipe_reference_described not far behind) if there were lots
of tiny draw calls (ipers). Now the reason was really t
Rob Herring 於 西元2016年01月14日 00:20 寫道:
From: Sumit Semwal
Android needs libdrm built statically for recovery;
enable that as well.
Signed-off-by: Sumit Semwal
Signed-off-by: Rob Herring
Cc: Chih-Wei Huang
Cc: Emil Velikov
---
Android.mk | 19 +++
1 file changed, 19 insert
https://bugs.freedesktop.org/show_bug.cgi?id=92000
--- Comment #9 from Alejandro Piñeiro (freenode IRC: apinheiro)
---
(In reply to Daniel Stone from comment #8)
> sure, done now
Just tested. Pushing to piglit working. Thank you very much!
--
You are receiving this mail because:
You are the Q
Hi,
After playing CS: GO a bit I have found quite a few of these messages:
Warning: Compiler emitted unknown config register: 0x286d0
The register in question seems to be R_0286D0_SPI_PS_INPUT_ADDR. If I
understand correctly, it is emitted by LLVM AMDGPU backend.
Is it something I should worry
On Thu, Jan 14, 2016 at 12:08 PM, Jason Ekstrand wrote:
> BDW adds the following restriction: "When multiplying DW x DW, the dst
> cannot be accumulator."
> ---
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/driv
On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
wrote:
> 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
>w
On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
wrote:
> This will also be used by tessellation packing code
> in a following patch.
> ---
> src/glsl/lower_packed_varyings.cpp | 45
> +-
> 1 file changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/src/
On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
wrote:
> ---
> src/glsl/lower_packed_varyings.cpp | 58
> +++---
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/src/glsl/lower_packed_varyings.cpp
> b/src/glsl/lower_packed_varyings.cpp
> index
https://bugs.freedesktop.org/show_bug.cgi?id=92000
--- Comment #8 from Daniel Stone ---
sure, done now
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lis
BDW adds the following restriction: "When multiplying DW x DW, the dst
cannot be accumulator."
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_ni
H well I set ->surface_based = TRUE on texture views. It
seemed to correspond to the restrictions of surface-based elsewhere,
but I probably wasn't 100% sure what the deal was back when I added
the logic.
On Thu, Jan 14, 2016 at 2:38 PM, Marek Olšák wrote:
> Hi Ilia,
>
> surface_based ori
Hi Ilia,
surface_based originally meant that the resource has been imported
from a DMABUF or GEM FLINK handle. Such resources can't be reallocated
ever, nor can they be mipmapped.
Marek
On Thu, Jan 14, 2016 at 7:46 PM, Ilia Mirkin wrote:
> This fixes the recently posted mipmap + texture views p
Looks good to me.
Reviewed-by: Roland Scheidegger
Am 14.01.2016 um 19:46 schrieb Ilia Mirkin:
> This fixes the recently posted mipmap + texture views piglit test.
>
> Signed-off-by: Ilia Mirkin
> Cc: "11.0 11.1"
> ---
> src/mesa/state_tracker/st_gen_mipmap.c | 10 --
> 1 file changed
On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
wrote:
> Rather than passing in the vertex count to the packing pass just use
> the outermost array size to get the count.
> ---
> src/glsl/ir_optimization.h | 3 +-
> src/glsl/link_varyings.cpp | 21 ---
> src/glsl/lower_pa
On Thursday, January 14, 2016 10:24:32 AM PST Matt Turner wrote:
> On Wed, Jan 13, 2016 at 8:33 PM, Kenneth Graunke
wrote:
> > gl_PointSize is delivered in the .w component of the VUE header, while
> > the language expects it to be a float (and thus in the .x component).
> >
> > Previously, we e
On Thursday, January 14, 2016 10:26:37 AM PST Matt Turner wrote:
> On Wed, Jan 13, 2016 at 8:33 PM, Kenneth Graunke
wrote:
> > This is no longer necessary...and it doesn't make much sense to
> > have inputs as destinations.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
>
> I don't think I rea
On Thursday, January 14, 2016 10:23:45 AM PST Matt Turner wrote:
> On Wed, Jan 13, 2016 at 8:33 PM, Kenneth Graunke
wrote:
> > This patch re-implements the pre-Haswell VS attribute workarounds.
> > Instead of emitting shader code in the vec4 backend, we now simply
> > call a NIR pass to emit the
This fixes the recently posted mipmap + texture views piglit test.
Signed-off-by: Ilia Mirkin
Cc: "11.0 11.1"
---
src/mesa/state_tracker/st_gen_mipmap.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_gen_mipmap.c
b/src/mesa/state_tracke
On Wed, Jan 13, 2016 at 8:33 PM, Kenneth Graunke wrote:
> This is no longer necessary...and it doesn't make much sense to
> have inputs as destinations.
>
> Signed-off-by: Kenneth Graunke
> ---
I don't think I realized they were ever destinations. I'm confused about how the
switch (inst->dst
On Wed, Jan 13, 2016 at 8:33 PM, Kenneth Graunke wrote:
> gl_PointSize is delivered in the .w component of the VUE header, while
> the language expects it to be a float (and thus in the .x component).
>
> Previously, we emitted MOVs to copy it over to the .x component.
> But this is silly - we can
On Wed, Jan 13, 2016 at 8:33 PM, Kenneth Graunke wrote:
> This patch re-implements the pre-Haswell VS attribute workarounds.
> Instead of emitting shader code in the vec4 backend, we now simply
> call a NIR pass to emit the necessary code.
>
> This simplifies the vec4 backend. Beyond deleting cod
https://bugs.freedesktop.org/show_bug.cgi?id=92000
--- Comment #7 from Alejandro Piñeiro (freenode IRC: apinheiro)
---
(In reply to Daniel Stone from comment #6)
> done
Hi, although I was able to push commits on mesa since September 2015, today I
realized that I don't have commit right to pigli
On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
wrote:
> 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 fil
On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
wrote:
> 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_
Patches 1-4 are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jan 13, 2016 at 9:26 PM, Timothy Arceri
wrote:
> The special case from detecting stream duplicates is also
> removed, as testing never trigged this error.
>
> From the ARB_shading_language_420pack spec:
>
>"More than one layout qualifier may appear in a single
>declaration. If the
https://bugs.freedesktop.org/show_bug.cgi?id=93628
Maurits changed:
What|Removed |Added
CC||maurits.fassa...@gmail.com
--- Comment #2 from
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #5 from ytr...@sdf-eu.org ---
(In reply to Roland Scheidegger from comment #4)
> (In reply to ytrezq from comment #3)
> I'm not sure what you exactly mean here: They do "load balancing" with
> multiple gpus as part of SLI
You don’t ne
Reviewed-by: Marek Olšák
Marek
On Thu, Jan 14, 2016 at 12:41 AM, Brian Paul wrote:
> We check that a bunch of raster operations are disabled in
> blit_copy_pixels(). We also need to check that color logicop is
> disabled.
> ---
> src/mesa/state_tracker/st_cb_drawpixels.c | 1 +
> 1 file chang
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #4 from Roland Scheidegger ---
(In reply to ytrezq from comment #3)
> I don’t think it’s necessary to combine 5 years old low end 90nm gpu with a
> 14nm high end cpu. For example (comparing the hd 2500 integrated graphic of
> my ivy
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #3 from ytr...@sdf-eu.org ---
(In reply to Roland Scheidegger from comment #2)
> I'm not sure if this exact same proposal really came up already. We have
> seen some though asking if we couldn't combine llvmpipe with less capable
> gpu
On Thu, 2016-01-14 at 14:15 +0200, Tapani Pälli wrote:
> If shader declares uniform explicit location in one stage but
> implicit in another, explicit location should be used. Patch marks
> implicit uniforms as explicit if they were explicit in previous
> stage.
> This makes sure that we don't trea
If shader declares uniform explicit location in one stage but
implicit in another, explicit location should be used. Patch marks
implicit uniforms as explicit if they were explicit in previous stage.
This makes sure that we don't treat them implicit later when assigning
locations.
Fixes following
On 01/14/2016 01:49 PM, Timothy Arceri wrote:
On Thu, 2016-01-14 at 13:02 +0200, Tapani Pälli wrote:
If shader declares uniform explicit location in one stage but
implicit in
another, explicit location should be used. Patch marks implicit
uniforms
as explicit if they were explicit in another s
https://bugs.freedesktop.org/show_bug.cgi?id=92137
--- Comment #6 from Tapani Pälli ---
Fixed by
--- 8<
commit c3ec12ec3c1ddbc72e50df1f5632fe0547a89f7e
Author: Timothy Arceri
Date: Thu Nov 26 21:32:48 2015 +1100
glsl: don't generate extra errors in ValidateProgramPipeline
From S
On Thu, 2016-01-14 at 13:02 +0200, Tapani Pälli wrote:
> If shader declares uniform explicit location in one stage but
> implicit in
> another, explicit location should be used. Patch marks implicit
> uniforms
> as explicit if they were explicit in another stage. This makes sure
> that
> we don't t
https://bugs.freedesktop.org/show_bug.cgi?id=92137
Tapani Pälli changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
If shader declares uniform explicit location in one stage but implicit in
another, explicit location should be used. Patch marks implicit uniforms
as explicit if they were explicit in another stage. This makes sure that
we don't treat them implicit later when assigning locations.
Fixes following C
On 01/14/2016 09:38 AM, Samuel Iglesias Gonsálvez wrote:
Only modify interpolation type for integer-based varyings or when the
consumer is known and different than fragment shader.
If we are linking separate shader programs and the consumer is unknown,
the consumer could be added later and be
66 matches
Mail list logo
