[Mesa-dev] [Bug 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.
https://bugs.freedesktop.org/show_bug.cgi?id=106915 --- Comment #5 from Jason Ekstrand --- (In reply to Ian Romanick from comment #4) > I don't think this text has anything to do with this bug. s[] is not > declared an explicit size. Exactly. My point is that the spec seems to explicitly allow for implicitly sized arrays (as opposed variable-length arrays at the end of the block). I'm not sure that actually means anything but I wouldn't be surprised if someone argues that it's intended. That said, I really hope we can get it disallowed because it's utterly insane at least for explicit buffer layouts. (I could see an argument in favor if the SSBO is implicitly laid out.) -- 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 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.
https://bugs.freedesktop.org/show_bug.cgi?id=106915 --- Comment #4 from Ian Romanick --- (In reply to Jason Ekstrand from comment #3) > I really hate it, but I fear they may be allowed. From the GLSL 4.60 spec > in the section on UBO and SSBO layouts: > > > The shared qualifier overrides only the std140, std430, and packed > > qualifiers; other qualifiers are inherited. The compiler/linker will > > ensure that multiple programs and programmable stages containing this > > definition will share the same memory layout for this block, as long > > as all arrays are declared with explicit sizes and all matrices have > > matching row_major and/or column_major qualifications (which may come > > from a declaration outside the block definition). > > I really wish I hadn't found this text and I think it's silly but there it > is. I don't think this text has anything to do with this bug. s[] is not declared an explicit size. -- 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 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.
https://bugs.freedesktop.org/show_bug.cgi?id=106915 --- Comment #3 from Jason Ekstrand --- I really hate it, but I fear they may be allowed. From the GLSL 4.60 spec in the section on UBO and SSBO layouts: > The shared qualifier overrides only the std140, std430, and packed > qualifiers; other qualifiers are inherited. The compiler/linker will > ensure that multiple programs and programmable stages containing this > definition will share the same memory layout for this block, as long > as all arrays are declared with explicit sizes and all matrices have > matching row_major and/or column_major qualifications (which may come > from a declaration outside the block definition). I really wish I hadn't found this text and I think it's silly but there it is. -- 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 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.
https://bugs.freedesktop.org/show_bug.cgi?id=106915 Ian Romanick changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Ian Romanick --- (In reply to Ian Romanick from comment #1) > (In reply to Eleni Maria Stea from comment #0) > > "An array implicitly sized in one shader can be explicitly sized by another > > shader in the same stage. If no shader in a stage has an explicit size for > > the array, the largest implicit size (one more than the largest index used) > > in that stage is used. There is no cross-stage array sizing. If there is no > > static access to an implicitly sized array within the stage declaring it, > > then the array is given a size of 1, which is relevant when the array is > > declared within an interface block that is shared with other stages or the > > application (other unused arrays might be eliminated by the optimizer)." > > I think we should submit a spec bug for this. There is explicit language in > the spec that says that only the last member of an SSBO may be declared > without a size. See issue #2 in the ARB_shader_storage_buffer_object spec. Before we do that... does this work on other implementations? I am very surprised that this is valid, as it does not match recollection of how we designed SSBOs. I'll be a little surprised if this works on other drivers. Let's collection some information about that, then decide how to proceed. Which ever way is determined to be correct, we should also add a test for the CTS. -- 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 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.
https://bugs.freedesktop.org/show_bug.cgi?id=106915
--- Comment #1 from Ian Romanick ---
(In reply to Eleni Maria Stea from comment #0)
> From GLSLang Spec 4.60 Section 4.2 Scoping:
Please refer to this as the "OpenGL Shading Language specification". GLSLang
is a particular implementation of the GLSL specification.
> "An array implicitly sized in one shader can be explicitly sized by another
> shader in the same stage. If no shader in a stage has an explicit size for
> the array, the largest implicit size (one more than the largest index used)
> in that stage is used. There is no cross-stage array sizing. If there is no
> static access to an implicitly sized array within the stage declaring it,
> then the array is given a size of 1, which is relevant when the array is
> declared within an interface block that is shared with other stages or the
> application (other unused arrays might be eliminated by the optimizer)."
I think we should submit a spec bug for this. There is explicit language in
the spec that says that only the last member of an SSBO may be declared without
a size. See issue #2 in the ARB_shader_storage_buffer_object spec.
> According to the paragraph above, the following piglit test should not
> generate any errors as s[] would be treated as an array of size 1:
>
> [vertex shader]
> #version 150
> #extension GL_ARB_shader_storage_buffer_object: require
> buffer a {
> vec4 s[];
> vec4 a[];
> } b;
>
> in vec4 piglit_vertex;
> out vec4 c;
>
> void main(void) {
> c = b.a[0];
>
> gl_Position = piglit_vertex;
> }
>
> [test]
> link error
>
> Test:
> spec/arb_shader_storage_buffer_object/linker/unsized_array_member.shader_test
>
> but it does.
>
> If we convert the GLSL code to SPIR-V there are no linker errors anymore
> since s[] seems to have type: OpTypeArray with size 1 and the linker accepts
> it.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #7940 failed
Build mesa 7940 failed Commit 355868dbfc by Ian Romanick on 6/6/2018 2:00 AM: nir: Document a couple instances of parent_instr\n\nnir_ssa_def::parent_instr and nir_src::parent_instr have the same name,\nbut they mean really different things. I choose to save the next person\nthe hour+ that I just spent figuring that out. Even now that I know, I\ndoubt I'd notice in code review that someone typed foo->parent_instr\nwhen they actually meant foo->ssa->parent_instr.\n\nv2: Minor wording tweak in nir_ssa_def::parent_instr. Suggested by\nJason.\n\nSigned-off-by: Ian Romanick \nReviewed-by: Jason Ekstrand Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #7939 completed
Build mesa 7939 completed Commit 4467040cb6 by Ian Romanick on 6/13/2018 5:36 PM: i965/fs: Propagate conditional modifiers from not instructions\n\nSkylake\ntotal instructions in shared programs: 14399081 -> 14399010 (<.01%)\ninstructions in affected programs: 26961 -> 26890 (-0.26%)\nhelped: 57\nHURT: 0\nhelped stats (abs) min: 1 max: 6 x̄: 1.25 x̃: 1\nhelped stats (rel) min: 0.16% max: 0.80% x̄: 0.30% x̃: 0.18%\n95% mean confidence interval for instructions value: -1.50 -0.99\n95% mean confidence interval for instructions %-change: -0.35% -0.25%\nInstructions are helped.\n\ntotal cycles in shared programs: 532978307 -> 532976050 (<.01%)\ncycles in affected programs: 468629 -> 466372 (-0.48%)\nhelped: 33\nHURT: 20\nhelped stats (abs) min: 3 max: 360 x̄: 116.52 x̃: 98\nhelped stats (rel) min: 0.06% max: 3.63% x̄: 1.66% x̃: 1.27%\nHURT stats (abs) min: 2 max: 172 x̄: 79.40 x̃: 43\nHURT stats (rel) min: 0.04% max: 3.02% x̄: 1.48% x̃: 0.44%\n95% mean confidence interval for cycles value: -81.29 -3.88\n95% mean confidence interval for cycles %-change: -1.07% 0.12%\nInconclusive result (%-change mean confidence interval includes 0).\n\nAll Gen6+ platforms, except Ivy Bridge, had similar results. (Haswell shown)\ntotal instructions in shared programs: 12973897 -> 12973838 (<.01%)\ninstructions in affected programs: 25970 -> 25911 (-0.23%)\nhelped: 55\nHURT: 0\nhelped stats (abs) min: 1 max: 2 x̄: 1.07 x̃: 1\nhelped stats (rel) min: 0.16% max: 0.62% x̄: 0.28% x̃: 0.18%\n95% mean confidence interval for instructions value: -1.14 -1.00\n95% mean confidence interval for instructions %-change: -0.32% -0.24%\nInstructions are helped.\n\ntotal cycles in shared programs: 410355841 -> 410352067 (<.01%)\ncycles in affected programs: 578454 -> 574680 (-0.65%)\nhelped: 47\nHURT: 5\nhelped stats (abs) min: 3 max: 360 x̄: 85.74 x̃: 18\nhelped stats (rel) min: 0.05% max: 3.68% x̄: 1.18% x̃: 0.38%\nHURT stats (abs) min: 2 max: 242 x̄: 51.20 x̃: 4\nHURT stats (rel) min: <.01% max: 0.45% x̄: 0.15% x̃: 0.11%\n95% mean confidence interval for cycles value: -104.89 -40.27\n95% mean confidence interval for cycles %-change: -1.45% -0.66%\nCycles are helped.\n\nIvy Bridge\ntotal instructions in shared programs: 11679351 -> 11679301 (<.01%)\ninstructions in affected programs: 28208 -> 28158 (-0.18%)\nhelped: 50\nHURT: 0\nhelped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1\nhelped stats (rel) min: 0.12% max: 0.54% x̄: 0.23% x̃: 0.16%\n95% mean confidence interval for instructions value: -1.00 -1.00\n95% mean confidence interval for instructions %-change: -0.27% -0.19%\nInstructions are helped.\n\ntotal cycles in shared programs: 257445362 -> 257444662 (<.01%)\ncycles in affected programs: 419338 -> 418638 (-0.17%)\nhelped: 40\nHURT: 3\nhelped stats (abs) min: 1 max: 170 x̄: 65.05 x̃: 24\nhelped stats (rel) min: 0.02% max: 3.51% x̄: 1.26% x̃: 0.41%\nHURT stats (abs) min: 2 max: 1588 x̄: 634.00 x̃: 312\nHURT stats (rel) min: 0.05% max: 2.97% x̄: 1.21% x̃: 0.62%\n95% mean confidence interval for cycles value: -97.96 65.41\n95% mean confidence interval for cycles %-change: -1.56% -0.62%\nInconclusive result (value mean confidence interval includes 0).\n\nNo changes on Iron Lake or GM45.\n\nv2: Move 'if (cond != BRW_CONDITIONAL_Z && cond != BRW_CONDITIONAL_NZ)'\ncheck outside the loop. Suggested by Iago.\n\nSigned-off-by: Ian Romanick Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv, radv: Add support for VK_KHR_get_display_properties2
Cc: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi_display.c | 57 +
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi_display.c | 56
src/vulkan/wsi/wsi_common_display.c | 192
src/vulkan/wsi/wsi_common_display.h | 27
6 files changed, 311 insertions(+), 23 deletions(-)
diff --git a/src/amd/vulkan/radv_extensions.py
b/src/amd/vulkan/radv_extensions.py
index 65ce7349016..5eb63a7d5dc 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -66,6 +66,7 @@ EXTENSIONS = [
Extension('VK_KHR_external_semaphore',1,
'device->rad_info.has_syncobj'),
Extension('VK_KHR_external_semaphore_capabilities', 1, True),
Extension('VK_KHR_external_semaphore_fd', 1,
'device->rad_info.has_syncobj'),
+Extension('VK_KHR_get_display_properties2', 1,
'VK_USE_PLATFORM_DISPLAY_KHR'),
Extension('VK_KHR_get_memory_requirements2', 1, True),
Extension('VK_KHR_get_physical_device_properties2', 1, True),
Extension('VK_KHR_get_surface_capabilities2', 1,
'RADV_HAS_SURFACE'),
diff --git a/src/amd/vulkan/radv_wsi_display.c
b/src/amd/vulkan/radv_wsi_display.c
index 0f88ce13942..c9915f0100f 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -56,6 +56,20 @@ radv_GetPhysicalDeviceDisplayPropertiesKHR(VkPhysicalDevice
physical_device,
properties);
}
+VkResult
+radv_GetPhysicalDeviceDisplayProperties2KHR(VkPhysicalDevice physical_device,
+uint32_t *property_count,
+VkDisplayProperties2KHR
*properties)
+{
+ RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+ return wsi_display_get_physical_device_display_properties2(
+ physical_device,
+ >wsi_device,
+ property_count,
+ properties);
+}
+
VkResult
radv_GetPhysicalDeviceDisplayPlanePropertiesKHR(
VkPhysicalDevice physical_device,
@@ -71,6 +85,21 @@ radv_GetPhysicalDeviceDisplayPlanePropertiesKHR(
properties);
}
+VkResult
+radv_GetPhysicalDeviceDisplayPlaneProperties2KHR(
+ VkPhysicalDevice physical_device,
+ uint32_t *property_count,
+ VkDisplayPlaneProperties2KHR *properties)
+{
+ RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+ return wsi_display_get_physical_device_display_plane_properties2(
+ physical_device,
+ >wsi_device,
+ property_count,
+ properties);
+}
+
VkResult
radv_GetDisplayPlaneSupportedDisplaysKHR(VkPhysicalDevice physical_device,
uint32_t plane_index,
@@ -103,6 +132,21 @@ radv_GetDisplayModePropertiesKHR(VkPhysicalDevice
physical_device,
properties);
}
+VkResult
+radv_GetDisplayModeProperties2KHR(VkPhysicalDevice physical_device,
+ VkDisplayKHR display,
+ uint32_t *property_count,
+ VkDisplayModeProperties2KHR *properties)
+{
+ RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+ return wsi_display_get_display_mode_properties2(physical_device,
+ >wsi_device,
+ display,
+ property_count,
+ properties);
+}
+
VkResult
radv_CreateDisplayModeKHR(VkPhysicalDevice physical_device,
VkDisplayKHR display,
@@ -129,6 +173,19 @@ radv_GetDisplayPlaneCapabilitiesKHR(VkPhysicalDevice
physical_device,
capabilities);
}
+VkResult
+radv_GetDisplayPlaneCapabilities2KHR(VkPhysicalDevice physical_device,
+ const VkDisplayPlaneInfo2KHR
*pDisplayPlaneInfo,
+ VkDisplayPlaneCapabilities2KHR
*capabilities)
+{
+ RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+ return wsi_get_display_plane_capabilities2(physical_device,
+ >wsi_device,
+ pDisplayPlaneInfo,
+ capabilities);
+}
+
VkResult
radv_CreateDisplayPlaneSurfaceKHR(
VkInstance _instance,
diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan/anv_extensions.py
index 4bffbcb5a2a..e8131335c0c 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -86,6 +86,7 @@ EXTENSIONS = [
Extension('VK_KHR_external_semaphore',
[Mesa-dev] [AppVeyor] mesa master #7938 failed
Build mesa 7938 failed Commit 4106f6ce54 by Eric Anholt on 6/15/2018 1:05 AM: v3d: Handle a no-intersection scissor even if it's outside of the VP.\n\nThe min/maxes ended up producing a negative clip width/height for\ndEQP-GLES3.functional.fragment_ops.scissor.outside_render_line. Just make\nsure they stay at 0 (or v3d 3.x's workaround) if that happens. Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] anv: Disable constant buffer 0 being relative.
Series is
Reviewed-by: Jason Ekstrand
On Fri, Jun 15, 2018 at 4:54 PM, Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> If we are on gen8+ and have context isolation support, just make that
> constant buffer address be absolute, so we can use it for push UBOs too.
>
> v2: Do not duplicate constant_buffer_0_is_relative flag (Jason)
> ---
> src/intel/vulkan/anv_device.c | 3 ++-
> src/intel/vulkan/genX_state.c | 27 +++
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index d1637f097e8..4e63f0c46fa 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -430,7 +430,8 @@ anv_physical_device_init(struct anv_physical_device
> *device,
> device->compiler->shader_debug_log = compiler_debug_log;
> device->compiler->shader_perf_log = compiler_perf_log;
> device->compiler->supports_pull_constants = false;
> - device->compiler->constant_buffer_0_is_relative = true;
> + device->compiler->constant_buffer_0_is_relative =
> + device->info.gen < 8 || !device->has_context_isolation;
>
> isl_device_init(>isl_dev, >info, swizzled);
>
> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
> index c6e54046910..213b6061278 100644
> --- a/src/intel/vulkan/genX_state.c
> +++ b/src/intel/vulkan/genX_state.c
> @@ -169,6 +169,33 @@ genX(init_device_state)(struct anv_device *device)
> gen10_emit_wa_lri_to_cache_mode_zero();
> #endif
>
> + /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> +* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> +*
> +* This is only safe on kernels with context isolation support.
> +*/
> + if (GEN_GEN >= 8 &&
> + device->instance->physicalDevice.has_context_isolation) {
> + UNUSED uint32_t tmp_reg;
> +#if GEN_GEN >= 9
> + anv_pack_struct(_reg, GENX(CS_DEBUG_MODE2),
> + .CONSTANT_BUFFERAddressOffsetDisable = true,
> + .CONSTANT_BUFFERAddressOffsetDisableMask = true);
> + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(CS_DEBUG_MODE2_num);
> + lri.DataDWord = tmp_reg;
> + }
> +#elif GEN_GEN == 8
> + anv_pack_struct(_reg, GENX(INSTPM),
> + .CONSTANT_BUFFERAddressOffsetDisable = true,
> + .CONSTANT_BUFFERAddressOffsetDisableMask = true);
> + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(INSTPM_num);
> + lri.DataDWord = tmp_reg;
> + }
> +#endif
> + }
> +
> anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
>
> assert(batch.next <= batch.end);
> --
> 2.14.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/3] anv: Disable constant buffer 0 being relative.
If we are on gen8+ and have context isolation support, just make that
constant buffer address be absolute, so we can use it for push UBOs too.
v2: Do not duplicate constant_buffer_0_is_relative flag (Jason)
---
src/intel/vulkan/anv_device.c | 3 ++-
src/intel/vulkan/genX_state.c | 27 +++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d1637f097e8..4e63f0c46fa 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -430,7 +430,8 @@ anv_physical_device_init(struct anv_physical_device *device,
device->compiler->shader_debug_log = compiler_debug_log;
device->compiler->shader_perf_log = compiler_perf_log;
device->compiler->supports_pull_constants = false;
- device->compiler->constant_buffer_0_is_relative = true;
+ device->compiler->constant_buffer_0_is_relative =
+ device->info.gen < 8 || !device->has_context_isolation;
isl_device_init(>isl_dev, >info, swizzled);
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index c6e54046910..213b6061278 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -169,6 +169,33 @@ genX(init_device_state)(struct anv_device *device)
gen10_emit_wa_lri_to_cache_mode_zero();
#endif
+ /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
+* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
+*
+* This is only safe on kernels with context isolation support.
+*/
+ if (GEN_GEN >= 8 &&
+ device->instance->physicalDevice.has_context_isolation) {
+ UNUSED uint32_t tmp_reg;
+#if GEN_GEN >= 9
+ anv_pack_struct(_reg, GENX(CS_DEBUG_MODE2),
+ .CONSTANT_BUFFERAddressOffsetDisable = true,
+ .CONSTANT_BUFFERAddressOffsetDisableMask = true);
+ anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
+ lri.RegisterOffset = GENX(CS_DEBUG_MODE2_num);
+ lri.DataDWord = tmp_reg;
+ }
+#elif GEN_GEN == 8
+ anv_pack_struct(_reg, GENX(INSTPM),
+ .CONSTANT_BUFFERAddressOffsetDisable = true,
+ .CONSTANT_BUFFERAddressOffsetDisableMask = true);
+ anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
+ lri.RegisterOffset = GENX(INSTPM_num);
+ lri.DataDWord = tmp_reg;
+ }
+#endif
+ }
+
anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
assert(batch.next <= batch.end);
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] i965: Don't recycle BOs until they are idle
Michel Dänzer writes: > On 2018-06-15 05:25 PM, Jason Ekstrand wrote: >> On June 15, 2018 01:14:24 Michel Dänzer wrote: >>> On 2018-06-15 07:31 AM, Jason Ekstrand wrote: I did some testing and x11perf -copywinwin500 is... exactly the same with or without my patches. If anything they might improve it by just a hair. >>> >>> Possible explanations I can think of: >>> >>> 1. Your glamor still has its own FBO cache. Which version of xserver are >>> you testing with? >>> >> 1.19 I think > > Okay, that doesn't have the glamor FBO cache anymore. > > >>> 2. The i965 driver cache isn't hit even before these changes. >> >> It's definitely getting hit in both cases, it just may require a >> slightly larger cache of we aren't recycling BOs until they're idle. > > It might be more than just slightly, -copywinwin500 can queue many > overlapping copies between flushes. Can you compare the maximum total > cache size with and without this series? I suspect it'll be only about a factor of how-many-batchbuffers-before-throttling difference -- while the batchbuffer still references the BO, the bufmgr wouldn't see the buffer to reuse it anyway. I suspect we hit the aperture limit and flush in the copywinwin500 case. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] nir: add comment for loop_unroll pass
Series:
Reviewed-by: Timothy Arceri
On 16/06/18 06:13, Rob Clark wrote:
Save the next person from digging through the code to figure out what
the indirect_mask parameter actually does.
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_opt_loop_unroll.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
b/src/compiler/nir/nir_opt_loop_unroll.c
index ff27c06cc01..04caa7c346d 100644
--- a/src/compiler/nir/nir_opt_loop_unroll.c
+++ b/src/compiler/nir/nir_opt_loop_unroll.c
@@ -578,6 +578,10 @@ nir_opt_loop_unroll_impl(nir_function_impl *impl,
return progress;
}
+/**
+ * indirect_mask specifies which type of indirectly accessed variables
+ * should force loop unrolling.
+ */
bool
nir_opt_loop_unroll(nir_shader *shader, nir_variable_mode indirect_mask)
{
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/16] docs: Add Sphinx configuration file.
Eric,
Thanks for finding that command to shut off copyright. I've updated the
series to add it.
Laura
On Fri, Jun 1, 2018 at 7:29 AM, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-06-01 02:41:36)
> > On Thursday, 2018-05-31 14:00:24 -0700, Dylan Baker wrote:
> > > Quoting Laura Ekstrand (2018-05-24 17:27:09)
> > > > From: Jean Hertel
> > > >
> > > > This tells Sphinx how to build our website from reStructured Text.
> > > >
> > > > Signed-off-by: Jean Hertel
> > > > ---
> > > > docs/conf.py | 162 ++
> +
> > > > 1 file changed, 162 insertions(+)
> > > > create mode 100644 docs/conf.py
> > > >
> > > > diff --git a/docs/conf.py b/docs/conf.py
> > > > new file mode 100644
> > > > index 00..dcdbdd51db
> > > > --- /dev/null
> > > > +++ b/docs/conf.py
> > > > @@ -0,0 +1,162 @@
> > > > +#!/usr/bin/env python3
> > > > +# -*- coding: utf-8 -*-
> > > > +
> > > > +import sphinx_rtd_theme
> > > > +
> > > > +#
> > > > +# The Mesa 3D Graphics Library documentation build configuration
> file, created by
> > > > +# sphinx-quickstart on Wed Mar 29 14:08:51 2017.
> > > > +#
> > > > +# This file is execfile()d with the current directory set to its
> > > > +# containing dir.
> > > > +#
> > > > +# Note that not all possible configuration values are present in
> this
> > > > +# autogenerated file.
> > > > +#
> > > > +# All configuration values have a default; values that are
> commented out
> > > > +# serve to show the default.
> > > > +
> > > > +# If extensions (or modules to document with autodoc) are in
> another directory,
> > > > +# add these directories to sys.path here. If the directory is
> relative to the
> > > > +# documentation root, use os.path.abspath to make it absolute, like
> shown here.
> > > > +#
> > > > +# import os
> > > > +# import sys
> > > > +# sys.path.insert(0, os.path.abspath('.'))
> > > > +
> > > > +
> > > > +# -- General configuration --
> --
> > > > +
> > > > +# If your documentation needs a minimal Sphinx version, state it
> here.
> > > > +#
> > > > +# needs_sphinx = '1.0'
> > > > +
> > > > +# Add any Sphinx extension module names here, as strings. They can
> be
> > > > +# extensions coming with Sphinx (named 'sphinx.ext.*') or your
> custom
> > > > +# ones.
> > > > +extensions = []
> > > > +
> > > > +# Add any paths that contain templates here, relative to this
> directory.
> > > > +templates_path = ['_templates']
> > > > +
> > > > +# The suffix(es) of source filenames.
> > > > +# You can specify multiple suffix as a list of string:
> > > > +#
> > > > +# source_suffix = ['.rst', '.md']
> > > > +source_suffix = '.rst'
> > > > +
> > > > +# The master toctree document.
> > > > +master_doc = 'index'
> > > > +
> > > > +# General information about the project.
> > > > +project = 'The Mesa 3D Graphics Library'
> > > > +copyright = '2017, Brian Paul'
> > > > +author = 'Brian Paul'
> > >
> > > Is this actually going to the final page?
> >
> > It's what appears at the bottom of every page.
> >
> > > Because this doesn't reflect the reality of the copyrights of mesa.
> >
> > Agreed; I think it's best left out, as there's no way to sanely reflect
> > the complex copyrights of mesa in a signature on each webpage. The
> > license page [1] already does that job.
> >
> > -copyright = '2017, Brian Paul'
> > +html_show_copyright = False
> >
> > [1] https://mesa3d.org/license.html
> >
>
> This seems like the most reasonable solution to me.
>
> Dylan
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] i965/fs: Propagate conditional modifiers from not instructions
On 06/15/2018 03:09 AM, Iago Toral wrote:
> On Thu, 2018-06-14 at 17:43 -0700, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Skylake
>> total instructions in shared programs: 14399081 -> 14399010 (<.01%)
>> instructions in affected programs: 26961 -> 26890 (-0.26%)
>> helped: 57
>> HURT: 0
>> helped stats (abs) min: 1 max: 6 x̄: 1.25 x̃: 1
>> helped stats (rel) min: 0.16% max: 0.80% x̄: 0.30% x̃: 0.18%
>> 95% mean confidence interval for instructions value: -1.50 -0.99
>> 95% mean confidence interval for instructions %-change: -0.35% -0.25%
>> Instructions are helped.
>>
>> total cycles in shared programs: 532978307 -> 532976050 (<.01%)
>> cycles in affected programs: 468629 -> 466372 (-0.48%)
>> helped: 33
>> HURT: 20
>> helped stats (abs) min: 3 max: 360 x̄: 116.52 x̃: 98
>> helped stats (rel) min: 0.06% max: 3.63% x̄: 1.66% x̃: 1.27%
>> HURT stats (abs) min: 2 max: 172 x̄: 79.40 x̃: 43
>> HURT stats (rel) min: 0.04% max: 3.02% x̄: 1.48% x̃: 0.44%
>> 95% mean confidence interval for cycles value: -81.29 -3.88
>> 95% mean confidence interval for cycles %-change: -1.07% 0.12%
>> Inconclusive result (%-change mean confidence interval includes 0).
>>
>> All Gen6+ platforms, except Ivy Bridge, had similar results. (Haswell
>> shown)
>> total instructions in shared programs: 12973897 -> 12973838 (<.01%)
>> instructions in affected programs: 25970 -> 25911 (-0.23%)
>> helped: 55
>> HURT: 0
>> helped stats (abs) min: 1 max: 2 x̄: 1.07 x̃: 1
>> helped stats (rel) min: 0.16% max: 0.62% x̄: 0.28% x̃: 0.18%
>> 95% mean confidence interval for instructions value: -1.14 -1.00
>> 95% mean confidence interval for instructions %-change: -0.32% -0.24%
>> Instructions are helped.
>>
>> total cycles in shared programs: 410355841 -> 410352067 (<.01%)
>> cycles in affected programs: 578454 -> 574680 (-0.65%)
>> helped: 47
>> HURT: 5
>> helped stats (abs) min: 3 max: 360 x̄: 85.74 x̃: 18
>> helped stats (rel) min: 0.05% max: 3.68% x̄: 1.18% x̃: 0.38%
>> HURT stats (abs) min: 2 max: 242 x̄: 51.20 x̃: 4
>> HURT stats (rel) min: <.01% max: 0.45% x̄: 0.15% x̃: 0.11%
>> 95% mean confidence interval for cycles value: -104.89 -40.27
>> 95% mean confidence interval for cycles %-change: -1.45% -0.66%
>> Cycles are helped.
>>
>> Ivy Bridge
>> total instructions in shared programs: 11679351 -> 11679301 (<.01%)
>> instructions in affected programs: 28208 -> 28158 (-0.18%)
>> helped: 50
>> HURT: 0
>> helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
>> helped stats (rel) min: 0.12% max: 0.54% x̄: 0.23% x̃: 0.16%
>> 95% mean confidence interval for instructions value: -1.00 -1.00
>> 95% mean confidence interval for instructions %-change: -0.27% -0.19%
>> Instructions are helped.
>>
>> total cycles in shared programs: 257445362 -> 257444662 (<.01%)
>> cycles in affected programs: 419338 -> 418638 (-0.17%)
>> helped: 40
>> HURT: 3
>> helped stats (abs) min: 1 max: 170 x̄: 65.05 x̃: 24
>> helped stats (rel) min: 0.02% max: 3.51% x̄: 1.26% x̃: 0.41%
>> HURT stats (abs) min: 2 max: 1588 x̄: 634.00 x̃: 312
>> HURT stats (rel) min: 0.05% max: 2.97% x̄: 1.21% x̃: 0.62%
>> 95% mean confidence interval for cycles value: -97.96 65.41
>> 95% mean confidence interval for cycles %-change: -1.56% -0.62%
>> Inconclusive result (value mean confidence interval includes 0).
>>
>> No changes on Iron Lake or GM45.
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/intel/compiler/brw_fs_cmod_propagation.cpp | 63
>> +-
>> 1 file changed, 62 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
>> b/src/intel/compiler/brw_fs_cmod_propagation.cpp
>> index b4f05613e98..c935cc66c81 100644
>> --- a/src/intel/compiler/brw_fs_cmod_propagation.cpp
>> +++ b/src/intel/compiler/brw_fs_cmod_propagation.cpp
>> @@ -111,6 +111,61 @@ cmod_propagate_cmp_to_add(const gen_device_info
>> *devinfo, bblock_t *block,
>> return false;
>> }
>>
>> +/**
>> + * Propagate conditional modifiers from NOT instructions
>> + *
>> + * Attempt to convert sequences like
>> + *
>> + *or(8) g78<8,8,1> g76<8,8,1>UDg77<8,8,1>UD
>> + *...
>> + *not.nz.f0(8)nullg78<8,8,1>UD
>> + *
>> + * into
>> + *
>> + *or.z.f0(8) g78<8,8,1> g76<8,8,1>UDg77<8,8,1>UD
>> + */
>> +static bool
>> +cmod_propagate_not(const gen_device_info *devinfo, bblock_t *block,
>> + fs_inst *inst)
>> +{
>> + const enum brw_conditional_mod cond = brw_negate_cmod(inst-
>>> conditional_mod);
>> + bool read_flag = false;
>> +
>> + foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst,
>> inst) {
>> + if (regions_overlap(scan_inst->dst, scan_inst->size_written,
>> + inst->src[0], inst->size_read(0))) {
>> + if (cond != BRW_CONDITIONAL_Z &&
>> + cond != BRW_CONDITIONAL_NZ)
>> +break;
>
> Looks like we can do this before the loop.
Yes... I have another patch that adds support for propagating
Re: [Mesa-dev] [PATCH v2 10/15] docs: Add toctree to relnotes
Eric, Thanks for picking up on this; I have updated the link: https://mesa-test.freedesktop.org/relnotes.html. The 18.2.0.html page exists even though it's not released yet. It's a stub that Emil added. Laura 2018-05-31 6:50 GMT-07:00 Eric Engestrom : > On Wednesday, 2018-05-30 15:53:22 -0700, Laura Ekstrand wrote: > > From: Jean Hertel > > > > Toctree directives create automatically generated navigation sidebars. > > This is the new relnotes sidebar. > > --- > > docs/relnotes.rst | 210 ++ > > > 1 file changed, 210 insertions(+) > > > > diff --git a/docs/relnotes.rst b/docs/relnotes.rst > > index 3cb96bb6a4..e4fa0e5efa 100644 > > --- a/docs/relnotes.rst > > +++ b/docs/relnotes.rst > > @@ -3,6 +3,8 @@ Release Notes > > > > The release notes summarize what's new or changed in each Mesa release. > > > > +- `18.2.0 release notes `__ > > s/18.1.0/18.2.0/ ^ > > (also note that 18.2.0 is not out and isn't expected until end of august) > > > +- `18.1.0 release notes `__ > > - `18.0.4 release notes `__ > > - `18.0.3 release notes `__ > > - `18.0.2 release notes `__ > > @@ -231,3 +233,211 @@ file `__ and the following release > notes. > > - `3.2.1 release notes `__ > > - `3.2 release notes `__ > > - `3.1 release notes `__ > > + > > +.. toctree:: > > + :maxdepth: 1 > > + :hidden: > > + > > + release-calendar > > + relnotes/18.2.0 > > + relnotes/18.1.0 > > + relnotes/18.0.4 > > + relnotes/18.0.3 > > + relnotes/18.0.2 > > + relnotes/18.0.1 > > + relnotes/18.0.0 > > + relnotes/17.3.9 > > + relnotes/17.3.8 > > + relnotes/17.3.7 > > + relnotes/17.3.6 > > + relnotes/17.3.5 > > + relnotes/17.3.4 > > + relnotes/17.3.3 > > + relnotes/17.3.2 > > + relnotes/17.3.1 > > + relnotes/17.3.0 > > + relnotes/17.2.8 > > + relnotes/17.2.7 > > + relnotes/17.2.6 > > + relnotes/17.2.5 > > + relnotes/17.2.4 > > + relnotes/17.2.3 > > + relnotes/17.2.2 > > + relnotes/17.2.1 > > + relnotes/17.2.0 > > + relnotes/17.1.10 > > + relnotes/17.1.9 > > + relnotes/17.1.8 > > + relnotes/17.1.7 > > + relnotes/17.1.6 > > + relnotes/17.1.5 > > + relnotes/17.1.4 > > + relnotes/17.1.3 > > + relnotes/17.1.2 > > + relnotes/17.1.1 > > + relnotes/17.1.0 > > + relnotes/17.0.7 > > + relnotes/17.0.6 > > + relnotes/17.0.5 > > + relnotes/17.0.4 > > + relnotes/17.0.3 > > + relnotes/17.0.2 > > + relnotes/13.0.6 > > + relnotes/17.0.1 > > + relnotes/13.0.5 > > + relnotes/17.0.0 > > + relnotes/13.0.4 > > + relnotes/12.0.6 > > + relnotes/13.0.3 > > + relnotes/12.0.5 > > + relnotes/13.0.2 > > + relnotes/13.0.1 > > + relnotes/12.0.4 > > + relnotes/13.0.0 > > + relnotes/12.0.3 > > + relnotes/12.0.2 > > + relnotes/12.0.1 > > + relnotes/12.0.0 > > + relnotes/11.2.2 > > + relnotes/11.1.4 > > + relnotes/11.2.1 > > + relnotes/11.1.3 > > + relnotes/11.2.0 > > + relnotes/11.1.2 > > + relnotes/11.0.9 > > + relnotes/11.1.1 > > + relnotes/11.0.8 > > + relnotes/11.1.0 > > + relnotes/11.0.7 > > + relnotes/11.0.6 > > + relnotes/11.0.5 > > + relnotes/11.0.4 > > + relnotes/11.0.3 > > + relnotes/10.6.9 > > + relnotes/11.0.2 > > + relnotes/11.0.1 > > + relnotes/10.6.8 > > + relnotes/11.0.0 > > + relnotes/10.6.7 > > + relnotes/10.6.6 > > + relnotes/10.6.5 > > + relnotes/10.6.4 > > + relnotes/10.6.3 > > + relnotes/10.6.2 > > + relnotes/10.5.9 > > + relnotes/10.6.1 > > + relnotes/10.5.8 > > + relnotes/10.6.0 > > + relnotes/10.5.7 > > + relnotes/10.5.6 > > + relnotes/10.5.5 > > + relnotes/10.5.4 > > + relnotes/10.5.3 > > + relnotes/10.5.2 > > + relnotes/10.4.7 > > + relnotes/10.5.1 > > + relnotes/10.5.0 > > + relnotes/10.4.6 > > + relnotes/10.4.5 > > + relnotes/10.4.4 > > + relnotes/10.4.3 > > + relnotes/10.4.2 > > + relnotes/10.3.7 > > + relnotes/10.4.1 > > + relnotes/10.3.6 > > + relnotes/10.4 > > + relnotes/10.3.5 > > + relnotes/10.3.4 > > + relnotes/10.3.3 > > + relnotes/10.3.2 > > + relnotes/10.3.1 > > + relnotes/10.2.9 > > + relnotes/10.3 > > + relnotes/10.2.8 > > + relnotes/10.2.7 > > + relnotes/10.2.6 > > + relnotes/10.2.5 > > + relnotes/10.2.4 > > + relnotes/10.2.3 > > + relnotes/10.2.2 > > + relnotes/10.2.1 > > + relnotes/10.2 > > + relnotes/10.1.6 > > + relnotes/10.1.5 > > + relnotes/10.1.4 > > + relnotes/10.1.3 > > + relnotes/10.1.2 > > + relnotes/10.1.1 > > + relnotes/10.1 > > + relnotes/10.0.5 > > + relnotes/10.0.4 > > + relnotes/10.0.3 > > + relnotes/10.0.2 > > + relnotes/10.0.1 > > + relnotes/10.0 > > + relnotes/9.2.5 > > + relnotes/9.2.4 > > + relnotes/9.2.3 > > + relnotes/9.2.2 > > + relnotes/9.2.1 > > + relnotes/9.2 > > + relnotes/9.1.7 > > + relnotes/9.1.6 > > + relnotes/9.1.5 > > + relnotes/9.1.4 > > + relnotes/9.1.3 > > + relnotes/9.1.2 > > + relnotes/9.1.1 > > + relnotes/9.1 > > + relnotes/9.0.3
Re: [Mesa-dev] [PATCH 1/6] i965/fs: Optimize OR with 0 into a MOV
On 06/15/2018 02:27 AM, Iago Toral wrote:
> On Thu, 2018-06-14 at 17:43 -0700, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> fs_visitor::set_gs_stream_control_data_bits generates some code like
>> "control_data_bits | stream_id << ((2 * (vertex_count - 1)) % 32)" as
>> part of EmitVertex. The first time this (dynamically) occurs in the
>> shader, control_data_bits is zero. Many times we can determine this
>> statically and various optimizations will collaborate to make one of
>> the
>> OR operands literal zero.
>>
>> Converting the OR to a MOV usually allows it to be copy-propagated
>> away.
>> However, this does not happen in at least some shaders (in the
>> assembly
>> output of
>> shaders/closed/UnrealEngine4/EffectsCaveDemo/301.shader_test,
>> search for shl).
>>
>> All of the affected shaders are geometry shaders.
>>
>> Broadwell and Skylake had similar results. (Skylake shown)
>> total instructions in shared programs: 14375452 -> 14375413 (<.01%)
>> instructions in affected programs: 6422 -> 6383 (-0.61%)
>> helped: 39
>> HURT: 0
>> helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
>> helped stats (rel) min: 0.14% max: 2.56% x̄: 1.91% x̃: 2.56%
>> 95% mean confidence interval for instructions value: -1.00 -1.00
>> 95% mean confidence interval for instructions %-change: -2.26% -1.57%
>> Instructions are helped.
>>
>> total cycles in shared programs: 531981179 -> 531980555 (<.01%)
>> cycles in affected programs: 27493 -> 26869 (-2.27%)
>> helped: 39
>> HURT: 0
>> helped stats (abs) min: 16 max: 16 x̄: 16.00 x̃: 16
>> helped stats (rel) min: 0.60% max: 7.92% x̄: 5.94% x̃: 7.92%
>> 95% mean confidence interval for cycles value: -16.00 -16.00
>> 95% mean confidence interval for cycles %-change: -6.98% -4.90%
>> Cycles are helped.
>>
>> No changes on earlier platforms.
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/intel/compiler/brw_fs.cpp | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_fs.cpp
>> b/src/intel/compiler/brw_fs.cpp
>> index d67c0a41922..d836b268629 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -2448,7 +2448,8 @@ fs_visitor::opt_algebraic()
>> }
>> break;
>>case BRW_OPCODE_OR:
>> - if (inst->src[0].equals(inst->src[1])) {
>> + if (inst->src[0].equals(inst->src[1]) ||
>> + inst->src[1].is_zero()) {
>> inst->opcode = BRW_OPCODE_MOV;
>> inst->src[1] = reg_undef;
>> progress = true;
>
> While we are at this, shouldn't we also handle this as a MOV (from
> src[1]) when src[0].is_zero() is true?
As far as I'm aware, immediate values can only appear on src1 for
two-source instructions. A similar algebraic optimization for x+0 in
the vec4 backend only checks src1.
> Iago
___
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
Stuart, We are now running on our own Docker image: https://mesa-test.freedesktop.org/. This should have fixed both of the issues you encountered. Thanks. Laura On Mon, Jun 11, 2018 at 3:24 PM, Laura Ekstrand wrote: > I really like the rotate on hover effect for the gears. I would rather > that we use 2D WebGL for it if we could, though, since Mesa enables WebGL > on certain platforms. > > Stuart, I will try to get the favicon and rtd_theme fixed. We may have to > make our Docker image. > > Thanks. > > Laura > > On Fri, Jun 8, 2018 at 7:23 AM, Erik Faye-Lund > wrote: > >> On Fri, Jun 8, 2018 at 4:09 PM Rhys Perry >> wrote: >> > >> > Might be good to do something like this: https://codepen.io/anon/pen/ER >> NdYJ >> > So that those with NoScript or something won't have gears constantly >> > rotating on their screen. >> > >> >> Yeah, good point. >> ___ >> 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 1/2] mesa : MESA_framebuffer_flip_y extension
On Tue, Jun 12, 2018 at 12:28 PM Chad Versace wrote: > > On Thu 07 Jun 2018, Fritz Koenig wrote: > > Adds an extension to glFramebufferParameteri > > that will specify if the framebuffer is vertically > > flipped. Historically system framebuffers are > > vertically flipped and user framebuffers are not. > > Checking to see the state was done by looking at > > the name field. This adds an explicit field. > > --- > > docs/specs/MESA_framebuffer_flip_y.spec | 59 + > > include/GLES2/gl2ext.h | 5 +++ > > src/mapi/glapi/registry/gl.xml | 6 +++ > > src/mesa/main/extensions_table.h| 1 + > > src/mesa/main/fbobject.c| 8 > > src/mesa/main/framebuffer.c | 1 + > > src/mesa/main/glheader.h| 3 ++ > > src/mesa/main/mtypes.h | 4 ++ > > 8 files changed, 87 insertions(+) > > create mode 100644 docs/specs/MESA_framebuffer_flip_y.spec > > > > diff --git a/docs/specs/MESA_framebuffer_flip_y.spec > > b/docs/specs/MESA_framebuffer_flip_y.spec > > new file mode 100644 > > index 00..b9867e0683 > > --- /dev/null > > +++ b/docs/specs/MESA_framebuffer_flip_y.spec > > @@ -0,0 +1,59 @@ > > +Name > > + > > +MESA_framebuffer_flip_y > > + > > +Name Strings > > + > > +GL_MESA_framebuffer_flip_y > > + > > +Contact > > + > > +Fritz Koenig > > + > > +Status > > + > > +Proposal > > + > > +Version > > + > > +Version 1, June 7, 2018 > > + > > +Number > > + > > +TBD > > + > > +Dependencies > > + > > +OpenGLES 3.1 is required. > > In specs, s/OpenGLES/OpenGL ES/. > > > + > > +Overview > > + > > +This extension adds the ability to specify that the internal > > framebuffer > > +object is vertically flipped. > > Questions: > > a. Is it legal to set and/or query GL_FRAMEBUFFER_FLIP_Y_MESA on the > default framebuffer (that is, the winsys framebuffer)? no, this is for user framebuffers only, FramebufferParameteri can not be called on a winsys framebuffer > b. If (a) is legal, then the default framebuffer's initial value of > GL_FRAMEBUFFER_FLIP_Y_MESA is ambiguous. Does the spec define it > to be GL_TRUE or GL_FALSE? (I assume the answer is GL_TRUE based on > the patch's code). > > The patch seems to allow toggling the state of winsys framebuffers, > but I was unsure if that decision was intentional. > > > +New Tokens > > + > > +Accepted by the argument of FramebufferParameteri: > > + > > +GL_FRAMEBUFFER_FLIP_Y_EXT 0x8BBB > > ... and GetFramebufferParameteriv. > > > + > > +Revision History > > + > > +Version 1, June, 2018 > > +Initial draft (Fritz Koenig) > > diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h > > index a7d19a1fc8..7fb5e9ca5f 100644 > > --- a/include/GLES2/gl2ext.h > > +++ b/include/GLES2/gl2ext.h > > @@ -2334,6 +2334,11 @@ GL_APICALL void GL_APIENTRY glGetPerfQueryInfoINTEL > > (GLuint queryId, GLuint quer > > #endif > > #endif /* GL_INTEL_performance_query */ > > > > +#ifndef GL_MESA_framebuffer_flip_y > > +#define GL_MESA_framebuffer_flip_y 1 > > +#define GL_FRAMEBUFFER_FLIP_Y_EXT 0x8BBB > > +#endif /* GL_MESA_framebuffer_flip_y */ > > + > > #ifndef GL_MESA_program_binary_formats > > #define GL_MESA_program_binary_formats 1 > > #define GL_PROGRAM_BINARY_FORMAT_MESA 0x875F > > diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml > > index 833478aa51..3a3d4f3d81 100644 > > --- a/src/mapi/glapi/registry/gl.xml > > +++ b/src/mapi/glapi/registry/gl.xml > > @@ -6568,6 +6568,7 @@ typedef unsigned int GLhandleARB; > > > > > > > > + > > > > > > > comment="Reassigned from AMD to QCOM"> > > @@ -44356,6 +44357,11 @@ typedef unsigned int GLhandleARB; > > > > > > > > + > > + > > + > > + > > + > > > > > > > > diff --git a/src/mesa/main/extensions_table.h > > b/src/mesa/main/extensions_table.h > > index 79ef228b69..03a5c7b345 100644 > > --- a/src/mesa/main/extensions_table.h > > +++ b/src/mesa/main/extensions_table.h > > @@ -322,6 +322,7 @@ EXT(KHR_texture_compression_astc_hdr, > > KHR_texture_compression_astc_hdr > > EXT(KHR_texture_compression_astc_ldr, > > KHR_texture_compression_astc_ldr , GLL, GLC, x , ES2, 2012) > > EXT(KHR_texture_compression_astc_sliced_3d , > > KHR_texture_compression_astc_sliced_3d , GLL, GLC, x , ES2, 2015) > > > > +EXT(MESA_framebuffer_flip_y , MESA_framebuffer_flip_y > > , x, x, x , ES2, 2018) > > Since the extension requires GLES 3.1, this row should have s/ES2/31/. > I don't see the option for an ES31 extension, only ES2 in that file. > > EXT(MESA_pack_invert, MESA_pack_invert > > , GLL, GLC, x , x ,
[Mesa-dev] [PATCH 3/5] st/mesa: add support for EXT_shader_image_load_formatted
Signed-off-by: Rhys Perry
---
src/mesa/state_tracker/st_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 467d9b0759..115472d790 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -651,6 +651,7 @@ void st_init_extensions(struct pipe_screen *screen,
{ o(ARB_shader_clock), PIPE_CAP_TGSI_CLOCK
},
{ o(ARB_shader_draw_parameters), PIPE_CAP_DRAW_PARAMETERS
},
{ o(ARB_shader_group_vote),PIPE_CAP_TGSI_VOTE
},
+ { o(EXT_shader_image_load_formatted), PIPE_CAP_IMAGE_LOAD_FORMATTED
},
{ o(ARB_shader_stencil_export),PIPE_CAP_SHADER_STENCIL_EXPORT
},
{ o(ARB_shader_texture_image_samples), PIPE_CAP_TGSI_TXQS
},
{ o(ARB_shader_texture_lod), PIPE_CAP_SM3
},
--
2.14.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/5] nvc0: Implement EXT_shader_image_load_formatted
Changes in v2: - Change from PIPE_SHADER_CAP_* to PIPE_CAP_* - Fix broken feature detection in the state tracker - Move code in AlgebraicOpt::handleSULDP() to nv50_ir_ra.cpp This patch series implements EXT_shader_image_load_formatted on Maxwell+. It should implement all of the spec except, if the extension is enabled, passing image variables without a format qualifier to atomic operations will not raise a compilation error like it should. This is because knowing the format used in an image operation before function inlining can be difficult, because formats don't have to (and currently can't) be specified in the paramter declaration. So this series leaves this issue to hopefully be resolved in a later patch. Rhys Perry (5): gallium: add support for formatted image loads mesa,glsl: add support for EXT_shader_image_load_formatted st/mesa: add support for EXT_shader_image_load_formatted nv50/ir: use suld.p on GM107+ nvc0,nv50/ir: enable support for formatted image loads on GM107+ src/compiler/glsl/ast_to_hir.cpp | 5 src/compiler/glsl/glsl_parser_extras.cpp | 1 + src/compiler/glsl/glsl_parser_extras.h | 7 + src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/codegen/nv50_ir.h | 4 +++ .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 ++ .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 6 +--- .../drivers/nouveau/codegen/nv50_ir_print.cpp | 17 +++ src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 27 - src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_get.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/v3d/v3d_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/mesa/main/extensions_table.h | 1 + src/mesa/main/mtypes.h | 1 + src/mesa/state_tracker/st_extensions.c | 1 + 28 files changed, 104 insertions(+), 18 deletions(-) -- 2.14.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] gallium: add support for formatted image loads
Signed-off-by: Rhys Perry --- src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_get.c| 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/v3d/v3d_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + 17 files changed, 17 insertions(+) diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c b/src/gallium/drivers/etnaviv/etnaviv_screen.c index e031807117..3fc7e9e47b 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c @@ -281,6 +281,7 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE: case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS: case PIPE_CAP_PACKED_UNIFORMS: + case PIPE_CAP_IMAGE_LOAD_FORMATTED: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index a414cb6d60..3d0d2bb60f 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -347,6 +347,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES: case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE: case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS: + case PIPE_CAP_IMAGE_LOAD_FORMATTED: return 0; case PIPE_CAP_CONTEXT_PRIORITY_MASK: diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index b08d2283e7..d879c8c1ba 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -333,6 +333,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_FENCE_SIGNAL: case PIPE_CAP_CONSTBUF0_FLAGS: case PIPE_CAP_PACKED_UNIFORMS: + case PIPE_CAP_IMAGE_LOAD_FORMATTED: return 0; case PIPE_CAP_MAX_VIEWPORTS: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index f12ad09298..ff8d10a86e 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -370,6 +370,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES: case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE: case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS: + case PIPE_CAP_IMAGE_LOAD_FORMATTED: return 0; } /* should only get here on unhandled cases */ diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index a77f70e6bb..bbf5d76f19 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c @@ -236,6 +236,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES: case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE: case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS: + case PIPE_CAP_IMAGE_LOAD_FORMATTED: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 2495a545fd..9e482128f4 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -289,6 +289,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES: case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE: case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS: + case PIPE_CAP_IMAGE_LOAD_FORMATTED: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index f679cbdba3..4c31bb4347 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -319,6 +319,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case
[Mesa-dev] [PATCH 5/5] nvc0, nv50/ir: enable support for formatted image loads on GM107+
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 +--
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 3 ++-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index f7ffa5627c..0fc93d221e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2377,12 +2377,11 @@
NVC0LoweringPass::processSurfaceCoordsGM107(TexInstruction *su)
bld.mkCmp(OP_SET, CC_EQ, TYPE_U32, bld.getSSA(1, FILE_PREDICATE),
TYPE_U32, bld.mkImm(0),
loadSuInfo32(ind, slot, NVC0_SU_INFO_ADDR, su->tex.bindless));
- if (su->op != OP_SUSTP && su->tex.format) {
+ if (su->op != OP_SUSTP && su->tex.format && su->tex.format->components > 0)
{
const TexInstruction::ImgFormatDesc *format = su->tex.format;
int blockwidth = format->bits[0] + format->bits[1] +
format->bits[2] + format->bits[3];
- assert(format->components != 0);
// make sure that the format doesn't mismatch when it's not FMT_NONE
bld.mkCmp(OP_SET_OR, CC_NE, TYPE_U32, pred->getDef(0),
TYPE_U32, bld.loadImm(NULL, blockwidth / 8),
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 4c31bb4347..2e22a8d4b1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -274,6 +274,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
return class_3d >= GM200_3D_CLASS;
case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_TRIANGLES:
return class_3d >= GP100_3D_CLASS;
+ case PIPE_CAP_IMAGE_LOAD_FORMATTED:
+ return class_3d >= GM107_3D_CLASS;
case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
case PIPE_CAP_TGSI_BALLOT:
case PIPE_CAP_BINDLESS_TEXTURE:
@@ -319,7 +321,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_CONSTBUF0_FLAGS:
case PIPE_CAP_PACKED_UNIFORMS:
case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES:
- case PIPE_CAP_IMAGE_LOAD_FORMATTED:
return 0;
case PIPE_CAP_VENDOR_ID:
--
2.14.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] mesa, glsl: add support for EXT_shader_image_load_formatted
Signed-off-by: Rhys Perry
---
src/compiler/glsl/ast_to_hir.cpp | 5 +
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/glsl_parser_extras.h | 7 +++
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 1 +
5 files changed, 15 insertions(+)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index dd60a2a87f..09ce5a44e6 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3461,6 +3461,11 @@ apply_image_qualifier_to_variable(const struct
ast_type_qualifier *qual,
}
var->data.image_format = qual->image_format;
+ } else if (state->has_image_load_formatted()) {
+ if (var->data.mode == ir_var_uniform &&
+ state->EXT_shader_image_load_formatted_warn) {
+ _mesa_glsl_warning(loc, state, "GL_EXT_image_load_formatted used");
+ }
} else {
if (var->data.mode == ir_var_uniform) {
if (state->es_shader) {
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index 04eba980e0..d575eb613d 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -714,6 +714,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
EXT(EXT_separate_shader_objects),
EXT(EXT_shader_framebuffer_fetch),
EXT(EXT_shader_framebuffer_fetch_non_coherent),
+ EXT(EXT_shader_image_load_formatted),
EXT(EXT_shader_integer_mix),
EXT_AEP(EXT_shader_io_blocks),
EXT(EXT_shader_samples_identical),
diff --git a/src/compiler/glsl/glsl_parser_extras.h
b/src/compiler/glsl/glsl_parser_extras.h
index 59a173418b..2818cdbb07 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -343,6 +343,11 @@ struct _mesa_glsl_parse_state {
return ARB_bindless_texture_enable;
}
+ bool has_image_load_formatted() const
+ {
+ return EXT_shader_image_load_formatted_enable;
+ }
+
void process_version_directive(YYLTYPE *locp, int version,
const char *ident);
@@ -790,6 +795,8 @@ struct _mesa_glsl_parse_state {
bool EXT_shader_framebuffer_fetch_warn;
bool EXT_shader_framebuffer_fetch_non_coherent_enable;
bool EXT_shader_framebuffer_fetch_non_coherent_warn;
+ bool EXT_shader_image_load_formatted_enable;
+ bool EXT_shader_image_load_formatted_warn;
bool EXT_shader_integer_mix_enable;
bool EXT_shader_integer_mix_warn;
bool EXT_shader_io_blocks_enable;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 79ef228b69..ac6acbb5ad 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -254,6 +254,7 @@ EXT(EXT_separate_shader_objects , dummy_true
EXT(EXT_separate_specular_color , dummy_true
, GLL, x , x , x , 1997)
EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch
, GLL, GLC, x , ES2, 2013)
EXT(EXT_shader_framebuffer_fetch_non_coherent,
EXT_shader_framebuffer_fetch_non_coherent, GLL, GLC, x, ES2, 2018)
+EXT(EXT_shader_image_load_formatted , EXT_shader_image_load_formatted
, GLL, GLC, x , x , 2014)
EXT(EXT_shader_integer_mix , EXT_shader_integer_mix
, GLL, GLC, x , 30, 2013)
EXT(EXT_shader_io_blocks, dummy_true
, x , x , x , 31, 2014)
EXT(EXT_shader_samples_identical, EXT_shader_samples_identical
, GLL, GLC, x , 31, 2015)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 482c42a4b2..4d0fdfe8e7 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4179,6 +4179,7 @@ struct gl_extensions
GLboolean EXT_provoking_vertex;
GLboolean EXT_semaphore;
GLboolean EXT_semaphore_fd;
+ GLboolean EXT_shader_image_load_formatted;
GLboolean EXT_shader_integer_mix;
GLboolean EXT_shader_samples_identical;
GLboolean EXT_stencil_two_side;
--
2.14.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] nv50/ir: use suld.p on GM107+
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 4 +++
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 ++
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 --
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 17 +++
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 27 -
5 files changed, 69 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index f4f3c70888..76dd93967b 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -221,6 +221,10 @@ enum operation
#define NV50_IR_SUBOP_SULD_ZERO0
#define NV50_IR_SUBOP_SULD_TRAP1
#define NV50_IR_SUBOP_SULD_SDCL3
+// These three are only for GM107+ and are set during register allocation
+#define NV50_IR_SUBOP_SULDP_RGBA (0 << 2)
+#define NV50_IR_SUBOP_SULDP_RG (1 << 2)
+#define NV50_IR_SUBOP_SULDP_R (2 << 2)
#define NV50_IR_SUBOP_SUBFM_3D 1
#define NV50_IR_SUBOP_SUCLAMP_2D 0x10
#define NV50_IR_SUBOP_SUCLAMP_SD(r, d) (( 0 + (r)) | ((d == 2) ? 0x10 : 0))
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 26826d6360..f1db0674b1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -3042,26 +3042,36 @@ void
CodeEmitterGM107::emitSULDx()
{
const TexInstruction *insn = this->insn->asTex();
- int type = 0;
emitInsn(0xeb00);
if (insn->op == OP_SULDB)
emitField(0x34, 1, 1);
emitSUTarget();
- switch (insn->dType) {
- case TYPE_S8: type = 1; break;
- case TYPE_U16: type = 2; break;
- case TYPE_S16: type = 3; break;
- case TYPE_U32: type = 4; break;
- case TYPE_U64: type = 5; break;
- case TYPE_B128: type = 6; break;
- default:
- assert(insn->dType == TYPE_U8);
- break;
+ if (insn->op == OP_SULDB) {
+ int type = 0;
+ switch (insn->dType) {
+ case TYPE_S8: type = 1; break;
+ case TYPE_U16: type = 2; break;
+ case TYPE_S16: type = 3; break;
+ case TYPE_U32: type = 4; break;
+ case TYPE_U64: type = 5; break;
+ case TYPE_B128: type = 6; break;
+ default:
+ assert(insn->dType == TYPE_U8);
+ break;
+ }
+ emitField(0x14, 3, type);
+ } else {
+ int type = 0;
+ switch (insn->subOp & 0xc) {
+ case NV50_IR_SUBOP_SULDP_R:type = 0x1; break;
+ case NV50_IR_SUBOP_SULDP_RG: type = 0x3; break;
+ case NV50_IR_SUBOP_SULDP_RGBA: type = 0xf; break;
+ }
+ emitField(0x14, 4, type);
}
emitLDSTc(0x18);
- emitField(0x14, 3, type);
emitGPR (0x00, insn->def(0));
emitGPR (0x08, insn->src(0));
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 29f674b451..f7ffa5627c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2397,9 +2397,6 @@ NVC0LoweringPass::handleSurfaceOpGM107(TexInstruction *su)
{
processSurfaceCoordsGM107(su);
- if (su->op == OP_SULDP)
- convertSurfaceFormat(su);
-
if (su->op == OP_SUREDP) {
Value *def = su->getDef(0);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index cbb21f5f72..8a9e0af4fd 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
@@ -240,6 +240,16 @@ static const char *barOpStr[] =
"sync", "arrive", "red and", "red or", "red popc"
};
+static const char *suldOpStr[] =
+{
+ "zero", "trap", "sdcl"
+};
+
+static const char *suldSwizzleOpStr[] =
+{
+ "rgba", "rg", "r"
+};
+
static const char *DataTypeStr[] =
{
"-",
@@ -624,6 +634,13 @@ void Instruction::print() const
if (subOp < ARRAY_SIZE(barOpStr))
PRINT("%s ", barOpStr[subOp]);
break;
+ case OP_SULDB:
+ case OP_SULDP:
+ if ((subOp & 0x3) < ARRAY_SIZE(suldOpStr))
+PRINT("%s ", suldOpStr[subOp & 0x3]);
+ if (op == OP_SULDP && subOp >> 2 < (int)ARRAY_SIZE(suldSwizzleOpStr))
+PRINT("%s ", suldSwizzleOpStr[subOp >> 2]);
+ break;
default:
if (subOp)
PRINT("(SUBOP:%u) ", subOp);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 28e0e260ce..4a362a6c12 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -2111,8 +2111,33 @@
RegAlloc::InsertConstraintsPass::texConstraintGM107(TexInstruction *tex)
{
int n, s;
- if
Re: [Mesa-dev] [PATCH 2/5] mesa, glsl: add support for EXT_shader_image_load_formatted
On Fri, Jun 15, 2018 at 4:31 PM, Ilia Mirkin wrote:
> On Fri, Jun 15, 2018 at 4:24 PM, Rhys Perry wrote:
>> Signed-off-by: Rhys Perry
>> ---
>> src/compiler/glsl/ast_to_hir.cpp | 5 +
>> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
>> src/compiler/glsl/glsl_parser_extras.h | 7 +++
>> src/mesa/main/extensions_table.h | 1 +
>> src/mesa/main/mtypes.h | 1 +
>> 5 files changed, 15 insertions(+)
>>
>> diff --git a/src/compiler/glsl/ast_to_hir.cpp
>> b/src/compiler/glsl/ast_to_hir.cpp
>> index dd60a2a87f..09ce5a44e6 100644
>> --- a/src/compiler/glsl/ast_to_hir.cpp
>> +++ b/src/compiler/glsl/ast_to_hir.cpp
>> @@ -3461,6 +3461,11 @@ apply_image_qualifier_to_variable(const struct
>> ast_type_qualifier *qual,
>>}
>>
>>var->data.image_format = qual->image_format;
>> + } else if (state->has_image_load_formatted()) {
>> + if (var->data.mode == ir_var_uniform &&
>> + state->EXT_shader_image_load_formatted_warn) {
>> + _mesa_glsl_warning(loc, state, "GL_EXT_image_load_formatted used");
>
> I'm confused by this. IIRC the warn stuff is so that you get a warning
> when you try to enable an ext that's not available (the options are
> "enable", "warn", and "require" -- the latter fails the compile while
> the first two allow you to handle it with #ifdef GL_EXT_foo).
As was pointed out to me, warn is precisely what Rhys had originally -
a warning when you use some extension feature. We utterly fail at this
in mesa though. So this can stay then...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600: fix copy/paste bug for sampleMaskIn workaround
From: Roland Scheidegger
The sampleMaskIn workaround (b936f4d1ca0d2ab1e828ff6a6e617f12469687fa)
tries to figure out if the shader is running at per-sample frequency, but
there's a typo bug so it will only recognize per-sample linar inputs,
not per-sample perspective ones.
Spotted by Eric Engestrom
---
src/gallium/drivers/r600/r600_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index c9f2fa6485..c466a48262 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1247,7 +1247,7 @@ static int allocate_system_value_inputs(struct
r600_shader_ctx *ctx, int gpr_off
tgsi_parse_free();
if (ctx->info.reads_samplemask &&
- (ctx->info.uses_linear_sample || ctx->info.uses_linear_sample)) {
+ (ctx->info.uses_linear_sample || ctx->info.uses_persp_sample)) {
inputs[1].enabled = true;
}
--
2.12.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] anv: Disable constant buffer 0 being relative.
On Fri, Jun 15, 2018 at 1:31 PM, Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> On Fri, Jun 15, 2018 at 01:21:17PM -0700, Jason Ekstrand wrote:
> > On Fri, Jun 15, 2018 at 1:12 PM, Rafael Antognolli <
> rafael.antogno...@intel.com
> > > wrote:
> >
> > If we are on gen8+ and have context isolation support, just make that
> > constant buffer address be absolute, so we can use it for push UBOs
> too.
> > ---
> > src/intel/vulkan/anv_device.c | 5 -
> > src/intel/vulkan/anv_private.h | 1 +
> > src/intel/vulkan/genX_state.c | 27 +++
> > 3 files changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index d1637f097e8..002b05f15f8 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -430,7 +430,8 @@ anv_physical_device_init(struct
> anv_physical_device
> > *device,
> > device->compiler->shader_debug_log = compiler_debug_log;
> > device->compiler->shader_perf_log = compiler_perf_log;
> > device->compiler->supports_pull_constants = false;
> > - device->compiler->constant_buffer_0_is_relative = true;
> > + device->compiler->constant_buffer_0_is_relative =
> > + device->info.gen < 8 || !device->has_context_isolation;
> >
> > isl_device_init(>isl_dev, >info, swizzled);
> >
> > @@ -1519,6 +1520,8 @@ VkResult anv_CreateDevice(
> > device->chipset_id = physical_device->chipset_id;
> > device->no_hw = physical_device->no_hw;
> > device->lost = false;
> > + device->constant_buffer_0_is_relative =
> > + physical_device->compiler->constant_buffer_0_is_relative;
> >
> > if (pAllocator)
> >device->alloc = *pAllocator;
> > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > private.h
> > index 6af2a0bd3f3..d7297da6f57 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -983,6 +983,7 @@ struct anv_device {
> > pthread_mutex_t mutex;
> > pthread_cond_t queue_submit;
> > boollost;
> > +bool
> > constant_buffer_0_is_relative;
> >
> >
> > I don't think we need a device boolean for this. Let's just dig it out
> of the
> > compiler or the physical device. I think the physical device probably
> makes a
> > bit more sense. Other than that, the series looks good to me.
>
> Do you mean store constant_buffer_0_is_relative into the physical
> device? Or just check for physical_device->context_isolation?
>
Just check physical_device->context_isolation. We don't need three
booleans to get out of sync.
--Jason
> > };
> >
> > static inline struct anv_state_pool *
> > diff --git a/src/intel/vulkan/genX_state.c
> b/src/intel/vulkan/genX_state.c
> > index c6e54046910..46e020c8134 100644
> > --- a/src/intel/vulkan/genX_state.c
> > +++ b/src/intel/vulkan/genX_state.c
> > @@ -169,6 +169,33 @@ genX(init_device_state)(struct anv_device
> *device)
> > gen10_emit_wa_lri_to_cache_mode_zero();
> > #endif
> >
> > + /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> > +* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> > +*
> > +* This is only safe on kernels with context isolation support.
> > +*/
> > + if (GEN_GEN >= 8 &&
> > + !device->constant_buffer_0_is_relative) {
> > + UNUSED uint32_t tmp_reg;
> > +#if GEN_GEN >= 9
> > + anv_pack_struct(_reg, GENX(CS_DEBUG_MODE2),
> > + .CONSTANT_BUFFERAddressOffsetDisable = true,
> > + .CONSTANT_BUFFERAddressOffsetDisableMask =
> true);
> > + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> > + lri.RegisterOffset = GENX(CS_DEBUG_MODE2_num);
> > + lri.DataDWord = tmp_reg;
> > + }
> > +#elif GEN_GEN == 8
> > + anv_pack_struct(_reg, GENX(INSTPM),
> > + .CONSTANT_BUFFERAddressOffsetDisable = true,
> > + .CONSTANT_BUFFERAddressOffsetDisableMask =
> true);
> > + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> > + lri.RegisterOffset = GENX(INSTPM_num);
> > + lri.DataDWord = tmp_reg;
> > + }
> > +#endif
> > + }
> > +
> > anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
> >
> > assert(batch.next <= batch.end);
> > --
> > 2.14.3
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
>
___
mesa-dev
[Mesa-dev] [AppVeyor] mesa master #7937 completed
Build mesa 7937 completed Commit 0d4f338a11 by Dylan Baker on 6/15/2018 8:53 PM: docs: Update release-notes and calendar Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] mesa, glsl: add support for EXT_shader_image_load_formatted
Yeah, I think that's right.
I must have misread something.
On Fri, Jun 15, 2018 at 9:31 PM, Ilia Mirkin wrote:
> On Fri, Jun 15, 2018 at 4:24 PM, Rhys Perry wrote:
>> Signed-off-by: Rhys Perry
>> ---
>> src/compiler/glsl/ast_to_hir.cpp | 5 +
>> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
>> src/compiler/glsl/glsl_parser_extras.h | 7 +++
>> src/mesa/main/extensions_table.h | 1 +
>> src/mesa/main/mtypes.h | 1 +
>> 5 files changed, 15 insertions(+)
>>
>> diff --git a/src/compiler/glsl/ast_to_hir.cpp
>> b/src/compiler/glsl/ast_to_hir.cpp
>> index dd60a2a87f..09ce5a44e6 100644
>> --- a/src/compiler/glsl/ast_to_hir.cpp
>> +++ b/src/compiler/glsl/ast_to_hir.cpp
>> @@ -3461,6 +3461,11 @@ apply_image_qualifier_to_variable(const struct
>> ast_type_qualifier *qual,
>>}
>>
>>var->data.image_format = qual->image_format;
>> + } else if (state->has_image_load_formatted()) {
>> + if (var->data.mode == ir_var_uniform &&
>> + state->EXT_shader_image_load_formatted_warn) {
>> + _mesa_glsl_warning(loc, state, "GL_EXT_image_load_formatted used");
>
> I'm confused by this. IIRC the warn stuff is so that you get a warning
> when you try to enable an ext that's not available (the options are
> "enable", "warn", and "require" -- the latter fails the compile while
> the first two allow you to handle it with #ifdef GL_EXT_foo).
>
>> + }
>> } else {
>>if (var->data.mode == ir_var_uniform) {
>> if (state->es_shader) {
>> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
>> b/src/compiler/glsl/glsl_parser_extras.cpp
>> index 04eba980e0..187bc0f18e 100644
>> --- a/src/compiler/glsl/glsl_parser_extras.cpp
>> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
>> @@ -714,6 +714,7 @@ static const _mesa_glsl_extension
>> _mesa_glsl_supported_extensions[] = {
>> EXT(EXT_separate_shader_objects),
>> EXT(EXT_shader_framebuffer_fetch),
>> EXT(EXT_shader_framebuffer_fetch_non_coherent),
>> + EXT(EXT_shader_image_load_formatted)
>> EXT(EXT_shader_integer_mix),
>> EXT_AEP(EXT_shader_io_blocks),
>> EXT(EXT_shader_samples_identical),
>> diff --git a/src/compiler/glsl/glsl_parser_extras.h
>> b/src/compiler/glsl/glsl_parser_extras.h
>> index 59a173418b..2818cdbb07 100644
>> --- a/src/compiler/glsl/glsl_parser_extras.h
>> +++ b/src/compiler/glsl/glsl_parser_extras.h
>> @@ -343,6 +343,11 @@ struct _mesa_glsl_parse_state {
>>return ARB_bindless_texture_enable;
>> }
>>
>> + bool has_image_load_formatted() const
>> + {
>> + return EXT_shader_image_load_formatted_enable;
>> + }
>> +
>> void process_version_directive(YYLTYPE *locp, int version,
>>const char *ident);
>>
>> @@ -790,6 +795,8 @@ struct _mesa_glsl_parse_state {
>> bool EXT_shader_framebuffer_fetch_warn;
>> bool EXT_shader_framebuffer_fetch_non_coherent_enable;
>> bool EXT_shader_framebuffer_fetch_non_coherent_warn;
>> + bool EXT_shader_image_load_formatted_enable;
>> + bool EXT_shader_image_load_formatted_warn;
>> bool EXT_shader_integer_mix_enable;
>> bool EXT_shader_integer_mix_warn;
>> bool EXT_shader_io_blocks_enable;
>> diff --git a/src/mesa/main/extensions_table.h
>> b/src/mesa/main/extensions_table.h
>> index 79ef228b69..ac6acbb5ad 100644
>> --- a/src/mesa/main/extensions_table.h
>> +++ b/src/mesa/main/extensions_table.h
>> @@ -254,6 +254,7 @@ EXT(EXT_separate_shader_objects , dummy_true
>> EXT(EXT_separate_specular_color , dummy_true
>> , GLL, x , x , x , 1997)
>> EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch
>> , GLL, GLC, x , ES2, 2013)
>> EXT(EXT_shader_framebuffer_fetch_non_coherent,
>> EXT_shader_framebuffer_fetch_non_coherent, GLL, GLC, x, ES2, 2018)
>> +EXT(EXT_shader_image_load_formatted ,
>> EXT_shader_image_load_formatted, GLL, GLC, x , x , 2014)
>> EXT(EXT_shader_integer_mix , EXT_shader_integer_mix
>> , GLL, GLC, x , 30, 2013)
>> EXT(EXT_shader_io_blocks, dummy_true
>> , x , x , x , 31, 2014)
>> EXT(EXT_shader_samples_identical, EXT_shader_samples_identical
>> , GLL, GLC, x , 31, 2015)
>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>> index 482c42a4b2..4d0fdfe8e7 100644
>> --- a/src/mesa/main/mtypes.h
>> +++ b/src/mesa/main/mtypes.h
>> @@ -4179,6 +4179,7 @@ struct gl_extensions
>> GLboolean EXT_provoking_vertex;
>> GLboolean EXT_semaphore;
>> GLboolean EXT_semaphore_fd;
>> + GLboolean EXT_shader_image_load_formatted;
>> GLboolean EXT_shader_integer_mix;
>> GLboolean EXT_shader_samples_identical;
>> GLboolean EXT_stencil_two_side;
>> --
>> 2.14.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>>
[Mesa-dev] [ANNOUNCE] mesa 18.1.2
Hi List, Mesa 18.1.2 is now available for download. In this release we have: - Fixes for libatomic checks on non-arm and non-x86 platforms - porting of additional libatomic checks to meson from autotools - numerous radv fixes - numerous intel fix - several files added to the release tarball not present before - A few fixes each for radeonsi, r300, ac, glx, and vulkan Dylan Alex Smith (4): radv: Consolidate GFX9 merged shader lookup logic radv: Handle GFX9 merged shaders in radv_flush_constants() radeonsi: Fix crash on shaders using MSAA image load/store radv: Set active_stages the same whether or not shaders were cached Andrew Galante (2): meson: Test for __atomic_add_fetch in atomic checks configure.ac: Test for __atomic_add_fetch in atomic checks Bas Nieuwenhuizen (1): radv: Don't pass a TESS_EVAL shader when tesselation is not enabled. Cameron Kumar (1): vulkan/wsi: Destroy swapchain images after terminating FIFO queues Dylan Baker (6): docs/relnotes: Add sha256 sums for mesa 18.1.1 cherry-ignore: add commits not to pull cherry-ignore: Add patches from Jason that he rebased on 18.1 meson: work around gentoo applying -m32 to host compiler in cross builds cherry-ignore: Add another patch version: bump version for 18.1.2 release Eric Engestrom (3): autotools: add missing android file to package configure: radv depends on mako i965: fix resource leak Jason Ekstrand (10): intel/eu: Add some brw_get_default_ helpers intel/eu: Copy fields manually in brw_next_insn intel/eu: Set flag [sub]register number differently for 3src intel/blorp: Don't vertex fetch directly from clear values intel/isl: Add bounds-checking assertions in isl_format_get_layout intel/isl: Add bounds-checking assertions for the format_info table i965/screen: Refactor query_dma_buf_formats i965/screen: Use RGBA non-sRGB formats for images anv: Set fence/semaphore types to NONE in impl_cleanup i965/screen: Return false for unsupported formats in query_modifiers Jordan Justen (1): mesa/program_binary: add implicit UseProgram after successful ProgramBinary Juan A. Suarez Romero (1): glsl: Add ir_binop_vector_extract in NIR Kenneth Graunke (2): i965: Fix batch-last mode to properly swap BOs. anv: Disable __gen_validate_value if NDEBUG is set. Marek Olšák (1): r300g/swtcl: make pipe_context uploaders use malloc'd memory as before Matt Turner (1): meson: Fix -latomic check Michel Dänzer (1): glx: Fix number of property values to read in glXImportContextEXT Nicolas Boichat (1): configure.ac/meson.build: Fix -latomic test Philip Rebohle (1): radv: Use correct color format for fast clears Samuel Pitoiset (3): radv: fix a GPU hang when MRTs are sparse radv: fix missing ZRANGE_PRECISION(1) for GFX9+ radv: add a workaround for DXVK hangs by setting amdgpu-skip-threshold Scott D Phillips (1): intel/tools: add intel_sanitize_gpu to EXTRA_DIST Thomas Petazzoni (1): configure.ac: rework -latomic check Timothy Arceri (2): ac: fix possible truncation of intrinsic name radeonsi: fix possible truncation on renderer string git tag: mesa-18.1.2 https://mesa.freedesktop.org/archive/mesa-18.1.2.tar.gz MD5: 66ec197f796090b8782f4d162bdebc66 mesa-18.1.2.tar.gz SHA1: d372eeaed5162d86c0e141bd2b1e38439163a0c8 mesa-18.1.2.tar.gz SHA256: a644df23937f4078a2bd9a54349f6315c1955f5e3a4ac272832da51dea4d3c11 mesa-18.1.2.tar.gz SHA512: dfc821133cb577699fa4208034153ea035137553f042e59477967c822df47b5a851472c25860e7b220e1da29d1b3ef91af1110c584d3119da4060119762de1aa mesa-18.1.2.tar.gz PGP: https://mesa.freedesktop.org/archive/mesa-18.1.2.tar.gz.sig https://mesa.freedesktop.org/archive/mesa-18.1.2.tar.xz MD5: a2d4f031eb6bd6111d44d84004476918 mesa-18.1.2.tar.xz SHA1: 938d22b966e9861a5387d31c44cd4753931d3076 mesa-18.1.2.tar.xz SHA256: 070bf0648ba5b242d7303ceed32aed80842f4c0ba16e5acc1a650a46eadfb1f9 mesa-18.1.2.tar.xz SHA512: 1b896ecc42c2f81813d551a2b14d271d274a948fa10bf5b7a567417690316c2ab7e7fdd52fe004732cd1a47661ba91acf7d5b21e3b3f28e21b50aadbfa96a5d5 mesa-18.1.2.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-18.1.2.tar.xz.sig signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] nv50/ir: use suld.p on GM107+
On Fri, Jun 15, 2018 at 4:24 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 4 +++
> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34
> ++
> .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 --
> .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 27 +
> .../drivers/nouveau/codegen/nv50_ir_print.cpp | 17 +++
> 5 files changed, 70 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> index f4f3c70888..a13bc6a6bb 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> @@ -221,6 +221,10 @@ enum operation
> #define NV50_IR_SUBOP_SULD_ZERO0
> #define NV50_IR_SUBOP_SULD_TRAP1
> #define NV50_IR_SUBOP_SULD_SDCL3
> +// These three are only for GM107+.
> +#define NV50_IR_SUBOP_SULDP_RGBA (0 << 2)
> +#define NV50_IR_SUBOP_SULDP_RG (1 << 2)
> +#define NV50_IR_SUBOP_SULDP_R (2 << 2)
> #define NV50_IR_SUBOP_SUBFM_3D 1
> #define NV50_IR_SUBOP_SUCLAMP_2D 0x10
> #define NV50_IR_SUBOP_SUCLAMP_SD(r, d) (( 0 + (r)) | ((d == 2) ? 0x10 : 0))
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> index 26826d6360..f1db0674b1 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> @@ -3042,26 +3042,36 @@ void
> CodeEmitterGM107::emitSULDx()
> {
> const TexInstruction *insn = this->insn->asTex();
> - int type = 0;
>
> emitInsn(0xeb00);
> if (insn->op == OP_SULDB)
>emitField(0x34, 1, 1);
> emitSUTarget();
>
> - switch (insn->dType) {
> - case TYPE_S8: type = 1; break;
> - case TYPE_U16: type = 2; break;
> - case TYPE_S16: type = 3; break;
> - case TYPE_U32: type = 4; break;
> - case TYPE_U64: type = 5; break;
> - case TYPE_B128: type = 6; break;
> - default:
> - assert(insn->dType == TYPE_U8);
> - break;
> + if (insn->op == OP_SULDB) {
> + int type = 0;
> + switch (insn->dType) {
> + case TYPE_S8: type = 1; break;
> + case TYPE_U16: type = 2; break;
> + case TYPE_S16: type = 3; break;
> + case TYPE_U32: type = 4; break;
> + case TYPE_U64: type = 5; break;
> + case TYPE_B128: type = 6; break;
> + default:
> + assert(insn->dType == TYPE_U8);
> + break;
> + }
> + emitField(0x14, 3, type);
> + } else {
> + int type = 0;
> + switch (insn->subOp & 0xc) {
> + case NV50_IR_SUBOP_SULDP_R:type = 0x1; break;
> + case NV50_IR_SUBOP_SULDP_RG: type = 0x3; break;
> + case NV50_IR_SUBOP_SULDP_RGBA: type = 0xf; break;
> + }
> + emitField(0x14, 4, type);
> }
> emitLDSTc(0x18);
> - emitField(0x14, 3, type);
> emitGPR (0x00, insn->def(0));
> emitGPR (0x08, insn->src(0));
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index 29f674b451..f7ffa5627c 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -2397,9 +2397,6 @@ NVC0LoweringPass::handleSurfaceOpGM107(TexInstruction
> *su)
> {
> processSurfaceCoordsGM107(su);
>
> - if (su->op == OP_SULDP)
> - convertSurfaceFormat(su);
This will essentially flip us over to *always* using SULD.P right?
> -
> if (su->op == OP_SUREDP) {
>Value *def = su->getDef(0);
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> index 39177bd044..65db2acfa2 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> @@ -1671,6 +1671,7 @@ private:
> void handleCVT_EXTBF(Instruction *);
> void handleSUCLAMP(Instruction *);
> void handleNEG(Instruction *);
> + void handleSULDP(Instruction *);
>
> BuildUtil bld;
> };
> @@ -2175,6 +2176,29 @@ AlgebraicOpt::handleNEG(Instruction *i) {
> }
> }
>
> +void
> +AlgebraicOpt::handleSULDP(Instruction *i) {
> + if (prog->getTarget()->getChipset() < NVISA_GM107_CHIPSET)
> + return;
> +
> + int max = 0;
> + for (int d = 0; i->defExists(d); d++) {
> + if (i->getDef(d)->uses.size() > 0)
> + max = MAX2(max, d);
This isn't the best place to do stuff like that. This kinda feels like
it might belong in GCRA::texConstraintGM107...
> + }
> +
> + if (max == 0) {
> + i->subOp |= NV50_IR_SUBOP_SULDP_R;
> + i->setDef(1, NULL);
> + i->setDef(2, NULL);
> + i->setDef(3, NULL);
> + } else if (max == 1) {
> + i->subOp |= NV50_IR_SUBOP_SULDP_RG;
> +
Re: [Mesa-dev] [PATCH 1/5] gallium: add support for formatted image loads
On Fri, Jun 15, 2018 at 4:24 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/gallium/auxiliary/gallivm/lp_bld_limits.h | 1 +
> src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 +
> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
> src/gallium/drivers/r300/r300_screen.c | 2 ++
> src/gallium/drivers/r600/r600_pipe.c | 1 +
> src/gallium/drivers/radeonsi/si_get.c | 1 +
> src/gallium/drivers/svga/svga_screen.c | 1 +
> src/gallium/drivers/v3d/v3d_screen.c | 1 +
> src/gallium/drivers/vc4/vc4_screen.c | 1 +
> src/gallium/drivers/virgl/virgl_screen.c | 1 +
> src/gallium/include/pipe/p_defines.h | 1 +
> 13 files changed, 14 insertions(+)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> index c7755bfe1d..4e0b19f650 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> @@ -120,6 +120,7 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
>return 1;
> case PIPE_SHADER_CAP_INT64_ATOMICS:
> case PIPE_SHADER_CAP_FP16:
> + case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
>return 0;
> case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
>return PIPE_MAX_SAMPLERS;
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
> b/src/gallium/auxiliary/tgsi/tgsi_exec.h
> index 0fac7ea456..30253426b3 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
> @@ -522,6 +522,7 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
>return 1;
> case PIPE_SHADER_CAP_INT64_ATOMICS:
> case PIPE_SHADER_CAP_FP16:
> + case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
>return 0;
> case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
>return PIPE_MAX_SAMPLERS;
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index a77f70e6bb..57b2952ae5 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -343,6 +343,7 @@ nv30_screen_get_shader_param(struct pipe_screen *pscreen,
>case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
>case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
>case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
> + case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
> return 0;
>default:
> debug_printf("unknown vertex shader param %d\n", param);
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> index 2495a545fd..1139b02eb4 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> @@ -385,6 +385,7 @@ nv50_screen_get_shader_param(struct pipe_screen *pscreen,
> case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
> + case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
>return 0;
> default:
>NOUVEAU_ERR("unknown PIPE_SHADER_CAP %d\n", param);
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index f679cbdba3..412c5bf54d 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -422,6 +422,7 @@ nvc0_screen_get_shader_param(struct pipe_screen *pscreen,
> case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
> case PIPE_SHADER_CAP_INT64_ATOMICS:
> case PIPE_SHADER_CAP_FP16:
> + case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
> diff --git a/src/gallium/drivers/r300/r300_screen.c
> b/src/gallium/drivers/r300/r300_screen.c
> index 459349e821..da526612d3 100644
> --- a/src/gallium/drivers/r300/r300_screen.c
> +++ b/src/gallium/drivers/r300/r300_screen.c
> @@ -378,6 +378,7 @@ static int r300_get_shader_param(struct pipe_screen
> *pscreen,
> case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
> +case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
> return 0;
> case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
> return 32;
> @@ -444,6 +445,7 @@ static int r300_get_shader_param(struct pipe_screen
> *pscreen,
> case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
> +case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
> return 0;
> case
Re: [Mesa-dev] [PATCH 2/5] mesa, glsl: add support for EXT_shader_image_load_formatted
On Fri, Jun 15, 2018 at 4:24 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/compiler/glsl/ast_to_hir.cpp | 5 +
> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
> src/compiler/glsl/glsl_parser_extras.h | 7 +++
> src/mesa/main/extensions_table.h | 1 +
> src/mesa/main/mtypes.h | 1 +
> 5 files changed, 15 insertions(+)
>
> diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> index dd60a2a87f..09ce5a44e6 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -3461,6 +3461,11 @@ apply_image_qualifier_to_variable(const struct
> ast_type_qualifier *qual,
>}
>
>var->data.image_format = qual->image_format;
> + } else if (state->has_image_load_formatted()) {
> + if (var->data.mode == ir_var_uniform &&
> + state->EXT_shader_image_load_formatted_warn) {
> + _mesa_glsl_warning(loc, state, "GL_EXT_image_load_formatted used");
I'm confused by this. IIRC the warn stuff is so that you get a warning
when you try to enable an ext that's not available (the options are
"enable", "warn", and "require" -- the latter fails the compile while
the first two allow you to handle it with #ifdef GL_EXT_foo).
> + }
> } else {
>if (var->data.mode == ir_var_uniform) {
> if (state->es_shader) {
> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
> b/src/compiler/glsl/glsl_parser_extras.cpp
> index 04eba980e0..187bc0f18e 100644
> --- a/src/compiler/glsl/glsl_parser_extras.cpp
> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
> @@ -714,6 +714,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> EXT(EXT_separate_shader_objects),
> EXT(EXT_shader_framebuffer_fetch),
> EXT(EXT_shader_framebuffer_fetch_non_coherent),
> + EXT(EXT_shader_image_load_formatted)
> EXT(EXT_shader_integer_mix),
> EXT_AEP(EXT_shader_io_blocks),
> EXT(EXT_shader_samples_identical),
> diff --git a/src/compiler/glsl/glsl_parser_extras.h
> b/src/compiler/glsl/glsl_parser_extras.h
> index 59a173418b..2818cdbb07 100644
> --- a/src/compiler/glsl/glsl_parser_extras.h
> +++ b/src/compiler/glsl/glsl_parser_extras.h
> @@ -343,6 +343,11 @@ struct _mesa_glsl_parse_state {
>return ARB_bindless_texture_enable;
> }
>
> + bool has_image_load_formatted() const
> + {
> + return EXT_shader_image_load_formatted_enable;
> + }
> +
> void process_version_directive(YYLTYPE *locp, int version,
>const char *ident);
>
> @@ -790,6 +795,8 @@ struct _mesa_glsl_parse_state {
> bool EXT_shader_framebuffer_fetch_warn;
> bool EXT_shader_framebuffer_fetch_non_coherent_enable;
> bool EXT_shader_framebuffer_fetch_non_coherent_warn;
> + bool EXT_shader_image_load_formatted_enable;
> + bool EXT_shader_image_load_formatted_warn;
> bool EXT_shader_integer_mix_enable;
> bool EXT_shader_integer_mix_warn;
> bool EXT_shader_io_blocks_enable;
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index 79ef228b69..ac6acbb5ad 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -254,6 +254,7 @@ EXT(EXT_separate_shader_objects , dummy_true
> EXT(EXT_separate_specular_color , dummy_true
> , GLL, x , x , x , 1997)
> EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch
> , GLL, GLC, x , ES2, 2013)
> EXT(EXT_shader_framebuffer_fetch_non_coherent,
> EXT_shader_framebuffer_fetch_non_coherent, GLL, GLC, x, ES2, 2018)
> +EXT(EXT_shader_image_load_formatted ,
> EXT_shader_image_load_formatted, GLL, GLC, x , x , 2014)
> EXT(EXT_shader_integer_mix , EXT_shader_integer_mix
> , GLL, GLC, x , 30, 2013)
> EXT(EXT_shader_io_blocks, dummy_true
> , x , x , x , 31, 2014)
> EXT(EXT_shader_samples_identical, EXT_shader_samples_identical
> , GLL, GLC, x , 31, 2015)
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 482c42a4b2..4d0fdfe8e7 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -4179,6 +4179,7 @@ struct gl_extensions
> GLboolean EXT_provoking_vertex;
> GLboolean EXT_semaphore;
> GLboolean EXT_semaphore_fd;
> + GLboolean EXT_shader_image_load_formatted;
> GLboolean EXT_shader_integer_mix;
> GLboolean EXT_shader_samples_identical;
> GLboolean EXT_stencil_two_side;
> --
> 2.14.4
>
> ___
> 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 3/3] anv: Disable constant buffer 0 being relative.
On Fri, Jun 15, 2018 at 01:21:17PM -0700, Jason Ekstrand wrote:
> On Fri, Jun 15, 2018 at 1:12 PM, Rafael Antognolli
> > wrote:
>
> If we are on gen8+ and have context isolation support, just make that
> constant buffer address be absolute, so we can use it for push UBOs too.
> ---
> src/intel/vulkan/anv_device.c | 5 -
> src/intel/vulkan/anv_private.h | 1 +
> src/intel/vulkan/genX_state.c | 27 +++
> 3 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index d1637f097e8..002b05f15f8 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -430,7 +430,8 @@ anv_physical_device_init(struct anv_physical_device
> *device,
> device->compiler->shader_debug_log = compiler_debug_log;
> device->compiler->shader_perf_log = compiler_perf_log;
> device->compiler->supports_pull_constants = false;
> - device->compiler->constant_buffer_0_is_relative = true;
> + device->compiler->constant_buffer_0_is_relative =
> + device->info.gen < 8 || !device->has_context_isolation;
>
> isl_device_init(>isl_dev, >info, swizzled);
>
> @@ -1519,6 +1520,8 @@ VkResult anv_CreateDevice(
> device->chipset_id = physical_device->chipset_id;
> device->no_hw = physical_device->no_hw;
> device->lost = false;
> + device->constant_buffer_0_is_relative =
> + physical_device->compiler->constant_buffer_0_is_relative;
>
> if (pAllocator)
>device->alloc = *pAllocator;
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index 6af2a0bd3f3..d7297da6f57 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -983,6 +983,7 @@ struct anv_device {
> pthread_mutex_t mutex;
> pthread_cond_t queue_submit;
> boollost;
> +bool
> constant_buffer_0_is_relative;
>
>
> I don't think we need a device boolean for this. Let's just dig it out of the
> compiler or the physical device. I think the physical device probably makes a
> bit more sense. Other than that, the series looks good to me.
Do you mean store constant_buffer_0_is_relative into the physical
device? Or just check for physical_device->context_isolation?
> };
>
> static inline struct anv_state_pool *
> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
> index c6e54046910..46e020c8134 100644
> --- a/src/intel/vulkan/genX_state.c
> +++ b/src/intel/vulkan/genX_state.c
> @@ -169,6 +169,33 @@ genX(init_device_state)(struct anv_device *device)
> gen10_emit_wa_lri_to_cache_mode_zero();
> #endif
>
> + /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> +* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> +*
> +* This is only safe on kernels with context isolation support.
> +*/
> + if (GEN_GEN >= 8 &&
> + !device->constant_buffer_0_is_relative) {
> + UNUSED uint32_t tmp_reg;
> +#if GEN_GEN >= 9
> + anv_pack_struct(_reg, GENX(CS_DEBUG_MODE2),
> + .CONSTANT_BUFFERAddressOffsetDisable = true,
> + .CONSTANT_BUFFERAddressOffsetDisableMask = true);
> + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(CS_DEBUG_MODE2_num);
> + lri.DataDWord = tmp_reg;
> + }
> +#elif GEN_GEN == 8
> + anv_pack_struct(_reg, GENX(INSTPM),
> + .CONSTANT_BUFFERAddressOffsetDisable = true,
> + .CONSTANT_BUFFERAddressOffsetDisableMask = true);
> + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(INSTPM_num);
> + lri.DataDWord = tmp_reg;
> + }
> +#endif
> + }
> +
> anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
>
> assert(batch.next <= batch.end);
> --
> 2.14.3
>
> ___
> 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 5/5] nvc0, nv50/ir: add support for formatted image loads on GM107+
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 +--
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 3 ++-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index f7ffa5627c..0fc93d221e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2377,12 +2377,11 @@
NVC0LoweringPass::processSurfaceCoordsGM107(TexInstruction *su)
bld.mkCmp(OP_SET, CC_EQ, TYPE_U32, bld.getSSA(1, FILE_PREDICATE),
TYPE_U32, bld.mkImm(0),
loadSuInfo32(ind, slot, NVC0_SU_INFO_ADDR, su->tex.bindless));
- if (su->op != OP_SUSTP && su->tex.format) {
+ if (su->op != OP_SUSTP && su->tex.format && su->tex.format->components > 0)
{
const TexInstruction::ImgFormatDesc *format = su->tex.format;
int blockwidth = format->bits[0] + format->bits[1] +
format->bits[2] + format->bits[3];
- assert(format->components != 0);
// make sure that the format doesn't mismatch when it's not FMT_NONE
bld.mkCmp(OP_SET_OR, CC_NE, TYPE_U32, pred->getDef(0),
TYPE_U32, bld.loadImm(NULL, blockwidth / 8),
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 412c5bf54d..4a4fff92fa 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -422,7 +422,6 @@ nvc0_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
case PIPE_SHADER_CAP_INT64_ATOMICS:
case PIPE_SHADER_CAP_FP16:
- case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
return 0;
@@ -440,6 +439,8 @@ nvc0_screen_get_shader_param(struct pipe_screen *pscreen,
if (shader == PIPE_SHADER_FRAGMENT || shader == PIPE_SHADER_COMPUTE)
return NVC0_MAX_IMAGES;
return 0;
+ case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
+ return class_3d >= GM107_3D_CLASS;
default:
NOUVEAU_ERR("unknown PIPE_SHADER_CAP %d\n", param);
return 0;
--
2.14.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] gallium: add support for formatted image loads
Signed-off-by: Rhys Perry
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h | 1 +
src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 +
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
src/gallium/drivers/r300/r300_screen.c | 2 ++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeonsi/si_get.c | 1 +
src/gallium/drivers/svga/svga_screen.c | 1 +
src/gallium/drivers/v3d/v3d_screen.c | 1 +
src/gallium/drivers/vc4/vc4_screen.c | 1 +
src/gallium/drivers/virgl/virgl_screen.c | 1 +
src/gallium/include/pipe/p_defines.h | 1 +
13 files changed, 14 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
index c7755bfe1d..4e0b19f650 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
@@ -120,6 +120,7 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
return 1;
case PIPE_SHADER_CAP_INT64_ATOMICS:
case PIPE_SHADER_CAP_FP16:
+ case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
return 0;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
return PIPE_MAX_SAMPLERS;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 0fac7ea456..30253426b3 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -522,6 +522,7 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
return 1;
case PIPE_SHADER_CAP_INT64_ATOMICS:
case PIPE_SHADER_CAP_FP16:
+ case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
return 0;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
return PIPE_MAX_SAMPLERS;
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index a77f70e6bb..57b2952ae5 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -343,6 +343,7 @@ nv30_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
+ case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
return 0;
default:
debug_printf("unknown vertex shader param %d\n", param);
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 2495a545fd..1139b02eb4 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -385,6 +385,7 @@ nv50_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
+ case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
return 0;
default:
NOUVEAU_ERR("unknown PIPE_SHADER_CAP %d\n", param);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f679cbdba3..412c5bf54d 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -422,6 +422,7 @@ nvc0_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
case PIPE_SHADER_CAP_INT64_ATOMICS:
case PIPE_SHADER_CAP_FP16:
+ case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
return 0;
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index 459349e821..da526612d3 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -378,6 +378,7 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen,
case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
+case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
return 0;
case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
return 32;
@@ -444,6 +445,7 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen,
case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
+case PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED:
return 0;
case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
return 32;
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index ff7306998b..209bdf99e0 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -634,6
[Mesa-dev] [PATCH 4/5] nv50/ir: use suld.p on GM107+
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 4 +++
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 ++
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 --
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 27 +
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 17 +++
5 files changed, 70 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index f4f3c70888..a13bc6a6bb 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -221,6 +221,10 @@ enum operation
#define NV50_IR_SUBOP_SULD_ZERO0
#define NV50_IR_SUBOP_SULD_TRAP1
#define NV50_IR_SUBOP_SULD_SDCL3
+// These three are only for GM107+.
+#define NV50_IR_SUBOP_SULDP_RGBA (0 << 2)
+#define NV50_IR_SUBOP_SULDP_RG (1 << 2)
+#define NV50_IR_SUBOP_SULDP_R (2 << 2)
#define NV50_IR_SUBOP_SUBFM_3D 1
#define NV50_IR_SUBOP_SUCLAMP_2D 0x10
#define NV50_IR_SUBOP_SUCLAMP_SD(r, d) (( 0 + (r)) | ((d == 2) ? 0x10 : 0))
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 26826d6360..f1db0674b1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -3042,26 +3042,36 @@ void
CodeEmitterGM107::emitSULDx()
{
const TexInstruction *insn = this->insn->asTex();
- int type = 0;
emitInsn(0xeb00);
if (insn->op == OP_SULDB)
emitField(0x34, 1, 1);
emitSUTarget();
- switch (insn->dType) {
- case TYPE_S8: type = 1; break;
- case TYPE_U16: type = 2; break;
- case TYPE_S16: type = 3; break;
- case TYPE_U32: type = 4; break;
- case TYPE_U64: type = 5; break;
- case TYPE_B128: type = 6; break;
- default:
- assert(insn->dType == TYPE_U8);
- break;
+ if (insn->op == OP_SULDB) {
+ int type = 0;
+ switch (insn->dType) {
+ case TYPE_S8: type = 1; break;
+ case TYPE_U16: type = 2; break;
+ case TYPE_S16: type = 3; break;
+ case TYPE_U32: type = 4; break;
+ case TYPE_U64: type = 5; break;
+ case TYPE_B128: type = 6; break;
+ default:
+ assert(insn->dType == TYPE_U8);
+ break;
+ }
+ emitField(0x14, 3, type);
+ } else {
+ int type = 0;
+ switch (insn->subOp & 0xc) {
+ case NV50_IR_SUBOP_SULDP_R:type = 0x1; break;
+ case NV50_IR_SUBOP_SULDP_RG: type = 0x3; break;
+ case NV50_IR_SUBOP_SULDP_RGBA: type = 0xf; break;
+ }
+ emitField(0x14, 4, type);
}
emitLDSTc(0x18);
- emitField(0x14, 3, type);
emitGPR (0x00, insn->def(0));
emitGPR (0x08, insn->src(0));
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 29f674b451..f7ffa5627c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2397,9 +2397,6 @@ NVC0LoweringPass::handleSurfaceOpGM107(TexInstruction *su)
{
processSurfaceCoordsGM107(su);
- if (su->op == OP_SULDP)
- convertSurfaceFormat(su);
-
if (su->op == OP_SUREDP) {
Value *def = su->getDef(0);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 39177bd044..65db2acfa2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1671,6 +1671,7 @@ private:
void handleCVT_EXTBF(Instruction *);
void handleSUCLAMP(Instruction *);
void handleNEG(Instruction *);
+ void handleSULDP(Instruction *);
BuildUtil bld;
};
@@ -2175,6 +2176,29 @@ AlgebraicOpt::handleNEG(Instruction *i) {
}
}
+void
+AlgebraicOpt::handleSULDP(Instruction *i) {
+ if (prog->getTarget()->getChipset() < NVISA_GM107_CHIPSET)
+ return;
+
+ int max = 0;
+ for (int d = 0; i->defExists(d); d++) {
+ if (i->getDef(d)->uses.size() > 0)
+ max = MAX2(max, d);
+ }
+
+ if (max == 0) {
+ i->subOp |= NV50_IR_SUBOP_SULDP_R;
+ i->setDef(1, NULL);
+ i->setDef(2, NULL);
+ i->setDef(3, NULL);
+ } else if (max == 1) {
+ i->subOp |= NV50_IR_SUBOP_SULDP_RG;
+ i->setDef(2, NULL);
+ i->setDef(3, NULL);
+ }
+}
+
bool
AlgebraicOpt::visit(BasicBlock *bb)
{
@@ -2215,6 +2239,9 @@ AlgebraicOpt::visit(BasicBlock *bb)
case OP_NEG:
handleNEG(i);
break;
+ case OP_SULDP:
+ handleSULDP(i);
+ break;
default:
break;
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index cbb21f5f72..8a9e0af4fd 100644
---
[Mesa-dev] [PATCH 0/5] nvc0: Implement EXT_shader_image_load_formatted
This patch series implements EXT_shader_image_load_formatted on Maxwell+. It should implement all of the spec except, if the extension is enabled, passing image variables without a format qualifier to atomic operations will not raise a compilation error like it should. This is because knowing the format used in an image operation before function inlining can be difficult, because formats don't have to (and currently can't) be specified in the paramter declaration. So this series leaves this issue to hopefully be resolved in a later patch. Rhys Perry (5): gallium: add support for formatted image loads mesa,glsl: add support for EXT_shader_image_load_formatted st/mesa: add support for EXT_shader_image_load_formatted nv50/ir: use suld.p on GM107+ nvc0,nv50/ir: add support for formatted image loads on GM107+ src/compiler/glsl/ast_to_hir.cpp | 5 src/compiler/glsl/glsl_parser_extras.cpp | 1 + src/compiler/glsl/glsl_parser_extras.h | 7 + src/gallium/auxiliary/gallivm/lp_bld_limits.h | 1 + src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 + src/gallium/drivers/nouveau/codegen/nv50_ir.h | 4 +++ .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 ++ .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 6 +--- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 27 + .../drivers/nouveau/codegen/nv50_ir_print.cpp | 17 +++ src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ src/gallium/drivers/r300/r300_screen.c | 2 ++ src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_get.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/v3d/v3d_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/mesa/main/extensions_table.h | 1 + src/mesa/main/mtypes.h | 1 + src/mesa/state_tracker/st_extensions.c | 3 ++ 24 files changed, 104 insertions(+), 17 deletions(-) -- 2.14.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] mesa, glsl: add support for EXT_shader_image_load_formatted
Signed-off-by: Rhys Perry
---
src/compiler/glsl/ast_to_hir.cpp | 5 +
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/glsl_parser_extras.h | 7 +++
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 1 +
5 files changed, 15 insertions(+)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index dd60a2a87f..09ce5a44e6 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3461,6 +3461,11 @@ apply_image_qualifier_to_variable(const struct
ast_type_qualifier *qual,
}
var->data.image_format = qual->image_format;
+ } else if (state->has_image_load_formatted()) {
+ if (var->data.mode == ir_var_uniform &&
+ state->EXT_shader_image_load_formatted_warn) {
+ _mesa_glsl_warning(loc, state, "GL_EXT_image_load_formatted used");
+ }
} else {
if (var->data.mode == ir_var_uniform) {
if (state->es_shader) {
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index 04eba980e0..187bc0f18e 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -714,6 +714,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
EXT(EXT_separate_shader_objects),
EXT(EXT_shader_framebuffer_fetch),
EXT(EXT_shader_framebuffer_fetch_non_coherent),
+ EXT(EXT_shader_image_load_formatted)
EXT(EXT_shader_integer_mix),
EXT_AEP(EXT_shader_io_blocks),
EXT(EXT_shader_samples_identical),
diff --git a/src/compiler/glsl/glsl_parser_extras.h
b/src/compiler/glsl/glsl_parser_extras.h
index 59a173418b..2818cdbb07 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -343,6 +343,11 @@ struct _mesa_glsl_parse_state {
return ARB_bindless_texture_enable;
}
+ bool has_image_load_formatted() const
+ {
+ return EXT_shader_image_load_formatted_enable;
+ }
+
void process_version_directive(YYLTYPE *locp, int version,
const char *ident);
@@ -790,6 +795,8 @@ struct _mesa_glsl_parse_state {
bool EXT_shader_framebuffer_fetch_warn;
bool EXT_shader_framebuffer_fetch_non_coherent_enable;
bool EXT_shader_framebuffer_fetch_non_coherent_warn;
+ bool EXT_shader_image_load_formatted_enable;
+ bool EXT_shader_image_load_formatted_warn;
bool EXT_shader_integer_mix_enable;
bool EXT_shader_integer_mix_warn;
bool EXT_shader_io_blocks_enable;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 79ef228b69..ac6acbb5ad 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -254,6 +254,7 @@ EXT(EXT_separate_shader_objects , dummy_true
EXT(EXT_separate_specular_color , dummy_true
, GLL, x , x , x , 1997)
EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch
, GLL, GLC, x , ES2, 2013)
EXT(EXT_shader_framebuffer_fetch_non_coherent,
EXT_shader_framebuffer_fetch_non_coherent, GLL, GLC, x, ES2, 2018)
+EXT(EXT_shader_image_load_formatted , EXT_shader_image_load_formatted
, GLL, GLC, x , x , 2014)
EXT(EXT_shader_integer_mix , EXT_shader_integer_mix
, GLL, GLC, x , 30, 2013)
EXT(EXT_shader_io_blocks, dummy_true
, x , x , x , 31, 2014)
EXT(EXT_shader_samples_identical, EXT_shader_samples_identical
, GLL, GLC, x , 31, 2015)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 482c42a4b2..4d0fdfe8e7 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4179,6 +4179,7 @@ struct gl_extensions
GLboolean EXT_provoking_vertex;
GLboolean EXT_semaphore;
GLboolean EXT_semaphore_fd;
+ GLboolean EXT_shader_image_load_formatted;
GLboolean EXT_shader_integer_mix;
GLboolean EXT_shader_samples_identical;
GLboolean EXT_stencil_two_side;
--
2.14.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] st/mesa: add support for EXT_shader_image_load_formatted
Signed-off-by: Rhys Perry --- src/mesa/state_tracker/st_extensions.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 467d9b0759..10342c1be2 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -1409,4 +1409,7 @@ void st_init_extensions(struct pipe_screen *screen, pre_snap_triangles && pre_snap_points_lines; } } + + extensions->EXT_shader_image_load_formatted = + screen->get_param(screen, PIPE_SHADER_CAP_IMAGE_LOAD_FORMATTED); } -- 2.14.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] anv: Disable constant buffer 0 being relative.
On Fri, Jun 15, 2018 at 1:12 PM, Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> If we are on gen8+ and have context isolation support, just make that
> constant buffer address be absolute, so we can use it for push UBOs too.
> ---
> src/intel/vulkan/anv_device.c | 5 -
> src/intel/vulkan/anv_private.h | 1 +
> src/intel/vulkan/genX_state.c | 27 +++
> 3 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index d1637f097e8..002b05f15f8 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -430,7 +430,8 @@ anv_physical_device_init(struct anv_physical_device
> *device,
> device->compiler->shader_debug_log = compiler_debug_log;
> device->compiler->shader_perf_log = compiler_perf_log;
> device->compiler->supports_pull_constants = false;
> - device->compiler->constant_buffer_0_is_relative = true;
> + device->compiler->constant_buffer_0_is_relative =
> + device->info.gen < 8 || !device->has_context_isolation;
>
> isl_device_init(>isl_dev, >info, swizzled);
>
> @@ -1519,6 +1520,8 @@ VkResult anv_CreateDevice(
> device->chipset_id = physical_device->chipset_id;
> device->no_hw = physical_device->no_hw;
> device->lost = false;
> + device->constant_buffer_0_is_relative =
> + physical_device->compiler->constant_buffer_0_is_relative;
>
> if (pAllocator)
>device->alloc = *pAllocator;
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index 6af2a0bd3f3..d7297da6f57 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -983,6 +983,7 @@ struct anv_device {
> pthread_mutex_t mutex;
> pthread_cond_t queue_submit;
> boollost;
> +bool
> constant_buffer_0_is_relative;
>
I don't think we need a device boolean for this. Let's just dig it out of
the compiler or the physical device. I think the physical device probably
makes a bit more sense. Other than that, the series looks good to me.
--Jason
> };
>
> static inline struct anv_state_pool *
> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
> index c6e54046910..46e020c8134 100644
> --- a/src/intel/vulkan/genX_state.c
> +++ b/src/intel/vulkan/genX_state.c
> @@ -169,6 +169,33 @@ genX(init_device_state)(struct anv_device *device)
> gen10_emit_wa_lri_to_cache_mode_zero();
> #endif
>
> + /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> +* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> +*
> +* This is only safe on kernels with context isolation support.
> +*/
> + if (GEN_GEN >= 8 &&
> + !device->constant_buffer_0_is_relative) {
> + UNUSED uint32_t tmp_reg;
> +#if GEN_GEN >= 9
> + anv_pack_struct(_reg, GENX(CS_DEBUG_MODE2),
> + .CONSTANT_BUFFERAddressOffsetDisable = true,
> + .CONSTANT_BUFFERAddressOffsetDisableMask = true);
> + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(CS_DEBUG_MODE2_num);
> + lri.DataDWord = tmp_reg;
> + }
> +#elif GEN_GEN == 8
> + anv_pack_struct(_reg, GENX(INSTPM),
> + .CONSTANT_BUFFERAddressOffsetDisable = true,
> + .CONSTANT_BUFFERAddressOffsetDisableMask = true);
> + anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(INSTPM_num);
> + lri.DataDWord = tmp_reg;
> + }
> +#endif
> + }
> +
> anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
>
> assert(batch.next <= batch.end);
> --
> 2.14.3
>
> ___
> 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 1/2] glsl: fix random typo
Just something I stumbled across.
Signed-off-by: Rob Clark
---
src/compiler/glsl/link_uniform_blocks.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/glsl/link_uniform_blocks.cpp
b/src/compiler/glsl/link_uniform_blocks.cpp
index e9e29d13a17..0ab9687b7fb 100644
--- a/src/compiler/glsl/link_uniform_blocks.cpp
+++ b/src/compiler/glsl/link_uniform_blocks.cpp
@@ -298,7 +298,7 @@ process_block_array_leaf(const char *name,
if (b->is_shader_storage &&
parcel->buffer_size > ctx->Const.MaxShaderStorageBlockSize) {
linker_error(prog, "shader storage block `%s' has size %d, "
- "which is larger than than the maximum allowed (%d)",
+ "which is larger than the maximum allowed (%d)",
b->type->name,
parcel->buffer_size,
ctx->Const.MaxShaderStorageBlockSize);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] nir: add comment for loop_unroll pass
Save the next person from digging through the code to figure out what
the indirect_mask parameter actually does.
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_opt_loop_unroll.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
b/src/compiler/nir/nir_opt_loop_unroll.c
index ff27c06cc01..04caa7c346d 100644
--- a/src/compiler/nir/nir_opt_loop_unroll.c
+++ b/src/compiler/nir/nir_opt_loop_unroll.c
@@ -578,6 +578,10 @@ nir_opt_loop_unroll_impl(nir_function_impl *impl,
return progress;
}
+/**
+ * indirect_mask specifies which type of indirectly accessed variables
+ * should force loop unrolling.
+ */
bool
nir_opt_loop_unroll(nir_shader *shader, nir_variable_mode indirect_mask)
{
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] intel/genxml: Add bitmasks for CS_DEBUG_MODE2/INSTPM.
--- src/intel/genxml/gen10.xml | 4 src/intel/genxml/gen11.xml | 4 src/intel/genxml/gen6.xml | 5 + src/intel/genxml/gen7.xml | 5 + src/intel/genxml/gen75.xml | 5 + src/intel/genxml/gen8.xml | 5 + src/intel/genxml/gen9.xml | 4 7 files changed, 32 insertions(+) diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml index 67fda868193..541e4405716 100644 --- a/src/intel/genxml/gen10.xml +++ b/src/intel/genxml/gen10.xml @@ -3631,6 +3631,10 @@ + + + + diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml index dea1cd83aec..bd3800e4b79 100644 --- a/src/intel/genxml/gen11.xml +++ b/src/intel/genxml/gen11.xml @@ -3629,6 +3629,10 @@ + + + + diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml index f258065ebae..c2967cd423d 100644 --- a/src/intel/genxml/gen6.xml +++ b/src/intel/genxml/gen6.xml @@ -1972,6 +1972,11 @@ + + + + + diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml index 895f5d232b5..6dde7973e69 100644 --- a/src/intel/genxml/gen7.xml +++ b/src/intel/genxml/gen7.xml @@ -2621,6 +2621,11 @@ + + + + + diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml index 54362bbb93c..5b01fd45400 100644 --- a/src/intel/genxml/gen75.xml +++ b/src/intel/genxml/gen75.xml @@ -3135,6 +3135,11 @@ + + + + + diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml index 24c91e2e578..4ed41d15612 100644 --- a/src/intel/genxml/gen8.xml +++ b/src/intel/genxml/gen8.xml @@ -3374,6 +3374,11 @@ + + + + + diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml index dbef0726f11..318ae89d5e7 100644 --- a/src/intel/genxml/gen9.xml +++ b/src/intel/genxml/gen9.xml @@ -3703,6 +3703,10 @@ + + + + -- 2.14.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] anv: Disable constant buffer 0 being relative.
If we are on gen8+ and have context isolation support, just make that
constant buffer address be absolute, so we can use it for push UBOs too.
---
src/intel/vulkan/anv_device.c | 5 -
src/intel/vulkan/anv_private.h | 1 +
src/intel/vulkan/genX_state.c | 27 +++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d1637f097e8..002b05f15f8 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -430,7 +430,8 @@ anv_physical_device_init(struct anv_physical_device *device,
device->compiler->shader_debug_log = compiler_debug_log;
device->compiler->shader_perf_log = compiler_perf_log;
device->compiler->supports_pull_constants = false;
- device->compiler->constant_buffer_0_is_relative = true;
+ device->compiler->constant_buffer_0_is_relative =
+ device->info.gen < 8 || !device->has_context_isolation;
isl_device_init(>isl_dev, >info, swizzled);
@@ -1519,6 +1520,8 @@ VkResult anv_CreateDevice(
device->chipset_id = physical_device->chipset_id;
device->no_hw = physical_device->no_hw;
device->lost = false;
+ device->constant_buffer_0_is_relative =
+ physical_device->compiler->constant_buffer_0_is_relative;
if (pAllocator)
device->alloc = *pAllocator;
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 6af2a0bd3f3..d7297da6f57 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -983,6 +983,7 @@ struct anv_device {
pthread_mutex_t mutex;
pthread_cond_t queue_submit;
boollost;
+boolconstant_buffer_0_is_relative;
};
static inline struct anv_state_pool *
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index c6e54046910..46e020c8134 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -169,6 +169,33 @@ genX(init_device_state)(struct anv_device *device)
gen10_emit_wa_lri_to_cache_mode_zero();
#endif
+ /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
+* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
+*
+* This is only safe on kernels with context isolation support.
+*/
+ if (GEN_GEN >= 8 &&
+ !device->constant_buffer_0_is_relative) {
+ UNUSED uint32_t tmp_reg;
+#if GEN_GEN >= 9
+ anv_pack_struct(_reg, GENX(CS_DEBUG_MODE2),
+ .CONSTANT_BUFFERAddressOffsetDisable = true,
+ .CONSTANT_BUFFERAddressOffsetDisableMask = true);
+ anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
+ lri.RegisterOffset = GENX(CS_DEBUG_MODE2_num);
+ lri.DataDWord = tmp_reg;
+ }
+#elif GEN_GEN == 8
+ anv_pack_struct(_reg, GENX(INSTPM),
+ .CONSTANT_BUFFERAddressOffsetDisable = true,
+ .CONSTANT_BUFFERAddressOffsetDisableMask = true);
+ anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
+ lri.RegisterOffset = GENX(INSTPM_num);
+ lri.DataDWord = tmp_reg;
+ }
+#endif
+ }
+
anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
assert(batch.next <= batch.end);
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] anv/device: Check for kernel support of context isolation.
---
src/intel/vulkan/anv_device.c | 3 +++
src/intel/vulkan/anv_private.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 63d5876edb1..d1637f097e8 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -377,6 +377,9 @@ anv_physical_device_init(struct anv_physical_device *device,
device->use_softpin = anv_gem_get_param(fd, I915_PARAM_HAS_EXEC_SOFTPIN)
&& device->supports_48bit_addresses;
+ device->has_context_isolation =
+ anv_gem_get_param(fd, I915_PARAM_HAS_CONTEXT_ISOLATION);
+
bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
/* Starting with Gen10, the timestamp frequency of the command streamer may
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index b035bf1c943..6af2a0bd3f3 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -856,6 +856,7 @@ struct anv_physical_device {
boolhas_syncobj_wait;
boolhas_context_priority;
booluse_softpin;
+boolhas_context_isolation;
struct anv_device_extension_table supported_extensions;
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] radv: fix bitwise check
Oops.
Reviewed-by: Samuel Pitoiset
On 06/15/2018 07:00 PM, Eric Engestrom wrote:
Fixes: 922cd38172b8a2bc286bd "radv: implement out-of-order rasterization when it's
safe on VI+"
Cc: Samuel Pitoiset
Signed-off-by: Eric Engestrom
---
src/amd/vulkan/radv_pipeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index ccbcbbadd55e672a572a..113622bb0ce1ea0f88f7 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -622,7 +622,7 @@ radv_blend_check_commutativity(struct radv_blend_state
*blend,
(1u << VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA);
if (dst == VK_BLEND_FACTOR_ONE &&
- (src_allowed && (1u << src))) {
+ (src_allowed & (1u << src))) {
/* Addition is commutative, but floating point addition isn't
* associative: subtle changes can be introduced via different
* rounding. Be conservative, only enable for min and max.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
On Fri, 2018-06-15 at 11:23 -0600, Kyle Brenneman wrote: > The Khronos repository basically is a package for the headers. The > challenge is that the pkg-config file has to specify an include path and > a library path. The include path depends on where you put the header > files (which are in the Khronos repository), but library path depends on > how you configure libglvnd. > > The libglvnd tree probably does make the most sense: That's where the > libraries are from, and so it should be the only thing you need to build > and link an OpenGL application. It also has a copy of the GL header > files that it uses to build. It could install those copies, but the > challenge then is keeping libglvnd's copy of the header files up to date. To be honest, that's something that needs better automation anyway. Epoxy and Mesa want to track the xml updates closely too. I've set up cron jobs in travis to check daily whether the xml has been changed, so I'll at least get notifications: https://travis-ci.org/nwnk/OpenGL-Registry https://travis-ci.org/nwnk/EGL-Registry It would be good to close the loop there and automate the process of importing the XML, rebuilding, checking for ABI breaks... - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/24] configure.ac: Add CFLAG -Wno-missing-field-initializers (v2)
Hi Emil, Am Freitag, den 08.06.2018, 16:28 +0100 schrieb Emil Velikov: > On 8 June 2018 at 12:02, Gert Wollny wrote: > > From: Gert Wollny > > [...] > Out of curiosity: how many warnings are we walking about - is it > something like 20-50 or it's in the 100+ region? > > There's a small comment on 24/24, with that the series is > Reviewed-by: Emil Velikov > Is your R-b also valid for the new versions of patch 24 and 1? (24 is essentially your proposal with an additional debug_printf, 1 changed a bit more for the meson stuff) many thanks, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] winsys/svga/drm: Include sys/types.h
Reviewed-by: Sinclair Yeh On Tue, Jun 12, 2018 at 03:27:04PM +0100, Ross Burton wrote: > From: Khem Raj > > vmw_screen.h uses dev_t which is defines in sys/types.h > this header is required to be included for getting dev_t > definition. This issue happens on musl C library, it is hidden > on glibc since sys/types.h is included through another > system headers > > Upstream-Status: Submitted > Signed-off-by: Khem Raj > --- > src/gallium/winsys/svga/drm/vmw_screen.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/winsys/svga/drm/vmw_screen.h > b/src/gallium/winsys/svga/drm/vmw_screen.h > index f21cabb51f..4c972fdaa9 100644 > --- a/src/gallium/winsys/svga/drm/vmw_screen.h > +++ b/src/gallium/winsys/svga/drm/vmw_screen.h > @@ -41,6 +41,7 @@ > #include "svga_winsys.h" > #include "pipebuffer/pb_buffer_fenced.h" > #include > +#include > > #define VMW_GMR_POOL_SIZE (16*1024*1024) > #define VMW_QUERY_POOL_SIZE (8192) > -- > 2.17.1 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
Quoting Kyle Brenneman (2018-06-15 11:02:37) > On 06/15/2018 11:41 AM, Dylan Baker wrote: > > Quoting Kyle Brenneman (2018-06-15 10:23:24) > >> On 06/15/2018 10:46 AM, Dylan Baker wrote: > >>> Quoting Kyle Brenneman (2018-05-30 06:18:27) > On 05/29/2018 12:04 PM, Adam Jackson wrote: > > On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > >> Quoting Adam Jackson (2018-05-29 06:50:46) > >>> GL_LIB expands to GLX_mesa, but applications should not link against > >>> that. -lGL is never wrong, just hardcode it. > >> Actually There is this really stupid option in the autotools build > >> called > >> --gl-lib-name. We should remove that. > >> > >> Emil and I had also discussed that glvnd should provide the gl.pc file > >> when used > >> instead of mesa. It appears he never got around to that, but it seems > >> like a > >> useful thing to do. > > https://github.com/NVIDIA/libglvnd/pull/86 > > > > Branch is a bit stale but better than reinventing everything. > > > > Part of the reason I didn't get much further on that is the question of > > distributing the _headers_. It would be a bit awkward if glvnd provided > > the library you link to but not the headers defining its interface - > > though, I guess no more awkward than the current situation. At any rate > > glvnd doesn't install any, and there's no way to generate > > from the Khronos scripts at the moment (it's assumed to be a platform > > implementation detail, and the version in Mesa is just handcoded > > history). > > > > - ajax > > > Yeah, the headers versus libraries question is what makes it awkward. > Libglvnd provides the libraries that an application links against, but > the header files are basically from the Khronos repository. Treating > libglvnd as the source for the libraries and the Khronos tree as the > source for the headers would seem to be the cleanest option, but the > pkg-config files would have to include the paths to both. > > Now that I think about it, though, since the Khronos registry is on > Github now instead of SVN, maybe a git submodule would work? > > -Kyle > > >>> Could we make a package for the headers separate from glvnd or mesa, with > >>> it's > >>> own pkg-config (basically just a fork with a pkg-config)? Then mesa and > >>> glvnd > >>> could rely on that package? Or maybe Khronos would be willing to accept > >>> something > >>> upstream? > >>> > >>> I don't know what the feasibility of either is, I'm just throwing out > >>> ideas. > >>> > >>> Dylan > >>> > >> The Khronos repository basically is a package for the headers. The > >> challenge is that the pkg-config file has to specify an include path and > >> a library path. The include path depends on where you put the header > >> files (which are in the Khronos repository), but library path depends on > >> how you configure libglvnd. > > But it could declare the library and then depend on another pkg-config that > > has > > the include path, right? So we could have a pkg-config for > > 'khronos-gl-headers' > > and a pkg config for 'libgl', and the libgl could declare a requires > > khronos-gl-headers. That would allow both libglvnd and mesa to avoid ever > > shipping the headers. Or would that just be too much headache? > > > > Dylan > Using two separate packages and two separate pkg-config files might > work, but it seems like it would be overly complicated for both app > developers and distro packagers. Also, we'd ideally want whatever we > come up with to be a drop-in replacement for the current pkg-config > files from Mesa. > > If we were to let libglvnd grab the headers from another package, > though, I suppose I could set up libglvnd to install the GL headers, and > then add a configure option to libglvnd to point it at a copy of the > Khronos repository. At that point, though, you might as well just build > and install libglvnd normally and manually overwrite the GL headers -- > the new option doesn't add much. > > -Kyle > My thought was either mesa and glvnd would agree that neither would ship headers and both would rely on the new package. But it sounds like that would be too much headache. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
On 06/15/2018 11:41 AM, Dylan Baker wrote: Quoting Kyle Brenneman (2018-06-15 10:23:24) On 06/15/2018 10:46 AM, Dylan Baker wrote: Quoting Kyle Brenneman (2018-05-30 06:18:27) On 05/29/2018 12:04 PM, Adam Jackson wrote: On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: Quoting Adam Jackson (2018-05-29 06:50:46) GL_LIB expands to GLX_mesa, but applications should not link against that. -lGL is never wrong, just hardcode it. Actually There is this really stupid option in the autotools build called --gl-lib-name. We should remove that. Emil and I had also discussed that glvnd should provide the gl.pc file when used instead of mesa. It appears he never got around to that, but it seems like a useful thing to do. https://github.com/NVIDIA/libglvnd/pull/86 Branch is a bit stale but better than reinventing everything. Part of the reason I didn't get much further on that is the question of distributing the _headers_. It would be a bit awkward if glvnd provided the library you link to but not the headers defining its interface - though, I guess no more awkward than the current situation. At any rate glvnd doesn't install any, and there's no way to generate from the Khronos scripts at the moment (it's assumed to be a platform implementation detail, and the version in Mesa is just handcoded history). - ajax Yeah, the headers versus libraries question is what makes it awkward. Libglvnd provides the libraries that an application links against, but the header files are basically from the Khronos repository. Treating libglvnd as the source for the libraries and the Khronos tree as the source for the headers would seem to be the cleanest option, but the pkg-config files would have to include the paths to both. Now that I think about it, though, since the Khronos registry is on Github now instead of SVN, maybe a git submodule would work? -Kyle Could we make a package for the headers separate from glvnd or mesa, with it's own pkg-config (basically just a fork with a pkg-config)? Then mesa and glvnd could rely on that package? Or maybe Khronos would be willing to accept something upstream? I don't know what the feasibility of either is, I'm just throwing out ideas. Dylan The Khronos repository basically is a package for the headers. The challenge is that the pkg-config file has to specify an include path and a library path. The include path depends on where you put the header files (which are in the Khronos repository), but library path depends on how you configure libglvnd. But it could declare the library and then depend on another pkg-config that has the include path, right? So we could have a pkg-config for 'khronos-gl-headers' and a pkg config for 'libgl', and the libgl could declare a requires khronos-gl-headers. That would allow both libglvnd and mesa to avoid ever shipping the headers. Or would that just be too much headache? Dylan Using two separate packages and two separate pkg-config files might work, but it seems like it would be overly complicated for both app developers and distro packagers. Also, we'd ideally want whatever we come up with to be a drop-in replacement for the current pkg-config files from Mesa. If we were to let libglvnd grab the headers from another package, though, I suppose I could set up libglvnd to install the GL headers, and then add a configure option to libglvnd to point it at a copy of the Khronos repository. At that point, though, you might as well just build and install libglvnd normally and manually overwrite the GL headers -- the new option doesn't add much. -Kyle ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] meson: add GL/glext.h warning fix for MacOS
Sent from my iPhone...
> On Jun 15, 2018, at 09:35, Eric Engestrom wrote:
>
>> On Friday, 2018-06-15 08:14:40 -0700, Jeremy Huddleston Sequoia wrote:
>> I think we can instead revert c7f3657450683827446072ad6b1e8fce04078162.
>
> If you think the issue is resolved, then please feel free to send that
> revert :)
Thanks. I’ll give it a try next week and get back to ya.
> Is there a way for someone without a Mac to test this?
I suppose you could change the __APPLE__ check to APPLE_GLHANDLEARB and have
that toggled by a configure check (with appropriate defaults for the platforms.
However, I would have concerns over such a change because that would make it
very easy for someone to go the wrong way in a production environment, and we
would be even worse off than we are now.
However just changing the GLhandleARB typeset locally to void * in an isolated
test environment should be enough to reproduce and test locally.
>> I believe the underlying issue should instead be addressed by
>> a087a09fa86f9617af98f6294dd2228555a4891c. If any issues remain, we
>> should address them properly rather than masking them with this.
>>
>> A quick audit makes me suspect we'll get some (benign) 32-64 pointer
>> conversion warnings in some cases which can be addressed like this:
>>
>> void GLAPIENTRY
>> _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
>> GLsizei * count, GLhandleARB * obj)
>> {
>>GET_CURRENT_CONTEXT(ctx);
>> - get_attached_shaders(ctx, (GLuint)container, maxCount, count, NULL, obj);
>> + get_attached_shaders(ctx, (GLuint)(uintptr_t)container, maxCount, count,
>> NULL, obj);
>> }
>>
>> I think that is preferable to masking the problem. If you prefer,
>> I can do a pass to fixup the casting followed by a revert of
>> c7f3657450683827446072ad6b1e8fce04078162 separate from your series.
>>
>> Thanks,
>> Jeremy
>>
>>> On Jun 15, 2018, at 6:41 AM, Jon Turney wrote:
>>>
>>> On 12/06/2018 16:53, Dylan Baker wrote:
Quoting Eric Engestrom (2018-06-12 04:25:10)
> Copied from configure.ac:1950
>
> Signed-off-by: Eric Engestrom
> ---
> Is it still needed? We've been building on MacOS for a while,
> yet nobody noticed anything (Dylan?)
> If not, we should probably avoid unnecessary differences with Khronos'
> headers and nuke BUILDING_MESA.
> ---
> meson.build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meson.build b/meson.build
> index c5acc8a3587ea20e131e..04b3bdfd77f36670ff7f 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -209,6 +209,7 @@ endif
> if host_machine.system() == 'darwin'
> with_dri_platform = 'apple'
> + pre_args += '-DBUILDING_MESA'
> elif ['windows', 'cygwin'].contains(host_machine.system())
> with_dri_platform = 'windows'
> elif system_has_kms_drm
> --
> Cheers,
> Eric
>
I didn't notice, but I also didn't do a whole lot of testing
I've added Jon who did most of the meson mac work and Jeremy who's the
resident
mac expert.
>>> No expert, but I believe this is unfortunately still needed.
>>>
>>> See commit c7f36574 and the referenced BZ.
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
Quoting Kyle Brenneman (2018-06-15 10:23:24) > On 06/15/2018 10:46 AM, Dylan Baker wrote: > > Quoting Kyle Brenneman (2018-05-30 06:18:27) > >> On 05/29/2018 12:04 PM, Adam Jackson wrote: > >>> On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > Quoting Adam Jackson (2018-05-29 06:50:46) > > GL_LIB expands to GLX_mesa, but applications should not link against > > that. -lGL is never wrong, just hardcode it. > Actually There is this really stupid option in the autotools build > called > --gl-lib-name. We should remove that. > > Emil and I had also discussed that glvnd should provide the gl.pc file > when used > instead of mesa. It appears he never got around to that, but it seems > like a > useful thing to do. > >>> https://github.com/NVIDIA/libglvnd/pull/86 > >>> > >>> Branch is a bit stale but better than reinventing everything. > >>> > >>> Part of the reason I didn't get much further on that is the question of > >>> distributing the _headers_. It would be a bit awkward if glvnd provided > >>> the library you link to but not the headers defining its interface - > >>> though, I guess no more awkward than the current situation. At any rate > >>> glvnd doesn't install any, and there's no way to generate > >>> from the Khronos scripts at the moment (it's assumed to be a platform > >>> implementation detail, and the version in Mesa is just handcoded > >>> history). > >>> > >>> - ajax > >>> > >> Yeah, the headers versus libraries question is what makes it awkward. > >> Libglvnd provides the libraries that an application links against, but > >> the header files are basically from the Khronos repository. Treating > >> libglvnd as the source for the libraries and the Khronos tree as the > >> source for the headers would seem to be the cleanest option, but the > >> pkg-config files would have to include the paths to both. > >> > >> Now that I think about it, though, since the Khronos registry is on > >> Github now instead of SVN, maybe a git submodule would work? > >> > >> -Kyle > >> > > Could we make a package for the headers separate from glvnd or mesa, with > > it's > > own pkg-config (basically just a fork with a pkg-config)? Then mesa and > > glvnd > > could rely on that package? Or maybe Khronos would be willing to accept > > something > > upstream? > > > > I don't know what the feasibility of either is, I'm just throwing out ideas. > > > > Dylan > > > The Khronos repository basically is a package for the headers. The > challenge is that the pkg-config file has to specify an include path and > a library path. The include path depends on where you put the header > files (which are in the Khronos repository), but library path depends on > how you configure libglvnd. But it could declare the library and then depend on another pkg-config that has the include path, right? So we could have a pkg-config for 'khronos-gl-headers' and a pkg config for 'libgl', and the libgl could declare a requires khronos-gl-headers. That would allow both libglvnd and mesa to avoid ever shipping the headers. Or would that just be too much headache? Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
On 06/15/2018 10:46 AM, Dylan Baker wrote: Quoting Kyle Brenneman (2018-05-30 06:18:27) On 05/29/2018 12:04 PM, Adam Jackson wrote: On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: Quoting Adam Jackson (2018-05-29 06:50:46) GL_LIB expands to GLX_mesa, but applications should not link against that. -lGL is never wrong, just hardcode it. Actually There is this really stupid option in the autotools build called --gl-lib-name. We should remove that. Emil and I had also discussed that glvnd should provide the gl.pc file when used instead of mesa. It appears he never got around to that, but it seems like a useful thing to do. https://github.com/NVIDIA/libglvnd/pull/86 Branch is a bit stale but better than reinventing everything. Part of the reason I didn't get much further on that is the question of distributing the _headers_. It would be a bit awkward if glvnd provided the library you link to but not the headers defining its interface - though, I guess no more awkward than the current situation. At any rate glvnd doesn't install any, and there's no way to generate from the Khronos scripts at the moment (it's assumed to be a platform implementation detail, and the version in Mesa is just handcoded history). - ajax Yeah, the headers versus libraries question is what makes it awkward. Libglvnd provides the libraries that an application links against, but the header files are basically from the Khronos repository. Treating libglvnd as the source for the libraries and the Khronos tree as the source for the headers would seem to be the cleanest option, but the pkg-config files would have to include the paths to both. Now that I think about it, though, since the Khronos registry is on Github now instead of SVN, maybe a git submodule would work? -Kyle Could we make a package for the headers separate from glvnd or mesa, with it's own pkg-config (basically just a fork with a pkg-config)? Then mesa and glvnd could rely on that package? Or maybe Khronos would be willing to accept something upstream? I don't know what the feasibility of either is, I'm just throwing out ideas. Dylan The Khronos repository basically is a package for the headers. The challenge is that the pkg-config file has to specify an include path and a library path. The include path depends on where you put the header files (which are in the Khronos repository), but library path depends on how you configure libglvnd. The libglvnd tree probably does make the most sense: That's where the libraries are from, and so it should be the only thing you need to build and link an OpenGL application. It also has a copy of the GL header files that it uses to build. It could install those copies, but the challenge then is keeping libglvnd's copy of the header files up to date. -Kyle ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 41/48] meson: Fix gtest linkage on msvc
Quoting Jon Turney (2018-06-15 09:51:31) > On 11/06/2018 23:56, Dylan Baker wrote: > > We need to add an extra flag (/SUBSYSTEM:CONSOLE) to get the msvc linker > > to find main() in a static library. > > --- > > src/gtest/meson.build | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/src/gtest/meson.build b/src/gtest/meson.build > > index 91a49240416..ed0d6974bd3 100644 > > --- a/src/gtest/meson.build > > +++ b/src/gtest/meson.build > > @@ -25,7 +25,14 @@ libgtest = static_library( > > build_by_default : false, > > ) > > > > +_gtest_link_args = [] > > +if cpp.get_id() == 'msvc' > > + # required to use main() from a static library > > + _gtest_link_args += '/SUBSYSTEM:CONSOLE' > > +endif > > I think this is perhaps working around a meson bug > > (This linker setting should be implied by executable(gui_app:false), but > I don't think that is the case for msvc with ninja backend. See > https://github.com/mesonbuild/meson/pull/1794) > > The rest of the series looks ok to me, but it's not stuff I actually use. I didn't even think about that it might be a ninja backend bug, I tried using the gui_false and it didn't change anything. I think I'll go see if it works correctly with the VS backend, if that's the case then I'll fix that I guess. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa] radv: fix bitwise check
Fixes: 922cd38172b8a2bc286bd "radv: implement out-of-order rasterization when
it's safe on VI+"
Cc: Samuel Pitoiset
Signed-off-by: Eric Engestrom
---
src/amd/vulkan/radv_pipeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index ccbcbbadd55e672a572a..113622bb0ce1ea0f88f7 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -622,7 +622,7 @@ radv_blend_check_commutativity(struct radv_blend_state
*blend,
(1u << VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA);
if (dst == VK_BLEND_FACTOR_ONE &&
- (src_allowed && (1u << src))) {
+ (src_allowed & (1u << src))) {
/* Addition is commutative, but floating point addition isn't
* associative: subtle changes can be introduced via different
* rounding. Be conservative, only enable for min and max.
--
Cheers,
Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa] radv: fix reported number of available VGPRs
It's a bit late to round up after an integer division. Fixes: de889794134e6245e08a2 "radv: Implement VK_AMD_shader_info" Cc: Alex Smith Signed-off-by: Eric Engestrom --- src/amd/vulkan/radv_shader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c index 76790a19047a86abdad5..b31eb9bfda5e9e29e115 100644 --- a/src/amd/vulkan/radv_shader.c +++ b/src/amd/vulkan/radv_shader.c @@ -808,7 +808,7 @@ radv_GetShaderInfoAMD(VkDevice _device, unsigned workgroup_size = local_size[0] * local_size[1] * local_size[2]; statistics.numAvailableVgprs = statistics.numPhysicalVgprs / - ceil(workgroup_size / statistics.numPhysicalVgprs); + ceil((double)workgroup_size / statistics.numPhysicalVgprs); statistics.computeWorkGroupSize[0] = local_size[0]; statistics.computeWorkGroupSize[1] = local_size[1]; -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 41/48] meson: Fix gtest linkage on msvc
On 11/06/2018 23:56, Dylan Baker wrote: We need to add an extra flag (/SUBSYSTEM:CONSOLE) to get the msvc linker to find main() in a static library. --- src/gtest/meson.build | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/gtest/meson.build b/src/gtest/meson.build index 91a49240416..ed0d6974bd3 100644 --- a/src/gtest/meson.build +++ b/src/gtest/meson.build @@ -25,7 +25,14 @@ libgtest = static_library( build_by_default : false, ) +_gtest_link_args = [] +if cpp.get_id() == 'msvc' + # required to use main() from a static library + _gtest_link_args += '/SUBSYSTEM:CONSOLE' +endif I think this is perhaps working around a meson bug (This linker setting should be implied by executable(gui_app:false), but I don't think that is the case for msvc with ninja backend. See https://github.com/mesonbuild/meson/pull/1794) The rest of the series looks ok to me, but it's not stuff I actually use. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote: > I don't even understand why we make these announcements TBH. I have a public > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that > branch > *anytime* to get the latest version. The only thing the announce email really > serves AFAICT, is to say "the staging/proposed branch has been merged to the > release branch". I don't think that's all that interesting TBH. "any time" means "no time". The announcement is "speak now or forever hold your peace". Gives driver teams a chance to review the list and test things out before they go out into a full release. Should they be doing this daily/continuously? Probably. But that's not the current state. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
Quoting Kyle Brenneman (2018-05-30 06:18:27) > On 05/29/2018 12:04 PM, Adam Jackson wrote: > > On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > >> Quoting Adam Jackson (2018-05-29 06:50:46) > >>> GL_LIB expands to GLX_mesa, but applications should not link against > >>> that. -lGL is never wrong, just hardcode it. > >> Actually There is this really stupid option in the autotools build > >> called > >> --gl-lib-name. We should remove that. > >> > >> Emil and I had also discussed that glvnd should provide the gl.pc file > >> when used > >> instead of mesa. It appears he never got around to that, but it seems like > >> a > >> useful thing to do. > > https://github.com/NVIDIA/libglvnd/pull/86 > > > > Branch is a bit stale but better than reinventing everything. > > > > Part of the reason I didn't get much further on that is the question of > > distributing the _headers_. It would be a bit awkward if glvnd provided > > the library you link to but not the headers defining its interface - > > though, I guess no more awkward than the current situation. At any rate > > glvnd doesn't install any, and there's no way to generate > > from the Khronos scripts at the moment (it's assumed to be a platform > > implementation detail, and the version in Mesa is just handcoded > > history). > > > > - ajax > > > Yeah, the headers versus libraries question is what makes it awkward. > Libglvnd provides the libraries that an application links against, but > the header files are basically from the Khronos repository. Treating > libglvnd as the source for the libraries and the Khronos tree as the > source for the headers would seem to be the cleanest option, but the > pkg-config files would have to include the paths to both. > > Now that I think about it, though, since the Khronos registry is on > Github now instead of SVN, maybe a git submodule would work? > > -Kyle > Could we make a package for the headers separate from glvnd or mesa, with it's own pkg-config (basically just a fork with a pkg-config)? Then mesa and glvnd could rely on that package? Or maybe Khronos would be willing to accept something upstream? I don't know what the feasibility of either is, I'm just throwing out ideas. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] meson: fix i965/anv/isl genX static lib names
Reviewed-by: Dylan Baker Quoting Eric Engestrom (2018-06-15 04:15:31) > Shouldn't make any functional difference, just that `liblibanv_gen90.a` > will now be called `libanv_gen90.a`. > > Fixes: 3218056e0eb375eeda470 "meson: Build i965 and dri stack" > Fixes: d1992255bb29054fa5176 "meson: Add build Intel "anv" vulkan driver" > Signed-off-by: Eric Engestrom > --- > src/intel/isl/meson.build | 2 +- > src/intel/vulkan/meson.build | 2 +- > src/mesa/drivers/dri/i965/meson.build | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build > index c70c5c05fcd1adb4c63b..5b57188d30c001172ab1 100644 > --- a/src/intel/isl/meson.build > +++ b/src/intel/isl/meson.build > @@ -54,7 +54,7 @@ foreach g : [['40', isl_gen4_files], ['50', []], ['60', > isl_gen6_files], > ['90', isl_gen9_files], ['100', []], ['110', []]] >_gen = g[0] >isl_gen_libs += static_library( > -'libisl_gen@0@'.format(_gen), > +'isl_gen@0@'.format(_gen), > [g[1], isl_gen_files, gen_xml_pack], > include_directories : [inc_common, inc_intel], > c_args : [c_vis_args, no_override_init_args, > diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build > index f20a8a54c9bbdfb43dd3..159ad092314bcef6ec7c 100644 > --- a/src/intel/vulkan/meson.build > +++ b/src/intel/vulkan/meson.build > @@ -95,7 +95,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', > ['gen7_cmd_buffer.c']], > ['100', ['gen8_cmd_buffer.c']], ['110', ['gen8_cmd_buffer.c']]] >_gen = g[0] >libanv_gen_libs += static_library( > -'libanv_gen@0@'.format(_gen), > +'anv_gen@0@'.format(_gen), > [anv_gen_files, g[1], anv_entrypoints[0], anv_extensions_h], > include_directories : [ >inc_common, inc_compiler, inc_drm_uapi, inc_intel, inc_vulkan_util, > diff --git a/src/mesa/drivers/dri/i965/meson.build > b/src/mesa/drivers/dri/i965/meson.build > index 20404d5b059736b9bc8c..761bb51d6faa696798cc 100644 > --- a/src/mesa/drivers/dri/i965/meson.build > +++ b/src/mesa/drivers/dri/i965/meson.build > @@ -138,7 +138,7 @@ files_i965 = files( > i965_gen_libs = [] > foreach v : ['40', '45', '50', '60', '70', '75', '80', '90', '100', '110'] >i965_gen_libs += static_library( > -'libi965_gen@0@'.format(v), > +'i965_gen@0@'.format(v), > ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack], > include_directories : [inc_common, inc_intel, inc_dri_common], > c_args : [ > -- > Cheers, > Eric > signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Juan A. Suarez Romero (2018-06-15 07:26:18) > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > > Hello list, > > > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > > > > - 42 queued > > > > - 6 nominated (outstanding) > > > > - and 0 rejected patches > > > > > > > > Notable changes in this release: > > > > - numerous fixes for radv > > > > - libatomic checks for meson, as well as fixing coverage for less > > > > common (not > > > > arm or x86) platforms > > > > - lots of common Intel fixes > > > > - GLX fixes > > > > - tarball fixes for android > > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > > > > Testing reports/general approval > > > > > > > > Any testing reports (or general approval of the state of the branch) > > > > will be > > > > greatly appreciated. > > > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly > > > > after 10 > > > > AM PDT. > > > > > > June 15th? > > > > Yes, June 15th. > > > > Apparently being woken up at 5AM does more brain damage than I thought. > > Also, we usually wait 48h (two days) between the pre-announcement and the > final > release, to give more time for testing. > > > J.A. > I don't even understand why we make these announcements TBH. I have a public 18.1-proposed branch that I push to *every weekday*. Anyone can pull that branch *anytime* to get the latest version. The only thing the announce email really serves AFAICT, is to say "the staging/proposed branch has been merged to the release branch". I don't think that's all that interesting TBH. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] meson: add GL/glext.h warning fix for MacOS
On Friday, 2018-06-15 08:14:40 -0700, Jeremy Huddleston Sequoia wrote:
> I think we can instead revert c7f3657450683827446072ad6b1e8fce04078162.
If you think the issue is resolved, then please feel free to send that
revert :)
Is there a way for someone without a Mac to test this?
> I believe the underlying issue should instead be addressed by
> a087a09fa86f9617af98f6294dd2228555a4891c. If any issues remain, we
> should address them properly rather than masking them with this.
>
> A quick audit makes me suspect we'll get some (benign) 32-64 pointer
> conversion warnings in some cases which can be addressed like this:
>
> void GLAPIENTRY
> _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
> GLsizei * count, GLhandleARB * obj)
> {
> GET_CURRENT_CONTEXT(ctx);
> - get_attached_shaders(ctx, (GLuint)container, maxCount, count, NULL, obj);
> + get_attached_shaders(ctx, (GLuint)(uintptr_t)container, maxCount, count,
> NULL, obj);
> }
>
> I think that is preferable to masking the problem. If you prefer,
> I can do a pass to fixup the casting followed by a revert of
> c7f3657450683827446072ad6b1e8fce04078162 separate from your series.
>
> Thanks,
> Jeremy
>
> > On Jun 15, 2018, at 6:41 AM, Jon Turney wrote:
> >
> > On 12/06/2018 16:53, Dylan Baker wrote:
> >> Quoting Eric Engestrom (2018-06-12 04:25:10)
> >>> Copied from configure.ac:1950
> >>>
> >>> Signed-off-by: Eric Engestrom
> >>> ---
> >>> Is it still needed? We've been building on MacOS for a while,
> >>> yet nobody noticed anything (Dylan?)
> >>> If not, we should probably avoid unnecessary differences with Khronos'
> >>> headers and nuke BUILDING_MESA.
> >>> ---
> >>> meson.build | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/meson.build b/meson.build
> >>> index c5acc8a3587ea20e131e..04b3bdfd77f36670ff7f 100644
> >>> --- a/meson.build
> >>> +++ b/meson.build
> >>> @@ -209,6 +209,7 @@ endif
> >>>if host_machine.system() == 'darwin'
> >>>with_dri_platform = 'apple'
> >>> + pre_args += '-DBUILDING_MESA'
> >>> elif ['windows', 'cygwin'].contains(host_machine.system())
> >>>with_dri_platform = 'windows'
> >>> elif system_has_kms_drm
> >>> --
> >>> Cheers,
> >>> Eric
> >>>
> >> I didn't notice, but I also didn't do a whole lot of testing
> >> I've added Jon who did most of the meson mac work and Jeremy who's the
> >> resident
> >> mac expert.
> > No expert, but I believe this is unfortunately still needed.
> >
> > See commit c7f36574 and the referenced BZ.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #7933 failed
Build mesa 7933 failed Commit 9e1f208795 by Rafael Antognolli on 6/12/2018 7:18 PM: intel/aubinator: Use int to store getopt_long flags.\n\ngetopt_long flag parameter is an int pointer, so if we use bool to store\nthose values, when getopt_long writes to one of them, it might end up\noverwriting the next one.\n\nReviewed-by: Ian Romanick Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] i965: Don't recycle BOs until they are idle
On Fri, Jun 15, 2018 at 8:31 AM, Michel Dänzer wrote: > On 2018-06-15 05:25 PM, Jason Ekstrand wrote: > > On June 15, 2018 01:14:24 Michel Dänzer wrote: > >> On 2018-06-15 07:31 AM, Jason Ekstrand wrote: > >>> > >>> I did some testing and x11perf -copywinwin500 is... exactly the same > >>> with > >>> or without my patches. If anything they might improve it by just a > >>> hair. > >> > >> Possible explanations I can think of: > >> > >> 1. Your glamor still has its own FBO cache. Which version of xserver are > >> you testing with? > >> > > 1.19 I think > > Okay, that doesn't have the glamor FBO cache anymore. > > > >> 2. The i965 driver cache isn't hit even before these changes. > > > > It's definitely getting hit in both cases, it just may require a > > slightly larger cache of we aren't recycling BOs until they're idle. > > It might be more than just slightly, -copywinwin500 can queue many > overlapping copies between flushes. Can you compare the maximum total > cache size with and without this series? > That should be possible. I'll see what I can do. It's always a bit annoying getting stuff out of X because printf gets weird but I should be able to come up with something. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On 15 June 2018 at 15:26, Juan A. Suarez Romero wrote: > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: >> Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) >> > On Thu, Jun 14, 2018 at 6:13 PM, wrote: >> > > Hello list, >> > > >> > > The candidate for the Mesa 18.1.2 is now available. Currently we have: >> > > - 42 queued >> > > - 6 nominated (outstanding) >> > > - and 0 rejected patches >> > > >> > > Notable changes in this release: >> > > - numerous fixes for radv >> > > - libatomic checks for meson, as well as fixing coverage for less common >> > > (not >> > > arm or x86) platforms >> > > - lots of common Intel fixes >> > > - GLX fixes >> > > - tarball fixes for android >> > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile >> > > >> > > Take a look at section "Mesa stable queue" for more information. >> > > >> > > >> > > Testing reports/general approval >> > > >> > > Any testing reports (or general approval of the state of the branch) >> > > will be >> > > greatly appreciated. >> > > >> > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly >> > > after 10 >> > > AM PDT. >> > >> > June 15th? >> >> Yes, June 15th. >> >> Apparently being woken up at 5AM does more brain damage than I thought. > > Also, we usually wait 48h (two days) between the pre-announcement and the > final > release, to give more time for testing. > Agreed. Sadly some people don't have the automation the Intel team does, so things may take some time. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] i965: Don't recycle BOs until they are idle
On 2018-06-15 05:25 PM, Jason Ekstrand wrote: > On June 15, 2018 01:14:24 Michel Dänzer wrote: >> On 2018-06-15 07:31 AM, Jason Ekstrand wrote: >>> >>> I did some testing and x11perf -copywinwin500 is... exactly the same >>> with >>> or without my patches. If anything they might improve it by just a >>> hair. >> >> Possible explanations I can think of: >> >> 1. Your glamor still has its own FBO cache. Which version of xserver are >> you testing with? >> > 1.19 I think Okay, that doesn't have the glamor FBO cache anymore. >> 2. The i965 driver cache isn't hit even before these changes. > > It's definitely getting hit in both cases, it just may require a > slightly larger cache of we aren't recycling BOs until they're idle. It might be more than just slightly, -copywinwin500 can queue many overlapping copies between flushes. Can you compare the maximum total cache size with and without this series? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] meson: add GL/glext.h warning fix for MacOS
I think we can instead revert c7f3657450683827446072ad6b1e8fce04078162. I
believe the underlying issue should instead be addressed by
a087a09fa86f9617af98f6294dd2228555a4891c. If any issues remain, we should
address them properly rather than masking them with this.
A quick audit makes me suspect we'll get some (benign) 32-64 pointer conversion
warnings in some cases which can be addressed like this:
void GLAPIENTRY
_mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
GLsizei * count, GLhandleARB * obj)
{
GET_CURRENT_CONTEXT(ctx);
- get_attached_shaders(ctx, (GLuint)container, maxCount, count, NULL, obj);
+ get_attached_shaders(ctx, (GLuint)(uintptr_t)container, maxCount, count,
NULL, obj);
}
I think that is preferable to masking the problem. If you prefer, I can do a
pass to fixup the casting followed by a revert of
c7f3657450683827446072ad6b1e8fce04078162 separate from your series.
Thanks,
Jeremy
> On Jun 15, 2018, at 6:41 AM, Jon Turney wrote:
>
> On 12/06/2018 16:53, Dylan Baker wrote:
>> Quoting Eric Engestrom (2018-06-12 04:25:10)
>>> Copied from configure.ac:1950
>>>
>>> Signed-off-by: Eric Engestrom
>>> ---
>>> Is it still needed? We've been building on MacOS for a while,
>>> yet nobody noticed anything (Dylan?)
>>> If not, we should probably avoid unnecessary differences with Khronos'
>>> headers and nuke BUILDING_MESA.
>>> ---
>>> meson.build | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/meson.build b/meson.build
>>> index c5acc8a3587ea20e131e..04b3bdfd77f36670ff7f 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -209,6 +209,7 @@ endif
>>>if host_machine.system() == 'darwin'
>>>with_dri_platform = 'apple'
>>> + pre_args += '-DBUILDING_MESA'
>>> elif ['windows', 'cygwin'].contains(host_machine.system())
>>>with_dri_platform = 'windows'
>>> elif system_has_kms_drm
>>> --
>>> Cheers,
>>> Eric
>>>
>> I didn't notice, but I also didn't do a whole lot of testing
>> I've added Jon who did most of the meson mac work and Jeremy who's the
>> resident
>> mac expert.
> No expert, but I believe this is unfortunately still needed.
>
> See commit c7f36574 and the referenced BZ.
___
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 12 June 2018 at 01:21, Laura Ekstrand wrote: > It's done already, it was a one-liner: > https://gitlab.freedesktop.org/ldeks/mesa/commits/website1_75_v2 > Thanks for the great work Laura and thanks to Jean for the initial poke in this direction. I'm a huge fan of the script and separate steps - beatify, rename, convert to markdown. In a few places pandadoc did produce some strange markdown, but meh. They are fairly hard to find and nitpicky, so it's something that we can address at later stage. The series in the above branch is Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: increase command size buffer a bit for constant buffers.
On Thu, Jun 14, 2018 at 11:13 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> If we want to upload 16k 32-bit consts we need a bit of overhead
> to faciliate that.
>
> Fixes crash in:
> KHR-GL44.geometry_shader.limits.max_uniform_components
> ---
> src/gallium/drivers/virgl/virgl_winsys.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> b/src/gallium/drivers/virgl/virgl_winsys.h
> index cf67b827e82..f1fa823bf6d 100644
> --- a/src/gallium/drivers/virgl/virgl_winsys.h
> +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> @@ -31,7 +31,7 @@ struct pipe_fence_handle;
> struct winsys_handle;
> struct virgl_hw_res;
>
> -#define VIRGL_MAX_CMDBUF_DWORDS (16*1024)
> +#define VIRGL_MAX_CMDBUF_DWORDS (16*1025)
Maybe add a comment here? This seems like the kind of thing someone
will try and "fix" at some point.
Alex
>
> struct virgl_drm_caps {
> union virgl_caps caps;
> --
> 2.14.3
>
> ___
> 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 0/8] i965: Don't recycle BOs until they are idle
On June 15, 2018 01:14:24 Michel Dänzer wrote: On 2018-06-15 07:31 AM, Jason Ekstrand wrote: On Thu, Jun 14, 2018 at 10:55 AM, Jason Ekstrand wrote: On June 14, 2018 01:43:12 Michel Dänzer wrote: On 2018-06-13 10:26 PM, Jason Ekstrand wrote: The current BO cache puts BOs back into the recycle bucket the moment the refcount hits zero. If the BO is busy, we just don't re-use it until it isn't or we re-use it for a render target which we assume will be used first for drawing. This patch series reworks the way the BO cache works a bit so that we don't ever recycle a busy BO. On the down side, it means that we don't get the "keep busy BOs busy" heuristic (which we have no proof actually helps). On the up side, we can now easily use a MRU heuristic instead of round-robin for all buffers and not just the busy ones. Will this be an improvement, a regression or a wash? I don't know but I doubt it will have a major effect one way or another. FWIW, I suspect this could be a significant loss with overlapping copies in glamor (e.g. x11perf -copywinwin500), because it won't be able to reuse the busy BOs anymore (glamor creates a temporary FBO for each overlapping copy). That's rather horrific... That seems like something glamour could do better. As of xserver 1.20, glamor can use GL_MESA_tile_raster_order if available. How common are overlapping copies in practice? Are we talking a couple per frame or hundreds? X doesn't have a "frame" concept per se, but overlapping copies can be quite common e.g. when scrolling, or moving windows without a compositor. 1.19 I think I did some testing and x11perf -copywinwin500 is... exactly the same with or without my patches. If anything they might improve it by just a hair. Possible explanations I can think of: 1. Your glamor still has its own FBO cache. Which version of xserver are you testing with? 2. The i965 driver cache isn't hit even before these changes. It's definitely getting hit in both cases, it just may require a slightly larger cache of we aren't recycling BOs until they're idle. 3. Allocating BOs from the kernel is significantly cheaper with i915 vs amdgpu. (4. Your GPU is too slow for it to matter. What kind of numbers are you getting?) That's entirely possible. FWIW, on a Radeon R9 285 I get 36 trep @ 0.0257 msec ( 38900.0/sec): Copy 500x500 from window to window with glamor's FBO cache and 24 trep @ 0.0700 msec ( 14300.0/sec): Copy 500x500 from window to window without (radeonsi's cache doesn't reclaim BOs either until they are idle), i.e. almost a factor of 3. I was getting about 6200 on the laptop I was testing with. That's about 1/5 of the speed you're seeing so maybe it just isn't mattering. Still, if that's the kind of drop you're seeing them maybe we should reconsider. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #7932 completed
Build mesa 7932 completed Commit f8e2c4c57c by Samuel Pitoiset on 6/15/2018 2:50 PM: Revert "radv: always set/load both depth and stencil clear values"\n\nThis fixes a rendering regression with RoTR.\n\nThis reverts commit 4bdad9faddc82a4560603936ce5ade5707ecb254.\n\nSigned-off-by: Samuel Pitoiset \nReviewed-by: Bas Nieuwenhuizen Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert "radv: always set/load both depth and stencil clear values"
Reviewed-by: Bas Nieuwenhuizen
On Fri, Jun 15, 2018 at 4:50 PM, Samuel Pitoiset
wrote:
> This fixes a rendering regression with RoTR.
>
> This reverts commit 4bdad9faddc82a4560603936ce5ade5707ecb254.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 33 +++-
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 56dbb759cb..a07717c719 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -1225,19 +1225,31 @@ radv_set_ds_clear_metadata(struct radv_cmd_buffer
> *cmd_buffer,
> {
> struct radeon_winsys_cs *cs = cmd_buffer->cs;
> uint64_t va = radv_buffer_get_va(image->bo);
> + unsigned reg_offset = 0, reg_count = 0;
>
> va += image->offset + image->clear_value_offset;
>
> assert(radv_image_has_htile(image));
>
> - radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 4, 0));
> + if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
> + ++reg_count;
> + } else {
> + ++reg_offset;
> + va += 4;
> + }
> + if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
> + ++reg_count;
> +
> + radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 2 + reg_count, 0));
> radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
> S_370_WR_CONFIRM(1) |
> S_370_ENGINE_SEL(V_370_PFP));
> radeon_emit(cs, va);
> radeon_emit(cs, va >> 32);
> - radeon_emit(cs, ds_clear_value.stencil);
> - radeon_emit(cs, fui(ds_clear_value.depth));
> + if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT)
> + radeon_emit(cs, ds_clear_value.stencil);
> + if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
> + radeon_emit(cs, fui(ds_clear_value.depth));
>
> radv_update_bound_fast_clear_ds(cmd_buffer, image, ds_clear_value,
> aspects);
> @@ -1251,20 +1263,31 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer
> *cmd_buffer,
> struct radv_image *image)
> {
> struct radeon_winsys_cs *cs = cmd_buffer->cs;
> + VkImageAspectFlags aspects = vk_format_aspects(image->vk_format);
> uint64_t va = radv_buffer_get_va(image->bo);
> + unsigned reg_offset = 0, reg_count = 0;
>
> va += image->offset + image->clear_value_offset;
>
> if (!radv_image_has_htile(image))
> return;
>
> + if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
> + ++reg_count;
> + } else {
> + ++reg_offset;
> + va += 4;
> + }
> + if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
> + ++reg_count;
> +
> radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
> radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_MEM) |
> COPY_DATA_DST_SEL(COPY_DATA_REG) |
> - COPY_DATA_COUNT_SEL);
> + (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
> radeon_emit(cs, va);
> radeon_emit(cs, va >> 32);
> - radeon_emit(cs, R_028028_DB_STENCIL_CLEAR >> 2);
> + radeon_emit(cs, (R_028028_DB_STENCIL_CLEAR + 4 * reg_offset) >> 2);
> radeon_emit(cs, 0);
>
> radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
> --
> 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] Revert "radv: always set/load both depth and stencil clear values"
This fixes a rendering regression with RoTR.
This reverts commit 4bdad9faddc82a4560603936ce5ade5707ecb254.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 33 +++-
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 56dbb759cb..a07717c719 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1225,19 +1225,31 @@ radv_set_ds_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
{
struct radeon_winsys_cs *cs = cmd_buffer->cs;
uint64_t va = radv_buffer_get_va(image->bo);
+ unsigned reg_offset = 0, reg_count = 0;
va += image->offset + image->clear_value_offset;
assert(radv_image_has_htile(image));
- radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 4, 0));
+ if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
+ ++reg_count;
+ } else {
+ ++reg_offset;
+ va += 4;
+ }
+ if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
+ ++reg_count;
+
+ radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 2 + reg_count, 0));
radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
S_370_WR_CONFIRM(1) |
S_370_ENGINE_SEL(V_370_PFP));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
- radeon_emit(cs, ds_clear_value.stencil);
- radeon_emit(cs, fui(ds_clear_value.depth));
+ if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT)
+ radeon_emit(cs, ds_clear_value.stencil);
+ if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
+ radeon_emit(cs, fui(ds_clear_value.depth));
radv_update_bound_fast_clear_ds(cmd_buffer, image, ds_clear_value,
aspects);
@@ -1251,20 +1263,31 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
struct radv_image *image)
{
struct radeon_winsys_cs *cs = cmd_buffer->cs;
+ VkImageAspectFlags aspects = vk_format_aspects(image->vk_format);
uint64_t va = radv_buffer_get_va(image->bo);
+ unsigned reg_offset = 0, reg_count = 0;
va += image->offset + image->clear_value_offset;
if (!radv_image_has_htile(image))
return;
+ if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
+ ++reg_count;
+ } else {
+ ++reg_offset;
+ va += 4;
+ }
+ if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
+ ++reg_count;
+
radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_MEM) |
COPY_DATA_DST_SEL(COPY_DATA_REG) |
- COPY_DATA_COUNT_SEL);
+ (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
- radeon_emit(cs, R_028028_DB_STENCIL_CLEAR >> 2);
+ radeon_emit(cs, (R_028028_DB_STENCIL_CLEAR + 4 * reg_offset) >> 2);
radeon_emit(cs, 0);
radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > Hello list, > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > > > - 42 queued > > > - 6 nominated (outstanding) > > > - and 0 rejected patches > > > > > > Notable changes in this release: > > > - numerous fixes for radv > > > - libatomic checks for meson, as well as fixing coverage for less common > > > (not > > > arm or x86) platforms > > > - lots of common Intel fixes > > > - GLX fixes > > > - tarball fixes for android > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > Testing reports/general approval > > > > > > Any testing reports (or general approval of the state of the branch) will > > > be > > > greatly appreciated. > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly > > > after 10 > > > AM PDT. > > > > June 15th? > > Yes, June 15th. > > Apparently being woken up at 5AM does more brain damage than I thought. Also, we usually wait 48h (two days) between the pre-announcement and the final release, to give more time for testing. J.A. > > Dylan > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106905] Account request
https://bugs.freedesktop.org/show_bug.cgi?id=106905 Emil Velikov changed: What|Removed |Added Version|git |unspecified Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org QA Contact|mesa-dev@lists.freedesktop. | |org | Product|Mesa|freedesktop.org Component|Other |New Accounts --- Comment #3 from Emil Velikov --- Gert has ~70 patches and has been with us for nearly an year. I believe he's earned commit access. -- 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] [AppVeyor] mesa master #7931 failed
Build mesa 7931 failed Commit a2f6e72138 by Samuel Pitoiset on 6/15/2018 1:53 PM: radv: don't check for linear images in emit_fast_color_clear()\n\nWe don't enable CMASK for linear surfaces and addrlib only\nenables DCC for tiling surfaces.\n\nSigned-off-by: Samuel Pitoiset \nReviewed-by: Bas Nieuwenhuizen Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] meson: add GL/glext.h warning fix for MacOS
On 12/06/2018 16:53, Dylan Baker wrote: Quoting Eric Engestrom (2018-06-12 04:25:10) Copied from configure.ac:1950 Signed-off-by: Eric Engestrom --- Is it still needed? We've been building on MacOS for a while, yet nobody noticed anything (Dylan?) If not, we should probably avoid unnecessary differences with Khronos' headers and nuke BUILDING_MESA. --- meson.build | 1 + 1 file changed, 1 insertion(+) diff --git a/meson.build b/meson.build index c5acc8a3587ea20e131e..04b3bdfd77f36670ff7f 100644 --- a/meson.build +++ b/meson.build @@ -209,6 +209,7 @@ endif if host_machine.system() == 'darwin' with_dri_platform = 'apple' + pre_args += '-DBUILDING_MESA' elif ['windows', 'cygwin'].contains(host_machine.system()) with_dri_platform = 'windows' elif system_has_kms_drm -- Cheers, Eric I didn't notice, but I also didn't do a whole lot of testing I've added Jon who did most of the meson mac work and Jeremy who's the resident mac expert. No expert, but I believe this is unfortunately still needed. See commit c7f36574 and the referenced BZ. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] meson: fix i965/anv/isl genX static lib names
Reviewed-by: Tapani Pälli On 15.06.2018 14:15, Eric Engestrom wrote: Shouldn't make any functional difference, just that `liblibanv_gen90.a` will now be called `libanv_gen90.a`. Fixes: 3218056e0eb375eeda470 "meson: Build i965 and dri stack" Fixes: d1992255bb29054fa5176 "meson: Add build Intel "anv" vulkan driver" Signed-off-by: Eric Engestrom --- src/intel/isl/meson.build | 2 +- src/intel/vulkan/meson.build | 2 +- src/mesa/drivers/dri/i965/meson.build | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build index c70c5c05fcd1adb4c63b..5b57188d30c001172ab1 100644 --- a/src/intel/isl/meson.build +++ b/src/intel/isl/meson.build @@ -54,7 +54,7 @@ foreach g : [['40', isl_gen4_files], ['50', []], ['60', isl_gen6_files], ['90', isl_gen9_files], ['100', []], ['110', []]] _gen = g[0] isl_gen_libs += static_library( -'libisl_gen@0@'.format(_gen), +'isl_gen@0@'.format(_gen), [g[1], isl_gen_files, gen_xml_pack], include_directories : [inc_common, inc_intel], c_args : [c_vis_args, no_override_init_args, diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build index f20a8a54c9bbdfb43dd3..159ad092314bcef6ec7c 100644 --- a/src/intel/vulkan/meson.build +++ b/src/intel/vulkan/meson.build @@ -95,7 +95,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', ['gen7_cmd_buffer.c']], ['100', ['gen8_cmd_buffer.c']], ['110', ['gen8_cmd_buffer.c']]] _gen = g[0] libanv_gen_libs += static_library( -'libanv_gen@0@'.format(_gen), +'anv_gen@0@'.format(_gen), [anv_gen_files, g[1], anv_entrypoints[0], anv_extensions_h], include_directories : [ inc_common, inc_compiler, inc_drm_uapi, inc_intel, inc_vulkan_util, diff --git a/src/mesa/drivers/dri/i965/meson.build b/src/mesa/drivers/dri/i965/meson.build index 20404d5b059736b9bc8c..761bb51d6faa696798cc 100644 --- a/src/mesa/drivers/dri/i965/meson.build +++ b/src/mesa/drivers/dri/i965/meson.build @@ -138,7 +138,7 @@ files_i965 = files( i965_gen_libs = [] foreach v : ['40', '45', '50', '60', '70', '75', '80', '90', '100', '110'] i965_gen_libs += static_library( -'libi965_gen@0@'.format(v), +'i965_gen@0@'.format(v), ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack], include_directories : [inc_common, inc_intel, inc_dri_common], c_args : [ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values
On Thu, Jun 14, 2018 at 05:57:01PM -0700, Keith Packard wrote:
> We sorted out what 'vscan' means and are trying to use it correctly.
>
> vscan = 0 is the same as vscan = 1, which is slightly annoying; we use
> MAX2(vscan, 1) everywhere.
>
> randr doesn't pass vscan at all, so we set wsi mode vscan = 0.
>
> The doublescan flag doubles the vscan value, so we don't need to deal
> with that separately, we can just compare flags normally.
>
> Signed-off-by: Keith Packard
> ---
> src/vulkan/wsi/wsi_common_display.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_display.c
> b/src/vulkan/wsi/wsi_common_display.c
> index c7f794a0eff..de1c1826bd2 100644
> --- a/src/vulkan/wsi/wsi_common_display.c
> +++ b/src/vulkan/wsi/wsi_common_display.c
> @@ -149,7 +149,7 @@ wsi_display_mode_matches_drm(wsi_display_mode *wsi,
>wsi->vsync_start == drm->vsync_start &&
>wsi->vsync_end == drm->vsync_end &&
>wsi->vtotal == drm->vtotal &&
> - wsi->vscan == drm->vscan &&
> + MAX2(wsi->vscan, 1) == MAX2(drm->vscan, 1) &&
>wsi->flags == drm->flags;
> }
>
> @@ -158,7 +158,7 @@ wsi_display_mode_refresh(struct wsi_display_mode *wsi)
> {
> return (double) wsi->clock * 1000.0 / ((double) wsi->htotal *
>(double) wsi->vtotal *
> - (double) (wsi->vscan + 1));
> + (double) MAX2(wsi->vscan, 1));
Are you dealing with INTERLACE anywhere? The kernel generally operates
under the assumption that vrefresh == field rate.
> }
>
> static uint64_t wsi_get_current_monotonic(void)
> @@ -1657,6 +1657,7 @@ wsi_display_mode_matches_x(struct wsi_display_mode *wsi,
>wsi->vsync_start == xcb->vsync_start &&
>wsi->vsync_end == xcb->vsync_end &&
>wsi->vtotal == xcb->vtotal &&
> + wsi->vscan <= 1 &&
>wsi->flags == xcb->mode_flags;
> }
>
> @@ -1707,8 +1708,6 @@ wsi_display_register_x_mode(struct wsi_device
> *wsi_device,
> display_mode->vsync_end = x_mode->vsync_end;
> display_mode->vtotal = x_mode->vtotal;
> display_mode->vscan = 0;
> - if (x_mode->mode_flags & XCB_RANDR_MODE_FLAG_DOUBLE_SCAN)
> - display_mode->vscan = 1;
> display_mode->flags = x_mode->mode_flags;
>
> list_addtail(_mode->list, >display_modes);
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: remove multisample bit from shader key.
Reviewed-by: Samuel Pitoiset
On 06/15/2018 12:51 AM, Dave Airlie wrote:
From: Dave Airlie
This wasn't being used anywhere inside the shader from what I can see.
---
src/amd/vulkan/radv_pipeline.c | 2 --
src/amd/vulkan/radv_private.h | 1 -
src/amd/vulkan/radv_shader.h | 1 -
3 files changed, 4 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 6eeedc65a39..ccbcbbadd55 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1868,7 +1868,6 @@ radv_generate_graphics_pipeline_key(struct radv_pipeline
*pipeline,
pCreateInfo->pMultisampleState->rasterizationSamples > 1) {
uint32_t num_samples =
pCreateInfo->pMultisampleState->rasterizationSamples;
uint32_t ps_iter_samples =
radv_pipeline_get_ps_iter_samples(pCreateInfo->pMultisampleState);
- key.multisample = true;
key.log2_num_samples = util_logbase2(num_samples);
key.log2_ps_iter_samples = util_logbase2(ps_iter_samples);
}
@@ -1909,7 +1908,6 @@ radv_fill_shader_keys(struct radv_shader_variant_key
*keys,
for(int i = 0; i < MESA_SHADER_STAGES; ++i)
keys[i].has_multiview_view_index =
key->has_multiview_view_index;
- keys[MESA_SHADER_FRAGMENT].fs.multisample = key->multisample;
keys[MESA_SHADER_FRAGMENT].fs.col_format = key->col_format;
keys[MESA_SHADER_FRAGMENT].fs.is_int8 = key->is_int8;
keys[MESA_SHADER_FRAGMENT].fs.is_int10 = key->is_int10;
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 316fbc9af1d..7841d70deea 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -360,7 +360,6 @@ struct radv_pipeline_key {
uint32_t is_int10;
uint8_t log2_ps_iter_samples;
uint8_t log2_num_samples;
- uint32_t multisample : 1;
uint32_t has_multiview_view_index : 1;
uint32_t optimisations_disabled : 1;
};
diff --git a/src/amd/vulkan/radv_shader.h b/src/amd/vulkan/radv_shader.h
index 05de188e3f3..5b2284efcfd 100644
--- a/src/amd/vulkan/radv_shader.h
+++ b/src/amd/vulkan/radv_shader.h
@@ -98,7 +98,6 @@ struct radv_fs_variant_key {
uint8_t log2_num_samples;
uint32_t is_int8;
uint32_t is_int10;
- uint32_t multisample : 1;
};
struct radv_shader_variant_key {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #7930 completed
Build mesa 7930 completed
Commit efae127993 by Christian Gmeiner on 6/15/2018 10:18 AM:
util/bitset: include util/macro.h\n\nBITSET_FFS(x) macro makes use of ARRAY_SIZE(x) macro which is\ndefined in util/macro.h. Include it directy to make usage more\nstraightforward.\n\nFixes: 692bd4a1ab9 ("util: replace Elements() with ARRAY_SIZE()")\nSigned-off-by: Christian Gmeiner \nReviewed-by: Eric Engestrom
Configure your notification preferences
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/bitset: include util/macro.h
On Friday, 2018-06-15 12:18:56 +0200, Christian Gmeiner wrote:
> BITSET_FFS(x) macro makes use of ARRAY_SIZE(x) macro which is
> defined in util/macro.h. Include it directy to make usage more
> straightforward.
>
> Fixes: 692bd4a1ab9 ("util: replace Elements() with ARRAY_SIZE()")
> Signed-off-by: Christian Gmeiner
Reviewed-by: Eric Engestrom
and pushed :)
> ---
> src/util/bitset.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/util/bitset.h b/src/util/bitset.h
> index 75e29a9a51..adafc72a5f 100644
> --- a/src/util/bitset.h
> +++ b/src/util/bitset.h
> @@ -32,6 +32,7 @@
> #define BITSET_H
>
> #include "util/bitscan.h"
> +#include "util/macros.h"
>
> /
> * generic bitset implementation
> --
> 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 mesa] meson: fix i965/anv/isl genX static lib names
Shouldn't make any functional difference, just that `liblibanv_gen90.a` will now be called `libanv_gen90.a`. Fixes: 3218056e0eb375eeda470 "meson: Build i965 and dri stack" Fixes: d1992255bb29054fa5176 "meson: Add build Intel "anv" vulkan driver" Signed-off-by: Eric Engestrom --- src/intel/isl/meson.build | 2 +- src/intel/vulkan/meson.build | 2 +- src/mesa/drivers/dri/i965/meson.build | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build index c70c5c05fcd1adb4c63b..5b57188d30c001172ab1 100644 --- a/src/intel/isl/meson.build +++ b/src/intel/isl/meson.build @@ -54,7 +54,7 @@ foreach g : [['40', isl_gen4_files], ['50', []], ['60', isl_gen6_files], ['90', isl_gen9_files], ['100', []], ['110', []]] _gen = g[0] isl_gen_libs += static_library( -'libisl_gen@0@'.format(_gen), +'isl_gen@0@'.format(_gen), [g[1], isl_gen_files, gen_xml_pack], include_directories : [inc_common, inc_intel], c_args : [c_vis_args, no_override_init_args, diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build index f20a8a54c9bbdfb43dd3..159ad092314bcef6ec7c 100644 --- a/src/intel/vulkan/meson.build +++ b/src/intel/vulkan/meson.build @@ -95,7 +95,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', ['gen7_cmd_buffer.c']], ['100', ['gen8_cmd_buffer.c']], ['110', ['gen8_cmd_buffer.c']]] _gen = g[0] libanv_gen_libs += static_library( -'libanv_gen@0@'.format(_gen), +'anv_gen@0@'.format(_gen), [anv_gen_files, g[1], anv_entrypoints[0], anv_extensions_h], include_directories : [ inc_common, inc_compiler, inc_drm_uapi, inc_intel, inc_vulkan_util, diff --git a/src/mesa/drivers/dri/i965/meson.build b/src/mesa/drivers/dri/i965/meson.build index 20404d5b059736b9bc8c..761bb51d6faa696798cc 100644 --- a/src/mesa/drivers/dri/i965/meson.build +++ b/src/mesa/drivers/dri/i965/meson.build @@ -138,7 +138,7 @@ files_i965 = files( i965_gen_libs = [] foreach v : ['40', '45', '50', '60', '70', '75', '80', '90', '100', '110'] i965_gen_libs += static_library( -'libi965_gen@0@'.format(v), +'i965_gen@0@'.format(v), ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack], include_directories : [inc_common, inc_intel, inc_dri_common], c_args : [ -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: Clear meminfo to avoid valgrind warning.
Reviewed-by: Samuel Pitoiset
On 06/15/2018 12:08 AM, Bas Nieuwenhuizen wrote:
Somehow valgrind misses that the value is initialized by the ioctl.
---
src/amd/common/ac_gpu_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index e908cc6fa96..e885c0538e9 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -235,7 +235,7 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
}
if (info->drm_minor >= 9) {
- struct drm_amdgpu_memory_info meminfo;
+ struct drm_amdgpu_memory_info meminfo = {};
r = amdgpu_query_info(dev, AMDGPU_INFO_MEMORY, sizeof(meminfo), );
if (r) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/2] gallium: add scalar isa shader cap
v1 -> v2:
- nv30 is _NOT_ scalar as suggested by Ilia Mirkin.
- Change from a screen cap to a shader cap as suggested
by Eric Anholt.
- radeonsi is scalar as suggested by Marek Olšák.
- Change missing ones to be scalar.
v2 -> v3:
- r600 prefers vec4 as suggested by Marek Olšák.
Signed-off-by: Christian Gmeiner
Reviewed-by: Eric Anholt
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h| 2 ++
src/gallium/auxiliary/tgsi/tgsi_exec.h | 2 ++
src/gallium/docs/source/screen.rst | 1 +
src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
src/gallium/drivers/freedreno/freedreno_screen.c | 3 ++-
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++
src/gallium/drivers/r600/r600_pipe.c | 2 ++
src/gallium/drivers/radeonsi/si_get.c| 2 ++
src/gallium/drivers/svga/svga_screen.c | 6 ++
src/gallium/drivers/v3d/v3d_screen.c | 2 ++
src/gallium/drivers/vc4/vc4_screen.c | 2 ++
src/gallium/drivers/virgl/virgl_screen.c | 3 +++
src/gallium/include/pipe/p_defines.h | 1 +
15 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
index c7755bfe1d..7b66b75872 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
@@ -143,6 +143,8 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
return 0;
+ case PIPE_SHADER_CAP_SCALAR_ISA:
+ return 1;
case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
return 32;
}
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 0fac7ea456..ed8b9e8869 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -544,6 +544,8 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
return 0;
+ case PIPE_SHADER_CAP_SCALAR_ISA:
+ return 1;
case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
return PIPE_MAX_SHADER_BUFFERS;
case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 0f18b7a94b..a044099873 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -546,6 +546,7 @@ MOV OUT[0], CONST[0][3] # copy vector 3 of constbuf 0
how many HW counters are available for this stage. (0 uses SSBO atomics).
* ``PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS``: If atomic counters are
separate, how many atomic counter buffers are available for this stage.
+* ``PIPE_SHADER_CAP_SCALAR_ISA``: Whether the ISA is a scalar one.
.. _pipe_compute_cap:
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index e031807117..e426514cc6 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -473,6 +473,7 @@ etna_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
+ case PIPE_SHADER_CAP_SCALAR_ISA:
return 0;
}
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index a414cb6d60..97eec73238 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -592,7 +592,8 @@ fd_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
- return 0;
+ case PIPE_SHADER_CAP_SCALAR_ISA:
+ return 1;
case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
if (is_a5xx(screen)) {
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index a77f70e6bb..dce88e1b1a 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -343,6 +343,7 @@ nv30_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
+ case PIPE_SHADER_CAP_SCALAR_ISA:
return 0;
default:
debug_printf("unknown vertex shader param %d\n", param);
@@ -395,6 +396,7 @@
[Mesa-dev] [PATCH v3 2/2] mesa/st: only do scalar lowerings if driver benefits
As not every (upcoming) backend compiler is happy with
nir_lower_xxx_to_scalar lowerings do them only if the backend
is scalar (and not vec4) based.
Signed-off-by: Christian Gmeiner
Reviewed-by: Eric Anholt
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 39 +--
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index c8c2ef6cff..67622c127a 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -315,15 +315,18 @@ st_nir_assign_uniform_locations(struct gl_context *ctx,
}
void
-st_nir_opts(nir_shader *nir)
+st_nir_opts(nir_shader *nir, bool scalar)
{
bool progress;
do {
progress = false;
NIR_PASS_V(nir, nir_lower_vars_to_ssa);
- NIR_PASS_V(nir, nir_lower_alu_to_scalar);
- NIR_PASS_V(nir, nir_lower_phis_to_scalar);
+
+ if (scalar) {
+ NIR_PASS_V(nir, nir_lower_alu_to_scalar);
+ NIR_PASS_V(nir, nir_lower_phis_to_scalar);
+ }
NIR_PASS_V(nir, nir_lower_alu);
NIR_PASS_V(nir, nir_lower_pack);
@@ -362,6 +365,9 @@ st_glsl_to_nir(struct st_context *st, struct gl_program
*prog,
{
const nir_shader_compiler_options *options =
st->ctx->Const.ShaderCompilerOptions[prog->info.stage].NirOptions;
+ enum pipe_shader_type type = pipe_shader_type_from_mesa(stage);
+ struct pipe_screen *screen = st->pipe->screen;
+ bool is_scalar = screen->get_shader_param(screen, type,
PIPE_SHADER_CAP_SCALAR_ISA);
assert(options);
if (prog->nir)
@@ -404,7 +410,7 @@ st_glsl_to_nir(struct st_context *st, struct gl_program
*prog,
NIR_PASS_V(nir, nir_split_var_copies);
NIR_PASS_V(nir, nir_lower_var_copies);
- st_nir_opts(nir);
+ st_nir_opts(nir, is_scalar);
return nir;
}
@@ -586,7 +592,7 @@ st_nir_get_mesa_program(struct gl_context *ctx,
}
static void
-st_nir_link_shaders(nir_shader **producer, nir_shader **consumer)
+st_nir_link_shaders(nir_shader **producer, nir_shader **consumer, bool scalar)
{
nir_lower_io_arrays_to_elements(*producer, *consumer);
@@ -613,8 +619,8 @@ st_nir_link_shaders(nir_shader **producer, nir_shader
**consumer)
NIR_PASS_V(*producer, nir_lower_indirect_derefs, indirect_mask);
NIR_PASS_V(*consumer, nir_lower_indirect_derefs, indirect_mask);
- st_nir_opts(*producer);
- st_nir_opts(*consumer);
+ st_nir_opts(*producer, scalar);
+ st_nir_opts(*consumer, scalar);
}
}
@@ -625,6 +631,20 @@ st_link_nir(struct gl_context *ctx,
struct gl_shader_program *shader_program)
{
struct st_context *st = st_context(ctx);
+ struct pipe_screen *screen = st->pipe->screen;
+ bool is_scalar[MESA_SHADER_STAGES];
+
+ /* Determine scalar property of each shader stage */
+ for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+ struct gl_linked_shader *shader = shader_program->_LinkedShaders[i];
+ enum pipe_shader_type type;
+
+ if (shader == NULL)
+ continue;
+
+ type = pipe_shader_type_from_mesa(shader->Stage);
+ is_scalar[i] = screen->get_shader_param(screen, type,
PIPE_SHADER_CAP_SCALAR_ISA);
+ }
/* Determine first and last stage. */
unsigned first = MESA_SHADER_STAGES;
@@ -653,7 +673,7 @@ st_link_nir(struct gl_context *ctx,
nir_shader *nir = shader->Program->nir;
NIR_PASS_V(nir, nir_lower_io_to_scalar_early, mask);
- st_nir_opts(nir);
+ st_nir_opts(nir, is_scalar[i]);
}
/* Linking the stages in the opposite order (from fragment to vertex)
@@ -668,7 +688,8 @@ st_link_nir(struct gl_context *ctx,
continue;
st_nir_link_shaders(>Program->nir,
- _program->_LinkedShaders[next]->Program->nir);
+ _program->_LinkedShaders[next]->Program->nir,
+ is_scalar[i]);
next = i;
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util/bitset: include util/macro.h
BITSET_FFS(x) macro makes use of ARRAY_SIZE(x) macro which is
defined in util/macro.h. Include it directy to make usage more
straightforward.
Fixes: 692bd4a1ab9 ("util: replace Elements() with ARRAY_SIZE()")
Signed-off-by: Christian Gmeiner
---
src/util/bitset.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/util/bitset.h b/src/util/bitset.h
index 75e29a9a51..adafc72a5f 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -32,6 +32,7 @@
#define BITSET_H
#include "util/bitscan.h"
+#include "util/macros.h"
/
* generic bitset implementation
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/14] intel/fs: general 8/16/32/64-bit shuffle_src_to_dst function (v2)
On 15/06/18 06:50, Jason Ekstrand wrote:
> On Thu, Jun 14, 2018 at 6:06 PM, Jose Maria Casanova Crespo
> mailto:jmcasan...@igalia.com>> wrote:
>
> This new function takes care of shuffle/unshuffle components of a
> particular bit-size in components with a different bit-size.
>
> If source type size is smaller than destination type size the operation
> needed is a component shuffle. The opposite case would be an unshuffle.
>
> Component units are measured in terms of the smaller type between
> source and destination. As we are un/shuffling the smaller components
> from/into a bigger one.
>
> The operation allows to skip first_component number of components from
> the source.
>
> Shuffle MOVs are retyped using integer types avoiding problems with
> denorms and float types if source and destination bitsize is different.
> This allows to simplify uses of shuffle functions that are dealing with
> these retypes individually.
>
> Now there is a new restriction so source and destination can not overlap
> anymore when calling this shuffle function. Following patches that
> migrate
> to use this new function will take care individually of avoiding source
> and destination overlaps.
>
> v2: (Jason Ekstrand)
> - Rewrite overlap asserts.
> - Manage type_sz(src.type) == type_sz(dst.type) case using MOVs
> from source to dest. This works for 64-bit to 64-bits
> operation that on Gen7 as it doesn't support Q registers.
> - Explain that components units are based in the smallest type.
>
> Cc: Jason Ekstrand mailto:ja...@jlekstrand.net>>
> ---
> src/intel/compiler/brw_fs_nir.cpp | 100 ++
> 1 file changed, 100 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 166da0aa6d7..9c5afc9c46f 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -5362,6 +5362,106 @@ shuffle_16bit_data_for_32bit_write(const
> fs_builder ,
> }
> }
>
> +/*
> + * This helper takes a source register and un/shuffles it into the
> destination
> + * register.
> + *
> + * If source type size is smaller than destination type size the
> operation
> + * needed is a component shuffle. The opposite case would be an
> unshuffle. If
> + * source/destination type size is equal a shuffle is done that
> would be
> + * equivalent to a simple MOV.
> + *
> + * For example, if source is a 16-bit type and destination is
> 32-bit. A 3
> + * components .xyz 16-bit vector on SIMD8 would be.
> + *
> + * |x1|x2|x3|x4|x5|x6|x7|x8|y1|y2|y3|y4|y5|y6|y7|y8|
> + * |z1|z2|z3|z4|z5|z6|z7|z8| | | | | | | | |
> + *
> + * This helper will return the following 2 32-bit components with
> the 16-bit
> + * values shuffled:
> + *
> + * |x1 y1|x2 y2|x3 y3|x4 y4|x5 y5|x6 y6|x7 y7|x8 y8|
> + * |z1 |z2 |z3 |z4 |z5 |z6 |z7 |z8 |
> + *
> + * For unshuffle, the example would be the opposite, a 64-bit type
> source
> + * and a 32-bit destination. A 2 component .xy 64-bit vector on SIMD8
> + * would be:
> + *
> + * | x1l x1h | x2l x2h | x3l x3h | x4l x4h |
> + * | x5l x5h | x6l x6h | x7l x7h | x8l x8h |
> + * | y1l y1h | y2l y2h | y3l y3h | y4l y4h |
> + * | y5l y5h | y6l y6h | y7l y7h | y8l y8h |
> + *
> + * The returned result would be the following 4 32-bit components
> unshuffled:
> + *
> + * | x1l | x2l | x3l | x4l | x5l | x6l | x7l | x8l |
> + * | x1h | x2h | x3h | x4h | x5h | x6h | x7h | x8h |
> + * | y1l | y2l | y3l | y4l | y5l | y6l | y7l | y8l |
> + * | y1h | y2h | y3h | y4h | y5h | y6h | y7h | y8h |
> + *
> + * - Source and destination register must not be overlapped.
> + * - components units are measured in terms of the smaller type between
> + * source and destination because we are un/shuffling the smaller
> + * components from/into the bigger ones.
> + * - first_component parameter allows skipping source components.
> + */
> +void
> +shuffle_src_to_dst(const fs_builder ,
> + const fs_reg ,
> + const fs_reg ,
> + uint32_t first_component,
> + uint32_t components)
> +{
> + if (type_sz(src.type) == type_sz(dst.type)) {
> + assert(!regions_overlap(dst,
> + type_sz(dst.type) * bld.dispatch_width() * components,
> + offset(src, bld, first_component),
> + type_sz(src.type) * bld.dispatch_width() * components));
> + for (unsigned i = 0; i < components; i++) {
> + bld.MOV(retype(offset(dst, bld, i), src.type),
> +
Re: [Mesa-dev] [PATCH 1/6] i965/fs: Optimize OR with 0 into a MOV
I dropped a suggestion in patch 1 that also applies to patch 3, feel
free to take it or not, and then I pointed out a small issue in patch 6
that I think should be addressed that I think should be fixed.
Otherwise, the series is:
Reviewed-by: Iago Toral Quiroga
On Thu, 2018-06-14 at 17:43 -0700, Ian Romanick wrote:
> From: Ian Romanick
>
> fs_visitor::set_gs_stream_control_data_bits generates some code like
> "control_data_bits | stream_id << ((2 * (vertex_count - 1)) % 32)" as
> part of EmitVertex. The first time this (dynamically) occurs in the
> shader, control_data_bits is zero. Many times we can determine this
> statically and various optimizations will collaborate to make one of
> the
> OR operands literal zero.
>
> Converting the OR to a MOV usually allows it to be copy-propagated
> away.
> However, this does not happen in at least some shaders (in the
> assembly
> output of
> shaders/closed/UnrealEngine4/EffectsCaveDemo/301.shader_test,
> search for shl).
>
> All of the affected shaders are geometry shaders.
>
> Broadwell and Skylake had similar results. (Skylake shown)
> total instructions in shared programs: 14375452 -> 14375413 (<.01%)
> instructions in affected programs: 6422 -> 6383 (-0.61%)
> helped: 39
> HURT: 0
> helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
> helped stats (rel) min: 0.14% max: 2.56% x̄: 1.91% x̃: 2.56%
> 95% mean confidence interval for instructions value: -1.00 -1.00
> 95% mean confidence interval for instructions %-change: -2.26% -1.57%
> Instructions are helped.
>
> total cycles in shared programs: 531981179 -> 531980555 (<.01%)
> cycles in affected programs: 27493 -> 26869 (-2.27%)
> helped: 39
> HURT: 0
> helped stats (abs) min: 16 max: 16 x̄: 16.00 x̃: 16
> helped stats (rel) min: 0.60% max: 7.92% x̄: 5.94% x̃: 7.92%
> 95% mean confidence interval for cycles value: -16.00 -16.00
> 95% mean confidence interval for cycles %-change: -6.98% -4.90%
> Cycles are helped.
>
> No changes on earlier platforms.
>
> Signed-off-by: Ian Romanick
> ---
> src/intel/compiler/brw_fs.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> index d67c0a41922..d836b268629 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -2448,7 +2448,8 @@ fs_visitor::opt_algebraic()
> }
> break;
>case BRW_OPCODE_OR:
> - if (inst->src[0].equals(inst->src[1])) {
> + if (inst->src[0].equals(inst->src[1]) ||
> + inst->src[1].is_zero()) {
> inst->opcode = BRW_OPCODE_MOV;
> inst->src[1] = reg_undef;
> progress = true;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] i965/fs: Propagate conditional modifiers from not instructions
On Thu, 2018-06-14 at 17:43 -0700, Ian Romanick wrote:
> From: Ian Romanick
>
> Skylake
> total instructions in shared programs: 14399081 -> 14399010 (<.01%)
> instructions in affected programs: 26961 -> 26890 (-0.26%)
> helped: 57
> HURT: 0
> helped stats (abs) min: 1 max: 6 x̄: 1.25 x̃: 1
> helped stats (rel) min: 0.16% max: 0.80% x̄: 0.30% x̃: 0.18%
> 95% mean confidence interval for instructions value: -1.50 -0.99
> 95% mean confidence interval for instructions %-change: -0.35% -0.25%
> Instructions are helped.
>
> total cycles in shared programs: 532978307 -> 532976050 (<.01%)
> cycles in affected programs: 468629 -> 466372 (-0.48%)
> helped: 33
> HURT: 20
> helped stats (abs) min: 3 max: 360 x̄: 116.52 x̃: 98
> helped stats (rel) min: 0.06% max: 3.63% x̄: 1.66% x̃: 1.27%
> HURT stats (abs) min: 2 max: 172 x̄: 79.40 x̃: 43
> HURT stats (rel) min: 0.04% max: 3.02% x̄: 1.48% x̃: 0.44%
> 95% mean confidence interval for cycles value: -81.29 -3.88
> 95% mean confidence interval for cycles %-change: -1.07% 0.12%
> Inconclusive result (%-change mean confidence interval includes 0).
>
> All Gen6+ platforms, except Ivy Bridge, had similar results. (Haswell
> shown)
> total instructions in shared programs: 12973897 -> 12973838 (<.01%)
> instructions in affected programs: 25970 -> 25911 (-0.23%)
> helped: 55
> HURT: 0
> helped stats (abs) min: 1 max: 2 x̄: 1.07 x̃: 1
> helped stats (rel) min: 0.16% max: 0.62% x̄: 0.28% x̃: 0.18%
> 95% mean confidence interval for instructions value: -1.14 -1.00
> 95% mean confidence interval for instructions %-change: -0.32% -0.24%
> Instructions are helped.
>
> total cycles in shared programs: 410355841 -> 410352067 (<.01%)
> cycles in affected programs: 578454 -> 574680 (-0.65%)
> helped: 47
> HURT: 5
> helped stats (abs) min: 3 max: 360 x̄: 85.74 x̃: 18
> helped stats (rel) min: 0.05% max: 3.68% x̄: 1.18% x̃: 0.38%
> HURT stats (abs) min: 2 max: 242 x̄: 51.20 x̃: 4
> HURT stats (rel) min: <.01% max: 0.45% x̄: 0.15% x̃: 0.11%
> 95% mean confidence interval for cycles value: -104.89 -40.27
> 95% mean confidence interval for cycles %-change: -1.45% -0.66%
> Cycles are helped.
>
> Ivy Bridge
> total instructions in shared programs: 11679351 -> 11679301 (<.01%)
> instructions in affected programs: 28208 -> 28158 (-0.18%)
> helped: 50
> HURT: 0
> helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
> helped stats (rel) min: 0.12% max: 0.54% x̄: 0.23% x̃: 0.16%
> 95% mean confidence interval for instructions value: -1.00 -1.00
> 95% mean confidence interval for instructions %-change: -0.27% -0.19%
> Instructions are helped.
>
> total cycles in shared programs: 257445362 -> 257444662 (<.01%)
> cycles in affected programs: 419338 -> 418638 (-0.17%)
> helped: 40
> HURT: 3
> helped stats (abs) min: 1 max: 170 x̄: 65.05 x̃: 24
> helped stats (rel) min: 0.02% max: 3.51% x̄: 1.26% x̃: 0.41%
> HURT stats (abs) min: 2 max: 1588 x̄: 634.00 x̃: 312
> HURT stats (rel) min: 0.05% max: 2.97% x̄: 1.21% x̃: 0.62%
> 95% mean confidence interval for cycles value: -97.96 65.41
> 95% mean confidence interval for cycles %-change: -1.56% -0.62%
> Inconclusive result (value mean confidence interval includes 0).
>
> No changes on Iron Lake or GM45.
>
> Signed-off-by: Ian Romanick
> ---
> src/intel/compiler/brw_fs_cmod_propagation.cpp | 63
> +-
> 1 file changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
> b/src/intel/compiler/brw_fs_cmod_propagation.cpp
> index b4f05613e98..c935cc66c81 100644
> --- a/src/intel/compiler/brw_fs_cmod_propagation.cpp
> +++ b/src/intel/compiler/brw_fs_cmod_propagation.cpp
> @@ -111,6 +111,61 @@ cmod_propagate_cmp_to_add(const gen_device_info
> *devinfo, bblock_t *block,
> return false;
> }
>
> +/**
> + * Propagate conditional modifiers from NOT instructions
> + *
> + * Attempt to convert sequences like
> + *
> + *or(8) g78<8,8,1> g76<8,8,1>UDg77<8,8,1>UD
> + *...
> + *not.nz.f0(8)nullg78<8,8,1>UD
> + *
> + * into
> + *
> + *or.z.f0(8) g78<8,8,1> g76<8,8,1>UDg77<8,8,1>UD
> + */
> +static bool
> +cmod_propagate_not(const gen_device_info *devinfo, bblock_t *block,
> + fs_inst *inst)
> +{
> + const enum brw_conditional_mod cond = brw_negate_cmod(inst-
> >conditional_mod);
> + bool read_flag = false;
> +
> + foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst,
> inst) {
> + if (regions_overlap(scan_inst->dst, scan_inst->size_written,
> + inst->src[0], inst->size_read(0))) {
> + if (cond != BRW_CONDITIONAL_Z &&
> + cond != BRW_CONDITIONAL_NZ)
> +break;
Looks like we can do this before the loop.
> +
> + if (scan_inst->opcode != BRW_OPCODE_OR &&
> + scan_inst->opcode != BRW_OPCODE_AND)
> +break;
> +
> + if (scan_inst->is_partial_write() ||
> + scan_inst->dst.offset !=
[Mesa-dev] [AppVeyor] mesa master #7929 failed
Build mesa 7929 failed Commit 4cfc4cef80 by Lukas Rusak on 6/4/2018 7:38 PM: meson: fix private libs when building without glx\n\nI noticed that the generated pkg-config files will include\nglx and x11 dependencies even when x11 isn't a selected platform.\n\nThis fixes the private libs and was tested by building kmscube\n\nV2:\n - check if gallium-xlib is being used for glx\n\nFixes: 108d257a16859898f5ce0 "meson: build libEGL"\nReviewed-by: Dylan Baker \nReviewed-by: Eric Engestrom Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] meson: fix private libs when building without glx
On Thursday, 2018-06-14 10:25:20 -0700, Lukas Rusak wrote:
> How can I get some traction on this?
Sorry about that, it fell through the cracks.
Pushed now with my r-b and Fixes: 108d257a16859898f5ce0 "meson: build libEGL"
>
> On Mon, Jun 4, 2018 at 12:38 PM Lukas Rusak wrote:
>
> > 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
> >
> > V2:
> > - check if gallium-xlib is being used for glx
> >
> > Reviewed-by: Dylan Baker
> > ---
> > meson.build | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 4aafba802a..b1ab9d6a20 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' or with_glx == 'gallium-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
Re: [Mesa-dev] [PATCH 1/6] i965/fs: Optimize OR with 0 into a MOV
On Thu, 2018-06-14 at 17:43 -0700, Ian Romanick wrote:
> From: Ian Romanick
>
> fs_visitor::set_gs_stream_control_data_bits generates some code like
> "control_data_bits | stream_id << ((2 * (vertex_count - 1)) % 32)" as
> part of EmitVertex. The first time this (dynamically) occurs in the
> shader, control_data_bits is zero. Many times we can determine this
> statically and various optimizations will collaborate to make one of
> the
> OR operands literal zero.
>
> Converting the OR to a MOV usually allows it to be copy-propagated
> away.
> However, this does not happen in at least some shaders (in the
> assembly
> output of
> shaders/closed/UnrealEngine4/EffectsCaveDemo/301.shader_test,
> search for shl).
>
> All of the affected shaders are geometry shaders.
>
> Broadwell and Skylake had similar results. (Skylake shown)
> total instructions in shared programs: 14375452 -> 14375413 (<.01%)
> instructions in affected programs: 6422 -> 6383 (-0.61%)
> helped: 39
> HURT: 0
> helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
> helped stats (rel) min: 0.14% max: 2.56% x̄: 1.91% x̃: 2.56%
> 95% mean confidence interval for instructions value: -1.00 -1.00
> 95% mean confidence interval for instructions %-change: -2.26% -1.57%
> Instructions are helped.
>
> total cycles in shared programs: 531981179 -> 531980555 (<.01%)
> cycles in affected programs: 27493 -> 26869 (-2.27%)
> helped: 39
> HURT: 0
> helped stats (abs) min: 16 max: 16 x̄: 16.00 x̃: 16
> helped stats (rel) min: 0.60% max: 7.92% x̄: 5.94% x̃: 7.92%
> 95% mean confidence interval for cycles value: -16.00 -16.00
> 95% mean confidence interval for cycles %-change: -6.98% -4.90%
> Cycles are helped.
>
> No changes on earlier platforms.
>
> Signed-off-by: Ian Romanick
> ---
> src/intel/compiler/brw_fs.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> index d67c0a41922..d836b268629 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -2448,7 +2448,8 @@ fs_visitor::opt_algebraic()
> }
> break;
>case BRW_OPCODE_OR:
> - if (inst->src[0].equals(inst->src[1])) {
> + if (inst->src[0].equals(inst->src[1]) ||
> + inst->src[1].is_zero()) {
> inst->opcode = BRW_OPCODE_MOV;
> inst->src[1] = reg_undef;
> progress = true;
While we are at this, shouldn't we also handle this as a MOV (from
src[1]) when src[0].is_zero() is true?
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106774] GLSL IR copy propagates loads of SSBOs
https://bugs.freedesktop.org/show_bug.cgi?id=106774 --- Comment #20 from Iago Toral --- FWIW, this sounds a lot like the problem we tried to address in NIR with a load-combine pass some time ago here: https://lists.freedesktop.org/archives/mesa-dev/2016-April/112925.html -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
Any movement on one of these solutions ending up in master and 18.1.x anytime soon? On Thu, 31 May 2018 at 05:09, Kyle Brenneman wrote: > On 05/29/2018 12:04 PM, Adam Jackson wrote: > > On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > >> Quoting Adam Jackson (2018-05-29 06:50:46) > >>> GL_LIB expands to GLX_mesa, but applications should not link against > >>> that. -lGL is never wrong, just hardcode it. > >> Actually There is this really stupid option in the autotools build > called > >> --gl-lib-name. We should remove that. > >> > >> Emil and I had also discussed that glvnd should provide the gl.pc file > when used > >> instead of mesa. It appears he never got around to that, but it seems > like a > >> useful thing to do. > > https://github.com/NVIDIA/libglvnd/pull/86 > > > > Branch is a bit stale but better than reinventing everything. > > > > Part of the reason I didn't get much further on that is the question of > > distributing the _headers_. It would be a bit awkward if glvnd provided > > the library you link to but not the headers defining its interface - > > though, I guess no more awkward than the current situation. At any rate > > glvnd doesn't install any, and there's no way to generate > > from the Khronos scripts at the moment (it's assumed to be a platform > > implementation detail, and the version in Mesa is just handcoded > > history). > > > > - ajax > > > Yeah, the headers versus libraries question is what makes it awkward. > Libglvnd provides the libraries that an application links against, but > the header files are basically from the Khronos repository. Treating > libglvnd as the source for the libraries and the Khronos tree as the > source for the headers would seem to be the cleanest option, but the > pkg-config files would have to include the paths to both. > > Now that I think about it, though, since the Khronos registry is on > Github now instead of SVN, maybe a git submodule would work? > > -Kyle > > ___ > 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
Re: [Mesa-dev] [PATCH 0/8] i965: Don't recycle BOs until they are idle
On 2018-06-15 07:31 AM, Jason Ekstrand wrote: > On Thu, Jun 14, 2018 at 10:55 AM, Jason Ekstrand > wrote: >> On June 14, 2018 01:43:12 Michel Dänzer wrote: >> On 2018-06-13 10:26 PM, Jason Ekstrand wrote: >>> The current BO cache puts BOs back into the recycle bucket the moment the refcount hits zero. If the BO is busy, we just don't re-use it until it isn't or we re-use it for a render target which we assume will be used first for drawing. This patch series reworks the way the BO cache works a bit so that we don't ever recycle a busy BO. On the down side, it means that we don't get the "keep busy BOs busy" heuristic (which we have no proof actually helps). On the up side, we can now easily use a MRU heuristic instead of round-robin for all buffers and not just the busy ones. Will this be an improvement, a regression or a wash? I don't know but I doubt it will have a major effect one way or another. >>> >>> FWIW, I suspect this could be a significant loss with overlapping copies >>> in glamor (e.g. x11perf -copywinwin500), because it won't be able to >>> reuse the busy BOs anymore (glamor creates a temporary FBO for each >>> overlapping copy). >>> >> >> That's rather horrific... That seems like something glamour could do >> better. As of xserver 1.20, glamor can use GL_MESA_tile_raster_order if available. >> How common are overlapping copies in practice? Are we talking a >> couple per frame or hundreds? X doesn't have a "frame" concept per se, but overlapping copies can be quite common e.g. when scrolling, or moving windows without a compositor. > I did some testing and x11perf -copywinwin500 is... exactly the same with > or without my patches. If anything they might improve it by just a hair. Possible explanations I can think of: 1. Your glamor still has its own FBO cache. Which version of xserver are you testing with? 2. The i965 driver cache isn't hit even before these changes. 3. Allocating BOs from the kernel is significantly cheaper with i915 vs amdgpu. (4. Your GPU is too slow for it to matter. What kind of numbers are you getting?) FWIW, on a Radeon R9 285 I get 36 trep @ 0.0257 msec ( 38900.0/sec): Copy 500x500 from window to window with glamor's FBO cache and 24 trep @ 0.0700 msec ( 14300.0/sec): Copy 500x500 from window to window without (radeonsi's cache doesn't reclaim BOs either until they are idle), i.e. almost a factor of 3. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106774] GLSL IR copy propagates loads of SSBOs
https://bugs.freedesktop.org/show_bug.cgi?id=106774 --- Comment #19 from Michel Dänzer --- (In reply to Ian Romanick from comment #18) > The updated test does not cause GPU hangs with these patches applied. Are > you ok with the test landing in piglit master? Sure, thanks. -- 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
