[Mesa-dev] [Bug 109140] [KBL-G][GL] KHR-GL43.compute_shader.max test failed
https://bugs.freedesktop.org/show_bug.cgi?id=109140 --- Comment #2 from Hai --- Is there any additional information needed for this bug? Thanks. -- 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
[Mesa-dev] [Bug 108878] OpenGL CTS KHR-GL31.transform_feedback.api_errors_test failed
https://bugs.freedesktop.org/show_bug.cgi?id=108878 Hai changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED -- 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 108878] OpenGL CTS KHR-GL31.transform_feedback.api_errors_test failed
https://bugs.freedesktop.org/show_bug.cgi?id=108878 --- Comment #4 from Hai --- Since ARB_geometry_shader4 is from OpenGL 3.2, this issue is a test case bug rather than mesa bug. Will close it. -- 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 05/12] nir: rename global/local to private/function memory
On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote: > the naming is a bit confusing no matter how you look at it. Within SPIR-V > "global" memory is memory accessible from all threads. glsl "global" memory > normally refers to shader thread private memory declared at global scope. As > we already use "shared" for memory shared across all thrads of a work group > the solution where everybody could be happy with is to rename "global" to > "private" and use "global" later for memory usually stored within system > accessible memory (be it VRAM or system RAM if keeping SVM in mind). > glsl "local" memory is memory only accessible within a function, while SPIR-V > "local" memory is memory accessible within the same workgroup. > > v2: rename local to function as well > > Signed-off-by: Karol Herbst I strongly dislike this patch, and I think we ought to revert it. This probably makes sense from an OpenCL memory-model view of the world, but it's really confusing from a compiler or general programming point of view. /Everybody/ knows what a local variable is. It's one of the most used concepts in programming. Calling it nir_var_function is very confusing. The variable is a...function? Maybe it's a function pointer? Neither of those things even exist in GLSL, so...what the heck is it? Renaming global scope variables to "private" is also confusing IMO. They're certainly not private to a function. They're globally accessible by anything in the whole shader. I'll admit "global" isn't a great name either. I think we need to discuss this more. There are people with large series of outstanding work that now have to rebase on this flag day rename, and I don't think two people is enough consensus for renaming a core IR concept. Can we find names we're all happy with? --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add pipe_grid_info::partial_block
On Tue, Jan 8, 2019, 7:55 PM Ilia Mirkin On Tue, Jan 8, 2019 at 7:26 PM Marek Olšák wrote:
> >
> > On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
> >>
> >> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
> >> >
> >> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin
> wrote:
> >> >>
> >> >> Why does this need to be in p_state? And who is responsible for
> >> >> setting it (and how will it be set)?
> >> >
> >> >
> >> > Oh right, there is a way to get it out of p_state.h if needed.
> >> >
> >> > It should be set to 0 by default.
> >> >
> >> > If your thread block is 8x8x1, but you need to launch 10x8x1 threads,
> set partial_block = {2, 0, 0}. It will launch the following thread blocks:
> >> > 8x8x1
> >> > 2x8x1
> >> >
> >> > It's the same as launching 16x8x1 threads and doing this at the
> beginning of the compute shader:
> >> > if (globalThreadID.x >= 10) return;
> >>
> >> But that all sounds like something a state tracker wouldn't care
> >> about, right? In e.g. GLSL you can specify the block to be 10x8x1 and
> >> let the backend work it all out. Should st/mesa care about this (or
> >> clover or whatever)?
> >
> >
> > The block size should be a multiple of 64 on radeonsi to utilize all
> SIMD lanes. If you want to launch 8192+1 threads with the block size of 64,
> you need to launch 1 partial block with the block size of 1 at the end.
> OpenGL can't do this.
>
> Ohh. So the partial-ness applies to the last-executed block.
> If you have a local_size=(2,2,1), and you want your global grid to be,
> say, (5,4,1), with unextended GL you might run it as groups = (3,2,1)
> which would end up invoking a bunch of bits you don't want, and so
> this partial_size is a way to say that you don't want the last "line"
> to be executed at all.
>
> That makes sense, and seems like a reasonable thing to have in
> pipe_grid_info. The documentation did not make that clear the first
> time I read it, but now I'm having trouble suggesting improvements to
> it. So I think it's fine.
>
Yep. The partialness adds additional blocks to the grid with disabled
threads (lanes). I might rename it to grid_padding[3]. Or I might keep the
whole thing private in radeonsi.
It's useful for e.g. compute-based image blits when the blit box is not
aligned to the block size.
Marek
The p_state.h bits are Acked-by: Ilia Mirkin .
> Can't speak as to the radeonsi bits.
>
> Cheers,
>
> -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #9 from Roman Elshin --- It looks like i have a same issue with rx560. -- 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
[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #8 from Roman Elshin --- Created attachment 143025 --> https://bugs.freedesktop.org/attachment.cgi?id=143025=edit game save -- 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 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #7 from Roman Elshin --- Created attachment 143024 --> https://bugs.freedesktop.org/attachment.cgi?id=143024=edit dmesg via ssh -- 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] llvmpipe: Always return some fence in flush (v2)
Am 07.01.19 um 09:54 schrieb Tomasz Figa:
> On Sun, Dec 23, 2018 at 12:55 AM Roland Scheidegger
> wrote:
>>
>> Alright, I guess it should work...
>>
>> Reviewed-by: Roland Scheidegger
>>
>
> Thanks!
>
> Would we have anyone who could help to commit it?
Pushed (albeit I forgot the R-b on it, ah well...)
Roland
>
> (I know that I was supposed to apply for commit rights, but I expect
> my contribution rate to be relatively low, due to a shift to different
> areas, so I don't think I'm a good candidate for a committer anymore.)
>
> Best regards,
> Tomasz
>
>>
>> Am 14.12.18 um 09:17 schrieb Tomasz Figa:
>>> If there is no last fence, due to no rendering happening yet, just
>>> create a new signaled fence and return it, to match the expectations of
>>> the EGL sync fence API.
>>>
>>> Fixes random "Could not create sync fence 0x3003" assertion failures from
>>> Skia on Android, coming from the following code:
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Flibs%2Fhwui%2Fpipeline%2Fskia%2FSkiaOpenGLPipeline.cpp%23427data=02%7C01%7Csroland%40vmware.com%7C578e1621b8de4eeca24508d6747dd1a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636824481094747485sdata=dEjvlyeiOlGCBnegZS%2FXsNRf8OX21qss9d59D0RGqZk%3Dreserved=0
>>>
>>> Reproducible especially with thread count >= 4.
>>>
>>> One could make the driver always keep the reference to the last fence,
>>> but:
>>>
>>> - the driver seems to explicitly destroy the fence whenever a rendering
>>>pass completes and changing that would require a significant functional
>>>change to the code. (Specifically, in lp_scene_end_rasterization().)
>>>
>>> - it still wouldn't solve the problem of an EGL sync fence being created
>>>and waited on without any rendering happening at all, which is
>>>also likely to happen with Android code pointed to in the commit.
>>>
>>> Therefore, the simple approach of always creating a fence is taken,
>>> similarly to other drivers, such as radeonsi.
>>>
>>> Tested with piglit llvmpipe suite with no regressions and following
>>> tests fixed:
>>>
>>> egl_khr_fence_sync
>>> conformance
>>> eglclientwaitsynckhr_flag_sync_flush
>>> eglclientwaitsynckhr_nonzero_timeout
>>> eglclientwaitsynckhr_zero_timeout
>>> eglcreatesynckhr_default_attributes
>>> eglgetsyncattribkhr_invalid_attrib
>>> eglgetsyncattribkhr_sync_status
>>>
>>> v2:
>>> - remove the useless lp_fence_reference() dance (Nicolai),
>>> - explain why creating the dummy fence is the right approach.
>>>
>>> Signed-off-by: Tomasz Figa
>>> ---
>>> src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
>>> b/src/gallium/drivers/llvmpipe/lp_setup.c
>>> index b087369473..e72e119c8a 100644
>>> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
>>> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
>>> @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
>>>
>>> if (fence) {
>>>lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
>>> + if (!*fence)
>>> + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
>>> }
>>> }
>>>
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add pipe_grid_info::partial_block
On Tue, Jan 8, 2019 at 7:26 PM Marek Olšák wrote:
>
> On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
>>
>> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
>> >
>> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
>> >>
>> >> Why does this need to be in p_state? And who is responsible for
>> >> setting it (and how will it be set)?
>> >
>> >
>> > Oh right, there is a way to get it out of p_state.h if needed.
>> >
>> > It should be set to 0 by default.
>> >
>> > If your thread block is 8x8x1, but you need to launch 10x8x1 threads, set
>> > partial_block = {2, 0, 0}. It will launch the following thread blocks:
>> > 8x8x1
>> > 2x8x1
>> >
>> > It's the same as launching 16x8x1 threads and doing this at the beginning
>> > of the compute shader:
>> > if (globalThreadID.x >= 10) return;
>>
>> But that all sounds like something a state tracker wouldn't care
>> about, right? In e.g. GLSL you can specify the block to be 10x8x1 and
>> let the backend work it all out. Should st/mesa care about this (or
>> clover or whatever)?
>
>
> The block size should be a multiple of 64 on radeonsi to utilize all SIMD
> lanes. If you want to launch 8192+1 threads with the block size of 64, you
> need to launch 1 partial block with the block size of 1 at the end. OpenGL
> can't do this.
Ohh. So the partial-ness applies to the last-executed block.
If you have a local_size=(2,2,1), and you want your global grid to be,
say, (5,4,1), with unextended GL you might run it as groups = (3,2,1)
which would end up invoking a bunch of bits you don't want, and so
this partial_size is a way to say that you don't want the last "line"
to be executed at all.
That makes sense, and seems like a reasonable thing to have in
pipe_grid_info. The documentation did not make that clear the first
time I read it, but now I'm having trouble suggesting improvements to
it. So I think it's fine.
The p_state.h bits are Acked-by: Ilia Mirkin .
Can't speak as to the radeonsi bits.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add pipe_grid_info::partial_block
On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
> >
> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
> >>
> >> Why does this need to be in p_state? And who is responsible for
> >> setting it (and how will it be set)?
> >
> >
> > Oh right, there is a way to get it out of p_state.h if needed.
> >
> > It should be set to 0 by default.
> >
> > If your thread block is 8x8x1, but you need to launch 10x8x1 threads,
> set partial_block = {2, 0, 0}. It will launch the following thread blocks:
> > 8x8x1
> > 2x8x1
> >
> > It's the same as launching 16x8x1 threads and doing this at the
> beginning of the compute shader:
> > if (globalThreadID.x >= 10) return;
>
> But that all sounds like something a state tracker wouldn't care
> about, right? In e.g. GLSL you can specify the block to be 10x8x1 and
> let the backend work it all out. Should st/mesa care about this (or
> clover or whatever)?
>
The block size should be a multiple of 64 on radeonsi to utilize all SIMD
lanes. If you want to launch 8192+1 threads with the block size of 64, you
need to launch 1 partial block with the block size of 1 at the end. OpenGL
can't do this.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add pipe_grid_info::partial_block
On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
>
> On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
>>
>> Why does this need to be in p_state? And who is responsible for
>> setting it (and how will it be set)?
>
>
> Oh right, there is a way to get it out of p_state.h if needed.
>
> It should be set to 0 by default.
>
> If your thread block is 8x8x1, but you need to launch 10x8x1 threads, set
> partial_block = {2, 0, 0}. It will launch the following thread blocks:
> 8x8x1
> 2x8x1
>
> It's the same as launching 16x8x1 threads and doing this at the beginning of
> the compute shader:
> if (globalThreadID.x >= 10) return;
But that all sounds like something a state tracker wouldn't care
about, right? In e.g. GLSL you can specify the block to be 10x8x1 and
let the backend work it all out. Should st/mesa care about this (or
clover or whatever)?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Restore optional xf86vidmode
On 08/01/2019 23:54, Rhys Kidd wrote: On Tue, 11 Dec 2018 at 10:22, Jon Turney wrote: Restore optional xf86vidmode, and fix the meson build to actually use it. Jon Turney (2): Revert "glx: make xf86vidmode mandatory for direct rendering" Fix typo preventing xxf86vm being used in meson build Jon I don't believe these patches ever landed in master. Did you want to continue pushing them forward, as they were either Reviewed-by or Ack'ed it seems. Superseded by https://lists.freedesktop.org/archives/mesa-dev/2018-December/211720.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Restore optional xf86vidmode
On Tue, 11 Dec 2018 at 10:22, Jon Turney wrote: > Restore optional xf86vidmode, and fix the meson build to actually use it. > > Jon Turney (2): > Revert "glx: make xf86vidmode mandatory for direct rendering" > Fix typo preventing xxf86vm being used in meson build > Jon I don't believe these patches ever landed in master. Did you want to continue pushing them forward, as they were either Reviewed-by or Ack'ed it seems. > configure.ac| 12 +++- > meson.build | 6 -- > src/glx/Makefile.am | 5 + > src/glx/SConscript | 5 - > src/glx/glxcmds.c | 7 ++- > src/glx/meson.build | 4 > 6 files changed, 34 insertions(+), 5 deletions(-) > > -- > 2.17.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 pipe_grid_info::partial_block
On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
> Why does this need to be in p_state? And who is responsible for
> setting it (and how will it be set)?
>
Oh right, there is a way to get it out of p_state.h if needed.
It should be set to 0 by default.
If your thread block is 8x8x1, but you need to launch 10x8x1 threads, set
partial_block = {2, 0, 0}. It will launch the following thread blocks:
8x8x1
2x8x1
It's the same as launching 16x8x1 threads and doing this at the beginning
of the compute shader:
if (globalThreadID.x >= 10) return;
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v10 12/20] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv
Quoting Pierre Moreau (2019-01-08 13:11:01)
> Reviewed-by: Dylan Baker
>
> Changes since:
> * v7:
> - Properly align LLVMSPIRVLib comment (Dylan Baker)
> - Only define CLOVER_ALLOW_SPIRV when **both** dependencies are found:
> autotools was only requiring one or the other.
> * v6: Replace the llvm-spirv repository by the new official
> SPIRV-LLVM-Translator.
> * v4: Add a comment saying where to find llvm-spirv (Karol Herbst).
> * v3:
> - make SPIRV-Tools and llvm-spirv optional (Francisco Jerez);
> - bump requirement for llvm-spirv to version 0.2
> * v2:
> - Bump the required version of SPIRV-Tools to the latest release;
> - Add a dependency on llvm-spirv.
>
> Signed-off-by: Pierre Moreau
> ---
> configure.ac | 18 ++
> meson.build | 8
> 2 files changed, 26 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index e4d20054d5f..799246e8319 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2513,6 +2513,24 @@ AM_CONDITIONAL(HAVE_CLOVER_ICD, test
> "x$enable_opencl_icd" = xyes)
> AC_SUBST([OPENCL_LIBNAME])
> AC_SUBST([CLANG_RESOURCE_DIR])
>
> +AS_IF([test "x$enable_opencl" = xyes], [
> +PKG_CHECK_MODULES([SPIRV_TOOLS], [SPIRV-Tools >= 2018.0],
> + [have_spirv_tools=yes], [have_spirv_tools=no])])
> +AC_SUBST([SPIRV_TOOLS_CFLAGS])
> +AC_SUBST([SPIRV_TOOLS_LIBS])
> +
> +# LLVMSPIRVLib is available at
> https://github.com/KhronosGroup/SPIRV-LLVM-Translator
> +AS_IF([test "x$enable_opencl" = xyes], [
> +PKG_CHECK_MODULES([LLVMSPIRVLIB], [LLVMSPIRVLib >= 0.2.1],
> + [have_llvmspirvlib=yes], [have_llvmspirvlib=no])])
> +AC_SUBST([LLVMSPIRVLIB_CFLAGS])
> +AC_SUBST([LLVMSPIRVLIB_LIBS])
> +
> +if test "x$have_spirv_tools" = xyes -a \
> +"x$have_llvmspirvlib" = xyes; then
> +DEFINES="$DEFINES -DCLOVER_ALLOW_SPIRV"
> +fi
> +
> dnl
> dnl Gallium configuration
> dnl
> diff --git a/meson.build b/meson.build
> index 709f77a9c7a..7f63d6c84cc 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -655,6 +655,12 @@ if _opencl != 'disabled'
>endif
>
>dep_clc = dependency('libclc')
> + dep_spirv_tools = dependency('SPIRV-Tools', required : false, version :
> '>= 2018.0')
> + # LLVMSPIRVLib is available at
> https://github.com/KhronosGroup/SPIRV-LLVM-Translator
> + dep_llvmspirvlib = dependency('LLVMSPIRVLib', required : false, version :
> '>= 0.2.1')
> + if dep_spirv_tools.found() and dep_llvmspirvlib.found()
> +pre_args += '-DCLOVER_ALLOW_SPIRV'
> + endif
As-is this is what distros call "automagical", and they don't like it :). There
is a case like this is for xlib-lease as well, I'd really like this to have an
option to control it, something similar to the way that xlib-lease works.
Dylan
>with_gallium_opencl = true
>with_opencl_icd = _opencl == 'icd'
>
> @@ -667,6 +673,8 @@ if _opencl != 'disabled'
>endif
> else
>dep_clc = null_dep
> + dep_spirv_tools = null_dep
> + dep_llvmspirvlib = null_dep
>with_gallium_opencl = false
>with_gallium_icd = false
> endif
> --
> 2.20.1
>
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add pipe_grid_info::partial_block
Why does this need to be in p_state? And who is responsible for
setting it (and how will it be set)?
On Tue, Jan 8, 2019 at 2:47 PM Jiang, Sonny wrote:
>
> and add radeonsi support. This will be used by radeonsi internally.
>
> Signed-off-by: Sonny Jiang
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 33 +++
> src/gallium/include/pipe/p_state.h| 7 +
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index cbcd8e79c7b..69ffad45cd9 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -797,11 +797,6 @@ static void si_emit_dispatch_packets(struct si_context
> *sctx,
> radeon_set_sh_reg(cs, R_00B854_COMPUTE_RESOURCE_LIMITS,
> compute_resource_limits);
>
> - radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
> - radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]));
> - radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]));
> - radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]));
> -
> unsigned dispatch_initiator =
> S_00B800_COMPUTE_SHADER_EN(1) |
> S_00B800_FORCE_START_AT_000(1) |
> @@ -809,6 +804,34 @@ static void si_emit_dispatch_packets(struct si_context
> *sctx,
> * allow launching waves out-of-order. (same as Vulkan) */
> S_00B800_ORDER_MODE(sctx->chip_class >= CIK);
>
> + bool partial_block_en = info->partial_block[0] ||
> + info->partial_block[1] ||
> + info->partial_block[2];
> +
> + radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
> +
> + if (partial_block_en) {
> + unsigned partial[3];
> +
> + /* If no partial_block, these should be an entire block size,
> not 0. */
> + partial[0] = info->partial_block[0] ? info->partial_block[0]
> : info->block[0];
> + partial[1] = info->partial_block[1] ? info->partial_block[1]
> : info->block[1];
> + partial[2] = info->partial_block[2] ? info->partial_block[2]
> : info->block[2];
> +
> + radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]) |
> + S_00B81C_NUM_THREAD_PARTIAL(partial[0]));
> + radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]) |
> + S_00B820_NUM_THREAD_PARTIAL(partial[1]));
> + radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]) |
> + S_00B824_NUM_THREAD_PARTIAL(partial[2]));
> +
> + dispatch_initiator |= S_00B800_PARTIAL_TG_EN(1);
> + } else {
> + radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]));
> + radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]));
> + radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]));
> + }
> +
> if (info->indirect) {
> uint64_t base_va = r600_resource(info->indirect)->gpu_address;
>
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index 38052e5fd3d..56f5bdd4c85 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -838,6 +838,13 @@ struct pipe_grid_info
> */
> uint block[3];
>
> + /**
> +* Number of threads to add to the grid in X, Y, and Z directions for
> +* compute dispatches that are not aligned to the block size.
> +* The added threads will be launched as partial thread blocks.
> +*/
> + uint partial_block[3];
> +
> /**
> * Determine the layout of the grid (in block units) to be used.
> */
> --
> 2.17.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
[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)
https://bugs.freedesktop.org/show_bug.cgi?id=109201 --- Comment #6 from Alexander --- Note 2: Does not happen if i set the texture quality to low. -- 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] st/mesa: don't leak pipe_surface if pipe_context is not current
On Tue, Jan 8, 2019 at 5:17 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> We have found some pipe_surface leaks internally.
>
> This is the same code as surface_destroy in radeonsi.
> Ideally, surface_destroy would be in pipe_screen.
> No, pipe_surfaces are not context objects.
>
> Cc: 18.3 19.0
FYI, 19.0 does not branch until 2019-01-29 as per the announcement from Dylan.
> ---
> src/gallium/auxiliary/util/u_inlines.h | 19 +++
> src/mesa/state_tracker/st_cb_fbo.c | 5 -
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_inlines.h
> b/src/gallium/auxiliary/util/u_inlines.h
> index b06fb111709..fa1e920b509 100644
> --- a/src/gallium/auxiliary/util/u_inlines.h
> +++ b/src/gallium/auxiliary/util/u_inlines.h
> @@ -147,20 +147,39 @@ pipe_resource_reference(struct pipe_resource **dst,
> struct pipe_resource *src)
>
> old_dst->screen->resource_destroy(old_dst->screen, old_dst);
> old_dst = next;
>} while (pipe_reference_described(_dst->reference, NULL,
> (debug_reference_descriptor)
> debug_describe_resource));
> }
> *dst = src;
> }
>
> +/**
> + * Same as pipe_surface_release, but used when pipe_context doesn't exist
> + * anymore.
> + */
> +static inline void
> +pipe_surface_release_no_context(struct pipe_surface **ptr)
> +{
> + struct pipe_surface *surf = *ptr;
> +
> + if (pipe_reference_described(>reference, NULL,
> +(debug_reference_descriptor)
> +debug_describe_surface)) {
> + /* trivially destroy pipe_surface */
> + pipe_resource_reference(>texture, NULL);
> + free(surf);
> + }
> + *ptr = NULL;
> +}
> +
> /**
> * Set *dst to \p src with proper reference counting.
> *
> * The caller must guarantee that \p src and *dst were created in
> * the same context (if they exist), and that this must be the current
> context.
> */
> static inline void
> pipe_sampler_view_reference(struct pipe_sampler_view **dst,
> struct pipe_sampler_view *src)
> {
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c
> b/src/mesa/state_tracker/st_cb_fbo.c
> index 8901a8680ef..8d099f7b0f9 100644
> --- a/src/mesa/state_tracker/st_cb_fbo.c
> +++ b/src/mesa/state_tracker/st_cb_fbo.c
> @@ -278,22 +278,25 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
> * gl_renderbuffer::Delete()
> */
> static void
> st_renderbuffer_delete(struct gl_context *ctx, struct gl_renderbuffer *rb)
> {
> struct st_renderbuffer *strb = st_renderbuffer(rb);
> if (ctx) {
>struct st_context *st = st_context(ctx);
>pipe_surface_release(st->pipe, >surface_srgb);
>pipe_surface_release(st->pipe, >surface_linear);
> - strb->surface = NULL;
> + } else {
> + pipe_surface_release_no_context(>surface_srgb);
> + pipe_surface_release_no_context(>surface_linear);
> }
> + strb->surface = NULL;
> pipe_resource_reference(>texture, NULL);
> free(strb->data);
> _mesa_delete_renderbuffer(ctx, rb);
> }
>
>
> /**
> * Called via ctx->Driver.NewRenderbuffer()
> */
> static struct gl_renderbuffer *
> --
> 2.17.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
[Mesa-dev] [PATCH v10 20/20] clover: Implement clCreateProgramWithIL from OpenCL 2.1
Reviewed-by: Karol Herbst
Change since:
* v2: Remove the const from the length argument of clCreateProgramWithIL
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
src/gallium/state_trackers/clover/api/program.cpp | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 8be4d3cb261..f5f3248f26b 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -162,7 +162,7 @@ namespace clover {
NULL, // clSetKernelExecInfo
NULL, // clGetKernelSubGroupInfoKHR
NULL, // clCloneKernel
- NULL, // clCreateProgramWithIL
+ clCreateProgramWithIL,
NULL, // clEnqueueSVMMigrateMem
NULL, // clGetDeviceAndHostTimer
NULL, // clGetHostTimer
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index 9ad7297da57..2a2ef932a32 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -184,6 +184,14 @@ clover::CreateProgramWithILKHR(cl_context d_ctx, const
void *il,
return NULL;
}
+CLOVER_API cl_program
+clCreateProgramWithIL(cl_context d_ctx,
+ const void *il,
+ size_t length,
+ cl_int *r_errcode) {
+ return CreateProgramWithILKHR(d_ctx, il, length, r_errcode);
+}
+
CLOVER_API cl_program
clCreateProgramWithBuiltInKernels(cl_context d_ctx, cl_uint n,
const cl_device_id *d_devs,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 19/20] clover: Advertise cl_khr_il_program
Reviewed-by: Karol Herbst
Changes since:
* v3: do not advertise SPIR-V support if CLOVER_ALLOW_SPIRV is not
defined
* v2: advertise cl_khr_il_program if if the device support NATIVE as IR
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/platform.cpp | 2 ++
src/gallium/state_trackers/clover/core/device.cpp | 8 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
b/src/gallium/state_trackers/clover/api/platform.cpp
index a684d34ba44..b591fe9874c 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -107,6 +107,8 @@ clover::GetExtensionFunctionAddress(const char *p_name) {
if (name == "clIcdGetPlatformIDsKHR")
return reinterpret_cast(IcdGetPlatformIDsKHR);
+ else if (name == "clCreateProgramWithILKHR")
+ return reinterpret_cast(CreateProgramWithILKHR);
else
return NULL;
}
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 21de0e3d61c..b9a26e4eec5 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -285,6 +285,11 @@ device::supports_ir(enum pipe_shader_ir ir) const {
std::string
device::supported_extensions() const {
+#ifdef CLOVER_ALLOW_SPIRV
+ const bool supports_il_program = supports_ir(PIPE_SHADER_IR_NATIVE);
+#else
+ const bool supports_il_program = false;
+#endif
return
"cl_khr_byte_addressable_store"
" cl_khr_global_int32_base_atomics"
@@ -294,5 +299,6 @@ device::supported_extensions() const {
+ std::string(has_int64_atomics() ? " cl_khr_int64_base_atomics" : "")
+ std::string(has_int64_atomics() ? " cl_khr_int64_extended_atomics" :
"")
+ std::string(has_doubles() ? " cl_khr_fp64" : "")
- + std::string(has_halves() ? " cl_khr_fp16" : "");
+ + std::string(has_halves() ? " cl_khr_fp16" : "")
+ + std::string(supports_il_program ? " cl_khr_il_program" : "");
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 16/20] clover: Implement clCreateProgramWithILKHR
Changes since:
* v4:
- Use is_binary_spirv and is_valid_spirv from the SPIR-V backend;
- Drop the SPIRV-Tools and llvm-spirv dependencies on clover.
* v3: guard parts of the code behind SPIR-V support
* v2:
- Remove the const on the length argument to CreateProgramWithILKHR
(Francisco Jerez)
- Capitalize comment (Francisco Jerez);
- Store the IL as a std::vector instead of a pointer + size (Francisco
Jerez);
- Remove the destructor, due to previous change;
- Remove endianness conversion, as already performed later on
(Francisco Jerez);
- Introduce a free function for compile_program, which calls the right
compile function based on the IR format (Francisco Jerez);
- Add dependency on SPIRV-Tools, as we validate the SPIR-V module fed
to clCreateProgramWithILKHR;
- Introduce an enum for representing which IL is stored in program;
- Correctly initialise the devices associated to a program created
from clCreateProgramWithILKHR;
- Introduce free functions for validating the SPIR-V binary, and
detecting the IL used in the binary fed to clCreateProgramWithILKHR.
Signed-off-by: Pierre Moreau
---
.../state_trackers/clover/api/dispatch.hpp| 4 ++
.../state_trackers/clover/api/program.cpp | 60 ++-
.../state_trackers/clover/core/program.cpp| 47 ---
.../state_trackers/clover/core/program.hpp| 12
4 files changed, 113 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 84b992af9ba..dc9c94a5408 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -974,6 +974,10 @@ namespace clover {
cl_int
IcdGetPlatformIDsKHR(cl_uint num_entries, cl_platform_id *rd_platforms,
cl_uint *rnum_platforms);
+
+ cl_program
+ CreateProgramWithILKHR(cl_context d_ctx, const void *il,
+ size_t length, cl_int *r_errcode);
}
#endif
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index acfbe560445..00b252e12b4 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -22,6 +22,7 @@
#include "api/util.hpp"
#include "core/program.hpp"
+#include "spirv/invocation.hpp"
#include "util/u_debug.h"
#include
@@ -45,6 +46,26 @@ namespace {
}, objs(d_devs, num_devs)))
throw error(CL_INVALID_DEVICE);
}
+
+ enum program::il_type
+ identify_and_validate_il(const void *il, size_t length,
+const std::string _version,
+const context::notify_action ) {
+
+ enum program::il_type il_type = program::il_type::none;
+
+#ifdef CLOVER_ALLOW_SPIRV
+ const uint32_t *stream = reinterpret_cast(il);
+ if (spirv::is_binary_spirv(reinterpret_cast(il), length)) {
+ if (!spirv::is_valid_spirv(stream, length / 4u, opencl_version,
+notify))
+throw error(CL_INVALID_VALUE);
+ il_type = program::il_type::spirv;
+ }
+#endif
+
+ return il_type;
+ }
}
CLOVER_API cl_program
@@ -128,6 +149,41 @@ clCreateProgramWithBinary(cl_context d_ctx, cl_uint n,
return NULL;
}
+cl_program
+clover::CreateProgramWithILKHR(cl_context d_ctx, const void *il,
+ size_t length, cl_int *r_errcode) try {
+ auto = obj(d_ctx);
+
+ if (!il || !length)
+ throw error(CL_INVALID_VALUE);
+
+ // Compute the highest OpenCL version supported by all devices associated to
+ // the context. That is the version used for validating the SPIR-V binary.
+ std::string min_opencl_version;
+ for (const device : ctx.devices()) {
+ const std::string opencl_version = dev.device_version();
+ if (min_opencl_version.empty())
+ min_opencl_version = opencl_version;
+ else if (opencl_version < min_opencl_version)
+ min_opencl_version = opencl_version;
+ }
+
+ const enum program::il_type il_type = identify_and_validate_il(il, length,
+
min_opencl_version,
+ ctx.notify);
+
+ if (il_type == program::il_type::none)
+ throw error(CL_INVALID_VALUE);
+
+ // Initialize a program object with it.
+ ret_error(r_errcode, CL_SUCCESS);
+ return new program(ctx, reinterpret_cast(il), length, il_type);
+
+} catch (error ) {
+ ret_error(r_errcode, e);
+ return NULL;
+}
+
CLOVER_API cl_program
clCreateProgramWithBuiltInKernels(cl_context d_ctx, cl_uint n,
const cl_device_id *d_devs,
@@ -183,7 +239,7 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
-
[Mesa-dev] [PATCH v10 17/20] clover: Handle CL_PROGRAM_IL in clGetProgramInfo
Reviewed-by: Karol Herbst
Changes since:
* v3: Use the core define instead of the extension one (Karol Herbst)
* v2: Switch from using a pointer attribute to a vector (Francisco
Jerez)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/program.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index 00b252e12b4..9ad7297da57 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -424,6 +424,13 @@ clGetProgramInfo(cl_program d_prog, cl_program_info param,
buf.as_string() = prog.source();
break;
+ case CL_PROGRAM_IL:
+ if (prog.has_il)
+ buf.as_vector() = prog.il();
+ else if (r_size)
+ *r_size = 0u;
+ break;
+
case CL_PROGRAM_BINARY_SIZES:
buf.as_vector() = map([&](const device ) {
return prog.build(dev).binary.size();
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 18/20] clover/api: Implement CL_DEVICE_IL_VERSION
Reviewed-by: Karol Herbst
Changes since:
* v3: Use the core define instead of the extension one (Karol Herbst)
* v2: Throw an exception if the cl_khr_il_program extension is not
supported (Francisco Jerez)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/device.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/src/gallium/state_trackers/clover/api/device.cpp
index ca6b90ba271..242d7ea0a51 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -329,6 +329,13 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
buf.as_string() = dev.supported_extensions();
break;
+ case CL_DEVICE_IL_VERSION:
+ if (dev.supported_extensions().find("cl_khr_il_program") ==
std::string::npos)
+ throw error(CL_INVALID_VALUE);
+ buf.as_string() = std::string("SPIR-V_1.0");
+
+ break;
+
case CL_DEVICE_PLATFORM:
buf.as_scalar() = desc(dev.platform);
break;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 15/20] clover/spirv: Add functions for validating SPIR-V binaries
Changes since:
* v9: Add `clover_cpp_std` to the overrides of the `libclspirv` target
in Meson.
* v7: Add DEFINES to libclspirv and libclover, in autotools, as they
would otherwise never know whether CLOVER_ALLOW_SPIRV has been
defined (Dave Airlie)
* v6: Update the dependency name (meson) and the libs variable
(Makefile) due to the replacement of llvm-spirv to the new
official SPIRV-LLVM-Translator.
* v5: Changed to match the updated “clover/llvm: Allow translating from
SPIR-V to LLVM IR” in the v6.
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/Makefile.am | 17 ++-
.../state_trackers/clover/Makefile.sources| 4 +
src/gallium/state_trackers/clover/meson.build | 11 +-
.../clover/spirv/invocation.cpp | 138 ++
.../clover/spirv/invocation.hpp | 47 ++
5 files changed, 214 insertions(+), 3 deletions(-)
create mode 100644 src/gallium/state_trackers/clover/spirv/invocation.cpp
create mode 100644 src/gallium/state_trackers/clover/spirv/invocation.hpp
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium/state_trackers/clover/Makefile.am
index 2f42011104f..9bc078609fd 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -28,7 +28,7 @@ cl_HEADERS = \
$(top_srcdir)/include/CL/opencl.h
endif
-noinst_LTLIBRARIES = libclover.la libclllvm.la
+noinst_LTLIBRARIES = libclover.la libclllvm.la libclspirv.la
libclllvm_la_CXXFLAGS = \
$(CXX11_CXXFLAGS) \
@@ -47,13 +47,26 @@ libclllvm_la_SOURCES = $(LLVM_SOURCES)
libclllvm_la_LDFLAGS = \
$(LLVMSPIRVLIB_LIBS)
+libclspirv_la_CXXFLAGS = \
+ $(CXX11_CXXFLAGS) \
+ $(CLOVER_STD_OVERRIDE) \
+ $(DEFINES) \
+ $(VISIBILITY_CXXFLAGS) \
+ $(SPIRV_TOOLS_CFLAGS)
+
+libclspirv_la_SOURCES = $(SPIRV_SOURCES)
+
+libclspirv_la_LDFLAGS = \
+ $(SPIRV_TOOLS_LIBS)
+
libclover_la_CXXFLAGS = \
$(CXX11_CXXFLAGS) \
$(CLOVER_STD_OVERRIDE) \
+ $(DEFINES) \
$(VISIBILITY_CXXFLAGS)
libclover_la_LIBADD = \
- libclllvm.la
+ libclllvm.la libclspirv.la
libclover_la_SOURCES = $(CPP_SOURCES)
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index 5167ca75af4..38f94981fb6 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -62,3 +62,7 @@ LLVM_SOURCES := \
llvm/invocation.hpp \
llvm/metadata.hpp \
llvm/util.hpp
+
+SPIRV_SOURCES := \
+ spirv/invocation.cpp \
+ spirv/invocation.hpp
diff --git a/src/gallium/state_trackers/clover/meson.build
b/src/gallium/state_trackers/clover/meson.build
index 096c33f52e1..ffe858b1c2a 100644
--- a/src/gallium/state_trackers/clover/meson.build
+++ b/src/gallium/state_trackers/clover/meson.build
@@ -52,6 +52,15 @@ libclllvm = static_library(
override_options : clover_cpp_std,
)
+libclspirv = static_library(
+ 'clspirv',
+ files('spirv/invocation.cpp', 'spirv/invocation.hpp'),
+ include_directories : clover_incs,
+ cpp_args : [cpp_vis_args],
+ dependencies : [dep_spirv_tools],
+ override_options : clover_cpp_std,
+)
+
clover_files = files(
'api/context.cpp',
'api/device.cpp',
@@ -112,6 +121,6 @@ libclover = static_library(
[clover_files, sha1_h],
include_directories : clover_incs,
cpp_args : [clover_cpp_args, cpp_vis_args],
- link_with : [libclllvm],
+ link_with : [libclllvm, libclspirv],
override_options : clover_cpp_std,
)
diff --git a/src/gallium/state_trackers/clover/spirv/invocation.cpp
b/src/gallium/state_trackers/clover/spirv/invocation.cpp
new file mode 100644
index 000..93cc49931d5
--- /dev/null
+++ b/src/gallium/state_trackers/clover/spirv/invocation.cpp
@@ -0,0 +1,138 @@
+//
+// Copyright 2018 Pierre Moreau
+//
+// Permission is hereby granted, free of charge, to any person obtaining a
+// copy of this software and associated documentation files (the "Software"),
+// to deal in the Software without restriction, including without limitation
+// the rights to use, copy, modify, merge, publish, distribute, sublicense,
+// and/or sell copies of the Software, and to permit persons to whom the
+// Software is furnished to do so, subject to the following conditions:
+//
+// The above copyright notice and this permission notice shall be included in
+// all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
[Mesa-dev] [PATCH v10 13/20] clover/llvm: Allow translating from SPIR-V to LLVM IR
Changes since:
* v6: Update the LLVM API call due to the replacement of llvm-spirv to
the new official SPIRV-LLVM-Translator.
* v5: Update Makefile.am to add to libclllvm its new llvm-spirv
dependency. (Karol Herbst)
* v3:
- guard the SPIR-V code;
- use an istringstream instead of a bidirectional stringstream, and
initialise it directly (Francisco Jerez).
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/Makefile.am | 6 +++-
.../state_trackers/clover/llvm/invocation.cpp | 29 +++
.../state_trackers/clover/llvm/invocation.hpp | 6
src/gallium/state_trackers/clover/meson.build | 2 +-
4 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium/state_trackers/clover/Makefile.am
index 35ee092f3fd..2f42011104f 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -39,10 +39,14 @@ libclllvm_la_CXXFLAGS = \
$(LIBELF_CFLAGS) \
-DLIBCLC_INCLUDEDIR=\"$(LIBCLC_INCLUDEDIR)/\" \
-DLIBCLC_LIBEXECDIR=\"$(LIBCLC_LIBEXECDIR)/\" \
- -DCLANG_RESOURCE_DIR=\"$(CLANG_RESOURCE_DIR)\"
+ -DCLANG_RESOURCE_DIR=\"$(CLANG_RESOURCE_DIR)\" \
+ $(LLVMSPIRVLIB_CFLAGS)
libclllvm_la_SOURCES = $(LLVM_SOURCES)
+libclllvm_la_LDFLAGS = \
+ $(LLVMSPIRVLIB_LIBS)
+
libclover_la_CXXFLAGS = \
$(CXX11_CXXFLAGS) \
$(CLOVER_STD_OVERRIDE) \
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 0a677ce2eaa..155dfc6964c 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -24,12 +24,17 @@
// OTHER DEALINGS IN THE SOFTWARE.
//
+#include
+
#include
#include
#include
#include
#include
#include
+#ifdef CLOVER_ALLOW_SPIRV
+#include
+#endif
#include
#include
@@ -395,3 +400,27 @@ clover::llvm::link_program(const std::vector
,
unreachable("Unsupported IR.");
}
}
+
+#ifdef CLOVER_ALLOW_SPIRV
+module
+clover::llvm::compile_from_spirv(const std::vector ,
+ const device ,
+ std::string _log) {
+ auto ctx = create_context(r_log);
+
+ ::llvm::Module *unsafe_mod;
+ std::string error_msg;
+ std::istringstream input({ binary.begin(), binary.end() },
std::ios_base::binary);
+ if (!::llvm::readSpirv(*ctx, input, unsafe_mod, error_msg)) {
+ r_log += "Failed to convert SPIR-V to LLVM IR: " + error_msg + ".\n";
+ throw error(CL_INVALID_VALUE);
+ }
+
+ std::unique_ptr<::llvm::Module> mod(unsafe_mod);
+
+ if (has_flag(debug::llvm))
+ debug::log(".ll", print_module_bitcode(*mod));
+
+ return build_module_library(*mod, module::section::text_intermediate);
+}
+#endif
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.hpp
b/src/gallium/state_trackers/clover/llvm/invocation.hpp
index ff9caa457ca..85b16f6c902 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.hpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.hpp
@@ -40,6 +40,12 @@ namespace clover {
const device ,
const std::string ,
std::string _log);
+
+#ifdef CLOVER_ALLOW_SPIRV
+ module compile_from_spirv(const std::vector ,
+const device ,
+std::string _log);
+#endif
}
}
diff --git a/src/gallium/state_trackers/clover/meson.build
b/src/gallium/state_trackers/clover/meson.build
index 7f0c60d40d9..096c33f52e1 100644
--- a/src/gallium/state_trackers/clover/meson.build
+++ b/src/gallium/state_trackers/clover/meson.build
@@ -48,7 +48,7 @@ libclllvm = static_library(
dep_llvm.get_configtool_variable('version'), 'include',
)),
],
- dependencies : [dep_llvm, dep_elf],
+ dependencies : [dep_llvm, dep_elf, dep_llvmspirvlib],
override_options : clover_cpp_std,
)
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 12/20] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv
Reviewed-by: Dylan Baker
Changes since:
* v7:
- Properly align LLVMSPIRVLib comment (Dylan Baker)
- Only define CLOVER_ALLOW_SPIRV when **both** dependencies are found:
autotools was only requiring one or the other.
* v6: Replace the llvm-spirv repository by the new official
SPIRV-LLVM-Translator.
* v4: Add a comment saying where to find llvm-spirv (Karol Herbst).
* v3:
- make SPIRV-Tools and llvm-spirv optional (Francisco Jerez);
- bump requirement for llvm-spirv to version 0.2
* v2:
- Bump the required version of SPIRV-Tools to the latest release;
- Add a dependency on llvm-spirv.
Signed-off-by: Pierre Moreau
---
configure.ac | 18 ++
meson.build | 8
2 files changed, 26 insertions(+)
diff --git a/configure.ac b/configure.ac
index e4d20054d5f..799246e8319 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2513,6 +2513,24 @@ AM_CONDITIONAL(HAVE_CLOVER_ICD, test
"x$enable_opencl_icd" = xyes)
AC_SUBST([OPENCL_LIBNAME])
AC_SUBST([CLANG_RESOURCE_DIR])
+AS_IF([test "x$enable_opencl" = xyes], [
+PKG_CHECK_MODULES([SPIRV_TOOLS], [SPIRV-Tools >= 2018.0],
+ [have_spirv_tools=yes], [have_spirv_tools=no])])
+AC_SUBST([SPIRV_TOOLS_CFLAGS])
+AC_SUBST([SPIRV_TOOLS_LIBS])
+
+# LLVMSPIRVLib is available at
https://github.com/KhronosGroup/SPIRV-LLVM-Translator
+AS_IF([test "x$enable_opencl" = xyes], [
+PKG_CHECK_MODULES([LLVMSPIRVLIB], [LLVMSPIRVLib >= 0.2.1],
+ [have_llvmspirvlib=yes], [have_llvmspirvlib=no])])
+AC_SUBST([LLVMSPIRVLIB_CFLAGS])
+AC_SUBST([LLVMSPIRVLIB_LIBS])
+
+if test "x$have_spirv_tools" = xyes -a \
+"x$have_llvmspirvlib" = xyes; then
+DEFINES="$DEFINES -DCLOVER_ALLOW_SPIRV"
+fi
+
dnl
dnl Gallium configuration
dnl
diff --git a/meson.build b/meson.build
index 709f77a9c7a..7f63d6c84cc 100644
--- a/meson.build
+++ b/meson.build
@@ -655,6 +655,12 @@ if _opencl != 'disabled'
endif
dep_clc = dependency('libclc')
+ dep_spirv_tools = dependency('SPIRV-Tools', required : false, version : '>=
2018.0')
+ # LLVMSPIRVLib is available at
https://github.com/KhronosGroup/SPIRV-LLVM-Translator
+ dep_llvmspirvlib = dependency('LLVMSPIRVLib', required : false, version :
'>= 0.2.1')
+ if dep_spirv_tools.found() and dep_llvmspirvlib.found()
+pre_args += '-DCLOVER_ALLOW_SPIRV'
+ endif
with_gallium_opencl = true
with_opencl_icd = _opencl == 'icd'
@@ -667,6 +673,8 @@ if _opencl != 'disabled'
endif
else
dep_clc = null_dep
+ dep_spirv_tools = null_dep
+ dep_llvmspirvlib = null_dep
with_gallium_opencl = false
with_gallium_icd = false
endif
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 14/20] include/CL: Add cl_khr_il_program
Reviewed-by: Karol Herbst Signed-off-by: Pierre Moreau --- include/CL/cl_ext.h | 37 + 1 file changed, 37 insertions(+) diff --git a/include/CL/cl_ext.h b/include/CL/cl_ext.h index 5078e8f45f0..5ea49680423 100644 --- a/include/CL/cl_ext.h +++ b/include/CL/cl_ext.h @@ -599,6 +599,43 @@ clSetKernelExecInfoARM(cl_kernel/* kernel */, #endif /* CL_VERSION_1_2 */ +/*** + * cl_khr_il_program extension * + ***/ + +#if defined(CL_VERSION_1_2) || defined(CL_VERSION_2_0) + +#ifndef cl_khr_il_program +#define cl_khr_il_program 1 + +/* New property to clGetDeviceInfo for retrieving supported intermediate + * languages + */ +#define CL_DEVICE_IL_VERSION_KHR0x105B + +/* New property to clGetProgramInfo for retrieving for retrieving the IL of a + * program + */ +#define CL_PROGRAM_IL_KHR 0x1169 + +extern CL_API_ENTRY cl_program + CL_API_CALL clCreateProgramWithILKHR( + cl_context /* context */, + const void * /* il */, + size_t /* length */, + cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2; + +typedef CL_API_ENTRY cl_program + (CL_API_CALL *clCreateProgramWithILKHR_fn)( + cl_context /* context */, + const void * /* il */, + size_t /* length */, + cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2; + +#endif /* CL_VERSION_1_2 || CL_VERSION_2_0 */ + +#endif /* cl_khr_il_program */ + #ifdef __cplusplus } #endif -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 11/20] clover: Move platform extensions definitions to clover/platform.cpp
Reviewed-by: Francisco Jerez
Reviewed-by: Aaron Watry
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/platform.cpp | 4 ++--
src/gallium/state_trackers/clover/core/platform.cpp | 5 +
src/gallium/state_trackers/clover/core/platform.hpp | 2 ++
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
b/src/gallium/state_trackers/clover/api/platform.cpp
index fddbbecaa59..a684d34ba44 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -51,7 +51,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
cl_platform_info param,
size_t size, void *r_buf, size_t *r_size) try {
property_buffer buf { r_buf, size, r_size };
- obj(d_platform);
+ auto = obj(d_platform);
switch (param) {
case CL_PLATFORM_PROFILE:
@@ -74,7 +74,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
cl_platform_info param,
break;
case CL_PLATFORM_EXTENSIONS:
- buf.as_string() = "cl_khr_icd";
+ buf.as_string() = platform.supported_extensions();
break;
case CL_PLATFORM_ICD_SUFFIX_KHR:
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
b/src/gallium/state_trackers/clover/core/platform.cpp
index 489e8dc5a83..ddd63fc5a0d 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -39,3 +39,8 @@ platform::platform() : adaptor_range(evals(), devs) {
}
}
}
+
+std::string
+platform::supported_extensions() const {
+ return "cl_khr_icd";
+}
diff --git a/src/gallium/state_trackers/clover/core/platform.hpp
b/src/gallium/state_trackers/clover/core/platform.hpp
index e849645bbed..b94434c983c 100644
--- a/src/gallium/state_trackers/clover/core/platform.hpp
+++ b/src/gallium/state_trackers/clover/core/platform.hpp
@@ -40,6 +40,8 @@ namespace clover {
platform &
operator=(const platform ) = delete;
+ std::string supported_extensions() const;
+
protected:
std::vector> devs;
};
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 06/20] clover/api: Rework the validation of devices for building
Reviewed-by: Francisco Jerez
Changes since:
* v5:
- Drop the `valid_devs` argument to `validate_build_common()`
(Francisco Jerez)
- Change `clLinkProgram()` to initialise `prog`’s devices prior to
calling `validate_build_common()`.
* v2:
- validate_build_common no longer returns a list of devices (Francisco
Jerez);
- Dropped duplicate checks (Francisco Jerez).
Signed-off-by: Pierre Moreau
---
.../state_trackers/clover/api/program.cpp | 18 +-
.../state_trackers/clover/core/program.cpp | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index 9d59668f8f6..891a002f3d0 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -41,7 +41,7 @@ namespace {
throw error(CL_INVALID_OPERATION);
if (any_of([&](const device ) {
- return !count(dev, prog.context().devices());
+ return !count(dev, prog.devices());
}, objs(d_devs, num_devs)))
throw error(CL_INVALID_DEVICE);
}
@@ -176,8 +176,8 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
void (*pfn_notify)(cl_program, void *),
void *user_data) try {
auto = obj(d_prog);
- auto devs = (d_devs ? objs(d_devs, num_devs) :
-ref_vector(prog.context().devices()));
+ auto devs =
+ (d_devs ? objs(d_devs, num_devs) : ref_vector(prog.devices()));
const auto opts = std::string(p_opts ? p_opts : "") + " " +
debug_get_option("CLOVER_EXTRA_BUILD_OPTIONS", "");
@@ -202,8 +202,8 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
void (*pfn_notify)(cl_program, void *),
void *user_data) try {
auto = obj(d_prog);
- auto devs = (d_devs ? objs(d_devs, num_devs) :
-ref_vector(prog.context().devices()));
+ auto devs =
+ (d_devs ? objs(d_devs, num_devs) : ref_vector(prog.devices()));
const auto opts = std::string(p_opts ? p_opts : "") + " " +
debug_get_option("CLOVER_EXTRA_COMPILE_OPTIONS", "");
header_map headers;
@@ -279,10 +279,10 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const
cl_device_id *d_devs,
const auto opts = std::string(p_opts ? p_opts : "") + " " +
debug_get_option("CLOVER_EXTRA_LINK_OPTIONS", "");
auto progs = objs(d_progs, num_progs);
- auto prog = create(ctx);
- auto devs = validate_link_devices(progs,
- (d_devs ? objs(d_devs, num_devs) :
- ref_vector(ctx.devices(;
+ auto all_devs =
+ (d_devs ? objs(d_devs, num_devs) : ref_vector(ctx.devices()));
+ auto prog = create(ctx, all_devs);
+ auto devs = validate_link_devices(progs, all_devs);
validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
diff --git a/src/gallium/state_trackers/clover/core/program.cpp
b/src/gallium/state_trackers/clover/core/program.cpp
index ec71d99b017..62fa13efbf9 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -26,7 +26,8 @@
using namespace clover;
program::program(clover::context , const std::string ) :
- has_source(true), context(ctx), _source(source), _kernel_ref_counter(0) {
+ has_source(true), context(ctx), _devices(ctx.devices()), _source(source),
+ _kernel_ref_counter(0) {
}
program::program(clover::context ,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 09/20] clover: Track flags per module section
One flag that needs to be tracked is whether a library is allowed to
received mathematics optimisations or not, as the authorisation is given
when creating the library while the optimisations are specified when
creating the executable.
Reviewed-by: Aaron Watry
Changes since:
* v3: drop the modification to the tgsi backend, as already dropped
(Aaron Watry)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/core/module.cpp | 1 +
src/gallium/state_trackers/clover/core/module.hpp | 13 +
.../state_trackers/clover/llvm/codegen/bitcode.cpp | 3 ++-
.../state_trackers/clover/llvm/codegen/common.cpp | 2 +-
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/module.cpp
b/src/gallium/state_trackers/clover/core/module.cpp
index a6c5b98d8e0..0e11506d0d7 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -163,6 +163,7 @@ namespace {
proc(S , QT ) {
_proc(s, x.id);
_proc(s, x.type);
+ _proc(s, x.flags);
_proc(s, x.size);
_proc(s, x.data);
}
diff --git a/src/gallium/state_trackers/clover/core/module.hpp
b/src/gallium/state_trackers/clover/core/module.hpp
index 2ddd26426fb..ff7e9b6234a 100644
--- a/src/gallium/state_trackers/clover/core/module.hpp
+++ b/src/gallium/state_trackers/clover/core/module.hpp
@@ -41,14 +41,19 @@ namespace clover {
data_local,
data_private
};
+ enum class flags_t {
+none,
+allow_link_options
+ };
- section(resource_id id, enum type type, size_t size,
- const std::vector ) :
- id(id), type(type), size(size), data(data) { }
- section() : id(0), type(text_intermediate), size(0), data() { }
+ section(resource_id id, enum type type, flags_t flags,
+ size_t size, const std::vector ) :
+ id(id), type(type), flags(flags), size(size), data(data) { }
+ section() : id(0), type(text_intermediate), flags(flags_t::none),
size(0), data() { }
resource_id id;
type type;
+ flags_t flags;
size_t size;
std::vector data;
};
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 40bb426218d..8e9d4c7e85c 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -84,7 +84,8 @@ clover::llvm::build_module_library(const ::llvm::Module ,
enum module::section::type section_type) {
module m;
const auto code = emit_code(mod);
- m.secs.emplace_back(0, section_type, code.size(), code);
+ m.secs.emplace_back(0, section_type, module::section::flags_t::none,
+ code.size(), code);
return m;
}
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index ca5f78940d2..a278e675003 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
@@ -178,7 +178,7 @@ namespace {
make_text_section(const std::vector ) {
const pipe_llvm_program_header header { uint32_t(code.size()) };
module::section text { 0, module::section::text_executable,
- header.num_bytes, {} };
+ module::section::flags_t::none, header.num_bytes,
{} };
text.data.insert(text.data.end(), reinterpret_cast(),
reinterpret_cast() +
sizeof(header));
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 10/20] clover: Move device extensions definitions to core/device.cpp
Reviewed-by: Francisco Jerez
Reviewed-by: Aaron Watry
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/device.cpp | 11 +--
src/gallium/state_trackers/clover/core/device.cpp | 14 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/src/gallium/state_trackers/clover/api/device.cpp
index 5a4f94c1141..ca6b90ba271 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -326,16 +326,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
case CL_DEVICE_EXTENSIONS:
- buf.as_string() =
- "cl_khr_byte_addressable_store"
- " cl_khr_global_int32_base_atomics"
- " cl_khr_global_int32_extended_atomics"
- " cl_khr_local_int32_base_atomics"
- " cl_khr_local_int32_extended_atomics"
- + std::string(dev.has_int64_atomics() ? " cl_khr_int64_base_atomics"
: "")
- + std::string(dev.has_int64_atomics() ? "
cl_khr_int64_extended_atomics" : "")
- + std::string(dev.has_doubles() ? " cl_khr_fp64" : "")
- + std::string(dev.has_halves() ? " cl_khr_fp16" : "");
+ buf.as_string() = dev.supported_extensions();
break;
case CL_DEVICE_PLATFORM:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index bd67bab5bc8..21de0e3d61c 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -282,3 +282,17 @@ device::supports_ir(enum pipe_shader_ir ir) const {
return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
PIPE_SHADER_CAP_SUPPORTED_IRS) & (1 << ir);
}
+
+std::string
+device::supported_extensions() const {
+ return
+ "cl_khr_byte_addressable_store"
+ " cl_khr_global_int32_base_atomics"
+ " cl_khr_global_int32_extended_atomics"
+ " cl_khr_local_int32_base_atomics"
+ " cl_khr_local_int32_extended_atomics"
+ + std::string(has_int64_atomics() ? " cl_khr_int64_base_atomics" : "")
+ + std::string(has_int64_atomics() ? " cl_khr_int64_extended_atomics" :
"")
+ + std::string(has_doubles() ? " cl_khr_fp64" : "")
+ + std::string(has_halves() ? " cl_khr_fp16" : "");
+}
diff --git a/src/gallium/state_trackers/clover/core/device.hpp
b/src/gallium/state_trackers/clover/core/device.hpp
index ebe15f28e93..a7084e863f4 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -83,6 +83,7 @@ namespace clover {
std::string ir_target() const;
enum pipe_endian endianness() const;
bool supports_ir(enum pipe_shader_ir ir) const;
+ std::string supported_extensions() const;
friend class command_queue;
friend class root_resource;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 04/20] clover: Add an helper for checking if an IR is supported
Reviewed-by: Aaron Watry
Reviewed-by: Karol Herbst
Changes since:
* v2:
- Dropped supported_irs() (Francisco Jerez)
- Changed supports_ir() argument type to `enum pipe_shader_ir`
(Francisco Jerez)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
2 files changed, 7 insertions(+)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 0d911e37514..62d5221bf83 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -280,3 +280,9 @@ device::device_clc_version() const {
debug_get_option("CLOVER_DEVICE_CLC_VERSION_OVERRIDE", "1.1");
return device_clc_version;
}
+
+bool
+device::supports_ir(enum pipe_shader_ir ir) const {
+ return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
+ PIPE_SHADER_CAP_SUPPORTED_IRS) & (1 << ir);
+}
diff --git a/src/gallium/state_trackers/clover/core/device.hpp
b/src/gallium/state_trackers/clover/core/device.hpp
index 85cd031676d..ebe15f28e93 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -82,6 +82,7 @@ namespace clover {
enum pipe_shader_ir ir_format() const;
std::string ir_target() const;
enum pipe_endian endianness() const;
+ bool supports_ir(enum pipe_shader_ir ir) const;
friend class command_queue;
friend class root_resource;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 07/20] clover/api: Fail if trying to build a non-executable binary
From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram):
> If program is created with clCreateProgramWithBinary, then the
> program binary must be an executable binary (not a compiled binary or
> library).
Reviewed-by: Aaron Watry
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/program.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index 891a002f3d0..ac8bc8a5630 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -186,6 +186,13 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
if (prog.has_source) {
prog.compile(devs, opts);
prog.link(devs, opts, { prog });
+ } else if (any_of([&](const device ){
+ return prog.build(dev).binary_type() !=
CL_PROGRAM_BINARY_TYPE_EXECUTABLE;
+ }, devs)) {
+ // According to the OpenCL 1.2 specification, “if program is created
+ // with clCreateProgramWithBinary, then the program binary must be an
+ // executable binary (not a compiled binary or library).”
+ throw error(CL_INVALID_BINARY);
}
return CL_SUCCESS;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 03/20] clover: Remove the TGSI backend as unused
Reviewed-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/Makefile.am | 11 +-
.../state_trackers/clover/Makefile.sources| 4 -
.../state_trackers/clover/core/program.cpp| 13 +-
src/gallium/state_trackers/clover/meson.build | 10 +-
.../state_trackers/clover/tgsi/compiler.cpp | 120 --
.../state_trackers/clover/tgsi/invocation.hpp | 37 --
6 files changed, 8 insertions(+), 187 deletions(-)
delete mode 100644 src/gallium/state_trackers/clover/tgsi/compiler.cpp
delete mode 100644 src/gallium/state_trackers/clover/tgsi/invocation.hpp
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium/state_trackers/clover/Makefile.am
index a7befb46059..35ee092f3fd 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -28,14 +28,7 @@ cl_HEADERS = \
$(top_srcdir)/include/CL/opencl.h
endif
-noinst_LTLIBRARIES = libclover.la libcltgsi.la libclllvm.la
-
-libcltgsi_la_CXXFLAGS = \
- $(CXX11_CXXFLAGS) \
- $(CLOVER_STD_OVERRIDE) \
- $(VISIBILITY_CXXFLAGS)
-
-libcltgsi_la_SOURCES = $(TGSI_SOURCES)
+noinst_LTLIBRARIES = libclover.la libclllvm.la
libclllvm_la_CXXFLAGS = \
$(CXX11_CXXFLAGS) \
@@ -56,7 +49,7 @@ libclover_la_CXXFLAGS = \
$(VISIBILITY_CXXFLAGS)
libclover_la_LIBADD = \
- libcltgsi.la libclllvm.la
+ libclllvm.la
libclover_la_SOURCES = $(CPP_SOURCES)
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index e9828b107b5..5167ca75af4 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -62,7 +62,3 @@ LLVM_SOURCES := \
llvm/invocation.hpp \
llvm/metadata.hpp \
llvm/util.hpp
-
-TGSI_SOURCES := \
- tgsi/compiler.cpp \
- tgsi/invocation.hpp
diff --git a/src/gallium/state_trackers/clover/core/program.cpp
b/src/gallium/state_trackers/clover/core/program.cpp
index 4e74fccd973..ec71d99b017 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -22,7 +22,6 @@
#include "core/program.hpp"
#include "llvm/invocation.hpp"
-#include "tgsi/invocation.hpp"
using namespace clover;
@@ -51,10 +50,9 @@ program::compile(const ref_vector , const
std::string ,
std::string log;
try {
-const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
- tgsi::compile_program(_source, log) :
- llvm::compile_program(_source, headers, dev,
-opts, log));
+assert(dev.ir_format() == PIPE_SHADER_IR_NATIVE);
+const module m = llvm::compile_program(_source, headers, dev, opts,
+ log);
_builds[] = { m, opts, log };
} catch (...) {
_builds[] = { module(), opts, log };
@@ -76,9 +74,8 @@ program::link(const ref_vector , const
std::string ,
std::string log = _builds[].log;
try {
- const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
- tgsi::link_program(ms) :
- llvm::link_program(ms, dev, opts, log));
+ assert(dev.ir_format() == PIPE_SHADER_IR_NATIVE);
+ const module m = llvm::link_program(ms, dev, opts, log);
_builds[] = { m, opts, log };
} catch (...) {
_builds[] = { module(), opts, log };
diff --git a/src/gallium/state_trackers/clover/meson.build
b/src/gallium/state_trackers/clover/meson.build
index a6729af2fb8..7f0c60d40d9 100644
--- a/src/gallium/state_trackers/clover/meson.build
+++ b/src/gallium/state_trackers/clover/meson.build
@@ -25,14 +25,6 @@ if with_opencl_icd
clover_cpp_args += '-DHAVE_CLOVER_ICD'
endif
-libcltgsi = static_library(
- 'cltgsi',
- files('tgsi/compiler.cpp', 'tgsi/invocation.hpp'),
- include_directories : clover_incs,
- cpp_args : [cpp_vis_args],
- override_options : clover_cpp_std,
-)
-
libclllvm = static_library(
'clllvm',
files(
@@ -120,6 +112,6 @@ libclover = static_library(
[clover_files, sha1_h],
include_directories : clover_incs,
cpp_args : [clover_cpp_args, cpp_vis_args],
- link_with : [libcltgsi, libclllvm],
+ link_with : [libclllvm],
override_options : clover_cpp_std,
)
diff --git a/src/gallium/state_trackers/clover/tgsi/compiler.cpp
b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
deleted file mode 100644
index e165311fa41..000
--- a/src/gallium/state_trackers/clover/tgsi/compiler.cpp
+++ /dev/null
@@ -1,120 +0,0 @@
-//
-// Copyright 2012 Francisco Jerez
-//
-// Permission is hereby granted, free of charge, to any person obtaining a
-// copy of this software and associated documentation files (the "Software"),
-// to deal in the Software
[Mesa-dev] [PATCH v10 05/20] clover/device: Replace usage of "1 << PIPE_SHADER_IR_*" with supports_ir
Reviewed-by: Aaron Watry
Reviewed-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/core/device.cpp | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 62d5221bf83..bd67bab5bc8 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -244,11 +244,7 @@ device::vendor_name() const {
enum pipe_shader_ir
device::ir_format() const {
- int supported_irs =
- pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
- PIPE_SHADER_CAP_SUPPORTED_IRS);
-
- if (supported_irs & (1 << PIPE_SHADER_IR_NATIVE)) {
+ if (supports_ir(PIPE_SHADER_IR_NATIVE)) {
return PIPE_SHADER_IR_NATIVE;
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 08/20] clover: Disallow creating libraries from other libraries
If creating a library, do not allow non-compiled object in it, as
executables are not allowed, and libraries would make it really hard to
enforce the "-enable-link-options" flag.
Reviewed-by: Francisco Jerez
Reviewed-by: Aaron Watry
Changes since:
* v5: changed to accommodate the update of "clover/api: Rework the
validation of devices for building” in the v6.
* v2: Re-write the explanation as to why libraries can’t be created from
other libraries (Francisco Jerez)
Signed-off-by: Pierre Moreau
---
.../state_trackers/clover/api/program.cpp | 21 ---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index ac8bc8a5630..acfbe560445 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -250,8 +250,11 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
namespace {
ref_vector
validate_link_devices(const ref_vector ,
- const ref_vector _devs) {
+ const ref_vector _devs,
+ const std::string ) {
std::vector devs;
+ const bool create_library =
+ opts.find("-create-library") != std::string::npos;
for (auto : all_devs) {
const auto has_binary = [&](const program ) {
@@ -260,10 +263,22 @@ namespace {
t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
};
+ // According to the OpenCL 1.2 specification, a library is made of
+ // “compiled binaries specified in input_programs argument to
+ // clLinkProgram“; compiled binaries does not refer to libraries:
+ // “input_programs is an array of program objects that are compiled
+ // binaries or libraries that are to be linked to create the program
+ // executable”.
+ if (create_library && any_of([&](const program ) {
+ const auto t = prog.build(dev).binary_type();
+ return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
+ }, progs))
+throw error(CL_INVALID_OPERATION);
+
// According to the CL 1.2 spec, when "all programs specified [..]
// contain a compiled binary or library for the device [..] a link is
// performed",
- if (all_of(has_binary, progs))
+ else if (all_of(has_binary, progs))
devs.push_back();
// otherwise if "none of the programs contain a compiled binary or
@@ -289,7 +304,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const
cl_device_id *d_devs,
auto all_devs =
(d_devs ? objs(d_devs, num_devs) : ref_vector(ctx.devices()));
auto prog = create(ctx, all_devs);
- auto devs = validate_link_devices(progs, all_devs);
+ auto devs = validate_link_devices(progs, all_devs, opts);
validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v10 02/20] clover: update ICD table to support everything up to 2.2
From: Karol Herbst
v6: Fix return type of clCreateCommandQueueWithProperties
v2: add more prototypes
Reviewed-by: Pierre Moreau
Signed-off-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
.../state_trackers/clover/api/dispatch.cpp| 29 ++-
.../state_trackers/clover/api/dispatch.hpp| 190 ++
2 files changed, 218 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 8f4cfdc7fb2..8be4d3cb261 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -142,6 +142,33 @@ namespace clover {
NULL, // clEnqueueReleaseD3D11ObjectsKHR
NULL, // clGetDeviceIDsFromDX9MediaAdapterKHR
NULL, // clEnqueueAcquireDX9MediaSurfacesKHR
- NULL // clEnqueueReleaseDX9MediaSurfacesKHR
+ NULL, // clEnqueueReleaseDX9MediaSurfacesKHR
+ NULL, // clCreateFromEGLImageKHR
+ NULL, // clEnqueueAcquireEGLObjectsKHR
+ NULL, // clEnqueueReleaseEGLObjectsKHR
+ NULL, // clCreateEventFromEGLSyncKHR
+ NULL, // clCreateCommandQueueWithProperties
+ NULL, // clCreatePipe
+ NULL, // clGetPipeInfo
+ NULL, // clSVMAlloc
+ NULL, // clSVMFree
+ NULL, // clEnqueueSVMFree
+ NULL, // clEnqueueSVMMemcpy
+ NULL, // clEnqueueSVMMemFill
+ NULL, // clEnqueueSVMMap
+ NULL, // clEnqueueSVMUnmap
+ NULL, // clCreateSamplerWithProperties
+ NULL, // clSetKernelArgSVMPointer
+ NULL, // clSetKernelExecInfo
+ NULL, // clGetKernelSubGroupInfoKHR
+ NULL, // clCloneKernel
+ NULL, // clCreateProgramWithIL
+ NULL, // clEnqueueSVMMigrateMem
+ NULL, // clGetDeviceAndHostTimer
+ NULL, // clGetHostTimer
+ NULL, // clGetKernelSubGroupInfo
+ NULL, // clSetDefaultDeviceCommandQueue
+ NULL, // clSetProgramReleaseCallback
+ NULL, // clSetProgramSpecializationConstant
};
}
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 0ec1b51fa6d..84b992af9ba 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -27,6 +27,7 @@
#include "CL/cl.h"
#include "CL/cl_ext.h"
+#include "CL/cl_egl.h"
#include "CL/cl_gl.h"
///
@@ -765,6 +766,195 @@ struct _cl_icd_dispatch {
void *clGetDeviceIDsFromDX9MediaAdapterKHR;
void *clEnqueueAcquireDX9MediaSurfacesKHR;
void *clEnqueueReleaseDX9MediaSurfacesKHR;
+
+ CL_API_ENTRY void (CL_API_CALL *clCreateFromEGLImageKHR)(
+ cl_context context,
+ CLeglDisplayKHR display,
+ CLeglImageKHR image,
+ cl_mem_flags flags,
+ const cl_egl_image_properties_khr *properties,
+ cl_int *errcode_ret);
+
+ CL_API_ENTRY void (CL_API_CALL *clEnqueueAcquireEGLObjectsKHR)(
+ cl_command_queue command_queue,
+ cl_uint num_objects,
+ const cl_mem *mem_objects,
+ cl_uint num_events_in_wait_list,
+ const cl_event *event_wait_list,
+ cl_event *event);
+
+ CL_API_ENTRY void (CL_API_CALL *clEnqueueReleaseEGLObjectsKHR)(
+ cl_command_queue command_queue,
+ cl_uint num_objects,
+ const cl_mem *mem_objects,
+ cl_uint num_events_in_wait_list,
+ const cl_event *event_wait_list,
+ cl_event *event);
+
+ CL_API_ENTRY void (CL_API_CALL *clCreateEventFromEGLSyncKHR)(
+ cl_context context,
+ CLeglSyncKHR sync,
+ CLeglDisplayKHR display,
+ cl_int *errcode_ret);
+
+ CL_API_ENTRY cl_command_queue (CL_API_CALL
*clCreateCommandQueueWithProperties)(
+ cl_context context,
+ cl_device_id device,
+ const cl_queue_properties *properties,
+ cl_int *errcode_ret);
+
+ CL_API_ENTRY void (CL_API_CALL *clCreatePipe)(
+ cl_context context,
+ cl_mem_flags flags,
+ cl_uint pipe_packet_size,
+ cl_uint pipe_max_packets,
+ const cl_pipe_properties *properties,
+ cl_int *errcode_ret);
+
+ CL_API_ENTRY void (CL_API_CALL *clGetPipeInfo)(
+ cl_mem pipe,
+ cl_pipe_info param_name,
+ size_t param_value_size,
+ void *param_value,
+ size_t *param_value_size_ret);
+
+ CL_API_ENTRY void (CL_API_CALL *clSVMAlloc)(
+ cl_context context,
+ cl_svm_mem_flags flags,
+ size_t size,
+ unsigned int alignment);
+
+ CL_API_ENTRY void (CL_API_CALL *clSVMFree)(
+ cl_context context,
+ void *svm_pointer);
+
+ CL_API_ENTRY cl_int (CL_API_CALL *clEnqueueSVMFree)(
+ cl_command_queue command_queue,
+ cl_uint num_svm_pointers,
+ void **svm_pointers,
+ void (CL_CALLBACK *pfn_free_func)(cl_command_queue, cl_uint, void **,
void *),
+ void *user_data,
+ cl_uint num_events_in_wait_list,
+ const cl_event *event_wait_list,
+ cl_event *event);
+
+ CL_API_ENTRY cl_int (CL_API_CALL *clEnqueueSVMMemcpy)(
+ cl_command_queue command_queue,
+ cl_bool blocking_copy,
+
[Mesa-dev] [PATCH v10 00/20] Introducing SPIR-V support to clover
Hello everyone,
The series is largely unchanged compared to the previous version, but it was
also rebased on the latest master. It would be nice to have the series merged
in for 19.0 (only three patches out of 20 are missing a review), if the series
is ready enough.
For recap since this series has been going on for a while and the last update
was some time ago, this series focuses on three areas:
* Updating the OpenCL headers and ICD table to OpenCL 2.2;
* Cleaning up and improving certain areas in clover, mostly in preparation for
SPIR-V support;
* Accepting SPIR-V as an input (via the cl_khr_il_program extension for OpenCL
<2.1, as well as via the OpenCL >=2.1 core support) and converting it to LLVM
IR so that in can easily be used by drivers that already consume LLVM IR.
Missing reviews:
* Patch 13 (“clover/llvm: Allow translating from SPIR-V to LLVM”)
* Patch 15 (“clover/spirv: Add functions for validating SPIR-V binaries”)
* Patch 16 (“clover: Implement clCreateProgramWithILKHR”)
Changes since v9:
* Patch 15 (“clover/spirv: Add functions for validating SPIR-V binaries”):
* Fix rebase conflicts against master;
* Add `clover_cpp_std` to the overrides of the libcspirv target on Meson.
Changes since v8:
* Patch 3 (“clover/api: Fix tab indentation to spaces”) was dropped as another
fix was merged in the mean time.
The whole series can be found at
https://gitlab.freedesktop.org/pmoreau/mesa/commits/clover_spirv_series_v10.
Thanks in advance,
Pierre
Karol Herbst (1):
clover: update ICD table to support everything up to 2.2
Pierre Moreau (19):
include/CL: Update to the latest OpenCL 2.2 headers
clover: Remove the TGSI backend as unused
clover: Add an helper for checking if an IR is supported
clover/device: Replace usage of "1 << PIPE_SHADER_IR_*" with
supports_ir
clover/api: Rework the validation of devices for building
clover/api: Fail if trying to build a non-executable binary
clover: Disallow creating libraries from other libraries
clover: Track flags per module section
clover: Move device extensions definitions to core/device.cpp
clover: Move platform extensions definitions to clover/platform.cpp
configure.ac,meson: Check for SPIRV-Tools and llvm-spirv
clover/llvm: Allow translating from SPIR-V to LLVM IR
include/CL: Add cl_khr_il_program
clover/spirv: Add functions for validating SPIR-V binaries
clover: Implement clCreateProgramWithILKHR
clover: Handle CL_PROGRAM_IL in clGetProgramInfo
clover/api: Implement CL_DEVICE_IL_VERSION
clover: Advertise cl_khr_il_program
clover: Implement clCreateProgramWithIL from OpenCL 2.1
configure.ac | 18 +
include/CL/cl.h | 472 ++
include/CL/cl_d3d10.h | 7 +-
include/CL/cl_d3d11.h | 7 +-
include/CL/cl_dx9_media_sharing.h | 9 +-
include/CL/cl_dx9_media_sharing_intel.h | 182 +++
include/CL/cl_egl.h | 9 +-
include/CL/cl_ext.h | 338 -
include/CL/cl_ext_intel.h | 429
include/CL/cl_gl.h| 7 +-
include/CL/cl_gl_ext.h| 7 +-
include/CL/cl_platform.h | 328 +---
include/CL/cl_va_api_media_sharing_intel.h| 172 +++
include/CL/opencl.h | 7 +-
meson.build | 8 +
src/gallium/state_trackers/clover/Makefile.am | 30 +-
.../state_trackers/clover/Makefile.sources| 6 +-
.../state_trackers/clover/api/device.cpp | 18 +-
.../state_trackers/clover/api/dispatch.cpp| 29 +-
.../state_trackers/clover/api/dispatch.hpp| 194 +++
.../state_trackers/clover/api/platform.cpp| 6 +-
.../state_trackers/clover/api/program.cpp | 119 -
.../state_trackers/clover/core/device.cpp | 32 +-
.../state_trackers/clover/core/device.hpp | 2 +
.../state_trackers/clover/core/module.cpp | 1 +
.../state_trackers/clover/core/module.hpp | 13 +-
.../state_trackers/clover/core/platform.cpp | 5 +
.../state_trackers/clover/core/platform.hpp | 2 +
.../state_trackers/clover/core/program.cpp| 55 +-
.../state_trackers/clover/core/program.hpp| 12 +
.../clover/llvm/codegen/bitcode.cpp | 3 +-
.../clover/llvm/codegen/common.cpp| 2 +-
.../state_trackers/clover/llvm/invocation.cpp | 29 ++
.../state_trackers/clover/llvm/invocation.hpp | 6 +
src/gallium/state_trackers/clover/meson.build | 21 +-
.../clover/spirv/invocation.cpp | 138 +
.../clover/{tgsi => spirv}/invocation.hpp | 26 +-
.../state_trackers/clover/tgsi/compiler.cpp | 120 -
38 files changed, 2470 insertions(+), 399 deletions(-)
create mode 100644 include/CL/cl_dx9_media_sharing_intel.h
create mode 100644 include/CL/cl_ext_intel.h
create
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
Quoting Kenneth Graunke (2019-01-08 20:17:01) > On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote: > > Quoting Lionel Landwerlin (2019-01-08 11:03:26) > > > Hi Andrii, > > > > > > Although I think what these patches do makes sense, I think it's missing > > > the bigger picture. > > > There is a lot more state that gets lost if we have to revert all of the > > > emitted commands. > > > A quick look at brw_upload_pipeline_state() shows all of the programs > > > could be invalid as well, or the number of samples, etc... > > > > > > To me it seems like we need a much larger state save/restore. > > > > > > Ken: what do you think? > > > > How about not rolling back? If we accept it as currently broken, and just > > demand the kernel provide logical contexts for all i965 devices (just ack > > some patches!), and then just flush the batch (possibly with a dummy 3D > > prim if you want to be sure the 3D state is loaded) and rely on the > > context preserving state across batches. > > -Chris > > I'm not sure precisely what you're proposing, but every scenario I can > think of is breaking in some subtle way. > > Option 1: Submit batch at last 3DPRIMITIVE, re-call emit in a new batch. > > This is what we do today; it doesn't work since brw_upload_render_state > implicitly sets CPU-side fields for "current state of the GPU", which > become inaccurate at rollback, so the next state upload would do the > wrong thing. We'd need to roll all those back as well, or only commit > them when we finish uploading state. Atoms also flag other new atoms, > and that's not getting rolled back, but extra flagging is harmless. > > Fixing this means disentangling some of our code, saving and restoring > more values, and so on. Maybe dropping a few CPU micro-optimizations. > > Option 2: Submit batch at last 3DPRIMITIVE (A), memcpy commands for > for failing primitive (B) into a new batch. > > This doesn't work either. Let's say (A) issued a 3DSTATE_INDEX_BUFFER > command with a pointer to the index buffer. (B) didn't change index > buffer state, so it doesn't emit one, intending to reuse the old value. This with all relocs with BRW_NEW_BATCH, and iirc the rule is that they are already tied into that BRW_NEW_BATCH flag. Except you don't need to memcpy, since you already have the 3DSTATE equivalent to the cpu state tracker in the batch, emit that, and it will be recorded in the context for the next batch. (You just don't tell the kernel about the buffers/relocs that cause the aperture exhaustion and it won't do anything about them. The GPU may load stale addresses, but never uses them, exactly like the context state on the next batch anyway.) It's not a great argument, but the argument is that there's less you need to fixup, than having to remember to every single comparison in order to rollback the cpu state tracker. -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote: > Quoting Lionel Landwerlin (2019-01-08 11:03:26) > > Hi Andrii, > > > > Although I think what these patches do makes sense, I think it's missing > > the bigger picture. > > There is a lot more state that gets lost if we have to revert all of the > > emitted commands. > > A quick look at brw_upload_pipeline_state() shows all of the programs > > could be invalid as well, or the number of samples, etc... > > > > To me it seems like we need a much larger state save/restore. > > > > Ken: what do you think? > > How about not rolling back? If we accept it as currently broken, and just > demand the kernel provide logical contexts for all i965 devices (just ack > some patches!), and then just flush the batch (possibly with a dummy 3D > prim if you want to be sure the 3D state is loaded) and rely on the > context preserving state across batches. > -Chris I'm not sure precisely what you're proposing, but every scenario I can think of is breaking in some subtle way. Option 1: Submit batch at last 3DPRIMITIVE, re-call emit in a new batch. This is what we do today; it doesn't work since brw_upload_render_state implicitly sets CPU-side fields for "current state of the GPU", which become inaccurate at rollback, so the next state upload would do the wrong thing. We'd need to roll all those back as well, or only commit them when we finish uploading state. Atoms also flag other new atoms, and that's not getting rolled back, but extra flagging is harmless. Fixing this means disentangling some of our code, saving and restoring more values, and so on. Maybe dropping a few CPU micro-optimizations. Option 2: Submit batch at last 3DPRIMITIVE (A), memcpy commands for for failing primitive (B) into a new batch. This doesn't work either. Let's say (A) issued a 3DSTATE_INDEX_BUFFER command with a pointer to the index buffer. (B) didn't change index buffer state, so it doesn't emit one, intending to reuse the old value. The kernel will process the batch containing (A), and relocate the index buffer somewhere to some address. Context save will store that address. Context load will happen before executing (B)'s batch, and restore the old pointer. But batch (B) won't have any relocations for the index buffer pointer (because there's no command to patch up). So, we'd either need relocations to patch the GEM context image...or we'd have to softpin all inherited buffers. Maybe softpinning inherited buffers in an otherwise relocation-centric world is viable? Does softpin even exist on Gen4? This doesn't seem easy. Option 3: Submit batch as soon as we overflow aperture checks, with state for a primitive ending up in two batches. This is not viable either - has all the problems of option 2, but also means checking aperture everywhere...and our binding table upload code means essentially pulling in all surfaces as one big group, which is dodgy... signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: don't leak pipe_surface if pipe_context is not current
On Tue, Jan 8, 2019 at 12:54 PM Roland Scheidegger wrote: > Am 08.01.19 um 17:17 schrieb Marek Olšák: > > From: Marek Olšák > > > > We have found some pipe_surface leaks internally. > > > > This is the same code as surface_destroy in radeonsi. > > Ideally, surface_destroy would be in pipe_screen. > > No, pipe_surfaces are not context objects. > Well they are supposed to be... > But yes mesa/st doesn't play by the rules there, so I guess that's > better than a leak... > If it was possible, I would change the rules. create_surface could stay in pipe_context, but I would move surface_destroy into pipe_screen. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] nir: fix warning in nir_lower_io.c
ACK
On Tue, Jan 8, 2019 at 12:27 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Initialize the variable with NULL. Fixes the following
>
> In file included from ../src/compiler/nir/nir_lower_io.c:34:
> ../src/compiler/nir/nir_lower_io.c: In function
> ‘nir_lower_explicit_io’:
> ../src/compiler/nir/nir.h:668:11: warning: ‘addr’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> return src;
>^~~
> ../src/compiler/nir/nir_lower_io.c:735:17: note: ‘addr’ was declared
> here
> nir_ssa_def *addr;
> ^~~~
>
> v2: Avoid using a 'default' case so we get help from the compiler when
> new deref types are added. (Lionel)
> ---
> src/compiler/nir/nir_lower_io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_lower_io.c
> b/src/compiler/nir/nir_lower_io.c
> index bcbfebdfa3b..44af76de599 100644
> --- a/src/compiler/nir/nir_lower_io.c
> +++ b/src/compiler/nir/nir_lower_io.c
> @@ -732,7 +732,7 @@ lower_explicit_io_deref(nir_builder *b,
> nir_deref_instr *deref,
> assert(deref->parent.is_ssa);
> nir_ssa_def *parent_addr = deref->parent.ssa;
>
> - nir_ssa_def *addr;
> + nir_ssa_def *addr = NULL;
> assert(deref->dest.is_ssa);
> switch (deref->deref_type) {
> case nir_deref_type_var:
> --
> 2.20.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] gallium: add pipe_grid_info::partial_block
and add radeonsi support. This will be used by radeonsi internally.
Signed-off-by: Sonny Jiang
---
src/gallium/drivers/radeonsi/si_compute.c | 33 +++
src/gallium/include/pipe/p_state.h| 7 +
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index cbcd8e79c7b..69ffad45cd9 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -797,11 +797,6 @@ static void si_emit_dispatch_packets(struct si_context
*sctx,
radeon_set_sh_reg(cs, R_00B854_COMPUTE_RESOURCE_LIMITS,
compute_resource_limits);
- radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
- radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]));
- radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]));
- radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]));
-
unsigned dispatch_initiator =
S_00B800_COMPUTE_SHADER_EN(1) |
S_00B800_FORCE_START_AT_000(1) |
@@ -809,6 +804,34 @@ static void si_emit_dispatch_packets(struct si_context
*sctx,
* allow launching waves out-of-order. (same as Vulkan) */
S_00B800_ORDER_MODE(sctx->chip_class >= CIK);
+ bool partial_block_en = info->partial_block[0] ||
+ info->partial_block[1] ||
+ info->partial_block[2];
+
+ radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
+
+ if (partial_block_en) {
+ unsigned partial[3];
+
+ /* If no partial_block, these should be an entire block size,
not 0. */
+ partial[0] = info->partial_block[0] ? info->partial_block[0] :
info->block[0];
+ partial[1] = info->partial_block[1] ? info->partial_block[1] :
info->block[1];
+ partial[2] = info->partial_block[2] ? info->partial_block[2] :
info->block[2];
+
+ radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]) |
+ S_00B81C_NUM_THREAD_PARTIAL(partial[0]));
+ radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]) |
+ S_00B820_NUM_THREAD_PARTIAL(partial[1]));
+ radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]) |
+ S_00B824_NUM_THREAD_PARTIAL(partial[2]));
+
+ dispatch_initiator |= S_00B800_PARTIAL_TG_EN(1);
+ } else {
+ radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]));
+ radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]));
+ radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]));
+ }
+
if (info->indirect) {
uint64_t base_va = r600_resource(info->indirect)->gpu_address;
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 38052e5fd3d..56f5bdd4c85 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -838,6 +838,13 @@ struct pipe_grid_info
*/
uint block[3];
+ /**
+* Number of threads to add to the grid in X, Y, and Z directions for
+* compute dispatches that are not aligned to the block size.
+* The added threads will be launched as partial thread blocks.
+*/
+ uint partial_block[3];
+
/**
* Determine the layout of the grid (in block units) to be used.
*/
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/12] nir: add legal bit_sizes to intrinsics
On Tue, Jan 8, 2019 at 1:03 PM Karol Herbst wrote:
> On Mon, Jan 7, 2019 at 6:16 PM Jason Ekstrand
> wrote:
> >
> > On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> >>
> >> With OpenCL some system values match the address bits, but in GLSL we
> also
> >> have some system values being 64 bit like subgroup masks.
> >>
> >> With this it is possible to adjust the builder functions so that
> depending
> >> on the bit_sizes the correct bit_size is used or an additional argument
> is
> >> added in case of multiple possible values.
> >>
> >> v2: validate dest bit_size
> >>
> >> Signed-off-by: Karol Herbst
> >> ---
> >> src/compiler/nir/nir.h | 3 +++
> >> src/compiler/nir/nir_intrinsics.py | 25 +++--
> >> src/compiler/nir/nir_intrinsics_c.py | 6 +-
> >> src/compiler/nir/nir_validate.c | 6 ++
> >> 4 files changed, 29 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> >> index e9f8f15d387..c5ea8dcdd1e 100644
> >> --- a/src/compiler/nir/nir.h
> >> +++ b/src/compiler/nir/nir.h
> >> @@ -1297,6 +1297,9 @@ typedef struct {
> >>
> >> /** semantic flags for calls to this intrinsic */
> >> nir_intrinsic_semantic_flag flags;
> >> +
> >> + /** bitfield of legal bit sizes */
> >> + unsigned bit_sizes : 7;
> >
> >
> > This should be called dest_bit_sizes and be after dest_components. Also
> the bitfield :7 is really pointless given how many other things we have in
> this struct that are simply declared "unsigned". If we're going to make it
> a bitfield (probably a good idea anyway), we should do so across the board.
> >
> >>
> >> } nir_intrinsic_info;
> >>
> >> extern const nir_intrinsic_info
> nir_intrinsic_infos[nir_num_intrinsics];
> >> diff --git a/src/compiler/nir/nir_intrinsics.py
> b/src/compiler/nir/nir_intrinsics.py
> >> index 6ea6ad1198f..830c406b450 100644
> >> --- a/src/compiler/nir/nir_intrinsics.py
> >> +++ b/src/compiler/nir/nir_intrinsics.py
> >> @@ -32,7 +32,7 @@ class Intrinsic(object):
> >> NOTE: this must be kept in sync with nir_intrinsic_info.
> >> """
> >> def __init__(self, name, src_components, dest_components,
> >> -indices, flags, sysval):
> >> +indices, flags, sysval, bit_sizes):
> >> """Parameters:
> >>
> >> - name: the intrinsic name
> >> @@ -45,6 +45,7 @@ class Intrinsic(object):
> >> - indices: list of constant indicies
> >> - flags: list of semantic flags
> >> - sysval: is this a system-value intrinsic
> >> + - bit_sizes: allowed dest bit_sizes
> >> """
> >> assert isinstance(name, str)
> >> assert isinstance(src_components, list)
> >> @@ -58,6 +59,8 @@ class Intrinsic(object):
> >> if flags:
> >> assert isinstance(flags[0], str)
> >> assert isinstance(sysval, bool)
> >> + if bit_sizes:
> >> + assert isinstance(bit_sizes[0], int)
> >>
> >> self.name = name
> >> self.num_srcs = len(src_components)
> >> @@ -68,6 +71,7 @@ class Intrinsic(object):
> >> self.indices = indices
> >> self.flags = flags
> >> self.sysval = sysval
> >> + self.bit_sizes = bit_sizes
> >>
> >> #
> >> # Possible indices:
> >> @@ -123,10 +127,10 @@ CAN_REORDER = "NIR_INTRINSIC_CAN_REORDER"
> >> INTR_OPCODES = {}
> >>
> >> def intrinsic(name, src_comp=[], dest_comp=-1, indices=[],
> >> - flags=[], sysval=False):
> >> + flags=[], sysval=False, bit_sizes=[]):
> >> assert name not in INTR_OPCODES
> >> INTR_OPCODES[name] = Intrinsic(name, src_comp, dest_comp,
> >> - indices, flags, sysval)
> >> + indices, flags, sysval, bit_sizes)
> >>
> >> intrinsic("nop", flags=[CAN_ELIMINATE])
> >>
> >> @@ -448,9 +452,10 @@ intrinsic("shared_atomic_fmin", src_comp=[1, 1],
> dest_comp=1, indices=[BASE])
> >> intrinsic("shared_atomic_fmax", src_comp=[1, 1], dest_comp=1,
> indices=[BASE])
> >> intrinsic("shared_atomic_fcomp_swap", src_comp=[1, 1, 1], dest_comp=1,
> indices=[BASE])
> >>
> >> -def system_value(name, dest_comp, indices=[]):
> >> +def system_value(name, dest_comp, indices=[], bit_sizes=[32]):
> >> intrinsic("load_" + name, [], dest_comp, indices,
> >> - flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True)
> >> + flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True,
> >> + bit_sizes=bit_sizes)
> >>
> >> system_value("frag_coord", 4)
> >> system_value("front_face", 1)
> >> @@ -485,11 +490,11 @@ system_value("layer_id", 1)
> >> system_value("view_index", 1)
> >> system_value("subgroup_size", 1)
> >> system_value("subgroup_invocation", 1)
> >> -system_value("subgroup_eq_mask", 0)
> >> -system_value("subgroup_ge_mask", 0)
> >> -system_value("subgroup_gt_mask", 0)
> >> -system_value("subgroup_le_mask", 0)
> >> -system_value("subgroup_lt_mask", 0)
> >>
Re: [Mesa-dev] Chromium - Application-level nouveau blacklist
On Tue, Jan 8, 2019 at 1:11 AM Eero Tamminen wrote: > > Hi, > > On 8.1.2019 8.56, Stéphane Marchesin wrote: > > Yes I think the Chrome-side is very simple here: because there isn't > > time or means for in-depth investigation, if a driver crashes too > > much, it gets blacklisted. The situation is not unique, the GPU > > blacklist file is 1700 lines: > > https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json > > > > Anyway, IMO if the biggest crashers can be fixed, I think we could > > eventually make a case to reenable. > > Can Chrome crash tracking system provide following information: > * which www-page caused the crash > * upstream Mesa commit used > * upstream kernel commit used > * if crash is from ChromeOS > - what patches have been applied on top of kernel & Mesa Note that for Chrome OS, we handle the crashes ourselves already. But of course there is no nouveau-based chromebook so that wouldn't help with the issue at hand. > * if crash is from a Linux distro >- distro version and windowing system setup (X/Wayland, compositor) >- package versions for kernel, Mesa, display server and compositor > (to find what kernel & Mesa patches are applied) > * detailed HW information > * backtrace The problem with the backtrace is that Chrome doesn't have the symbols for the driver, so although we (internally, at Google) can get a backtrace, we still need to symbolize it somehow. > ? > > So that developers could try the corresponding combination? The Chrome team has a relationship with a lot of vendors on other OSes. If there is interest, I am sure we can work out something similar between the Chrome team and the nouveau devs, and I'd be happy to play middle man if needed. I think the main roadblock is about symbolizing the backtraces which we have. We can probably start with bugs that happen on "common" distros, for which it should be easy to get symbols. Stéphane > > > - Eero > ___ > 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 11/12] nir: add support for address bit sized system values
On Mon, Jan 7, 2019 at 6:29 PM Jason Ekstrand wrote: > > > On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote: >> >> Signed-off-by: Karol Herbst >> --- >> src/amd/vulkan/radv_meta_buffer.c | 8 ++-- >> src/amd/vulkan/radv_meta_bufimage.c| 28 +++--- >> src/amd/vulkan/radv_meta_clear.c | 4 +- >> src/amd/vulkan/radv_meta_fast_clear.c | 4 +- >> src/amd/vulkan/radv_meta_resolve_cs.c | 4 +- >> src/amd/vulkan/radv_query.c| 12 +++--- >> src/compiler/nir/nir_intrinsics.py | 12 +++--- >> src/compiler/nir/nir_lower_system_values.c | 43 +- >> 8 files changed, 61 insertions(+), 54 deletions(-) >> >> diff --git a/src/amd/vulkan/radv_meta_buffer.c >> b/src/amd/vulkan/radv_meta_buffer.c >> index 76854d7bbad..208988c3775 100644 >> --- a/src/amd/vulkan/radv_meta_buffer.c >> +++ b/src/amd/vulkan/radv_meta_buffer.c >> @@ -15,8 +15,8 @@ build_buffer_fill_shader(struct radv_device *dev) >> b.shader->info.cs.local_size[1] = 1; >> b.shader->info.cs.local_size[2] = 1; >> >> - nir_ssa_def *invoc_id = nir_load_local_invocation_id(); >> - nir_ssa_def *wg_id = nir_load_work_group_id(); >> + nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32); >> + nir_ssa_def *wg_id = nir_load_work_group_id(, 32); >> nir_ssa_def *block_size = nir_imm_ivec4(, >> >> b.shader->info.cs.local_size[0], >> >> b.shader->info.cs.local_size[1], >> @@ -67,8 +67,8 @@ build_buffer_copy_shader(struct radv_device *dev) >> b.shader->info.cs.local_size[1] = 1; >> b.shader->info.cs.local_size[2] = 1; >> >> - nir_ssa_def *invoc_id = nir_load_local_invocation_id(); >> - nir_ssa_def *wg_id = nir_load_work_group_id(); >> + nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32); >> + nir_ssa_def *wg_id = nir_load_work_group_id(, 32); >> nir_ssa_def *block_size = nir_imm_ivec4(, >> >> b.shader->info.cs.local_size[0], >> >> b.shader->info.cs.local_size[1], >> diff --git a/src/amd/vulkan/radv_meta_bufimage.c >> b/src/amd/vulkan/radv_meta_bufimage.c >> index 45df8438234..c8a733b3062 100644 >> --- a/src/amd/vulkan/radv_meta_bufimage.c >> +++ b/src/amd/vulkan/radv_meta_bufimage.c >> @@ -60,8 +60,8 @@ build_nir_itob_compute_shader(struct radv_device *dev, >> bool is_3d) >> output_img->data.descriptor_set = 0; >> output_img->data.binding = 1; >> >> - nir_ssa_def *invoc_id = nir_load_local_invocation_id(); >> - nir_ssa_def *wg_id = nir_load_work_group_id(); >> + nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32); >> + nir_ssa_def *wg_id = nir_load_work_group_id(, 32); >> nir_ssa_def *block_size = nir_imm_ivec4(, >> >> b.shader->info.cs.local_size[0], >> >> b.shader->info.cs.local_size[1], >> @@ -289,8 +289,8 @@ build_nir_btoi_compute_shader(struct radv_device *dev, >> bool is_3d) >> output_img->data.descriptor_set = 0; >> output_img->data.binding = 1; >> >> - nir_ssa_def *invoc_id = nir_load_local_invocation_id(); >> - nir_ssa_def *wg_id = nir_load_work_group_id(); >> + nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32); >> + nir_ssa_def *wg_id = nir_load_work_group_id(, 32); >> nir_ssa_def *block_size = nir_imm_ivec4(, >> >> b.shader->info.cs.local_size[0], >> >> b.shader->info.cs.local_size[1], >> @@ -511,8 +511,8 @@ build_nir_btoi_r32g32b32_compute_shader(struct >> radv_device *dev) >> output_img->data.descriptor_set = 0; >> output_img->data.binding = 1; >> >> - nir_ssa_def *invoc_id = nir_load_local_invocation_id(); >> - nir_ssa_def *wg_id = nir_load_work_group_id(); >> + nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32); >> + nir_ssa_def *wg_id = nir_load_work_group_id(, 32); >> nir_ssa_def *block_size = nir_imm_ivec4(, >> >> b.shader->info.cs.local_size[0], >> >> b.shader->info.cs.local_size[1], >> @@ -719,8 +719,8 @@ build_nir_itoi_compute_shader(struct radv_device *dev, >> bool is_3d) >> output_img->data.descriptor_set = 0; >> output_img->data.binding = 1; >> >> - nir_ssa_def *invoc_id = nir_load_local_invocation_id(); >> - nir_ssa_def *wg_id = nir_load_work_group_id(); >> + nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32); >> + nir_ssa_def *wg_id = nir_load_work_group_id(, 32); >> nir_ssa_def *block_size = nir_imm_ivec4(, >>
Re: [Mesa-dev] [PATCH 09/12] nir: add legal bit_sizes to intrinsics
On Mon, Jan 7, 2019 at 6:16 PM Jason Ekstrand wrote:
>
> On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
>>
>> With OpenCL some system values match the address bits, but in GLSL we also
>> have some system values being 64 bit like subgroup masks.
>>
>> With this it is possible to adjust the builder functions so that depending
>> on the bit_sizes the correct bit_size is used or an additional argument is
>> added in case of multiple possible values.
>>
>> v2: validate dest bit_size
>>
>> Signed-off-by: Karol Herbst
>> ---
>> src/compiler/nir/nir.h | 3 +++
>> src/compiler/nir/nir_intrinsics.py | 25 +++--
>> src/compiler/nir/nir_intrinsics_c.py | 6 +-
>> src/compiler/nir/nir_validate.c | 6 ++
>> 4 files changed, 29 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index e9f8f15d387..c5ea8dcdd1e 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -1297,6 +1297,9 @@ typedef struct {
>>
>> /** semantic flags for calls to this intrinsic */
>> nir_intrinsic_semantic_flag flags;
>> +
>> + /** bitfield of legal bit sizes */
>> + unsigned bit_sizes : 7;
>
>
> This should be called dest_bit_sizes and be after dest_components. Also the
> bitfield :7 is really pointless given how many other things we have in this
> struct that are simply declared "unsigned". If we're going to make it a
> bitfield (probably a good idea anyway), we should do so across the board.
>
>>
>> } nir_intrinsic_info;
>>
>> extern const nir_intrinsic_info nir_intrinsic_infos[nir_num_intrinsics];
>> diff --git a/src/compiler/nir/nir_intrinsics.py
>> b/src/compiler/nir/nir_intrinsics.py
>> index 6ea6ad1198f..830c406b450 100644
>> --- a/src/compiler/nir/nir_intrinsics.py
>> +++ b/src/compiler/nir/nir_intrinsics.py
>> @@ -32,7 +32,7 @@ class Intrinsic(object):
>> NOTE: this must be kept in sync with nir_intrinsic_info.
>> """
>> def __init__(self, name, src_components, dest_components,
>> -indices, flags, sysval):
>> +indices, flags, sysval, bit_sizes):
>> """Parameters:
>>
>> - name: the intrinsic name
>> @@ -45,6 +45,7 @@ class Intrinsic(object):
>> - indices: list of constant indicies
>> - flags: list of semantic flags
>> - sysval: is this a system-value intrinsic
>> + - bit_sizes: allowed dest bit_sizes
>> """
>> assert isinstance(name, str)
>> assert isinstance(src_components, list)
>> @@ -58,6 +59,8 @@ class Intrinsic(object):
>> if flags:
>> assert isinstance(flags[0], str)
>> assert isinstance(sysval, bool)
>> + if bit_sizes:
>> + assert isinstance(bit_sizes[0], int)
>>
>> self.name = name
>> self.num_srcs = len(src_components)
>> @@ -68,6 +71,7 @@ class Intrinsic(object):
>> self.indices = indices
>> self.flags = flags
>> self.sysval = sysval
>> + self.bit_sizes = bit_sizes
>>
>> #
>> # Possible indices:
>> @@ -123,10 +127,10 @@ CAN_REORDER = "NIR_INTRINSIC_CAN_REORDER"
>> INTR_OPCODES = {}
>>
>> def intrinsic(name, src_comp=[], dest_comp=-1, indices=[],
>> - flags=[], sysval=False):
>> + flags=[], sysval=False, bit_sizes=[]):
>> assert name not in INTR_OPCODES
>> INTR_OPCODES[name] = Intrinsic(name, src_comp, dest_comp,
>> - indices, flags, sysval)
>> + indices, flags, sysval, bit_sizes)
>>
>> intrinsic("nop", flags=[CAN_ELIMINATE])
>>
>> @@ -448,9 +452,10 @@ intrinsic("shared_atomic_fmin", src_comp=[1, 1],
>> dest_comp=1, indices=[BASE])
>> intrinsic("shared_atomic_fmax", src_comp=[1, 1], dest_comp=1,
>> indices=[BASE])
>> intrinsic("shared_atomic_fcomp_swap", src_comp=[1, 1, 1], dest_comp=1,
>> indices=[BASE])
>>
>> -def system_value(name, dest_comp, indices=[]):
>> +def system_value(name, dest_comp, indices=[], bit_sizes=[32]):
>> intrinsic("load_" + name, [], dest_comp, indices,
>> - flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True)
>> + flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True,
>> + bit_sizes=bit_sizes)
>>
>> system_value("frag_coord", 4)
>> system_value("front_face", 1)
>> @@ -485,11 +490,11 @@ system_value("layer_id", 1)
>> system_value("view_index", 1)
>> system_value("subgroup_size", 1)
>> system_value("subgroup_invocation", 1)
>> -system_value("subgroup_eq_mask", 0)
>> -system_value("subgroup_ge_mask", 0)
>> -system_value("subgroup_gt_mask", 0)
>> -system_value("subgroup_le_mask", 0)
>> -system_value("subgroup_lt_mask", 0)
>> +system_value("subgroup_eq_mask", 0, bit_sizes=[32, 64])
>> +system_value("subgroup_ge_mask", 0, bit_sizes=[32, 64])
>> +system_value("subgroup_gt_mask", 0, bit_sizes=[32, 64])
>> +system_value("subgroup_le_mask", 0, bit_sizes=[32, 64])
>> +system_value("subgroup_lt_mask", 0,
Re: [Mesa-dev] [PATCH] radv: get rid of bunch of KHR suffixes
On Tuesday, 2019-01-08 14:30:32 +0100, Samuel Pitoiset wrote:
> Signed-off-by: Samuel Pitoiset
Acked-by: Eric Engestrom
You've inspired me, I'll send the same for anv in a bit ;)
> ---
> src/amd/vulkan/radv_android.c| 18 +--
> src/amd/vulkan/radv_cmd_buffer.c | 4 +-
> src/amd/vulkan/radv_descriptor_set.c | 22 ++--
> src/amd/vulkan/radv_device.c | 176 +--
> src/amd/vulkan/radv_formats.c| 82 ++---
> src/amd/vulkan/radv_image.c | 8 +-
> src/amd/vulkan/radv_meta_bufimage.c | 2 +-
> src/amd/vulkan/radv_pass.c | 6 +-
> src/amd/vulkan/radv_pipeline.c | 6 +-
> src/amd/vulkan/radv_private.h| 4 +-
> 10 files changed, 164 insertions(+), 164 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_android.c b/src/amd/vulkan/radv_android.c
> index 1a4425f26a5..9613eabbe87 100644
> --- a/src/amd/vulkan/radv_android.c
> +++ b/src/amd/vulkan/radv_android.c
> @@ -111,7 +111,7 @@ radv_image_from_gralloc(VkDevice device_h,
> VkResult result;
>
> if (gralloc_info->handle->numFds != 1) {
> - return vk_errorf(device->instance,
> VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR,
> + return vk_errorf(device->instance,
> VK_ERROR_INVALID_EXTERNAL_HANDLE,
>"VkNativeBufferANDROID::handle::numFds is %d, "
>"expected 1", gralloc_info->handle->numFds);
> }
> @@ -126,7 +126,7 @@ radv_image_from_gralloc(VkDevice device_h,
>
> const VkImportMemoryFdInfoKHR import_info = {
> .sType = VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR,
> - .handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR,
> + .handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT,
> .fd = dup(dma_buf),
> };
>
> @@ -230,16 +230,16 @@ VkResult radv_GetSwapchainGrallocUsageANDROID(
>* dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
>*/
>
> - const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
> - .sType =
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
> + const VkPhysicalDeviceImageFormatInfo2 image_format_info = {
> + .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2,
> .format = format,
> .type = VK_IMAGE_TYPE_2D,
> .tiling = VK_IMAGE_TILING_OPTIMAL,
> .usage = imageUsage,
> };
>
> - VkImageFormatProperties2KHR image_format_props = {
> - .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR,
> + VkImageFormatProperties2 image_format_props = {
> + .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2,
> };
>
> /* Check that requested format and usage are supported. */
> @@ -303,7 +303,7 @@ radv_AcquireImageANDROID(
> semaphore_result = radv_ImportSemaphoreFdKHR(device,
>
> &(VkImportSemaphoreFdInfoKHR) {
>.sType =
> VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR,
> - .flags =
> VK_SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR,
> + .flags =
> VK_SEMAPHORE_IMPORT_TEMPORARY_BIT,
>.fd =
> semaphore_fd,
>.semaphore =
> semaphore,
> });
> @@ -314,7 +314,7 @@ radv_AcquireImageANDROID(
> fence_result = radv_ImportFenceFdKHR(device,
>&(VkImportFenceFdInfoKHR) {
>.sType =
> VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR,
> - .flags =
> VK_FENCE_IMPORT_TEMPORARY_BIT_KHR,
> + .flags =
> VK_FENCE_IMPORT_TEMPORARY_BIT,
>.fd = fence_fd,
>.fence = fence,
>});
> @@ -351,7 +351,7 @@ radv_QueueSignalReleaseImageANDROID(
> result =
> radv_GetSemaphoreFdKHR(radv_device_to_handle(queue->device),
> &(VkSemaphoreGetFdInfoKHR) {
> .sType =
> VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR,
> - .handleType =
> VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR,
> + .handleType =
> VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT,
> .semaphore =
[Mesa-dev] [PATCH v2] nir: fix warning in nir_lower_io.c
Initialize the variable with NULL. Fixes the following
In file included from ../src/compiler/nir/nir_lower_io.c:34:
../src/compiler/nir/nir_lower_io.c: In function ‘nir_lower_explicit_io’:
../src/compiler/nir/nir.h:668:11: warning: ‘addr’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
return src;
^~~
../src/compiler/nir/nir_lower_io.c:735:17: note: ‘addr’ was declared here
nir_ssa_def *addr;
^~~~
v2: Avoid using a 'default' case so we get help from the compiler when
new deref types are added. (Lionel)
---
src/compiler/nir/nir_lower_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index bcbfebdfa3b..44af76de599 100644
--- a/src/compiler/nir/nir_lower_io.c
+++ b/src/compiler/nir/nir_lower_io.c
@@ -732,7 +732,7 @@ lower_explicit_io_deref(nir_builder *b, nir_deref_instr
*deref,
assert(deref->parent.is_ssa);
nir_ssa_def *parent_addr = deref->parent.ssa;
- nir_ssa_def *addr;
+ nir_ssa_def *addr = NULL;
assert(deref->dest.is_ssa);
switch (deref->deref_type) {
case nir_deref_type_var:
--
2.20.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] 19.0 branchpoint on 2019/01/29
There are two things I'd like to land prior to the branch point (as an FYI): - Rafiel's code to stop using userptr for ANV state pools (!11) - VK_EXT_transform_feedback (!2) Both are pretty close at this point so I think it's feasible. --Jason On Tue, Jan 8, 2019 at 11:52 AM Dylan Baker wrote: > Just a reminder that the branchpoint for the 19.0 release and the first RC > will > happen on January 29th. I just wanted to give an extra long heads up since > many > of us are still recovering from a long holiday season ☺ > > Dylan > ___ > 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] [Bug 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #6 from Dmitry --- Saving the game is not important, I started the game first and realized that hangs in any battles. Problem new. 4.20.0-arch1-1 LLVM 7.0.1-1 I understand this is a problem with the RX460. On bug tracker has several reports about The Witcher 3. And even with my RX460 https://bugs.freedesktop.org/show_bug.cgi?id=101731 -- 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] st/mesa: don't leak pipe_surface if pipe_context is not current
Am 08.01.19 um 17:17 schrieb Marek Olšák:
> From: Marek Olšák
>
> We have found some pipe_surface leaks internally.
>
> This is the same code as surface_destroy in radeonsi.
> Ideally, surface_destroy would be in pipe_screen.
> No, pipe_surfaces are not context objects.
Well they are supposed to be...
But yes mesa/st doesn't play by the rules there, so I guess that's
better than a leak...
Roland
>
> Cc: 18.3 19.0
> ---
> src/gallium/auxiliary/util/u_inlines.h | 19 +++
> src/mesa/state_tracker/st_cb_fbo.c | 5 -
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_inlines.h
> b/src/gallium/auxiliary/util/u_inlines.h
> index b06fb111709..fa1e920b509 100644
> --- a/src/gallium/auxiliary/util/u_inlines.h
> +++ b/src/gallium/auxiliary/util/u_inlines.h
> @@ -147,20 +147,39 @@ pipe_resource_reference(struct pipe_resource **dst,
> struct pipe_resource *src)
>
> old_dst->screen->resource_destroy(old_dst->screen, old_dst);
> old_dst = next;
>} while (pipe_reference_described(_dst->reference, NULL,
> (debug_reference_descriptor)
> debug_describe_resource));
> }
> *dst = src;
> }
>
> +/**
> + * Same as pipe_surface_release, but used when pipe_context doesn't exist
> + * anymore.
> + */
> +static inline void
> +pipe_surface_release_no_context(struct pipe_surface **ptr)
> +{
> + struct pipe_surface *surf = *ptr;
> +
> + if (pipe_reference_described(>reference, NULL,
> +(debug_reference_descriptor)
> +debug_describe_surface)) {
> + /* trivially destroy pipe_surface */
> + pipe_resource_reference(>texture, NULL);
> + free(surf);
> + }
> + *ptr = NULL;
> +}
> +
> /**
> * Set *dst to \p src with proper reference counting.
> *
> * The caller must guarantee that \p src and *dst were created in
> * the same context (if they exist), and that this must be the current
> context.
> */
> static inline void
> pipe_sampler_view_reference(struct pipe_sampler_view **dst,
> struct pipe_sampler_view *src)
> {
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c
> b/src/mesa/state_tracker/st_cb_fbo.c
> index 8901a8680ef..8d099f7b0f9 100644
> --- a/src/mesa/state_tracker/st_cb_fbo.c
> +++ b/src/mesa/state_tracker/st_cb_fbo.c
> @@ -278,22 +278,25 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
> * gl_renderbuffer::Delete()
> */
> static void
> st_renderbuffer_delete(struct gl_context *ctx, struct gl_renderbuffer *rb)
> {
> struct st_renderbuffer *strb = st_renderbuffer(rb);
> if (ctx) {
>struct st_context *st = st_context(ctx);
>pipe_surface_release(st->pipe, >surface_srgb);
>pipe_surface_release(st->pipe, >surface_linear);
> - strb->surface = NULL;
> + } else {
> + pipe_surface_release_no_context(>surface_srgb);
> + pipe_surface_release_no_context(>surface_linear);
> }
> + strb->surface = NULL;
> pipe_resource_reference(>texture, NULL);
> free(strb->data);
> _mesa_delete_renderbuffer(ctx, rb);
> }
>
>
> /**
> * Called via ctx->Driver.NewRenderbuffer()
> */
> static struct gl_renderbuffer *
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] 19.0 branchpoint on 2019/01/29
Just a reminder that the branchpoint for the 19.0 release and the first RC will happen on January 29th. I just wanted to give an extra long heads up since many of us are still recovering from a long holiday season ☺ Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Remove tegra vdpau driver
Quoting Ilia Mirkin (2019-01-08 09:12:46)
> Reviewed-by: Ilia Mirkin
>
> Thanks!
>
> On Tue, Dec 18, 2018 at 5:41 PM Dylan Baker wrote:
> >
> > This has never functioned and probably wont ever function, due to the
> > way gallium media state trackers are architected and the tegra video
> > decoder is architected.
> >
> > Cc: Thierry Reding
> > Fixes: 1755f608f5201e0a23f00cc3ea1b01edd07eb6ef
> >("tegra: Initial support")
> > ---
> > src/gallium/targets/vdpau/Makefile.am | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/src/gallium/targets/vdpau/Makefile.am
> > b/src/gallium/targets/vdpau/Makefile.am
> > index cd05a024451..2742c7acd44 100644
> > --- a/src/gallium/targets/vdpau/Makefile.am
> > +++ b/src/gallium/targets/vdpau/Makefile.am
> > @@ -57,8 +57,6 @@ include
> > $(top_srcdir)/src/gallium/drivers/r300/Automake.inc
> > include $(top_srcdir)/src/gallium/drivers/r600/Automake.inc
> > include $(top_srcdir)/src/gallium/drivers/radeonsi/Automake.inc
> >
> > -include $(top_srcdir)/src/gallium/drivers/tegra/Automake.inc
> > -
> > if HAVE_GALLIUM_STATIC_TARGETS
> >
> > libvdpau_gallium_la_SOURCES += target.c
> > --
> > 2.20.0
> >
Thank you! I've gone ahead and pushed this.
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [MR] intel: Add support for split SEND instructions
We've had split send instructions in the hardware since Sky Lake but haven't bothered to wire them up yet. In order to get there, this MR adds a new SHADER_OPCODE_SEND opcode which does a generic send without all the special-casing in fs_generator. At the end, it switches us to sends for surface writes where it's especially convenient. In future, we can easily start using SENDs for more stuff or even possibly add some sort of optimization pass to do automatic splitting. For now, this just gets everything we need in place. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/70 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: fix warning in nir_lower_io.c
On 08/01/2019 17:33, Caio Marcelo de Oliveira Filho wrote:
Add unreachable case for invalid deref type. Fixes the warning below
In file included from ../src/compiler/nir/nir_lower_io.c:34:
../src/compiler/nir/nir_lower_io.c: In function ‘nir_lower_explicit_io’:
../src/compiler/nir/nir.h:668:11: warning: ‘addr’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
return src;
^~~
../src/compiler/nir/nir_lower_io.c:735:17: note: ‘addr’ was declared here
nir_ssa_def *addr;
^~~~
---
src/compiler/nir/nir_lower_io.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index bcbfebdfa3b..4a322da609e 100644
--- a/src/compiler/nir/nir_lower_io.c
+++ b/src/compiler/nir/nir_lower_io.c
@@ -783,6 +783,10 @@ lower_explicit_io_deref(nir_builder *b, nir_deref_instr
*deref,
/* Nothing to do here */
addr = parent_addr;
break;
+
+ default:
+ unreachable("Invalid deref type");
+ break;
Just a thought, but you could rather set the addr variable to NULL
before the switch so that if a new deref type is ever added, the
compiler can find all the places we need to update.
-
Lionel
}
nir_instr_remove(>instr);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: fix warning in nir_lower_io.c
Add unreachable case for invalid deref type. Fixes the warning below
In file included from ../src/compiler/nir/nir_lower_io.c:34:
../src/compiler/nir/nir_lower_io.c: In function ‘nir_lower_explicit_io’:
../src/compiler/nir/nir.h:668:11: warning: ‘addr’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
return src;
^~~
../src/compiler/nir/nir_lower_io.c:735:17: note: ‘addr’ was declared here
nir_ssa_def *addr;
^~~~
---
src/compiler/nir/nir_lower_io.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index bcbfebdfa3b..4a322da609e 100644
--- a/src/compiler/nir/nir_lower_io.c
+++ b/src/compiler/nir/nir_lower_io.c
@@ -783,6 +783,10 @@ lower_explicit_io_deref(nir_builder *b, nir_deref_instr
*deref,
/* Nothing to do here */
addr = parent_addr;
break;
+
+ default:
+ unreachable("Invalid deref type");
+ break;
}
nir_instr_remove(>instr);
--
2.20.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/mesa: unify window-system renderbuffer initialization
For both, Reviewed-by: Brian Paul
On 01/08/2019 08:57 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_eglimage.c | 11 +
> src/mesa/state_tracker/st_manager.c | 32 -
> src/mesa/state_tracker/st_manager.h | 6 +
> 3 files changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_eglimage.c
> b/src/mesa/state_tracker/st_cb_eglimage.c
> index d6b93c3dbe8..f79df5a38ca 100644
> --- a/src/mesa/state_tracker/st_cb_eglimage.c
> +++ b/src/mesa/state_tracker/st_cb_eglimage.c
> @@ -152,34 +152,25 @@ st_egl_image_target_renderbuffer_storage(struct
> gl_context *ctx,
> surf_tmpl.format = stimg.format;
> surf_tmpl.u.tex.level = stimg.level;
> surf_tmpl.u.tex.first_layer = stimg.layer;
> surf_tmpl.u.tex.last_layer = stimg.layer;
> ps = pipe->create_surface(pipe, stimg.texture, _tmpl);
> pipe_resource_reference(, NULL);
>
> if (!ps)
>return;
>
> - strb->Base.Width = ps->width;
> - strb->Base.Height = ps->height;
> strb->Base.Format = st_pipe_format_to_mesa_format(ps->format);
> strb->Base._BaseFormat = st_pipe_format_to_base_format(ps->format);
> strb->Base.InternalFormat = strb->Base._BaseFormat;
>
> - struct pipe_surface **psurf =
> - util_format_is_srgb(ps->format) ? >surface_srgb :
> - >surface_linear;
> -
> - pipe_surface_reference(psurf, ps);
> - strb->surface = *psurf;
> - pipe_resource_reference(>texture, ps->texture);
> -
> + st_set_ws_renderbuffer_surface(strb, ps);
> pipe_surface_reference(, NULL);
> }
> }
>
> static void
> st_bind_egl_image(struct gl_context *ctx,
> struct gl_texture_object *texObj,
> struct gl_texture_image *texImage,
> struct st_egl_image *stimg)
> {
> diff --git a/src/mesa/state_tracker/st_manager.c
> b/src/mesa/state_tracker/st_manager.c
> index 73729d74545..7a3d9777101 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -166,20 +166,40 @@ st_context_validate(struct st_context *st,
> st->dirty |= ST_NEW_FRAMEBUFFER;
> _mesa_resize_framebuffer(st->ctx, >Base,
> stread->Base.Width,
> stread->Base.Height);
> }
> st->read_stamp = stread->stamp;
> }
> }
>
>
> +void
> +st_set_ws_renderbuffer_surface(struct st_renderbuffer *strb,
> + struct pipe_surface *surf)
> +{
> + pipe_surface_reference(>surface_srgb, NULL);
> + pipe_surface_reference(>surface_linear, NULL);
> +
> + if (util_format_is_srgb(surf->format))
> + pipe_surface_reference(>surface_srgb, surf);
> + else
> + pipe_surface_reference(>surface_linear, surf);
> +
> + strb->surface = surf; /* just assign, don't ref */
> + pipe_resource_reference(>texture, surf->texture);
> +
> + strb->Base.Width = surf->width;
> + strb->Base.Height = surf->height;
> +}
> +
> +
> /**
>* Validate a framebuffer to make sure up-to-date pipe_textures are used.
>* The context is only used for creating pipe surfaces and for calling
>* _mesa_resize_framebuffer().
>* (That should probably be rethought, since those surfaces become
>* drawable state, not context state, and can be freed by another pipe
>* context).
>*/
> static void
> st_framebuffer_validate(struct st_framebuffer *stfb,
> @@ -227,35 +247,25 @@ st_framebuffer_validate(struct st_framebuffer *stfb,
> strb = st_renderbuffer(stfb->Base.Attachment[idx].Renderbuffer);
> assert(strb);
> if (strb->texture == textures[i]) {
>pipe_resource_reference([i], NULL);
>continue;
> }
>
> u_surface_default_template(_tmpl, textures[i]);
> ps = st->pipe->create_surface(st->pipe, textures[i], _tmpl);
> if (ps) {
> - struct pipe_surface **psurf =
> -util_format_is_srgb(ps->format) ? >surface_srgb :
> - >surface_linear;
> -
> - pipe_surface_reference(psurf, ps);
> - strb->surface = *psurf;
> - pipe_resource_reference(>texture, ps->texture);
> - /* ownership transfered */
> + st_set_ws_renderbuffer_surface(strb, ps);
>pipe_surface_reference(, NULL);
>
>changed = TRUE;
>
> - strb->Base.Width = strb->surface->width;
> - strb->Base.Height = strb->surface->height;
> -
>width = strb->Base.Width;
>height = strb->Base.Height;
> }
>
> pipe_resource_reference([i], NULL);
> }
>
> if (changed) {
> ++stfb->stamp;
> _mesa_resize_framebuffer(st->ctx, >Base, width, height);
> diff --git
Re: [Mesa-dev] [PATCH] st/mesa: don't leak pipe_surface if pipe_context is not current
LGTM. Reviewed-by: Brian Paul
On 01/08/2019 09:17 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> We have found some pipe_surface leaks internally.
>
> This is the same code as surface_destroy in radeonsi.
> Ideally, surface_destroy would be in pipe_screen.
> No, pipe_surfaces are not context objects.
>
> Cc: 18.3 19.0
> ---
> src/gallium/auxiliary/util/u_inlines.h | 19 +++
> src/mesa/state_tracker/st_cb_fbo.c | 5 -
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_inlines.h
> b/src/gallium/auxiliary/util/u_inlines.h
> index b06fb111709..fa1e920b509 100644
> --- a/src/gallium/auxiliary/util/u_inlines.h
> +++ b/src/gallium/auxiliary/util/u_inlines.h
> @@ -147,20 +147,39 @@ pipe_resource_reference(struct pipe_resource **dst,
> struct pipe_resource *src)
>
>old_dst->screen->resource_destroy(old_dst->screen, old_dst);
>old_dst = next;
> } while (pipe_reference_described(_dst->reference, NULL,
> (debug_reference_descriptor)
> debug_describe_resource));
> }
> *dst = src;
> }
>
> +/**
> + * Same as pipe_surface_release, but used when pipe_context doesn't exist
> + * anymore.
> + */
> +static inline void
> +pipe_surface_release_no_context(struct pipe_surface **ptr)
> +{
> + struct pipe_surface *surf = *ptr;
> +
> + if (pipe_reference_described(>reference, NULL,
> +(debug_reference_descriptor)
> +debug_describe_surface)) {
> + /* trivially destroy pipe_surface */
> + pipe_resource_reference(>texture, NULL);
> + free(surf);
> + }
> + *ptr = NULL;
> +}
> +
> /**
>* Set *dst to \p src with proper reference counting.
>*
>* The caller must guarantee that \p src and *dst were created in
>* the same context (if they exist), and that this must be the current
> context.
>*/
> static inline void
> pipe_sampler_view_reference(struct pipe_sampler_view **dst,
> struct pipe_sampler_view *src)
> {
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c
> b/src/mesa/state_tracker/st_cb_fbo.c
> index 8901a8680ef..8d099f7b0f9 100644
> --- a/src/mesa/state_tracker/st_cb_fbo.c
> +++ b/src/mesa/state_tracker/st_cb_fbo.c
> @@ -278,22 +278,25 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
>* gl_renderbuffer::Delete()
>*/
> static void
> st_renderbuffer_delete(struct gl_context *ctx, struct gl_renderbuffer *rb)
> {
> struct st_renderbuffer *strb = st_renderbuffer(rb);
> if (ctx) {
> struct st_context *st = st_context(ctx);
> pipe_surface_release(st->pipe, >surface_srgb);
> pipe_surface_release(st->pipe, >surface_linear);
> - strb->surface = NULL;
> + } else {
> + pipe_surface_release_no_context(>surface_srgb);
> + pipe_surface_release_no_context(>surface_linear);
> }
> + strb->surface = NULL;
> pipe_resource_reference(>texture, NULL);
> free(strb->data);
> _mesa_delete_renderbuffer(ctx, rb);
> }
>
>
> /**
>* Called via ctx->Driver.NewRenderbuffer()
>*/
> static struct gl_renderbuffer *
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109249] vkd3d test failures related to ordered/unordered comparisons in test_shader_instructions()
https://bugs.freedesktop.org/show_bug.cgi?id=109249 Jason Ekstrand changed: What|Removed |Added CC||i...@freedesktop.org --- Comment #2 from Jason Ekstrand --- +idr. There has been some discussion of this and some different patches on the mailing list for different approaches to solving the problem. This one gets a bit sticky because it's an area where GL is intentionally lax but Vulkan is supposedly more strict. It's also an area where breaking IEEE a little is extremely useful for optimization. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109249] vkd3d test failures related to ordered/unordered comparisons in test_shader_instructions()
https://bugs.freedesktop.org/show_bug.cgi?id=109249 Samuel Pitoiset changed: What|Removed |Added CC||samuel.pitoi...@gmail.com --- Comment #1 from Samuel Pitoiset --- One other solution is to set the exact bit when translating spirv to nir. -- You are receiving this mail because: 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] autotools: Remove tegra vdpau driver
Reviewed-by: Ilia Mirkin
Thanks!
On Tue, Dec 18, 2018 at 5:41 PM Dylan Baker wrote:
>
> This has never functioned and probably wont ever function, due to the
> way gallium media state trackers are architected and the tegra video
> decoder is architected.
>
> Cc: Thierry Reding
> Fixes: 1755f608f5201e0a23f00cc3ea1b01edd07eb6ef
>("tegra: Initial support")
> ---
> src/gallium/targets/vdpau/Makefile.am | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/src/gallium/targets/vdpau/Makefile.am
> b/src/gallium/targets/vdpau/Makefile.am
> index cd05a024451..2742c7acd44 100644
> --- a/src/gallium/targets/vdpau/Makefile.am
> +++ b/src/gallium/targets/vdpau/Makefile.am
> @@ -57,8 +57,6 @@ include $(top_srcdir)/src/gallium/drivers/r300/Automake.inc
> include $(top_srcdir)/src/gallium/drivers/r600/Automake.inc
> include $(top_srcdir)/src/gallium/drivers/radeonsi/Automake.inc
>
> -include $(top_srcdir)/src/gallium/drivers/tegra/Automake.inc
> -
> if HAVE_GALLIUM_STATIC_TARGETS
>
> libvdpau_gallium_la_SOURCES += target.c
> --
> 2.20.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] [Bug 109249] vkd3d test failures related to ordered/unordered comparisons in test_shader_instructions()
https://bugs.freedesktop.org/show_bug.cgi?id=109249
Bug ID: 109249
Summary: vkd3d test failures related to ordered/unordered
comparisons in test_shader_instructions()
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Vulkan/Common
Assignee: mesa-dev@lists.freedesktop.org
Reporter: joseph.ku...@gmail.com
CC: airl...@freedesktop.org, chadvers...@chromium.org,
dan...@fooishbar.org, ja...@jlekstrand.net
Radv and Anv are affected. Nir optimizations appear to flip ordered/unordered
comparisons. Removing ~inot optimization from
https://gitlab.freedesktop.org/mesa/mesa/blob/add5a2ec92f4b3f7ac8353e5986dc04186a7b6da/src/compiler/nir/nir_opt_algebraic.py#L160
fixes the vkd3d test failures.
See https://lists.freedesktop.org/archives/mesa-dev/2018-December/210780.html
for a related discussion.
The problem produces the following test failures on Anv:
d3d12:8258:31:if_return: Test failed: Got {0.e+00, 0.e+00,
0.e+00, 0.e+00}, expected {1.e+00, 0.e+00,
0.e+00, 0.e+00} at (0, 0).
d3d12:8258:41:if_return: Test failed: Got {1.e+00, 1.e+00,
1.e+00, 0.e+00}, expected {1.e+00, 1.e+00,
1.e+00, 1.e+00} at (0, 0).
d3d12:8258:48:if_return: Test failed: Got {0.e+00, 0.e+00,
0.e+00, 0.e+00}, expected {1.e+00, 1.e+00,
1.e+00, 1.e+00} at (0, 0).
and the following test failures on Radv:
d3d12:8258:31:if_return: Test failed: Got {0.e+00, 0.e+00,
0.e+00, 0.e+00}, expected {1.e+00, 0.e+00,
0.e+00, 0.e+00} at (0, 0).
d3d12:8258:34:if_return: Test failed: Got {1.e+00, 0.e+00,
0.e+00, 0.e+00}, expected {1.e+00, 1.e+00,
1.e+00, 0.e+00} at (0, 0).
d3d12:8258:37:if_return: Test failed: Got {1.e+00, 1.e+00,
0.e+00, 0.e+00}, expected {1.e+00, 1.e+00,
1.e+00, 0.e+00} at (0, 0).
d3d12:8258:41:if_return: Test failed: Got {1.e+00, 1.e+00,
1.e+00, 0.e+00}, expected {1.e+00, 1.e+00,
1.e+00, 1.e+00} at (0, 0).
d3d12:8258:48:if_return: Test failed: Got {0.e+00, 0.e+00,
0.e+00, 0.e+00}, expected {1.e+00, 1.e+00,
1.e+00, 1.e+00} at (0, 0).
--
You are receiving this mail because:
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] st/va: Return correct status from vlVaQuerySurfaceStatus
From: Indrajit Das
Date: Thu, 3 Jan 2019 14:36:33 +0530
Subject: [PATCH] st/va: Return correct status from vlVaQuerySurfaceStatus
This ensures that during encoding, applications can get
the correct status of the surface before submitting
more operations on the same.
Reviewed-by: Leo Liu
Signed-off-by: Indrajit Das
---
src/gallium/state_trackers/va/surface.c | 31 +
1 file changed, 31 insertions(+)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index cc26efe..e7ed64b 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -146,9 +146,40 @@ vlVaSyncSurface(VADriverContextP ctx, VASurfaceID
render_target)
VAStatus
vlVaQuerySurfaceStatus(VADriverContextP ctx, VASurfaceID render_target,
VASurfaceStatus *status)
{
+ vlVaDriver *drv;
+ vlVaSurface *surf;
+ vlVaContext *context;
+
if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
+ drv = VL_VA_DRIVER(ctx);
+ if (!drv)
+ return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+ mtx_lock(>mutex);
+
+ surf = handle_table_get(drv->htab, render_target);
+ if (!surf || !surf->buffer) {
+ mtx_unlock(>mutex);
+ return VA_STATUS_ERROR_INVALID_SURFACE;
+ }
+
+ context = handle_table_get(drv->htab, surf->ctx);
+ if (!context) {
+ mtx_unlock(>mutex);
+ return VA_STATUS_ERROR_INVALID_CONTEXT;
+ }
+
+ if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
+ if(surf->feedback == NULL)
+ *status=VASurfaceReady;
+ else
+ *status=VASurfaceRendering;
+ }
+
+ mtx_unlock(>mutex);
+
return VA_STATUS_SUCCESS;
}
--
2.17.1
-Original Message-
From: Liu, Leo
Sent: Friday, January 4, 2019 7:54 PM
To: Das, Indrajit-kumar ;
mesa-dev@lists.freedesktop.org
Subject: Re: st/va: Return correct status from vlVaQuerySurfaceStatus
Please add some commit messages. With that, the patch is
Reviewed-by: Leo Liu
On 1/3/19 5:20 AM, Das, Indrajit-kumar wrote:
> From: Indrajit Das
> Date: Thu, 3 Jan 2019 14:36:33 +0530
> Subject: [PATCH] st/va: Return correct status from vlVaQuerySurfaceStatus
>
> Signed-off-by: Indrajit Das
> ---
> src/gallium/state_trackers/va/surface.c | 31 +
> 1 file changed, 31 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> index cc26efe..e7ed64b 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -146,9 +146,40 @@ vlVaSyncSurface(VADriverContextP ctx, VASurfaceID
> render_target)
> VAStatus
> vlVaQuerySurfaceStatus(VADriverContextP ctx, VASurfaceID render_target,
> VASurfaceStatus *status)
> {
> + vlVaDriver *drv;
> + vlVaSurface *surf;
> + vlVaContext *context;
> +
> if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>
> + drv = VL_VA_DRIVER(ctx);
> + if (!drv)
> + return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> + mtx_lock(>mutex);
> +
> + surf = handle_table_get(drv->htab, render_target);
> + if (!surf || !surf->buffer) {
> + mtx_unlock(>mutex);
> + return VA_STATUS_ERROR_INVALID_SURFACE;
> + }
> +
> + context = handle_table_get(drv->htab, surf->ctx);
> + if (!context) {
> + mtx_unlock(>mutex);
> + return VA_STATUS_ERROR_INVALID_CONTEXT;
> + }
> +
> + if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
> + if(surf->feedback == NULL)
> + *status=VASurfaceReady;
> + else
> + *status=VASurfaceRendering;
> + }
> +
> + mtx_unlock(>mutex);
> +
> return VA_STATUS_SUCCESS;
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] anv: Implement VK_KHR_draw_indirect_count and VK_EXT_conditional_rendering
Awesome, thanks for the update :) On Tue, 2019-01-08 at 11:47 +0200, Danylo Piliaiev wrote: > Hi, Thanks! > > I finally got CI results with ALL relevant tests and my > implementation works on everything but Haswell. > So I'll fix whatever is wrong there (hope that's just something > small) and send the final version. > > There are still some tests for VK-GL-CTS which are not merged in > master e.g. > https://github.com/KhronosGroup/VK-GL-CTS/pull/136 and there are some > unpublished tests for VK_EXT_conditional_rendering from other devs > which I have no idea when will be merged. I don't think this will > prevent merging my patches but still I would be more confident if CI > have ALL tests. > > And yes, I also was quite slow with my patches. > > On 1/8/19 11:13 AM, Erik Faye-Lund wrote: > > On Wed, 2018-10-17 at 14:58 +0300, Danylo Piliaiev wrote: > > > This series implement VK_KHR_draw_indirect_count and > > > VK_EXT_conditional_rendering extensions. > > > They are implemented together because they are highly > > > interweaved. > > > > > > There are already tests in VK_CTS for VK_KHR_draw_indirect_count > > > and > > > I made a pull request with > > > the tests for VK_EXT_conditional_rendering ( > > > https://github.com/KhronosGroup/VK-GL-CTS/pull/131). > > > > > > VK_KHR_draw_indirect_count is implemented for gen7+. > > > VK_EXT_conditional_rendering is implemented for gen7.5+ because > > > it > > > requires MI_MATH to be > > > implemented correctly. > > > > > > Since part of the tests aren't in VK-GL-CTS master I'm not sure > > > how > > > to test the implementation > > > of VK_EXT_conditional_rendering with my tests on CI. Could anyone > > > help me with this? > > > > > > Also the one thing I'm uncertain of is described in the last > > > patch. > > > > > > Many thanks to Jason Ekstrand for the help with the extensions. > > > > > > > Hey, great work :) > > > > What's holding this series back? I'm very interested in this > > functionality due to my work on Zink... :) > > > > ___ > 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] autotools: Remove tegra vdpau driver
Quoting Dylan Baker (2018-12-18 14:39:59)
> This has never functioned and probably wont ever function, due to the
> way gallium media state trackers are architected and the tegra video
> decoder is architected.
>
> Cc: Thierry Reding
> Fixes: 1755f608f5201e0a23f00cc3ea1b01edd07eb6ef
>("tegra: Initial support")
> ---
> src/gallium/targets/vdpau/Makefile.am | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/src/gallium/targets/vdpau/Makefile.am
> b/src/gallium/targets/vdpau/Makefile.am
> index cd05a024451..2742c7acd44 100644
> --- a/src/gallium/targets/vdpau/Makefile.am
> +++ b/src/gallium/targets/vdpau/Makefile.am
> @@ -57,8 +57,6 @@ include $(top_srcdir)/src/gallium/drivers/r300/Automake.inc
> include $(top_srcdir)/src/gallium/drivers/r600/Automake.inc
> include $(top_srcdir)/src/gallium/drivers/radeonsi/Automake.inc
>
> -include $(top_srcdir)/src/gallium/drivers/tegra/Automake.inc
> -
> if HAVE_GALLIUM_STATIC_TARGETS
>
> libvdpau_gallium_la_SOURCES += target.c
> --
> 2.20.0
>
ping
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #5 from Samuel Pitoiset --- Where is the savegame? Also what kernel and llvm versions are you using? The ones provided by Arch Linux? I have just tried to reproduce GPU hangs on my side by playing around few minutes, no success. -- 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 1/2] i965: add missing rollback of URB requirements
On Tue, Jan 8, 2019 at 6:16 PM Chris Wilson
wrote:
> Quoting andrey simiklit (2019-01-08 16:00:45)
> > On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson
> wrote:
> >
> > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > Hi Andrii,
> > >
> > > Although I think what these patches do makes sense, I think it's
> missing
> > > the bigger picture.
> > > There is a lot more state that gets lost if we have to revert all
> of the
> > > emitted commands.
> > > A quick look at brw_upload_pipeline_state() shows all of the
> programs
> > > could be invalid as well, or the number of samples, etc...
> > >
> > > To me it seems like we need a much larger state save/restore.
> > >
> > > Ken: what do you think?
> >
> > How about not rolling back? If we accept it as currently broken, and
> just
> > demand the kernel provide logical contexts for all i965 devices
> (just ack
> > some patches!), and then just flush the batch (possibly with a dummy
> 3D
> > prim if you want to be sure the 3D state is loaded) and rely on the
> > context preserving state across batches.
> > -Chris
> >
> >
> > Could you please provide a link to the patches you talking about?
>
> I just need an ack for the kernel patches to enable context support.
>
> > At the moment as far as I understood the rollback system
> > helps to reduce quantity of the flush operations in some lucky cases.
> > When there isn't enough space for a batch aperture,
> > we will rollback the batch to the saved state,
> > when limit (means aperture_threshold) wasn't reached by it.
> >
> > pseudo code (simple variant, without error handling):
> >save batch state here;
> >do
> >{
> >add primitives to the batch;
> >if the batch size limit is exceeded
> >{
> >rollback to the saved batch state;
> >flush the batch;
> >}
> >else
> >{
> >break;
> >}
> >} while(true);
> >
> > Are you suggesting to flush the batch every time without waiting for a
> nearly
> > full filling of it?
> > Like this:
> >add primitives to batch;
> >flush batch;
>
> The suggestion was just thinking about if we detect that this primitive
> would exceed the aperture, instead of rolling back the batch to before
> the primitive, unroll the objects/relocs (so that we don't trigger
> ENOSPC from the kernel) but keep the 3DSTATE without the final PRIM and
> submit that.
>
> Basically it's all about removing no_batch_wrap.
>
> Quite icky. All it saves is having to track the incidental details like
> URB, but you still have to re-emit all the surface state (but that's
> already a given as it is stored alongside the batch). However, that's
> all you have to remember.
> -Chris
>
Thanks a lot for clarifications.
-Andrii
> ___
> 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] st/mesa: don't leak pipe_surface if pipe_context is not current
From: Marek Olšák
We have found some pipe_surface leaks internally.
This is the same code as surface_destroy in radeonsi.
Ideally, surface_destroy would be in pipe_screen.
No, pipe_surfaces are not context objects.
Cc: 18.3 19.0
---
src/gallium/auxiliary/util/u_inlines.h | 19 +++
src/mesa/state_tracker/st_cb_fbo.c | 5 -
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_inlines.h
b/src/gallium/auxiliary/util/u_inlines.h
index b06fb111709..fa1e920b509 100644
--- a/src/gallium/auxiliary/util/u_inlines.h
+++ b/src/gallium/auxiliary/util/u_inlines.h
@@ -147,20 +147,39 @@ pipe_resource_reference(struct pipe_resource **dst,
struct pipe_resource *src)
old_dst->screen->resource_destroy(old_dst->screen, old_dst);
old_dst = next;
} while (pipe_reference_described(_dst->reference, NULL,
(debug_reference_descriptor)
debug_describe_resource));
}
*dst = src;
}
+/**
+ * Same as pipe_surface_release, but used when pipe_context doesn't exist
+ * anymore.
+ */
+static inline void
+pipe_surface_release_no_context(struct pipe_surface **ptr)
+{
+ struct pipe_surface *surf = *ptr;
+
+ if (pipe_reference_described(>reference, NULL,
+(debug_reference_descriptor)
+debug_describe_surface)) {
+ /* trivially destroy pipe_surface */
+ pipe_resource_reference(>texture, NULL);
+ free(surf);
+ }
+ *ptr = NULL;
+}
+
/**
* Set *dst to \p src with proper reference counting.
*
* The caller must guarantee that \p src and *dst were created in
* the same context (if they exist), and that this must be the current context.
*/
static inline void
pipe_sampler_view_reference(struct pipe_sampler_view **dst,
struct pipe_sampler_view *src)
{
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 8901a8680ef..8d099f7b0f9 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -278,22 +278,25 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
* gl_renderbuffer::Delete()
*/
static void
st_renderbuffer_delete(struct gl_context *ctx, struct gl_renderbuffer *rb)
{
struct st_renderbuffer *strb = st_renderbuffer(rb);
if (ctx) {
struct st_context *st = st_context(ctx);
pipe_surface_release(st->pipe, >surface_srgb);
pipe_surface_release(st->pipe, >surface_linear);
- strb->surface = NULL;
+ } else {
+ pipe_surface_release_no_context(>surface_srgb);
+ pipe_surface_release_no_context(>surface_linear);
}
+ strb->surface = NULL;
pipe_resource_reference(>texture, NULL);
free(strb->data);
_mesa_delete_renderbuffer(ctx, rb);
}
/**
* Called via ctx->Driver.NewRenderbuffer()
*/
static struct gl_renderbuffer *
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
Quoting andrey simiklit (2019-01-08 16:00:45)
> On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
> > There is a lot more state that gets lost if we have to revert all of the
> > emitted commands.
> > A quick look at brw_upload_pipeline_state() shows all of the programs
> > could be invalid as well, or the number of samples, etc...
> >
> > To me it seems like we need a much larger state save/restore.
> >
> > Ken: what do you think?
>
> How about not rolling back? If we accept it as currently broken, and just
> demand the kernel provide logical contexts for all i965 devices (just ack
> some patches!), and then just flush the batch (possibly with a dummy 3D
> prim if you want to be sure the 3D state is loaded) and rely on the
> context preserving state across batches.
> -Chris
>
>
> Could you please provide a link to the patches you talking about?
I just need an ack for the kernel patches to enable context support.
> At the moment as far as I understood the rollback system
> helps to reduce quantity of the flush operations in some lucky cases.
> When there isn't enough space for a batch aperture,
> we will rollback the batch to the saved state,
> when limit (means aperture_threshold) wasn't reached by it.
>
> pseudo code (simple variant, without error handling):
> save batch state here;
> do
> {
> add primitives to the batch;
> if the batch size limit is exceeded
> {
> rollback to the saved batch state;
> flush the batch;
> }
> else
> {
> break;
> }
> } while(true);
>
> Are you suggesting to flush the batch every time without waiting for a nearly
> full filling of it?
> Like this:
> add primitives to batch;
> flush batch;
The suggestion was just thinking about if we detect that this primitive
would exceed the aperture, instead of rolling back the batch to before
the primitive, unroll the objects/relocs (so that we don't trigger
ENOSPC from the kernel) but keep the 3DSTATE without the final PRIM and
submit that.
Basically it's all about removing no_batch_wrap.
Quite icky. All it saves is having to track the incidental details like
URB, but you still have to re-emit all the surface state (but that's
already a given as it is stored alongside the batch). However, that's
all you have to remember.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] radv: add support for VK_EXT_memory_budget
Thanks! I've played around with this a bit and it looks like it's behaving
how I'd expect.
One comment inline below...
On Tue, 8 Jan 2019 at 15:17, Samuel Pitoiset
wrote:
> A simple Vulkan extension that allows apps to query size and
> usage of all exposed memory heaps.
>
> The different usage values are not really accurate because
> they are per drm-fd, but they should be close enough.
>
> v2: - add software counters for the different heaps in the winsys
> - improve budget/usage computations based on these counters
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_device.c | 72 +++
> src/amd/vulkan/radv_extensions.py | 1 +
> src/amd/vulkan/radv_radeon_winsys.h | 4 ++
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 29 +++-
> .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 6 ++
> .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 4 ++
> 6 files changed, 115 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index d1e47133d1f..f79d54296b4 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1350,12 +1350,84 @@ void radv_GetPhysicalDeviceMemoryProperties(
> *pMemoryProperties = physical_device->memory_properties;
> }
>
> +static void
> +radv_get_memory_budget_properties(VkPhysicalDevice physicalDevice,
> +
> VkPhysicalDeviceMemoryBudgetPropertiesEXT *memoryBudget)
> +{
> + RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
> + VkPhysicalDeviceMemoryProperties *memory_properties =
> >memory_properties;
> + uint64_t visible_vram_size = radv_get_visible_vram_size(device);
> + uint64_t vram_size = radv_get_vram_size(device);
> + uint64_t gtt_size = device->rad_info.gart_size;
> + uint64_t heap_budget, heap_usage;
> +
> + /* For all memory heaps, the computation of budget is as follow:
> +* heap_budget = heap_size - global_heap_usage +
> app_heap_usage
> +*
> +* The Vulkan spec 1.1.97 says that the budget should include any
> +* currently allocated device memory.
> +*
> +* Note that the application heap usages are not really accurate
> (eg.
> +* in presence of shared buffers).
> +*/
> + if (vram_size) {
> + heap_usage = device->ws->query_value(device->ws,
> +
> RADEON_ALLOCATED_VRAM);
> +
> + heap_budget = vram_size -
> + device->ws->query_value(device->ws,
> RADEON_VRAM_USAGE) +
> + heap_usage;
> +
> + memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
> + memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
> + }
> +
> + if (visible_vram_size) {
> + heap_usage = device->ws->query_value(device->ws,
> +
> RADEON_ALLOCATED_VRAM_VIS);
> +
> + heap_budget = visible_vram_size -
> + device->ws->query_value(device->ws,
> RADEON_VRAM_VIS_USAGE) +
> + heap_usage;
> +
> + memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
> heap_budget;
> + memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
> heap_usage;
> + }
> +
> + if (gtt_size) {
> + heap_usage = device->ws->query_value(device->ws,
> +RADEON_ALLOCATED_GTT);
> +
> + heap_budget = gtt_size -
> + device->ws->query_value(device->ws,
> RADEON_GTT_USAGE) +
> + heap_usage;
> +
> + memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
> + memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
> + }
> +
> + /* The heapBudget and heapUsage values must be zero for array
> elements
> +* greater than or equal to
> +* VkPhysicalDeviceMemoryProperties::memoryHeapCount.
> +*/
> + for (uint32_t i = memory_properties->memoryHeapCount; i <
> VK_MAX_MEMORY_HEAPS; i++) {
> + memoryBudget->heapBudget[i] = 0;
> + memoryBudget->heapUsage[i] = 0;
> + }
> +}
> +
> void radv_GetPhysicalDeviceMemoryProperties2(
> VkPhysicalDevicephysicalDevice,
> VkPhysicalDeviceMemoryProperties2KHR *pMemoryProperties)
> {
> radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
>
> >memoryProperties);
> +
> + VkPhysicalDeviceMemoryBudgetPropertiesEXT *memory_budget =
> + vk_find_struct(pMemoryProperties->pNext,
> +
> PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT);
> + if (memory_budget)
> + radv_get_memory_budget_properties(physicalDevice,
> memory_budget);
> }
>
> VkResult radv_GetMemoryHostPointerPropertiesEXT(
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson
wrote:
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
> > There is a lot more state that gets lost if we have to revert all of the
> > emitted commands.
> > A quick look at brw_upload_pipeline_state() shows all of the programs
> > could be invalid as well, or the number of samples, etc...
> >
> > To me it seems like we need a much larger state save/restore.
> >
> > Ken: what do you think?
>
> How about not rolling back? If we accept it as currently broken, and just
> demand the kernel provide logical contexts for all i965 devices (just ack
> some patches!), and then just flush the batch (possibly with a dummy 3D
> prim if you want to be sure the 3D state is loaded) and rely on the
> context preserving state across batches.
> -Chris
>
Could you please provide a link to the patches you talking about?
At the moment as far as I understood the rollback system
helps to reduce quantity of the flush operations in some lucky cases.
When there isn't enough space for a batch aperture,
we will rollback the batch to the saved state,
when limit (means aperture_threshold) wasn't reached by it.
pseudo code (simple variant, without error handling):
save batch state here;
do
{
add primitives to the batch;
if the batch size limit is exceeded
{
rollback to the saved batch state;
flush the batch;
}
else
{
break;
}
} while(true);
Are you suggesting to flush the batch every time without waiting for a
nearly full filling of it?
Like this:
add primitives to batch;
flush batch;
Please correct me if I am wrong.
-Andrii
> ___
> 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 2/2] st/mesa: don't reference pipe_surface locally in PBO code
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_texture.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 45918e425ac..ff4694da9e0 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1236,25 +1236,23 @@ try_pbo_upload_common(struct gl_context *ctx,
pipe_sampler_view_reference(_view, NULL);
}
/* Framebuffer_state */
{
struct pipe_framebuffer_state fb;
memset(, 0, sizeof(fb));
fb.width = surface->width;
fb.height = surface->height;
fb.nr_cbufs = 1;
- pipe_surface_reference([0], surface);
+ fb.cbufs[0] = surface;
cso_set_framebuffer(cso, );
-
- pipe_surface_reference([0], NULL);
}
cso_set_viewport_dims(cso, surface->width, surface->height, FALSE);
/* Blend state */
cso_set_blend(cso, >pbo.upload_blend);
/* Depth/stencil/alpha state */
{
struct pipe_depth_stencil_alpha_state dsa;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/mesa: unify window-system renderbuffer initialization
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_eglimage.c | 11 +
src/mesa/state_tracker/st_manager.c | 32 -
src/mesa/state_tracker/st_manager.h | 6 +
3 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_eglimage.c
b/src/mesa/state_tracker/st_cb_eglimage.c
index d6b93c3dbe8..f79df5a38ca 100644
--- a/src/mesa/state_tracker/st_cb_eglimage.c
+++ b/src/mesa/state_tracker/st_cb_eglimage.c
@@ -152,34 +152,25 @@ st_egl_image_target_renderbuffer_storage(struct
gl_context *ctx,
surf_tmpl.format = stimg.format;
surf_tmpl.u.tex.level = stimg.level;
surf_tmpl.u.tex.first_layer = stimg.layer;
surf_tmpl.u.tex.last_layer = stimg.layer;
ps = pipe->create_surface(pipe, stimg.texture, _tmpl);
pipe_resource_reference(, NULL);
if (!ps)
return;
- strb->Base.Width = ps->width;
- strb->Base.Height = ps->height;
strb->Base.Format = st_pipe_format_to_mesa_format(ps->format);
strb->Base._BaseFormat = st_pipe_format_to_base_format(ps->format);
strb->Base.InternalFormat = strb->Base._BaseFormat;
- struct pipe_surface **psurf =
- util_format_is_srgb(ps->format) ? >surface_srgb :
- >surface_linear;
-
- pipe_surface_reference(psurf, ps);
- strb->surface = *psurf;
- pipe_resource_reference(>texture, ps->texture);
-
+ st_set_ws_renderbuffer_surface(strb, ps);
pipe_surface_reference(, NULL);
}
}
static void
st_bind_egl_image(struct gl_context *ctx,
struct gl_texture_object *texObj,
struct gl_texture_image *texImage,
struct st_egl_image *stimg)
{
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 73729d74545..7a3d9777101 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -166,20 +166,40 @@ st_context_validate(struct st_context *st,
st->dirty |= ST_NEW_FRAMEBUFFER;
_mesa_resize_framebuffer(st->ctx, >Base,
stread->Base.Width,
stread->Base.Height);
}
st->read_stamp = stread->stamp;
}
}
+void
+st_set_ws_renderbuffer_surface(struct st_renderbuffer *strb,
+ struct pipe_surface *surf)
+{
+ pipe_surface_reference(>surface_srgb, NULL);
+ pipe_surface_reference(>surface_linear, NULL);
+
+ if (util_format_is_srgb(surf->format))
+ pipe_surface_reference(>surface_srgb, surf);
+ else
+ pipe_surface_reference(>surface_linear, surf);
+
+ strb->surface = surf; /* just assign, don't ref */
+ pipe_resource_reference(>texture, surf->texture);
+
+ strb->Base.Width = surf->width;
+ strb->Base.Height = surf->height;
+}
+
+
/**
* Validate a framebuffer to make sure up-to-date pipe_textures are used.
* The context is only used for creating pipe surfaces and for calling
* _mesa_resize_framebuffer().
* (That should probably be rethought, since those surfaces become
* drawable state, not context state, and can be freed by another pipe
* context).
*/
static void
st_framebuffer_validate(struct st_framebuffer *stfb,
@@ -227,35 +247,25 @@ st_framebuffer_validate(struct st_framebuffer *stfb,
strb = st_renderbuffer(stfb->Base.Attachment[idx].Renderbuffer);
assert(strb);
if (strb->texture == textures[i]) {
pipe_resource_reference([i], NULL);
continue;
}
u_surface_default_template(_tmpl, textures[i]);
ps = st->pipe->create_surface(st->pipe, textures[i], _tmpl);
if (ps) {
- struct pipe_surface **psurf =
-util_format_is_srgb(ps->format) ? >surface_srgb :
- >surface_linear;
-
- pipe_surface_reference(psurf, ps);
- strb->surface = *psurf;
- pipe_resource_reference(>texture, ps->texture);
- /* ownership transfered */
+ st_set_ws_renderbuffer_surface(strb, ps);
pipe_surface_reference(, NULL);
changed = TRUE;
- strb->Base.Width = strb->surface->width;
- strb->Base.Height = strb->surface->height;
-
width = strb->Base.Width;
height = strb->Base.Height;
}
pipe_resource_reference([i], NULL);
}
if (changed) {
++stfb->stamp;
_mesa_resize_framebuffer(st->ctx, >Base, width, height);
diff --git a/src/mesa/state_tracker/st_manager.h
b/src/mesa/state_tracker/st_manager.h
index 162dcc2ca57..581e858229b 100644
--- a/src/mesa/state_tracker/st_manager.h
+++ b/src/mesa/state_tracker/st_manager.h
@@ -28,20 +28,22 @@
#ifndef ST_MANAGER_H
#define ST_MANAGER_H
#include "main/menums.h"
#include "pipe/p_compiler.h"
struct st_context;
struct st_framebuffer;
struct st_framebuffer_interface;
+struct
[Mesa-dev] [Bug 109153] [KBL-G][VK] Vulkan CTS spirv_assembly cases failed Segmentation fault (core dumped)
https://bugs.freedesktop.org/show_bug.cgi?id=109153 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #7 from Samuel Pitoiset --- This is actually a test bug. It doesn't check that variablePointers is enabled. I reported the problem to Khronos, should be fixed and upstreamed soon. -- 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 v2 3/3] radv: add support for VK_EXT_memory_budget
A simple Vulkan extension that allows apps to query size and
usage of all exposed memory heaps.
The different usage values are not really accurate because
they are per drm-fd, but they should be close enough.
v2: - add software counters for the different heaps in the winsys
- improve budget/usage computations based on these counters
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 72 +++
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_radeon_winsys.h | 4 ++
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 29 +++-
.../vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 6 ++
.../vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 4 ++
6 files changed, 115 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index d1e47133d1f..f79d54296b4 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1350,12 +1350,84 @@ void radv_GetPhysicalDeviceMemoryProperties(
*pMemoryProperties = physical_device->memory_properties;
}
+static void
+radv_get_memory_budget_properties(VkPhysicalDevice physicalDevice,
+ VkPhysicalDeviceMemoryBudgetPropertiesEXT
*memoryBudget)
+{
+ RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
+ VkPhysicalDeviceMemoryProperties *memory_properties =
>memory_properties;
+ uint64_t visible_vram_size = radv_get_visible_vram_size(device);
+ uint64_t vram_size = radv_get_vram_size(device);
+ uint64_t gtt_size = device->rad_info.gart_size;
+ uint64_t heap_budget, heap_usage;
+
+ /* For all memory heaps, the computation of budget is as follow:
+* heap_budget = heap_size - global_heap_usage + app_heap_usage
+*
+* The Vulkan spec 1.1.97 says that the budget should include any
+* currently allocated device memory.
+*
+* Note that the application heap usages are not really accurate (eg.
+* in presence of shared buffers).
+*/
+ if (vram_size) {
+ heap_usage = device->ws->query_value(device->ws,
+RADEON_ALLOCATED_VRAM);
+
+ heap_budget = vram_size -
+ device->ws->query_value(device->ws, RADEON_VRAM_USAGE) +
+ heap_usage;
+
+ memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
+ memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
+ }
+
+ if (visible_vram_size) {
+ heap_usage = device->ws->query_value(device->ws,
+RADEON_ALLOCATED_VRAM_VIS);
+
+ heap_budget = visible_vram_size -
+ device->ws->query_value(device->ws,
RADEON_VRAM_VIS_USAGE) +
+ heap_usage;
+
+ memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
heap_budget;
+ memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
heap_usage;
+ }
+
+ if (gtt_size) {
+ heap_usage = device->ws->query_value(device->ws,
+RADEON_ALLOCATED_GTT);
+
+ heap_budget = gtt_size -
+ device->ws->query_value(device->ws, RADEON_GTT_USAGE) +
+ heap_usage;
+
+ memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
+ memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
+ }
+
+ /* The heapBudget and heapUsage values must be zero for array elements
+* greater than or equal to
+* VkPhysicalDeviceMemoryProperties::memoryHeapCount.
+*/
+ for (uint32_t i = memory_properties->memoryHeapCount; i <
VK_MAX_MEMORY_HEAPS; i++) {
+ memoryBudget->heapBudget[i] = 0;
+ memoryBudget->heapUsage[i] = 0;
+ }
+}
+
void radv_GetPhysicalDeviceMemoryProperties2(
VkPhysicalDevicephysicalDevice,
VkPhysicalDeviceMemoryProperties2KHR *pMemoryProperties)
{
radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
>memoryProperties);
+
+ VkPhysicalDeviceMemoryBudgetPropertiesEXT *memory_budget =
+ vk_find_struct(pMemoryProperties->pNext,
+ PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT);
+ if (memory_budget)
+ radv_get_memory_budget_properties(physicalDevice,
memory_budget);
}
VkResult radv_GetMemoryHostPointerPropertiesEXT(
diff --git a/src/amd/vulkan/radv_extensions.py
b/src/amd/vulkan/radv_extensions.py
index 9952bb9c1c6..491ed9d94c3 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -105,6 +105,7 @@ EXTENSIONS = [
Extension('VK_EXT_external_memory_dma_buf', 1, True),
[Mesa-dev] [PATCH] radv: enable variable pointers
The Vulkan spec 1.1.97 says:
"variablePointers specifies whether the implementation supports
the SPIR-V VariablePointers capability. When this feature is
not enabled, shader modules must not declare the
VariablePointers capability."
As the SPIR-V feature is enabled, we should turn on the
extension feature as well.
All dEQP-VK.spirv_assembly.instruction.compute.variable_pointers.*
pass with the khronos internal repo. Note that a bunch of them
fails with the public repo, but it's expected as they violate the
specification.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index a1199c614f7..a36a0ba1d99 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -762,7 +762,7 @@ void radv_GetPhysicalDeviceFeatures2(
case
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR: {
VkPhysicalDeviceVariablePointerFeaturesKHR *features =
(void *)ext;
features->variablePointersStorageBuffer = true;
- features->variablePointers = false;
+ features->variablePointers = true;
break;
}
case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR: {
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #4 from Dmitry --- Any heavy scene, for example fight with the first Griffin on a plot. https://www.youtube.com/watch?v=0J9qnKeID0s Yes I can. It hangs in the fight. dmesg is not done because I do a physical reboot. -- 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: get rid of bunch of KHR suffixes
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_android.c| 18 +--
src/amd/vulkan/radv_cmd_buffer.c | 4 +-
src/amd/vulkan/radv_descriptor_set.c | 22 ++--
src/amd/vulkan/radv_device.c | 176 +--
src/amd/vulkan/radv_formats.c| 82 ++---
src/amd/vulkan/radv_image.c | 8 +-
src/amd/vulkan/radv_meta_bufimage.c | 2 +-
src/amd/vulkan/radv_pass.c | 6 +-
src/amd/vulkan/radv_pipeline.c | 6 +-
src/amd/vulkan/radv_private.h| 4 +-
10 files changed, 164 insertions(+), 164 deletions(-)
diff --git a/src/amd/vulkan/radv_android.c b/src/amd/vulkan/radv_android.c
index 1a4425f26a5..9613eabbe87 100644
--- a/src/amd/vulkan/radv_android.c
+++ b/src/amd/vulkan/radv_android.c
@@ -111,7 +111,7 @@ radv_image_from_gralloc(VkDevice device_h,
VkResult result;
if (gralloc_info->handle->numFds != 1) {
- return vk_errorf(device->instance,
VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR,
+ return vk_errorf(device->instance,
VK_ERROR_INVALID_EXTERNAL_HANDLE,
"VkNativeBufferANDROID::handle::numFds is %d, "
"expected 1", gralloc_info->handle->numFds);
}
@@ -126,7 +126,7 @@ radv_image_from_gralloc(VkDevice device_h,
const VkImportMemoryFdInfoKHR import_info = {
.sType = VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR,
- .handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR,
+ .handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT,
.fd = dup(dma_buf),
};
@@ -230,16 +230,16 @@ VkResult radv_GetSwapchainGrallocUsageANDROID(
* dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
*/
- const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
- .sType =
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
+ const VkPhysicalDeviceImageFormatInfo2 image_format_info = {
+ .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2,
.format = format,
.type = VK_IMAGE_TYPE_2D,
.tiling = VK_IMAGE_TILING_OPTIMAL,
.usage = imageUsage,
};
- VkImageFormatProperties2KHR image_format_props = {
- .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR,
+ VkImageFormatProperties2 image_format_props = {
+ .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2,
};
/* Check that requested format and usage are supported. */
@@ -303,7 +303,7 @@ radv_AcquireImageANDROID(
semaphore_result = radv_ImportSemaphoreFdKHR(device,
&(VkImportSemaphoreFdInfoKHR) {
.sType =
VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR,
-.flags =
VK_SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR,
+.flags =
VK_SEMAPHORE_IMPORT_TEMPORARY_BIT,
.fd =
semaphore_fd,
.semaphore =
semaphore,
});
@@ -314,7 +314,7 @@ radv_AcquireImageANDROID(
fence_result = radv_ImportFenceFdKHR(device,
&(VkImportFenceFdInfoKHR) {
.sType =
VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR,
-.flags =
VK_FENCE_IMPORT_TEMPORARY_BIT_KHR,
+.flags =
VK_FENCE_IMPORT_TEMPORARY_BIT,
.fd = fence_fd,
.fence = fence,
});
@@ -351,7 +351,7 @@ radv_QueueSignalReleaseImageANDROID(
result =
radv_GetSemaphoreFdKHR(radv_device_to_handle(queue->device),
&(VkSemaphoreGetFdInfoKHR) {
.sType =
VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR,
- .handleType =
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR,
+ .handleType =
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT,
.semaphore =
pWaitSemaphores[i],
}, _fd);
if (result != VK_SUCCESS) {
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index d1b8b3dee6a..4382062c411 100644
---
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
On 08/01/2019 11:11, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-01-08 11:03:26) Hi Andrii, Although I think what these patches do makes sense, I think it's missing the bigger picture. There is a lot more state that gets lost if we have to revert all of the emitted commands. A quick look at brw_upload_pipeline_state() shows all of the programs could be invalid as well, or the number of samples, etc... To me it seems like we need a much larger state save/restore. Ken: what do you think? How about not rolling back? If we accept it as currently broken, and just demand the kernel provide logical contexts for all i965 devices (just ack some patches!), and then just flush the batch (possibly with a dummy 3D prim if you want to be sure the 3D state is loaded) and rely on the context preserving state across batches. -Chris Actually I'm not sure why this isn't happening already :| Unless you're talking about kernel patches? ;) - Lionel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
Quoting Lionel Landwerlin (2019-01-08 11:03:26) > Hi Andrii, > > Although I think what these patches do makes sense, I think it's missing > the bigger picture. > There is a lot more state that gets lost if we have to revert all of the > emitted commands. > A quick look at brw_upload_pipeline_state() shows all of the programs > could be invalid as well, or the number of samples, etc... > > To me it seems like we need a much larger state save/restore. > > Ken: what do you think? How about not rolling back? If we accept it as currently broken, and just demand the kernel provide logical contexts for all i965 devices (just ack some patches!), and then just flush the batch (possibly with a dummy 3D prim if you want to be sure the 3D state is loaded) and rely on the context preserving state across batches. -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
Hi Andrii,
Although I think what these patches do makes sense, I think it's missing
the bigger picture.
There is a lot more state that gets lost if we have to revert all of the
emitted commands.
A quick look at brw_upload_pipeline_state() shows all of the programs
could be invalid as well, or the number of samples, etc...
To me it seems like we need a much larger state save/restore.
Ken: what do you think?
Cheers,
-
Lionel
On 19/11/2018 21:19, asimiklit.w...@gmail.com wrote:
From: Andrii Simiklit
This patch is needed to avoid missing 3DSTATE_URB_* commands in a batch after
rollback operation.
To be able to test easily this issue
the following workaround is necessary:
-if (!brw_batch_has_aperture_space(brw, 0)) {
by:
+if (true) {
in brw_draw_single_prim function.
This workaround forces a rollback for each batch.
The "gl-3.2-adj-prims pv-first -auto -fbo" piglit test with this workaround
led to a hung. The hung investigation helped to find that some batches
didn't have the 3DSTATE_URB_* commands in compare to batches which were
generated without this workaround.
Reported-by: Kenneth Graunke
Signed-off-by: Andrii Simiklit
---
src/mesa/drivers/dri/i965/brw_context.h | 8
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12
2 files changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 7fd15669eb..4e1682ba5c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -521,6 +521,14 @@ struct intel_batchbuffer {
int batch_reloc_count;
int state_reloc_count;
int exec_count;
+ struct {
+ GLuint vsize;
+ GLuint gsize;
+ GLuint hsize;
+ GLuint dsize;
+ bool gs_present;
+ bool tess_present;
+ } urb;
} saved;
/** Map from batch offset to brw_state_batch data (with DEBUG_BATCH) */
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 353fcba18f..bae9f2ffed 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -299,6 +299,12 @@ intel_batchbuffer_save_state(struct brw_context *brw)
brw->batch.saved.batch_reloc_count = brw->batch.batch_relocs.reloc_count;
brw->batch.saved.state_reloc_count = brw->batch.state_relocs.reloc_count;
brw->batch.saved.exec_count = brw->batch.exec_count;
+ brw->batch.saved.urb.vsize = brw->urb.vsize;
+ brw->batch.saved.urb.gs_present = brw->urb.gs_present;
+ brw->batch.saved.urb.gsize = brw->urb.gsize;
+ brw->batch.saved.urb.tess_present = brw->urb.tess_present;
+ brw->batch.saved.urb.hsize = brw->urb.hsize;
+ brw->batch.saved.urb.dsize = brw->urb.dsize;
}
void
@@ -313,6 +319,12 @@ intel_batchbuffer_reset_to_saved(struct brw_context *brw)
brw->batch.exec_count = brw->batch.saved.exec_count;
brw->batch.map_next = brw->batch.saved.map_next;
+ brw->urb.vsize = brw->batch.saved.urb.vsize;
+ brw->urb.gs_present = brw->batch.saved.urb.gs_present;
+ brw->urb.gsize = brw->batch.saved.urb.gsize;
+ brw->urb.tess_present = brw->batch.saved.urb.tess_present;
+ brw->urb.hsize = brw->batch.saved.urb.hsize;
+ brw->urb.dsize = brw->batch.saved.urb.dsize;
if (USED_BATCH(brw->batch) == 0)
brw_new_batch(brw);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl/linker: specify proper direction in location aliasing error
Reviewed-by: Iago Toral Quiroga
On Mon, 2019-01-07 at 16:11 +0200, Andres Gomez wrote:
> The check for location aliasing was always asuming output variables
> but this validation is also called for input variables.
>
> Fixes: e2abb75b0e4 ("glsl/linker: validate explicit locations for SSO
> programs")
> Cc: Iago Toral Quiroga
> Signed-off-by: Andres Gomez
> ---
> src/compiler/glsl/link_varyings.cpp | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/src/compiler/glsl/link_varyings.cpp
> b/src/compiler/glsl/link_varyings.cpp
> index 52e493cb599..3969c0120b3 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -481,9 +481,10 @@ check_location_aliasing(struct
> explicit_location_info explicit_locations[][4],
> /* Component aliasing is not alloed */
> if (comp >= component && comp < last_comp) {
> linker_error(prog,
> -"%s shader has multiple outputs
> explicitly "
> +"%s shader has multiple %sputs
> explicitly "
> "assigned to location %d and component
> %d\n",
> _mesa_shader_stage_to_string(stage),
> +var->data.mode == ir_var_shader_in ?
> "in" : "out",
> location, comp);
> return false;
> } else {
> @@ -502,10 +503,12 @@ check_location_aliasing(struct
> explicit_location_info explicit_locations[][4],
>
> if (info->interpolation != interpolation) {
>linker_error(prog,
> - "%s shader has multiple outputs at
> explicit "
> + "%s shader has multiple %sputs at
> explicit "
> "location %u with different
> interpolation "
> "settings\n",
> - _mesa_shader_stage_to_string(stage),
> location);
> + _mesa_shader_stage_to_string(stage),
> + var->data.mode == ir_var_shader_in ?
> + "in" : "out", location);
>return false;
> }
>
> @@ -513,9 +516,11 @@ check_location_aliasing(struct
> explicit_location_info explicit_locations[][4],
> info->sample != sample ||
> info->patch != patch) {
>linker_error(prog,
> - "%s shader has multiple outputs at
> explicit "
> + "%s shader has multiple %sputs at
> explicit "
> "location %u with different aux
> storage\n",
> - _mesa_shader_stage_to_string(stage),
> location);
> + _mesa_shader_stage_to_string(stage),
> + var->data.mode == ir_var_shader_in ?
> + "in" : "out", location);
>return false;
> }
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] egl: add config debug printout (v2)
On Thursday, 2018-12-20 10:02:35 +, Silvestrs Timofejevs wrote:
> Feature to print out EGL returned configs for debug purposes.
>
> 'eglChooseConfig' and 'eglGetConfigs' debug information printout is
> enabled when the log level equals '_EGL_DEBUG'. The configs are
> printed, and if any of them are "chosen" they are marked with their
> index in the chosen configs array.
>
> v2:
>a) refactor the code in line with Eric's comments
>b) rename function _snprintfStrcat, split it out and put into the
> src/util/u_string.h, make it a separate patch.
>
> Signed-off-by: Silvestrs Timofejevs
> ---
> src/egl/Makefile.sources | 4 +-
> src/egl/main/eglconfig.c | 20 +++-
> src/egl/main/eglconfigdebug.c | 265
> ++
> src/egl/main/eglconfigdebug.h | 55 +
> src/egl/meson.build | 2 +
> 5 files changed, 341 insertions(+), 5 deletions(-)
> create mode 100644 src/egl/main/eglconfigdebug.c
> create mode 100644 src/egl/main/eglconfigdebug.h
>
> diff --git a/src/egl/Makefile.sources b/src/egl/Makefile.sources
> index 0cc5f1b..353a848 100644
> --- a/src/egl/Makefile.sources
> +++ b/src/egl/Makefile.sources
> @@ -28,7 +28,9 @@ LIBEGL_C_FILES := \
> main/eglsync.c \
> main/eglsync.h \
> main/eglentrypoint.h \
> - main/egltypedefs.h
> + main/egltypedefs.h \
> + main/eglconfigdebug.h \
> + main/eglconfigdebug.c
>
> dri2_backend_core_FILES := \
> drivers/dri2/egl_dri2.c \
> diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
> index a346f93..0095dc2 100644
> --- a/src/egl/main/eglconfig.c
> +++ b/src/egl/main/eglconfig.c
> @@ -40,6 +40,7 @@
> #include "util/macros.h"
>
> #include "eglconfig.h"
> +#include "eglconfigdebug.h"
> #include "egldisplay.h"
> #include "eglcurrent.h"
> #include "egllog.h"
> @@ -797,14 +798,21 @@ _eglChooseConfig(_EGLDriver *drv, _EGLDisplay *disp,
> const EGLint *attrib_list,
> EGLConfig *configs, EGLint config_size, EGLint *num_configs)
> {
> _EGLConfig criteria;
> + EGLBoolean result;
>
> if (!_eglParseConfigAttribList(, disp, attrib_list))
>return _eglError(EGL_BAD_ATTRIBUTE, "eglChooseConfig");
>
> - return _eglFilterConfigArray(disp->Configs,
> - configs, config_size, num_configs,
> - _eglFallbackMatch, _eglFallbackCompare,
> - (void *) );
> + result = _eglFilterConfigArray(disp->Configs,
> + configs, config_size, num_configs,
> + _eglFallbackMatch, _eglFallbackCompare,
> + (void *) );
> +
> + if (result && (_eglGetLogLevel() == _EGL_DEBUG))
> + eglPrintConfigDebug(drv, disp, configs, *num_configs,
> + EGL_CONFIG_DEBUG_CHOOSE);
> +
> + return result;
> }
>
>
> @@ -857,5 +865,9 @@ _eglGetConfigs(_EGLDriver *drv, _EGLDisplay *disp,
> EGLConfig *configs,
> *num_config = _eglFlattenArray(disp->Configs, (void *) configs,
> sizeof(configs[0]), config_size, _eglFlattenConfig);
>
> + if (_eglGetLogLevel() == _EGL_DEBUG)
> + eglPrintConfigDebug(drv, disp, configs, *num_config,
> + EGL_CONFIG_DEBUG_GET);
> +
> return EGL_TRUE;
> }
> diff --git a/src/egl/main/eglconfigdebug.c b/src/egl/main/eglconfigdebug.c
> new file mode 100644
> index 000..0617c99
> --- /dev/null
> +++ b/src/egl/main/eglconfigdebug.c
> @@ -0,0 +1,265 @@
> +/*
> + * Copyright 2017 Imagination Technologies.
> + * All Rights Reserved.
> + *
> + * Based on eglinfo, which has copyright:
> + * Copyright (C) 2005 Brian Paul All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included
> + * in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
> + * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "eglarray.h"
> +#include "eglconfig.h"
> +#include "eglconfigdebug.h"
> +#include "egldisplay.h"
> +#include "egllog.h"
>
Re: [Mesa-dev] [PATCH] editorconfig: Add max_line_length property
On Monday, 2019-01-07 12:43:54 -0800, Dylan Baker wrote:
> Quoting Andres Gomez (2019-01-07 05:49:00)
> > The property is supported by the most of the editors, but not all:
> > https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#max_line_length
> >
> > Cc: Eric Engestrom
> > Cc: Eric Anholt
> > Signed-off-by: Andres Gomez
> > ---
> > .editorconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/.editorconfig b/.editorconfig
> > index 06848f68c08..c2b772da6c1 100644
> > --- a/.editorconfig
> > +++ b/.editorconfig
> > @@ -11,6 +11,7 @@ tab_width = 8
> > [*.{c,h,cpp,hpp,cc,hh}]
> > indent_style = space
> > indent_size = 3
> > +max_line_length = 78
> >
> > [{Makefile*,*.mk}]
> > indent_style = tab
> > --
> > 2.18.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> I think the big ones are covered here: vim, emacs, atom, intellij (and
> deriviatives), resharper, rider. That seems like it covers pretty much
> everyone.
Thanks, and agreed with Dylan; you can also have my:
Reviewed-by: Eric Engestrom
>
> Reviewed-by: Dylan Baker
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
Hi all,
Could somebody take a look at this patch?
Regards,
Andrii.
On Mon, Nov 19, 2018 at 11:19 PM wrote:
> From: Andrii Simiklit
>
> This patch is needed to avoid missing 3DSTATE_URB_* commands in a batch
> after
> rollback operation.
>
> To be able to test easily this issue
> the following workaround is necessary:
> -if (!brw_batch_has_aperture_space(brw, 0)) {
> by:
> +if (true) {
> in brw_draw_single_prim function.
>
> This workaround forces a rollback for each batch.
> The "gl-3.2-adj-prims pv-first -auto -fbo" piglit test with this workaround
> led to a hung. The hung investigation helped to find that some batches
> didn't have the 3DSTATE_URB_* commands in compare to batches which were
> generated without this workaround.
>
> Reported-by: Kenneth Graunke
> Signed-off-by: Andrii Simiklit
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 8
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12
> 2 files changed, 20 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 7fd15669eb..4e1682ba5c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -521,6 +521,14 @@ struct intel_batchbuffer {
>int batch_reloc_count;
>int state_reloc_count;
>int exec_count;
> + struct {
> + GLuint vsize;
> + GLuint gsize;
> + GLuint hsize;
> + GLuint dsize;
> + bool gs_present;
> + bool tess_present;
> + } urb;
> } saved;
>
> /** Map from batch offset to brw_state_batch data (with DEBUG_BATCH) */
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 353fcba18f..bae9f2ffed 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -299,6 +299,12 @@ intel_batchbuffer_save_state(struct brw_context *brw)
> brw->batch.saved.batch_reloc_count =
> brw->batch.batch_relocs.reloc_count;
> brw->batch.saved.state_reloc_count =
> brw->batch.state_relocs.reloc_count;
> brw->batch.saved.exec_count = brw->batch.exec_count;
> + brw->batch.saved.urb.vsize = brw->urb.vsize;
> + brw->batch.saved.urb.gs_present = brw->urb.gs_present;
> + brw->batch.saved.urb.gsize = brw->urb.gsize;
> + brw->batch.saved.urb.tess_present = brw->urb.tess_present;
> + brw->batch.saved.urb.hsize = brw->urb.hsize;
> + brw->batch.saved.urb.dsize = brw->urb.dsize;
> }
>
> void
> @@ -313,6 +319,12 @@ intel_batchbuffer_reset_to_saved(struct brw_context
> *brw)
> brw->batch.exec_count = brw->batch.saved.exec_count;
>
> brw->batch.map_next = brw->batch.saved.map_next;
> + brw->urb.vsize = brw->batch.saved.urb.vsize;
> + brw->urb.gs_present = brw->batch.saved.urb.gs_present;
> + brw->urb.gsize = brw->batch.saved.urb.gsize;
> + brw->urb.tess_present = brw->batch.saved.urb.tess_present;
> + brw->urb.hsize = brw->batch.saved.urb.hsize;
> + brw->urb.dsize = brw->batch.saved.urb.dsize;
> if (USED_BATCH(brw->batch) == 0)
>brw_new_batch(brw);
> }
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: add missing rollback of a xfb zero_offsets flag
Hi all,
Could somebody take a look at this patch?
Regards,
Andrii.
On Mon, Nov 19, 2018 at 11:19 PM wrote:
> From: Andrii Simiklit
>
> This patch is needed to avoid incorrect value of StreamOffset flag
> in 3DSTATE_SO_BUFFER command after rollback operation.
>
> To be able to test easily this issue
> the following workaround is necessary:
> -if (!brw_batch_has_aperture_space(brw, 0)) {
> by:
> +if (true) {
> in brw_draw_single_prim function.
>
> This workaround forces a rollback for each batch.
> The "gl-3.2-adj-prims pv-first -fbo" piglit test with this workaround
> failed
> (when URB requirements was fixed this test started to fail instead of a
> hang).
> Investigation of this failure helped to find that some batches have a
> different
> Stream Offset in the 3D STATE_SO_BUFFER command in compare to batches
> which were
> generated without this workaround.
>
> Reported-by: Kenneth Graunke
> Signed-off-by: Andrii Simiklit
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 3 +++
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 10 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 4e1682ba5c..86c9bf0a5c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -521,6 +521,9 @@ struct intel_batchbuffer {
>int batch_reloc_count;
>int state_reloc_count;
>int exec_count;
> + struct {
> + bool zero_offsets;
> + } xfb;
>struct {
> GLuint vsize;
> GLuint gsize;
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index bae9f2ffed..85e5f64123 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -295,10 +295,15 @@
> intel_batchbuffer_reset_and_clear_render_cache(struct brw_context *brw)
> void
> intel_batchbuffer_save_state(struct brw_context *brw)
> {
> + struct brw_transform_feedback_object *brw_xfb_obj =
> + (struct brw_transform_feedback_object *)
> +brw->ctx.TransformFeedback.CurrentObject;
> +
> brw->batch.saved.map_next = brw->batch.map_next;
> brw->batch.saved.batch_reloc_count =
> brw->batch.batch_relocs.reloc_count;
> brw->batch.saved.state_reloc_count =
> brw->batch.state_relocs.reloc_count;
> brw->batch.saved.exec_count = brw->batch.exec_count;
> + brw->batch.saved.xfb.zero_offsets = brw_xfb_obj->zero_offsets;
> brw->batch.saved.urb.vsize = brw->urb.vsize;
> brw->batch.saved.urb.gs_present = brw->urb.gs_present;
> brw->batch.saved.urb.gsize = brw->urb.gsize;
> @@ -310,6 +315,10 @@ intel_batchbuffer_save_state(struct brw_context *brw)
> void
> intel_batchbuffer_reset_to_saved(struct brw_context *brw)
> {
> + struct brw_transform_feedback_object *brw_xfb_obj =
> + (struct brw_transform_feedback_object *)
> +brw->ctx.TransformFeedback.CurrentObject;
> +
> for (int i = brw->batch.saved.exec_count;
> i < brw->batch.exec_count; i++) {
>brw_bo_unreference(brw->batch.exec_bos[i]);
> @@ -319,6 +328,7 @@ intel_batchbuffer_reset_to_saved(struct brw_context
> *brw)
> brw->batch.exec_count = brw->batch.saved.exec_count;
>
> brw->batch.map_next = brw->batch.saved.map_next;
> + brw_xfb_obj->zero_offsets = brw->batch.saved.xfb.zero_offsets;
> brw->urb.vsize = brw->batch.saved.urb.vsize;
> brw->urb.gs_present = brw->batch.saved.urb.gs_present;
> brw->urb.gsize = brw->batch.saved.urb.gsize;
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] anv: Implement VK_KHR_draw_indirect_count and VK_EXT_conditional_rendering
Hi, Thanks! I finally got CI results with ALL relevant tests and my implementation works on everything but Haswell. So I'll fix whatever is wrong there (hope that's just something small) and send the final version. There are still some tests for VK-GL-CTS which are not merged in master e.g. https://github.com/KhronosGroup/VK-GL-CTS/pull/136 and there are some unpublished tests for VK_EXT_conditional_rendering from other devs which I have no idea when will be merged. I don't think this will prevent merging my patches but still I would be more confident if CI have ALL tests. And yes, I also was quite slow with my patches. On 1/8/19 11:13 AM, Erik Faye-Lund wrote: On Wed, 2018-10-17 at 14:58 +0300, Danylo Piliaiev wrote: This series implement VK_KHR_draw_indirect_count and VK_EXT_conditional_rendering extensions. They are implemented together because they are highly interweaved. There are already tests in VK_CTS for VK_KHR_draw_indirect_count and I made a pull request with the tests for VK_EXT_conditional_rendering ( https://github.com/KhronosGroup/VK-GL-CTS/pull/131). VK_KHR_draw_indirect_count is implemented for gen7+. VK_EXT_conditional_rendering is implemented for gen7.5+ because it requires MI_MATH to be implemented correctly. Since part of the tests aren't in VK-GL-CTS master I'm not sure how to test the implementation of VK_EXT_conditional_rendering with my tests on CI. Could anyone help me with this? Also the one thing I'm uncertain of is described in the last patch. Many thanks to Jason Ekstrand for the help with the extensions. Hey, great work :) What's holding this series back? I'm very interested in this functionality due to my work on Zink... :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: complete the calendar and release schedule documentation
On January 7, 2019 5:07:34 PM UTC, Andres Gomez wrote: > As suggested by Emil Velikov. > > Cc: Dylan Baker > Cc: Juan A. Suarez > Cc: Emil Velikov > Signed-off-by: Andres Gomez Reviewed-by: Eric Engestrom > --- > docs/release-calendar.html | 10 ++ > docs/releasing.html| 14 -- > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index afef899b0e0..3f4e1e9d8b9 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -23,6 +23,16 @@ Mesa provides feature/development and stable > releases. > The table below lists the date and release manager that is expected to > do the > specific release. > > +Regular updates will ensure that the schedule for the current and the > +next two feature releases are shown in the table. > + > +In order to keep the whole releasing team up to date with the tools > +used, best practices and other details, the member in charge of the > +next feature release will be in constant rotation. > + > +The way the release schedule works is > +explained target="_parent">here. > + > Take a look target="_parent">here > if you'd like to nominate a patch in the next stable release. > > diff --git a/docs/releasing.html b/docs/releasing.html > index e4c770f9186..851bbf58670 100644 > --- a/docs/releasing.html > +++ b/docs/releasing.html > @@ -56,9 +56,10 @@ For example: > > > Releases should happen on Wednesdays. Delays can occur although those > -should be keep to a minimum. > +should be kept to a minimum. > > -See our calendar > for the > +See our calendar > +for information about how the release schedule is planned, and the > date and other details for individual releases. > > > @@ -67,6 +68,9 @@ date and other details for individual releases. > Available approximately every three months. > Initial timeplan available 2-4 weeks before the planned > branchpoint (rc1) > on the mesa-announce@ mailing list. > +Typically, the final release will happen after 4 > +candidates. Additional ones may be needed in order to resolve > blocking > +regressions, though. > A pre-release announcement should be > available > approximately 24 hours before the final (non-rc) release. > > @@ -84,6 +88,12 @@ Note: There is one or two releases overlap when > changing branches. For example: > > The final release from the 12.0 series Mesa 12.0.5 will be out around > the same > time (or shortly after) 13.0.1 is out. > + > +This also involves that, as a final release may be delayed due to the > +need of additional candidates to solve some blocking regression(s), > +the release manager might have to update > +the calendar > with > +additional bug fix releases of the current stable branch. > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] radv: add support for VK_EXT_memory_budget
On Mon, 7 Jan 2019 at 17:20, Samuel Pitoiset
wrote:
>
> On 1/7/19 6:06 PM, Alex Smith wrote:
>
> Hi Samuel,
>
> Thanks for implementing this - I've been wanting this extension for a
> while so it's good it's finally available.
>
> This is just reporting the total heap sizes as the budget, which is the
> same info we already get from the basic heap properties. The way I'd
> expected budget to work (and what the spec is saying as far as I can see)
> is that it's an estimate of how much is available for the calling app to
> use in that heap at the time of the call, so should account for current
> system-wide usage of the heap by other apps. Shouldn't this be something
> like (heap size - system wide usage of the heap + current app usage of the
> heap)? (+ app usage since the spec says budget includes currently allocated
> device memory)
>
> Hi Alex,
>
> Yes, I was also wondering about that. We can add per-process counters for
> VRAM and GTT heaps, but I don't see how we can be accurate for the visible
> VRAM heap.
>
> As said in the commit description, that implementation is really
> inacurate. Though if you need something better I can improve.
>
What I'm after from this extension is the ability to get an idea of when we
will either start failing allocations, or start causing some allocations to
be paged out from a heap (and probably cause a perf degradation). We have
our own systems for relocating resources between heaps when under memory
pressure, but currently we can only decide when we need to do this based on
guesswork of how much we need to leave free in a heap for other apps or
when we actually get to the point where allocations fail. For this
extension to be useful to improve on that it needs to include some sort of
reporting of app usage vs system-wide usage.
Thanks,
Alex
> Note that I agree with you about the spec.
>
>
> Alex
>
> On Mon, 7 Jan 2019 at 16:35, Samuel Pitoiset
> wrote:
>
>> A simple Vulkan extension that allows apps to query size and
>> usage of all exposed memory heaps.
>>
>> The different usage values are not really accurate because
>> they are per drm-fd, but they should be close enough.
>>
>> Signed-off-by: Samuel Pitoiset
>> ---
>> src/amd/vulkan/radv_device.c | 44 +++
>> src/amd/vulkan/radv_extensions.py | 1 +
>> 2 files changed, 45 insertions(+)
>>
>> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
>> index cef3a430555..32eaeb3b226 100644
>> --- a/src/amd/vulkan/radv_device.c
>> +++ b/src/amd/vulkan/radv_device.c
>> @@ -1352,12 +1352,56 @@ void radv_GetPhysicalDeviceMemoryProperties(
>> *pMemoryProperties = physical_device->memory_properties;
>> }
>>
>> +static void
>> +radv_get_memory_budget_properties(VkPhysicalDevice physicalDevice,
>> +
>> VkPhysicalDeviceMemoryBudgetPropertiesEXT *memoryBudget)
>> +{
>> + RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
>> + VkPhysicalDeviceMemoryProperties *memory_properties =
>> >memory_properties;
>> + uint64_t visible_vram_size = radv_get_visible_vram_size(device);
>> + uint64_t vram_size = radv_get_vram_size(device);
>> + uint64_t gtt_size = device->rad_info.gart_size;
>> +
>> + if (vram_size) {
>> + memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = vram_size;
>> + memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] =
>> + device->ws->query_value(device->ws,
>> RADEON_VRAM_USAGE);
>> + }
>> +
>> + if (visible_vram_size) {
>> + memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
>> visible_vram_size;
>> + memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
>> + device->ws->query_value(device->ws,
>> RADEON_VRAM_VIS_USAGE);
>> + }
>> +
>> + if (gtt_size) {
>> + memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = gtt_size;
>> + memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] =
>> + device->ws->query_value(device->ws,
>> RADEON_GTT_USAGE);
>> + }
>> +
>> + /* The heapBudget and heapUsage values must be zero for array
>> elements
>> +* greater than or equal to
>> +* VkPhysicalDeviceMemoryProperties::memoryHeapCount.
>> +*/
>> + for (uint32_t i = memory_properties->memoryHeapCount; i <
>> VK_MAX_MEMORY_HEAPS; i++) {
>> + memoryBudget->heapBudget[i] = 0;
>> + memoryBudget->heapUsage[i] = 0;
>> + }
>> +}
>> +
>> void radv_GetPhysicalDeviceMemoryProperties2(
>> VkPhysicalDevicephysicalDevice,
>> VkPhysicalDeviceMemoryProperties2KHR *pMemoryProperties)
>> {
>> radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
>>
>> >memoryProperties);
>> +
>> + VkPhysicalDeviceMemoryBudgetPropertiesEXT *memory_budget =
>> + vk_find_struct(pMemoryProperties->pNext,
>> +
>>
Re: [Mesa-dev] [PATCH 0/3] anv: Implement VK_KHR_draw_indirect_count and VK_EXT_conditional_rendering
On Wed, 2018-10-17 at 14:58 +0300, Danylo Piliaiev wrote: > This series implement VK_KHR_draw_indirect_count and > VK_EXT_conditional_rendering extensions. > They are implemented together because they are highly interweaved. > > There are already tests in VK_CTS for VK_KHR_draw_indirect_count and > I made a pull request with > the tests for VK_EXT_conditional_rendering ( > https://github.com/KhronosGroup/VK-GL-CTS/pull/131). > > VK_KHR_draw_indirect_count is implemented for gen7+. > VK_EXT_conditional_rendering is implemented for gen7.5+ because it > requires MI_MATH to be > implemented correctly. > > Since part of the tests aren't in VK-GL-CTS master I'm not sure how > to test the implementation > of VK_EXT_conditional_rendering with my tests on CI. Could anyone > help me with this? > > Also the one thing I'm uncertain of is described in the last patch. > > Many thanks to Jason Ekstrand for the help with the extensions. > Hey, great work :) What's holding this series back? I'm very interested in this functionality due to my work on Zink... :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Chromium - Application-level nouveau blacklist
Hi, On 8.1.2019 8.56, Stéphane Marchesin wrote: Yes I think the Chrome-side is very simple here: because there isn't time or means for in-depth investigation, if a driver crashes too much, it gets blacklisted. The situation is not unique, the GPU blacklist file is 1700 lines: https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json Anyway, IMO if the biggest crashers can be fixed, I think we could eventually make a case to reenable. Can Chrome crash tracking system provide following information: * which www-page caused the crash * upstream Mesa commit used * upstream kernel commit used * if crash is from ChromeOS - what patches have been applied on top of kernel & Mesa * if crash is from a Linux distro - distro version and windowing system setup (X/Wayland, compositor) - package versions for kernel, Mesa, display server and compositor (to find what kernel & Mesa patches are applied) * detailed HW information * backtrace ? So that developers could try the corresponding combination? - Eero ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109153] [KBL-G][VK] Vulkan CTS spirv_assembly cases failed Segmentation fault (core dumped)
https://bugs.freedesktop.org/show_bug.cgi?id=109153 --- Comment #6 from Samuel Pitoiset --- The following commit fixes the crash for me commit 2f4f5a5055c74a35916645ed6eb2f8bd8ca7d221 Author: Dave Airlie Date: Wed Jul 4 16:21:49 2018 +1000 spirv/vtn: handle variable pointers without offset lowering Reviewed-by: Jason Ekstrand -- 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 1/6] vulkan: Update the XML and headers to 1.1.97
Thanks! Pushed.
On Mon, Jan 7, 2019 at 9:46 AM Samuel Pitoiset
wrote:
> Acked-by: Samuel Pitoiset
>
> On 1/7/19 4:39 PM, Jason Ekstrand wrote:
> > ---
> > include/vulkan/vulkan.h | 2 +-
> > include/vulkan/vulkan_android.h | 2 +-
> > include/vulkan/vulkan_core.h| 155 +++-
> > include/vulkan/vulkan_fuchsia.h | 2 +-
> > include/vulkan/vulkan_ios.h | 2 +-
> > include/vulkan/vulkan_macos.h | 2 +-
> > include/vulkan/vulkan_vi.h | 2 +-
> > include/vulkan/vulkan_wayland.h | 2 +-
> > include/vulkan/vulkan_win32.h | 2 +-
> > include/vulkan/vulkan_xcb.h | 2 +-
> > include/vulkan/vulkan_xlib.h| 2 +-
> > include/vulkan/vulkan_xlib_xrandr.h | 2 +-
> > src/vulkan/registry/vk.xml | 175 +++-
> > 13 files changed, 311 insertions(+), 41 deletions(-)
> >
> > diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
> > index 77da63783e6..a3be4af6c46 100644
> > --- a/include/vulkan/vulkan.h
> > +++ b/include/vulkan/vulkan.h
> > @@ -2,7 +2,7 @@
> > #define VULKAN_H_ 1
> >
> > /*
> > -** Copyright (c) 2015-2018 The Khronos Group Inc.
> > +** Copyright (c) 2015-2019 The Khronos Group Inc.
> > **
> > ** Licensed under the Apache License, Version 2.0 (the "License");
> > ** you may not use this file except in compliance with the License.
> > diff --git a/include/vulkan/vulkan_android.h
> b/include/vulkan/vulkan_android.h
> > index 07aaeda28e3..e70376c8867 100644
> > --- a/include/vulkan/vulkan_android.h
> > +++ b/include/vulkan/vulkan_android.h
> > @@ -6,7 +6,7 @@ extern "C" {
> > #endif
> >
> > /*
> > -** Copyright (c) 2015-2018 The Khronos Group Inc.
> > +** Copyright (c) 2015-2019 The Khronos Group Inc.
> > **
> > ** Licensed under the Apache License, Version 2.0 (the "License");
> > ** you may not use this file except in compliance with the License.
> > diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
> > index 72542c72ec8..caeecd9bed1 100644
> > --- a/include/vulkan/vulkan_core.h
> > +++ b/include/vulkan/vulkan_core.h
> > @@ -6,7 +6,7 @@ extern "C" {
> > #endif
> >
> > /*
> > -** Copyright (c) 2015-2018 The Khronos Group Inc.
> > +** Copyright (c) 2015-2019 The Khronos Group Inc.
> > **
> > ** Licensed under the Apache License, Version 2.0 (the "License");
> > ** you may not use this file except in compliance with the License.
> > @@ -43,7 +43,7 @@ extern "C" {
> > #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
> > #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
> > // Version of this file
> > -#define VK_HEADER_VERSION 96
> > +#define VK_HEADER_VERSION 97
> >
> >
> > #define VK_NULL_HANDLE 0
> > @@ -148,6 +148,7 @@ typedef enum VkResult {
> > VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT =
> -1000158000,
> > VK_ERROR_FRAGMENTATION_EXT = -1000161000,
> > VK_ERROR_NOT_PERMITTED_EXT = -1000174001,
> > +VK_ERROR_INVALID_DEVICE_ADDRESS_EXT = -1000244000,
> > VK_ERROR_OUT_OF_POOL_MEMORY_KHR = VK_ERROR_OUT_OF_POOL_MEMORY,
> > VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR =
> VK_ERROR_INVALID_EXTERNAL_HANDLE,
> > VK_RESULT_BEGIN_RANGE = VK_ERROR_FRAGMENTED_POOL,
> > @@ -444,6 +445,8 @@ typedef enum VkStructureType {
> >
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT =
> 1000190002,
> > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR =
> 1000196000,
> > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR =
> 1000197000,
> > +
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR =
> 1000199000,
> > +VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR =
> 1000199001,
> >
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV =
> 1000201000,
> > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV =
> 1000202000,
> > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV =
> 1000202001,
> > @@ -460,7 +463,14 @@ typedef enum VkStructureType {
> >
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_PROPERTIES_EXT =
> 1000218001,
> > VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT
> = 1000218002,
> > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT
> = 1000221000,
> > +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT =
> 1000237000,
> > +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PRIORITY_FEATURES_EXT =
> 1000238000,
> > +VK_STRUCTURE_TYPE_MEMORY_PRIORITY_ALLOCATE_INFO_EXT = 1000238001,
> > +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT =
> 1000244000,
> > +VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT = 1000244001,
> > +VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT =
> 1000244002,
> > VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT = 1000246000,
>
Re: [Mesa-dev] [PATCH] docs: complete the calendar and release schedule documentation
Quoting Andres Gomez (2019-01-07 09:04:34) > As suggested by Emil Velikov. > > Cc: Dylan Baker > Cc: Juan A. Suarez > Cc: Emil Velikov > Signed-off-by: Andres Gomez > --- > docs/release-calendar.html | 10 ++ > docs/releasing.html| 14 -- > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index afef899b0e0..3f4e1e9d8b9 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -23,6 +23,16 @@ Mesa provides feature/development and stable releases. > The table below lists the date and release manager that is expected to do the > specific release. > > +Regular updates will ensure that the schedule for the current and the > +next two feature releases are shown in the table. > + > +In order to keep the whole releasing team up to date with the tools > +used, best practices and other details, the member in charge of the > +next feature release will be in constant rotation. > + > +The way the release schedule works is > +explained here. > + > Take a look target="_parent">here > if you'd like to nominate a patch in the next stable release. > > diff --git a/docs/releasing.html b/docs/releasing.html > index e4c770f9186..851bbf58670 100644 > --- a/docs/releasing.html > +++ b/docs/releasing.html > @@ -56,9 +56,10 @@ For example: > > > Releases should happen on Wednesdays. Delays can occur although those > -should be keep to a minimum. > +should be kept to a minimum. > > -See our calendar for the > +See our calendar > +for information about how the release schedule is planned, and the > date and other details for individual releases. > > > @@ -67,6 +68,9 @@ date and other details for individual releases. > Available approximately every three months. > Initial timeplan available 2-4 weeks before the planned branchpoint (rc1) > on the mesa-announce@ mailing list. > +Typically, the final release will happen after 4 > +candidates. Additional ones may be needed in order to resolve blocking > +regressions, though. > A pre-release announcement should be available > approximately 24 hours before the final (non-rc) release. > > @@ -84,6 +88,12 @@ Note: There is one or two releases overlap when changing > branches. For example: > > The final release from the 12.0 series Mesa 12.0.5 will be out around the > same > time (or shortly after) 13.0.1 is out. > + > +This also involves that, as a final release may be delayed due to the > +need of additional candidates to solve some blocking regression(s), > +the release manager might have to update > +the calendar with > +additional bug fix releases of the current stable branch. > > > > -- > 2.18.0 > Acked-by: Dylan Baker signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #3 from Samuel Pitoiset --- Can you explain how to reproduce? Can you upload a savegame? Is there anything in dmesg when it hangs? -- 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
