[Mesa-dev] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
Fixes: https://github.com/iXit/Mesa-3D/issues/314
For this application, NaN is passed to KILL_IF and is expected to
pass.
v2: Explain in the code why UGE is used.
Signed-off-by: Axel Davy
Reviewed-by: Marek Olšák
CC:
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index f54d025aec0..a768b449047 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -60,7 +60,8 @@ static void kil_emit(const struct lp_build_tgsi_action
*action,
for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
LLVMValueRef value = lp_build_emit_fetch(bld_base,
inst, 0, i);
- conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE, value,
+ /* UGE because NaN shouldn't get killed */
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE, value,
ctx->ac.f32_0, "");
}
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
On 24/09/18 01:55, Marek Olšák wrote: On Fri, Sep 21, 2018 at 11:34 AM, Emil Velikov wrote: On 21 September 2018 at 00:42, Timothy Arceri wrote: On 20/9/18 11:09 pm, Ian Romanick wrote: On 09/19/2018 11:36 PM, Federico Dossena wrote: As most of you are probably aware of, id2 and id3 games store GL extensions in a buffer that's too small for modern systems. This usually leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the creator of this commit didn't know is that some id3 games (the more "recent" ones) don't crash, they just truncate the string. As a result of this commit, these games can't detect some extensions and therefore don't work properly. It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not set, so why not just set it? Doesn't that fix the problem? There is no driconfig option for this currently. Personally I'd rather just sort the extensions (even if it was only for 32bit builds of Mesa) rather than adding a bunch of code and extra entry's into driconfig. Or are you saying you would prefer we do nothing and people should use MESA_EXTENSION_MAX_YEAR be required to use? As mentioned in my other reply there seems to be two type of problems when dealing with some idtech games: - blind copy - leading to crashes - copy + truncation - leading to "missing" extensions Since the change causes incorrect rendering and it's impossible to associate that with the need to set MESA_EXTENSION_MAX_YEAR, the env var doesn't help. You need to be a professional driver developer in order to guess that the env var should be set. I certainly wouldn't guess that. I didn't even know that the extension list is not sorted by year anymore. The driconfig approach is fragile. You can't identify the list of affected apps because you don't have or test all apps and they may just show incorrect rendering, which is inconclusive. Building a list of affected apps for driconfig is a huge effort that nobody will realistically do. I prefer minimizing the number of workarounds in driconfig as much as possible. Marek I agree FWIW. The sorting by year is a bit of a nuisance, but unfortunately the problem won't disappear by wishing it away. IMHO, only sorting on some apps is just adding complexity to the workaround. Restricting to 32bit makes sense though, as it makes a clear transition path, since I suppose no 64 bit app is affected, and I suppose one day (far in the future perhaps, on specially on Windows) 32 bit will go out of use. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/22] radeonsi: NaN should pass kill_if
Please add a comment that UGE is used because NaN means no kill.
Thanks. You can also nominate this for stable. Other than those:
Reviewed-by: Marek Olšák
Marek
On Sun, Sep 23, 2018 at 1:00 PM, Axel Davy wrote:
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
> Fixes: https://github.com/iXit/Mesa-3D/issues/314
>
> For this application, NaN is passed to KILL_IF and is expected to
> pass.
>
> Signed-off-by: Axel Davy
> ---
> src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> index f54d025aec0..3469ad9ca67 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> @@ -60,7 +60,7 @@ static void kil_emit(const struct lp_build_tgsi_action
> *action,
>
> for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> LLVMValueRef value = lp_build_emit_fetch(bld_base,
> inst, 0, i);
> - conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE, value,
> + conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE, value,
> ctx->ac.f32_0, "");
> }
>
> --
> 2.18.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: Clarify comment in util_init_thread_pinning
Reviewed-by: Marek Olšák Marek On Tue, Sep 18, 2018 at 11:26 AM, Michel Dänzer wrote: > From: Michel Dänzer > > As discussed in the review of the patch which added the comment: > > Nothing happens when a thread is created, because pthread_atfork doesn't > affect creating threads. However, spawning a child process will likely > crash. > > Signed-off-by: Michel Dänzer > --- > src/gallium/auxiliary/util/u_helpers.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/auxiliary/util/u_helpers.c > b/src/gallium/auxiliary/util/u_helpers.c > index b6cebf96329..4c70c004178 100644 > --- a/src/gallium/auxiliary/util/u_helpers.c > +++ b/src/gallium/auxiliary/util/u_helpers.c > @@ -148,7 +148,10 @@ util_init_thread_pinning(void) > /* Reset thread affinity for all child processes to prevent them from > * inheriting the current thread's affinity. > * > -* What happens if a driver is unloaded and the app creates a thread? > +* XXX: If the driver is unloaded after this, and the app later calls > +* fork(), the child process will likely crash before fork() returns, > +* because the address where util_set_full_cpu_affinity was located > +* will either be unmapped or point to random other contents. > */ > pthread_atfork(NULL, NULL, util_set_full_cpu_affinity); > } > -- > 2.19.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
On Fri, Sep 21, 2018 at 11:34 AM, Emil Velikov wrote: > On 21 September 2018 at 00:42, Timothy Arceri wrote: >> On 20/9/18 11:09 pm, Ian Romanick wrote: >>> >>> On 09/19/2018 11:36 PM, Federico Dossena wrote: As most of you are probably aware of, id2 and id3 games store GL extensions in a buffer that's too small for modern systems. This usually leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the creator of this commit didn't know is that some id3 games (the more "recent" ones) don't crash, they just truncate the string. As a result of this commit, these games can't detect some extensions and therefore don't work properly. >>> >>> >>> It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not >>> set, so why not just set it? Doesn't that fix the problem? >> >> >> There is no driconfig option for this currently. Personally I'd rather just >> sort the extensions (even if it was only for 32bit builds of Mesa) rather >> than adding a bunch of code and extra entry's into driconfig. >> >> Or are you saying you would prefer we do nothing and people should use >> MESA_EXTENSION_MAX_YEAR be required to use? >> > As mentioned in my other reply there seems to be two type of problems > when dealing with some idtech games: > - blind copy - leading to crashes > - copy + truncation - leading to "missing" extensions Since the change causes incorrect rendering and it's impossible to associate that with the need to set MESA_EXTENSION_MAX_YEAR, the env var doesn't help. You need to be a professional driver developer in order to guess that the env var should be set. I certainly wouldn't guess that. I didn't even know that the extension list is not sorted by year anymore. The driconfig approach is fragile. You can't identify the list of affected apps because you don't have or test all apps and they may just show incorrect rendering, which is inconclusive. Building a list of affected apps for driconfig is a huge effort that nobody will realistically do. I prefer minimizing the number of workarounds in driconfig as much as possible. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] docs: Update FAQ re: OpenGL API version supported
Used a variation on the standard boilerplate version info that is used in the release notes. v2: Fixed text re: context creation. --- docs/faq.html | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/docs/faq.html b/docs/faq.html index 6270a071da..d1be04bf71 100644 --- a/docs/faq.html +++ b/docs/faq.html @@ -45,7 +45,18 @@ See the https://www.opengl.org/";>OpenGL website for more information. -Mesa 9.x supports the OpenGL 3.1 specification. +Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API specification. +Note that the version reported by glGetString(GL_VERSION) or +glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on +the particular driver being used. Some drivers don't support all the features +required in OpenGL 4.5. OpenGL 4.5 is only available if +requested at context creation. Compatibility contexts may report a lower +version depending on each driver. Note that compatibility contexts were not +supported prior to 18.1.0. + + +For earlier versions, consult the release notes for the version of the +OpenGL API they support. -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Update FAQ with current OpenGL API version supported
On Sun, 23 Sep 2018 at 20:35, Bas Nieuwenhuizen wrote: > On Sun, Sep 23, 2018 at 2:05 AM Stuart Young wrote: > > > > Used a variation on the standard boilerplate version info that is used in > > the release notes. > > > > --- > > docs/faq.html | 11 ++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/docs/faq.html b/docs/faq.html > > index 6270a071da..080c6b6da7 100644 > > --- a/docs/faq.html > > +++ b/docs/faq.html > > @@ -45,7 +45,16 @@ See the https://www.opengl.org/";>OpenGL > website for more > > information. > > > > > > -Mesa 9.x supports the OpenGL 3.1 specification. > > +Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API > specification. > > +Note that the version reported by glGetString(GL_VERSION) or > > +glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) > depends on > > +the particular driver being used. Some drivers don't support all the > features > > +required in OpenGL 4.5. OpenGL 4.5 is only available if requested at > context > > +creation because compatibility contexts are not supported. > > Aren't hey supported for radeonsi these days? > Ahh yes. Sorry, think I pulled this from the 17.0.0 release notes and didn't notice the difference at the time compared to the 18.2.1 notes. Well spotted. Will update and resend. -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vulkan: Disable randr lease for libxcb < 1.13
From: Maxime Since the Randr lease code was added, compiling against libxcb 1.12 no longer works. CC: mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108024 Fixes: 7ab1fffcd2a504024b16e408de329f7a94553ecc Tested-By: Maxime --- src/vulkan/wsi/wsi_common_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/vulkan/wsi/wsi_common_display.c b/src/vulkan/wsi/wsi_common_display.c index e99b0465ec..e23d2983c9 100644 --- a/src/vulkan/wsi/wsi_common_display.c +++ b/src/vulkan/wsi/wsi_common_display.c @@ -2304,6 +2304,7 @@ wsi_acquire_xlib_display(VkPhysicalDevice physical_device, if (!crtc) return VK_ERROR_INITIALIZATION_FAILED; +#ifdef HAVE_DRI3_MODIFIERS xcb_randr_lease_t lease = xcb_generate_id(connection); xcb_randr_create_lease_cookie_t cl_c = xcb_randr_create_lease(connection, root, lease, 1, 1, @@ -2324,6 +2325,7 @@ wsi_acquire_xlib_display(VkPhysicalDevice physical_device, return VK_ERROR_INITIALIZATION_FAILED; wsi->fd = fd; +#endif return VK_SUCCESS; } -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: avoid sending GS_EMIT in shaders without outputs
Fixes GPU hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107857
Signed-off-by: Józef Kucia
---
src/gallium/drivers/radeonsi/si_shader.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 36f58e2ce52c..fedc616ebf61 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4326,9 +4326,12 @@ static void si_llvm_emit_vertex(struct ac_shader_abi
*abi,
gs_next_vertex = LLVMBuildAdd(ctx->ac.builder, gs_next_vertex,
ctx->i32_1, "");
LLVMBuildStore(ctx->ac.builder, gs_next_vertex,
ctx->gs_next_vertex[stream]);
- /* Signal vertex emission */
- ac_build_sendmsg(&ctx->ac, AC_SENDMSG_GS_OP_EMIT | AC_SENDMSG_GS |
(stream << 8),
-si_get_gs_wave_id(ctx));
+ /* Signal vertex emission if vertex data was written. */
+ if (offset) {
+ ac_build_sendmsg(&ctx->ac, AC_SENDMSG_GS_OP_EMIT |
AC_SENDMSG_GS | (stream << 8),
+si_get_gs_wave_id(ctx));
+ }
+
if (!use_kill)
lp_build_endif(&if_state);
}
--
2.16.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108024] [Debian Stretch]Fail to build because "xcb_randr_lease_t"
https://bugs.freedesktop.org/show_bug.cgi?id=108024 --- Comment #4 from Stuart Young --- Hi Maxime, Looks good to me (tho I am not an expert either), and same sort of fix as Dave Airlie's patch to support older versions of libxcb. Will see if I can get this in to Mesa & 18.2.2. If it takes some time, I'll log a bug report against Mesa in Debian as well with a link to this report/patch. Fixes: 7ab1fffcd2a504024b16e408de329f7a94553ecc -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108024] [Debian Stretch]Fail to build because "xcb_randr_lease_t"
https://bugs.freedesktop.org/show_bug.cgi?id=108024 --- Comment #3 from Max --- Created attachment 141701 --> https://bugs.freedesktop.org/attachment.cgi?id=141701&action=edit Disable lease for libxcb < 1.13 Hello, I'm not an expert about Mesa development but i found a workaround to compile Mesa 18.2.1 on Debian Stretch. Stretch has libxcb 1.12 and without this patch, the compilation for Vulkan drivers fails. If someone can create a better patch and implement it in the next release 18.2.x, it will be great. And if it's possible obviously. I try mesa 18.2.1 on Stretch with DXVK games like Vampyr, Divinity Original Sin 2 and Assassin's Creed : Unity. All these games work without problems. Cheers, Maxime -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/22] st/nine: Capture also default matrices for D3DSBT_ALL
It should be
last_index += D3DTS_WORLDMATRIX(0) - 10;
I drop this patch from the serie and patch 21/22 as they need more testing.
On 9/23/18 7:00 PM, Axel Davy wrote:
We avoid allocating space for never unused matrices.
However we must do as if we had captured them.
Thus when a D3DSBT_ALL stateblock apply has fewer matrices
than device state, allocate the default matrices for the stateblock
before applying.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/stateblock9.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/state_trackers/nine/stateblock9.c
b/src/gallium/state_trackers/nine/stateblock9.c
index ebfd622ff91..fd6f5d55677 100644
--- a/src/gallium/state_trackers/nine/stateblock9.c
+++ b/src/gallium/state_trackers/nine/stateblock9.c
@@ -494,6 +494,16 @@ nine_state_copy_common_all(struct NineDevice9 *device,
src->ff.num_transforms * sizeof(src->ff.transform[0]));
dst->ff.num_transforms = src->ff.num_transforms;
}
+/* Alloc and init missing transforms */
+if (dst->ff.num_transforms > src->ff.num_transforms) {
+int last_index = dst->ff.num_transforms - 1;
+/* There a hole in the indices we fill */
+if (last_index >= 10)
+last_index += D3DTS_WORLDMATRIX(0);
+(void) nine_state_access_transform((struct nine_ff_state
*)&src->ff,
+ last_index,
+ TRUE);
+}
memcpy(dst->ff.transform,
src->ff.transform, src->ff.num_transforms * sizeof(D3DMATRIX));
if (apply) /* TODO: memset */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50/ir: fix link-time build failure
Reviewed-by: Ilia Mirkin
On Sun, Sep 23, 2018 at 12:59 PM, Rhys Perry wrote:
> Seems this fixes linking problems that occur in some situations.
>
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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 0cbf4d071f..295497be2f 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -1732,7 +1732,7 @@ NVC0LoweringPass::loadSuInfo32(Value *ptr, int slot,
> uint32_t off, bool bindless
> prog->driver->io.suInfoBase);
> }
>
> -inline Value *
> +Value *
> NVC0LoweringPass::loadMsAdjInfo32(TexInstruction::Target target, uint32_t
> index, int slot, Value *ind, bool bindless)
> {
> if (!bindless || targ->getChipset() < NVISA_GM107_CHIPSET)
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 21/22] st/nine: Mark transform matrices dirty for D3DSBT_ALL
D3DSBT_ALL stateblocks capture the transform matrices. Fixes some d3d test programs not displaying properly. Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/device9.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/nine/device9.c b/src/gallium/state_trackers/nine/device9.c index 51e49ac4303..a051f6b62fa 100644 --- a/src/gallium/state_trackers/nine/device9.c +++ b/src/gallium/state_trackers/nine/device9.c @@ -2376,13 +2376,24 @@ NineDevice9_CreateStateBlock( struct NineDevice9 *This, NINE_STATE_IDXBUF | NINE_STATE_MATERIAL | NINE_STATE_BLEND_COLOR | - NINE_STATE_SAMPLE_MASK; + NINE_STATE_SAMPLE_MASK | + NINE_STATE_FF_VSTRANSF; memset(dst->changed.rs, ~0, (D3DRS_COUNT / 32) * sizeof(uint32_t)); dst->changed.rs[D3DRS_LAST / 32] |= (1 << (D3DRS_COUNT % 32)) - 1; dst->changed.vtxbuf = (1ULL << This->caps.MaxStreams) - 1; dst->changed.stream_freq = dst->changed.vtxbuf; dst->changed.ucp = (1 << PIPE_MAX_CLIP_PLANES) - 1; dst->changed.texture = (1 << NINE_MAX_SAMPLERS) - 1; + /* The doc says the projection, world, view and texture matrices +* are saved, which would translate to: +* dst->ff.changed.transform[0] = 0x00FF000C; +* dst->ff.changed.transform[D3DTS_WORLD / 32] |= 1 << (D3DTS_WORLD % 32); +* However we assume they meant save everything (which is basically just the +* above plus the other world matrices). +*/ + dst->ff.changed.transform[0] = 0x00FF000C; + for (s = 0; s < 8; s++) + dst->ff.changed.transform[8+s] = ~0; } NineStateBlock9_Capture(NineStateBlock9(*ppSB)); -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 22/22] radeonsi: NaN should pass kill_if
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
Fixes: https://github.com/iXit/Mesa-3D/issues/314
For this application, NaN is passed to KILL_IF and is expected to
pass.
Signed-off-by: Axel Davy
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index f54d025aec0..3469ad9ca67 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -60,7 +60,7 @@ static void kil_emit(const struct lp_build_tgsi_action
*action,
for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
LLVMValueRef value = lp_build_emit_fetch(bld_base,
inst, 0, i);
- conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE, value,
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE, value,
ctx->ac.f32_0, "");
}
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 20/22] st/nine: Capture also default matrices for D3DSBT_ALL
We avoid allocating space for never unused matrices.
However we must do as if we had captured them.
Thus when a D3DSBT_ALL stateblock apply has fewer matrices
than device state, allocate the default matrices for the stateblock
before applying.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/stateblock9.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/state_trackers/nine/stateblock9.c
b/src/gallium/state_trackers/nine/stateblock9.c
index ebfd622ff91..fd6f5d55677 100644
--- a/src/gallium/state_trackers/nine/stateblock9.c
+++ b/src/gallium/state_trackers/nine/stateblock9.c
@@ -494,6 +494,16 @@ nine_state_copy_common_all(struct NineDevice9 *device,
src->ff.num_transforms * sizeof(src->ff.transform[0]));
dst->ff.num_transforms = src->ff.num_transforms;
}
+/* Alloc and init missing transforms */
+if (dst->ff.num_transforms > src->ff.num_transforms) {
+int last_index = dst->ff.num_transforms - 1;
+/* There a hole in the indices we fill */
+if (last_index >= 10)
+last_index += D3DTS_WORLDMATRIX(0);
+(void) nine_state_access_transform((struct nine_ff_state
*)&src->ff,
+ last_index,
+ TRUE);
+}
memcpy(dst->ff.transform,
src->ff.transform, src->ff.num_transforms * sizeof(D3DMATRIX));
if (apply) /* TODO: memset */
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 18/22] st/nine: Split NINE_STATE_FF_OTHER
NINE_STATE_FF_OTHER was mostly ff vs states.
Rename it to NINE_STATE_FF_VS_OTHER and
move common states with ps to
NINE_STATE_FF_PS_CONSTS (renamed from
NINE_STATE_FF_PSSTAGES).
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 4 +--
src/gallium/state_trackers/nine/nine_ff.c | 4 +--
src/gallium/state_trackers/nine/nine_state.c | 30 +--
src/gallium/state_trackers/nine/nine_state.h | 6 ++--
src/gallium/state_trackers/nine/stateblock9.c | 2 +-
5 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 37fcba875ff..51e49ac4303 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -2350,7 +2350,7 @@ NineDevice9_CreateStateBlock( struct NineDevice9 *This,
if (Type == D3DSBT_ALL || Type == D3DSBT_PIXELSTATE) {
dst->changed.group |=
NINE_STATE_PS | NINE_STATE_PS_CONST | NINE_STATE_BLEND |
- NINE_STATE_FF_OTHER | NINE_STATE_FF_PSSTAGES | NINE_STATE_PS_CONST |
+ NINE_STATE_FF_VS_OTHER | NINE_STATE_FF_PS_CONSTS |
NINE_STATE_PS_CONST |
NINE_STATE_FB | NINE_STATE_DSA | NINE_STATE_MULTISAMPLE |
NINE_STATE_RASTERIZER | NINE_STATE_STENCIL_REF;
memcpy(dst->changed.rs,
@@ -2539,7 +2539,7 @@ NineDevice9_SetTextureStageState( struct NineDevice9
*This,
if (unlikely(This->is_recording)) {
if (Type == D3DTSS_TEXTURETRANSFORMFLAGS)
state->changed.group |= NINE_STATE_PS_PARAMS_MISC;
-state->changed.group |= NINE_STATE_FF_PSSTAGES;
+state->changed.group |= NINE_STATE_FF_PS_CONSTS;
state->ff.changed.tex_stage[Stage][Type / 32] |= 1 << (Type % 32);
} else
nine_context_set_texture_stage_state(This, Stage, Type, Value);
diff --git a/src/gallium/state_trackers/nine/nine_ff.c
b/src/gallium/state_trackers/nine/nine_ff.c
index 453f280c9fc..addea3dde1f 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -1949,7 +1949,7 @@ nine_ff_load_point_and_fog_params(struct NineDevice9
*device)
struct nine_context *context = &device->context;
struct fvec4 *dst = (struct fvec4 *)device->ff.vs_const;
-if (!(context->changed.group & NINE_STATE_FF_OTHER))
+if (!(context->changed.group & NINE_STATE_FF_VS_OTHER))
return;
dst[26].x = asfloat(context->rs[D3DRS_POINTSIZE_MIN]);
dst[26].y = asfloat(context->rs[D3DRS_POINTSIZE_MAX]);
@@ -1986,7 +1986,7 @@ nine_ff_load_ps_params(struct NineDevice9 *device)
struct fvec4 *dst = (struct fvec4 *)device->ff.ps_const;
unsigned s;
-if (!(context->changed.group & (NINE_STATE_FF_PSSTAGES |
NINE_STATE_FF_OTHER)))
+if (!(context->changed.group & NINE_STATE_FF_PS_CONSTS))
return;
for (s = 0; s < 8; ++s)
diff --git a/src/gallium/state_trackers/nine/nine_state.c
b/src/gallium/state_trackers/nine/nine_state.c
index cb62c28b7b7..3db9a07fbf4 100644
--- a/src/gallium/state_trackers/nine/nine_state.c
+++ b/src/gallium/state_trackers/nine/nine_state.c
@@ -1870,7 +1870,7 @@ CSMT_ITEM_NO_WAIT(nine_context_set_texture_stage_state,
context->changed.group |= NINE_STATE_PS_CONST;
}
-context->changed.group |= NINE_STATE_FF_PSSTAGES;
+context->changed.group |= NINE_STATE_FF_PS_CONSTS;
context->ff.changed.tex_stage[Stage][Type / 32] |= 1 << (Type % 32);
}
@@ -2073,7 +2073,7 @@ nine_context_apply_stateblock(struct NineDevice9 *device,
if (src->changed.group & NINE_STATE_FF_MATERIAL)
context->ff.material = src->ff.material;
-if (src->changed.group & NINE_STATE_FF_PSSTAGES) {
+if (src->changed.group & NINE_STATE_FF_PS_CONSTS) {
unsigned s;
for (s = 0; s < NINE_MAX_TEXTURE_STAGES; ++s) {
for (i = 0; i < NINED3DTSS_COUNT; ++i)
@@ -2266,7 +2266,7 @@ nine_context_apply_stateblock(struct NineDevice9 *device,
if (src->changed.group & NINE_STATE_FF_MATERIAL)
nine_context_set_material(device, &src->ff.material);
-if (src->changed.group & NINE_STATE_FF_PSSTAGES) {
+if (src->changed.group & NINE_STATE_FF_PS_CONSTS) {
unsigned s;
for (s = 0; s < NINE_MAX_TEXTURE_STAGES; ++s) {
for (i = 0; i < NINED3DTSS_COUNT; ++i)
@@ -3531,11 +3531,11 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST +
1] =
[D3DRS_ALPHABLENDENABLE] = NINE_STATE_BLEND,
[D3DRS_FOGENABLE] = NINE_STATE_FF_SHADER | NINE_STATE_VS_PARAMS_MISC |
NINE_STATE_PS_PARAMS_MISC | NINE_STATE_PS_CONST,
[D3DRS_SPECULARENABLE] = NINE_STATE_FF_LIGHTING,
-[D3DRS_FOGCOLOR] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST,
+[D3DRS_FOGCOLOR] = NINE_STATE_FF_PS_CONSTS | NINE_STATE_PS_CONST,
[D3DRS_FOGTABLEMODE] = NINE_STATE_FF_SHADER | NINE_STATE_PS_PARAMS_MISC |
NINE_STATE_PS_CONST,
-[D3DRS_FOGSTART] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST,
-[D3DRS_FOG
[Mesa-dev] [PATCH 16/22] st/nine: Mark pointsize states as ff states
The pointsize states were missing the ff NINE_STATE_FF_OTHER flag, and thus might miss state updates when using ff. Fixes some wine tests. Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/nine_state.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/state_trackers/nine/nine_state.c b/src/gallium/state_trackers/nine/nine_state.c index 3ab90633d25..7e13feb83d6 100644 --- a/src/gallium/state_trackers/nine/nine_state.c +++ b/src/gallium/state_trackers/nine/nine_state.c @@ -3567,8 +3567,8 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST + 1] = [D3DRS_EMISSIVEMATERIALSOURCE] = NINE_STATE_FF_LIGHTING, [D3DRS_VERTEXBLEND] = NINE_STATE_FF_OTHER, [D3DRS_CLIPPLANEENABLE] = NINE_STATE_RASTERIZER, -[D3DRS_POINTSIZE] = NINE_STATE_RASTERIZER, -[D3DRS_POINTSIZE_MIN] = NINE_STATE_RASTERIZER | NINE_STATE_VS_PARAMS_MISC, +[D3DRS_POINTSIZE] = NINE_STATE_RASTERIZER | NINE_STATE_FF_OTHER, +[D3DRS_POINTSIZE_MIN] = NINE_STATE_RASTERIZER | NINE_STATE_FF_OTHER | NINE_STATE_VS_PARAMS_MISC, [D3DRS_POINTSPRITEENABLE] = NINE_STATE_RASTERIZER, [D3DRS_POINTSCALEENABLE] = NINE_STATE_FF_OTHER, [D3DRS_POINTSCALE_A] = NINE_STATE_FF_OTHER, @@ -3578,7 +3578,7 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST + 1] = [D3DRS_MULTISAMPLEMASK] = NINE_STATE_SAMPLE_MASK, [D3DRS_PATCHEDGESTYLE] = NINE_STATE_UNHANDLED, [D3DRS_DEBUGMONITORTOKEN] = NINE_STATE_UNHANDLED, -[D3DRS_POINTSIZE_MAX] = NINE_STATE_RASTERIZER | NINE_STATE_VS_PARAMS_MISC, +[D3DRS_POINTSIZE_MAX] = NINE_STATE_RASTERIZER | NINE_STATE_FF_OTHER | NINE_STATE_VS_PARAMS_MISC, [D3DRS_INDEXEDVERTEXBLENDENABLE] = NINE_STATE_FF_OTHER, [D3DRS_COLORWRITEENABLE] = NINE_STATE_BLEND, [D3DRS_TWEENFACTOR] = NINE_STATE_FF_OTHER, -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/22] st/nine: Increase maximum number of temp registers
With some test app I hit the limit. As we allocate on demand (up to the maximum), it is free to increase the limit. Signed-off-by: Axel Davy CC: --- src/gallium/state_trackers/nine/nine_shader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/nine/nine_shader.c b/src/gallium/state_trackers/nine/nine_shader.c index 5c33a6308c2..2b11958b261 100644 --- a/src/gallium/state_trackers/nine/nine_shader.c +++ b/src/gallium/state_trackers/nine/nine_shader.c @@ -487,7 +487,7 @@ struct shader_translator struct ureg_dst predicate_dst; struct ureg_dst tS[8]; /* texture stage registers */ struct ureg_dst tdst; /* scratch dst if we need extra modifiers */ -struct ureg_dst t[5]; /* scratch TEMPs */ +struct ureg_dst t[8]; /* scratch TEMPs */ struct ureg_src vC[2]; /* PS color in */ struct ureg_src vT[8]; /* PS texcoord in */ struct ureg_dst rL[NINE_MAX_LOOP_DEPTH]; /* loop ctr */ -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 19/22] st/nine: Do not mark both ff vs and ps updated
Previously if only ff vs or only ff ps was used,
the constants for both were marked as updated,
while only the constants of the used ff shader
were updated.
Now that NINE_STATE_FF_VS and
NINE_STATE_FF_PS do not intersect anymore,
we can correctly mark the correct set of constant
as updated.
Fixes: https://github.com/iXit/Mesa-3D/issues/319
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_ff.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_ff.c
b/src/gallium/state_trackers/nine/nine_ff.c
index addea3dde1f..261be276ad8 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -2066,6 +2066,8 @@ nine_ff_update(struct NineDevice9 *device)
context->pipe_data.cb_vs_ff = cb;
context->commit |= NINE_STATE_COMMIT_CONST_VS;
+
+context->changed.group &= ~NINE_STATE_FF_VS;
}
if (!context->ps) {
@@ -2078,9 +2080,9 @@ nine_ff_update(struct NineDevice9 *device)
context->pipe_data.cb_ps_ff = cb;
context->commit |= NINE_STATE_COMMIT_CONST_PS;
-}
-context->changed.group &= ~NINE_STATE_FF;
+context->changed.group &= ~NINE_STATE_FF_PS;
+}
}
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/22] st/nine: Don't call SetCursor until a cursor is set
The previous code was ignoring the input
until a cursor is set inside d3d
(with SetCursorProperties), as expected
by wine tests.
However it did still make a call to ID3DPresent_SetCursor,
which would result into a SetCursor(NULL) call, thus
hidding any cursor set outside d3d, which we shouldn't do.
Add comment about not avoiding redundant ID3DPresent_SetCursor
calls once a cursor has been set in d3d, as it has been tested to
cause regressions.
Fixes: https://github.com/iXit/Mesa-3D/issues/197
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index b3e56d70b74..04f90ad8210 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -810,7 +810,14 @@ NineDevice9_ShowCursor( struct NineDevice9 *This,
DBG("This=%p bShow=%d\n", This, (int) bShow);
-This->cursor.visible = bShow && (This->cursor.hotspot.x != -1);
+/* No-op until a cursor is set in d3d */
+if (This->cursor.hotspot.x == -1)
+return old;
+
+This->cursor.visible = bShow;
+/* Note: Don't optimize by avoiding the call if This->cursor.visible
+ * hasn't changed. One has to keep in mind the app may do SetCursor
+ * calls outside d3d, thus such an optimization affects behaviour. */
if (!This->cursor.software)
This->cursor.software =
ID3DPresent_SetCursor(This->swapchains[0]->present, NULL, NULL, bShow) !=
D3D_OK;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 17/22] st/nine: Add dummy ff shader state
Some states only affect the ff shader, not its constants. Currently we don't check anything and always recompute the ff shader key. However we do check for NINE_STATE_FF_OTHER and if set we reupload some constants. Thus for those states which had NINE_STATE_FF_OTHER set but didn't need it, replace by a dummy ff shader state (which is easier to understand for an external reader than just setting 0 and more future proof). Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/nine_state.c | 16 src/gallium/state_trackers/nine/nine_state.h | 4 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/src/gallium/state_trackers/nine/nine_state.c b/src/gallium/state_trackers/nine/nine_state.c index 7e13feb83d6..cb62c28b7b7 100644 --- a/src/gallium/state_trackers/nine/nine_state.c +++ b/src/gallium/state_trackers/nine/nine_state.c @@ -3529,14 +3529,14 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST + 1] = [D3DRS_ALPHAFUNC] = NINE_STATE_DSA, [D3DRS_DITHERENABLE] = NINE_STATE_BLEND, [D3DRS_ALPHABLENDENABLE] = NINE_STATE_BLEND, -[D3DRS_FOGENABLE] = NINE_STATE_FF_OTHER | NINE_STATE_VS_PARAMS_MISC | NINE_STATE_PS_PARAMS_MISC | NINE_STATE_PS_CONST, +[D3DRS_FOGENABLE] = NINE_STATE_FF_SHADER | NINE_STATE_VS_PARAMS_MISC | NINE_STATE_PS_PARAMS_MISC | NINE_STATE_PS_CONST, [D3DRS_SPECULARENABLE] = NINE_STATE_FF_LIGHTING, [D3DRS_FOGCOLOR] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST, -[D3DRS_FOGTABLEMODE] = NINE_STATE_FF_OTHER | NINE_STATE_PS_PARAMS_MISC | NINE_STATE_PS_CONST, +[D3DRS_FOGTABLEMODE] = NINE_STATE_FF_SHADER | NINE_STATE_PS_PARAMS_MISC | NINE_STATE_PS_CONST, [D3DRS_FOGSTART] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST, [D3DRS_FOGEND] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST, [D3DRS_FOGDENSITY] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST, -[D3DRS_RANGEFOGENABLE] = NINE_STATE_FF_OTHER, +[D3DRS_RANGEFOGENABLE] = NINE_STATE_FF_SHADER, [D3DRS_STENCILENABLE] = NINE_STATE_DSA | NINE_STATE_MULTISAMPLE, [D3DRS_STENCILFAIL] = NINE_STATE_DSA, [D3DRS_STENCILZFAIL] = NINE_STATE_DSA, @@ -3557,20 +3557,20 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST + 1] = [D3DRS_CLIPPING] = 0, /* software vertex processing only */ [D3DRS_LIGHTING] = NINE_STATE_FF_LIGHTING, [D3DRS_AMBIENT] = NINE_STATE_FF_LIGHTING | NINE_STATE_FF_MATERIAL, -[D3DRS_FOGVERTEXMODE] = NINE_STATE_FF_OTHER, +[D3DRS_FOGVERTEXMODE] = NINE_STATE_FF_SHADER, [D3DRS_COLORVERTEX] = NINE_STATE_FF_LIGHTING, [D3DRS_LOCALVIEWER] = NINE_STATE_FF_LIGHTING, -[D3DRS_NORMALIZENORMALS] = NINE_STATE_FF_OTHER, +[D3DRS_NORMALIZENORMALS] = NINE_STATE_FF_SHADER, [D3DRS_DIFFUSEMATERIALSOURCE] = NINE_STATE_FF_LIGHTING, [D3DRS_SPECULARMATERIALSOURCE] = NINE_STATE_FF_LIGHTING, [D3DRS_AMBIENTMATERIALSOURCE] = NINE_STATE_FF_LIGHTING, [D3DRS_EMISSIVEMATERIALSOURCE] = NINE_STATE_FF_LIGHTING, -[D3DRS_VERTEXBLEND] = NINE_STATE_FF_OTHER, +[D3DRS_VERTEXBLEND] = NINE_STATE_FF_SHADER, [D3DRS_CLIPPLANEENABLE] = NINE_STATE_RASTERIZER, [D3DRS_POINTSIZE] = NINE_STATE_RASTERIZER | NINE_STATE_FF_OTHER, [D3DRS_POINTSIZE_MIN] = NINE_STATE_RASTERIZER | NINE_STATE_FF_OTHER | NINE_STATE_VS_PARAMS_MISC, [D3DRS_POINTSPRITEENABLE] = NINE_STATE_RASTERIZER, -[D3DRS_POINTSCALEENABLE] = NINE_STATE_FF_OTHER, +[D3DRS_POINTSCALEENABLE] = NINE_STATE_FF_SHADER, [D3DRS_POINTSCALE_A] = NINE_STATE_FF_OTHER, [D3DRS_POINTSCALE_B] = NINE_STATE_FF_OTHER, [D3DRS_POINTSCALE_C] = NINE_STATE_FF_OTHER, @@ -3579,7 +3579,7 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST + 1] = [D3DRS_PATCHEDGESTYLE] = NINE_STATE_UNHANDLED, [D3DRS_DEBUGMONITORTOKEN] = NINE_STATE_UNHANDLED, [D3DRS_POINTSIZE_MAX] = NINE_STATE_RASTERIZER | NINE_STATE_FF_OTHER | NINE_STATE_VS_PARAMS_MISC, -[D3DRS_INDEXEDVERTEXBLENDENABLE] = NINE_STATE_FF_OTHER, +[D3DRS_INDEXEDVERTEXBLENDENABLE] = NINE_STATE_FF_SHADER, [D3DRS_COLORWRITEENABLE] = NINE_STATE_BLEND, [D3DRS_TWEENFACTOR] = NINE_STATE_FF_OTHER, [D3DRS_BLENDOP] = NINE_STATE_BLEND, diff --git a/src/gallium/state_trackers/nine/nine_state.h b/src/gallium/state_trackers/nine/nine_state.h index b8a74a4ee2f..77823655efa 100644 --- a/src/gallium/state_trackers/nine/nine_state.h +++ b/src/gallium/state_trackers/nine/nine_state.h @@ -90,6 +90,10 @@ #define NINE_STATE_ALL 0x1fff #define NINE_STATE_UNHANDLED (1 << 29) +/* These states affect the ff shader key, + * which we recompute everytime. */ +#define NINE_STATE_FF_SHADER0 + #define NINE_STATE_COMMIT_DSA (1 << 0) #define NINE_STATE_COMMIT_RASTERIZER (1 << 1) #define NINE_STATE_COMMIT_BLEND (1 << 2) -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/22] st/nine: Minor refactor of a few NINE_STATE_* flags
Rename NINE_STATE_FOG_SHADER,
NINE_STATE_POINTSIZE_SHADER and NINE_STATE_PS1X_SHADER
into
NINE_STATE_VS_PARAMS_MISC and NINE_STATE_PS_PARAMS_MISC.
The behaviour is unchanged, except one minor change:
D3DRS_FOGTABLEMODE doesn't need to affect VS.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c| 2 +-
src/gallium/state_trackers/nine/nine_state.c | 16 +++-
src/gallium/state_trackers/nine/nine_state.h | 13 ++---
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 04f90ad8210..37fcba875ff 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -2538,7 +2538,7 @@ NineDevice9_SetTextureStageState( struct NineDevice9
*This,
if (unlikely(This->is_recording)) {
if (Type == D3DTSS_TEXTURETRANSFORMFLAGS)
-state->changed.group |= NINE_STATE_PS1X_SHADER;
+state->changed.group |= NINE_STATE_PS_PARAMS_MISC;
state->changed.group |= NINE_STATE_FF_PSSTAGES;
state->ff.changed.tex_stage[Stage][Type / 32] |= 1 << (Type % 32);
} else
diff --git a/src/gallium/state_trackers/nine/nine_state.c
b/src/gallium/state_trackers/nine/nine_state.c
index c81a05a952b..3ab90633d25 100644
--- a/src/gallium/state_trackers/nine/nine_state.c
+++ b/src/gallium/state_trackers/nine/nine_state.c
@@ -1077,15 +1077,13 @@ commit_ps(struct NineDevice9 *device)
#define NINE_STATE_SHADER_CHANGE_VS \
(NINE_STATE_VS | \
NINE_STATE_TEXTURE |\
-NINE_STATE_FOG_SHADER | \
-NINE_STATE_POINTSIZE_SHADER | \
+NINE_STATE_VS_PARAMS_MISC | \
NINE_STATE_SWVP)
#define NINE_STATE_SHADER_CHANGE_PS \
(NINE_STATE_PS | \
NINE_STATE_TEXTURE |\
-NINE_STATE_FOG_SHADER | \
-NINE_STATE_PS1X_SHADER)
+NINE_STATE_PS_PARAMS_MISC)
#define NINE_STATE_FREQUENT \
(NINE_STATE_RASTERIZER | \
@@ -1861,7 +1859,7 @@ CSMT_ITEM_NO_WAIT(nine_context_set_texture_stage_state,
bumpmap_index = 4 * 8 + 2 * Stage + 1;
break;
case D3DTSS_TEXTURETRANSFORMFLAGS:
-context->changed.group |= NINE_STATE_PS1X_SHADER;
+context->changed.group |= NINE_STATE_PS_PARAMS_MISC;
break;
default:
break;
@@ -3531,10 +3529,10 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST +
1] =
[D3DRS_ALPHAFUNC] = NINE_STATE_DSA,
[D3DRS_DITHERENABLE] = NINE_STATE_BLEND,
[D3DRS_ALPHABLENDENABLE] = NINE_STATE_BLEND,
-[D3DRS_FOGENABLE] = NINE_STATE_FF_OTHER | NINE_STATE_FOG_SHADER |
NINE_STATE_PS_CONST,
+[D3DRS_FOGENABLE] = NINE_STATE_FF_OTHER | NINE_STATE_VS_PARAMS_MISC |
NINE_STATE_PS_PARAMS_MISC | NINE_STATE_PS_CONST,
[D3DRS_SPECULARENABLE] = NINE_STATE_FF_LIGHTING,
[D3DRS_FOGCOLOR] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST,
-[D3DRS_FOGTABLEMODE] = NINE_STATE_FF_OTHER | NINE_STATE_FOG_SHADER |
NINE_STATE_PS_CONST,
+[D3DRS_FOGTABLEMODE] = NINE_STATE_FF_OTHER | NINE_STATE_PS_PARAMS_MISC |
NINE_STATE_PS_CONST,
[D3DRS_FOGSTART] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST,
[D3DRS_FOGEND] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST,
[D3DRS_FOGDENSITY] = NINE_STATE_FF_OTHER | NINE_STATE_PS_CONST,
@@ -3570,7 +3568,7 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST +
1] =
[D3DRS_VERTEXBLEND] = NINE_STATE_FF_OTHER,
[D3DRS_CLIPPLANEENABLE] = NINE_STATE_RASTERIZER,
[D3DRS_POINTSIZE] = NINE_STATE_RASTERIZER,
-[D3DRS_POINTSIZE_MIN] = NINE_STATE_RASTERIZER |
NINE_STATE_POINTSIZE_SHADER,
+[D3DRS_POINTSIZE_MIN] = NINE_STATE_RASTERIZER | NINE_STATE_VS_PARAMS_MISC,
[D3DRS_POINTSPRITEENABLE] = NINE_STATE_RASTERIZER,
[D3DRS_POINTSCALEENABLE] = NINE_STATE_FF_OTHER,
[D3DRS_POINTSCALE_A] = NINE_STATE_FF_OTHER,
@@ -3580,7 +3578,7 @@ const uint32_t nine_render_state_group[NINED3DRS_LAST +
1] =
[D3DRS_MULTISAMPLEMASK] = NINE_STATE_SAMPLE_MASK,
[D3DRS_PATCHEDGESTYLE] = NINE_STATE_UNHANDLED,
[D3DRS_DEBUGMONITORTOKEN] = NINE_STATE_UNHANDLED,
-[D3DRS_POINTSIZE_MAX] = NINE_STATE_RASTERIZER |
NINE_STATE_POINTSIZE_SHADER,
+[D3DRS_POINTSIZE_MAX] = NINE_STATE_RASTERIZER | NINE_STATE_VS_PARAMS_MISC,
[D3DRS_INDEXEDVERTEXBLENDENABLE] = NINE_STATE_FF_OTHER,
[D3DRS_COLORWRITEENABLE] = NINE_STATE_BLEND,
[D3DRS_TWEENFACTOR] = NINE_STATE_FF_OTHER,
diff --git a/src/gallium/state_trackers/nine/nine_state.h
b/src/gallium/state_trackers/nine/nine_state.h
index f5fd1ef9cd8..b8a74a4ee2f 100644
--- a/src/gallium/state_trackers/nine/nine_state.h
+++ b/src/gallium/state_trackers/nine/nine_state.h
@@ -83,13 +83,12 @@
#define NINE_STATE_FF_VSTRANSF (1 << 22)
#define NINE_STATE_FF_PSSTAGES (1 << 23)
#define NINE_STATE_FF_OTHER(1 << 24)
-#define NINE_STATE_FOG_SHADER (1 << 25)
-#define NINE_STATE_PS1X_SHADER (1 << 26)
-#define NINE_STATE_POINTSIZE_SHADER (1 << 27)
-#define NINE_STATE_MULTISAMPLE (1 << 28)
-#define NI
[Mesa-dev] [PATCH 10/22] st/nine: Init cursor position at device creation
This is only useful for software cursor,
but at least now we won't start it at (0, 0).
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 9bb97bdf9c3..113ba9d975d 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -333,8 +333,11 @@ NineDevice9_ctor( struct NineDevice9 *This,
This->cursor.hotspot.y = -1;
This->cursor.w = This->cursor.h = 0;
This->cursor.visible = FALSE;
-This->cursor.pos.x = 0;
-This->cursor.pos.y = 0;
+if (ID3DPresent_GetCursorPos(This->swapchains[0]->present,
&This->cursor.pos) != S_OK) {
+This->cursor.pos.x = 0;
+This->cursor.pos.y = 0;
+}
+
{
struct pipe_resource tmpl;
memset(&tmpl, 0, sizeof(tmpl));
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/22] st/nine: Lock the entire buffer in some cases.
Previously we had already found that for
MANAGED buffers the buffer started dirty
(which meant all writes out of bound
before the first draw call using the
buffer have to be taken into account).
Possibly it is the same for the other types of buffers.
For now always lock the entire buffer (starting from the offset)
for these (except for DYNAMIC buffers, which might hurt
performance too much).
Fixes: https://github.com/iXit/Mesa-3D/issues/301
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/buffer9.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/state_trackers/nine/buffer9.c
b/src/gallium/state_trackers/nine/buffer9.c
index 69b08e8c10e..5880ee3c1a2 100644
--- a/src/gallium/state_trackers/nine/buffer9.c
+++ b/src/gallium/state_trackers/nine/buffer9.c
@@ -231,6 +231,14 @@ NineBuffer9_Lock( struct NineBuffer9 *This,
user_warn(OffsetToLock != 0);
}
+/* Write out of bound seems to have to be taken into account for these.
+ * TODO: Do more tests (is it only at buffer first lock ? etc).
+ * Since these buffers are supposed to be locked once and never
+ * writen again (MANAGED or DYNAMIC is used for the other uses cases),
+ * performance should be unaffected. */
+if (!(This->base.usage & D3DUSAGE_DYNAMIC) && This->base.pool !=
D3DPOOL_MANAGED)
+SizeToLock = This->size - OffsetToLock;
+
u_box_1d(OffsetToLock, SizeToLock, &box);
if (This->base.pool == D3DPOOL_MANAGED) {
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/22] st/nine: Avoid redundant SetCursorPos calls
For some applications SetCursorPosition
is called when a cursor event is received.
Our SetCursorPosition was always calling
wine SetCursorPos which would trigger
a cursor event.
The infinite loop is avoided by not calling
SetCursorPos when the position hasn't changed.
Found thanks to wine tests.
Fixes irresponsive GUI for some applications.
Fixes: https://github.com/iXit/Mesa-3D/issues/173
Signed-off-by: Axel Davy
CC:
---
src/gallium/state_trackers/nine/device9.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 113ba9d975d..b3e56d70b74 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -791,6 +791,10 @@ NineDevice9_SetCursorPosition( struct NineDevice9 *This,
DBG("This=%p X=%d Y=%d Flags=%d\n", This, X, Y, Flags);
+if (This->cursor.pos.x == X &&
+This->cursor.pos.y == Y)
+return;
+
This->cursor.pos.x = X;
This->cursor.pos.y = Y;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/22] st/nine: Initialize manually cursor structure
Initialize manually the cursor structure fields
for more clarity on its content.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 293f63bd7b7..9bb97bdf9c3 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -331,6 +331,10 @@ NineDevice9_ctor( struct NineDevice9 *This,
This->cursor.software = FALSE;
This->cursor.hotspot.x = -1;
This->cursor.hotspot.y = -1;
+This->cursor.w = This->cursor.h = 0;
+This->cursor.visible = FALSE;
+This->cursor.pos.x = 0;
+This->cursor.pos.y = 0;
{
struct pipe_resource tmpl;
memset(&tmpl, 0, sizeof(tmpl));
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/22] st/nine: Check if format is DS before retrieving flags
d3d9_get_pipe_depth_format_bindings assumes the input format
is a depth stencil format.
Previously the user could hit this function with an invalid format.
Protect the last non protected call with a depth_stencil_format check.
Another solution is to have d3d9_get_pipe_depth_format_bindings
support non depth stencil format, but we don't want the user
to create depth buffers with d3d formats that can't be one,
it's better to check if the format can be depth buffer with d3d.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/surface9.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/state_trackers/nine/surface9.c
b/src/gallium/state_trackers/nine/surface9.c
index 71aa4f46ffd..5fd662fa049 100644
--- a/src/gallium/state_trackers/nine/surface9.c
+++ b/src/gallium/state_trackers/nine/surface9.c
@@ -111,6 +111,8 @@ NineSurface9_ctor( struct NineSurface9 *This,
if (pDesc->Usage & D3DUSAGE_RENDERTARGET) {
This->base.info.bind |= PIPE_BIND_RENDER_TARGET;
} else if (pDesc->Usage & D3DUSAGE_DEPTHSTENCIL) {
+if (!depth_stencil_format(pDesc->Format))
+return D3DERR_INVALIDCALL;
This->base.info.bind =
d3d9_get_pipe_depth_format_bindings(pDesc->Format);
if (TextureType)
This->base.info.bind |= PIPE_BIND_SAMPLER_VIEW;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/22] st/nine: Fix ff assignment with aliasing
"tex_stage[s][D3DTSS_COLORARG0] >> 4" could be a two bit
number, thus colorarg_b4 was incorrectly set.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_ff.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_ff.c
b/src/gallium/state_trackers/nine/nine_ff.c
index c64085b2ac4..2cb5f080be8 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -1768,20 +1768,20 @@ nine_ff_get_ps(struct NineDevice9 *device)
if (used_c & 0x1) key.ts[s].colorarg0 =
context->ff.tex_stage[s][D3DTSS_COLORARG0] & 0x7;
if (used_c & 0x2) key.ts[s].colorarg1 =
context->ff.tex_stage[s][D3DTSS_COLORARG1] & 0x7;
if (used_c & 0x4) key.ts[s].colorarg2 =
context->ff.tex_stage[s][D3DTSS_COLORARG2] & 0x7;
-if (used_c & 0x1) key.colorarg_b4[0] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG0] >> 4) << s;
-if (used_c & 0x1) key.colorarg_b5[0] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG0] >> 5) << s;
-if (used_c & 0x2) key.colorarg_b4[1] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG1] >> 4) << s;
-if (used_c & 0x2) key.colorarg_b5[1] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG1] >> 5) << s;
-if (used_c & 0x4) key.colorarg_b4[2] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG2] >> 4) << s;
-if (used_c & 0x4) key.colorarg_b5[2] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG2] >> 5) << s;
+if (used_c & 0x1) key.colorarg_b4[0] |=
((context->ff.tex_stage[s][D3DTSS_COLORARG0] >> 4) & 0x1) << s;
+if (used_c & 0x1) key.colorarg_b5[0] |=
((context->ff.tex_stage[s][D3DTSS_COLORARG0] >> 5) & 0x1) << s;
+if (used_c & 0x2) key.colorarg_b4[1] |=
((context->ff.tex_stage[s][D3DTSS_COLORARG1] >> 4) & 0x1) << s;
+if (used_c & 0x2) key.colorarg_b5[1] |=
((context->ff.tex_stage[s][D3DTSS_COLORARG1] >> 5) & 0x1) << s;
+if (used_c & 0x4) key.colorarg_b4[2] |=
((context->ff.tex_stage[s][D3DTSS_COLORARG2] >> 4) & 0x1) << s;
+if (used_c & 0x4) key.colorarg_b5[2] |=
((context->ff.tex_stage[s][D3DTSS_COLORARG2] >> 5) & 0x1) << s;
}
if (key.ts[s].alphaop != D3DTOP_DISABLE) {
if (used_a & 0x1) key.ts[s].alphaarg0 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG0] & 0x7;
if (used_a & 0x2) key.ts[s].alphaarg1 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG1] & 0x7;
if (used_a & 0x4) key.ts[s].alphaarg2 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG2] & 0x7;
-if (used_a & 0x1) key.alphaarg_b4[0] |=
(context->ff.tex_stage[s][D3DTSS_ALPHAARG0] >> 4) << s;
-if (used_a & 0x2) key.alphaarg_b4[1] |=
(context->ff.tex_stage[s][D3DTSS_ALPHAARG1] >> 4) << s;
-if (used_a & 0x4) key.alphaarg_b4[2] |=
(context->ff.tex_stage[s][D3DTSS_ALPHAARG2] >> 4) << s;
+if (used_a & 0x1) key.alphaarg_b4[0] |=
((context->ff.tex_stage[s][D3DTSS_ALPHAARG0] >> 4) & 0x1) << s;
+if (used_a & 0x2) key.alphaarg_b4[1] |=
((context->ff.tex_stage[s][D3DTSS_ALPHAARG1] >> 4) & 0x1) << s;
+if (used_a & 0x4) key.alphaarg_b4[2] |=
((context->ff.tex_stage[s][D3DTSS_ALPHAARG2] >> 4) & 0x1) << s;
}
key.ts[s].resultarg = context->ff.tex_stage[s][D3DTSS_RESULTARG] ==
D3DTA_TEMP;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/22] st/nine: Print transform matrices in debug
This is useful to see the matrices content
in the log to debug.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 150f5e3e05e..293f63bd7b7 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -1967,6 +1967,19 @@ NineDevice9_Clear( struct NineDevice9 *This,
return D3D_OK;
}
+static void
+nine_D3DMATRIX_print(const D3DMATRIX *M)
+{
+DBG("\n(%f %f %f %f)\n"
+"(%f %f %f %f)\n"
+"(%f %f %f %f)\n"
+"(%f %f %f %f)\n",
+M->m[0][0], M->m[0][1], M->m[0][2], M->m[0][3],
+M->m[1][0], M->m[1][1], M->m[1][2], M->m[1][3],
+M->m[2][0], M->m[2][1], M->m[2][2], M->m[2][3],
+M->m[3][0], M->m[3][1], M->m[3][2], M->m[3][3]);
+}
+
HRESULT NINE_WINAPI
NineDevice9_SetTransform( struct NineDevice9 *This,
D3DTRANSFORMSTATETYPE State,
@@ -1978,6 +1991,7 @@ NineDevice9_SetTransform( struct NineDevice9 *This,
DBG("This=%p State=%d pMatrix=%p\n", This, State, pMatrix);
user_assert(M, D3DERR_INVALIDCALL);
+nine_D3DMATRIX_print(pMatrix);
*M = *pMatrix;
if (unlikely(This->is_recording)) {
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/22] st/nine: Implement predicated instructions
Most of the work was already there, just not implemented.
Fixes: https://github.com/iXit/Mesa-3D/issues/318
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_shader.c | 62 ---
1 file changed, 55 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/gallium/state_trackers/nine/nine_shader.c
index 913508fb889..9e90da59597 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -481,6 +481,9 @@ struct shader_translator
struct ureg_dst p;
struct ureg_dst address;
struct ureg_dst a0;
+struct ureg_dst predicate;
+struct ureg_dst predicate_tmp;
+struct ureg_dst predicate_dst;
struct ureg_dst tS[8]; /* texture stage registers */
struct ureg_dst tdst; /* scratch dst if we need extra modifiers */
struct ureg_dst t[5]; /* scratch TEMPs */
@@ -496,6 +499,7 @@ struct shader_translator
unsigned loop_labels[NINE_MAX_LOOP_DEPTH];
unsigned cond_labels[NINE_MAX_COND_DEPTH];
boolean loop_or_rep[NINE_MAX_LOOP_DEPTH]; /* true: loop, false: rep */
+boolean predicated_activated;
unsigned *inst_labels; /* LABEL op */
unsigned num_inst_labels;
@@ -975,7 +979,12 @@ tx_src_param(struct shader_translator *tx, const struct
sm1_src_param *param)
}
break;
case D3DSPR_PREDICATE:
-assert(!"D3DSPR_PREDICATE");
+if (ureg_dst_is_undef(tx->regs.predicate)) {
+/* Forbidden to use the predicate register before being set */
+tx->failure = TRUE;
+tx->regs.predicate = ureg_DECL_temporary(tx->ureg);
+}
+src = ureg_src(tx->regs.predicate);
break;
case D3DSPR_SAMPLER:
assert(param->mod == NINED3DSPSM_NONE);
@@ -1157,11 +1166,15 @@ tx_src_param(struct shader_translator *tx, const struct
sm1_src_param *param)
src = ureg_src(tmp);
break;
case NINED3DSPSM_NOT:
-if (tx->native_integers) {
+if (tx->native_integers && param->file == D3DSPR_CONSTBOOL) {
tmp = tx_scratch(tx);
ureg_NOT(ureg, tmp, src);
src = ureg_src(tmp);
break;
+} else { /* predicate */
+tmp = tx_scratch(tx);
+ureg_ADD(ureg, tmp, ureg_imm1f(ureg, 1.0f), ureg_negate(src));
+src = ureg_src(tmp);
}
/* fall through */
case NINED3DSPSM_COMP:
@@ -1292,7 +1305,9 @@ _tx_dst_param(struct shader_translator *tx, const struct
sm1_dst_param *param)
dst = tx->regs.oDepth; /* XXX: must write .z component */
break;
case D3DSPR_PREDICATE:
-assert(!"D3DSPR_PREDICATE");
+if (ureg_dst_is_undef(tx->regs.predicate))
+tx->regs.predicate = ureg_DECL_temporary(tx->ureg);
+dst = tx->regs.predicate;
break;
case D3DSPR_TEMPFLOAT16:
DBG("unhandled D3DSPR: %u\n", param->file);
@@ -1309,6 +1324,11 @@ _tx_dst_param(struct shader_translator *tx, const struct
sm1_dst_param *param)
if (param->mod & NINED3DSPDM_SATURATE)
dst = ureg_saturate(dst);
+if (tx->predicated_activated) {
+tx->regs.predicate_dst = dst;
+dst = tx->regs.predicate_tmp;
+}
+
return dst;
}
@@ -2891,12 +2911,24 @@ DECL_SPECIAL(TEXLDL)
DECL_SPECIAL(SETP)
{
-STUB(D3DERR_INVALIDCALL);
+const unsigned cmp_op = sm1_insn_flags_to_tgsi_setop(tx->insn.flags);
+struct ureg_dst dst = tx_dst_param(tx, &tx->insn.dst[0]);
+struct ureg_src src[2] = {
+ tx_src_param(tx, &tx->insn.src[0]),
+ tx_src_param(tx, &tx->insn.src[1])
+};
+ureg_insn(tx->ureg, cmp_op, &dst, 1, src, 2, 0);
+return D3D_OK;
}
DECL_SPECIAL(BREAKP)
{
-STUB(D3DERR_INVALIDCALL);
+struct ureg_src src = tx_src_param(tx, &tx->insn.src[0]);
+ureg_IF(tx->ureg, src, tx_cond(tx));
+ureg_BRK(tx->ureg);
+tx_endcond(tx);
+ureg_ENDIF(tx->ureg);
+return D3D_OK;
}
DECL_SPECIAL(PHASE)
@@ -3323,8 +3355,6 @@ sm1_parse_instruction(struct shader_translator *tx)
insn->ndst = info->ndst;
insn->nsrc = info->nsrc;
-assert(!insn->predicated && "TODO: predicated instructions");
-
/* check version */
{
unsigned min = IS_VS ? info->vert_version.min : info->frag_version.min;
@@ -3353,12 +3383,30 @@ sm1_parse_instruction(struct shader_translator *tx)
sm1_dump_instruction(insn, tx->cond_depth + tx->loop_depth);
sm1_instruction_check(insn);
+if (insn->predicated) {
+tx->predicated_activated = true;
+if (ureg_dst_is_undef(tx->regs.predicate_tmp)) {
+tx->regs.predicate_tmp = ureg_DECL_temporary(tx->ureg);
+tx->regs.predicate_dst = ureg_DECL_temporary(tx->ureg);
+}
+}
+
if (info->handler)
hr = info->handler(tx);
else
hr = NineTranslateInstruction_Generic(tx);
tx_apply_dst0_modifiers(tx);
[Mesa-dev] [PATCH 01/22] st/nine: Add ff key hash to help debug
This is very useful to find in the log
the ff shader shource of a given call.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_ff.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/state_trackers/nine/nine_ff.c
b/src/gallium/state_trackers/nine/nine_ff.c
index 58cc29b5e30..e5b0c3e1258 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -1683,6 +1683,7 @@ nine_ff_get_vs(struct NineDevice9 *device)
key.tc_dim_output |= dim << (s * 3);
}
+DBG("VS ff key hash: %x\n", nine_ff_vs_key_hash(&key));
vs = util_hash_table_get(device->ff.ht_vs, &key);
if (vs)
return vs;
@@ -1836,6 +1837,7 @@ nine_ff_get_ps(struct NineDevice9 *device)
!(projection_matrix->_34 == 0.0f &&
projection_matrix->_44 == 1.0f);
+DBG("PS ff key hash: %x\n", nine_ff_ps_key_hash(&key));
ps = util_hash_table_get(device->ff.ht_ps, &key);
if (ps)
return ps;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/22] st/nine: Fix aliased read in ff
Fix aliasing of colorarg_b4 with colorarg_b5. Fixes: https://github.com/iXit/Mesa-3D/issues/302 Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/nine_ff.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/state_trackers/nine/nine_ff.c b/src/gallium/state_trackers/nine/nine_ff.c index 2cb5f080be8..453f280c9fc 100644 --- a/src/gallium/state_trackers/nine/nine_ff.c +++ b/src/gallium/state_trackers/nine/nine_ff.c @@ -1463,9 +1463,9 @@ nine_ff_build_ps(struct NineDevice9 *device, struct nine_ff_ps_key *key) ureg_MUL(ureg, ps.rMod, ps.rCurSrc, ps.rTexSrc); } -colorarg[0] = (key->ts[s].colorarg0 | ((key->colorarg_b4[0] >> s) << 4) | ((key->colorarg_b5[0] >> s) << 5)) & 0x3f; -colorarg[1] = (key->ts[s].colorarg1 | ((key->colorarg_b4[1] >> s) << 4) | ((key->colorarg_b5[1] >> s) << 5)) & 0x3f; -colorarg[2] = (key->ts[s].colorarg2 | ((key->colorarg_b4[2] >> s) << 4) | ((key->colorarg_b5[2] >> s) << 5)) & 0x3f; +colorarg[0] = (key->ts[s].colorarg0 | (((key->colorarg_b4[0] >> s) & 0x1) << 4) | ((key->colorarg_b5[0] >> s) << 5)) & 0x3f; +colorarg[1] = (key->ts[s].colorarg1 | (((key->colorarg_b4[1] >> s) & 0x1) << 4) | ((key->colorarg_b5[1] >> s) << 5)) & 0x3f; +colorarg[2] = (key->ts[s].colorarg2 | (((key->colorarg_b4[2] >> s) & 0x1) << 4) | ((key->colorarg_b5[2] >> s) << 5)) & 0x3f; alphaarg[0] = (key->ts[s].alphaarg0 | ((key->alphaarg_b4[0] >> s) << 4)) & 0x1f; alphaarg[1] = (key->ts[s].alphaarg1 | ((key->alphaarg_b4[1] >> s) << 4)) & 0x1f; alphaarg[2] = (key->ts[s].alphaarg2 | ((key->alphaarg_b4[2] >> s) << 4)) & 0x1f; -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/22] st/nine: Clarify some ff assignments
colorarg0, etc are 3 bits wide.
Make the code more readable by adding an & 0x7
to further indicate we only remember the first 3 bits only.
The 4th bit is always 0,
and colorarg_b4, colorarg_b5, etc are used to store
the 5th and 6th bits.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_ff.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_ff.c
b/src/gallium/state_trackers/nine/nine_ff.c
index e5b0c3e1258..c64085b2ac4 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -1765,9 +1765,9 @@ nine_ff_get_ps(struct NineDevice9 *device)
sampler_mask |= (1 << s);
if (key.ts[s].colorop != D3DTOP_DISABLE) {
-if (used_c & 0x1) key.ts[s].colorarg0 =
context->ff.tex_stage[s][D3DTSS_COLORARG0];
-if (used_c & 0x2) key.ts[s].colorarg1 =
context->ff.tex_stage[s][D3DTSS_COLORARG1];
-if (used_c & 0x4) key.ts[s].colorarg2 =
context->ff.tex_stage[s][D3DTSS_COLORARG2];
+if (used_c & 0x1) key.ts[s].colorarg0 =
context->ff.tex_stage[s][D3DTSS_COLORARG0] & 0x7;
+if (used_c & 0x2) key.ts[s].colorarg1 =
context->ff.tex_stage[s][D3DTSS_COLORARG1] & 0x7;
+if (used_c & 0x4) key.ts[s].colorarg2 =
context->ff.tex_stage[s][D3DTSS_COLORARG2] & 0x7;
if (used_c & 0x1) key.colorarg_b4[0] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG0] >> 4) << s;
if (used_c & 0x1) key.colorarg_b5[0] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG0] >> 5) << s;
if (used_c & 0x2) key.colorarg_b4[1] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG1] >> 4) << s;
@@ -1776,9 +1776,9 @@ nine_ff_get_ps(struct NineDevice9 *device)
if (used_c & 0x4) key.colorarg_b5[2] |=
(context->ff.tex_stage[s][D3DTSS_COLORARG2] >> 5) << s;
}
if (key.ts[s].alphaop != D3DTOP_DISABLE) {
-if (used_a & 0x1) key.ts[s].alphaarg0 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG0];
-if (used_a & 0x2) key.ts[s].alphaarg1 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG1];
-if (used_a & 0x4) key.ts[s].alphaarg2 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG2];
+if (used_a & 0x1) key.ts[s].alphaarg0 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG0] & 0x7;
+if (used_a & 0x2) key.ts[s].alphaarg1 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG1] & 0x7;
+if (used_a & 0x4) key.ts[s].alphaarg2 =
context->ff.tex_stage[s][D3DTSS_ALPHAARG2] & 0x7;
if (used_a & 0x1) key.alphaarg_b4[0] |=
(context->ff.tex_stage[s][D3DTSS_ALPHAARG0] >> 4) << s;
if (used_a & 0x2) key.alphaarg_b4[1] |=
(context->ff.tex_stage[s][D3DTSS_ALPHAARG1] >> 4) << s;
if (used_a & 0x4) key.alphaarg_b4[2] |=
(context->ff.tex_stage[s][D3DTSS_ALPHAARG2] >> 4) << s;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/22] st/nine: Remove clamping when mul_zero_wins
Tests show the clamping can be removed
when mul_zero_wins is supported.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_shader.c | 55 ---
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/gallium/state_trackers/nine/nine_shader.c
index 9e90da59597..5c33a6308c2 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -460,6 +460,7 @@ struct shader_translator
boolean shift_wpos;
boolean wpos_is_sysval;
boolean face_is_sysval_integer;
+boolean mul_zero_wins;
unsigned texcoord_sn;
struct sm1_instruction insn; /* current instruction */
@@ -2293,15 +2294,46 @@ DECL_SPECIAL(POW)
return D3D_OK;
}
+/* Tests results on Win 10:
+ * NV (NVIDIA GeForce GT 635M)
+ * AMD (AMD Radeon HD 7730M)
+ * INTEL (Intel(R) HD Graphics 4000)
+ * PS2 and PS3:
+ * RCP and RSQ can generate inf on NV and AMD.
+ * RCP and RSQ are clamped on INTEL (+- FLT_MAX),
+ * NV: log not clamped
+ * AMD: log(0) is -FLT_MAX (but log(inf) is inf)
+ * INTEL: log(0) is -FLT_MAX and log(inf) is 127
+ * All devices have 0*anything = 0
+ *
+ * INTEL VS2 and VS3: same behaviour.
+ * Some differences VS2 and VS3 for constants defined with inf/NaN.
+ * While PS3, VS3 and PS2 keep NaN and Inf shader constants without change,
+ * VS2 seems to clamp to zero (may be test failure).
+ * AMD VS2: unknown, VS3: very likely behaviour of PS3
+ * NV VS2 and VS3: very likely behaviour of PS3
+ * For both, Inf in VS becomes NaN is PS
+ * "Very likely" because the test was less extensive.
+ *
+ * Thus all clamping can be removed for shaders 2 and 3,
+ * as long as 0*anything = 0.
+ * Else clamps to enforce 0*anything = 0 (anything being then
+ * neither inf or NaN, the user being unlikely to pass them
+ * as constant).
+ * The status for VS1 and PS1 is unknown.
+ */
+
DECL_SPECIAL(RCP)
{
struct ureg_program *ureg = tx->ureg;
struct ureg_dst dst = tx_dst_param(tx, &tx->insn.dst[0]);
struct ureg_src src = tx_src_param(tx, &tx->insn.src[0]);
-struct ureg_dst tmp = tx_scratch(tx);
+struct ureg_dst tmp = tx->mul_zero_wins ? dst : tx_scratch(tx);
ureg_RCP(ureg, tmp, src);
-ureg_MIN(ureg, tmp, ureg_imm1f(ureg, FLT_MAX), ureg_src(tmp));
-ureg_MAX(ureg, dst, ureg_imm1f(ureg, -FLT_MAX), ureg_src(tmp));
+if (!tx->mul_zero_wins) {
+ureg_MIN(ureg, tmp, ureg_imm1f(ureg, FLT_MAX), ureg_src(tmp));
+ureg_MAX(ureg, dst, ureg_imm1f(ureg, -FLT_MAX), ureg_src(tmp));
+}
return D3D_OK;
}
@@ -2310,9 +2342,10 @@ DECL_SPECIAL(RSQ)
struct ureg_program *ureg = tx->ureg;
struct ureg_dst dst = tx_dst_param(tx, &tx->insn.dst[0]);
struct ureg_src src = tx_src_param(tx, &tx->insn.src[0]);
-struct ureg_dst tmp = tx_scratch(tx);
+struct ureg_dst tmp = tx->mul_zero_wins ? dst : tx_scratch(tx);
ureg_RSQ(ureg, tmp, ureg_abs(src));
-ureg_MIN(ureg, dst, ureg_imm1f(ureg, FLT_MAX), ureg_src(tmp));
+if (!tx->mul_zero_wins)
+ureg_MIN(ureg, dst, ureg_imm1f(ureg, FLT_MAX), ureg_src(tmp));
return D3D_OK;
}
@@ -2323,7 +2356,11 @@ DECL_SPECIAL(LOG)
struct ureg_dst dst = tx_dst_param(tx, &tx->insn.dst[0]);
struct ureg_src src = tx_src_param(tx, &tx->insn.src[0]);
ureg_LG2(ureg, tmp, ureg_abs(src));
-ureg_MAX(ureg, dst, ureg_imm1f(ureg, -FLT_MAX), tx_src_scalar(tmp));
+if (tx->mul_zero_wins) {
+ureg_MOV(ureg, dst, tx_src_scalar(tmp));
+} else {
+ureg_MAX(ureg, dst, ureg_imm1f(ureg, -FLT_MAX), tx_src_scalar(tmp));
+}
return D3D_OK;
}
@@ -2353,7 +2390,8 @@ DECL_SPECIAL(NRM)
struct ureg_src src = tx_src_param(tx, &tx->insn.src[0]);
ureg_DP3(ureg, tmp, src, src);
ureg_RSQ(ureg, tmp, nrm);
-ureg_MIN(ureg, tmp, ureg_imm1f(ureg, FLT_MAX), nrm);
+if (!tx->mul_zero_wins)
+ureg_MIN(ureg, tmp, ureg_imm1f(ureg, FLT_MAX), nrm);
ureg_MUL(ureg, dst, src, nrm);
return D3D_OK;
}
@@ -3637,7 +3675,8 @@ nine_translate_shader(struct NineDevice9 *device, struct
nine_shader_info *info,
ureg_property(tx->ureg, TGSI_PROPERTY_FS_COORD_PIXEL_CENTER,
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
}
-if (GET_CAP(TGSI_MUL_ZERO_WINS))
+tx->mul_zero_wins = GET_CAP(TGSI_MUL_ZERO_WINS);
+if (tx->mul_zero_wins)
ureg_property(tx->ureg, TGSI_PROPERTY_MUL_ZERO_WINS, 1);
while (!sm1_parse_eof(tx) && !tx->failure)
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/ir: fix link-time build failure
Seems this fixes linking problems that occur in some situations.
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 0cbf4d071f..295497be2f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1732,7 +1732,7 @@ NVC0LoweringPass::loadSuInfo32(Value *ptr, int slot,
uint32_t off, bool bindless
prog->driver->io.suInfoBase);
}
-inline Value *
+Value *
NVC0LoweringPass::loadMsAdjInfo32(TexInstruction::Target target, uint32_t
index, int slot, Value *ind, bool bindless)
{
if (!bindless || targ->getChipset() < NVISA_GM107_CHIPSET)
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] radeonsi: don't set the VS prolog key for the blit VS
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 157a0e3..0bf783f 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1187,21 +1187,22 @@ static unsigned si_get_alpha_test_func(struct
si_context *sctx)
return sctx->queued.named.dsa->alpha_func;
return PIPE_FUNC_ALWAYS;
}
static void si_shader_selector_key_vs(struct si_context *sctx,
struct si_shader_selector *vs,
struct si_shader_key *key,
struct si_vs_prolog_bits *prolog_key)
{
- if (!sctx->vertex_elements)
+ if (!sctx->vertex_elements ||
+ vs->info.properties[TGSI_PROPERTY_VS_BLIT_SGPRS])
return;
prolog_key->instance_divisor_is_one =
sctx->vertex_elements->instance_divisor_is_one;
prolog_key->instance_divisor_is_fetched =
sctx->vertex_elements->instance_divisor_is_fetched;
/* Prefer a monolithic shader to allow scheduling divisions around
* VBO loads. */
if (prolog_key->instance_divisor_is_fetched)
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] radeonsi: initialize ac_gpu_info::name when using SI_FORCE_FAMILY
From: Marek Olšák
so that it's not NULL when loading radeonsi and a GCN GPU is not
present in the system.
---
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 0b38feb..0955c9f 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -704,20 +704,21 @@ static void si_handle_env_var_force_family(struct
si_screen *sscreen)
const char *family = debug_get_option("SI_FORCE_FAMILY", NULL);
unsigned i;
if (!family)
return;
for (i = CHIP_TAHITI; i < CHIP_LAST; i++) {
if (!strcmp(family, ac_get_llvm_processor_name(i))) {
/* Override family and chip_class. */
sscreen->info.family = i;
+ sscreen->info.name = "GCN-NOOP";
if (i >= CHIP_VEGA10)
sscreen->info.chip_class = GFX9;
else if (i >= CHIP_TONGA)
sscreen->info.chip_class = VI;
else if (i >= CHIP_BONAIRE)
sscreen->info.chip_class = CIK;
else
sscreen->info.chip_class = SI;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] ac: add helpers for fast integer division by a constant
From: Marek Olšák
---
src/amd/common/ac_llvm_build.c | 44 ++
src/amd/common/ac_llvm_build.h | 13 +
2 files changed, 57 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index ab0ba09..793ff81 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -571,20 +571,64 @@ ac_build_fdiv(struct ac_llvm_context *ctx,
*/
LLVMValueRef rcp = LLVMBuildFDiv(ctx->builder, ctx->f32_1, den, "");
LLVMValueRef ret = LLVMBuildFMul(ctx->builder, num, rcp, "");
/* Use v_rcp_f32 instead of precise division. */
if (!LLVMIsConstant(ret))
LLVMSetMetadata(ret, ctx->fpmath_md_kind,
ctx->fpmath_md_2p5_ulp);
return ret;
}
+/* See fast_idiv_by_const.h. */
+/* Set: increment = util_fast_udiv_info::increment ? multiplier : 0; */
+LLVMValueRef ac_build_fast_udiv(struct ac_llvm_context *ctx,
+ LLVMValueRef num,
+ LLVMValueRef multiplier,
+ LLVMValueRef pre_shift,
+ LLVMValueRef post_shift,
+ LLVMValueRef increment)
+{
+ LLVMBuilderRef builder = ctx->builder;
+
+ num = LLVMBuildLShr(builder, num, pre_shift, "");
+ num = LLVMBuildMul(builder,
+ LLVMBuildZExt(builder, num, ctx->i64, ""),
+ LLVMBuildZExt(builder, multiplier, ctx->i64, ""),
"");
+ num = LLVMBuildAdd(builder, num,
+ LLVMBuildZExt(builder, increment, ctx->i64, ""), "");
+ num = LLVMBuildLShr(builder, num, LLVMConstInt(ctx->i64, 32, 0), "");
+ num = LLVMBuildTrunc(builder, num, ctx->i32, "");
+ return LLVMBuildLShr(builder, num, post_shift, "");
+}
+
+/* See fast_idiv_by_const.h. */
+/* If num != UINT_MAX, this more efficient version can be used. */
+/* Set: increment = util_fast_udiv_info::increment; */
+LLVMValueRef ac_build_fast_udiv_nuw(struct ac_llvm_context *ctx,
+ LLVMValueRef num,
+ LLVMValueRef multiplier,
+ LLVMValueRef pre_shift,
+ LLVMValueRef post_shift,
+ LLVMValueRef increment)
+{
+ LLVMBuilderRef builder = ctx->builder;
+
+ num = LLVMBuildLShr(builder, num, pre_shift, "");
+ num = LLVMBuildNUWAdd(builder, num, increment, "");
+ num = LLVMBuildMul(builder,
+ LLVMBuildZExt(builder, num, ctx->i64, ""),
+ LLVMBuildZExt(builder, multiplier, ctx->i64, ""),
"");
+ num = LLVMBuildLShr(builder, num, LLVMConstInt(ctx->i64, 32, 0), "");
+ num = LLVMBuildTrunc(builder, num, ctx->i32, "");
+ return LLVMBuildLShr(builder, num, post_shift, "");
+}
+
/* Coordinates for cube map selection. sc, tc, and ma are as in Table 8.27
* of the OpenGL 4.5 (Compatibility Profile) specification, except ma is
* already multiplied by two. id is the cube face number.
*/
struct cube_selection_coords {
LLVMValueRef stc[2];
LLVMValueRef ma;
LLVMValueRef id;
};
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 0df9234..722faad 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -172,20 +172,33 @@ ac_build_gather_values(struct ac_llvm_context *ctx,
unsigned value_count);
LLVMValueRef ac_build_expand_to_vec4(struct ac_llvm_context *ctx,
LLVMValueRef value,
unsigned num_channels);
LLVMValueRef
ac_build_fdiv(struct ac_llvm_context *ctx,
LLVMValueRef num,
LLVMValueRef den);
+LLVMValueRef ac_build_fast_udiv(struct ac_llvm_context *ctx,
+ LLVMValueRef num,
+ LLVMValueRef multiplier,
+ LLVMValueRef pre_shift,
+ LLVMValueRef post_shift,
+ LLVMValueRef increment);
+LLVMValueRef ac_build_fast_udiv_nuw(struct ac_llvm_context *ctx,
+ LLVMValueRef num,
+ LLVMValueRef multiplier,
+ LLVMValueRef pre_shift,
+ LLVMValueRef post_shift,
+ LLVMValueRef increment);
+
void
ac_prepare_cube_coords(struct ac_llvm_context *ctx,
bool is_deriv, bool is_array, bool is_lod,
LLVMValueRef *coords_arg,
LLVMValueRef *derivs_arg);
LLVMValueRef
ac_build_fs_interp(struct ac_llvm_context *ctx,
LLVMValueRef llvm_chan,
--
2.7.4
___
mesa-dev mailin
[Mesa-dev] [PATCH 3/5] radeonsi: use faster integer division for instance divisors
From: Marek Olšák
We know the divisors when we upload them, so instead we can precompute
and upload division factors derived from each divisor.
This fast division consists of add, mul_hi, and two shifts,
and we have to load 4 dwords intead of 1.
This probably won't affect any apps.
---
src/gallium/drivers/radeonsi/si_shader.c | 46 +++-
src/gallium/drivers/radeonsi/si_state.c | 42 -
src/gallium/drivers/radeonsi/si_state.h | 2 +-
3 files changed, 57 insertions(+), 33 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 36f58e2..90cb059 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -421,34 +421,20 @@ static LLVMValueRef get_tcs_in_vertex_dw_stride(struct
si_shader_context *ctx)
return LLVMConstInt(ctx->i32, stride, 0);
}
return si_unpack_param(ctx, ctx->param_vs_state_bits, 24, 8);
default:
assert(0);
return NULL;
}
}
-static LLVMValueRef get_instance_index_for_fetch(
- struct si_shader_context *ctx,
- unsigned param_start_instance, LLVMValueRef divisor)
-{
- LLVMValueRef result = ctx->abi.instance_id;
-
- /* The division must be done before START_INSTANCE is added. */
- if (divisor != ctx->i32_1)
- result = LLVMBuildUDiv(ctx->ac.builder, result, divisor, "");
-
- return LLVMBuildAdd(ctx->ac.builder, result,
- LLVMGetParam(ctx->main_fn, param_start_instance),
"");
-}
-
/* Bitcast <4 x float> to <2 x double>, extract the component, and convert
* to float. */
static LLVMValueRef extract_double_to_float(struct si_shader_context *ctx,
LLVMValueRef vec4,
unsigned double_index)
{
LLVMBuilderRef builder = ctx->ac.builder;
LLVMTypeRef f64 = LLVMDoubleTypeInContext(ctx->ac.context);
LLVMValueRef dvec2 = LLVMBuildBitCast(builder, vec4,
LLVMVectorType(f64, 2), "");
@@ -7294,34 +7280,44 @@ static void si_build_vs_prolog_function(struct
si_shader_context *ctx,
ac_build_load_to_sgpr(&ctx->ac, list, buf_index);
}
for (i = 0; i <= key->vs_prolog.last_input; i++) {
bool divisor_is_one =
key->vs_prolog.states.instance_divisor_is_one & (1u <<
i);
bool divisor_is_fetched =
key->vs_prolog.states.instance_divisor_is_fetched & (1u
<< i);
LLVMValueRef index;
- if (divisor_is_one || divisor_is_fetched) {
- LLVMValueRef divisor = ctx->i32_1;
+ if (divisor_is_one) {
+ index = ctx->abi.instance_id;
+ } else if (divisor_is_fetched) {
+ LLVMValueRef udiv_factors[4];
- if (divisor_is_fetched) {
- divisor = buffer_load_const(ctx,
instance_divisor_constbuf,
-
LLVMConstInt(ctx->i32, i * 4, 0));
- divisor = ac_to_integer(&ctx->ac, divisor);
+ for (unsigned j = 0; j < 4; j++) {
+ udiv_factors[j] =
+ buffer_load_const(ctx,
instance_divisor_constbuf,
+
LLVMConstInt(ctx->i32, i*16 + j*4, 0));
+ udiv_factors[j] = ac_to_integer(&ctx->ac,
udiv_factors[j]);
}
+ /* The faster NUW version doesn't work when InstanceID
== UINT_MAX.
+* Such InstanceID might not be achievable in a
reasonable time though.
+*/
+ index = ac_build_fast_udiv_nuw(&ctx->ac,
ctx->abi.instance_id,
+ udiv_factors[0],
udiv_factors[1],
+ udiv_factors[2],
udiv_factors[3]);
+ }
- /* InstanceID / Divisor + StartInstance */
- index = get_instance_index_for_fetch(ctx,
-user_sgpr_base +
-
SI_SGPR_START_INSTANCE,
-divisor);
+ if (divisor_is_one || divisor_is_fetched) {
+ /* Add StartInstance. */
+ index = LLVMBuildAdd(ctx->ac.builder, index,
+LLVMGetParam(ctx->main_fn,
user_sgpr_base +
+
[Mesa-dev] [PATCH 1/5] util: import public domain code for integer division by a constant
From: Marek Olšák
Compilers can use this to generate optimal code for integer division
by a constant.
Additionally, an unsigned division by a uniform that is constant but not
known at compile time can still be optimized by passing 2-4 division
factors to the shader as uniforms and executing one of the fast_udiv*
variants. The signed division algorithm doesn't have this capability.
---
src/util/Makefile.sources | 2 +
src/util/fast_idiv_by_const.c | 245 ++
src/util/fast_idiv_by_const.h | 173 +
src/util/meson.build | 2 +
4 files changed, 422 insertions(+)
create mode 100644 src/util/fast_idiv_by_const.c
create mode 100644 src/util/fast_idiv_by_const.h
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index b562d6c..f741b2a 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -3,20 +3,22 @@ MESA_UTIL_FILES := \
bitscan.h \
bitset.h \
build_id.c \
build_id.h \
crc32.c \
crc32.h \
debug.c \
debug.h \
disk_cache.c \
disk_cache.h \
+ fast_idiv_by_const.c \
+ fast_idiv_by_const.h \
format_r11g11b10f.h \
format_rgb9e5.h \
format_srgb.h \
futex.h \
half_float.c \
half_float.h \
hash_table.c \
hash_table.h \
list.h \
macros.h \
diff --git a/src/util/fast_idiv_by_const.c b/src/util/fast_idiv_by_const.c
new file mode 100644
index 000..f247b66
--- /dev/null
+++ b/src/util/fast_idiv_by_const.c
@@ -0,0 +1,245 @@
+/*
+ * Copyright © 2018 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/* Imported from:
+ *
https://raw.githubusercontent.com/ridiculousfish/libdivide/master/divide_by_constants_codegen_reference.c
+ * Paper:
+ * http://ridiculousfish.com/files/faster_unsigned_division_by_constants.pdf
+ *
+ * The author, ridiculous_fish, wrote:
+ *
+ * ''Reference implementations of computing and using the "magic number"
+ *approach to dividing by constants, including codegen instructions.
+ *The unsigned division incorporates the "round down" optimization per
+ *ridiculous_fish.
+ *
+ *This is free and unencumbered software. Any copyright is dedicated
+ *to the Public Domain.''
+ */
+
+#include "fast_idiv_by_const.h"
+#include "u_math.h"
+#include
+#include
+
+/* uint_t and sint_t can be replaced by different integer types and the code
+ * will work as-is. The only requirement is that sizeof(uintN) == sizeof(intN).
+ */
+
+struct util_fast_udiv_info
+util_compute_fast_udiv_info(uint_t D, unsigned num_bits)
+{
+ /* The numerator must fit in a uint_t */
+ assert(num_bits > 0 && num_bits <= sizeof(uint_t) * CHAR_BIT);
+ assert(D != 0);
+
+ /* The eventual result */
+ struct util_fast_udiv_info result;
+
+ if (util_is_power_of_two_nonzero(D)) {
+ unsigned div_shift = util_logbase2(D);
+
+ if (div_shift) {
+ /* Dividing by a power of two. */
+ result.multiplier = 1 << 31;
+ result.pre_shift = 0;
+ result.post_shift = div_shift - 1;
+ result.increment = 0;
+ return result;
+ } else {
+ /* Dividing by 1. */
+ /* Assuming: floor((num + 1) * (2^32 - 1) / 2^32) = num */
+ result.multiplier = UINT_MAX;
+ result.pre_shift = 0;
+ result.post_shift = 0;
+ result.increment = 1;
+ return result;
+ }
+ }
+
+ /* Bits in a uint_t */
+ const unsigned UINT_BITS = sizeof(uint_t) * CHAR_BIT;
+
+ /* The extra shift implicit in the difference between UINT_BITS and num_bits
+*/
+ const unsigned extra_shift = UINT_BITS - num_bits;
+
+ /* The initial power of 2 is one less than the first one that can possibly
+* work.
+*/
+ const uint_t initial_power_of_2 = (uint_t)1
Re: [Mesa-dev] [PATCH] anv,radv: Implement vkAcquireNextImage2
On September 23, 2018 16:17:36 Emil Velikov wrote: Hi Jason, On 20 September 2018 at 11:33, Jason Ekstrand wrote: This was added as part of 1.1 but it's very hard to track exactly what extension added it. In any case, we should implement it. A small question while skimming through I think we'd want this alongside 59a8e0dbf855d390e96a88d859f0d120dfc34404 in the stable branches, right? IIRC Vulkan 1.1 landed back in 18.1.0 with commit d6b65222df53677e5d3b2f6f42163387725d57b8 Yes, we should. I thought I CCd stable when I pushed but I may have forgotten. Yes, it would be good to back-port --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Clarify Fixes tag behavior for stable branches.
On 23 September 2018 at 15:40, Bas Nieuwenhuizen wrote: > On Sun, Sep 23, 2018 at 4:34 PM Emil Velikov wrote: >> >> On 23 September 2018 at 15:28, Bas Nieuwenhuizen >> wrote: >> > This seems to be the current state of affairs. Emil has plans to >> > get feedback about it and possibly change it, but let us put this >> > in the documentation now in case that gets delayed or cancelled. >> > >> > This should clarify the misunderstanding which started >> > >> > https://lists.freedesktop.org/archives/mesa-dev/2018-September/205696.html >> > >> > Signed-off-by: Bas Nieuwenhuizen >> > CC: Emil Velikov >> > --- >> > >> > Seems like some release managers also consistently notify on rejected >> > Fixes patches, >> > but I don't think we should encode behavior of different release managers >> > in the >> > documentation, so this seems like the safe choice. >> > >> I think it's crucial that there's consistency and clarity of what we do. >> >> > docs/submittingpatches.html | 4 +++- >> > 1 file changed, 3 insertions(+), 1 deletion(-) >> > >> > diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html >> > index e5350bdb2cf..144e00d677b 100644 >> > --- a/docs/submittingpatches.html >> > +++ b/docs/submittingpatches.html >> > @@ -284,7 +284,9 @@ Thus, drop the line only if you want >> > to cancel the nomination. >> > >> > Alternatively, if one uses the "Fixes" tag as described in the "Patch >> > formatting" >> > section, it nominates a commit for all active stable branches that >> > include the >> > -commit that is referred to. >> > +commit that is referred to. However, this is only an implicit nomination >> > and the >> > +release manager can decide to reject your patch without replying to the >> > original >> > +patch or asking for a backport. >> > >> We can have this temporary, but I'd argue that silently dropping >> things is a bad idea. > > Totally agreed, the question here is whether there is value in > documenting our current process with the listed shortcomings. If yes, > this patch is IMO it, if not I'll drop it. Since this is what others have been doing - let's get this merged as-is. But we should sit down and clarify things this week. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Clarify Fixes tag behavior for stable branches.
On Sun, Sep 23, 2018 at 4:34 PM Emil Velikov wrote: > > On 23 September 2018 at 15:28, Bas Nieuwenhuizen > wrote: > > This seems to be the current state of affairs. Emil has plans to > > get feedback about it and possibly change it, but let us put this > > in the documentation now in case that gets delayed or cancelled. > > > > This should clarify the misunderstanding which started > > > > https://lists.freedesktop.org/archives/mesa-dev/2018-September/205696.html > > > > Signed-off-by: Bas Nieuwenhuizen > > CC: Emil Velikov > > --- > > > > Seems like some release managers also consistently notify on rejected Fixes > > patches, > > but I don't think we should encode behavior of different release managers > > in the > > documentation, so this seems like the safe choice. > > > I think it's crucial that there's consistency and clarity of what we do. > > > docs/submittingpatches.html | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html > > index e5350bdb2cf..144e00d677b 100644 > > --- a/docs/submittingpatches.html > > +++ b/docs/submittingpatches.html > > @@ -284,7 +284,9 @@ Thus, drop the line only if you want > > to cancel the nomination. > > > > Alternatively, if one uses the "Fixes" tag as described in the "Patch > > formatting" > > section, it nominates a commit for all active stable branches that include > > the > > -commit that is referred to. > > +commit that is referred to. However, this is only an implicit nomination > > and the > > +release manager can decide to reject your patch without replying to the > > original > > +patch or asking for a backport. > > > We can have this temporary, but I'd argue that silently dropping > things is a bad idea. Totally agreed, the question here is whether there is value in documenting our current process with the listed shortcomings. If yes, this patch is IMO it, if not I'll drop it. > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Clarify Fixes tag behavior for stable branches.
On 23 September 2018 at 15:28, Bas Nieuwenhuizen wrote: > This seems to be the current state of affairs. Emil has plans to > get feedback about it and possibly change it, but let us put this > in the documentation now in case that gets delayed or cancelled. > > This should clarify the misunderstanding which started > > https://lists.freedesktop.org/archives/mesa-dev/2018-September/205696.html > > Signed-off-by: Bas Nieuwenhuizen > CC: Emil Velikov > --- > > Seems like some release managers also consistently notify on rejected Fixes > patches, > but I don't think we should encode behavior of different release managers in > the > documentation, so this seems like the safe choice. > I think it's crucial that there's consistency and clarity of what we do. > docs/submittingpatches.html | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html > index e5350bdb2cf..144e00d677b 100644 > --- a/docs/submittingpatches.html > +++ b/docs/submittingpatches.html > @@ -284,7 +284,9 @@ Thus, drop the line only if you want to > cancel the nomination. > > Alternatively, if one uses the "Fixes" tag as described in the "Patch > formatting" > section, it nominates a commit for all active stable branches that include > the > -commit that is referred to. > +commit that is referred to. However, this is only an implicit nomination and > the > +release manager can decide to reject your patch without replying to the > original > +patch or asking for a backport. > We can have this temporary, but I'd argue that silently dropping things is a bad idea. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: Clarify Fixes tag behavior for stable branches.
This seems to be the current state of affairs. Emil has plans to get feedback about it and possibly change it, but let us put this in the documentation now in case that gets delayed or cancelled. This should clarify the misunderstanding which started https://lists.freedesktop.org/archives/mesa-dev/2018-September/205696.html Signed-off-by: Bas Nieuwenhuizen CC: Emil Velikov --- Seems like some release managers also consistently notify on rejected Fixes patches, but I don't think we should encode behavior of different release managers in the documentation, so this seems like the safe choice. docs/submittingpatches.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index e5350bdb2cf..144e00d677b 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -284,7 +284,9 @@ Thus, drop the line only if you want to cancel the nomination. Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting" section, it nominates a commit for all active stable branches that include the -commit that is referred to. +commit that is referred to. However, this is only an implicit nomination and the +release manager can decide to reject your patch without replying to the original +patch or asking for a backport. Criteria for accepting patches to the stable branch -- 2.19.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv,radv: Implement vkAcquireNextImage2
Hi Jason, On 20 September 2018 at 11:33, Jason Ekstrand wrote: > This was added as part of 1.1 but it's very hard to track exactly what > extension added it. In any case, we should implement it. > A small question while skimming through I think we'd want this alongside 59a8e0dbf855d390e96a88d859f0d120dfc34404 in the stable branches, right? IIRC Vulkan 1.1 landed back in 18.1.0 with commit d6b65222df53677e5d3b2f6f42163387725d57b8 -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On 23 September 2018 at 14:53, Bas Nieuwenhuizen wrote: > On Sun, Sep 23, 2018 at 3:42 PM Emil Velikov wrote: >> >> On 21 September 2018 at 17:49, Dylan Baker wrote: >> > Quoting Emil Velikov (2018-09-21 09:07:58) >> >> On 21 September 2018 at 16:55, Dylan Baker wrote: >> >> > Quoting Emil Velikov (2018-09-21 08:47:30) >> >> >> On 21 September 2018 at 08:19, Juan A. Suarez Romero >> >> >> wrote: >> >> >> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: >> >> >> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: >> >> >> >> > > Was missing the init, found by Emil. >> >> >> >> > > >> >> >> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache >> >> >> >> > > UUID." >> >> >> >> > >> >> >> >> > Reviewed-by: Eric Engestrom >> >> >> >> > >> >> >> >> > > CC: >> >> >> >> > >> >> >> >> > Cc'ing mesa-stable has no effect when you're already adding the >> >> >> >> > proper Fixes: tag :) >> >> >> >> >> >> >> >> Last time I asked about the difference between Fixes and CC, the >> >> >> >> conclusion I got that Fixes is only best effort for the stable >> >> >> >> branches and that if it does not apply it will be dropped silently, >> >> >> >> while for the CC ones the release manager will notify you. >> >> >> >> >> >> >> > >> >> >> > In previous releases that was the way it worked: we always our best >> >> >> > effort to >> >> >> > apply CC and Fixes patches. The difference was that if we couldn't >> >> >> > apply the >> >> >> > patch, then we were only notifying in the pre-announcement >> >> >> > "Rejected" section >> >> >> > about the CC, and silently ignoring the Fixes. >> >> >> > >> >> >> > >> >> >> > But nowadays, we notify about all the candidates to stable, which >> >> >> > are CC and >> >> >> > Fixes. >> >> >> > >> >> >> Here is an alternative wording, hopefully it will make things clearer: >> >> >> >> >> >> Both CC and Fixes work and having both does not hurt. >> >> >> >> >> >> Fixes provides clear indication when/where the problem originates. >> >> >> Cc _explicitly_ requests the patch to be in stable - that's why we >> >> >> have the list + late nominations. >> >> >> >> >> >> It _explicit_ nomination does _not_ apply then the nominator is >> >> >> informed. >> >> >> >> >> >> -Emil >> >> > >> >> > Yeah, that's not useful. We don't need a "you can put this in if you >> >> > want but >> >> > don't tell me if you didn't". Either it's nominated or it's not. If >> >> > Fixes: >> >> > doesn't mean "I want this in any stable branch with commit X" then we >> >> > should >> >> > stop using the tag. >> >> > >> >> Fixes means "I want this _anywhere_ with commit X". No idea how you >> >> read my comment otherwise ;-) >> >> >> >> -Emil >> > >> > Where you said CC is _explicit_ but fixes isn't. Having two ways to do the >> > same >> > thing that are subtly different seems like a bad idea to me. >> > >> > I'm going to admit this is just another reason that I feel like our whole >> > stable >> > process is rather fragile and tedious. We have three ways to nominate a >> > patch >> > that are all subtly different, but those differences are not clearly >> > documented. >> >> Keep in mind that before I started the documentation was a mere >> fraction of what it is today. >> As I said multiple times if something is unclear - ask _and_ send >> patches to clarify the documentation. >> >> Sadly close to no patches appear :-( > > I'm happy to send patches to clarify the documentation once this > discussion is through. However, I'm not sure how to reconcile your > statements though: > > "Both CC and Fixes work and having both does not hurt. > > Fixes provides clear indication when/where the problem originates. > Cc _explicitly_ requests the patch to be in stable - that's why we > have the list + late nominations. > > It _explicit_ nomination does _not_ apply then the nominator is informed." > > which seems to say that patches with only "Fixes:" can get rejected > silently. (which would match Juan's old answer in > https://lists.freedesktop.org/archives/mesa-stable/2018-April/008072.html) > I _really_ should have read that clearer. I have no recollection of a Fixes patch which was rejected, might may have brought some confusion on my end. > vs. > > "As a TL;DR _nothing_ is rejected silently ;-)" > > which seems to say that patches with only "Fixes:" can not get > rejected silently. (which matches what Dylan is saying) > > While documentation can help prevent future confusion/discussion on > this topic, which way should the documentation go, as these two > statements seem to contradict each other to me. > Agreed. I will be mentioning a thing or two about the history what things mean (from my POV that is) and why in a couple of days at XDC. After that I'm planning to gather feedback from everyone so we can adjust things accordingly. -Emil __
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On Sun, Sep 23, 2018 at 3:42 PM Emil Velikov wrote: > > On 21 September 2018 at 17:49, Dylan Baker wrote: > > Quoting Emil Velikov (2018-09-21 09:07:58) > >> On 21 September 2018 at 16:55, Dylan Baker wrote: > >> > Quoting Emil Velikov (2018-09-21 08:47:30) > >> >> On 21 September 2018 at 08:19, Juan A. Suarez Romero > >> >> wrote: > >> >> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: > >> >> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom > >> >> >> wrote: > >> >> >> > > >> >> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: > >> >> >> > > Was missing the init, found by Emil. > >> >> >> > > > >> >> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache > >> >> >> > > UUID." > >> >> >> > > >> >> >> > Reviewed-by: Eric Engestrom > >> >> >> > > >> >> >> > > CC: > >> >> >> > > >> >> >> > Cc'ing mesa-stable has no effect when you're already adding the > >> >> >> > proper Fixes: tag :) > >> >> >> > >> >> >> Last time I asked about the difference between Fixes and CC, the > >> >> >> conclusion I got that Fixes is only best effort for the stable > >> >> >> branches and that if it does not apply it will be dropped silently, > >> >> >> while for the CC ones the release manager will notify you. > >> >> >> > >> >> > > >> >> > In previous releases that was the way it worked: we always our best > >> >> > effort to > >> >> > apply CC and Fixes patches. The difference was that if we couldn't > >> >> > apply the > >> >> > patch, then we were only notifying in the pre-announcement "Rejected" > >> >> > section > >> >> > about the CC, and silently ignoring the Fixes. > >> >> > > >> >> > > >> >> > But nowadays, we notify about all the candidates to stable, which are > >> >> > CC and > >> >> > Fixes. > >> >> > > >> >> Here is an alternative wording, hopefully it will make things clearer: > >> >> > >> >> Both CC and Fixes work and having both does not hurt. > >> >> > >> >> Fixes provides clear indication when/where the problem originates. > >> >> Cc _explicitly_ requests the patch to be in stable - that's why we > >> >> have the list + late nominations. > >> >> > >> >> It _explicit_ nomination does _not_ apply then the nominator is > >> >> informed. > >> >> > >> >> -Emil > >> > > >> > Yeah, that's not useful. We don't need a "you can put this in if you > >> > want but > >> > don't tell me if you didn't". Either it's nominated or it's not. If > >> > Fixes: > >> > doesn't mean "I want this in any stable branch with commit X" then we > >> > should > >> > stop using the tag. > >> > > >> Fixes means "I want this _anywhere_ with commit X". No idea how you > >> read my comment otherwise ;-) > >> > >> -Emil > > > > Where you said CC is _explicit_ but fixes isn't. Having two ways to do the > > same > > thing that are subtly different seems like a bad idea to me. > > > > I'm going to admit this is just another reason that I feel like our whole > > stable > > process is rather fragile and tedious. We have three ways to nominate a > > patch > > that are all subtly different, but those differences are not clearly > > documented. > > Keep in mind that before I started the documentation was a mere > fraction of what it is today. > As I said multiple times if something is unclear - ask _and_ send > patches to clarify the documentation. > > Sadly close to no patches appear :-( I'm happy to send patches to clarify the documentation once this discussion is through. However, I'm not sure how to reconcile your statements though: "Both CC and Fixes work and having both does not hurt. Fixes provides clear indication when/where the problem originates. Cc _explicitly_ requests the patch to be in stable - that's why we have the list + late nominations. It _explicit_ nomination does _not_ apply then the nominator is informed." which seems to say that patches with only "Fixes:" can get rejected silently. (which would match Juan's old answer in https://lists.freedesktop.org/archives/mesa-stable/2018-April/008072.html) vs. "As a TL;DR _nothing_ is rejected silently ;-)" which seems to say that patches with only "Fixes:" can not get rejected silently. (which matches what Dylan is saying) While documentation can help prevent future confusion/discussion on this topic, which way should the documentation go, as these two statements seem to contradict each other to me. > > Our thinking, and hence expressions vary, so I'm more than happy to > change the docs so that they are better suited for a wider audience. > > As a TL;DR _nothing_ is rejected silently ;-) > > -Emil > ___ > 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] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On 21 September 2018 at 17:49, Dylan Baker wrote: > Quoting Emil Velikov (2018-09-21 09:07:58) >> On 21 September 2018 at 16:55, Dylan Baker wrote: >> > Quoting Emil Velikov (2018-09-21 08:47:30) >> >> On 21 September 2018 at 08:19, Juan A. Suarez Romero >> >> wrote: >> >> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: >> >> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom >> >> >> wrote: >> >> >> > >> >> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: >> >> >> > > Was missing the init, found by Emil. >> >> >> > > >> >> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache >> >> >> > > UUID." >> >> >> > >> >> >> > Reviewed-by: Eric Engestrom >> >> >> > >> >> >> > > CC: >> >> >> > >> >> >> > Cc'ing mesa-stable has no effect when you're already adding the >> >> >> > proper Fixes: tag :) >> >> >> >> >> >> Last time I asked about the difference between Fixes and CC, the >> >> >> conclusion I got that Fixes is only best effort for the stable >> >> >> branches and that if it does not apply it will be dropped silently, >> >> >> while for the CC ones the release manager will notify you. >> >> >> >> >> > >> >> > In previous releases that was the way it worked: we always our best >> >> > effort to >> >> > apply CC and Fixes patches. The difference was that if we couldn't >> >> > apply the >> >> > patch, then we were only notifying in the pre-announcement "Rejected" >> >> > section >> >> > about the CC, and silently ignoring the Fixes. >> >> > >> >> > >> >> > But nowadays, we notify about all the candidates to stable, which are >> >> > CC and >> >> > Fixes. >> >> > >> >> Here is an alternative wording, hopefully it will make things clearer: >> >> >> >> Both CC and Fixes work and having both does not hurt. >> >> >> >> Fixes provides clear indication when/where the problem originates. >> >> Cc _explicitly_ requests the patch to be in stable - that's why we >> >> have the list + late nominations. >> >> >> >> It _explicit_ nomination does _not_ apply then the nominator is informed. >> >> >> >> -Emil >> > >> > Yeah, that's not useful. We don't need a "you can put this in if you want >> > but >> > don't tell me if you didn't". Either it's nominated or it's not. If Fixes: >> > doesn't mean "I want this in any stable branch with commit X" then we >> > should >> > stop using the tag. >> > >> Fixes means "I want this _anywhere_ with commit X". No idea how you >> read my comment otherwise ;-) >> >> -Emil > > Where you said CC is _explicit_ but fixes isn't. Having two ways to do the > same > thing that are subtly different seems like a bad idea to me. > > I'm going to admit this is just another reason that I feel like our whole > stable > process is rather fragile and tedious. We have three ways to nominate a patch > that are all subtly different, but those differences are not clearly > documented. Keep in mind that before I started the documentation was a mere fraction of what it is today. As I said multiple times if something is unclear - ask _and_ send patches to clarify the documentation. Sadly close to no patches appear :-( Our thinking, and hence expressions vary, so I'm more than happy to change the docs so that they are better suited for a wider audience. As a TL;DR _nothing_ is rejected silently ;-) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess
yeah, you are right, overlooked that "Target target;" inside the inner
"tex" struct.
On Sat, Sep 22, 2018 at 4:27 PM, Jan Vesely wrote:
> The warning is correct. In the first case, memset tries to zero "Target"
> object which has a non-trivial constructor and non-trivial copy-constructor.
> The original code is broken in the way it mixes C and C++ initialization and
> the patch only papers over the issue.
> The correct fix would be to provide a proper constructor for structs that
> include instances of C++ classes.
>
> Jan
>
>
> On Sat, Sep 22, 2018 at 6:43 AM Karol Herbst wrote:
>>
>> yeah, I agree here. Either the code was wrong in the first place,
>> which means it would have to be fixed properly or the warning is
>> wrong. The proper fix here is that GCC should detect itself if it's
>> safe to do or not, otherwise that warning becomes a "might be a
>> problem" thing which doesn't help at all. Either it is wrong, or it
>> isn't. And gcc should be able to know in this case.
>>
>> On Sat, Sep 22, 2018 at 6:07 AM, Ilia Mirkin wrote:
>> > Based on the various fixes, warning seems bogus -- is the proper
>> > solution -Wno-class-memaccess? (Or however one disables such
>> > things...)
>> >
>> > On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
>> > wrote:
>> >> Signed-off-by: Eric Engestrom
>> >> ---
>> >> src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
>> >> src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
>> >> 2 files changed, 2 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> >> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> >> index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
>> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> >> @@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction
>> >> *i) const
>> >> TexInstruction::TexInstruction(Function *fn, operation op)
>> >> : Instruction(fn, op, TYPE_F32)
>> >> {
>> >> - memset(&tex, 0, sizeof(tex));
>> >> + memset(static_cast(&tex), 0, sizeof(tex));
>> >>
>> >> tex.rIndirectSrc = -1;
>> >> tex.sIndirectSrc = -1;
>> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> >> b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> >> index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
>> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> >> @@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply
>> >> apply)
>> >>if (!fixupInfo)
>> >> return false;
>> >>if (n == 0)
>> >> - memset(fixupInfo, 0, sizeof(FixupInfo));
>> >> + memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
>> >> }
>> >> ++fixupInfo->count;
>> >>
>> >> --
>> >> Cheers,
>> >> Eric
>> >>
>> >> ___
>> >> mesa-dev mailing list
>> >> mesa-dev@lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Update FAQ with current OpenGL API version supported
On Sun, Sep 23, 2018 at 2:05 AM Stuart Young wrote: > > Used a variation on the standard boilerplate version info that is used in > the release notes. > > --- > docs/faq.html | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/docs/faq.html b/docs/faq.html > index 6270a071da..080c6b6da7 100644 > --- a/docs/faq.html > +++ b/docs/faq.html > @@ -45,7 +45,16 @@ See the https://www.opengl.org/";>OpenGL > website for more > information. > > > -Mesa 9.x supports the OpenGL 3.1 specification. > +Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API specification. > +Note that the version reported by glGetString(GL_VERSION) or > +glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on > +the particular driver being used. Some drivers don't support all the features > +required in OpenGL 4.5. OpenGL 4.5 is only available if requested at context > +creation because compatibility contexts are not supported. Aren't hey supported for radeonsi these days? > + > + > +For earlier versions, consult the release notes for the version of the > +OpenGL API they support. > > > > -- > 2.11.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
