[Mesa-dev] [PATCH] meson: Add dep_thread dependency.
Fix this build error on Ubuntu 18.04. /usr/bin/ld: src/util/libmesa_util.a(u_cpu_detect.c.o): undefined reference to symbol 'pthread_once@@GLIBC_2.2.5' Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110663 Suggested-by: Eric Engestrom Signed-off-by: Vinson Lee --- src/gallium/tests/trivial/meson.build | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/tests/trivial/meson.build b/src/gallium/tests/trivial/meson.build index bbb25519e12..1f912d5aa46 100644 --- a/src/gallium/tests/trivial/meson.build +++ b/src/gallium/tests/trivial/meson.build @@ -24,6 +24,7 @@ foreach t : ['compute', 'tri', 'quad-tex'] '@0@.c'.format(t), include_directories : inc_common, link_with : [libmesa_util, libgallium, libpipe_loader_dynamic], +dependencies : dep_thread, install : false, ) endforeach -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] radeonsi: don't use the low-optimizing compiler on LLVM 9
For the series
Tested-by: Dieter Nützel
on Polaris 20
Have a look here, too.
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1106085-linux-kernel-set-to-expose-hidden-nvidia-hda-controllers-helping-laptop-users?p=1106199#post1106199
Dieter
Am 13.06.2019 02:40, schrieb Marek Olšák:
From: Marek Olšák
The compilation is faster on LLVM 9.
---
src/gallium/drivers/radeonsi/si_pipe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 8527999645b..d2fd058f2cd 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -115,21 +115,22 @@ static const struct debug_named_value
debug_options[] = {
DEBUG_NAMED_VALUE_END /* must be last */
};
static void si_init_compiler(struct si_screen *sscreen,
struct ac_llvm_compiler *compiler)
{
/* Only create the less-optimizing version of the compiler on APUs
* predating Ryzen (Raven). */
bool create_low_opt_compiler = !sscreen->info.has_dedicated_vram &&
- sscreen->info.chip_class <= GFX8;
+ sscreen->info.chip_class <= GFX8 &&
+ HAVE_LLVM < 0x0900;
enum ac_target_machine_options tm_options =
(sscreen->debug_flags & DBG(SI_SCHED) ? AC_TM_SISCHED : 0) |
(sscreen->debug_flags & DBG(GISEL) ? AC_TM_ENABLE_GLOBAL_ISEL :
0) |
(sscreen->info.chip_class >= GFX9 ? AC_TM_FORCE_ENABLE_XNACK :
0) |
(sscreen->info.chip_class < GFX9 ? AC_TM_FORCE_DISABLE_XNACK :
0) |
(!sscreen->llvm_has_working_vgpr_indexing ?
AC_TM_PROMOTE_ALLOCA_TO_SCRATCH : 0) |
(sscreen->debug_flags & DBG(CHECK_IR) ? AC_TM_CHECK_IR : 0) |
(create_low_opt_compiler ? AC_TM_CREATE_LOW_OPT : 0);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations
Am 13.06.2019 07:10, schrieb Marek Olšák:
FYI, I just pushed the new linker.
Marek
Thank you very much Marek and _Nicolai_ for this GREAT stuff.
It brings back some speed after 1/8 drop with glmark2, lately.
Maybe my amd-staging-drm-next tree (5.2-rc1) didn't honor the kernel
mitigation parameter right.
@Jan
Go ahead with your nice relocation and image work.
Send me what you have in the works.
Latest Mesa git (with Nicolai's new linker) let all 3 luxmark versions
run.
Only 'Hotel lobby' (with v3.0 and v3.1) show some corruption but do NOT
crash any longer. Numbers for 'Neumann TLM-102 SE' (medium) show ~43000K
(!!!).
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1106085-linux-kernel-set-to-expose-hidden-nvidia-hda-controllers-helping-laptop-users?p=1106199#post1106199
Blender crash as expected ;-)
/home/dieter> trying to save userpref at
/home/dieter/.config/blender/2.79/config/userpref.blend ok
Read blend: /data/Blender/barbershop_interior_gpu.blend
scripts disabled for "/data/Blender/barbershop_interior_gpu.blend",
skipping 'generate_customprops.py'
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
skipping driver 'var', automatic scripts are disabled
Device init success
Compiling OpenCL program split
Kernel compilation of split finished in 8.41s.
Compiling OpenCL program base
Kernel compilation of base finished in 4.55s.
Compiling OpenCL program denoising
Kernel compilation of denoising finished in 2.08s.
blender: ../src/gallium/drivers/radeonsi/si_compute.c:319:
si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS'
failed.
[1]Abbruch blender (core dumped)
Gretings,
Dieter
On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely
wrote:
Fixes piglits:
call.cl [1]
calls-larget-struct.cl [2]
calls-struct.cl [3]
calls-workitem-id.cl [4]
realign-stack.cl [5]
tail-calls.cl [6]
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely
---
The piglit test now pass using llvm-7,8,git.
ImageMagick works on my raven, but some test still fail on
carrizo/iceland.
Other workloads (like shoc) that used function calls also work ok.
ocltoys work after removing static keyword from .cl files.
src/amd/common/ac_binary.c| 30
+++
src/gallium/drivers/radeonsi/si_compute.c | 6 -
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index 18dc72c61f0..4d152fcf1be 100644
--- a/src/amd/common/ac_binary.c
+++ b/src/amd/common/ac_binary.c
@@ -178,6 +178,36 @@ bool ac_elf_read(const char *elf_data, unsigned
elf_size,
parse_relocs(elf, relocs, symbols, symbol_sh_link, binary);
+ // Apply relocations
+ for (int i = 0; i < binary->reloc_count; ++i) {
+ struct ac_shader_reloc *r = >relocs[i];
+ uint32_t *loc = (uint32_t*)(binary->code +
r->offset);
+ /* Section target relocations store symbol offsets
as
+* values in reloc location. We're expected to
adjust it for
+* start of the section. However, R_AMDGPU_REL32 are
+* PC relative relocations, so we need to recompute
the
+* delta between reloc locatin and the target
adress.
+*/
+ if (r->target_type == 0x3) { // section relocation
+ uint32_t target_offset = *loc; // already
adjusted
+ int64_t diff = target_offset - r->offset;
+ if (r->type == 0xa) { // R_AMDGPU_REL32_LO
+ // address of the 'lo' instruction
is 4B below
+ // the relocation point, but the
target has
+ // alredy been adjusted.
+ *loc = (diff & 0x);
+ } else if (r->type == 0xb) { //
R_AMDGPU_REL32_HI
+ // 'hi' relocation is 8B above 'lo'
relocation
+ *loc = ((diff - 8) >> 32);
+ } else {
+ success = false;
+ fprintf(stderr, "Unsupported section
relocation: type: %d, offset: %lx, value: %x\n",
+ r->type, r->offset,
*loc);
+ }
+ } else
+ success = false;
+ }
+
if (elf){
elf_end(elf);
}
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index b9cea00eeeb..88631369a62 100644
---
[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 105113, which changed state.
Bug 105113 Summary: [hawaii, radeonsi, clover] Running Piglit
cl/program/execute/{,tail-}calls{,-struct,-workitem-id}.cl cause GPU VM error
and ring stalled GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=105113
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations
On Thu, 2019-06-13 at 01:10 -0400, Marek Olšák wrote:
> FYI, I just pushed the new linker.
thanks. I've checked the handling and the current approach works for
sections as well (even if not handled explicitly).
Jan
>
> Marek
>
> On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely wrote:
>
> > Fixes piglits:
> > call.cl
> > calls-larget-struct.cl
> > calls-struct.cl
> > calls-workitem-id.cl
> > realign-stack.cl
> > tail-calls.cl
> >
> > Cc: mesa-sta...@lists.freedesktop.org
> > Signed-off-by: Jan Vesely
> > ---
> > The piglit test now pass using llvm-7,8,git.
> > ImageMagick works on my raven, but some test still fail on
> > carrizo/iceland.
> > Other workloads (like shoc) that used function calls also work ok.
> > ocltoys work after removing static keyword from .cl files.
> > src/amd/common/ac_binary.c| 30 +++
> > src/gallium/drivers/radeonsi/si_compute.c | 6 -
> > 2 files changed, 30 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
> > index 18dc72c61f0..4d152fcf1be 100644
> > --- a/src/amd/common/ac_binary.c
> > +++ b/src/amd/common/ac_binary.c
> > @@ -178,6 +178,36 @@ bool ac_elf_read(const char *elf_data, unsigned
> > elf_size,
> >
> > parse_relocs(elf, relocs, symbols, symbol_sh_link, binary);
> >
> > + // Apply relocations
> > + for (int i = 0; i < binary->reloc_count; ++i) {
> > + struct ac_shader_reloc *r = >relocs[i];
> > + uint32_t *loc = (uint32_t*)(binary->code + r->offset);
> > + /* Section target relocations store symbol offsets as
> > +* values in reloc location. We're expected to adjust it
> > for
> > +* start of the section. However, R_AMDGPU_REL32 are
> > +* PC relative relocations, so we need to recompute the
> > +* delta between reloc locatin and the target adress.
> > +*/
> > + if (r->target_type == 0x3) { // section relocation
> > + uint32_t target_offset = *loc; // already adjusted
> > + int64_t diff = target_offset - r->offset;
> > + if (r->type == 0xa) { // R_AMDGPU_REL32_LO
> > + // address of the 'lo' instruction is 4B
> > below
> > + // the relocation point, but the target has
> > + // alredy been adjusted.
> > + *loc = (diff & 0x);
> > + } else if (r->type == 0xb) { // R_AMDGPU_REL32_HI
> > + // 'hi' relocation is 8B above 'lo'
> > relocation
> > + *loc = ((diff - 8) >> 32);
> > + } else {
> > + success = false;
> > + fprintf(stderr, "Unsupported section
> > relocation: type: %d, offset: %lx, value: %x\n",
> > + r->type, r->offset, *loc);
> > + }
> > + } else
> > + success = false;
> > + }
> > +
> > if (elf){
> > elf_end(elf);
> > }
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> > b/src/gallium/drivers/radeonsi/si_compute.c
> > index b9cea00eeeb..88631369a62 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -246,12 +246,6 @@ static void *si_create_compute_state(
> > const amd_kernel_code_t *code_object =
> > si_compute_get_code_object(program, 0);
> > code_object_to_config(code_object,
> > >shader.config);
> > - if (program->shader.binary.reloc_count != 0) {
> > - fprintf(stderr, "Error: %d unsupported
> > relocations\n",
> > -
> > program->shader.binary.reloc_count);
> > - FREE(program);
> > - return NULL;
> > - }
> > } else {
> >
> > si_shader_binary_read_config(>shader.binary,
> > >shader.config, 0);
> > --
> > 2.21.0
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-stabledata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C799b455386104f3a30dd08d6efbd81dc%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636959994551504256sdata=E5usx69EyFtABg3cn24Q5idNveyntDYJ7xR5a7K%2BboA%3Dreserved=0
--
Jan Vesely
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
Re: [Mesa-dev] [PATCH 2/2] ac: make ac_compute_cmask() a static function
Reviewed-by: Marek Olšák
Marek
On Thu, Jun 13, 2019 at 11:14 AM Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_surface.c | 6 +++---
> src/amd/common/ac_surface.h | 4
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index 28256352cb7..7b86cb1e1f2 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -552,9 +552,9 @@ static int gfx6_surface_settings(ADDR_HANDLE addrlib,
> return 0;
> }
>
> -void ac_compute_cmask(const struct radeon_info *info,
> - const struct ac_surf_config *config,
> - struct radeon_surf *surf)
> +static void ac_compute_cmask(const struct radeon_info *info,
> +const struct ac_surf_config *config,
> +struct radeon_surf *surf)
> {
> unsigned pipe_interleave_bytes = info->pipe_interleave_bytes;
> unsigned num_pipes = info->num_tile_pipes;
> diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
> index 08aac94d3a9..49f68f4fc92 100644
> --- a/src/amd/common/ac_surface.h
> +++ b/src/amd/common/ac_surface.h
> @@ -261,10 +261,6 @@ int ac_compute_surface(ADDR_HANDLE addrlib, const
> struct radeon_info *info,
>enum radeon_surf_mode mode,
>struct radeon_surf *surf);
>
> -void ac_compute_cmask(const struct radeon_info *info,
> - const struct ac_surf_config *config,
> - struct radeon_surf *surf);
> -
> #ifdef __cplusplus
> }
> #endif
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add z24s8_as_r8g8b8a8 format
I'm OK with this.
Reviewed-by: Marek Olšák
Marek
On Thu, Jun 13, 2019 at 1:39 PM Rob Clark wrote:
> From: Rob Clark
>
> This maps to a special format that recent generations of adreno have,
> for blitting z24s8. Conceptually it is similar to doing Z and/or S
> blits by pretending it is r8g8b8a8 (with appropriate writemask). But
> it differs when bandwidth compression is used, as z24 is a different
> type from r8g8b8.
>
> Signed-off-by: Rob Clark
> ---
> This is part of:
>
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1088
>
> but sending to list to give better visibility.
>
> src/gallium/auxiliary/util/u_format.csv | 7 +++
> src/gallium/drivers/svga/svga_format.c | 1 +
> src/gallium/include/pipe/p_format.h | 2 ++
> 3 files changed, 10 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_format.csv
> b/src/gallium/auxiliary/util/u_format.csv
> index 51a08bd6530..039b5fa9141 100644
> --- a/src/gallium/auxiliary/util/u_format.csv
> +++ b/src/gallium/auxiliary/util/u_format.csv
> @@ -144,6 +144,13 @@ PIPE_FORMAT_X8Z24_UNORM , plain, 1, 1,
> x8 , un24, , , y___,
> PIPE_FORMAT_Z32_FLOAT_S8X24_UINT, plain, 1, 1, f32 , up8 , x24,
> , xy__, zs,f32 , x24 , up8, , xz__
> PIPE_FORMAT_X32_S8X24_UINT , plain, 1, 1, x32 , up8 , x24,
> , _y__, zs,x32 , x24 , up8, , _z__
>
> +# Depth-stencil formats equivalent to blitting
> PIPE_FORMAT_Z24_UNORM_S8_UINT
> +# as PIPE_FORMAT_R8G8B8A8_*, in that it is an equivalent size to the z/s
> +# format. This is mainly for hw that has some sort of bandwidth
> compressed
> +# format where the compression for z24s8 is not equivalent to r8g8b8a8,
> +# and therefore some special handling is required for blits.
> +PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8 , plain, 1, 1, un8 , un8 , un8
> , un8 , xyzw, rgb
> +
> # YUV formats
> # http://www.fourcc.org/yuv.php#UYVY
> PIPE_FORMAT_UYVY , subsampled, 2, 1, x32 , , ,
> , xyz1, yuv
> diff --git a/src/gallium/drivers/svga/svga_format.c
> b/src/gallium/drivers/svga/svga_format.c
> index 830ff0a1e6b..84134018c17 100644
> --- a/src/gallium/drivers/svga/svga_format.c
> +++ b/src/gallium/drivers/svga/svga_format.c
> @@ -378,6 +378,7 @@ static const struct vgpu10_format_entry
> format_conversion_table[] =
> { PIPE_FORMAT_ATC_RGB, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> { PIPE_FORMAT_ATC_RGBA_EXPLICIT, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> { PIPE_FORMAT_ATC_RGBA_INTERPOLATED, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> + { PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID,SVGA3D_FORMAT_INVALID, 0 },
> };
>
>
> diff --git a/src/gallium/include/pipe/p_format.h
> b/src/gallium/include/pipe/p_format.h
> index a4401658f5f..42908e9a720 100644
> --- a/src/gallium/include/pipe/p_format.h
> +++ b/src/gallium/include/pipe/p_format.h
> @@ -407,6 +407,8 @@ enum pipe_format {
> PIPE_FORMAT_ATC_RGBA_EXPLICIT = 318,
> PIPE_FORMAT_ATC_RGBA_INTERPOLATED = 319,
>
> + PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8 = 320,
> +
> PIPE_FORMAT_COUNT
> };
>
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: update GL headers from the registry
Kind ping. Marek On Tue, Jun 11, 2019 at 8:06 PM Marek Olšák wrote: > From: Marek Olšák > > --- > include/GL/glcorearb.h | 261 +++ > include/GL/glext.h | 269 + > include/GLES/gl.h | 21 +--- > include/GLES/glext.h | 35 +- > include/GLES2/gl2.h| 6 +- > include/GLES2/gl2ext.h | 201 +- > include/GLES3/gl3.h| 8 +- > include/GLES3/gl31.h | 18 ++- > include/GLES3/gl32.h | 18 ++- > src/util/disk_cache.c | 1 + > 10 files changed, 692 insertions(+), 146 deletions(-) > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely
https://bugs.freedesktop.org/show_bug.cgi?id=110697 --- Comment #13 from QwertyChouskie --- (In reply to Michel Dänzer from comment #12) > (In reply to QwertyChouskie from comment #11) > > Whoops, missed that they were posted in a comment further down. Here they > > are again for reference: > > I did follow those steps. At this point tildearrow will have to weigh in. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: add radeon_info::is_amdgpu instead of checking drm_major == 3
It's only a random cleanup. Marek On Thu, Jun 13, 2019 at 2:57 AM Samuel Pitoiset wrote: > Why do you need that? > > On 6/12/19 11:31 PM, Marek Olšák wrote: > > From: Marek Olšák > > > > and clean up > > --- > > src/amd/common/ac_gpu_info.c | 13 -- > > src/amd/common/ac_gpu_info.h | 1 + > > src/amd/vulkan/radv_debug.c | 5 +- > > src/gallium/drivers/r600/r600_buffer_common.c | 6 +-- > > src/gallium/drivers/r600/r600_pipe.c | 2 +- > > src/gallium/drivers/r600/r600_pipe_common.c | 46 ++- > > src/gallium/drivers/r600/r600_query.c | 2 +- > > src/gallium/drivers/r600/r600_texture.c | 2 +- > > src/gallium/drivers/r600/radeon_uvd.c | 3 +- > > src/gallium/drivers/r600/radeon_vce.c | 5 +- > > src/gallium/drivers/radeon/radeon_uvd.c | 2 +- > > src/gallium/drivers/radeon/radeon_vce.c | 6 +-- > > src/gallium/drivers/radeonsi/si_buffer.c | 2 +- > > src/gallium/drivers/radeonsi/si_debug.c | 2 +- > > src/gallium/drivers/radeonsi/si_get.c | 4 +- > > src/gallium/drivers/radeonsi/si_pipe.c| 4 +- > > src/gallium/drivers/radeonsi/si_query.c | 2 +- > > src/gallium/drivers/radeonsi/si_state.c | 2 +- > > .../winsys/radeon/drm/radeon_drm_winsys.c | 1 + > > 19 files changed, 33 insertions(+), 77 deletions(-) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Fix general purpose varying handling
Reviewed-by: Alyssa Rosenzweig ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add z24s8_as_r8g8b8a8 format
From: Rob Clark
This maps to a special format that recent generations of adreno have,
for blitting z24s8. Conceptually it is similar to doing Z and/or S
blits by pretending it is r8g8b8a8 (with appropriate writemask). But
it differs when bandwidth compression is used, as z24 is a different
type from r8g8b8.
Signed-off-by: Rob Clark
---
This is part of:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1088
but sending to list to give better visibility.
src/gallium/auxiliary/util/u_format.csv | 7 +++
src/gallium/drivers/svga/svga_format.c | 1 +
src/gallium/include/pipe/p_format.h | 2 ++
3 files changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 51a08bd6530..039b5fa9141 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -144,6 +144,13 @@ PIPE_FORMAT_X8Z24_UNORM , plain, 1, 1, x8 ,
un24, , , y___,
PIPE_FORMAT_Z32_FLOAT_S8X24_UINT, plain, 1, 1, f32 , up8 , x24, ,
xy__, zs,f32 , x24 , up8, , xz__
PIPE_FORMAT_X32_S8X24_UINT , plain, 1, 1, x32 , up8 , x24, ,
_y__, zs,x32 , x24 , up8, , _z__
+# Depth-stencil formats equivalent to blitting PIPE_FORMAT_Z24_UNORM_S8_UINT
+# as PIPE_FORMAT_R8G8B8A8_*, in that it is an equivalent size to the z/s
+# format. This is mainly for hw that has some sort of bandwidth compressed
+# format where the compression for z24s8 is not equivalent to r8g8b8a8,
+# and therefore some special handling is required for blits.
+PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8 , plain, 1, 1, un8 , un8 , un8 , un8
, xyzw, rgb
+
# YUV formats
# http://www.fourcc.org/yuv.php#UYVY
PIPE_FORMAT_UYVY , subsampled, 2, 1, x32 , , , ,
xyz1, yuv
diff --git a/src/gallium/drivers/svga/svga_format.c
b/src/gallium/drivers/svga/svga_format.c
index 830ff0a1e6b..84134018c17 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -378,6 +378,7 @@ static const struct vgpu10_format_entry
format_conversion_table[] =
{ PIPE_FORMAT_ATC_RGB, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_ATC_RGBA_EXPLICIT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_ATC_RGBA_INTERPOLATED, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID,SVGA3D_FORMAT_INVALID, 0 },
};
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index a4401658f5f..42908e9a720 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -407,6 +407,8 @@ enum pipe_format {
PIPE_FORMAT_ATC_RGBA_EXPLICIT = 318,
PIPE_FORMAT_ATC_RGBA_INTERPOLATED = 319,
+ PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8 = 320,
+
PIPE_FORMAT_COUNT
};
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: ci: Update test expectations
Both R-b, thank you! Wonder what's up with the RK3288 regressions ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] panfrost: ci: Update test expectations
Some tests got fixed since the last update, but also some regressions crept in. To keep the CI green, add the regressions to the expected failures. Signed-off-by: Tomeu Vizoso --- .../drivers/panfrost/ci/expected-failures.txt | 98 +-- 1 file changed, 5 insertions(+), 93 deletions(-) diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt b/src/gallium/drivers/panfrost/ci/expected-failures.txt index 9cbea0c6bfd8..c53869665545 100644 --- a/src/gallium/drivers/panfrost/ci/expected-failures.txt +++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt @@ -8,8 +8,6 @@ dEQP-GLES2.functional.color_clear.scissored_rgb dEQP-GLES2.functional.color_clear.scissored_rgba dEQP-GLES2.functional.color_clear.short_scissored_rgb dEQP-GLES2.functional.fbo.completeness.size.distinct -dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgb565 -dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgb565_depth_component16 dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgb5_a1 dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgb5_a1_depth_component16 dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgba4 @@ -54,6 +52,7 @@ dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgba_depth_co dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgba_stencil_index8 dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgb dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgba +dEQP-GLES2.functional.fbo.render.resize.rbo_rgb565_stencil_index8 dEQP-GLES2.functional.fbo.render.resize.rbo_rgb5_a1 dEQP-GLES2.functional.fbo.render.resize.rbo_rgb5_a1_depth_component16 dEQP-GLES2.functional.fbo.render.resize.rbo_rgb5_a1_stencil_index8 @@ -70,28 +69,25 @@ dEQP-GLES2.functional.fbo.render.shared_colorbuffer.rbo_rgb565_depth_component16 dEQP-GLES2.functional.fbo.render.shared_colorbuffer.rbo_rgb565_stencil_index8 dEQP-GLES2.functional.fbo.render.shared_colorbuffer.rbo_rgba4_depth_component16 dEQP-GLES2.functional.fbo.render.shared_colorbuffer.rbo_rgba4_stencil_index8 -dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgb dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgb_depth_component16 dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgb_stencil_index8 -dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgba dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgba_depth_component16 dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgba_stencil_index8 dEQP-GLES2.functional.fbo.render.shared_colorbuffer_clear.rbo_rgb5_a1 dEQP-GLES2.functional.fbo.render.shared_colorbuffer_clear.rbo_rgba4 dEQP-GLES2.functional.fbo.render.shared_colorbuffer_clear.tex2d_rgb -dEQP-GLES2.functional.fbo.render.shared_colorbuffer_clear.tex2d_rgba dEQP-GLES2.functional.fbo.render.shared_depthbuffer.rbo_rgb565_depth_component16 dEQP-GLES2.functional.fbo.render.shared_depthbuffer.tex2d_rgb_depth_component16 dEQP-GLES2.functional.fbo.render.shared_depthbuffer.tex2d_rgba_depth_component16 -dEQP-GLES2.functional.fbo.render.stencil.npot_rbo_rgb565_stencil_index8 dEQP-GLES2.functional.fbo.render.stencil.npot_rbo_rgb5_a1_stencil_index8 dEQP-GLES2.functional.fbo.render.stencil.npot_rbo_rgba4_stencil_index8 -dEQP-GLES2.functional.fbo.render.stencil.npot_tex2d_rgb_stencil_index8 -dEQP-GLES2.functional.fbo.render.stencil.npot_tex2d_rgba_stencil_index8 dEQP-GLES2.functional.fbo.render.stencil.rbo_rgb5_a1_stencil_index8 dEQP-GLES2.functional.fbo.render.stencil.rbo_rgba4_stencil_index8 dEQP-GLES2.functional.fbo.render.stencil_clear.rbo_rgb5_a1_stencil_index8 +dEQP-GLES2.functional.fbo.render.stencil_clear.rbo_rgb565_stencil_index8 dEQP-GLES2.functional.fbo.render.stencil_clear.rbo_rgba4_stencil_index8 +dEQP-GLES2.functional.fbo.render.stencil_clear.tex2d_rgb_stencil_index8 +dEQP-GLES2.functional.fbo.render.stencil_clear.tex2d_rgba_stencil_index8 dEQP-GLES2.functional.fbo.render.texsubimage.after_render_tex2d_rgb dEQP-GLES2.functional.fbo.render.texsubimage.after_render_tex2d_rgba dEQP-GLES2.functional.fbo.render.texsubimage.between_render_tex2d_rgb @@ -307,95 +303,39 @@ dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_w dEQP-GLES2.functional.shaders.preprocessor.predefined_macros.line_2_fragment dEQP-GLES2.functional.shaders.preprocessor.predefined_macros.line_2_vertex dEQP-GLES2.functional.shaders.random.all_features.fragment.0 -dEQP-GLES2.functional.shaders.random.all_features.fragment.10 dEQP-GLES2.functional.shaders.random.all_features.fragment.16 -dEQP-GLES2.functional.shaders.random.all_features.fragment.17 dEQP-GLES2.functional.shaders.random.all_features.fragment.45 -dEQP-GLES2.functional.shaders.random.all_features.fragment.48 dEQP-GLES2.functional.shaders.random.all_features.fragment.5 -dEQP-GLES2.functional.shaders.random.all_features.fragment.54 dEQP-GLES2.functional.shaders.random.all_features.fragment.6 -dEQP-GLES2.functional.shaders.random.all_features.fragment.60
[Mesa-dev] [PATCH 2/2] panfrost: ci: Exclude some tests from results
These are tests that regressed in RK3288 but still pass on RK3399. So we still have a CI we can rely on, add them to the flip-flop list for now. Signed-off-by: Tomeu Vizoso --- src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 51 ++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml b/src/gallium/drivers/panfrost/ci/gitlab-ci.yml index d67c1ff6c946..276d4649dad8 100644 --- a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml +++ b/src/gallium/drivers/panfrost/ci/gitlab-ci.yml @@ -194,6 +194,7 @@ build:arm64: dEQP-GLES2.functional.polygon_offset.fixed16_factor_0_slope dEQP-GLES2.functional.polygon_offset.fixed16_factor_1_slope dEQP-GLES2.functional.shaders.invariance.highp.loop_4 + dEQP-GLES2.functional.shaders.matrix.mul.dynamic_highp_vec4_mat4_fragment dEQP-GLES2.functional.shaders.operator.common_functions.smoothstep.mediump_vec3_vertex dEQP-GLES2.functional.shaders.random.all_features.fragment.12 dEQP-GLES2.functional.shaders.random.all_features.fragment.37 @@ -202,10 +203,58 @@ build:arm64: dEQP-GLES2.functional.texture.units.2_units.only_2d.2 dEQP-GLES2.functional.texture.units.4_units.mixed.5 dEQP-GLES2.functional.texture.units.4_units.only_2d.0 +dEQP-GLES2.functional.texture.units.all_units.mixed.6 dEQP-GLES2.functional.texture.units.all_units.only_cube.4 dEQP-GLES2.functional.texture.units.all_units.only_cube.7 dEQP-GLES2.functional.texture.units.all_units.only_cube.8 " + +# FIXME: These tests fail in RK3288 but pass on RK3399 +- | + FLIP_FLOPS="$FLIP_FLOPS + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.add_dst_color_one_minus_src_color + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.add_dst_color_src_color + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.add_one_minus_dst_color_src_color + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_constant_alpha_one_minus_dst_color + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_dst_alpha_one_minus_constant_color + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_dst_color_constant_alpha + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_zero_dst_alpha + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_zero_dst_color + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_zero_one + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.subtract_one_one + dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.subtract_src_alpha_saturate_constant_alpha + dEQP-GLES2.functional.fragment_ops.blend.rgb_equation_alpha_equation.reverse_subtract_reverse_subtract + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.constant_color_one + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_minus_constant_alpha_one_minus_constant_alpha + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_minus_constant_alpha_src_alpha + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_minus_constant_color_src_alpha + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_minus_dst_color_one_minus_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_minus_src_color_one_minus_src_alpha + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_minus_src_color_one_minus_src_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.one_one_minus_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.src_color_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.src_color_src_alpha + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.zero_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.dst.zero_one_minus_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.src.constant_color_one_minus_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.src.dst_color_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.src.one_minus_constant_color_one_minus_constant_color + dEQP-GLES2.functional.fragment_ops.blend.rgb_func_alpha_func.src.one_minus_dst_color_constant_color +
[Mesa-dev] [PATCH] panfrost: Fix general purpose varying handling
When both the fragment and vertex shaders point to the same varying
location they expect to share the same varying slot.
Make sure vertex and fragment varyings pointing to the same loc have
->src_offset set to the same value.
Signed-off-by: Boris Brezillon
---
Found the bug while debugging gallium-hud on panfrost. The vertex and
fragment shaders used for the fonts do not have the same number of
general purpose varying input/ouput. This ->src_offset mismatch leads
to wrong texture coordinates when sampling the font texture.
---
.../panfrost/midgard/midgard_compile.c| 6 +--
src/gallium/drivers/panfrost/pan_assemble.c | 7 +--
src/gallium/drivers/panfrost/pan_context.c| 44 ---
src/gallium/drivers/panfrost/pan_context.h| 2 +-
4 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 6761b2768143..1374c1ee6475 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -2414,9 +2414,9 @@ midgard_compile_shader_nir(nir_shader *nir,
midgard_program *program, bool is_bl
unsigned loc = var->data.driver_location;
unsigned sz = glsl_type_size(var->type, FALSE);
-for (int c = loc; c < (loc + sz); ++c) {
-program->varyings[c] = var->data.location;
-max_varying = MAX2(max_varying, c);
+for (int c = 0; c < sz; ++c) {
+program->varyings[loc + c] = var->data.location + c;
+max_varying = MAX2(max_varying, loc + c);
}
}
diff --git a/src/gallium/drivers/panfrost/pan_assemble.c
b/src/gallium/drivers/panfrost/pan_assemble.c
index a6ba5fa6790e..de8a53ce05d7 100644
--- a/src/gallium/drivers/panfrost/pan_assemble.c
+++ b/src/gallium/drivers/panfrost/pan_assemble.c
@@ -105,8 +105,6 @@ panfrost_shader_compile(struct panfrost_context *ctx,
struct mali_shader_meta *m
unsigned default_vec4_swizzle = panfrost_get_default_swizzle(4);
/* Iterate the varyings and emit the corresponding descriptor */
-unsigned general_purpose_count = 0;
-
for (unsigned i = 0; i < program.varying_count; ++i) {
unsigned location = program.varyings[i];
@@ -136,12 +134,9 @@ panfrost_shader_compile(struct panfrost_context *ctx,
struct mali_shader_meta *m
state->reads_point_coord = true;
} else {
v.index = 0;
-v.src_offset = 16 * (general_purpose_count++);
}
state->varyings[i] = v;
+state->varyings_loc[i] = location;
}
-
-/* Set the stride for the general purpose fp32 vec4 varyings */
-state->general_varying_stride = (4 * 4) * general_purpose_count;
}
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 53c2fe3cee79..d178a0f1db21 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -697,6 +697,7 @@ panfrost_emit_varying_descriptor(
struct panfrost_shader_state *vs =
>vs->variants[ctx->vs->active_variant];
struct panfrost_shader_state *fs =
>fs->variants[ctx->fs->active_variant];
+unsigned int num_gen_varyings = 0;
/* Allocate the varying descriptor */
@@ -706,6 +707,42 @@ panfrost_emit_varying_descriptor(
struct panfrost_transfer trans = panfrost_allocate_transient(ctx,
vs_size + fs_size);
+/*
+ * Assign ->src_offset now that we know about all the general purpose
+ * varyings that will be used by the fragment and vertex shaders.
+ */
+for (unsigned i = 0; i < vs->tripipe->varying_count; i++) {
+/*
+ * General purpose varyings have ->index set to 0, skip other
+ * entries.
+ */
+if (vs->varyings[i].index)
+continue;
+
+vs->varyings[i].src_offset = 16 * (num_gen_varyings++);
+}
+
+for (unsigned i = 0; i < fs->tripipe->varying_count; i++) {
+unsigned j;
+
+if (fs->varyings[i].index)
+continue;
+
+/*
+ * Re-use the VS general purpose varying pos if it exists,
+ * create a new one otherwise.
+ */
+for (j = 0; j < vs->tripipe->varying_count; j++) {
+if (fs->varyings_loc[i] == vs->varyings_loc[j])
+break;
+}
+
+if (j < vs->tripipe->varying_count)
+fs->varyings[i].src_offset =
vs->varyings[j].src_offset;
+
[Mesa-dev] [PATCH 2/2] ac: make ac_compute_cmask() a static function
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_surface.c | 6 +++---
src/amd/common/ac_surface.h | 4
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 28256352cb7..7b86cb1e1f2 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -552,9 +552,9 @@ static int gfx6_surface_settings(ADDR_HANDLE addrlib,
return 0;
}
-void ac_compute_cmask(const struct radeon_info *info,
- const struct ac_surf_config *config,
- struct radeon_surf *surf)
+static void ac_compute_cmask(const struct radeon_info *info,
+const struct ac_surf_config *config,
+struct radeon_surf *surf)
{
unsigned pipe_interleave_bytes = info->pipe_interleave_bytes;
unsigned num_pipes = info->num_tile_pipes;
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 08aac94d3a9..49f68f4fc92 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -261,10 +261,6 @@ int ac_compute_surface(ADDR_HANDLE addrlib, const struct
radeon_info *info,
enum radeon_surf_mode mode,
struct radeon_surf *surf);
-void ac_compute_cmask(const struct radeon_info *info,
- const struct ac_surf_config *config,
- struct radeon_surf *surf);
-
#ifdef __cplusplus
}
#endif
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radv: rely on ac_compute_cmask() for CMASK info
Instead of re-computing in the driver. The 3d and cube flags
are correctly set, so the same values should returned by
ac_compute_surface().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_image.c | 45 +++--
1 file changed, 3 insertions(+), 42 deletions(-)
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index d8dc2dfabde..909145e1e75 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -885,10 +885,6 @@ radv_image_get_cmask_info(struct radv_device *device,
struct radv_image *image,
struct radv_cmask_info *out)
{
- unsigned pipe_interleave_bytes =
device->physical_device->rad_info.pipe_interleave_bytes;
- unsigned num_pipes = device->physical_device->rad_info.num_tile_pipes;
- unsigned cl_width, cl_height;
-
assert(image->plane_count == 1);
if (device->physical_device->rad_info.chip_class >= GFX9) {
@@ -897,44 +893,9 @@ radv_image_get_cmask_info(struct radv_device *device,
return;
}
- switch (num_pipes) {
- case 2:
- cl_width = 32;
- cl_height = 16;
- break;
- case 4:
- cl_width = 32;
- cl_height = 32;
- break;
- case 8:
- cl_width = 64;
- cl_height = 32;
- break;
- case 16: /* Hawaii */
- cl_width = 64;
- cl_height = 64;
- break;
- default:
- assert(0);
- return;
- }
-
- unsigned base_align = num_pipes * pipe_interleave_bytes;
-
- unsigned width =
align(image->planes[0].surface.u.legacy.level[0].nblk_x, cl_width*8);
- unsigned height =
align(image->planes[0].surface.u.legacy.level[0].nblk_y, cl_height*8);
- unsigned slice_elements = (width * height) / (8*8);
-
- /* Each element of CMASK is a nibble. */
- unsigned slice_bytes = slice_elements / 2;
-
- out->slice_tile_max = (width * height) / (128*128);
- if (out->slice_tile_max)
- out->slice_tile_max -= 1;
-
- out->alignment = MAX2(256, base_align);
- out->size = (image->type == VK_IMAGE_TYPE_3D ? image->info.depth :
image->info.array_size) *
- align(slice_bytes, base_align);
+ out->slice_tile_max =
image->planes[0].surface.u.legacy.cmask_slice_tile_max;
+ out->alignment = image->planes[0].surface.cmask_alignment;
+ out->size = image->planes[0].surface.cmask_size;
}
static void
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #9 from network...@rkmail.ru --- (In reply to Samuel Pitoiset from comment #8) > This is not a bug and performance for that game is quite acceptable. > Closing. How does this is 'not a bug' and 'acceptable' if much more powerful gpu performs worse than old one with same quality settings? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: implement compressed FMASK texture reads with RADV_PERFTEST=tccompatcmask
This allows us to disable the FMASK decompress pass when
transitioning from CB writes to shader reads.
This will likely be improved and enabled by default in the future.
No CTS regressions on GFX8 but a few number of multisample CTS
failures on GFX9 (they look related to the small hint).
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 9 ++
src/amd/vulkan/radv_debug.h | 1 +
src/amd/vulkan/radv_device.c | 15 ++
src/amd/vulkan/radv_image.c | 42 +++
src/amd/vulkan/radv_meta.h| 26 +
src/amd/vulkan/radv_meta_fast_clear.c | 2 +-
src/amd/vulkan/radv_private.h | 10 +++
7 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 2fd5f8b7a07..bf208899887 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1254,6 +1254,15 @@ radv_emit_fb_color_state(struct radv_cmd_buffer
*cmd_buffer,
cb_color_info &= C_028C70_DCC_ENABLE;
}
+ if (radv_image_is_tc_compat_cmask(image) &&
+ (radv_is_fmask_decompress_pipeline(cmd_buffer) ||
+radv_is_dcc_decompress_pipeline(cmd_buffer))) {
+ /* If this bit is set, the FMASK decompression operation
+* doesn't occur (DCC_COMPRESS also implies FMASK_DECOMPRESS).
+*/
+ cb_color_info &= C_028C70_FMASK_COMPRESS_1FRAG_ONLY;
+ }
+
if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
radeon_set_context_reg_seq(cmd_buffer->cs,
R_028C60_CB_COLOR0_BASE + index * 0x3c, 11);
radeon_emit(cmd_buffer->cs, cb->cb_color_base);
diff --git a/src/amd/vulkan/radv_debug.h b/src/amd/vulkan/radv_debug.h
index 652a3b677d2..29793e549ce 100644
--- a/src/amd/vulkan/radv_debug.h
+++ b/src/amd/vulkan/radv_debug.h
@@ -61,6 +61,7 @@ enum {
RADV_PERFTEST_OUT_OF_ORDER = 0x8,
RADV_PERFTEST_DCC_MSAA = 0x10,
RADV_PERFTEST_BO_LIST= 0x20,
+ RADV_PERFTEST_TC_COMPAT_CMASK = 0x40,
};
bool
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 3b69e457496..b75ce59dfc3 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -479,6 +479,7 @@ static const struct debug_control radv_perftest_options[] =
{
{"localbos", RADV_PERFTEST_LOCAL_BOS},
{"dccmsaa", RADV_PERFTEST_DCC_MSAA},
{"bolist", RADV_PERFTEST_BO_LIST},
+ {"tccompatcmask", RADV_PERFTEST_TC_COMPAT_CMASK},
{NULL, 0}
};
@@ -4389,6 +4390,20 @@ radv_initialise_color_surface(struct radv_device *device,
unsigned fmask_bankh =
util_logbase2(iview->image->fmask.bank_height);
cb->cb_color_attrib |=
S_028C74_FMASK_BANK_HEIGHT(fmask_bankh);
}
+
+ if (radv_image_is_tc_compat_cmask(iview->image)) {
+ /* Allow the texture block to read FMASK directly
+* without decompressing it. This bit must be cleared
+* when performing FMASK_DECOMPRESS or DCC_COMPRESS,
+* otherwise the operation doesn't happen.
+*/
+ cb->cb_color_info |=
S_028C70_FMASK_COMPRESS_1FRAG_ONLY(1);
+
+ /* Set CMASK into a tiling format that allows the
+* texture block to read it.
+*/
+ cb->cb_color_info |= S_028C70_CMASK_ADDR_TYPE(2);
+ }
}
if (radv_image_has_cmask(iview->image) &&
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index d8dc2dfabde..c58c08fca59 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -219,6 +219,29 @@ radv_use_dcc_for_image(struct radv_device *device,
return true;
}
+static bool
+radv_use_tc_compat_cmask_for_image(struct radv_device *device,
+ struct radv_image *image)
+{
+ if (!(device->instance->perftest_flags & RADV_PERFTEST_TC_COMPAT_CMASK))
+ return false;
+
+ /* TC-compat CMASK is only available for GFX8+. */
+ if (device->physical_device->rad_info.chip_class < GFX8)
+ return false;
+
+ if (image->usage & VK_IMAGE_USAGE_STORAGE_BIT)
+ return false;
+
+ if (radv_image_has_dcc(image))
+ return false;
+
+ if (!radv_image_has_cmask(image))
+ return false;
+
+ return true;
+}
+
static void
radv_prefill_surface_from_metadata(struct radv_device *device,
struct radeon_surf *surface,
@@ -726,11 +749,26 @@ si_make_texture_descriptor(struct radv_device *device,
[Mesa-dev] [Bug 110815] Segfault vkCreateDescriptorPool in The-Forge on RADV
https://bugs.freedesktop.org/show_bug.cgi?id=110815 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #8 from Samuel Pitoiset --- This is definitely a bug in TheForge. VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_NV is part of VK_NV_ray_tracing, so if the extension isn't exposed, you shouldn't try to use it. Also, as mentioned by Bas, poolSizeCount seems totally wrong. Anyways, AFAIU The Forge doesn't want to support RADV, closing... -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #8 from Samuel Pitoiset --- This is not a bug and performance for that game is quite acceptable. Closing. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: emit framebuffer state from primary if secondary doesn't herit it
Otherwise fast color/depth clears can't work because they depend
on the framebuffer.
This fixes the following CTS (when the small hint is disabled):
- dEQP-VK.geometry.layered.1d_array.secondary_cmd_buffer
- dEQP-VK.geometry.layered.2d_array.secondary_cmd_buffer
- dEQP-VK.geometry.layered.cube.secondary_cmd_buffer
- dEQP-VK.geometry.layered.cube_array.secondary_cmd_buffer
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110810
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107986
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 2fd5f8b7a07..b59d78f1829 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3680,6 +3680,15 @@ void radv_CmdExecuteCommands(
if (secondary->sample_positions_needed)
primary->sample_positions_needed = true;
+ if (!secondary->state.framebuffer &&
+ (primary->state.dirty & RADV_CMD_DIRTY_FRAMEBUFFER)) {
+ /* Emit the framebuffer state from primary if secondary
+* has been recorded without a framebuffer, otherwise
+* fast color/depth clears can't work.
+*/
+ radv_emit_framebuffer_state(primary);
+ }
+
primary->device->ws->cs_execute_secondary(primary->cs,
secondary->cs);
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?
On Wed, 2019-06-12 at 14:03 -0400, Adam Jackson wrote: > On Wed, 2019-06-12 at 10:29 +0200, Erik Faye-Lund wrote: > > On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote: > > > On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote: > > > > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote: > > > > > > > > > So here's the question: How does people feel about hosting > > > > > this under > > > > > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people > > > > > are OK with > > > > > this, I will make that happen, and send out a patch to update > > > > > the link > > > > > we have in our FAQ once that's done. > > > > > > > > Sounds fine to me. I've needed to refer to the SI more than > > > > once, I'd > > > > be happy to have it in a well-known location. > > > > > > > > Vaguely related: Old-timers may remember that DRI used to have > > > > its own > > > > CVS repo on dri.sourceforge.net. If you want a git import of > > > > that tree, > > > > you can find it here: > > > > > > > > https://gitlab.freedesktop.org/ajax/dri > > > > > > Hmm, for some reason I can't see the repo here, just the (empty) > > > issue > > > tracker. Even though the project is listed as public... Strange. > > Weirdly there are separate controls for project and repository > visibility, and the latter was set to "Only project members" for some > reason. Fixed, thanks! > Thanks, I can see it now :) > > > > I'd be happy to move this under mesa/ too if we want. > > > > > > I think that'd be nice, yeah. I think it would be nice to keep > > > things > > > like this in some central location. > > > > > > One could also imagine that the SGI GLX realease in it's original > > > form > > > would be interesting to preserve in case other mirrors go down as > > > well. > > > Just for the heck of it, I've archived that as well, even though > > > it's > > > just a single tarball, so it ends up as just a single commit: > > > > > > https://gitlab.freedesktop.org/kusma/glx > > > > > > This could also be a candidate for moving under the mesa-group. > > > > Actually, perhaps this one belongs under the xorg-group instead of > > the > > mesa-group... > > Yeah, toss-up really. The glx code drop has both the client library > and > server support, so it's not entirely one or the other. libGL used to > live only in the X11 monolith, and (iirc) we moved it to Mesa during > m12n so it lived near the DRI drivers since that interface kept > growing. > Yeah, fair enough. I don't really feel the need to decide on this right now. I want to add a link to the ogl-sample code in our FAQ, so that's the only repo I have a motivation to do something with right now. I would say we move both the ogl-sample repo and the glx repo to the mesa organization, and mark them as read-only as we reasonably can. I'm pretty much indifferent to archiving vs permissions-tweaks, but I do very slightly lean towards archiving (AFAIK, owners can always push regardless of premissins-tweaks, so there's a *very* theoretical chance of something going wrong then). The glx-repo can wait until there's a motivation, I think. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: make sure to init the DCC decompress compute path state
This fixes a segfault when forcing DCC decompressions on compute
because internal meta objects are not created since the on-demand
stuff.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_fast_clear.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/amd/vulkan/radv_meta_fast_clear.c
b/src/amd/vulkan/radv_meta_fast_clear.c
index 8f97c1a8f15..176f9803b45 100644
--- a/src/amd/vulkan/radv_meta_fast_clear.c
+++ b/src/amd/vulkan/radv_meta_fast_clear.c
@@ -753,6 +753,14 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer
*cmd_buffer,
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+ if
(!cmd_buffer->device->meta_state.fast_clear_flush.cmask_eliminate_pipeline) {
+ VkResult ret =
radv_device_init_meta_fast_clear_flush_state_internal(cmd_buffer->device);
+ if (ret != VK_SUCCESS) {
+ cmd_buffer->record_result = ret;
+ return;
+ }
+ }
+
radv_meta_save(_state, cmd_buffer, RADV_META_SAVE_DESCRIPTORS |
RADV_META_SAVE_COMPUTE_PIPELINE);
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: flush and invalidate CB before resetting query pools on GFX9
On 6/13/19 11:14 AM, Bas Nieuwenhuizen wrote: Add DB while we are at it? Pushed with DB added. Otherwise, r-b On Thu, Jun 13, 2019 at 10:51 AM Samuel Pitoiset wrote: We have to emit a CACHE_FLUSH_AND_INV_TS_EVENT to be sure all prior GPU work is done. This fixes the following CTS (when the small hint is disabled): dEQP-VK.query_pool.statistics_query.reset_before_copy.* Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_query.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c index 3bbd10cbb34..b91ffbab989 100644 --- a/src/amd/vulkan/radv_query.c +++ b/src/amd/vulkan/radv_query.c @@ -1641,6 +1641,8 @@ static void emit_end_query(struct radv_cmd_buffer *cmd_buffer, RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_INV_GLOBAL_L2 | RADV_CMD_FLAG_INV_VMEM_L1; + if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) + cmd_buffer->active_query_flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB; } void radv_CmdBeginQueryIndexedEXT( -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: flush and invalidate CB before resetting query pools on GFX9
Add DB while we are at it? Otherwise, r-b On Thu, Jun 13, 2019 at 10:51 AM Samuel Pitoiset wrote: > > We have to emit a CACHE_FLUSH_AND_INV_TS_EVENT to be sure all > prior GPU work is done. > > This fixes the following CTS (when the small hint is disabled): > dEQP-VK.query_pool.statistics_query.reset_before_copy.* > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_query.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c > index 3bbd10cbb34..b91ffbab989 100644 > --- a/src/amd/vulkan/radv_query.c > +++ b/src/amd/vulkan/radv_query.c > @@ -1641,6 +1641,8 @@ static void emit_end_query(struct radv_cmd_buffer > *cmd_buffer, >RADV_CMD_FLAG_CS_PARTIAL_FLUSH > | >RADV_CMD_FLAG_INV_GLOBAL_L2 | >RADV_CMD_FLAG_INV_VMEM_L1; > + if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) > + cmd_buffer->active_query_flush_bits |= > RADV_CMD_FLAG_FLUSH_AND_INV_CB; > } > > void radv_CmdBeginQueryIndexedEXT( > -- > 2.22.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: flush and invalidate CB before resetting query pools on GFX9
We have to emit a CACHE_FLUSH_AND_INV_TS_EVENT to be sure all prior GPU work is done. This fixes the following CTS (when the small hint is disabled): dEQP-VK.query_pool.statistics_query.reset_before_copy.* Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_query.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c index 3bbd10cbb34..b91ffbab989 100644 --- a/src/amd/vulkan/radv_query.c +++ b/src/amd/vulkan/radv_query.c @@ -1641,6 +1641,8 @@ static void emit_end_query(struct radv_cmd_buffer *cmd_buffer, RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_INV_GLOBAL_L2 | RADV_CMD_FLAG_INV_VMEM_L1; + if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) + cmd_buffer->active_query_flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB; } void radv_CmdBeginQueryIndexedEXT( -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely
https://bugs.freedesktop.org/show_bug.cgi?id=110697 --- Comment #12 from Michel Dänzer --- (In reply to QwertyChouskie from comment #11) > Whoops, missed that they were posted in a comment further down. Here they > are again for reference: I did follow those steps. -- 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] ac/registers: use better names for disambiguated definitions
Patches 1-2 are: Reviewed-by: Samuel Pitoiset On 6/13/19 2:40 AM, Marek Olšák wrote: From: Marek Olšák --- src/amd/registers/makeregheader.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/amd/registers/makeregheader.py b/src/amd/registers/makeregheader.py index 859a59b9f3e..1d73cb47bdf 100644 --- a/src/amd/registers/makeregheader.py +++ b/src/amd/registers/makeregheader.py @@ -37,24 +37,24 @@ import re import sys from regdb import Object, RegisterDatabase, deduplicate_enums, deduplicate_register_types # BEGIN HARDCODED CONFIGURATION # Chips are sorted chronologically CHIPS = [ Object(name='gfx6', disambiguation='GFX6'), -Object(name='gfx7', disambiguation='GFX6'), -Object(name='gfx8', disambiguation='GFX6'), -Object(name='fiji', disambiguation='GFX6'), -Object(name='stoney', disambiguation='GFX6'), +Object(name='gfx7', disambiguation='GFX7'), +Object(name='gfx8', disambiguation='GFX8'), +Object(name='fiji', disambiguation='GFX8'), +Object(name='stoney', disambiguation='GFX8'), Object(name='gfx9', disambiguation='GFX9'), ] # END HARDCODED CONFIGURATION def get_chip_index(chip): """ Given a chip name, return its index in the global CHIPS list. """ return next(idx for idx, obj in enumerate(CHIPS) if obj.name == chip) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: add radeon_info::is_amdgpu instead of checking drm_major == 3
Why do you need that?
On 6/12/19 11:31 PM, Marek Olšák wrote:
From: Marek Olšák
and clean up
---
src/amd/common/ac_gpu_info.c | 13 --
src/amd/common/ac_gpu_info.h | 1 +
src/amd/vulkan/radv_debug.c | 5 +-
src/gallium/drivers/r600/r600_buffer_common.c | 6 +--
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe_common.c | 46 ++-
src/gallium/drivers/r600/r600_query.c | 2 +-
src/gallium/drivers/r600/r600_texture.c | 2 +-
src/gallium/drivers/r600/radeon_uvd.c | 3 +-
src/gallium/drivers/r600/radeon_vce.c | 5 +-
src/gallium/drivers/radeon/radeon_uvd.c | 2 +-
src/gallium/drivers/radeon/radeon_vce.c | 6 +--
src/gallium/drivers/radeonsi/si_buffer.c | 2 +-
src/gallium/drivers/radeonsi/si_debug.c | 2 +-
src/gallium/drivers/radeonsi/si_get.c | 4 +-
src/gallium/drivers/radeonsi/si_pipe.c| 4 +-
src/gallium/drivers/radeonsi/si_query.c | 2 +-
src/gallium/drivers/radeonsi/si_state.c | 2 +-
.../winsys/radeon/drm/radeon_drm_winsys.c | 1 +
19 files changed, 33 insertions(+), 77 deletions(-)
diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 13fba8df047..4de6882f15e 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -110,20 +110,23 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
if (r) {
fprintf(stderr, "amdgpu: drmGetDevice2 failed.\n");
return false;
}
info->pci_domain = devinfo->businfo.pci->domain;
info->pci_bus = devinfo->businfo.pci->bus;
info->pci_dev = devinfo->businfo.pci->dev;
info->pci_func = devinfo->businfo.pci->func;
drmFreeDevice();
+ assert(info->drm_major == 3);
+ info->is_amdgpu = true;
+
/* Query hardware and driver information. */
r = amdgpu_query_gpu_info(dev, amdinfo);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_gpu_info failed.\n");
return false;
}
r = amdgpu_query_info(dev, AMDGPU_INFO_DEV_INFO, sizeof(device_info),
_info);
if (r) {
@@ -154,45 +157,45 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(compute)
failed.\n");
return false;
}
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD, 0, );
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(uvd)
failed.\n");
return false;
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD_ENC, 0,
_enc);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(uvd_enc)
failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_DEC, 0,
_dec);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vcn_dec)
failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_ENC, 0,
_enc);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vcn_enc)
failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 27) {
+ if (info->drm_minor >= 27) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_JPEG, 0,
_jpeg);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vcn_jpeg)
failed.\n");
return false;
}
}
r = amdgpu_query_firmware_version(dev, AMDGPU_INFO_FW_GFX_ME, 0, 0,
>me_fw_version,
>me_fw_feature);
@@ -737,21 +740,21 @@ ac_get_raster_config(struct radeon_info *info,
fprintf(stderr,
"ac: Unknown GPU, using 0 for raster_config\n");
raster_config = 0x;
raster_config_1 = 0x;
break;
}
/* drm/radeon on Kaveri is buggy, so disable 1 RB to work around it.
* This decreases performance by up to 50% when the RB is the
bottleneck.
*/
- if (info->family == CHIP_KAVERI && info->drm_major == 2)
+ if (info->family == CHIP_KAVERI && !info->is_amdgpu)
raster_config =
