With OpenCL, kernels can take arguments and return values (?). However
in practice, there is no more TGSI compute implementation, and even if
there were, it would probably have named functions and no explicit main.
This improves RA considerably for compute shaders, since temps are not
kept around
This can happen if it's e.g. a uniform or a function argument.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111217
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +++--
1 file changed, 3 insertions(+), 2
The meson conversion chose to change the meaning of DEBUG to "used for
debugging" to be "used for expensive things for debugging", primarily
for nir_validate. Flip things over so that we get nice things with
optimizations enabled.
While we're at it, also kill off nouveau_statebuf.h which is unused
Previously the code only handled it for positions 1 and up (as would be
for UBO's in GL). It's not a lot of trouble to handle this, and vl or
vdpau want this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
.../dr
Apparently vl (or vdpau) wants to pass that in now. Handle it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_state.c | 14 --
src/gallium/drivers/nouveau/nvc0/nv
This caused nouveau's function handling logic to think that the MAIN
function was due to receive external parameters, and cascaded some
failures after that. Instead avoid having the undefined components in
the first place.
Fixes: f6ac0b5d71 (gallium/auxiliary/vl: Add compute shader to support vide
Reviewed-by: Samuel Pitoiset
On 7/25/19 4:55 PM, Bas Nieuwenhuizen wrote:
Without correct size, radeonsi assumes the metadata is incorrect,
which can and will cause issues.
Since the metadata is really incorrect without the size, let us
fix that.
Fixes: e43cc3e3afc "radv/gfx9: handle GFX9 opa
Without correct size, radeonsi assumes the metadata is incorrect,
which can and will cause issues.
Since the metadata is really incorrect without the size, let us
fix that.
Fixes: e43cc3e3afc "radv/gfx9: handle GFX9 opaque metadata"
---
src/amd/vulkan/radv_image.c | 3 ++-
1 file changed, 2 inse
bleh, you're right
So we should not be using DCC ...
On Thu, Jul 25, 2019 at 4:37 PM Samuel Pitoiset
wrote:
>
> It's already disabled later in this function?
>
> On 7/25/19 4:34 PM, Bas Nieuwenhuizen wrote:
> > (a) radv does not set the DCC fields required yet.
> > (b) radeonsi just broke t
It's already disabled later in this function?
On 7/25/19 4:34 PM, Bas Nieuwenhuizen wrote:
(a) radv does not set the DCC fields required yet.
(b) radeonsi just broke their DCC metadata.
Fixes: f8b6c5a1a63 "radeonsi: rewrite si_get_opaque_metadata, also for gfx10
support"
---
src/amd/vulkan/r
(a) radv does not set the DCC fields required yet.
(b) radeonsi just broke their DCC metadata.
Fixes: f8b6c5a1a63 "radeonsi: rewrite si_get_opaque_metadata, also for gfx10
support"
---
src/amd/vulkan/radv_image.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amd/vulkan/radv_image.c
On 7/25/19 3:39 PM, Bas Nieuwenhuizen wrote:
r-b
though it sounds like some of our cache flushes might be not ideal.
Yes.
On Thu, Jul 25, 2019 at 3:35 PM Samuel Pitoiset
wrote:
It's coherent and faster. GFX7-GFX9 should also support this but
for now only uses L2 for GFX10 because it's unte
r-b
though it sounds like some of our cache flushes might be not ideal.
On Thu, Jul 25, 2019 at 3:35 PM Samuel Pitoiset
wrote:
>
> It's coherent and faster. GFX7-GFX9 should also support this but
> for now only uses L2 for GFX10 because it's untested on previous gens.
>
> This fixes dEQP-VK.memo
It's coherent and faster. GFX7-GFX9 should also support this but
for now only uses L2 for GFX10 because it's untested on previous gens.
This fixes dEQP-VK.memory.pipeline_barrier.transfer_*
This also fixes some missing geometry in Dawn Of War III because
VBOs weren't updated correctly.
Signed-of
A-b
On Thu, Jul 25, 2019 at 01:26:07PM +0200, Tomeu Vizoso wrote:
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/ci/debian-install.sh | 4 ++--
> src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/debian-install.sh | 4 ++--
src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/debian-install.sh
b/src/gallium/drivers/panfrost/ci
https://bugs.freedesktop.org/show_bug.cgi?id=111200
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEEDINFO
https://bugs.freedesktop.org/show_bug.cgi?id=111200
--- Comment #2 from Matt ---
Thanks Bas - that's fixed the corruption on my current snapshot
Further to the newness of the navi support - should we as users be logging bugs
for general instability or should we just be patient as the support fo
On Wed, Jul 24, 2019 at 4:47 PM Samuel Pitoiset
wrote:
>
> This fixes
> dEQP-VK.rasterization.primitive_size.points.point_size_*
>
> This also fixes some black squares with the Sascha SSAO demo.
>
> v2: - do not set for multiple channels
> - call vi_alpha_is_on_msb() for pre-GFX10
> - remo
https://bugs.freedesktop.org/show_bug.cgi?id=41
--- Comment #17 from Connor Abbott ---
No, crashing when replaying is definitely not expected, although the result of
some bug could definitely be a GPU hang. It's really strange, though, since I
can replay it just fine on my machine with a simi
https://bugs.freedesktop.org/show_bug.cgi?id=50
--- Comment #9 from Illia Iorin ---
(In reply to Nanley Chery from comment #7)
> I just updated the MR to fix the issue in iris. Please let me know if it
> still helps.
Updated MR fixes assert in WRC5.
--
You are receiving this mail becaus
21 matches
Mail list logo
