[Mesa-dev] [PATCH] meson: fix private libs when building without glx
I noticed that the generated pkg-config files will include
glx and x11 dependencies even when x11 isn't a selected platform.
This fixes the private libs and was tested by building kmscube
---
meson.build | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/meson.build b/meson.build
index 4aafba802a..80bb8746b2 100644
--- a/meson.build
+++ b/meson.build
@@ -1339,18 +1339,24 @@ endforeach
inc_include = include_directories('include')
-gl_priv_reqs = [
- 'x11', 'xext', 'xdamage >= 1.1', 'xfixes', 'x11-xcb', 'xcb',
- 'xcb-glx >= 1.8.1']
+gl_priv_reqs = []
+
+if with_glx == 'xlib'
+ gl_priv_reqs += ['x11', 'xext', 'xcb']
+elif with_glx == 'dri'
+ gl_priv_reqs += [
+'x11', 'xext', 'xdamage >= 1.1', 'xfixes', 'x11-xcb', 'xcb',
+'xcb-glx >= 1.8.1']
+ if with_dri_platform == 'drm'
+gl_priv_reqs += 'xcb-dri2 >= 1.8'
+ endif
+endif
if dep_libdrm.found()
gl_priv_reqs += 'libdrm >= 2.4.75'
endif
if dep_xxf86vm.found()
gl_priv_reqs += 'xxf86vm'
endif
-if with_dri_platform == 'drm'
- gl_priv_reqs += 'xcb-dri2 >= 1.8'
-endif
gl_priv_libs = []
if dep_thread.found()
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106801] vma_random_test.cpp:239:18: error: non-constant-expression cannot be narrowed from type 'unsigned long' to 'uint_fast32_t' (aka 'unsigned int') in initializer list [-Wc++11-nar
https://bugs.freedesktop.org/show_bug.cgi?id=106801
Bug ID: 106801
Summary: vma_random_test.cpp:239:18: error:
non-constant-expression cannot be narrowed from type
'unsigned long' to 'uint_fast32_t' (aka 'unsigned
int') in initializer list [-Wc++11-narrowing]
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Mac OS X (All)
Status: NEW
Keywords: bisected, regression
Severity: normal
Priority: medium
Component: Other
Assignee: mesa-dev@lists.freedesktop.org
Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: bugzi...@sandyscott.net, ja...@jlekstrand.net
CXX vma_random_test-vma_random_test.o
vma_random_test.cpp:239:18: error: non-constant-expression cannot be narrowed
from type 'unsigned long' to 'uint_fast32_t' (aka 'unsigned int') in
initializer list [-Wc++11-narrowing]
random_test r{seed};
^~~~
vma_random_test.cpp:239:18: note: insert an explicit cast to silence this issue
random_test r{seed};
^~~~
static_cast( )
commit 943fecc5691b55b8ce8740d133dd70614effb72d
Author: Scott D Phillips
Date: Fri May 4 17:11:13 2018 -0700
util: Add a randomized test for the virtual memory allocator
The test pseudo-randomly makes allocations and deallocations with
the virtual memory allocator and checks that the results are
consistent. Specifically, we test that:
* no result from the allocator overlaps an already allocated range
* allocated memory fulfills the stated alignment requirement
* a failed result from the allocator could not have been fulfilled
* memory freed to the allocator can later be allocated again
v2: - fix if() in test() to actually run fill()
v3: - add c++11 build flag (Jason)
- test the full 64-bit range (Jason)
Reviewed-by: Jason Ekstrand
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import (v2)
Looks good to me. Tapani (CCd) would know wheter we want EXEC_OBJECT_ASYNC
or not. Either way (not setting EXEC_OBJECT_ASYNC won't hurt),
Reviewed-by: Jason Ekstrand
Sorry for the mess and thanks for fixing it!
--Jason
On Sun, Jun 3, 2018 at 5:38 PM, Mauro Rossi wrote:
> Changes to avoid building error:
>
> external/mesa/src/intel/vulkan/anv_android.c:131:72:
> error: too few arguments to function call, expected 5, have 4
>result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
> ~~~^
> 1 error generated.
>
> (v2) Set the correct bo_flags based on support of 48bit addresses and
> soft-pin
>
> Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in
> bo_cache_alloc/import")
> Fixes: e7d0378bd9 ("anv: Soft-pin client-allocated memory")
> Signed-off-by: Mauro Rossi
> ---
> src/intel/vulkan/anv_android.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_
> android.c
> index 7e07dbaaa4..8611e77b82 100644
> --- a/src/intel/vulkan/anv_android.c
> +++ b/src/intel/vulkan/anv_android.c
> @@ -128,7 +128,13 @@ anv_image_from_gralloc(VkDevice device_h,
> */
> int dma_buf = gralloc_info->handle->data[0];
>
> - result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
> + uint64_t bo_flags = 0;
> + if (device->instance->physicalDevice.supports_48bit_addresses)
> + bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> + if (device->instance->physicalDevice.use_softpin)
> + bo_flags |= EXEC_OBJECT_PINNED;
> +
> + result = anv_bo_cache_import(device, >bo_cache, dma_buf,
> bo_flags, );
> if (result != VK_SUCCESS) {
>return vk_errorf(device->instance, device, result,
> "failed to import dma-buf from
> VkNativeBufferANDROID");
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 069.1/129] FIXUP: move lower_deref_instrs
---
src/amd/vulkan/radv_pipeline.c | 4 ++--
src/amd/vulkan/radv_shader.c | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 59bbab714df..f4d076db795 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -2025,6 +2025,8 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
nir[i] = nir_shader_clone(NULL, nir[i]);
}
+ NIR_PASS_V(nir[i], nir_lower_deref_instrs, ~0);
+
if (first != last) {
nir_variable_mode mask = 0;
@@ -2034,8 +2036,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
if (i != last)
mask = mask | nir_var_shader_out;
- NIR_PASS_V(nir[i], nir_lower_deref_instrs, ~0);
-
if (!(flags &
VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT)) {
nir_lower_io_to_scalar_early(nir[i], mask);
radv_optimize_nir(nir[i], false);
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 61f141adffc..ff133ded722 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -250,8 +250,6 @@ radv_shader_compile_to_nir(struct radv_device *device,
assert(exec_list_length(>functions) == 1);
entry_point->name = ralloc_strdup(entry_point, "main");
- NIR_PASS_V(nir, nir_lower_deref_instrs, ~0);
-
/* Make sure we lower constant initializers on output variables
so that
* nir_remove_dead_variables below sees the corresponding stores
*/
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 073.1/129] FIXUP: nir: convert lower_io_arrays_to_elements to deref instructions
---
src/amd/vulkan/radv_pipeline.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 34249bf843d..375f7c357d3 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -2039,8 +2039,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
radv_optimize_nir(nir[i], false);
}
}
-
- NIR_PASS_V(nir[i], nir_lower_deref_instrs, ~0);
}
if (nir[MESA_SHADER_TESS_CTRL]) {
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import
Hi,
2018-06-04 0:31 GMT+02:00 Lionel Landwerlin :
> On 03/06/18 21:22, Mauro Rossi wrote:
>
> Hi there,
>
> 2018-06-03 21:52 GMT+02:00 Lionel Landwerlin <
> lionel.g.landwer...@intel.com>:
>
>> On 03/06/18 19:41, Mauro Rossi wrote:
>>
>>> Change to avoid building error:
>>>
>>> external/mesa/src/intel/vulkan/anv_android.c:131:72:
>>> error: too few arguments to function call, expected 5, have 4
>>> result = anv_bo_cache_import(device, >bo_cache, dma_buf,
>>> );
>>> ~~~^
>>> 1 error generated.
>>>
>>> Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in
>>> bo_cache_alloc/import")
>>> Signed-off-by: Mauro Rossi
>>> ---
>>> src/intel/vulkan/anv_android.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/intel/vulkan/anv_android.c
>>> b/src/intel/vulkan/anv_android.c
>>> index 7e07dbaaa4..ed5da5b537 100644
>>> --- a/src/intel/vulkan/anv_android.c
>>> +++ b/src/intel/vulkan/anv_android.c
>>> @@ -128,7 +128,7 @@ anv_image_from_gralloc(VkDevice device_h,
>>> */
>>> int dma_buf = gralloc_info->handle->data[0];
>>> - result = anv_bo_cache_import(device, >bo_cache, dma_buf,
>>> );
>>> + result = anv_bo_cache_import(device, >bo_cache, dma_buf, 0,
>>> );
>>>
>>
>> If you look at anv_intel.c here are the flags that we use :
>>
>>uint64_t bo_flags = 0;
>>if (device->instance->physicalDevice.supports_48bit_addresses)
>> bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
>>
>> I'm pretty sure we want the same, potentially also the async flag?
>
>
> Please I need review on the correctness or improvements,
> because I just put 0 as bo_flags as a deduction based on similar change
> in src/intel/vulkan/anv_queue.c where in anv_bo_cache_import() call the
> bo_flag was set to 0
>
> Thanks
> M.
>
>
> Here is what looks good to me (maybe Jason can confirm) :
>
>uint64_t bo_flags = 0;
>if (device->instance->physicalDevice.supports_48bit_addresses)
> bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
>if (pdevice->use_softpin) /* You'll need to grab a pointer to the
> physical device here */
>
The above expression should be ok:
if (device->instance->physicalDevice.use_softpin)
If all builds I'm sending v2 of PATCH 1/2 soon
Thanks
Mauro
>
>
bo_flags |= EXEC_OBJECT_PINNED;
>
> anv_queue.c is for fences which are buffers we don't actually touch for
> the GPU.
> They're just used for creating/dealing with dependency graph of workloads.
>
> It seems anv_intel.c needs updating, or maybe we should just drop that
> extensions now that we have other means of importing BOs.
>
> Thanks for looking into this,
>
> -
> Lionel
>
>
>
>>
>>
>> if (result != VK_SUCCESS) {
>>> return vk_errorf(device->instance, device, result,
>>> "failed to import dma-buf from
>>> VkNativeBufferANDROID");
>>>
>>
>>
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx
Perhaps just have the archive as a separate repo that gets pulled in by the main ci yaml at build, just to populate the archives directory? This avoids any possible submodule breakage (just not worth it here IMO), with no chance of accidentally pulling down all the archives. I know a few people who have git shortcuts that update submodules by default for example, whether they exist or not. Also I personally think the archives dir needs a bit of re-org/cleanup to make it a bit more persistent over time (eg: like moving the old stuff into the older-versions dir effectively breaks links for distros, etc). That's getting more into content, but it'd be worth exploring if that should/would get done before or after the move to a git repo (ie: would it being in git make the process harder/a nightmare if it was to happen). On 4 June 2018 at 06:19, Daniel Stone wrote: > Hi Laura, > > On 25 May 2018 at 01:27, Laura Ekstrand wrote: > > When reviewing these patches, please note: > > 1. This patch series does *not* touch content. Please do not > bikeshed > >the content of webpages here. That will be addressed in later > >commits. > > 2. Please do *not* bikeshed website style here. We are using the > >classic ReadTheDocs style for now and we will update style in > a > >future commit. > > 3. I've done my best to make your current content look > beautiful. If > >there's a problem, please let me know. > > 4. There were some commits to the website between when I started > this > >series and now. I've done my best to incorporate your changes. > >So if you changed your content in the past two weeks, take a > look > >at your page. > > One thing I've just remembered is that https://www.mesa3d.org/archive/ > serves all the tarballs for Mesa releases. Given how Pages is > structured, we don't have a good way to redirect these to the old > server, so the Pages repository needs to hold all the tarballs. This > probably suggests to me that the site should live in a different repo, > where we can just commit all the tarballs. > > I reflexively didn't love the idea of committing tarballs to a git > repository, but the more I think about it, the more I like the idea. > It makes it more clear where they're coming from, makes the provenance > easier to verify, gives us audit logs of who put them in, and so on. > > Cheers, > Daniel > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 066.9/129] radv: Disable lower_io_to_temporaries during deref changes.
The ordering of passes is such that this already generates deref_var
based stores before the lower_io_to_scalar pass is ready for it.
---
src/amd/vulkan/radv_shader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 68f2a55e810..42623c950b7 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -278,6 +278,8 @@ radv_shader_compile_to_nir(struct radv_device *device,
nir_lower_vars_to_ssa(nir);
+ /* Temporarily disabled during deref changes */
+#if 0
if (nir->info.stage == MESA_SHADER_VERTEX ||
nir->info.stage == MESA_SHADER_GEOMETRY) {
NIR_PASS_V(nir, nir_lower_io_to_temporaries,
@@ -287,6 +289,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
NIR_PASS_V(nir, nir_lower_io_to_temporaries,
nir_shader_get_entrypoint(nir), true, false);
}
+#endif
nir_split_var_copies(nir);
nir_lower_var_copies(nir);
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 111.1/129] FIXUP: ac/nir: Add deref support to image intrinsics.
---
When removing the deref chain support you'll probably get a rebase conflict.
src_shift + 2 has to become 3 there.
src/amd/common/ac_nir_to_llvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index de4779026a7..d23d3cd5f2e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2353,7 +2353,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
} else {
struct ac_image_args args = {};
args.opcode = ac_image_store;
- args.data[0] = ac_to_float(>ac, get_src(ctx,
instr->src[2]));
+ args.data[0] = ac_to_float(>ac, get_src(ctx,
instr->src[src_shift + 2]));
get_image_coords(ctx, instr, );
args.resource = get_image_descriptor(ctx, instr, AC_DESC_IMAGE,
true);;
args.dim = get_ac_image_dim(>ac,
glsl_get_sampler_dim(type),
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import (v2)
Changes to avoid building error:
external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
~~~^
1 error generated.
(v2) Set the correct bo_flags based on support of 48bit addresses and soft-pin
Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Fixes: e7d0378bd9 ("anv: Soft-pin client-allocated memory")
Signed-off-by: Mauro Rossi
---
src/intel/vulkan/anv_android.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..8611e77b82 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,13 @@ anv_image_from_gralloc(VkDevice device_h,
*/
int dma_buf = gralloc_info->handle->data[0];
- result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
+ uint64_t bo_flags = 0;
+ if (device->instance->physicalDevice.supports_48bit_addresses)
+ bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ if (device->instance->physicalDevice.use_softpin)
+ bo_flags |= EXEC_OBJECT_PINNED;
+
+ result = anv_bo_cache_import(device, >bo_cache, dma_buf, bo_flags,
);
if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
"failed to import dma-buf from VkNativeBufferANDROID");
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 070.1/129] FIXUP: nir: convert lower_io_to_scalar to deref instructions
---
src/amd/vulkan/radv_pipeline.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 43719449784..34249bf843d 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -2025,8 +2025,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
nir[i] = nir_shader_clone(NULL, nir[i]);
}
- NIR_PASS_V(nir[i], nir_lower_deref_instrs, ~0);
-
if (first != last) {
nir_variable_mode mask = 0;
@@ -2040,9 +2038,9 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
nir_lower_io_to_scalar_early(nir[i], mask);
radv_optimize_nir(nir[i], false);
}
-
- NIR_PASS_V(nir[i], nir_lower_deref_instrs, ~0);
}
+
+ NIR_PASS_V(nir[i], nir_lower_deref_instrs, ~0);
}
if (nir[MESA_SHADER_TESS_CTRL]) {
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 000/129] nir: Move to using instructions for derefs
On Sat, Jun 2, 2018 at 2:48 AM, Rob Clark wrote: > On Fri, Jun 1, 2018 at 1:01 AM, Jason Ekstrand wrote: >> This is something that Connor and I have been talking about for some time >> now. The basic idea is to replace the current singly linked nir_deref list >> with deref instructions. This is similar to what LLVM does and it offers >> quite a bit more freedom when we start getting more realistic pointers from >> compute applications. >> >> Right now, we still have a fully "logical" pointer model where pointer >> chains eventually terminate at variable dereferences. In future, we'd like >> to be able to use nir_deref_instrs for things like UBOs and SSBOs where tha >> tmay not be the case. There are still a couple open questions around how >> we want to handle "raw" pointers in SPIR-V for OpenCL drivers particularly >> around casting. However, the hard part is getting the deref instructions >> and getting everything switched over to them. Now that we've done that, >> some of those other details can be sorted out later. >> >> This series is, as far as Rob, Bas, and I can tell, a complete and correct >> transition for all NIR-based drivers. The final patch deletes the data >> structures and helpers for the older deref chains. >> >> A massive thank you goes out to Rob for putting the final patch set >> together and trying to get things in an order that will hopefully not >> regress anyone. Thanks also to Bas for fixing up the radeon and radv >> bits. >> >> This series can be found as a branch on gitlab: >> >> https://gitlab.freedesktop.org/jekstrand/mesa/commits/review/nir-deref-instr-v4 >> >> Ideally, I'd like the series to get some amount of real review before it >> lands. Honestly, it's been baking long enough and tested by enough people >> on enough drivers that we can probably throw a bunch of Acked-by and >> Tested-bys on it and call it a day but I'd rather not. I plan to review >> all of the patches I didn't write but that will have to wait until >> tomorrow. >> >> At the very least, I'd like some sort of an ACK from a variety of the >> people that use NIR on the core concept and the sort of general shape of >> things at the end of the series. A lot of work has gone into this but it's >> also a big change and the more positive feedback it gets, the more >> comfortable I'll be pulling the trigger. > > fwiw, with the issues that Bas hit, strong a-b from me.. With the fixups I just sent (and which the list will hopefully pick up soon ...) and the mentioned patch moves in the cover letter (and Daves r-b applied on the original AMD patches?), this series is acked-by me. - Bas > > I've been working with the patchset for a while, (and a big stack of > compute related patches on top that I'd like to be able to start > sending to list) and the handful of comments made on irc in the early > stages have been addressed. This makes for a much cleaner base to > start adding "real" pointer support for compute, so I'm totally happy, > it works out much cleaner than earlier attempts based on working > around deref chains :-) > > not a traditional patch-by-patch review, so not really sure r-b is > appropriate, but I'm pretty happy with the result (and the amount of > churn involved does make tranditional patch-by-patch review difficult) > > BR, > -R > >> >> Thanks, >> >> --Jason Ekstrand >> >> >> >> Cc: Rob Clark >> Cc: Timothy Arceri >> Cc: Eric Anholt >> Cc: Connor Abbott >> Cc: Bas Nieuwenhuizen >> Cc: Karol Herbst >> Cc: Matt Turner >> Cc: Kenneth Graunke >> Cc: Ian Romanick >> >> Bas Nieuwenhuizen (16): >> ac/nir: Implement the deref instr for shared memory. >> ac/nir: Support deref instructions in get_sampler_desc. >> ac/nir: Support deref instructions in tex instructions. >> ac/nir: Implement derefs for integer gather4 lowering. >> ac/nir: Add deref support to image intrinsics. >> radv: Add shader info support for image deref instructions. >> ac/nir: Add deref based var loads/stores. >> radv: Gather info for deref instr based load/store. >> ac/nir: Add shared atomic deref instr support. >> ac/nir: Add deref interp support. >> radv: Use deref instructions for tex derefs in meta shaders. >> radv: Remove image_var stores. >> radeonsi: Add deref support to the nir scan pass. >> ac/nir: Remove deref chain support. >> radv: Remove deref chain support in radv shader info pass. >> radeonsi: Remove deref chain support in nir scan pass. >> >> Eric Anholt (1): >> broadcom/vc4: Remove deref chain support from nir_lower_txf_ms. >> >> Jason Ekstrand (98): >> nir/validate: Rework intrinsic type validation >> nir: Add a deref instruction type >> nir/builder: Add deref building helpers >> nir: Add _deref versions of all of the _var intrinsics >> nir: Add deref sources to texture instructions >> nir: Add helpers for working with deref instructions >> nir/deref: Add some deref cleanup functions >> anv,i965,radv,st,ir3: Call nir_lower_deref_instrs >>
[Mesa-dev] [PATCH 038.1/129] FIXUP: nir: Support deref instructions in opt_undef
---
src/compiler/nir/nir_opt_undef.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_opt_undef.c b/src/compiler/nir/nir_opt_undef.c
index 1439ca9c165..e42a9af2bdf 100644
--- a/src/compiler/nir/nir_opt_undef.c
+++ b/src/compiler/nir/nir_opt_undef.c
@@ -107,20 +107,24 @@ opt_undef_vecN(nir_builder *b, nir_alu_instr *alu)
static bool
opt_undef_store(nir_intrinsic_instr *intrin)
{
+ int arg_index;
switch (intrin->intrinsic) {
case nir_intrinsic_store_deref:
+ arg_index = 1;
+ break;
case nir_intrinsic_store_var:
case nir_intrinsic_store_output:
case nir_intrinsic_store_per_vertex_output:
case nir_intrinsic_store_ssbo:
case nir_intrinsic_store_shared:
+ arg_index = 0;
break;
default:
return false;
}
- if (!intrin->src[0].is_ssa ||
- intrin->src[0].ssa->parent_instr->type != nir_instr_type_ssa_undef)
+ if (!intrin->src[arg_index].is_ssa ||
+ intrin->src[arg_index].ssa->parent_instr->type !=
nir_instr_type_ssa_undef)
return false;
nir_instr_remove(>instr);
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] anv/android: Use an address for each anv_image plane
On 03/06/18 19:41, Mauro Rossi wrote:
Fixes to avoid building error after change in image->planes[] structure,
{bo,bo_offset} has to be replaced by address.{bo,offset}
and update is needed also in the assert() for debug builds.
external/mesa/src/intel/vulkan/anv_android.c:188:21:
error: no member named 'bo' in 'struct anv_image::(anonymous at
external/mesa/src/intel/vulkan/anv_private.h:2647:4)'
image->planes[0].bo = bo;
^
1 error generated.
Fixes: bf34ef16ac ("anv: Use an address for each anv_image plane")
Signed-off-by: Mauro Rossi
Thanks for the fix!
Reviewed-by: Lionel Landwerlin
---
src/intel/vulkan/anv_android.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index ed5da5b537..45a21dcfc3 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -183,9 +183,9 @@ anv_image_from_gralloc(VkDevice device_h,
}
assert(image->n_planes == 1);
- assert(image->planes[0].bo_offset == 0);
+ assert(image->planes[0].address.offset == 0);
- image->planes[0].bo = bo;
+ image->planes[0].address.bo = bo;
image->planes[0].bo_is_owned = true;
/* We need to set the WRITE flag on window system buffers so that GEM will
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 077.1/129] FIXUP: st, ir3, radeonsi: push lower_deref_instrs back into driver
Wrong place and we don't need it anymore anyway. --- src/gallium/drivers/radeonsi/si_compute.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_compute.c b/src/gallium/drivers/radeonsi/si_compute.c index a27e6284adb..e20bae0afc4 100644 --- a/src/gallium/drivers/radeonsi/si_compute.c +++ b/src/gallium/drivers/radeonsi/si_compute.c @@ -105,8 +105,6 @@ static void si_create_compute_state_async(void *job, int thread_index) assert(program->ir_type == PIPE_SHADER_IR_NIR); sel.nir = program->ir.nir; - NIR_PASS_V(sel.nir, nir_lower_deref_instrs, ~0); - si_nir_scan_shader(sel.nir, ); si_lower_nir(); } -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 000/129] AMD Fixups for the deref patches.
These are some fixes for v4 of Jasons deref instruction series.
Furthermore patches 107-119:
radv: Remove image_var stores.
radv: Use deref instructions for tex derefs in meta shaders.
radeonsi: Add deref support to the nir scan pass.
ac/nir: Add deref interp support.
ac/nir: Add shared atomic deref instr support.
radv: Gather info for deref instr based load/store.
ac/nir: Add deref based var loads/stores.
radv: Add shader info support for image deref instructions.
ac/nir: Add deref support to image intrinsics.
ac/nir: Implement derefs for integer gather4 lowering.
ac/nir: Support deref instructions in tex instructions.
ac/nir: Support deref instructions in get_sampler_desc.
ac/nir: Implement the deref instr for shared memory.
have to be moved to directly before patch 54
("anv/pipeline: Do less deref instruction lowering").
With that the series has no regressions and should be fully
bisectable without regressions on radv.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv/android: Set the BO flags in bo_cache_import (v2)
Changes to avoid building error:
external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
~~~^
1 error generated.
(v2) Set the correct bo_flags based on support of 48bit addresses and soft-pin
Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Fixes: e7d0378bd9 ("anv: Soft-pin client-allocated memory")
Signed-off-by: Mauro Rossi
---
src/intel/vulkan/anv_android.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..6e4d5a6d27 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,13 @@ anv_image_from_gralloc(VkDevice device_h,
*/
int dma_buf = gralloc_info->handle->data[0];
- result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
+ uint64_t bo_flags = 0;
+ if (device->instance->physicalDevice.supports_48bit_addresses)
+ bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ if (device->instance->physicalDevice.use_softpin)
+ bo_flags |= EXEC_OBJECT_PINNED;
+
+ result = anv_bo_cache_import(device, >bo_cache, dma_buf, bo_flags,
);
if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
"failed to import dma-buf from VkNativeBufferANDROID");
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import
On June 3, 2018 15:31:11 Lionel Landwerlin
wrote:
On 03/06/18 21:22, Mauro Rossi wrote:
Hi there,
2018-06-03 21:52 GMT+02:00 Lionel Landwerlin :
On 03/06/18 19:41, Mauro Rossi wrote:
Change to avoid building error:
external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
~~~^
1 error generated.
Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Signed-off-by: Mauro Rossi
---
src/intel/vulkan/anv_android.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..ed5da5b537 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,7 @@ anv_image_from_gralloc(VkDevice device_h,
*/
int dma_buf = gralloc_info->handle->data[0];
- result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
+ result = anv_bo_cache_import(device, >bo_cache, dma_buf, 0, );
If you look at anv_intel.c here are the flags that we use :
uint64_t bo_flags = 0;
if (device->instance->physicalDevice.supports_48bit_addresses)
bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
I'm pretty sure we want the same, potentially also the async flag?
Please I need review on the correctness or improvements,
because I just put 0 as bo_flags as a deduction based on similar change
in src/intel/vulkan/anv_queue.c where in anv_bo_cache_import() call the
bo_flag was set to 0
Thanks
M.
Here is what looks good to me (maybe Jason can confirm) :
uint64_t bo_flags = 0;
if (device->instance->physicalDevice.supports_48bit_addresses)
bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
if (pdevice->use_softpin) /* You'll need to grab a pointer to the physical
device here */
bo_flags |= EXEC_OBJECT_PINNED;
That looks good to me. Sorry about the mess.
anv_queue.c is for fences which are buffers we don't actually touch for the
GPU.
They're just used for creating/dealing with dependency graph of workloads.
It seems anv_intel.c needs updating, or maybe we should just drop that
extensions now that we have other means of importing BOs.
Thanks for looking into this,
-
Lionel
if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
"failed to import dma-buf from VkNativeBufferANDROID");
___
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 129.5/129] radv: Enable lower_io_to_temporaries after deref changes.
---
src/amd/vulkan/radv_shader.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index ff133ded722..929348d5e50 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -286,8 +286,6 @@ radv_shader_compile_to_nir(struct radv_device *device,
nir_lower_vars_to_ssa(nir);
- /* Temporarily disabled during deref changes */
-#if 0
if (nir->info.stage == MESA_SHADER_VERTEX ||
nir->info.stage == MESA_SHADER_GEOMETRY) {
NIR_PASS_V(nir, nir_lower_io_to_temporaries,
@@ -297,7 +295,6 @@ radv_shader_compile_to_nir(struct radv_device *device,
NIR_PASS_V(nir, nir_lower_io_to_temporaries,
nir_shader_get_entrypoint(nir), true, false);
}
-#endif
nir_split_var_copies(nir);
nir_lower_var_copies(nir);
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import
On 03/06/18 21:22, Mauro Rossi wrote:
Hi there,
2018-06-03 21:52 GMT+02:00 Lionel Landwerlin
mailto:lionel.g.landwer...@intel.com>>:
On 03/06/18 19:41, Mauro Rossi wrote:
Change to avoid building error:
external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache,
dma_buf, );
~~~ ^
1 error generated.
Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in
bo_cache_alloc/import")
Signed-off-by: Mauro Rossi mailto:issor.or...@gmail.com>>
---
src/intel/vulkan/anv_android.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_android.c
b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..ed5da5b537 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,7 @@ anv_image_from_gralloc(VkDevice device_h,
*/
int dma_buf = gralloc_info->handle->data[0];
- result = anv_bo_cache_import(device, >bo_cache,
dma_buf, );
+ result = anv_bo_cache_import(device, >bo_cache,
dma_buf, 0, );
If you look at anv_intel.c here are the flags that we use :
uint64_t bo_flags = 0;
if (device->instance->physicalDevice.supports_48bit_addresses)
bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
I'm pretty sure we want the same, potentially also the async flag?
Please I need review on the correctness or improvements,
because I just put 0 as bo_flags as a deduction based on similar change
in src/intel/vulkan/anv_queue.c where in anv_bo_cache_import() call
the bo_flag was set to 0
Thanks
M.
Here is what looks good to me (maybe Jason can confirm) :
uint64_t bo_flags = 0;
if (device->instance->physicalDevice.supports_48bit_addresses)
bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
if (pdevice->use_softpin) /* You'll need to grab a pointer to the
physical device here */
bo_flags |= EXEC_OBJECT_PINNED;
anv_queue.c is for fences which are buffers we don't actually touch for
the GPU.
They're just used for creating/dealing with dependency graph of workloads.
It seems anv_intel.c needs updating, or maybe we should just drop that
extensions now that we have other means of importing BOs.
Thanks for looking into this,
-
Lionel
if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
"failed to import dma-buf from
VkNativeBufferANDROID");
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako
https://bugs.freedesktop.org/show_bug.cgi?id=106784 Matt Turner changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com |org | -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import
Hi there,
2018-06-03 21:52 GMT+02:00 Lionel Landwerlin
:
> On 03/06/18 19:41, Mauro Rossi wrote:
>
>> Change to avoid building error:
>>
>> external/mesa/src/intel/vulkan/anv_android.c:131:72:
>> error: too few arguments to function call, expected 5, have 4
>> result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
>> ~~~^
>> 1 error generated.
>>
>> Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in
>> bo_cache_alloc/import")
>> Signed-off-by: Mauro Rossi
>> ---
>> src/intel/vulkan/anv_android.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/vulkan/anv_android.c
>> b/src/intel/vulkan/anv_android.c
>> index 7e07dbaaa4..ed5da5b537 100644
>> --- a/src/intel/vulkan/anv_android.c
>> +++ b/src/intel/vulkan/anv_android.c
>> @@ -128,7 +128,7 @@ anv_image_from_gralloc(VkDevice device_h,
>> */
>> int dma_buf = gralloc_info->handle->data[0];
>> - result = anv_bo_cache_import(device, >bo_cache, dma_buf,
>> );
>> + result = anv_bo_cache_import(device, >bo_cache, dma_buf, 0,
>> );
>>
>
> If you look at anv_intel.c here are the flags that we use :
>
>uint64_t bo_flags = 0;
>if (device->instance->physicalDevice.supports_48bit_addresses)
> bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
>
> I'm pretty sure we want the same, potentially also the async flag?
Please I need review on the correctness or improvements,
because I just put 0 as bo_flags as a deduction based on similar change
in src/intel/vulkan/anv_queue.c where in anv_bo_cache_import() call the
bo_flag was set to 0
Thanks
M.
>
>
> if (result != VK_SUCCESS) {
>> return vk_errorf(device->instance, device, result,
>> "failed to import dma-buf from
>> VkNativeBufferANDROID");
>>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx
Hi Laura, On 25 May 2018 at 01:27, Laura Ekstrand wrote: > When reviewing these patches, please note: > 1. This patch series does *not* touch content. Please do not bikeshed >the content of webpages here. That will be addressed in later >commits. > 2. Please do *not* bikeshed website style here. We are using the >classic ReadTheDocs style for now and we will update style in a >future commit. > 3. I've done my best to make your current content look beautiful. If >there's a problem, please let me know. > 4. There were some commits to the website between when I started this >series and now. I've done my best to incorporate your changes. >So if you changed your content in the past two weeks, take a look >at your page. One thing I've just remembered is that https://www.mesa3d.org/archive/ serves all the tarballs for Mesa releases. Given how Pages is structured, we don't have a good way to redirect these to the old server, so the Pages repository needs to hold all the tarballs. This probably suggests to me that the site should live in a different repo, where we can just commit all the tarballs. I reflexively didn't love the idea of committing tarballs to a git repository, but the more I think about it, the more I like the idea. It makes it more clear where they're coming from, makes the provenance easier to verify, gives us audit logs of who put them in, and so on. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import
On 03/06/18 19:41, Mauro Rossi wrote:
Change to avoid building error:
external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
~~~^
1 error generated.
Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Signed-off-by: Mauro Rossi
---
src/intel/vulkan/anv_android.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..ed5da5b537 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,7 @@ anv_image_from_gralloc(VkDevice device_h,
*/
int dma_buf = gralloc_info->handle->data[0];
- result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
+ result = anv_bo_cache_import(device, >bo_cache, dma_buf, 0, );
If you look at anv_intel.c here are the flags that we use :
uint64_t bo_flags = 0;
if (device->instance->physicalDevice.supports_48bit_addresses)
bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
I'm pretty sure we want the same, potentially also the async flag?
if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
"failed to import dma-buf from VkNativeBufferANDROID");
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: use num_components wrappers in print/validate.
Rb
On June 3, 2018 12:41:04 Dave Airlie wrote:
From: Dave Airlie
These wrappers were introduces, so start using them.
---
src/compiler/nir/nir_print.c| 4 +---
src/compiler/nir/nir_validate.c | 16
2 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index fad274e62f6..7c3e93eb82a 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -199,9 +199,7 @@ print_alu_src(nir_alu_instr *instr, unsigned src,
print_state *state)
}
}
- unsigned live_channels = instr->src[src].src.is_ssa
- ? instr->src[src].src.ssa->num_components
- : instr->src[src].src.reg.reg->num_components;
+ unsigned live_channels = nir_src_num_components(instr->src[src].src);
if (print_swizzle || used_channels != live_channels) {
fprintf(fp, ".");
diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index eee737e8069..abfd1712b39 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -228,15 +228,9 @@ validate_alu_src(nir_alu_instr *instr, unsigned index,
validate_state *state)
{
nir_alu_src *src = >src[index];
- unsigned num_components;
- if (src->src.is_ssa) {
- num_components = src->src.ssa->num_components;
- } else {
- if (src->src.reg.reg->is_packed)
- num_components = 4; /* can't check anything */
- else
- num_components = src->src.reg.reg->num_components;
- }
+ unsigned num_components = nir_src_num_components(src->src);
+ if (!src->src.is_ssa && src->src.reg.reg->is_packed)
+ num_components = 4; /* can't check anything */
for (unsigned i = 0; i < 4; i++) {
validate_assert(state, src->swizzle[i] < 4);
@@ -333,9 +327,7 @@ validate_alu_dest(nir_alu_instr *instr, validate_state
*state)
{
nir_alu_dest *dest = >dest;
- unsigned dest_size =
- dest->dest.is_ssa ? dest->dest.ssa.num_components
-: dest->dest.reg.reg->num_components;
+ unsigned dest_size = nir_dest_num_components(dest->dest);
bool is_packed = !dest->dest.is_ssa && dest->dest.reg.reg->is_packed;
/*
* validate that the instruction doesn't write to components not in the
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: use num_components wrappers in print/validate.
From: Dave Airlie
These wrappers were introduces, so start using them.
---
src/compiler/nir/nir_print.c| 4 +---
src/compiler/nir/nir_validate.c | 16
2 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index fad274e62f6..7c3e93eb82a 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -199,9 +199,7 @@ print_alu_src(nir_alu_instr *instr, unsigned src,
print_state *state)
}
}
- unsigned live_channels = instr->src[src].src.is_ssa
- ? instr->src[src].src.ssa->num_components
- : instr->src[src].src.reg.reg->num_components;
+ unsigned live_channels = nir_src_num_components(instr->src[src].src);
if (print_swizzle || used_channels != live_channels) {
fprintf(fp, ".");
diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index eee737e8069..abfd1712b39 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -228,15 +228,9 @@ validate_alu_src(nir_alu_instr *instr, unsigned index,
validate_state *state)
{
nir_alu_src *src = >src[index];
- unsigned num_components;
- if (src->src.is_ssa) {
- num_components = src->src.ssa->num_components;
- } else {
- if (src->src.reg.reg->is_packed)
- num_components = 4; /* can't check anything */
- else
- num_components = src->src.reg.reg->num_components;
- }
+ unsigned num_components = nir_src_num_components(src->src);
+ if (!src->src.is_ssa && src->src.reg.reg->is_packed)
+ num_components = 4; /* can't check anything */
for (unsigned i = 0; i < 4; i++) {
validate_assert(state, src->swizzle[i] < 4);
@@ -333,9 +327,7 @@ validate_alu_dest(nir_alu_instr *instr, validate_state
*state)
{
nir_alu_dest *dest = >dest;
- unsigned dest_size =
- dest->dest.is_ssa ? dest->dest.ssa.num_components
-: dest->dest.reg.reg->num_components;
+ unsigned dest_size = nir_dest_num_components(dest->dest);
bool is_packed = !dest->dest.is_ssa && dest->dest.reg.reg->is_packed;
/*
* validate that the instruction doesn't write to components not in the
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Make sure that imm draws are flushed before other draws execute.
Reviewed-by: Marek Olšák
Marek
On Sat, Jun 2, 2018 at 2:51 AM, wrote:
> From: Mathias Fröhlich
>
> Hi all,
>
> The below patch fixes a recently introduced failure of my VAO rework.
> I could finally reproduce the problem using the provided apitrace
> (thanks Kai for the hint with the lower left corner).
> The change is slightly different than what I put initially into the
> bugreport.
> The patch survived piglit quick and dEQP in radeonsi and did not
> introduce regressions to the base version with intels CI system.
>
> Please review!
>
> best
>
> Mathias
>
>
>
>
> The recent patch
>
> mesa: Remove FLUSH_VERTICES from VAO state changes.
>
> Pending draw calls on immediate mode or display list calls do
> not depend on changes of the VAO state. So, remove calls to
> FLUSH_VERTICES and flag _NEW_ARRAY as appropriate.
>
> uncovered a problem that non immediate mode draw calls do only
> flush outstanding immediate mode draws if FLUSH_UPDATE_CURRENT
> is set in ctx->Driver.NeedFlush.
> In that case, due to the sequence of _mesa_set_draw_vao commands
> we could end up with the VAO from the FLUSH_VERTICES call set
> into gl_context::Array._DrawVAO when the array draw is executed.
> So the change pulls FLUSH_CURRENT out of _mesa_validate_* calls
> into the array draw calls being validated.
> The change introduces a new macro FLUSH_FOR_DRAW beside FLUSH_VERTICES
> and FLUSH_CURRENT that flushes on changed current attributes as well
> as on outstanding immediate mode draw calls. Use FLUSH_FOR_DRAW
> in the non immediate mode draw code paths.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106594
> Signed-off-by: Mathias Fröhlich
> ---
> src/mesa/main/context.h | 16
> src/mesa/main/draw_validate.c | 26
> src/mesa/vbo/vbo_exec_array.c | 77 ++-
> src/mesa/vbo/vbo_save_draw.c | 2 +-
> 4 files changed, 56 insertions(+), 65 deletions(-)
>
> diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> index 77520f678f..d50438fd7f 100644
> --- a/src/mesa/main/context.h
> +++ b/src/mesa/main/context.h
> @@ -232,6 +232,22 @@ do {
> \
> ctx->NewState |= newstate; \
> } while (0)
>
> +/**
> + * Flush vertices.
> + *
> + * \param ctx GL context.
> + *
> + * Checks if dd_function_table::NeedFlush is marked to flush stored
> vertices
> + * or current state and calls dd_function_table::FlushVertices if so.
> + */
> +#define FLUSH_FOR_DRAW(ctx) \
> +do {\
> + if (MESA_VERBOSE & VERBOSE_STATE)\
> + _mesa_debug(ctx, "FLUSH_FOR_DRAW in %s\n", __func__); \
> + if (ctx->Driver.NeedFlush) \
> + vbo_exec_FlushVertices(ctx, ctx->Driver.NeedFlush); \
> +} while (0)
> +
> /**
> * Macro to assert that the API call was made outside the
> * glBegin()/glEnd() pair, with return value.
> diff --git a/src/mesa/main/draw_validate.c b/src/mesa/main/draw_validate.c
> index bcb2d91306..352263c5c7 100644
> --- a/src/mesa/main/draw_validate.c
> +++ b/src/mesa/main/draw_validate.c
> @@ -696,8 +696,6 @@ _mesa_validate_DrawElements(struct gl_context *ctx,
> GLenum mode, GLsizei count, GLenum type,
> const GLvoid *indices)
> {
> - FLUSH_CURRENT(ctx, 0);
> -
> return validate_DrawElements_common(ctx, mode, count, type, indices,
> "glDrawElements");
> }
> @@ -716,8 +714,6 @@ _mesa_validate_MultiDrawElements(struct gl_context
> *ctx,
> {
> GLsizei i;
>
> - FLUSH_CURRENT(ctx, 0);
> -
> /*
> * Section 2.3.1 (Errors) of the OpenGL 4.5 (Core Profile) spec says:
> *
> @@ -780,8 +776,6 @@ _mesa_validate_DrawRangeElements(struct gl_context
> *ctx, GLenum mode,
> GLsizei count, GLenum type,
> const GLvoid *indices)
> {
> - FLUSH_CURRENT(ctx, 0);
> -
> if (end < start) {
>_mesa_error(ctx, GL_INVALID_VALUE, "glDrawRangeElements(end<
> start)");
>return GL_FALSE;
> @@ -895,8 +889,6 @@ static bool
> validate_draw_arrays(struct gl_context *ctx, const char *func,
> GLenum mode, GLsizei count, GLsizei numInstances)
> {
> - FLUSH_CURRENT(ctx, 0);
> -
> if (count < 0) {
>_mesa_error(ctx, GL_INVALID_VALUE, "%s(count)", func);
>return false;
> @@ -971,8 +963,6 @@ _mesa_validate_MultiDrawArrays(struct gl_context
> *ctx, GLenum mode,
> {
> int i;
>
> - FLUSH_CURRENT(ctx, 0);
> -
> if (!_mesa_valid_prim_mode(ctx, mode, "glMultiDrawArrays"))
>return false;
>
> @@ -1018,8 +1008,6 @@ _mesa_validate_DrawElementsInstanced(struct
> gl_context *ctx,
> GLenum mode, GLsizei count, GLenum
> type,
> const
[Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import
Change to avoid building error:
external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
~~~^
1 error generated.
Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Signed-off-by: Mauro Rossi
---
src/intel/vulkan/anv_android.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..ed5da5b537 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,7 @@ anv_image_from_gralloc(VkDevice device_h,
*/
int dma_buf = gralloc_info->handle->data[0];
- result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
+ result = anv_bo_cache_import(device, >bo_cache, dma_buf, 0, );
if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
"failed to import dma-buf from VkNativeBufferANDROID");
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] anv/android: Use an address for each anv_image plane
Fixes to avoid building error after change in image->planes[] structure,
{bo,bo_offset} has to be replaced by address.{bo,offset}
and update is needed also in the assert() for debug builds.
external/mesa/src/intel/vulkan/anv_android.c:188:21:
error: no member named 'bo' in 'struct anv_image::(anonymous at
external/mesa/src/intel/vulkan/anv_private.h:2647:4)'
image->planes[0].bo = bo;
^
1 error generated.
Fixes: bf34ef16ac ("anv: Use an address for each anv_image plane")
Signed-off-by: Mauro Rossi
---
src/intel/vulkan/anv_android.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index ed5da5b537..45a21dcfc3 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -183,9 +183,9 @@ anv_image_from_gralloc(VkDevice device_h,
}
assert(image->n_planes == 1);
- assert(image->planes[0].bo_offset == 0);
+ assert(image->planes[0].address.offset == 0);
- image->planes[0].bo = bo;
+ image->planes[0].address.bo = bo;
image->planes[0].bo_is_owned = true;
/* We need to set the WRITE flag on window system buffers so that GEM will
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] vbo: Reestablish VAO limit checking on imm VAOs.
Am Sa., 2. Juni 2018 um 08:53 Uhr schrieb :
>
> From: Mathias Fröhlich
>
> Bail out with out of memory, when the required stride exceeds the
> maximum possible stride as stored in Const.MaxVertexAttribStride.
> Etnaviv can only handle less than the OpenGL standard mandated
> minimum of 2048. For this one, at least give some 'resource
> exhaustion error' to the application.
> The virgl driver provides 0 for Const.MaxVertexAttribStride
> as it may not be able to query the relevant informatition from the
> underlying OpenGL stack. In this case we just make the assumption
> that the underlying OpenGL stack is able to cope with then commonly
> seen small strides. Note that this is the same than what applications
> had to do before the queries to GL_MAX_VERTEX_ATTRIB_STRIDE, they had to
> hope for the best that the driver and hardware can safely handle the
> used stride values.
>
> Signed-off-by: Mathias Fröhlich
> ---
> src/mesa/vbo/vbo_exec_draw.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
> index 8d74725db3..0ab9a0d3ea 100644
> --- a/src/mesa/vbo/vbo_exec_draw.c
> +++ b/src/mesa/vbo/vbo_exec_draw.c
> @@ -177,6 +177,29 @@ vbo_exec_bind_arrays(struct gl_context *ctx)
> struct gl_vertex_array_object *vao = vbo->VAO;
> struct vbo_exec_context *exec = >exec;
>
> + const GLuint stride = exec->vtx.vertex_size*sizeof(GLfloat);
> +
> + /* Bail out with out of memory, when the required stride exceeds the
> +* maximum possible stride.
> +* Etnaviv can only handle less than the OpenGL standard mandated
> +* minimum of 2048. For this one, at least give some 'resource
> +* exhaustion error' to the application.
> +* The virgl driver provides 0 for Const.MaxVertexAttribStride
> +* as it may not be able to query the relevant informatition from the
> +* underlying OpenGL stack. In this case we just make the assumption
> +* that the underlying OpenGL stack is able to cope with then commonly
> +* seen small strides. Note that this is the same than what applications
> +* had to do before the queries to GL_MAX_VERTEX_ATTRIB_STRIDE, they had
> to
> +* hope for the best that the driver and hardware can safely handle the
> +* used stride values.
> +*/
Do we really need to duplicate the commit message text here? If the driver fetch
up e.g. by supporting other/newer GPUs with a more sane limit the patch author
needs to update this comment too.
> + if (ctx->Const.MaxVertexAttribStride &&
> + stride > ctx->Const.MaxVertexAttribStride) {
> + _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "Max VAO binding stride exceeded");
> + return;
> + }
> +
> GLintptr buffer_offset;
> if (_mesa_is_bufferobj(exec->vtx.bufferobj)) {
>assert(exec->vtx.bufferobj->Mappings[MAP_INTERNAL].Pointer);
> @@ -200,7 +223,6 @@ vbo_exec_bind_arrays(struct gl_context *ctx)
> assert((~vao_enabled & vao->_Enabled) == 0);
>
> /* Bind the buffer object */
> - const GLuint stride = exec->vtx.vertex_size*sizeof(GLfloat);
> _mesa_bind_vertex_buffer(ctx, vao, 0, exec->vtx.bufferobj, buffer_offset,
> stride);
>
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106687] radv: Fast color clears use incorrect format
https://bugs.freedesktop.org/show_bug.cgi?id=106687 --- Comment #1 from Edmondo Tommasina --- This patch fixes the issue in Elex with DXVK for me. Thanks. (Polaris, RX 470, radv) -- 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 00/16] Move the Mesa Website to Sphinx
On Sat, Jun 2, 2018 at 7:49 PM, Jason Ekstrand wrote: > With all this talk of fancy looking new websites, I decided to take a crack > at being artsy and coming up with a fancy-looking logo to put on it. Here's > a first rough draft: > > https://people.freedesktop.org/~jekstrand/gears-logo-bold.png > > It's not great but it turned out better than I expected. That version looks > good on a light background but it could probably be tweaked to look good on > dark/black if we want. it almost looks like the three corners of the "M" could fit in the holes in the gears.. not sure if that could be made to work by tweaking the width of the "M" or size of the gears, or if that just ends up worse.. (then someone just needs to make a 3d rotating model of mesa-gears with the gears running on axles extending from the M .. :-P) BR, -R > > --Jason > > > > On Fri, Jun 1, 2018 at 2:46 AM, Eric Engestrom > wrote: >> >> On Thursday, 2018-05-31 21:33:16 -0400, >> mesa-dev-boun...@lists.freedesktop.org wrote: >> > On Thu, May 31, 2018 at 8:31 PM, Jordan Justen >> > wrote: >> > > On 2018-05-31 16:06:13, Laura Ekstrand wrote: >> > >> A little bit of messing around this afternoon, led to this: >> > >> >> > >> https://drive.google.com/file/d/1rteTv9415XEMN1E11fyN0l3hTUCCbgwz/view?usp=sharing >> > > >> > > Nice. That confirms we can easily get back to a something closer to >> > > the older look in short order. (Unless the consensus is to actually >> > > stay with the generic look.) >> > > >> > >> The gears are from Font Awesome, which comes with the RTD format. >> > > >> > > It'd be nice to get the icon back, but the gear glyph is an >> > > improvement compared to the house glyph. >> > > >> > > Anyway, I stick by what I said below too in reply to Eric about >> > > withdrawing my feedback. >> > >> > my $0.02 (which is probably worth even less when it comes to the topic >> > of aesthetics), Laura's new proposal looks much nicer than generic rtd >> > which looks better than current site.. >> > >> > I mostly don't want to get a much needed infrastructure/process >> > improvement derailed with a bikeshed discussion about themes. Nothing >> > against playing with theme options and seeing what people (with better >> > taste than me) like, just don't want that to be something that derails >> > the bigger picture ;-) >> >> Entirely agreed. I also think the old style was distinctive and had >> become part of the "personality" of our website, and I would like the >> new website to look similar, but this is a minor detail that we can >> trivially alter later. >> >> For now let's focus on the infrastructure changes, discussing the style >> can be done in parallel or later, but shouldn't block this. >> >> > >> > BR, >> > -R >> > >> > >> > > >> > > Thanks, >> > > >> > > -Jordan >> > > >> > >> On Thu, May 31, 2018 at 1:55 PM, Jordan Justen >> > >> >> > >> wrote: >> > >> >> > >> > On 2018-05-31 12:27:04, Eric Anholt wrote: >> > >> > > Jordan Justen writes: >> > >> > > >> > >> > > > On 2018-05-24 17:37:09, Laura Ekstrand wrote: >> > >> > > >> A few of the commits are quite large and awaiting list >> > >> > > >> approval. I >> > >> > suggest >> > >> > > >> that you take a look at the code here: >> > >> > > >> https://gitlab.freedesktop.org/ldeks/mesa/tree/website1_75, >> > >> > > >> and the new website here: https://mesa-test.freedesktop. >> > >> > org/index.html >> > >> > > > >> > >> > > > I think the theme should be changed to look somewhat close to >> > >> > > > the >> > >> > > > current mesa3d.org website before changing the main site. >> > >> > > > (Color >> > >> > > > scheme and missing icons.) >> > >> > > > >> > >> > > > Right now the test website looks like a million other sphinx >> > >> > > > websites, >> > >> > > > including every readthedocs book. >> > >> > > > >> > >> > > > Based on http://www.sphinx-doc.org/en/master/ and >> > >> > > > https://www.python.org/, I would say sphinx gives a lot of >> > >> > > > opportunities for a custom look. >> > >> > > >> > >> > > I think looking like a generic other sphinx website is a step >> > >> > > forward, >> > >> > > and I look forward to this series landing. No need for >> > >> > > continuity with >> > >> > > the old theme. >> > >> > >> > >> > I think it is 1 step forward, 1 step back. As no else appears to >> > >> > agree, I'll withdraw my feedback. >> > >> > >> > >> > -Jordan >> > >> > >> > > ___ >> > > 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 mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > ___ > mesa-dev mailing
Re: [Mesa-dev] [PATCH 5/6] r600g: some -Wsign-compare fixes
Patches 2-4 Reviewed-By: Gert Wollny
I can't push them though
I'd like to add that for the future it would be better to
- send the patches for st and r600 as separate series, this would
make it easier to find reviewers
- when fixing warning to add the specific warnings you fixed to
the commit messages (actually Ian Romanick gave me that hint)
Best,
Gert
Am Freitag, den 29.12.2017, 08:32 +0300 schrieb Konstantin Kharlamov:
> Signed-off-by: Konstantin Kharlamov
> ---
> src/gallium/drivers/r600/eg_debug.c | 6 +++---
> src/gallium/drivers/r600/evergreen_state.c | 6 +++---
> src/gallium/drivers/r600/r600_isa.c | 6 +++---
> src/gallium/drivers/r600/r600_pipe.h | 2 +-
> src/gallium/drivers/r600/r600_state_common.c | 5 ++---
> src/gallium/drivers/r600/r600_test_dma.c | 2 +-
> 6 files changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/eg_debug.c
> b/src/gallium/drivers/r600/eg_debug.c
> index ceb7c1672c..56195df296 100644
> --- a/src/gallium/drivers/r600/eg_debug.c
> +++ b/src/gallium/drivers/r600/eg_debug.c
> @@ -78,7 +78,7 @@ static void print_named_value(FILE *file, const
> char *name, uint32_t value,
> static void eg_dump_reg(FILE *file, unsigned offset, uint32_t value,
> uint32_t field_mask)
> {
> - int r, f;
> + unsigned r, f;
>
> for (r = 0; r < ARRAY_SIZE(egd_reg_table); r++) {
> const struct eg_reg *reg = _reg_table[r];
> @@ -134,7 +134,7 @@ static void ac_parse_set_reg_packet(FILE *f,
> uint32_t *ib, unsigned count,
> unsigned reg_offset)
> {
> unsigned reg = (ib[1] << 2) + reg_offset;
> - int i;
> + unsigned i;
>
> for (i = 0; i < count; i++)
> eg_dump_reg(f, reg + i*4, ib[2+i], ~0);
> @@ -149,7 +149,7 @@ static uint32_t *ac_parse_packet3(FILE *f,
> uint32_t *ib, int *num_dw,
> unsigned op = PKT3_IT_OPCODE_G(ib[0]);
> const char *predicate = PKT3_PREDICATE(ib[0]) ?
> "(predicate)" : "";
> const char *compute_mode = (ib[0] & 0x2) ? "(C)" : "";
> - int i;
> + unsigned i;
>
> /* Print the name first. */
> for (i = 0; i < ARRAY_SIZE(packet3_table); i++)
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c
> index ecb9c598e3..1aae9097f3 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3915,7 +3915,7 @@ static void
> evergreen_set_hw_atomic_buffers(struct pipe_context *ctx,
> {
> struct r600_context *rctx = (struct r600_context *)ctx;
> struct r600_atomic_buffer_state *astate;
> - int i, idx;
> + unsigned i, idx;
>
> astate = >atomic_buffer_state;
>
> @@ -3951,7 +3951,7 @@ static void evergreen_set_shader_buffers(struct
> pipe_context *ctx,
> struct r600_tex_color_info color;
> struct eg_buf_res_params buf_params;
> struct r600_resource *resource;
> - int i, idx;
> + unsigned i, idx;
> unsigned old_mask;
>
> if (shader != PIPE_SHADER_FRAGMENT &&
> @@ -4042,7 +4042,7 @@ static void evergreen_set_shader_images(struct
> pipe_context *ctx,
> const struct pipe_image_view
> *images)
> {
> struct r600_context *rctx = (struct r600_context *)ctx;
> - int i;
> + unsigned i;
> struct r600_image_view *rview;
> struct pipe_resource *image;
> struct r600_resource *resource;
> diff --git a/src/gallium/drivers/r600/r600_isa.c
> b/src/gallium/drivers/r600/r600_isa.c
> index 2633cdcdb9..0d3e93d141 100644
> --- a/src/gallium/drivers/r600/r600_isa.c
> +++ b/src/gallium/drivers/r600/r600_isa.c
> @@ -557,7 +557,7 @@ int r600_isa_init(struct r600_context *ctx,
> struct r600_isa *isa) {
>
> for (i = 0; i < ARRAY_SIZE(r600_alu_op_table); ++i) {
> const struct alu_op_info *op =
> _alu_op_table[i];
> - unsigned opc;
> + int opc;
> if (op->flags & AF_LDS || op->slots[isa->hw_class]
> == 0)
> continue;
> opc = op->opcode[isa->hw_class >> 1];
> @@ -570,7 +570,7 @@ int r600_isa_init(struct r600_context *ctx,
> struct r600_isa *isa) {
>
> for (i = 0; i < ARRAY_SIZE(fetch_op_table); ++i) {
> const struct fetch_op_info *op = _op_table[i];
> - unsigned opc = op->opcode[isa->hw_class];
> + int opc = op->opcode[isa->hw_class];
> if ((op->flags & FF_GDS) || ((opc & 0xFF) != opc))
> continue; /* ignore GDS ops and INST_MOD
> versions for now */
> isa->fetch_map[opc] = i + 1;
> @@ -578,7 +578,7 @@ int r600_isa_init(struct r600_context *ctx,
> struct r600_isa *isa) {
>
> for (i = 0; i < ARRAY_SIZE(cf_op_table); ++i) {
> const struct cf_op_info *op = _op_table[i];
> - unsigned opc = op->opcode[isa->hw_class];
> +
Re: [Mesa-dev] [PATCH 1/6 v3] r600g: do not use "fast-clear" for small textures (v3)
This gives me ~200 FPS more with a 200x200 glxgears window with both,
Barts and Ceder.
Reviewed-by: Gert Wollny
Am Montag, den 01.01.2018, 10:38 +0300 schrieb Konstantin Kharlamov:
> Ported from radeonsi. Improves windowed glxgears ran as
>
> vblank_mode=0 glxgears -info -geometry 0+0+512+512
>
> from ≈2270 FPS to ≈2360 FPS. Tested with AMD TURKS.
>
> v2: turned out glxgears ignores the option above, the correct way
> would
> be "512x512+0+0". Now it can be seen 512x512 actually loses 30 FPS.
> 300×300 however wins around a hundred FPS, and to leave some room in
> case results may differ for other cards I want not to nitpick in
> search
> of an optimum but to simply leave 300×300 in the code.
> v3: remove redundant braces, and try harder for the mail to stick to
> the rest of the series.
>
> Signed-off-by: Konstantin Kharlamov
> ---
> src/gallium/drivers/r600/r600_texture.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_texture.c
> b/src/gallium/drivers/r600/r600_texture.c
> index 03cdcd22ee..778e801136 100644
> --- a/src/gallium/drivers/r600/r600_texture.c
> +++ b/src/gallium/drivers/r600/r600_texture.c
> @@ -1793,6 +1793,16 @@ void evergreen_do_fast_color_clear(struct
> r600_common_context *rctx,
> !(tex->resource.external_usage &
> PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
> continue;
>
> + /* Use a slow clear for small surfaces where the
> cost of
> + * the eliminate pass can be higher than the benefit
> of fast
> + * clear. AMDGPU-pro does this, but the numbers may
> differ.
> + *
> + * This helps on both dGPUs and APUs, even small
> ones.
> + */
> + if (tex->resource.b.b.nr_samples <= 1 &&
> + tex->resource.b.b.width0 * tex-
> >resource.b.b.height0 <= 300 * 300)
> + continue;
> +
> {
> /* 128-bit formats are unusupported */
> if (tex->surface.bpe > 8) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] r600g: fix unused variable warning
This patch doesn't apply, the "int i" was deleted already; I didn't
find the commit though.
Am Freitag, den 29.12.2017, 08:32 +0300 schrieb Konstantin Kharlamov:
> Signed-off-by: Konstantin Kharlamov
> ---
> src/gallium/drivers/r600/r600_state_common.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index ec8945f084..dc5cc0ad2e 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -902,7 +902,6 @@ struct r600_pipe_shader_selector
> *r600_create_shader_state_tokens(struct pipe_co
> un
> signed pipe_shader_type)
> {
> struct r600_pipe_shader_selector *sel =
> CALLOC_STRUCT(r600_pipe_shader_selector);
> - int i;
>
> sel->type = pipe_shader_type;
> sel->tokens = tgsi_dup_tokens(tokens);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106163] r600/sb: optimizer tries to schedule access to different array elements in one instruction group
https://bugs.freedesktop.org/show_bug.cgi?id=106163 --- Comment #1 from Gert Wollny --- A patch fixing this has been submitted to the ML: https://patchwork.freedesktop.org/series/44053/ -- 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 106163] r600/sb: optimizer tries to schedule access to different array elements in one instruction group
https://bugs.freedesktop.org/show_bug.cgi?id=106163 mirh changed: What|Removed |Added CC||m...@protonmail.ch -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 18.0.5
On Sun, 2018-06-03 at 12:23 +0200, Juan A. Suarez Romero wrote:
> Mesa 18.0.5 is now available.
>
NOTE: It is anticipated that 18.0.5 will be the final release in the
18.0 series. Users of 18.0 are encouraged to migrate to the 18.1 series
in order to obtain future fixes.
> In this release we have:
>
> Mesa core fixes GL_UNSIGNED_INT64_ARB usage, get rid of leak when using
> glUseProgram(), add glUniform*ui{v} support for display lists, and fixes
> texture
> finalizing that were causing assertions in CTS tests.
>
> Several fixes for intel/i965 driver: support blits and clears in surfaces with
> offsets, several patches around buffer textures, support for 2x6 configuration
> l3 banks count, properly CCS_D buffers initialization, and properly rounding
> mode set.
>
> RADV also gets couple of fixes, for centroid interpolation and for SRGB
> compute
> copies.
>
> Finally, we have also several other fixes in different parts of the framework.
>
>
> Anuj Phogat (1):
> i965/glk: Add l3 banks count for 2x6 configuration
>
> Bas Nieuwenhuizen (2):
> amd/addrlib: Use defines in autotools build.
> radv: Fix SRGB compute copies.
>
> Dave Airlie (1):
> tgsi/scan: add hw atomic to the list of memory accessing files
>
> Francisco Jerez (4):
> Revert "mesa: simplify _mesa_is_image_unit_valid for buffers"
> i965: Move buffer texture size calculation into a common helper
> function.
> i965: Handle non-zero texture buffer offsets in buffer object range
> calculation.
> i965: Use intel_bufferobj_buffer() wrapper in image surface state setup.
>
> Jan Vesely (1):
> eg/compute: Use reference counting to handle compute memory pool.
>
> Jason Ekstrand (2):
> intel/eu: Set EXECUTE_1 when setting the rounding mode in cr0
> intel/blorp: Support blits and clears on surfaces with offsets
>
> Jose Dapena Paz (1):
> mesa: do not leak ctx->Shader.ReferencedProgram references
>
> Juan A. Suarez Romero (9):
> docs: add sha256 checksums for 18.0.4
> cherry-ignore: i965/miptree: Fix handling of uninitialized MCS buffers
> cherry-ignore: add explicit 18.1 only nominations
> cherry-ignore: mesa/st: handle vert_attrib_mask in nir case too
> cherry-ignore: Tegra is not supported
> cherry-ignore: st/mesa: fix assertion failures with
> GL_UNSIGNED_INT64_ARB (v2)
> cherry-ignore: nv30: ensure that displayable formats are marked
> accordingly
> Update version to 18.0.5
> docs: add release notes for 18.0.5
>
> Marek Olšák (3):
> st/mesa: simplify lastLevel determination in st_finalize_texture
> radeonsi: fix incorrect parentheses around VS-PS varying elimination
> mesa: handle GL_UNSIGNED_INT64_ARB properly (v2)
>
> Michel Dänzer (1):
> dri3: Stricter SBC wraparound handling
>
> Nanley Chery (1):
> i965/miptree: Zero-initialize CCS_D buffers
>
> Samuel Pitoiset (2):
> spirv: fix visiting inner loops with same break/continue block
> radv: fix centroid interpolation
>
> Stuart Young (1):
> etnaviv: Fix missing rnndb file in tarballs
>
> Timothy Arceri (1):
> mesa: add glUniform*ui{v} support to display lists
>
> git tag: mesa-18.0.5
>
> https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.gz
> MD5: 3947b8941836f324b273366f2cec2377 mesa-18.0.5.tar.gz
> SHA1: f7f21c5651d50b37402de89ed5f5a9b1b3a917eb mesa-18.0.5.tar.gz
> SHA256: ea3e00329cea899b1e32db812fd2f426832be37e4baa2e2fd9288a3480f30531
> mesa-18.0.5.tar.gz
> SHA512:
> a8fff267edf1b34a3f27e5d579200105039a9f64de561a84343a9609d50d2f30d4eba31b2f862fbee9f73157f2061bc37ea1b8ecd75b556dae03bcb40f0a6b6b
> mesa-18.0.5.tar.gz
> PGP: https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.xz
> MD5: 4bc9ea1263e6af29b7b8add53ff147d4 mesa-18.0.5.tar.xz
> SHA1: 4f6f87d47336536b4c1864cd3e39e42bbc4ec158 mesa-18.0.5.tar.xz
> SHA256: 5187bba8d72aea78f2062d134ec6079a508e8216062dce9ec9048b5eb2c4fc6b
> mesa-18.0.5.tar.xz
> SHA512:
> 63b47cdca7f8282aab7aaa66233411f02918e5c4804b7a0010de2b1867fe90171e492ff031dfc4aa20968dfc99bd7dceb5d35fd44c709e54a2ece61175a60f3d
> mesa-18.0.5.tar.xz
> PGP: https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.xz.sig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 18.0.5
Mesa 18.0.5 is now available.
In this release we have:
Mesa core fixes GL_UNSIGNED_INT64_ARB usage, get rid of leak when using
glUseProgram(), add glUniform*ui{v} support for display lists, and fixes texture
finalizing that were causing assertions in CTS tests.
Several fixes for intel/i965 driver: support blits and clears in surfaces with
offsets, several patches around buffer textures, support for 2x6 configuration
l3 banks count, properly CCS_D buffers initialization, and properly rounding
mode set.
RADV also gets couple of fixes, for centroid interpolation and for SRGB compute
copies.
Finally, we have also several other fixes in different parts of the framework.
Anuj Phogat (1):
i965/glk: Add l3 banks count for 2x6 configuration
Bas Nieuwenhuizen (2):
amd/addrlib: Use defines in autotools build.
radv: Fix SRGB compute copies.
Dave Airlie (1):
tgsi/scan: add hw atomic to the list of memory accessing files
Francisco Jerez (4):
Revert "mesa: simplify _mesa_is_image_unit_valid for buffers"
i965: Move buffer texture size calculation into a common helper function.
i965: Handle non-zero texture buffer offsets in buffer object range
calculation.
i965: Use intel_bufferobj_buffer() wrapper in image surface state setup.
Jan Vesely (1):
eg/compute: Use reference counting to handle compute memory pool.
Jason Ekstrand (2):
intel/eu: Set EXECUTE_1 when setting the rounding mode in cr0
intel/blorp: Support blits and clears on surfaces with offsets
Jose Dapena Paz (1):
mesa: do not leak ctx->Shader.ReferencedProgram references
Juan A. Suarez Romero (9):
docs: add sha256 checksums for 18.0.4
cherry-ignore: i965/miptree: Fix handling of uninitialized MCS buffers
cherry-ignore: add explicit 18.1 only nominations
cherry-ignore: mesa/st: handle vert_attrib_mask in nir case too
cherry-ignore: Tegra is not supported
cherry-ignore: st/mesa: fix assertion failures with GL_UNSIGNED_INT64_ARB
(v2)
cherry-ignore: nv30: ensure that displayable formats are marked
accordingly
Update version to 18.0.5
docs: add release notes for 18.0.5
Marek Olšák (3):
st/mesa: simplify lastLevel determination in st_finalize_texture
radeonsi: fix incorrect parentheses around VS-PS varying elimination
mesa: handle GL_UNSIGNED_INT64_ARB properly (v2)
Michel Dänzer (1):
dri3: Stricter SBC wraparound handling
Nanley Chery (1):
i965/miptree: Zero-initialize CCS_D buffers
Samuel Pitoiset (2):
spirv: fix visiting inner loops with same break/continue block
radv: fix centroid interpolation
Stuart Young (1):
etnaviv: Fix missing rnndb file in tarballs
Timothy Arceri (1):
mesa: add glUniform*ui{v} support to display lists
git tag: mesa-18.0.5
https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.gz
MD5: 3947b8941836f324b273366f2cec2377 mesa-18.0.5.tar.gz
SHA1: f7f21c5651d50b37402de89ed5f5a9b1b3a917eb mesa-18.0.5.tar.gz
SHA256: ea3e00329cea899b1e32db812fd2f426832be37e4baa2e2fd9288a3480f30531
mesa-18.0.5.tar.gz
SHA512:
a8fff267edf1b34a3f27e5d579200105039a9f64de561a84343a9609d50d2f30d4eba31b2f862fbee9f73157f2061bc37ea1b8ecd75b556dae03bcb40f0a6b6b
mesa-18.0.5.tar.gz
PGP: https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.gz.sig
https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.xz
MD5: 4bc9ea1263e6af29b7b8add53ff147d4 mesa-18.0.5.tar.xz
SHA1: 4f6f87d47336536b4c1864cd3e39e42bbc4ec158 mesa-18.0.5.tar.xz
SHA256: 5187bba8d72aea78f2062d134ec6079a508e8216062dce9ec9048b5eb2c4fc6b
mesa-18.0.5.tar.xz
SHA512:
63b47cdca7f8282aab7aaa66233411f02918e5c4804b7a0010de2b1867fe90171e492ff031dfc4aa20968dfc99bd7dceb5d35fd44c709e54a2ece61175a60f3d
mesa-18.0.5.tar.xz
PGP: https://mesa.freedesktop.org/archive/mesa-18.0.5.tar.xz.sig
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
[Mesa-dev] [Bug 106479] NDEBUG not defined for libamdgpu_addrlib
https://bugs.freedesktop.org/show_bug.cgi?id=106479 --- Comment #2 from Juan A. Suarez --- Also, please verify with the latest versions. -- 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] GitLab migration update
Hi, On 2 June 2018 at 16:45, Jason Ekstrand wrote: > My current plan (if Daniel is amenable) is to due the migration late next > week. I'm tentatively thinking Thursday morning pacific but that may change > depending on Daniel's schedule. That works for me. > When the migration happens, there will be a very brief (less than 30 > minutes?) period during which no one will be able to push to either repo. > I'll fire off an e-mail as well as messages in #dri-devel and #intel-3d > shortly before we actually take the repo offline so that everyone has a bit > of warning. So far it's been in the seconds rather than minutes range for all our repos; I wouldn't expect more than a couple of minutes even for Mesa. Pulls (both anonymous and SSH) will continue to work throughout. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 104665] r600: computer shaders break Bioshock on barts (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=104665 --- Comment #5 from Gert Wollny --- Can't reproduce it any more as of git-8841c2cda51d, but I don't know which commit actually fixed the bug. -- 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
