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.
> ---
>
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
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 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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=92137
Tapani Pälli changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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
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
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
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 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
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
>
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=93628
Maurits changed:
What|Removed |Added
CC|
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
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
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
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
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
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
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
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
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
> >
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
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
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 ++--
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
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
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
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
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
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
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"
>
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
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
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.
>
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
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
---
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
---
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:
---
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 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
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
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
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
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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
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
I guess some piglit tests also?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
> >
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
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
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
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 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
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.
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).
>
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
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
>
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
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(-)
>
>
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
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,
>
66 matches
Mail list logo