Re: [Mesa-dev] [PATCH] nir/lower_tex: Fix the channel ordering during conversion of AYUV images
On 1/15/19 4:34 AM, Lionel Landwerlin wrote: When writing this I used this page to figure the bytes' ordering : https://docs.microsoft.com/en-us/windows/desktop/medfound/recommended-8-bit-yuv-formats-for-video-rendering#ayuv Of course endianess confuses everything :( sunxi seems to support AYUV & VUYA : https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/include/video/sunxi_display2.h#L40 Finally this patch (and its gstreamer comments) confuses me even more : https://patchwork.freedesktop.org/patch/255529/ I really don't know what's right or wrong here... IMO order 1230 seems wrong to me. Vivek, was the order chosen just because vivid driver outputs that or is it based on anything else, like some specification or other information? - Lionel On 15/01/2019 00:49, Vivek Kasireddy wrote: From: "Kasireddy, Vivek" The channel ordering should be 1230 instead of 2103. While displaying the packed YUV buffers generated by the Vivid (Virtual Video) driver on Weston, it was observed that AYUV images were not displayed correctly. Changing the ordering to 1230 makes AYUV buffers display as expected. CC: Lionel Landwerlin CC: Tapani Palli Signed-off-by: Vivek Kasireddy --- src/compiler/nir/nir_lower_tex.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c index a618b86b34c..7058c54f17c 100644 --- a/src/compiler/nir/nir_lower_tex.c +++ b/src/compiler/nir/nir_lower_tex.c @@ -434,10 +434,10 @@ lower_ayuv_external(nir_builder *b, nir_tex_instr *tex) nir_ssa_def *ayuv = sample_plane(b, tex, 0); convert_yuv_to_rgb(b, tex, - nir_channel(b, ayuv, 2), nir_channel(b, ayuv, 1), - nir_channel(b, ayuv, 0), - nir_channel(b, ayuv, 3)); + nir_channel(b, ayuv, 2), + nir_channel(b, ayuv, 3), + nir_channel(b, ayuv, 0)); } /* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 Thomas Crider changed: What|Removed |Added Attachment #143100|0 |1 is obsolete|| --- Comment #71 from Thomas Crider --- Created attachment 143118 --> https://bugs.freedesktop.org/attachment.cgi?id=143118=edit patch to make divinity work Here's the modified patch that allows the vendor to be set in the driconf value. Things that need fixing: -It still sets an envvar because I dont know how to set the vendor string directly in dri_context.c or how to make driQueryOptionstr work in getstring.c -It still contains the glxcmds.c patch because without it the game crashes at launch. -- 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 6/6] anv: Implement VK_KHR_depth_stencil_resolve
On Mon, 2019-01-14 at 10:27 -0600, Jason Ekstrand wrote:
> On Mon, Jan 14, 2019 at 1:16 AM Iago Toral wrote:
> > On Fri, 2019-01-11 at 12:31 -0600, Jason Ekstrand wrote:
> > > On Fri, Jan 11, 2019 at 3:21 AM Iago Toral
> > > wrote:
> > > > On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > > >
> > > > > ---
> > > >
> > > > > src/intel/vulkan/anv_device.c | 28 ++
> > > >
> > > > > src/intel/vulkan/anv_extensions.py | 1 +
> > > >
> > > > > src/intel/vulkan/anv_pass.c| 37 +++-
> > > >
> > > > > src/intel/vulkan/anv_private.h | 3 +
> > > >
> > > > > src/intel/vulkan/genX_cmd_buffer.c | 136
> > > >
> > > > > +
> > > >
> > > > > 5 files changed, 204 insertions(+), 1 deletion(-)
> > > >
> > > > >
> > > >
> > > > > diff --git a/src/intel/vulkan/anv_device.c
> > > >
> > > > > b/src/intel/vulkan/anv_device.c
> > > >
> > > > > index 2a3919d2949..3761846bb7f 100644
> > > >
> > > > > --- a/src/intel/vulkan/anv_device.c
> > > >
> > > > > +++ b/src/intel/vulkan/anv_device.c
> > > >
> > > > > @@ -1138,6 +1138,34 @@ void anv_GetPhysicalDeviceProperties2(
> > > >
> > > > > break;
> > > >
> > > > >}
> > > >
> > > > >
> > > >
> > > > > + case
> > > >
> > > > >
> > > > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERT
> > > > IES_KH
> > > >
> > > > > R: {
> > > >
> > > > > + VkPhysicalDeviceDepthStencilResolvePropertiesKHR
> > > > *props =
> > > >
> > > > > +
> > > > (VkPhysicalDeviceDepthStencilResolvePropertiesKHR *)ext;
> > > >
> > > > > +
> > > >
> > > > > + /* We support all of the depth resolve modes */
> > > >
> > > > > + props->supportedDepthResolveModes =
> > > >
> > > > > +VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR |
> > > >
> > > > > +VK_RESOLVE_MODE_AVERAGE_BIT_KHR |
> > > >
> > > > > +VK_RESOLVE_MODE_MIN_BIT_KHR |
> > > >
> > > > > +VK_RESOLVE_MODE_MAX_BIT_KHR;
> > > >
> > > > > +
> > > >
> > > > > + /* Average doesn't make sense for stencil so we
> > > > don't
> > > >
> > > > > support that */
> > > >
> > > > > + props->supportedStencilResolveModes =
> > > >
> > > > > +VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR;
> > > >
> > > > > + if (pdevice->info.gen >= 8) {
> > > >
> > > > > +/* The advanced stencil resolve modes currently
> > > > require
> > > >
> > > > > stencil
> > > >
> > > > > + * sampling be supported by the hardware.
> > > >
> > > > > + */
> > > >
> > > > > +props->supportedStencilResolveModes |=
> > > >
> > > > > + VK_RESOLVE_MODE_MIN_BIT_KHR |
> > > >
> > > > > + VK_RESOLVE_MODE_MAX_BIT_KHR;
> > > >
> > > > > + }
> > > >
> > > > > +
> > > >
> > > > > + props->independentResolveNone = VK_TRUE;
> > > >
> > > > > + props->independentResolve = VK_TRUE;
> > > >
> > > > > + break;
> > > >
> > > > > + }
> > > >
> > > > > +
> > > >
> > > > >case
> > > > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR:
> > > >
> > > > > {
> > > >
> > > > > VkPhysicalDeviceDriverPropertiesKHR *driver_props =
> > > >
> > > > > (VkPhysicalDeviceDriverPropertiesKHR *) ext;
> > > >
> > > > > diff --git a/src/intel/vulkan/anv_extensions.py
> > > >
> > > > > b/src/intel/vulkan/anv_extensions.py
> > > >
> > > > > index 388845003aa..2ea4cab0e97 100644
> > > >
> > > > > --- a/src/intel/vulkan/anv_extensions.py
> > > >
> > > > > +++ b/src/intel/vulkan/anv_extensions.py
> > > >
> > > > > @@ -76,6 +76,7 @@ EXTENSIONS = [
> > > >
> > > > > Extension('VK_KHR_bind_memory2', 1,
> > > > True),
> > > >
> > > > > Extension('VK_KHR_create_renderpass2',1,
> > > > True),
> > > >
> > > > > Extension('VK_KHR_dedicated_allocation', 1,
> > > > True),
> > > >
> > > > > +Extension('VK_KHR_depth_stencil_resolve', 1,
> > > > True),
> > > >
> > > > > Extension('VK_KHR_descriptor_update_template',1,
> > > > True),
> > > >
> > > > > Extension('VK_KHR_device_group', 1,
> > > > True),
> > > >
> > > > > Extension('VK_KHR_device_group_creation', 1,
> > > > True),
> > > >
> > > > > diff --git a/src/intel/vulkan/anv_pass.c
> > > >
> > > > > b/src/intel/vulkan/anv_pass.c
> > > >
> > > > > index 7b17cc06935..196cf3ff8fd 100644
> > > >
> > > > > --- a/src/intel/vulkan/anv_pass.c
> > > >
> > > > > +++ b/src/intel/vulkan/anv_pass.c
> > > >
> > > > > @@ -74,6 +74,10 @@ anv_render_pass_compile(struct
> > > > anv_render_pass
> > > >
> > > > > *pass)
> > > >
> > > > >subpass->depth_stencil_attachment->attachment ==
> > > >
> > > > > VK_ATTACHMENT_UNUSED)
> > > >
> > > > > subpass->depth_stencil_attachment = NULL;
> > > >
> > > > >
> > > >
> > > > > + if
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551
--- Comment #70 from Thomas Crider ---
Marek Olšák this patch for glxcmds.c is necessary for the game to run at all,
without it the game crashes:
+ if (strcmp((const char *) procName, "glNamedStringARB") == 0 ||
+ strcmp((const char *) procName, "glDeleteNamedStringARB") == 0 ||
+ strcmp((const char *) procName, "glCompileShaderIncludeARB") == 0 ||
+ strcmp((const char *) procName, "glIsNamedStringARB") == 0 ||
+ strcmp((const char *) procName, "glGetNamedStringARB") == 0 ||
+ strcmp((const char *) procName, "glGetNamedStringivARB") == 0)
+ return NULL;
as for not setting envvars, in my current patch I made dri_context set an
envvar and getstring read that envvar because I wasn't sure how to set the
vendor string in dri_context, and I wasn't sure how to use driQueryOptionstr in
getstring in order to do so.
I have a modified patch which currently does this instead in dri_context:
if (driQueryOptionstr(optionCache, "allow_vendor_override")) {
ctx_config->vendor==driQueryOptionstr(optionCache,
"allow_vendor_override");
}
obv. ctx_config->vendor is wrong, but I don't know the correct syntax.
--
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] Thoughts after hitting 100 merge requests?
On 1/14/19 2:36 PM, Daniel Stone wrote: Hi, On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote: 5. There's no way with gitlab for Reviewed-by tags to get automatically applied as part of the merging process. This makes merging a bit more manual than it needs to be but is really no worse than it was before. I'm still on the side of not seeing the value in them. Most of the time when I go to pursue someone who reviewed a commit, I'll go to see what came up in review anyway. Maybe someone had the same comment which was found to be not applicable or otherwise explained away. Reviewed-by and Acked-by are also pretty lossy anyway, and freeform text descriptors in a comment can much better capture the intent (e.g. 'I'm strongly OK with the driver changes and weakly OK with the core changes as it's not really my area of expertise'). In other projects, we looked for ways to apply the tags and ended up concluding that they didn't bring enough value to make it worthwhile. I don't know if that holds for Mesa, but it would be better to start with an actual problem statement - what value does R-b bring and how? - then look at ways to solve that problem, rather than just very directly finding a way to insert that literal text string into every commit message. IMO it brings some 'shared responsibility' for correctness of the patch and quickly accessible information on who were looking at the change. So ideally later when filing bug against commit/series there would be more people than just the committer that should take a look at the possible regressions. At least in my experience people filing bugs tend to often also CC the reviewer. FWIW, if you go to https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a hyperlink from the web UI which points you to the MR. The API to do this is pretty straightforward and amenable to piping through jq: https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit I guess if we would move issue tracking to gitlab then we could possibly automate the CC list generation based on commit? // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109362] Objects are invisible in Resident Evil 2 "1-Shot Demo" with RADV
https://bugs.freedesktop.org/show_bug.cgi?id=109362 Bug ID: 109362 Summary: Objects are invisible in Resident Evil 2 "1-Shot Demo" with RADV Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: laichiah...@outlook.com QA Contact: mesa-dev@lists.freedesktop.org https://user-images.githubusercontent.com/3217851/51076915-c9ff6280-16c0-11e9-9c5b-468c33690f4a.png RADV doesn't render correctly in this game, but I've tried AMDGPU-PRO driver, it works without problem. -- 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 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
https://bugs.freedesktop.org/show_bug.cgi?id=109258 n3rdopolis changed: What|Removed |Added Version|unspecified |git OS|All |Linux (All) Hardware|Other |All -- 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 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
https://bugs.freedesktop.org/show_bug.cgi?id=109258
--- Comment #1 from n3rdopolis ---
Hi
I tested on an older image of a system that I have. (testing a few)
Then testing different Mesa revisons.
I have narrowed this down to commit 8cb84c8477a57ed05d703669fee1770f31b76ae6
"egl: move alloc & init out of _eglBuiltInDriver{DRI2,Haiku}" on
2017-10-18
as the commit 4893673b155b9ff2e0fc0730b214ba3bcbe75a89 before it works.
I am able to run weston with LIBGL_ALWAYS_SOFTWARE with a mesa built from this
commit
Thanks
--
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 109361] [KBL-G][GL-es] several shader test cases failed to compile
https://bugs.freedesktop.org/show_bug.cgi?id=109361 Hai changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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] Thoughts after hitting 100 merge requests?
There are still people who don't look at the merge requests in gitlab yet, like me. :) I've noticed there are fewer emails... I'll switch after you guys figure out whether MRs are better. Marek On Mon, Jan 14, 2019 at 7:36 AM Daniel Stone wrote: > Hi, > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote: > > 5. There's no way with gitlab for Reviewed-by tags to get automatically > applied as part of the merging process. This makes merging a bit more > manual than it needs to be but is really no worse than it was before. > > I'm still on the side of not seeing the value in them. Most of the > time when I go to pursue someone who reviewed a commit, I'll go to see > what came up in review anyway. Maybe someone had the same comment > which was found to be not applicable or otherwise explained away. > Reviewed-by and Acked-by are also pretty lossy anyway, and freeform > text descriptors in a comment can much better capture the intent (e.g. > 'I'm strongly OK with the driver changes and weakly OK with the core > changes as it's not really my area of expertise'). > > In other projects, we looked for ways to apply the tags and ended up > concluding that they didn't bring enough value to make it worthwhile. > I don't know if that holds for Mesa, but it would be better to start > with an actual problem statement - what value does R-b bring and how? > - then look at ways to solve that problem, rather than just very > directly finding a way to insert that literal text string into every > commit message. > > FWIW, if you go to > https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a > hyperlink from the web UI which points you to the MR. The API to do > this is pretty straightforward and amenable to piping through jq: > > https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit > > Cheers, > Daniel > ___ > 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] nir/lower_tex: Fix the channel ordering during conversion of AYUV images
When writing this I used this page to figure the bytes' ordering : https://docs.microsoft.com/en-us/windows/desktop/medfound/recommended-8-bit-yuv-formats-for-video-rendering#ayuv Of course endianess confuses everything :( sunxi seems to support AYUV & VUYA : https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/include/video/sunxi_display2.h#L40 Finally this patch (and its gstreamer comments) confuses me even more : https://patchwork.freedesktop.org/patch/255529/ I really don't know what's right or wrong here... - Lionel On 15/01/2019 00:49, Vivek Kasireddy wrote: From: "Kasireddy, Vivek" The channel ordering should be 1230 instead of 2103. While displaying the packed YUV buffers generated by the Vivid (Virtual Video) driver on Weston, it was observed that AYUV images were not displayed correctly. Changing the ordering to 1230 makes AYUV buffers display as expected. CC: Lionel Landwerlin CC: Tapani Palli Signed-off-by: Vivek Kasireddy --- src/compiler/nir/nir_lower_tex.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c index a618b86b34c..7058c54f17c 100644 --- a/src/compiler/nir/nir_lower_tex.c +++ b/src/compiler/nir/nir_lower_tex.c @@ -434,10 +434,10 @@ lower_ayuv_external(nir_builder *b, nir_tex_instr *tex) nir_ssa_def *ayuv = sample_plane(b, tex, 0); convert_yuv_to_rgb(b, tex, - nir_channel(b, ayuv, 2), nir_channel(b, ayuv, 1), - nir_channel(b, ayuv, 0), - nir_channel(b, ayuv, 3)); + nir_channel(b, ayuv, 2), + nir_channel(b, ayuv, 3), + nir_channel(b, ayuv, 0)); } /* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] util/queue: add ability to kill a subset of threads
On Thu, Jan 3, 2019 at 3:01 PM Ian Romanick wrote:
> On 11/28/18 6:59 PM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > for ARB_parallel_shader_compile
> > ---
> > src/util/u_queue.c | 49 +-
> > src/util/u_queue.h | 5 ++---
> > 2 files changed, 33 insertions(+), 21 deletions(-)
> >
> > diff --git a/src/util/u_queue.c b/src/util/u_queue.c
> > index 48c5c79552d..5aaf60ae78e 100644
> > --- a/src/util/u_queue.c
> > +++ b/src/util/u_queue.c
> > @@ -26,42 +26,43 @@
> >
> > #include "u_queue.h"
> >
> > #include
> >
> > #include "util/os_time.h"
> > #include "util/u_string.h"
> > #include "util/u_thread.h"
> > #include "u_process.h"
> >
> > -static void util_queue_killall_and_wait(struct util_queue *queue);
> > +static void
> > +util_queue_kill_threads(struct util_queue *queue, unsigned
> keep_num_threads);
> >
> >
> /
> > * Wait for all queues to assert idle when exit() is called.
> > *
> > * Otherwise, C++ static variable destructors can be called while
> threads
> > * are using the static variables.
> > */
> >
> > static once_flag atexit_once_flag = ONCE_FLAG_INIT;
> > static struct list_head queue_list;
> > static mtx_t exit_mutex = _MTX_INITIALIZER_NP;
> >
> > static void
> > atexit_handler(void)
> > {
> > struct util_queue *iter;
> >
> > mtx_lock(_mutex);
> > /* Wait for all queues to assert idle. */
> > LIST_FOR_EACH_ENTRY(iter, _list, head) {
> > - util_queue_killall_and_wait(iter);
> > + util_queue_kill_threads(iter, 0);
> > }
> > mtx_unlock(_mutex);
> > }
> >
> > static void
> > global_init(void)
> > {
> > LIST_INITHEAD(_list);
> > atexit(atexit_handler);
> > }
> > @@ -259,55 +260,58 @@ util_queue_thread_func(void *input)
> >u_thread_setname(name);
> > }
> >
> > while (1) {
> >struct util_queue_job job;
> >
> >mtx_lock(>lock);
> >assert(queue->num_queued >= 0 && queue->num_queued <=
> queue->max_jobs);
> >
> >/* wait if the queue is empty */
> > - while (!queue->kill_threads && queue->num_queued == 0)
> > + while (thread_index < queue->num_threads && queue->num_queued ==
> 0)
> > cnd_wait(>has_queued_cond, >lock);
> >
> > - if (queue->kill_threads) {
> > + /* only kill threads that are above "num_threads" */
> > + if (thread_index >= queue->num_threads) {
> > mtx_unlock(>lock);
> > break;
> >}
> >
> >job = queue->jobs[queue->read_idx];
> >memset(>jobs[queue->read_idx], 0, sizeof(struct
> util_queue_job));
> >queue->read_idx = (queue->read_idx + 1) % queue->max_jobs;
> >
> >queue->num_queued--;
> >cnd_signal(>has_space_cond);
> >mtx_unlock(>lock);
> >
> >if (job.job) {
> > job.execute(job.job, thread_index);
> > util_queue_fence_signal(job.fence);
> > if (job.cleanup)
> > job.cleanup(job.job, thread_index);
> >}
> > }
> >
> > - /* signal remaining jobs before terminating */
> > + /* signal remaining jobs if all threads are being terminated */
> > mtx_lock(>lock);
> > - for (unsigned i = queue->read_idx; i != queue->write_idx;
> > -i = (i + 1) % queue->max_jobs) {
> > - if (queue->jobs[i].job) {
> > - util_queue_fence_signal(queue->jobs[i].fence);
> > - queue->jobs[i].job = NULL;
> > + if (queue->num_threads == 0) {
> > + for (unsigned i = queue->read_idx; i != queue->write_idx;
> > + i = (i + 1) % queue->max_jobs) {
> > + if (queue->jobs[i].job) {
> > +util_queue_fence_signal(queue->jobs[i].fence);
> > +queue->jobs[i].job = NULL;
> > + }
> >}
> > + queue->read_idx = queue->write_idx;
> > + queue->num_queued = 0;
> > }
> > - queue->read_idx = queue->write_idx;
> > - queue->num_queued = 0;
> > mtx_unlock(>lock);
> > return 0;
> > }
> >
> > static bool
> > util_queue_create_thread(struct util_queue *queue, unsigned index)
> > {
> > struct thread_input *input =
> >(struct thread_input *) malloc(sizeof(struct thread_input));
> > input->queue = queue;
> > @@ -418,60 +422,69 @@ fail:
> >cnd_destroy(>has_queued_cond);
> >mtx_destroy(>lock);
> >free(queue->jobs);
> > }
> > /* also util_queue_is_initialized can be used to check for success */
> > memset(queue, 0, sizeof(*queue));
> > return false;
> > }
> >
> > static void
> > -util_queue_killall_and_wait(struct util_queue *queue)
> > +util_queue_kill_threads(struct util_queue *queue, unsigned
> keep_num_threads)
> > {
> > unsigned i;
> >
> > /* Signal all threads to terminate. */
> > + mtx_lock(>finish_lock);
> > +
> > + if (keep_num_threads >= queue->num_threads) {
> > + mtx_unlock(>finish_lock);
> > + return;
> > + }
> > +
> >
[Mesa-dev] [PATCH] nir/lower_tex: Fix the channel ordering during conversion of AYUV images
From: "Kasireddy, Vivek" The channel ordering should be 1230 instead of 2103. While displaying the packed YUV buffers generated by the Vivid (Virtual Video) driver on Weston, it was observed that AYUV images were not displayed correctly. Changing the ordering to 1230 makes AYUV buffers display as expected. CC: Lionel Landwerlin CC: Tapani Palli Signed-off-by: Vivek Kasireddy --- src/compiler/nir/nir_lower_tex.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c index a618b86b34c..7058c54f17c 100644 --- a/src/compiler/nir/nir_lower_tex.c +++ b/src/compiler/nir/nir_lower_tex.c @@ -434,10 +434,10 @@ lower_ayuv_external(nir_builder *b, nir_tex_instr *tex) nir_ssa_def *ayuv = sample_plane(b, tex, 0); convert_yuv_to_rgb(b, tex, - nir_channel(b, ayuv, 2), nir_channel(b, ayuv, 1), - nir_channel(b, ayuv, 0), - nir_channel(b, ayuv, 3)); + nir_channel(b, ayuv, 2), + nir_channel(b, ayuv, 3), + nir_channel(b, ayuv, 0)); } /* -- 2.14.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 --- Comment #69 from Marek Olšák --- The patch shouldn't set environment variables and shouldn't change glxcmds.c. The name of the option can be more straightforward, like force_ati_vendor_string. -- 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] gallium: add pipe_grid_info::last_block
From: "Jiang, Sonny"
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| 21 +++
2 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index cbcd8e79c7b..4d844e9f4e3 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -790,32 +790,55 @@ static void si_emit_dispatch_packets(struct si_context
*sctx,
/* SI */
if (sctx->cs_max_waves_per_sh) {
unsigned limit_div16 =
DIV_ROUND_UP(sctx->cs_max_waves_per_sh, 16);
compute_resource_limits |=
S_00B854_WAVES_PER_SH_SI(limit_div16);
}
}
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) |
/* If the KMD allows it (there is a KMD hw register for it),
* allow launching waves out-of-order. (same as Vulkan) */
S_00B800_ORDER_MODE(sctx->chip_class >= CIK);
+ bool partial_block_en = info->last_block[0] ||
+ info->last_block[1] ||
+ info->last_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->last_block[0] ? info->last_block[0] :
info->block[0];
+ partial[1] = info->last_block[1] ? info->last_block[1] :
info->block[1];
+ partial[2] = info->last_block[2] ? info->last_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;
radeon_add_to_buffer_list(sctx, sctx->gfx_cs,
r600_resource(info->indirect),
RADEON_USAGE_READ, RADEON_PRIO_DRAW_INDIRECT);
radeon_emit(cs, PKT3(PKT3_SET_BASE, 2, 0) |
PKT3_SHADER_TYPE_S(1));
radeon_emit(cs, 1);
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 38052e5fd3d..0960577e61a 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -831,20 +831,41 @@ struct pipe_grid_info
* clEnqueueNDRangeKernel. Note block[] and grid[] must be padded with
* 1 for non-used dimensions.
*/
uint work_dim;
/**
* Determine the layout of the working block (in thread units) to be used.
*/
uint block[3];
+ /**
+* last_block allows disabling threads at the farthermost grid boundary.
+* Full blocks as specified by "block" are launched, but the threads
+* outside of "last_block" dimensions are disabled.
+*
+* If a block touches the grid boundary in the i-th axis, threads with
+* THREAD_ID[i] >= last_block[i] are disabled.
+*
+* If last_block[i] is 0, it has the same behavior as last_block[i] =
block[i],
+* meaning no effect.
+*
+* It's equivalent to doing this at the beginning of the compute shader:
+*
+* for (i = 0; i < 3; i++) {
+* if (block_id[i] == grid[i] - 1 &&
+* last_block[i] && last_block[i] >= thread_id[i])
+* return;
+* }
+*/
+ uint last_block[3];
+
/**
* Determine the layout of the grid (in block units) to be used.
*/
uint grid[3];
/* Indirect compute parameters resource: If not
Re: [Mesa-dev] [PATCH] radeonsi: also apply the GS hang workaround to draws without tessellation
Reviewed-by: Bas Nieuwenhuizen
On Tue, Jan 15, 2019 at 12:33 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ported from AMDVLK.
>
> Cc: 18.3
> ---
> src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++-
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index d0b2e18b4ea..dd670f3f670 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -343,34 +343,25 @@ si_get_init_multi_vgt_param(struct si_screen *sscreen,
> if (key->u.tess_uses_prim_id)
> ia_switch_on_eoi = true;
>
> /* Bug with tessellation and GS on Bonaire and older 2 SE
> chips. */
> if ((sscreen->info.family == CHIP_TAHITI ||
> sscreen->info.family == CHIP_PITCAIRN ||
> sscreen->info.family == CHIP_BONAIRE) &&
> key->u.uses_gs)
> partial_vs_wave = true;
>
> - /* Needed for 028B6C_DISTRIBUTION_MODE != 0 */
> + /* Needed for 028B6C_DISTRIBUTION_MODE != 0. (implies >= VI)
> */
> if (sscreen->has_distributed_tess) {
> if (key->u.uses_gs) {
> - if (sscreen->info.chip_class <= VI)
> + if (sscreen->info.chip_class == VI)
> partial_es_wave = true;
> -
> - /* GPU hang workaround. */
> - if (sscreen->info.family == CHIP_TONGA ||
> - sscreen->info.family == CHIP_FIJI ||
> - sscreen->info.family == CHIP_POLARIS10 ||
> - sscreen->info.family == CHIP_POLARIS11 ||
> - sscreen->info.family == CHIP_POLARIS12 ||
> - sscreen->info.family == CHIP_VEGAM)
> - partial_vs_wave = true;
> } else {
> partial_vs_wave = true;
> }
> }
> }
>
> /* This is a hardware requirement. */
> if (key->u.line_stipple_enabled ||
> (sscreen->debug_flags & DBG(SWITCH_ON_EOP))) {
> ia_switch_on_eop = true;
> @@ -412,20 +403,32 @@ si_get_init_multi_vgt_param(struct si_screen *sscreen,
> */
> if (sscreen->info.chip_class <= VI &&
> sscreen->info.max_se == 4 &&
> key->u.multi_instances_smaller_than_primgroup)
> wd_switch_on_eop = true;
>
> /* Required on CIK and later. */
> if (sscreen->info.max_se == 4 && !wd_switch_on_eop)
> ia_switch_on_eoi = true;
>
> + /* HW engineers suggested that PARTIAL_VS_WAVE_ON should be
> set
> +* to work around a GS hang.
> +*/
> + if (key->u.uses_gs &&
> + (sscreen->info.family == CHIP_TONGA ||
> +sscreen->info.family == CHIP_FIJI ||
> +sscreen->info.family == CHIP_POLARIS10 ||
> +sscreen->info.family == CHIP_POLARIS11 ||
> +sscreen->info.family == CHIP_POLARIS12 ||
> +sscreen->info.family == CHIP_VEGAM))
> + partial_vs_wave = true;
> +
> /* Required by Hawaii and, for some special cases, by VI. */
> if (ia_switch_on_eoi &&
> (sscreen->info.family == CHIP_HAWAII ||
> (sscreen->info.chip_class == VI &&
> (key->u.uses_gs || max_primgroup_in_wave != 2
> partial_vs_wave = true;
>
> /* Instancing bug on Bonaire. */
> if (sscreen->info.family == CHIP_BONAIRE && ia_switch_on_eoi
> &&
> key->u.uses_instancing)
> --
> 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] radeonsi: also apply the GS hang workaround to draws without tessellation
From: Marek Olšák
ported from AMDVLK.
Cc: 18.3
---
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++-
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index d0b2e18b4ea..dd670f3f670 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -343,34 +343,25 @@ si_get_init_multi_vgt_param(struct si_screen *sscreen,
if (key->u.tess_uses_prim_id)
ia_switch_on_eoi = true;
/* Bug with tessellation and GS on Bonaire and older 2 SE
chips. */
if ((sscreen->info.family == CHIP_TAHITI ||
sscreen->info.family == CHIP_PITCAIRN ||
sscreen->info.family == CHIP_BONAIRE) &&
key->u.uses_gs)
partial_vs_wave = true;
- /* Needed for 028B6C_DISTRIBUTION_MODE != 0 */
+ /* Needed for 028B6C_DISTRIBUTION_MODE != 0. (implies >= VI) */
if (sscreen->has_distributed_tess) {
if (key->u.uses_gs) {
- if (sscreen->info.chip_class <= VI)
+ if (sscreen->info.chip_class == VI)
partial_es_wave = true;
-
- /* GPU hang workaround. */
- if (sscreen->info.family == CHIP_TONGA ||
- sscreen->info.family == CHIP_FIJI ||
- sscreen->info.family == CHIP_POLARIS10 ||
- sscreen->info.family == CHIP_POLARIS11 ||
- sscreen->info.family == CHIP_POLARIS12 ||
- sscreen->info.family == CHIP_VEGAM)
- partial_vs_wave = true;
} else {
partial_vs_wave = true;
}
}
}
/* This is a hardware requirement. */
if (key->u.line_stipple_enabled ||
(sscreen->debug_flags & DBG(SWITCH_ON_EOP))) {
ia_switch_on_eop = true;
@@ -412,20 +403,32 @@ si_get_init_multi_vgt_param(struct si_screen *sscreen,
*/
if (sscreen->info.chip_class <= VI &&
sscreen->info.max_se == 4 &&
key->u.multi_instances_smaller_than_primgroup)
wd_switch_on_eop = true;
/* Required on CIK and later. */
if (sscreen->info.max_se == 4 && !wd_switch_on_eop)
ia_switch_on_eoi = true;
+ /* HW engineers suggested that PARTIAL_VS_WAVE_ON should be set
+* to work around a GS hang.
+*/
+ if (key->u.uses_gs &&
+ (sscreen->info.family == CHIP_TONGA ||
+sscreen->info.family == CHIP_FIJI ||
+sscreen->info.family == CHIP_POLARIS10 ||
+sscreen->info.family == CHIP_POLARIS11 ||
+sscreen->info.family == CHIP_POLARIS12 ||
+sscreen->info.family == CHIP_VEGAM))
+ partial_vs_wave = true;
+
/* Required by Hawaii and, for some special cases, by VI. */
if (ia_switch_on_eoi &&
(sscreen->info.family == CHIP_HAWAII ||
(sscreen->info.chip_class == VI &&
(key->u.uses_gs || max_primgroup_in_wave != 2
partial_vs_wave = true;
/* Instancing bug on Bonaire. */
if (sscreen->info.family == CHIP_BONAIRE && ia_switch_on_eoi &&
key->u.uses_instancing)
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [MR] Fix SWR compilation issues with meson
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/113 signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 --- Comment #68 from Axel Davy --- Shmerl: driconf vars can be overriden with env vars (of the same name). If the driconf option is a string, thus any user could change the vendor string with an env var. -- 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 v3 3/3] egl: add config debug printout (v3)
e aOn Fri, 11 Jan 2019 at 16:34, 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.
> v3:
>remove unnecessary 'const' qualifiers from the function prototype
>
> Signed-off-by: Silvestrs Timofejevs
> Reviewed-by: Eric Engestrom
> ---
> 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"
>
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 --- Comment #67 from Shmerl --- Actual override value shouldn't be hardcoded and probably should be passed through environment variable. -- 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 v3 2/3] egl: introduce a log level getter function
On Mon, 14 Jan 2019 at 18:20, Emil Velikov wrote:
>
> On 2019/01/11, Silvestrs Timofejevs wrote:
> > Being able to retrieve the log level can be useful to enable/disable
> > debug code. The alternative, which is calling 'getenv' function every
> > time to retrieve the log level, is more "expensive".
> >
> > Signed-off-by: Silvestrs Timofejevs
> > Reviewed-by: Eric Engestrom
> > ---
> > src/egl/main/egllog.c | 9 +
> > src/egl/main/egllog.h | 4
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/src/egl/main/egllog.c b/src/egl/main/egllog.c
> > index c223f49..42bae01 100644
> > --- a/src/egl/main/egllog.c
> > +++ b/src/egl/main/egllog.c
> > @@ -133,6 +133,15 @@ _eglInitLogger(void)
> > }
> > }
> >
> > +/**
> > + * Return the log level.
> > + */
> > +EGLint
> > +_eglGetLogLevel(void)
> > +{
> > + return logging.level;
> > +}
> > +
> Any particular reason why are not using _eglLog()? It does not log level
> and VA handling for us.
>
Right, _eglLog is being used... silly me. I've got confused by the
mention of getenv and expensive.
Currently the getenv() call is a once-off thing.
I'd imagine when this work originates, when that wasn't the case.
Hence we no longer need this micro optimisation?
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] ac: add missing 16-bit types to glsl_base_to_llvm_type()
On Mon, Jan 14, 2019 at 5:55 PM Samuel Pitoiset wrote: > > Fix crashes with > dEQP-VK.spirv_assembly.instruction.compute.workgroup_memory.*16 > > v2: - add INT16/UINT16 too > - update commit description > > Signed-off-by: Samuel Pitoiset > Reviewed-by: Bas Nieuwenhuizen (v1) > --- > src/amd/common/ac_nir_to_llvm.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c > index 5023b96f92d..f9a3c171b1d 100644 > --- a/src/amd/common/ac_nir_to_llvm.c > +++ b/src/amd/common/ac_nir_to_llvm.c > @@ -3902,8 +3902,13 @@ glsl_base_to_llvm_type(struct ac_llvm_context *ac, > case GLSL_TYPE_BOOL: > case GLSL_TYPE_SUBROUTINE: > return ac->i32; > + case GLSL_TYPE_INT16: > + case GLSL_TYPE_UINT16: > + return ac->i16; > case GLSL_TYPE_FLOAT: /* TODO handle mediump */ Remove the TODO while you're at it? Either way, r-b. > return ac->f32; > + case GLSL_TYPE_FLOAT16: > + return ac->f16; > case GLSL_TYPE_INT64: > case GLSL_TYPE_UINT64: > return ac->i64; > -- > 2.20.1 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa git break nvidia opencl
Hi, I don't know what "mesa card" means. You mentioned nvidia GPU, if you want to use nvidia binary drivers, you can't use mesa provided libOpenCL.so. The output you posted looks like you're trying to use mesa to load other ICD drivers, that won't work. This is not a change in git. Unless you have a recent AMD GPU you shouldn't build opencl, or at least configure with --enable-opencl- icd. Jan On Sun, 2019-01-13 at 15:22 +0100, andreas.benz...@googlemail.com wrote: > Hello Jan, > > clinfo shows a little bit of opencl info while no "mesa" card is with > the machine. > > That's wrong: > > flatpak --command=/bin/bash run online.winehub.GPUViewer > > clinfo > Number of platforms 1 > Platform Name Clover > Platform Vendor Mesa > Platform VersionOpenCL 1.1 Mesa > 18.3.1 > Platform ProfileFULL_PROFILE > Platform Extensions cl_khr_icd > Platform Extensions function suffix MESA > > Platform Name Clover > Number of devices 0 > > NULL platform behavior > clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) Clover > clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) > clCreateContext(NULL, ...) [default]No devices found in > platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices > found in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found > in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found > in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices > found in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices > found in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No devices found > in platform > > ICD loader properties > ICD loader Name OpenCL ICD Loader > ICD loader Vendor OCL Icd free software > ICD loader Version 2.2.12 > ICD loader Profile OpenCL 2.2 > > AndyBe > Am Samstag, den 12.01.2019, 16:39 -0500 schrieb Jan Vesely: > > Hi, > > > > you're not very specific what 'break' means. Mesa libOpenCL.so does > > not support loading additional opencl icd drivers. > > It is, however, possible to use mesa as an icd driver > > (libMesaOpenCL.so) which can be loaded by an icd loader, such as ocl- > > icd, or other opencl drivers. > > > > Jan > > > > > > On Thu, 2019-01-10 at 19:58 +0100, andreas.benz...@googlemail.com > > wrote: > > > Hello Everyone, > > > > > > at this moment I develop on freedesktop opencl. Current the mesa > > > opencl > > > break clinfo to read the information from nvidia when mesa opencl > > > is > > > available. There is no other graphic card plugged in. > > > > > > The stable 18.3.1 it works. > > > > > > Don't know how to analise this kind of problem. > > > > > > Sincerely > > > > > > AndyBe > > > > > > ___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Jan Vesely 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 v3 2/3] egl: introduce a log level getter function
On 2019/01/11, Silvestrs Timofejevs wrote:
> Being able to retrieve the log level can be useful to enable/disable
> debug code. The alternative, which is calling 'getenv' function every
> time to retrieve the log level, is more "expensive".
>
> Signed-off-by: Silvestrs Timofejevs
> Reviewed-by: Eric Engestrom
> ---
> src/egl/main/egllog.c | 9 +
> src/egl/main/egllog.h | 4
> 2 files changed, 13 insertions(+)
>
> diff --git a/src/egl/main/egllog.c b/src/egl/main/egllog.c
> index c223f49..42bae01 100644
> --- a/src/egl/main/egllog.c
> +++ b/src/egl/main/egllog.c
> @@ -133,6 +133,15 @@ _eglInitLogger(void)
> }
> }
>
> +/**
> + * Return the log level.
> + */
> +EGLint
> +_eglGetLogLevel(void)
> +{
> + return logging.level;
> +}
> +
Any particular reason why are not using _eglLog()? It does not log level
and VA handling for us.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/3] util: introduce the util_strnappend function (v2)
On 2019/01/11, Silvestrs Timofejevs wrote: > This function is similar to strncat, but unlike strncat it allows to > concatenate the buffer with a formatted string. The alternative would > be to have an intermediate string that is formated first, and then > appended via strncat. > Personally I'd go with the alternative solution. The user isn't a hot path by any means, plus it does a reasonable amount of strncat already. What do you think? Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] debug feature to dump "get configs" and "chosen configs" (v3)
Hi Silvestrs, On 2019/01/11, Timofejevs wrote: > This patch series provides an easy way to see what configs > have been returned by the 'eglGetConfigs' and 'eglChooseConfig' > functions, and give an overview of config attributes. I can see how this would be useful, although the current approach does seem a bit over engineered? Concrete points coming shortly. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
Quoting Axel Davy (2019-01-12 09:40:40) > Hi, > > I'm not sure the promise "1 mail per pull request" is working well. > For example, taking one recent pull request > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/105 > > I didn't receive anything, nor > https://lists.freedesktop.org/archives/mesa-dev/2019-January/thread.html > yet. > > I received some mails with [MR] in the title with two lines indicating merge > requests, but that seems to be for a minority of the requests. > > I guess the system is not automated right now. > > I think there needs to be an automated system, and that it should look pretty > close to what a cover-letter for a mail serie should look like, that is: > . The global stat diffs of the merge requests (which files are affected, how > many modifications, etc) > . The summary of the request > . All the patch titles > > I don't want to go open all merge requests in my browser to get that > information. > So far I only went check the list of gitlab merge requests 3 times, whereas I > go through my mails several times a day. > > > Yours, > > Axel Davy > > > > > On 11/01/2019 17:57, Jason Ekstrand wrote: > > All, > > The mesa project has now hit 100 merge requests (36 are still open). I > (and I'm sure others) would be curious to hear people's initial thoughts > on > the process. What's working well? What's not working? Is it total fail > and should we go back to mailing lists? > > --Jason > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > Another option, which I find much better, is to just subscribe to the MRs for all of mesa in gitlab. I've then set up my mail client to sort all of those mails and all of mesa-dev into the view so there is zero gap between the mailing list and gitlab. 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] Thoughts after hitting 100 merge requests?
On Mon, Jan 14, 2019 at 12:36:26PM +, Daniel Stone wrote: > FWIW, if you go to > https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a > hyperlink from the web UI which points you to the MR. The API to do > this is pretty straightforward and amenable to piping through jq: > https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit That works great and solves one of the issues I had. Thanks! Caio ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: avoid context rolls when binding graphics pipelines
Sure
On Mon, 14 Jan 2019 at 16:50, Samuel Pitoiset wrote:
>
> While you are on it, can you experiment the tracked ctx stuff that
> RadeonSI implements (ie. SI_TRACKED_XXX)?
>
> This approach will likely be more costly from the CPU side, but it will
> reduce the number of register changes a lot more.
>
> Not sure if that will improve anything though, but I think it's worth to
> try?
>
> On 1/14/19 5:12 PM, Rhys Perry wrote:
> > I did and found small improvements in Rise of the Tomb Raider. I
> > measured framerates ~104.3% that of without the changes for the
> > Geothermal Valley scene, ~101.2% for Spine of the Mountain and ~102.3%
> > for Prophets Tomb.
> >
> > I found no change with Dota 2 but I've heard it's cpu-bound.
> >
> > On Mon, 14 Jan 2019 at 16:05, Samuel Pitoiset
> > wrote:
> >> Did you benchmark?
> >>
> >> On 1/14/19 5:01 PM, Rhys Perry wrote:
> >>> It's common in some applications to bind a new graphics pipeline without
> >>> ending up changing any context registers.
> >>>
> >>> This has a pipline have two command buffers: one for setting context
> >>> registers and one for everything else. The context register command buffer
> >>> is only emitted if it differs from the previous pipeline's.
> >>>
> >>> Signed-off-by: Rhys Perry
> >>> ---
> >>>src/amd/vulkan/radv_cmd_buffer.c | 46 +--
> >>>src/amd/vulkan/radv_pipeline.c | 217 ---
> >>>src/amd/vulkan/radv_private.h| 2 +
> >>>3 files changed, 150 insertions(+), 115 deletions(-)
> >>>
> >>> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> >>> b/src/amd/vulkan/radv_cmd_buffer.c
> >>> index f41d6c0b3e7..59903ab64d8 100644
> >>> --- a/src/amd/vulkan/radv_cmd_buffer.c
> >>> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> >>> @@ -634,7 +634,7 @@ radv_emit_descriptor_pointers(struct radv_cmd_buffer
> >>> *cmd_buffer,
> >>>}
> >>>}
> >>>
> >>> -static void
> >>> +static bool
> >>>radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer,
> >>> struct radv_pipeline *pipeline)
> >>>{
> >>> @@ -646,7 +646,7 @@ radv_update_multisample_state(struct radv_cmd_buffer
> >>> *cmd_buffer,
> >>>cmd_buffer->sample_positions_needed = true;
> >>>
> >>>if (old_pipeline && num_samples ==
> >>> old_pipeline->graphics.ms.num_samples)
> >>> - return;
> >>> + return false;
> >>>
> >>>radeon_set_context_reg_seq(cmd_buffer->cs,
> >>> R_028BDC_PA_SC_LINE_CNTL, 2);
> >>>radeon_emit(cmd_buffer->cs, ms->pa_sc_line_cntl);
> >>> @@ -661,6 +661,8 @@ radv_update_multisample_state(struct radv_cmd_buffer
> >>> *cmd_buffer,
> >>>radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
> >>>radeon_emit(cmd_buffer->cs,
> >>> EVENT_TYPE(V_028A90_FLUSH_DFSM) | EVENT_INDEX(0));
> >>>}
> >>> +
> >>> + return true;
> >>>}
> >>>
> >>>static void
> >>> @@ -863,15 +865,15 @@ radv_emit_rbplus_state(struct radv_cmd_buffer
> >>> *cmd_buffer)
> >>>radeon_emit(cmd_buffer->cs, sx_blend_opt_control);
> >>>}
> >>>
> >>> -static void
> >>> +static bool
> >>>radv_emit_graphics_pipeline(struct radv_cmd_buffer *cmd_buffer)
> >>>{
> >>>struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
> >>>
> >>>if (!pipeline || cmd_buffer->state.emitted_pipeline == pipeline)
> >>> - return;
> >>> + return false;
> >>>
> >>> - radv_update_multisample_state(cmd_buffer, pipeline);
> >>> + bool context_roll = radv_update_multisample_state(cmd_buffer,
> >>> pipeline);
> >>>
> >>>cmd_buffer->scratch_size_needed =
> >>> MAX2(cmd_buffer->scratch_size_needed,
> >>> @@ -884,6 +886,15 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> >>> *cmd_buffer)
> >>>
> >>>radeon_emit_array(cmd_buffer->cs, pipeline->cs.buf,
> >>> pipeline->cs.cdw);
> >>>
> >>> + if (!cmd_buffer->state.emitted_pipeline ||
> >>> + cmd_buffer->state.emitted_pipeline->ctx_cs.cdw !=
> >>> pipeline->ctx_cs.cdw ||
> >>> + cmd_buffer->state.emitted_pipeline->ctx_cs_hash !=
> >>> pipeline->ctx_cs_hash ||
> >>> + memcmp(cmd_buffer->state.emitted_pipeline->ctx_cs.buf,
> >>> +pipeline->ctx_cs.buf, pipeline->ctx_cs.cdw * 4)) {
> >>> + radeon_emit_array(cmd_buffer->cs, pipeline->ctx_cs.buf,
> >>> pipeline->ctx_cs.cdw);
> >>> + context_roll = true;
> >>> + }
> >>> +
> >>>for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
> >>>if (!pipeline->shaders[i])
> >>>continue;
> >>> @@ -902,6 +913,8 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> >>> *cmd_buffer)
> >>>cmd_buffer->state.emitted_pipeline = pipeline;
> >>>
> >>>cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_PIPELINE;
> >>> +
> >>> + return context_roll;
> >>>}
> >>>
> >>>static void
> >>> @@ -2859,6
Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks
On Fri, 2019-01-11 at 15:01 +, Emil Velikov wrote: > > @@ -460,6 +464,14 @@ driGetConfigAttribIndex(const __DRIconfig *config, > > else > > *value = 0; > > break; > > +case __DRI_ATTRIB_RED_MASK_HI: > > +case __DRI_ATTRIB_GREEN_MASK_HI: > > +case __DRI_ATTRIB_BLUE_MASK_HI: > > +case __DRI_ATTRIB_ALPHA_MASK_HI: > > +/* upper 32 bits of 64 bit fields */ > > +*value = *(unsigned int *) > > +((char *) >modes + attribMap[index].offset + 4); > > Is the "+ 4" going to work on big endian systems? No. I think I'd prefer to just expand config attribute values to 64-bit across the board internally, rather than have paired 32-bit attributes like this. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109354] eglCreateImageKHR should throw a error when called with anything but EGL_NO_CONTEXT
https://bugs.freedesktop.org/show_bug.cgi?id=109354 --- Comment #1 from Daniel Stone --- Same for dmabuf import: https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt Mutter used to pass a context though, so we should only do this with care. -- 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] ac: add missing 16-bit types to glsl_base_to_llvm_type()
Fix crashes with dEQP-VK.spirv_assembly.instruction.compute.workgroup_memory.*16 v2: - add INT16/UINT16 too - update commit description Signed-off-by: Samuel Pitoiset Reviewed-by: Bas Nieuwenhuizen (v1) --- src/amd/common/ac_nir_to_llvm.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 5023b96f92d..f9a3c171b1d 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -3902,8 +3902,13 @@ glsl_base_to_llvm_type(struct ac_llvm_context *ac, case GLSL_TYPE_BOOL: case GLSL_TYPE_SUBROUTINE: return ac->i32; + case GLSL_TYPE_INT16: + case GLSL_TYPE_UINT16: + return ac->i16; case GLSL_TYPE_FLOAT: /* TODO handle mediump */ return ac->f32; + case GLSL_TYPE_FLOAT16: + return ac->f16; case GLSL_TYPE_INT64: case GLSL_TYPE_UINT64: return ac->i64; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: avoid context rolls when binding graphics pipelines
While you are on it, can you experiment the tracked ctx stuff that
RadeonSI implements (ie. SI_TRACKED_XXX)?
This approach will likely be more costly from the CPU side, but it will
reduce the number of register changes a lot more.
Not sure if that will improve anything though, but I think it's worth to
try?
On 1/14/19 5:12 PM, Rhys Perry wrote:
I did and found small improvements in Rise of the Tomb Raider. I
measured framerates ~104.3% that of without the changes for the
Geothermal Valley scene, ~101.2% for Spine of the Mountain and ~102.3%
for Prophets Tomb.
I found no change with Dota 2 but I've heard it's cpu-bound.
On Mon, 14 Jan 2019 at 16:05, Samuel Pitoiset wrote:
Did you benchmark?
On 1/14/19 5:01 PM, Rhys Perry wrote:
It's common in some applications to bind a new graphics pipeline without
ending up changing any context registers.
This has a pipline have two command buffers: one for setting context
registers and one for everything else. The context register command buffer
is only emitted if it differs from the previous pipeline's.
Signed-off-by: Rhys Perry
---
src/amd/vulkan/radv_cmd_buffer.c | 46 +--
src/amd/vulkan/radv_pipeline.c | 217 ---
src/amd/vulkan/radv_private.h| 2 +
3 files changed, 150 insertions(+), 115 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f41d6c0b3e7..59903ab64d8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -634,7 +634,7 @@ radv_emit_descriptor_pointers(struct radv_cmd_buffer
*cmd_buffer,
}
}
-static void
+static bool
radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer,
struct radv_pipeline *pipeline)
{
@@ -646,7 +646,7 @@ radv_update_multisample_state(struct radv_cmd_buffer
*cmd_buffer,
cmd_buffer->sample_positions_needed = true;
if (old_pipeline && num_samples == old_pipeline->graphics.ms.num_samples)
- return;
+ return false;
radeon_set_context_reg_seq(cmd_buffer->cs, R_028BDC_PA_SC_LINE_CNTL, 2);
radeon_emit(cmd_buffer->cs, ms->pa_sc_line_cntl);
@@ -661,6 +661,8 @@ radv_update_multisample_state(struct radv_cmd_buffer
*cmd_buffer,
radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) |
EVENT_INDEX(0));
}
+
+ return true;
}
static void
@@ -863,15 +865,15 @@ radv_emit_rbplus_state(struct radv_cmd_buffer *cmd_buffer)
radeon_emit(cmd_buffer->cs, sx_blend_opt_control);
}
-static void
+static bool
radv_emit_graphics_pipeline(struct radv_cmd_buffer *cmd_buffer)
{
struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
if (!pipeline || cmd_buffer->state.emitted_pipeline == pipeline)
- return;
+ return false;
- radv_update_multisample_state(cmd_buffer, pipeline);
+ bool context_roll = radv_update_multisample_state(cmd_buffer, pipeline);
cmd_buffer->scratch_size_needed =
MAX2(cmd_buffer->scratch_size_needed,
@@ -884,6 +886,15 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
*cmd_buffer)
radeon_emit_array(cmd_buffer->cs, pipeline->cs.buf, pipeline->cs.cdw);
+ if (!cmd_buffer->state.emitted_pipeline ||
+ cmd_buffer->state.emitted_pipeline->ctx_cs.cdw !=
pipeline->ctx_cs.cdw ||
+ cmd_buffer->state.emitted_pipeline->ctx_cs_hash !=
pipeline->ctx_cs_hash ||
+ memcmp(cmd_buffer->state.emitted_pipeline->ctx_cs.buf,
+pipeline->ctx_cs.buf, pipeline->ctx_cs.cdw * 4)) {
+ radeon_emit_array(cmd_buffer->cs, pipeline->ctx_cs.buf,
pipeline->ctx_cs.cdw);
+ context_roll = true;
+ }
+
for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
if (!pipeline->shaders[i])
continue;
@@ -902,6 +913,8 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
*cmd_buffer)
cmd_buffer->state.emitted_pipeline = pipeline;
cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_PIPELINE;
+
+ return context_roll;
}
static void
@@ -2859,6 +2872,8 @@ radv_emit_compute_pipeline(struct radv_cmd_buffer
*cmd_buffer)
if (!pipeline || pipeline == cmd_buffer->state.emitted_compute_pipeline)
return;
+ assert(!pipeline->ctx_cs.cdw);
+
cmd_buffer->state.emitted_compute_pipeline = pipeline;
radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs,
pipeline->cs.cdw);
@@ -3609,30 +3624,30 @@ radv_emit_draw_packets(struct radv_cmd_buffer
*cmd_buffer,
* any context registers.
*/
static bool radv_need_late_scissor_emission(struct radv_cmd_buffer
*cmd_buffer,
-bool indexed_draw)
+bool indexed_draw,
+
Re: [Mesa-dev] [PATCH 0/8] i965: improved the support for ETC2 formats on Gen 7
On Mon, 19 Nov 2018 10:54:04 +0200 Eleni Maria Stea wrote: > Intel Gen7 GPUs don't have native support for ETC2 formats. We store > the ETC2 images as RGBA in order to render them. This is a problem for > GetCompressed* functions that should return compressed pixel values > but return instead RGBA. > [...] Hi Nanley and Kenneth, It's been a while I've sent these ETC2-related patches and I was wondering if you could get a look when you have some time available. I've also written a test to check the compressed cubemaps rendering (we already had tests for the Get functions, and compressed mipmaps, so this case was the only one missing). The patch is here (compressed-cubemap test): https://patchwork.freedesktop.org/series/54880/ While working on the test I found an issue with TexImage2D and some other compressed formats (like BPTC), and I wrote another test (included in the same patch) that points it out (see the cover letter). Another problem I hit while working on the cubemap test is described here (I found it by calling glViewport with invalid values accidentally): https://bugs.freedesktop.org/show_bug.cgi?id=108999 I've sent a small patch for it, but so far there was no reply: https://patchwork.freedesktop.org/patch/267292/ I'd really appreciate it if you could take some time to look at these 3 issues. Thank you very much in advance, Eleni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] anv: Implement VK_KHR_depth_stencil_resolve
On Mon, Jan 14, 2019 at 1:16 AM Iago Toral wrote:
> On Fri, 2019-01-11 at 12:31 -0600, Jason Ekstrand wrote:
>
>
> On Fri, Jan 11, 2019 at 3:21 AM Iago Toral wrote:
>
> On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/anv_device.c | 28 ++
> > src/intel/vulkan/anv_extensions.py | 1 +
> > src/intel/vulkan/anv_pass.c| 37 +++-
> > src/intel/vulkan/anv_private.h | 3 +
> > src/intel/vulkan/genX_cmd_buffer.c | 136
> > +
> > 5 files changed, 204 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> > b/src/intel/vulkan/anv_device.c
> > index 2a3919d2949..3761846bb7f 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -1138,6 +1138,34 @@ void anv_GetPhysicalDeviceProperties2(
> > break;
> >}
> >
> > + case
> > VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KH
> > R: {
> > + VkPhysicalDeviceDepthStencilResolvePropertiesKHR *props =
> > +(VkPhysicalDeviceDepthStencilResolvePropertiesKHR *)ext;
> > +
> > + /* We support all of the depth resolve modes */
> > + props->supportedDepthResolveModes =
> > +VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR |
> > +VK_RESOLVE_MODE_AVERAGE_BIT_KHR |
> > +VK_RESOLVE_MODE_MIN_BIT_KHR |
> > +VK_RESOLVE_MODE_MAX_BIT_KHR;
> > +
> > + /* Average doesn't make sense for stencil so we don't
> > support that */
> > + props->supportedStencilResolveModes =
> > +VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR;
> > + if (pdevice->info.gen >= 8) {
> > +/* The advanced stencil resolve modes currently require
> > stencil
> > + * sampling be supported by the hardware.
> > + */
> > +props->supportedStencilResolveModes |=
> > + VK_RESOLVE_MODE_MIN_BIT_KHR |
> > + VK_RESOLVE_MODE_MAX_BIT_KHR;
> > + }
> > +
> > + props->independentResolveNone = VK_TRUE;
> > + props->independentResolve = VK_TRUE;
> > + break;
> > + }
> > +
> >case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR:
> > {
> > VkPhysicalDeviceDriverPropertiesKHR *driver_props =
> > (VkPhysicalDeviceDriverPropertiesKHR *) ext;
> > diff --git a/src/intel/vulkan/anv_extensions.py
> > b/src/intel/vulkan/anv_extensions.py
> > index 388845003aa..2ea4cab0e97 100644
> > --- a/src/intel/vulkan/anv_extensions.py
> > +++ b/src/intel/vulkan/anv_extensions.py
> > @@ -76,6 +76,7 @@ EXTENSIONS = [
> > Extension('VK_KHR_bind_memory2', 1, True),
> > Extension('VK_KHR_create_renderpass2',1, True),
> > Extension('VK_KHR_dedicated_allocation', 1, True),
> > +Extension('VK_KHR_depth_stencil_resolve', 1, True),
> > Extension('VK_KHR_descriptor_update_template',1, True),
> > Extension('VK_KHR_device_group', 1, True),
> > Extension('VK_KHR_device_group_creation', 1, True),
> > diff --git a/src/intel/vulkan/anv_pass.c
> > b/src/intel/vulkan/anv_pass.c
> > index 7b17cc06935..196cf3ff8fd 100644
> > --- a/src/intel/vulkan/anv_pass.c
> > +++ b/src/intel/vulkan/anv_pass.c
> > @@ -74,6 +74,10 @@ anv_render_pass_compile(struct anv_render_pass
> > *pass)
> >subpass->depth_stencil_attachment->attachment ==
> > VK_ATTACHMENT_UNUSED)
> > subpass->depth_stencil_attachment = NULL;
> >
> > + if (subpass->ds_resolve_attachment &&
> > + subpass->ds_resolve_attachment->attachment ==
> > VK_ATTACHMENT_UNUSED)
> > + subpass->ds_resolve_attachment = NULL;
> > +
>
> This is a nitpick, but since we setup subpass->ds_resolve_attachment in
> anv_CreateRenderPass2KHR(), should't we just do this sanitation there?
>
>
> Maybe? It's an interesting philosophical question. The original idea
> behind the compile step was to make stuff like this unified between the two
> create paths. That said, this only happens in the CreateRenderPass2KHR
> path so should it go there? I don't know. I'm inclined to leave it as-is
> if that's ok.
>
>
> Sure, that's fine.
>
> >for (uint32_t j = 0; j < subpass->attachment_count; j++) {
> > struct anv_subpass_attachment *subpass_att =
> > >attachments[j];
> > if (subpass_att->attachment == VK_ATTACHMENT_UNUSED)
> > @@ -116,6 +120,16 @@ anv_render_pass_compile(struct anv_render_pass
> > *pass)
> > color_att->usage |= VK_IMAGE_USAGE_TRANSFER_SRC_BIT;
> > }
> >}
> > +
> > + if (subpass->ds_resolve_attachment) {
> > + struct anv_subpass_attachment *ds_att =
> > +subpass->depth_stencil_attachment;
> > + UNUSED struct anv_subpass_attachment *resolve_att =
> > +subpass->ds_resolve_attachment;
> > +
> > +
Re: [Mesa-dev] [PATCH] radv: avoid context rolls when binding graphics pipelines
This is with Rise of the Tomb Raider's graphics settings set to "High"
by the way.
On Mon, 14 Jan 2019 at 16:12, Rhys Perry wrote:
>
> I did and found small improvements in Rise of the Tomb Raider. I
> measured framerates ~104.3% that of without the changes for the
> Geothermal Valley scene, ~101.2% for Spine of the Mountain and ~102.3%
> for Prophets Tomb.
>
> I found no change with Dota 2 but I've heard it's cpu-bound.
>
> On Mon, 14 Jan 2019 at 16:05, Samuel Pitoiset
> wrote:
> >
> > Did you benchmark?
> >
> > On 1/14/19 5:01 PM, Rhys Perry wrote:
> > > It's common in some applications to bind a new graphics pipeline without
> > > ending up changing any context registers.
> > >
> > > This has a pipline have two command buffers: one for setting context
> > > registers and one for everything else. The context register command buffer
> > > is only emitted if it differs from the previous pipeline's.
> > >
> > > Signed-off-by: Rhys Perry
> > > ---
> > > src/amd/vulkan/radv_cmd_buffer.c | 46 +--
> > > src/amd/vulkan/radv_pipeline.c | 217 ---
> > > src/amd/vulkan/radv_private.h| 2 +
> > > 3 files changed, 150 insertions(+), 115 deletions(-)
> > >
> > > diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> > > b/src/amd/vulkan/radv_cmd_buffer.c
> > > index f41d6c0b3e7..59903ab64d8 100644
> > > --- a/src/amd/vulkan/radv_cmd_buffer.c
> > > +++ b/src/amd/vulkan/radv_cmd_buffer.c
> > > @@ -634,7 +634,7 @@ radv_emit_descriptor_pointers(struct radv_cmd_buffer
> > > *cmd_buffer,
> > > }
> > > }
> > >
> > > -static void
> > > +static bool
> > > radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer,
> > > struct radv_pipeline *pipeline)
> > > {
> > > @@ -646,7 +646,7 @@ radv_update_multisample_state(struct radv_cmd_buffer
> > > *cmd_buffer,
> > > cmd_buffer->sample_positions_needed = true;
> > >
> > > if (old_pipeline && num_samples ==
> > > old_pipeline->graphics.ms.num_samples)
> > > - return;
> > > + return false;
> > >
> > > radeon_set_context_reg_seq(cmd_buffer->cs,
> > > R_028BDC_PA_SC_LINE_CNTL, 2);
> > > radeon_emit(cmd_buffer->cs, ms->pa_sc_line_cntl);
> > > @@ -661,6 +661,8 @@ radv_update_multisample_state(struct radv_cmd_buffer
> > > *cmd_buffer,
> > > radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
> > > radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM)
> > > | EVENT_INDEX(0));
> > > }
> > > +
> > > + return true;
> > > }
> > >
> > > static void
> > > @@ -863,15 +865,15 @@ radv_emit_rbplus_state(struct radv_cmd_buffer
> > > *cmd_buffer)
> > > radeon_emit(cmd_buffer->cs, sx_blend_opt_control);
> > > }
> > >
> > > -static void
> > > +static bool
> > > radv_emit_graphics_pipeline(struct radv_cmd_buffer *cmd_buffer)
> > > {
> > > struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
> > >
> > > if (!pipeline || cmd_buffer->state.emitted_pipeline == pipeline)
> > > - return;
> > > + return false;
> > >
> > > - radv_update_multisample_state(cmd_buffer, pipeline);
> > > + bool context_roll = radv_update_multisample_state(cmd_buffer,
> > > pipeline);
> > >
> > > cmd_buffer->scratch_size_needed =
> > > MAX2(cmd_buffer->scratch_size_needed,
> > > @@ -884,6 +886,15 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> > > *cmd_buffer)
> > >
> > > radeon_emit_array(cmd_buffer->cs, pipeline->cs.buf,
> > > pipeline->cs.cdw);
> > >
> > > + if (!cmd_buffer->state.emitted_pipeline ||
> > > + cmd_buffer->state.emitted_pipeline->ctx_cs.cdw !=
> > > pipeline->ctx_cs.cdw ||
> > > + cmd_buffer->state.emitted_pipeline->ctx_cs_hash !=
> > > pipeline->ctx_cs_hash ||
> > > + memcmp(cmd_buffer->state.emitted_pipeline->ctx_cs.buf,
> > > +pipeline->ctx_cs.buf, pipeline->ctx_cs.cdw * 4)) {
> > > + radeon_emit_array(cmd_buffer->cs, pipeline->ctx_cs.buf,
> > > pipeline->ctx_cs.cdw);
> > > + context_roll = true;
> > > + }
> > > +
> > > for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
> > > if (!pipeline->shaders[i])
> > > continue;
> > > @@ -902,6 +913,8 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> > > *cmd_buffer)
> > > cmd_buffer->state.emitted_pipeline = pipeline;
> > >
> > > cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_PIPELINE;
> > > +
> > > + return context_roll;
> > > }
> > >
> > > static void
> > > @@ -2859,6 +2872,8 @@ radv_emit_compute_pipeline(struct radv_cmd_buffer
> > > *cmd_buffer)
> > > if (!pipeline || pipeline ==
> > > cmd_buffer->state.emitted_compute_pipeline)
> > > return;
> > >
> > > + assert(!pipeline->ctx_cs.cdw);
> > > +
> > > cmd_buffer->state.emitted_compute_pipeline = pipeline;
> > >
> > >
[Mesa-dev] [Bug 109354] eglCreateImageKHR should throw a error when called with anything but EGL_NO_CONTEXT
https://bugs.freedesktop.org/show_bug.cgi?id=109354 Bug ID: 109354 Summary: eglCreateImageKHR should throw a error when called with anything but EGL_NO_CONTEXT Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: EGL Assignee: mesa-dev@lists.freedesktop.org Reporter: ro...@garg.io QA Contact: mesa-dev@lists.freedesktop.org Calling eglCreateImageKHR with anything but EGL_NO_CONTEXT should throw a error. From https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_image_pixmap.txt * If is EGL_NATIVE_PIXMAP_KHR, and is not EGL_NO_CONTEXT, the error EGL_BAD_PARAMETER is generated. Xorg has recently been fixed to incorporate this : https://gitlab.freedesktop.org/xorg/xserver/commit/cc05c01925755310f027c61daa29648a10155f96 -- 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 6/6] ac: use llvm.amdgcn.s.buffer.load
Yes, I'll remove this patch.
Marek
On Sun, Jan 13, 2019 at 10:17 AM Bas Nieuwenhuizen
wrote:
> I think this is done with
>
> https://patchwork.freedesktop.org/series/55025/
>
> ?
>
> On Sat, Jan 12, 2019 at 12:53 AM Marek Olšák wrote:
> >
> > From: Marek Olšák
> >
> > ---
> > src/amd/common/ac_llvm_build.c | 18 +-
> > .../drivers/radeonsi/si_shader_tgsi_mem.c | 4 ++--
> > 2 files changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/amd/common/ac_llvm_build.c
> b/src/amd/common/ac_llvm_build.c
> > index 76047148a6a..c0d90ada2be 100644
> > --- a/src/amd/common/ac_llvm_build.c
> > +++ b/src/amd/common/ac_llvm_build.c
> > @@ -1234,25 +1234,33 @@ ac_build_buffer_load(struct ac_llvm_context *ctx,
> > if (allow_smem && !glc && !slc) {
> > assert(vindex == NULL);
> >
> > LLVMValueRef result[8];
> >
> > for (int i = 0; i < num_channels; i++) {
> > if (i) {
> > offset = LLVMBuildAdd(ctx->builder,
> offset,
> >
> LLVMConstInt(ctx->i32, 4, 0), "");
> > }
> > - LLVMValueRef args[2] = {rsrc, offset};
> > - result[i] = ac_build_intrinsic(ctx,
> "llvm.SI.load.const.v4i32",
> > - ctx->f32, args, 2,
> > -
> AC_FUNC_ATTR_READNONE |
> > -
> AC_FUNC_ATTR_LEGACY);
> > +
> > + if (HAVE_LLVM >= 0x0800) {
> > + LLVMValueRef args[3] = {rsrc, offset,
> ctx->i32_0};
> > + result[i] = ac_build_intrinsic(ctx,
> "llvm.amdgcn.s.buffer.load.i32",
> > + ctx->f32,
> args, 3,
> > +
> AC_FUNC_ATTR_READNONE);
> > + } else {
> > + LLVMValueRef args[2] = {rsrc, offset};
> > + result[i] = ac_build_intrinsic(ctx,
> "llvm.SI.load.const.v4i32",
> > + ctx->f32,
> args, 2,
> > +
> AC_FUNC_ATTR_READNONE |
> > +
> AC_FUNC_ATTR_LEGACY);
> > + }
> > }
> > if (num_channels == 1)
> > return result[0];
> >
> > if (num_channels == 3)
> > result[num_channels++] = LLVMGetUndef(ctx->f32);
> > return ac_build_gather_values(ctx, result, num_channels);
> > }
> >
> > return ac_build_buffer_load_common(ctx, rsrc, vindex, offset,
> > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> > index 727def56f65..2f49685c642 100644
> > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> > @@ -533,24 +533,24 @@ static void load_emit(
> > info->images_store |
> > info->images_atomic,
> >
> info->uses_bindless_buffer_store |
> >
> info->uses_bindless_buffer_atomic,
> >
> info->uses_bindless_image_store |
> >
> info->uses_bindless_image_atomic);
> > args.cache_policy = get_cache_policy(ctx, inst, false, false,
> false);
> >
> > if (inst->Src[0].Register.File == TGSI_FILE_BUFFER) {
> > /* Don't use SMEM for shader buffer loads, because LLVM
> doesn't
> > -* select SMEM for SI.load.const with a non-constant
> offset, and
> > +* select SMEM for amdgcn.s.buffer.load with a
> non-constant offset, and
> > * constant offsets practically don't exist with shader
> buffers.
> > *
> > -* Also, SI.load.const doesn't use inst_offset when it's
> lowered
> > +* Also, amdgcn.s.buffer.load doesn't use inst_offset
> when it's lowered
> > * to VMEM, so we just end up with more VALU
> instructions in the end
> > * and no benefit.
> > *
> > * TODO: Remove this line once LLVM can select SMEM with
> a non-constant
> > * offset, and can derive inst_offset when VMEM is
> selected.
> > * After that, si_memory_barrier should invalidate
> sL1 for shader
> > * buffers.
> > */
> > emit_data->output[emit_data->chan] =
> > ac_build_buffer_load(>ac, args.resource,
> > --
> > 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
Re: [Mesa-dev] [PATCH] radv: avoid context rolls when binding graphics pipelines
I did and found small improvements in Rise of the Tomb Raider. I
measured framerates ~104.3% that of without the changes for the
Geothermal Valley scene, ~101.2% for Spine of the Mountain and ~102.3%
for Prophets Tomb.
I found no change with Dota 2 but I've heard it's cpu-bound.
On Mon, 14 Jan 2019 at 16:05, Samuel Pitoiset wrote:
>
> Did you benchmark?
>
> On 1/14/19 5:01 PM, Rhys Perry wrote:
> > It's common in some applications to bind a new graphics pipeline without
> > ending up changing any context registers.
> >
> > This has a pipline have two command buffers: one for setting context
> > registers and one for everything else. The context register command buffer
> > is only emitted if it differs from the previous pipeline's.
> >
> > Signed-off-by: Rhys Perry
> > ---
> > src/amd/vulkan/radv_cmd_buffer.c | 46 +--
> > src/amd/vulkan/radv_pipeline.c | 217 ---
> > src/amd/vulkan/radv_private.h| 2 +
> > 3 files changed, 150 insertions(+), 115 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> > b/src/amd/vulkan/radv_cmd_buffer.c
> > index f41d6c0b3e7..59903ab64d8 100644
> > --- a/src/amd/vulkan/radv_cmd_buffer.c
> > +++ b/src/amd/vulkan/radv_cmd_buffer.c
> > @@ -634,7 +634,7 @@ radv_emit_descriptor_pointers(struct radv_cmd_buffer
> > *cmd_buffer,
> > }
> > }
> >
> > -static void
> > +static bool
> > radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer,
> > struct radv_pipeline *pipeline)
> > {
> > @@ -646,7 +646,7 @@ radv_update_multisample_state(struct radv_cmd_buffer
> > *cmd_buffer,
> > cmd_buffer->sample_positions_needed = true;
> >
> > if (old_pipeline && num_samples ==
> > old_pipeline->graphics.ms.num_samples)
> > - return;
> > + return false;
> >
> > radeon_set_context_reg_seq(cmd_buffer->cs, R_028BDC_PA_SC_LINE_CNTL,
> > 2);
> > radeon_emit(cmd_buffer->cs, ms->pa_sc_line_cntl);
> > @@ -661,6 +661,8 @@ radv_update_multisample_state(struct radv_cmd_buffer
> > *cmd_buffer,
> > radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
> > radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) |
> > EVENT_INDEX(0));
> > }
> > +
> > + return true;
> > }
> >
> > static void
> > @@ -863,15 +865,15 @@ radv_emit_rbplus_state(struct radv_cmd_buffer
> > *cmd_buffer)
> > radeon_emit(cmd_buffer->cs, sx_blend_opt_control);
> > }
> >
> > -static void
> > +static bool
> > radv_emit_graphics_pipeline(struct radv_cmd_buffer *cmd_buffer)
> > {
> > struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
> >
> > if (!pipeline || cmd_buffer->state.emitted_pipeline == pipeline)
> > - return;
> > + return false;
> >
> > - radv_update_multisample_state(cmd_buffer, pipeline);
> > + bool context_roll = radv_update_multisample_state(cmd_buffer,
> > pipeline);
> >
> > cmd_buffer->scratch_size_needed =
> > MAX2(cmd_buffer->scratch_size_needed,
> > @@ -884,6 +886,15 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> > *cmd_buffer)
> >
> > radeon_emit_array(cmd_buffer->cs, pipeline->cs.buf, pipeline->cs.cdw);
> >
> > + if (!cmd_buffer->state.emitted_pipeline ||
> > + cmd_buffer->state.emitted_pipeline->ctx_cs.cdw !=
> > pipeline->ctx_cs.cdw ||
> > + cmd_buffer->state.emitted_pipeline->ctx_cs_hash !=
> > pipeline->ctx_cs_hash ||
> > + memcmp(cmd_buffer->state.emitted_pipeline->ctx_cs.buf,
> > +pipeline->ctx_cs.buf, pipeline->ctx_cs.cdw * 4)) {
> > + radeon_emit_array(cmd_buffer->cs, pipeline->ctx_cs.buf,
> > pipeline->ctx_cs.cdw);
> > + context_roll = true;
> > + }
> > +
> > for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
> > if (!pipeline->shaders[i])
> > continue;
> > @@ -902,6 +913,8 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> > *cmd_buffer)
> > cmd_buffer->state.emitted_pipeline = pipeline;
> >
> > cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_PIPELINE;
> > +
> > + return context_roll;
> > }
> >
> > static void
> > @@ -2859,6 +2872,8 @@ radv_emit_compute_pipeline(struct radv_cmd_buffer
> > *cmd_buffer)
> > if (!pipeline || pipeline ==
> > cmd_buffer->state.emitted_compute_pipeline)
> > return;
> >
> > + assert(!pipeline->ctx_cs.cdw);
> > +
> > cmd_buffer->state.emitted_compute_pipeline = pipeline;
> >
> > radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs,
> > pipeline->cs.cdw);
> > @@ -3609,30 +3624,30 @@ radv_emit_draw_packets(struct radv_cmd_buffer
> > *cmd_buffer,
> >* any context registers.
> >*/
> > static bool radv_need_late_scissor_emission(struct radv_cmd_buffer
> > *cmd_buffer,
> > -bool indexed_draw)
> > +
Re: [Mesa-dev] [PATCH] radv: avoid context rolls when binding graphics pipelines
Did you benchmark?
On 1/14/19 5:01 PM, Rhys Perry wrote:
It's common in some applications to bind a new graphics pipeline without
ending up changing any context registers.
This has a pipline have two command buffers: one for setting context
registers and one for everything else. The context register command buffer
is only emitted if it differs from the previous pipeline's.
Signed-off-by: Rhys Perry
---
src/amd/vulkan/radv_cmd_buffer.c | 46 +--
src/amd/vulkan/radv_pipeline.c | 217 ---
src/amd/vulkan/radv_private.h| 2 +
3 files changed, 150 insertions(+), 115 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f41d6c0b3e7..59903ab64d8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -634,7 +634,7 @@ radv_emit_descriptor_pointers(struct radv_cmd_buffer
*cmd_buffer,
}
}
-static void
+static bool
radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer,
struct radv_pipeline *pipeline)
{
@@ -646,7 +646,7 @@ radv_update_multisample_state(struct radv_cmd_buffer
*cmd_buffer,
cmd_buffer->sample_positions_needed = true;
if (old_pipeline && num_samples == old_pipeline->graphics.ms.num_samples)
- return;
+ return false;
radeon_set_context_reg_seq(cmd_buffer->cs, R_028BDC_PA_SC_LINE_CNTL, 2);
radeon_emit(cmd_buffer->cs, ms->pa_sc_line_cntl);
@@ -661,6 +661,8 @@ radv_update_multisample_state(struct radv_cmd_buffer
*cmd_buffer,
radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) |
EVENT_INDEX(0));
}
+
+ return true;
}
static void
@@ -863,15 +865,15 @@ radv_emit_rbplus_state(struct radv_cmd_buffer *cmd_buffer)
radeon_emit(cmd_buffer->cs, sx_blend_opt_control);
}
-static void
+static bool
radv_emit_graphics_pipeline(struct radv_cmd_buffer *cmd_buffer)
{
struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
if (!pipeline || cmd_buffer->state.emitted_pipeline == pipeline)
- return;
+ return false;
- radv_update_multisample_state(cmd_buffer, pipeline);
+ bool context_roll = radv_update_multisample_state(cmd_buffer, pipeline);
cmd_buffer->scratch_size_needed =
MAX2(cmd_buffer->scratch_size_needed,
@@ -884,6 +886,15 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
*cmd_buffer)
radeon_emit_array(cmd_buffer->cs, pipeline->cs.buf, pipeline->cs.cdw);
+ if (!cmd_buffer->state.emitted_pipeline ||
+ cmd_buffer->state.emitted_pipeline->ctx_cs.cdw !=
pipeline->ctx_cs.cdw ||
+ cmd_buffer->state.emitted_pipeline->ctx_cs_hash !=
pipeline->ctx_cs_hash ||
+ memcmp(cmd_buffer->state.emitted_pipeline->ctx_cs.buf,
+ pipeline->ctx_cs.buf, pipeline->ctx_cs.cdw * 4)) {
+ radeon_emit_array(cmd_buffer->cs, pipeline->ctx_cs.buf,
pipeline->ctx_cs.cdw);
+ context_roll = true;
+ }
+
for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
if (!pipeline->shaders[i])
continue;
@@ -902,6 +913,8 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
*cmd_buffer)
cmd_buffer->state.emitted_pipeline = pipeline;
cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_PIPELINE;
+
+ return context_roll;
}
static void
@@ -2859,6 +2872,8 @@ radv_emit_compute_pipeline(struct radv_cmd_buffer
*cmd_buffer)
if (!pipeline || pipeline == cmd_buffer->state.emitted_compute_pipeline)
return;
+ assert(!pipeline->ctx_cs.cdw);
+
cmd_buffer->state.emitted_compute_pipeline = pipeline;
radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs, pipeline->cs.cdw);
@@ -3609,30 +3624,30 @@ radv_emit_draw_packets(struct radv_cmd_buffer
*cmd_buffer,
* any context registers.
*/
static bool radv_need_late_scissor_emission(struct radv_cmd_buffer
*cmd_buffer,
-bool indexed_draw)
+bool indexed_draw,
+bool pipeline_context_roll)
{
struct radv_cmd_state *state = _buffer->state;
if (!cmd_buffer->device->physical_device->has_scissor_bug)
return false;
+ if (pipeline_context_roll)
+ return true;
+
uint32_t used_states =
cmd_buffer->state.pipeline->graphics.needed_dynamic_state |
~RADV_CMD_DIRTY_DYNAMIC_ALL;
/* Index, vertex and streamout buffers don't change context regs, and
-* pipeline is handled later.
+* pipeline is already handled.
*/
used_states &= ~(RADV_CMD_DIRTY_INDEX_BUFFER |
RADV_CMD_DIRTY_VERTEX_BUFFER |
[Mesa-dev] [PATCH] radv: avoid context rolls when binding graphics pipelines
It's common in some applications to bind a new graphics pipeline without
ending up changing any context registers.
This has a pipline have two command buffers: one for setting context
registers and one for everything else. The context register command buffer
is only emitted if it differs from the previous pipeline's.
Signed-off-by: Rhys Perry
---
src/amd/vulkan/radv_cmd_buffer.c | 46 +--
src/amd/vulkan/radv_pipeline.c | 217 ---
src/amd/vulkan/radv_private.h| 2 +
3 files changed, 150 insertions(+), 115 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f41d6c0b3e7..59903ab64d8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -634,7 +634,7 @@ radv_emit_descriptor_pointers(struct radv_cmd_buffer
*cmd_buffer,
}
}
-static void
+static bool
radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer,
struct radv_pipeline *pipeline)
{
@@ -646,7 +646,7 @@ radv_update_multisample_state(struct radv_cmd_buffer
*cmd_buffer,
cmd_buffer->sample_positions_needed = true;
if (old_pipeline && num_samples ==
old_pipeline->graphics.ms.num_samples)
- return;
+ return false;
radeon_set_context_reg_seq(cmd_buffer->cs, R_028BDC_PA_SC_LINE_CNTL, 2);
radeon_emit(cmd_buffer->cs, ms->pa_sc_line_cntl);
@@ -661,6 +661,8 @@ radv_update_multisample_state(struct radv_cmd_buffer
*cmd_buffer,
radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) |
EVENT_INDEX(0));
}
+
+ return true;
}
static void
@@ -863,15 +865,15 @@ radv_emit_rbplus_state(struct radv_cmd_buffer *cmd_buffer)
radeon_emit(cmd_buffer->cs, sx_blend_opt_control);
}
-static void
+static bool
radv_emit_graphics_pipeline(struct radv_cmd_buffer *cmd_buffer)
{
struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
if (!pipeline || cmd_buffer->state.emitted_pipeline == pipeline)
- return;
+ return false;
- radv_update_multisample_state(cmd_buffer, pipeline);
+ bool context_roll = radv_update_multisample_state(cmd_buffer, pipeline);
cmd_buffer->scratch_size_needed =
MAX2(cmd_buffer->scratch_size_needed,
@@ -884,6 +886,15 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
*cmd_buffer)
radeon_emit_array(cmd_buffer->cs, pipeline->cs.buf, pipeline->cs.cdw);
+ if (!cmd_buffer->state.emitted_pipeline ||
+ cmd_buffer->state.emitted_pipeline->ctx_cs.cdw !=
pipeline->ctx_cs.cdw ||
+ cmd_buffer->state.emitted_pipeline->ctx_cs_hash !=
pipeline->ctx_cs_hash ||
+ memcmp(cmd_buffer->state.emitted_pipeline->ctx_cs.buf,
+ pipeline->ctx_cs.buf, pipeline->ctx_cs.cdw * 4)) {
+ radeon_emit_array(cmd_buffer->cs, pipeline->ctx_cs.buf,
pipeline->ctx_cs.cdw);
+ context_roll = true;
+ }
+
for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
if (!pipeline->shaders[i])
continue;
@@ -902,6 +913,8 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
*cmd_buffer)
cmd_buffer->state.emitted_pipeline = pipeline;
cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_PIPELINE;
+
+ return context_roll;
}
static void
@@ -2859,6 +2872,8 @@ radv_emit_compute_pipeline(struct radv_cmd_buffer
*cmd_buffer)
if (!pipeline || pipeline == cmd_buffer->state.emitted_compute_pipeline)
return;
+ assert(!pipeline->ctx_cs.cdw);
+
cmd_buffer->state.emitted_compute_pipeline = pipeline;
radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs,
pipeline->cs.cdw);
@@ -3609,30 +3624,30 @@ radv_emit_draw_packets(struct radv_cmd_buffer
*cmd_buffer,
* any context registers.
*/
static bool radv_need_late_scissor_emission(struct radv_cmd_buffer *cmd_buffer,
-bool indexed_draw)
+bool indexed_draw,
+bool pipeline_context_roll)
{
struct radv_cmd_state *state = _buffer->state;
if (!cmd_buffer->device->physical_device->has_scissor_bug)
return false;
+ if (pipeline_context_roll)
+ return true;
+
uint32_t used_states =
cmd_buffer->state.pipeline->graphics.needed_dynamic_state |
~RADV_CMD_DIRTY_DYNAMIC_ALL;
/* Index, vertex and streamout buffers don't change context regs, and
-* pipeline is handled later.
+* pipeline is already handled.
*/
used_states &= ~(RADV_CMD_DIRTY_INDEX_BUFFER |
RADV_CMD_DIRTY_VERTEX_BUFFER |
RADV_CMD_DIRTY_STREAMOUT_BUFFER |
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 --- Comment #66 from Thomas Crider --- can confirm changing the string has no effect on intel. only needed for amd. the glxcmds portion of the patch is still necessary for both. will see if I can jump in irc and get more input on the patch. Axel Davy since the string change requirement is amd specific your change may be more viable after all tested on rx 580, vega 64, and Intel Haswell iGPU -- 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] bin/get-pick-list.sh: fix the oneline printing
On Fri, 2019-01-11 at 14:56 +, Eric Engestrom wrote:
> On Friday, 2019-01-11 16:42:25 +0200, Andres Gomez wrote:
> > "--summary" will also print extended header information such as
> > creations, renames and mode changes.
> >
> > Let's just use "-s", which suppresses the diff output.
> >
> > Fixes: 559c32d2412 ("bin/get-pick-list.sh: simplify git oneline printing")
> > Cc: Juan A. Suarez
> > Cc: Eric Engestrom
> > Cc: Dylan Baker
> > Cc: Emil Velikov
> > Signed-off-by: Andres Gomez
> > ---
> > bin/get-pick-list.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> > index 3099fc69413..d71ff4a708a 100755
> > --- a/bin/get-pick-list.sh
> > +++ b/bin/get-pick-list.sh
> > @@ -143,7 +143,7 @@ do
> > esac
> >
> > printf "[ %8s ] " "$tag"
> > - git --no-pager show --summary --oneline $sha
> > + git --no-pager show -s --oneline $sha
>
> Small preference for the explicit `--no-patch` instead of `-s`, but:
> Reviewed-by: Eric Engestrom
Changed locally and pushed.
Thanks for the review!
>
> > done
> >
> > rm -f already_picked
> > --
> > 2.18.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
--
Br,
Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] bin/get-pick-list.sh: fix redirection in sh
On Fri, 2019-01-11 at 15:41 +, Emil Velikov wrote:
> On 2019/01/11, Andres Gomez wrote:
> > "&>" is bash specific.
> >
> > Fixes: e0dbfc99537 ("bin/get-pick-list.sh: warn when commit lists invalid
> > sha")
> > Cc: Juan A. Suarez
> > Cc: Eric Engestrom
> > Cc: Dylan Baker
> > Cc: Emil Velikov
>
> Reviewed-by: Emil Velikov
>
> Out of curiosity, are you using dash/mksh? ZSH seems happy.
dash. It is the one shipped by Debian:
root@debian-testing:~# dpkg -L dash
/.
/bin
/bin/dash
/usr
/usr/share
/usr/share/doc
/usr/share/doc/dash
/usr/share/doc/dash/NEWS.Debian.gz
/usr/share/doc/dash/README.Debian.diet
/usr/share/doc/dash/README.source
/usr/share/doc/dash/changelog.Debian.gz
/usr/share/doc/dash/changelog.gz
/usr/share/doc/dash/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/dash.1.gz
/usr/share/menu
/usr/share/menu/dash
/bin/sh
package diverts others to: /bin/sh.distrib
/usr/share/man/man1/sh.1.gz
package diverts others to: /usr/share/man/man1/sh.distrib.1.gz
--
Br,
Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's
Am Montag, den 14.01.2019, 15:20 +0100 schrieb Marek Vasut: > On 1/14/19 3:02 PM, Lucas Stach wrote: > > Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut: > > > On 1/14/19 12:16 PM, Lucas Stach wrote: > > > > Hi Marek, > > > > > > > > Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut: > > > > > > From: Christian Gmeiner > > > > > > > > > > A pipe_resource can be shared by all the pipe_context's hanging off > > > > > the > > > > > same pipe_screen. > > > > > > > > > > > > > > > Signed-off-by: Christian Gmeiner > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Marek Vasut > > > > > > > > > > To: mesa-dev@lists.freedesktop.org > > > > > Cc: etna...@lists.freedesktop.org > > > > > --- > > > > > Changes from v1 -> v2: > > > > > - to remove the resource from the used_resources set when it is > > > > > destroyed > > > > > Changes from v2 -> v3: > > > > > - add locking with mtx_*() to resource and screen (Marek) > > > > > Changes from v3 -> v4: > > > > > - drop rsc->lock, just use screen->lock for the entire serialization > > > > > (Marek) > > > > > - simplify etna_resource_used() flush condition, which also prevents > > > > > potentially flushing resources twice (Marek) > > > > > - don't remove resouces from screen->used_resources in > > > > > etna_cmd_stream_reset_notify(), they may still be used in other > > > > > contexts and may need flushing there later on (Marek) > > > > > > > > The patch mostly makes sense to me now, but don't we need to take the > > > > screen->lock on all call sites where we do a ctx->flush? Otherwise we > > > > may enter etna_cmd_stream_reset_notify unlocked, changing the > > > > used_resources set while other threads might use it at the same time, > > > > right? > > > > > > etna_cmd_stream_reset_notify() takes the lock when accessing the > > > used_resources set , see below. > > > > Uh, sorry seems I mixed this up. But then I don't see how this isn't > > deadlocking, as AFAICS mtx_lock isn't recursive. > > > > In etna_resource_used() you already lock the screen mutex, then when > > you find a context that needs flushing you call the context flush, > > which flushes the cmd stream and calls into > > etna_cmd_stream_reset_notify() where the mutex is locked again -> self > > deadlock. > > [...] > > > > > > + mtx_init(>lock, mtx_recursive); > > [...] > > But it is recursive ... Thanks, going back to ridicule myself somewhere myself somewhere else now. Regards, Lucas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's
On 1/14/19 3:02 PM, Lucas Stach wrote: > Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut: >> On 1/14/19 12:16 PM, Lucas Stach wrote: >>> Hi Marek, >>> >>> Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut: > From: Christian Gmeiner A pipe_resource can be shared by all the pipe_context's hanging off the same pipe_screen. > Signed-off-by: Christian Gmeiner > Signed-off-by: Marek Vasut To: mesa-dev@lists.freedesktop.org Cc: etna...@lists.freedesktop.org --- Changes from v1 -> v2: - to remove the resource from the used_resources set when it is destroyed Changes from v2 -> v3: - add locking with mtx_*() to resource and screen (Marek) Changes from v3 -> v4: - drop rsc->lock, just use screen->lock for the entire serialization (Marek) - simplify etna_resource_used() flush condition, which also prevents potentially flushing resources twice (Marek) - don't remove resouces from screen->used_resources in etna_cmd_stream_reset_notify(), they may still be used in other contexts and may need flushing there later on (Marek) >>> >>> The patch mostly makes sense to me now, but don't we need to take the >>> screen->lock on all call sites where we do a ctx->flush? Otherwise we >>> may enter etna_cmd_stream_reset_notify unlocked, changing the >>> used_resources set while other threads might use it at the same time, >>> right? >> >> etna_cmd_stream_reset_notify() takes the lock when accessing the >> used_resources set , see below. > > Uh, sorry seems I mixed this up. But then I don't see how this isn't > deadlocking, as AFAICS mtx_lock isn't recursive. > > In etna_resource_used() you already lock the screen mutex, then when > you find a context that needs flushing you call the context flush, > which flushes the cmd stream and calls into > etna_cmd_stream_reset_notify() where the mutex is locked again -> self > deadlock. [...] + mtx_init(>lock, mtx_recursive); [...] But it is recursive ... -- Best regards, Marek Vasut ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's
Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut:
> On 1/14/19 12:16 PM, Lucas Stach wrote:
> > Hi Marek,
> >
> > Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > > > From: Christian Gmeiner
> > >
> > > A pipe_resource can be shared by all the pipe_context's hanging off the
> > > same pipe_screen.
> > >
> > > > > > > > Signed-off-by: Christian Gmeiner
> > > > Signed-off-by: Marek Vasut
> > >
> > > To: mesa-dev@lists.freedesktop.org
> > > Cc: etna...@lists.freedesktop.org
> > > ---
> > > Changes from v1 -> v2:
> > > - to remove the resource from the used_resources set when it is destroyed
> > > Changes from v2 -> v3:
> > > - add locking with mtx_*() to resource and screen (Marek)
> > > Changes from v3 -> v4:
> > > - drop rsc->lock, just use screen->lock for the entire serialization
> > > (Marek)
> > > - simplify etna_resource_used() flush condition, which also prevents
> > > potentially flushing resources twice (Marek)
> > > - don't remove resouces from screen->used_resources in
> > > etna_cmd_stream_reset_notify(), they may still be used in other
> > > contexts and may need flushing there later on (Marek)
> >
> > The patch mostly makes sense to me now, but don't we need to take the
> > screen->lock on all call sites where we do a ctx->flush? Otherwise we
> > may enter etna_cmd_stream_reset_notify unlocked, changing the
> > used_resources set while other threads might use it at the same time,
> > right?
>
> etna_cmd_stream_reset_notify() takes the lock when accessing the
> used_resources set , see below.
Uh, sorry seems I mixed this up. But then I don't see how this isn't
deadlocking, as AFAICS mtx_lock isn't recursive.
In etna_resource_used() you already lock the screen mutex, then when
you find a context that needs flushing you call the context flush,
which flushes the cmd stream and calls into
etna_cmd_stream_reset_notify() where the mutex is locked again -> self
deadlock.
Regards,
Lucas
> > Regards,
> > Lucas
> >
> > > ---
> > > src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
> > > src/gallium/drivers/etnaviv/etnaviv_context.h | 3 --
> > > .../drivers/etnaviv/etnaviv_resource.c| 52 +++
> > > .../drivers/etnaviv/etnaviv_resource.h| 8 +--
> > > src/gallium/drivers/etnaviv/etnaviv_screen.c | 12 +
> > > src/gallium/drivers/etnaviv/etnaviv_screen.h | 6 +++
> > > 6 files changed, 78 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > index 3038d21..2f8cae8 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > @@ -36,6 +36,7 @@
> > > #include "etnaviv_query.h"
> > > #include "etnaviv_query_hw.h"
> > > #include "etnaviv_rasterizer.h"
> > > +#include "etnaviv_resource.h"
> > > #include "etnaviv_screen.h"
> > > #include "etnaviv_shader.h"
> > > #include "etnaviv_state.h"
> > > @@ -329,7 +330,8 @@ static void
> > > etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
> > > {
> > > struct etna_context *ctx = priv;
> > > - struct etna_resource *rsc, *rsc_tmp;
> > > + struct etna_screen *screen = ctx->screen;
> > > + struct set_entry *entry;
> > >
> > > etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> > > etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> > > @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream
> > > *stream, void *priv)
> > > ctx->dirty = ~0L;
> > > ctx->dirty_sampler_views = ~0L;
> > >
> > > - /* go through all the used resources and clear their status flag */
> > > - LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, >used_resources, list)
> > > - {
> > > - debug_assert(rsc->status != 0);
> > > - rsc->status = 0;
> > > - rsc->pending_ctx = NULL;
> > > - list_delinit(>list);
> > > - }
> > > + /*
> > > +* Go through all _resources_ associated with this _screen_, pending
> > > +* in this _context_ and mark them as not pending in this _context_
> > > +* anymore, since they were just flushed.
> > > +*/
> > > + mtx_lock(>lock);
> > > + set_foreach(screen->used_resources, entry) {
> > > + struct etna_resource *rsc = (struct etna_resource *)entry->key;
> > >
> > > - assert(LIST_IS_EMPTY(>used_resources));
> > > + _mesa_set_remove_key(rsc->pending_ctx, ctx);
> > > + }
> > > + mtx_unlock(>lock);
> > > }
> > >
> > > static void
> > > @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void
> > > *priv, unsigned flags)
> > > /* need some sane default in case state tracker doesn't set some
> > > state: */
> > > ctx->sample_mask = 0x;
> > >
> > > - list_inithead(>used_resources);
> > > -
> > > /* Set sensible defaults for state */
> > > etna_cmd_stream_reset_notify(ctx->stream, ctx);
> > >
>
Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's
On 1/14/19 12:16 PM, Lucas Stach wrote:
> Hi Marek,
>
> Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
>>> From: Christian Gmeiner
>>
>> A pipe_resource can be shared by all the pipe_context's hanging off the
>> same pipe_screen.
>>
>>> Signed-off-by: Christian Gmeiner
>>> Signed-off-by: Marek Vasut
>> To: mesa-dev@lists.freedesktop.org
>> Cc: etna...@lists.freedesktop.org
>> ---
>> Changes from v1 -> v2:
>> - to remove the resource from the used_resources set when it is destroyed
>> Changes from v2 -> v3:
>> - add locking with mtx_*() to resource and screen (Marek)
>> Changes from v3 -> v4:
>> - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
>> - simplify etna_resource_used() flush condition, which also prevents
>> potentially flushing resources twice (Marek)
>> - don't remove resouces from screen->used_resources in
>> etna_cmd_stream_reset_notify(), they may still be used in other
>> contexts and may need flushing there later on (Marek)
>
> The patch mostly makes sense to me now, but don't we need to take the
> screen->lock on all call sites where we do a ctx->flush? Otherwise we
> may enter etna_cmd_stream_reset_notify unlocked, changing the
> used_resources set while other threads might use it at the same time,
> right?
etna_cmd_stream_reset_notify() takes the lock when accessing the
used_resources set , see below.
> Regards,
> Lucas
>
>> ---
>> src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
>> src/gallium/drivers/etnaviv/etnaviv_context.h | 3 --
>> .../drivers/etnaviv/etnaviv_resource.c| 52 +++
>> .../drivers/etnaviv/etnaviv_resource.h| 8 +--
>> src/gallium/drivers/etnaviv/etnaviv_screen.c | 12 +
>> src/gallium/drivers/etnaviv/etnaviv_screen.h | 6 +++
>> 6 files changed, 78 insertions(+), 29 deletions(-)
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c
>> b/src/gallium/drivers/etnaviv/etnaviv_context.c
>> index 3038d21..2f8cae8 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
>> @@ -36,6 +36,7 @@
>> #include "etnaviv_query.h"
>> #include "etnaviv_query_hw.h"
>> #include "etnaviv_rasterizer.h"
>> +#include "etnaviv_resource.h"
>> #include "etnaviv_screen.h"
>> #include "etnaviv_shader.h"
>> #include "etnaviv_state.h"
>> @@ -329,7 +330,8 @@ static void
>> etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
>> {
>> struct etna_context *ctx = priv;
>> - struct etna_resource *rsc, *rsc_tmp;
>> + struct etna_screen *screen = ctx->screen;
>> + struct set_entry *entry;
>>
>> etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
>> etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
>> @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream
>> *stream, void *priv)
>> ctx->dirty = ~0L;
>> ctx->dirty_sampler_views = ~0L;
>>
>> - /* go through all the used resources and clear their status flag */
>> - LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, >used_resources, list)
>> - {
>> - debug_assert(rsc->status != 0);
>> - rsc->status = 0;
>> - rsc->pending_ctx = NULL;
>> - list_delinit(>list);
>> - }
>> + /*
>> +* Go through all _resources_ associated with this _screen_, pending
>> +* in this _context_ and mark them as not pending in this _context_
>> +* anymore, since they were just flushed.
>> +*/
>> + mtx_lock(>lock);
>> + set_foreach(screen->used_resources, entry) {
>> + struct etna_resource *rsc = (struct etna_resource *)entry->key;
>>
>> - assert(LIST_IS_EMPTY(>used_resources));
>> + _mesa_set_remove_key(rsc->pending_ctx, ctx);
>> + }
>> + mtx_unlock(>lock);
>> }
>>
>> static void
>> @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void
>> *priv, unsigned flags)
>> /* need some sane default in case state tracker doesn't set some state:
>> */
>> ctx->sample_mask = 0x;
>>
>> - list_inithead(>used_resources);
>> -
>> /* Set sensible defaults for state */
>> etna_cmd_stream_reset_notify(ctx->stream, ctx);
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h
>> b/src/gallium/drivers/etnaviv/etnaviv_context.h
>> index 584caa7..eff0a23 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
>> @@ -136,9 +136,6 @@ struct etna_context {
>> uint32_t prim_hwsupport;
>> struct primconvert_context *primconvert;
>>
>> - /* list of resources used by currently-unsubmitted renders */
>> - struct list_head used_resources;
>> -
>> struct slab_child_pool transfer_pool;
>> struct blitter_context *blitter;
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
>> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
>> index 3808c29..46ab849 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
>>
Re: [Mesa-dev] [PATCH 07/11] radv: Add multiview clears.
On Wed, 19 Dec 2018 at 11:54, Juan A. Suarez Romero wrote:
>
> On Wed, 2017-08-23 at 22:51 +0200, Bas Nieuwenhuizen wrote:
> > ---
> > src/amd/vulkan/radv_cmd_buffer.c | 1 +
> > src/amd/vulkan/radv_meta_clear.c | 65
> >
> > src/amd/vulkan/radv_private.h| 1 +
> > 3 files changed, 48 insertions(+), 19 deletions(-)
> >
>
> Hi. This landed in master as f67dea5e19e ("radv: Fix multiview depth clears"),
> fixing 2e86f6b2597 ("radv: Add multiview clears."), which is part of 18.2
> stable
> branch. Thus this commit is also a candidate for the same branch.
>
> Nevertheless, I'm rejecting it as it does not apply in the branch. Apparently
> it
> would require at least aeaf8dbd097 ("radv: add radv_image_can_fast_clear()
> helper") and 7484bc894b9 ("radv: refactor the fast clear path for better re-
> use"), but very likely more changes.
>
>
> If you can provide a backport for 18.2 stable branch, I could enqueue it.
> Otherwise, I'll keep it out.
>
Likewise for 18.3.
Bas, Dave, team, please send a backport if we need this for the 18.3 series.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
Hi, On 13.1.2019 9.44, Jonathan Gray wrote: ...> As we can not depend on python to build Mesa in OpenBSD I will have to go back to maintaining a local Mesa build system if autotools is removed. Mesa already needs python-mako (for code generation) with Autotools. Why Meson also needing Python is a problem? - Eero ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0
Hello, The test for this issue is pushed to the piglit. It would be great to push the mesa fix too if it is still an acceptable for all :) Thanks, Andrii. On Sat, Oct 20, 2018 at 12:29 PM andrey simiklit wrote: > Hello, > > On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke > wrote: > >> On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote: >> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote: >> > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com >> wrote: >> > > > From: Andrii Simiklit >> > > > >> > > > I guess that when we calculating the width0, height0, depth0 >> > > > to use for function 'intel_miptree_create' we need to consider >> > > > the 'base level' like it is done in the >> 'intel_miptree_create_for_teximage' >> > > > function. >> > > > >> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987 >> > > > Signed-off-by: Andrii Simiklit >> > > > --- >> > > > .../drivers/dri/i965/intel_tex_validate.c | 26 >> ++- >> > > > 1 file changed, 25 insertions(+), 1 deletion(-) >> > > >> > > I believe this patch is correct - we're assembling things into a new >> > > miptree, which we start at level 0 - so we need the sizes for level 0. >> > > >> > > Alternatively, we might be able to pass validate_first_level instead >> > > of 0 when calling intel_miptree_create, to make one that's only good >> > > up until the new base...and have to re-assemble it the next time they >> > > change the base. It would save memory potentially. But more copies. >> > > I don't have a strong preference which is better. >> > > >> > > Please do make a Piglit or dEQP test for this. >> > > >> > > Reviewed-by: Kenneth Graunke >> > >> > Sorry, withdrawing my review. :( Chris Forbes pointed out on IRC that >> > your reproducer case is backwards: >> > >> > miplevel 0 - 1x1 >> > miplevel 1 - 2x2 >> > miplevel 2 - 4x4 >> > >> > That's upside down. A proper miptree would have the base be largest: >> > >> > miplevel 0 - 4x4 >> > miplevel 1 - 2x2 >> > miplevel 2 - 1x1 >> > >> > So, yes, I could see this tripping an assert...but such a crazy texture >> > will never be mipmap complete. If they're expecting mipmapping, then >> > it seems like they should get a fallback black texture (which normally >> > happens for incomplete textures). If not, maybe they should get a >> > single miplevel? Either way, seems like we should detect insanity and >> > bail, rather than change size calculations for the normal sane case. >> > >> >> So...looked at this again. I'm not sure why upside-down matters. >> >> At DrawArrays time, we have a single miplevel (base = 2), and are trying >> to put that single miplevel's image into a miptree. We do properly >> ignore levels 0..1 as they're beyond the base. >> >> We appear to use level 0 as the actual base, and want to store our >> single level at level 2. Other places (TexImage) seem to work that way >> too. >> >> But, we're creating the miplevel with level 0 as the base, but where >> level 0 has the dimensions of level 2. This doesn't work. And your >> patch fixes that. >> >> I tried making the actual base of the unified tree be level 2, rather >> than level 0...so that the BaseLevel is the actual base...but tons of >> things broke. >> >> So, back to Reviewed-by. I think once we get a Piglit test, I'm happy >> to land this patch. > > > Thanks for reviewing :-) I will start to work on it as soon as come back > from vacation (on Monday) > > >> >> --Ken > > > Thanks, > Andrii. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: add missing GLSL_TYPE_FLOAT16 to glsl_base_to_llvm_type()
Reviewed-by: Bas Nieuwenhuizen On Mon, Jan 14, 2019 at 1:49 PM Samuel Pitoiset wrote: > > Fix a crash with > dEQP-VK.spirv_assembly.instruction.compute.workgroup_memory.float16 > > Signed-off-by: Samuel Pitoiset > --- > src/amd/common/ac_nir_to_llvm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c > index 5023b96f92d..6bdc617b586 100644 > --- a/src/amd/common/ac_nir_to_llvm.c > +++ b/src/amd/common/ac_nir_to_llvm.c > @@ -3904,6 +3904,8 @@ glsl_base_to_llvm_type(struct ac_llvm_context *ac, > return ac->i32; > case GLSL_TYPE_FLOAT: /* TODO handle mediump */ > return ac->f32; > + case GLSL_TYPE_FLOAT16: > + return ac->f16; > case GLSL_TYPE_INT64: > case GLSL_TYPE_UINT64: > return ac->i64; > -- > 2.20.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac: add missing GLSL_TYPE_FLOAT16 to glsl_base_to_llvm_type()
Fix a crash with dEQP-VK.spirv_assembly.instruction.compute.workgroup_memory.float16 Signed-off-by: Samuel Pitoiset --- src/amd/common/ac_nir_to_llvm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 5023b96f92d..6bdc617b586 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -3904,6 +3904,8 @@ glsl_base_to_llvm_type(struct ac_llvm_context *ac, return ac->i32; case GLSL_TYPE_FLOAT: /* TODO handle mediump */ return ac->f32; + case GLSL_TYPE_FLOAT16: + return ac->f16; case GLSL_TYPE_INT64: case GLSL_TYPE_UINT64: return ac->i64; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
Hi, On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote: > 5. There's no way with gitlab for Reviewed-by tags to get automatically > applied as part of the merging process. This makes merging a bit more manual > than it needs to be but is really no worse than it was before. I'm still on the side of not seeing the value in them. Most of the time when I go to pursue someone who reviewed a commit, I'll go to see what came up in review anyway. Maybe someone had the same comment which was found to be not applicable or otherwise explained away. Reviewed-by and Acked-by are also pretty lossy anyway, and freeform text descriptors in a comment can much better capture the intent (e.g. 'I'm strongly OK with the driver changes and weakly OK with the core changes as it's not really my area of expertise'). In other projects, we looked for ways to apply the tags and ended up concluding that they didn't bring enough value to make it worthwhile. I don't know if that holds for Mesa, but it would be better to start with an actual problem statement - what value does R-b bring and how? - then look at ways to solve that problem, rather than just very directly finding a way to insert that literal text string into every commit message. FWIW, if you go to https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a hyperlink from the web UI which points you to the MR. The API to do this is pretty straightforward and amenable to piping through jq: https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 05/24] mapi: add all _glapi_table entrypoints to static_data.py
From: Emil Velikov
Currently various parts of mesa use the glapi_table differently.
Some use _glapi_get_proc_offset() to get the offset, while others
directly reference the specific offset via _gloffset_Function.
Add all static entries, to ensure things don't break as we flip to the
upstream XML + new mapi generator.
Note: the offsets are also used for the alias remap table, thus we need
to ensure we honour the correct offsets range or it will break.
Currently this is done via MAX_OFFSETS constant, although a better
solution is in the works.
v2: add FramebufferTexture2DMultisampleEXT
v3: add MAX_OFFSETS guard
Signed-off-by: Emil Velikov
Reviewed-by: Erik Faye-Lund (v1)
Signed-off-by: Emil Velikov
---
src/mapi/glapi/gen/gl_XML.py |2 +-
src/mapi/glapi/gen/static_data.py | 1023 -
2 files changed, 1023 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index b4aa6be985e..d2972992d1e 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -693,7 +693,7 @@ class gl_function( gl_item ):
# Only try to set the offset when a non-alias entry-point
# is being processed.
-if name in static_data.offsets:
+if name in static_data.offsets and static_data.offsets[name] <=
static_data.MAX_OFFSETS:
self.offset = static_data.offsets[name]
else:
self.offset = -1
diff --git a/src/mapi/glapi/gen/static_data.py
b/src/mapi/glapi/gen/static_data.py
index 0596d2cd3bb..1c71e188ef1 100644
--- a/src/mapi/glapi/gen/static_data.py
+++ b/src/mapi/glapi/gen/static_data.py
@@ -20,8 +20,17 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
+
+"""The maximum entries of actual static data required by indirect GLX."""
+
+
+MAX_OFFSETS = 407
+
"""Table of functions that have ABI-mandated offsets in the dispatch table.
+The first MAX_OFFSETS entries are required by indirect GLX. The rest are
+required to preserve the glapi <> drivers ABI. This is to be addressed shortly.
+
This list will never change."""
offsets = {
"NewList": 0,
@@ -431,7 +440,1019 @@ offsets = {
"MultiTexCoord4i": 404,
"MultiTexCoord4iv": 405,
"MultiTexCoord4s": 406,
-"MultiTexCoord4sv": 407
+"MultiTexCoord4sv": 407,
+"CompressedTexImage1D": 408,
+"CompressedTexImage2D": 409,
+"CompressedTexImage3D": 410,
+"CompressedTexSubImage1D": 411,
+"CompressedTexSubImage2D": 412,
+"CompressedTexSubImage3D": 413,
+"GetCompressedTexImage": 414,
+"LoadTransposeMatrixd": 415,
+"LoadTransposeMatrixf": 416,
+"MultTransposeMatrixd": 417,
+"MultTransposeMatrixf": 418,
+"SampleCoverage": 419,
+"BlendFuncSeparate": 420,
+"FogCoordPointer": 421,
+"FogCoordd": 422,
+"FogCoorddv": 423,
+"MultiDrawArrays": 424,
+"PointParameterf": 425,
+"PointParameterfv": 426,
+"PointParameteri": 427,
+"PointParameteriv": 428,
+"SecondaryColor3b": 429,
+"SecondaryColor3bv": 430,
+"SecondaryColor3d": 431,
+"SecondaryColor3dv": 432,
+"SecondaryColor3i": 433,
+"SecondaryColor3iv": 434,
+"SecondaryColor3s": 435,
+"SecondaryColor3sv": 436,
+"SecondaryColor3ub": 437,
+"SecondaryColor3ubv": 438,
+"SecondaryColor3ui": 439,
+"SecondaryColor3uiv": 440,
+"SecondaryColor3us": 441,
+"SecondaryColor3usv": 442,
+"SecondaryColorPointer": 443,
+"WindowPos2d": 444,
+"WindowPos2dv": 445,
+"WindowPos2f": 446,
+"WindowPos2fv": 447,
+"WindowPos2i": 448,
+"WindowPos2iv": 449,
+"WindowPos2s": 450,
+"WindowPos2sv": 451,
+"WindowPos3d": 452,
+"WindowPos3dv": 453,
+"WindowPos3f": 454,
+"WindowPos3fv": 455,
+"WindowPos3i": 456,
+"WindowPos3iv": 457,
+"WindowPos3s": 458,
+"WindowPos3sv": 459,
+"BeginQuery": 460,
+"BindBuffer": 461,
+"BufferData": 462,
+"BufferSubData": 463,
+"DeleteBuffers": 464,
+"DeleteQueries": 465,
+"EndQuery": 466,
+"GenBuffers": 467,
+"GenQueries": 468,
+"GetBufferParameteriv": 469,
+"GetBufferPointerv": 470,
+"GetBufferSubData": 471,
+"GetQueryObjectiv": 472,
+"GetQueryObjectuiv": 473,
+"GetQueryiv": 474,
+"IsBuffer": 475,
+"IsQuery": 476,
+"MapBuffer": 477,
+"UnmapBuffer": 478,
+"AttachShader": 479,
+"BindAttribLocation": 480,
+"BlendEquationSeparate": 481,
+"CompileShader": 482,
+"CreateProgram": 483,
+"CreateShader": 484,
+"DeleteProgram": 485,
+"DeleteShader": 486,
+"DetachShader": 487,
+"DisableVertexAttribArray": 488,
+"DrawBuffers": 489,
+"EnableVertexAttribArray": 490,
+"GetActiveAttrib": 491,
+"GetActiveUniform": 492,
+"GetAttachedShaders": 493,
+"GetAttribLocation": 494,
+"GetProgramInfoLog": 495,
+"GetProgramiv": 496,
+"GetShaderInfoLog": 497,
+
[Mesa-dev] [PATCH v4] anv/device: fix maximum number of images supported
We had defined MAX_IMAGES as 8, which we used to size the array for
image push constant data. The comment there stated that this was for
gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
that array, asserting that we don't exceed that number of images,
which imposes a limit of MAX_IMAGES on all gens.
Furthermore, despite this, we are exposing up to 64 images per shader
stage on all gens, gen8 included.
This patch lowers the number of images we expose in gen8 to 8 and
keeps 64 images for gen9+ while making sure that only pre-SKL gens
use push constant space to handle images.
v2:
- <= instead of < in the assert (Eric, Lionel)
- Change the way the assertion is written (Eric)
v3:
- Revert the way the assertion is written to the form it had in v1,
the version in v2 was not equivalent and was incorrect. (Lionel)
v4:
- gen9+ doesn't need push constants for images at all (Jason)
---
src/intel/vulkan/anv_device.c | 7 --
.../vulkan/anv_nir_apply_pipeline_layout.c| 4 +--
src/intel/vulkan/anv_private.h| 5 ++--
src/intel/vulkan/genX_cmd_buffer.c| 25 +--
4 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 523f1483e29..f85458b672e 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -987,9 +987,12 @@ void anv_GetPhysicalDeviceProperties(
const uint32_t max_samplers = (devinfo->gen >= 8 || devinfo->is_haswell) ?
128 : 16;
+ const uint32_t max_images = devinfo->gen < 9 ? MAX_GEN8_IMAGES : MAX_IMAGES;
+
VkSampleCountFlags sample_counts =
isl_device_get_sample_counts(>isl_dev);
+
VkPhysicalDeviceLimits limits = {
.maxImageDimension1D = (1 << 14),
.maxImageDimension2D = (1 << 14),
@@ -1009,7 +1012,7 @@ void anv_GetPhysicalDeviceProperties(
.maxPerStageDescriptorUniformBuffers = 64,
.maxPerStageDescriptorStorageBuffers = 64,
.maxPerStageDescriptorSampledImages = max_samplers,
- .maxPerStageDescriptorStorageImages = 64,
+ .maxPerStageDescriptorStorageImages = max_images,
.maxPerStageDescriptorInputAttachments= 64,
.maxPerStageResources = 250,
.maxDescriptorSetSamplers = 6 * max_samplers, /* number
of stages * maxPerStageDescriptorSamplers */
@@ -1018,7 +1021,7 @@ void anv_GetPhysicalDeviceProperties(
.maxDescriptorSetStorageBuffers = 6 * 64, /* number
of stages * maxPerStageDescriptorStorageBuffers */
.maxDescriptorSetStorageBuffersDynamic= MAX_DYNAMIC_BUFFERS / 2,
.maxDescriptorSetSampledImages= 6 * max_samplers, /* number
of stages * maxPerStageDescriptorSampledImages */
- .maxDescriptorSetStorageImages= 6 * 64, /* number
of stages * maxPerStageDescriptorStorageImages */
+ .maxDescriptorSetStorageImages= 6 * max_images, /* number
of stages * maxPerStageDescriptorStorageImages */
.maxDescriptorSetInputAttachments = 256,
.maxVertexInputAttributes = MAX_VBS,
.maxVertexInputBindings = MAX_VBS,
diff --git a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
index b3daf702bc0..623984b0f8c 100644
--- a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
+++ b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
@@ -528,8 +528,8 @@ anv_nir_apply_pipeline_layout(const struct
anv_physical_device *pdevice,
}
}
- if (map->image_count > 0) {
- assert(map->image_count <= MAX_IMAGES);
+ if (map->image_count > 0 && pdevice->compiler->devinfo->gen < 9) {
+ assert(map->image_count <= MAX_GEN8_IMAGES);
assert(shader->num_uniforms == prog_data->nr_params * 4);
state.first_image_uniform = shader->num_uniforms;
uint32_t *param = brw_stage_prog_data_add_params(prog_data,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 770254e93ea..47878adb066 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -157,7 +157,8 @@ struct gen_l3_config;
#define MAX_SCISSORS16
#define MAX_PUSH_CONSTANTS_SIZE 128
#define MAX_DYNAMIC_BUFFERS 16
-#define MAX_IMAGES 8
+#define MAX_IMAGES 64
+#define MAX_GEN8_IMAGES 8
#define MAX_PUSH_DESCRIPTORS 32 /* Minimum requirement */
/* The kernel relocation API has a limitation of a 32-bit delta value
@@ -1883,7 +1884,7 @@ struct anv_push_constants {
uint32_t base_work_group_id[3];
/* Image data for image_load_store on pre-SKL */
- struct brw_image_param images[MAX_IMAGES];
+ struct brw_image_param images[MAX_GEN8_IMAGES];
};
struct anv_dynamic_state {
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's
Hi Marek,
Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > From: Christian Gmeiner
>
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.
>
> > Signed-off-by: Christian Gmeiner
> > Signed-off-by: Marek Vasut
> To: mesa-dev@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org
> ---
> Changes from v1 -> v2:
> - to remove the resource from the used_resources set when it is destroyed
> Changes from v2 -> v3:
> - add locking with mtx_*() to resource and screen (Marek)
> Changes from v3 -> v4:
> - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
> - simplify etna_resource_used() flush condition, which also prevents
> potentially flushing resources twice (Marek)
> - don't remove resouces from screen->used_resources in
> etna_cmd_stream_reset_notify(), they may still be used in other
> contexts and may need flushing there later on (Marek)
The patch mostly makes sense to me now, but don't we need to take the
screen->lock on all call sites where we do a ctx->flush? Otherwise we
may enter etna_cmd_stream_reset_notify unlocked, changing the
used_resources set while other threads might use it at the same time,
right?
Regards,
Lucas
> ---
> src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
> src/gallium/drivers/etnaviv/etnaviv_context.h | 3 --
> .../drivers/etnaviv/etnaviv_resource.c| 52 +++
> .../drivers/etnaviv/etnaviv_resource.h| 8 +--
> src/gallium/drivers/etnaviv/etnaviv_screen.c | 12 +
> src/gallium/drivers/etnaviv/etnaviv_screen.h | 6 +++
> 6 files changed, 78 insertions(+), 29 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 3038d21..2f8cae8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -36,6 +36,7 @@
> #include "etnaviv_query.h"
> #include "etnaviv_query_hw.h"
> #include "etnaviv_rasterizer.h"
> +#include "etnaviv_resource.h"
> #include "etnaviv_screen.h"
> #include "etnaviv_shader.h"
> #include "etnaviv_state.h"
> @@ -329,7 +330,8 @@ static void
> etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
> {
> struct etna_context *ctx = priv;
> - struct etna_resource *rsc, *rsc_tmp;
> + struct etna_screen *screen = ctx->screen;
> + struct set_entry *entry;
>
> etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream
> *stream, void *priv)
> ctx->dirty = ~0L;
> ctx->dirty_sampler_views = ~0L;
>
> - /* go through all the used resources and clear their status flag */
> - LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, >used_resources, list)
> - {
> - debug_assert(rsc->status != 0);
> - rsc->status = 0;
> - rsc->pending_ctx = NULL;
> - list_delinit(>list);
> - }
> + /*
> +* Go through all _resources_ associated with this _screen_, pending
> +* in this _context_ and mark them as not pending in this _context_
> +* anymore, since they were just flushed.
> +*/
> + mtx_lock(>lock);
> + set_foreach(screen->used_resources, entry) {
> + struct etna_resource *rsc = (struct etna_resource *)entry->key;
>
> - assert(LIST_IS_EMPTY(>used_resources));
> + _mesa_set_remove_key(rsc->pending_ctx, ctx);
> + }
> + mtx_unlock(>lock);
> }
>
> static void
> @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void
> *priv, unsigned flags)
> /* need some sane default in case state tracker doesn't set some state: */
> ctx->sample_mask = 0x;
>
> - list_inithead(>used_resources);
> -
> /* Set sensible defaults for state */
> etna_cmd_stream_reset_notify(ctx->stream, ctx);
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 584caa7..eff0a23 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -136,9 +136,6 @@ struct etna_context {
> uint32_t prim_hwsupport;
> struct primconvert_context *primconvert;
>
> - /* list of resources used by currently-unsubmitted renders */
> - struct list_head used_resources;
> -
> struct slab_child_pool transfer_pool;
> struct blitter_context *blitter;
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 3808c29..46ab849 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -33,6 +33,7 @@
> #include "etnaviv_screen.h"
> #include "etnaviv_translate.h"
>
> +#include "util/hash_table.h"
> #include "util/u_inlines.h"
> #include "util/u_memory.h"
>
> @@ -275,7 +276,6 @@
Re: [Mesa-dev] [PATCH v3 3/3] radv: add support for VK_EXT_memory_budget
On Wed, Jan 9, 2019, 2:37 PM Samuel Pitoiset 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.
>
> v3: - use atomic operations in the winsys
> 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 | 38 +-
> .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 6 ++
> .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 4 ++
> 6 files changed, 124 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 279917f3e0c..4bf36f9f384 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,
> VkPhysicalDeviceMemoryProperties2 *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
> +++
Re: [Mesa-dev] [PATCH] bin/get-pick-list.sh: fix redirection in sh
On Fri, 2019-01-11 at 16:43 +0200, Andres Gomez wrote:
> "&>" is bash specific.
>
Reviewed-by: Juan A. Suarez
J.A.
> Fixes: e0dbfc99537 ("bin/get-pick-list.sh: warn when commit lists invalid
> sha")
> Cc: Juan A. Suarez
> Cc: Eric Engestrom
> Cc: Dylan Baker
> Cc: Emil Velikov
> Signed-off-by: Andres Gomez
> ---
> bin/get-pick-list.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> index 79b7a295ea6..3099fc69413 100755
> --- a/bin/get-pick-list.sh
> +++ b/bin/get-pick-list.sh
> @@ -44,7 +44,7 @@ is_sha_nomination()
> # Treat only the current line
> id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | cut -d :
> -f 2`
> fixes_count=$(($fixes_count-1))
> - if ! git show $id &>/dev/null; then
> + if ! git show $id >/dev/null 2>&1; then
> echo WARNING: Commit $1 lists invalid sha $id
> fi
> done
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] bin/get-pick-list.sh: fix the oneline printing
On Fri, 2019-01-11 at 16:42 +0200, Andres Gomez wrote:
> "--summary" will also print extended header information such as
> creations, renames and mode changes.
>
> Let's just use "-s", which suppresses the diff output.
Reviewed-by: Juan A. Suarez
J.A.
>
> Fixes: 559c32d2412 ("bin/get-pick-list.sh: simplify git oneline printing")
> Cc: Juan A. Suarez
> Cc: Eric Engestrom
> Cc: Dylan Baker
> Cc: Emil Velikov
> Signed-off-by: Andres Gomez
> ---
> bin/get-pick-list.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> index 3099fc69413..d71ff4a708a 100755
> --- a/bin/get-pick-list.sh
> +++ b/bin/get-pick-list.sh
> @@ -143,7 +143,7 @@ do
> esac
>
> printf "[ %8s ] " "$tag"
> - git --no-pager show --summary --oneline $sha
> + git --no-pager show -s --oneline $sha
> done
>
> rm -f already_picked
___
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 Mon, 2019-01-07 at 19:04 +0200, Andres Gomez wrote: > 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(-) Acked-by: Juan A. Suarez > > 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. > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa git break nvidia opencl
Hello Jan, clinfo shows a little bit of opencl info while no "mesa" card is with the machine. That's wrong: flatpak --command=/bin/bash run online.winehub.GPUViewer clinfo Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform VersionOpenCL 1.1 Mesa 18.3.1 Platform ProfileFULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name Clover Number of devices 0 NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) Clover clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) clCreateContext(NULL, ...) [default]No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No devices found in platform ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.12 ICD loader Profile OpenCL 2.2 AndyBe Am Samstag, den 12.01.2019, 16:39 -0500 schrieb Jan Vesely: > Hi, > > you're not very specific what 'break' means. Mesa libOpenCL.so does > not support loading additional opencl icd drivers. > It is, however, possible to use mesa as an icd driver > (libMesaOpenCL.so) which can be loaded by an icd loader, such as ocl- > icd, or other opencl drivers. > > Jan > > > On Thu, 2019-01-10 at 19:58 +0100, andreas.benz...@googlemail.com > wrote: > > Hello Everyone, > > > > at this moment I develop on freedesktop opencl. Current the mesa > > opencl > > break clinfo to read the information from nvidia when mesa opencl > > is > > available. There is no other graphic card plugged in. > > > > The stable 18.3.1 it works. > > > > Don't know how to analise this kind of problem. > > > > Sincerely > > > > AndyBe > > > > ___ > > 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
