Re: [Mesa-dev] [PATCH] mesa: don't overwrite existing shader files with MESA_SHADER_CAPTURE_PATH
On 4/11/19 3:32 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/mesa/main/shaderapi.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 01342c04e8f..6b73e6c7e7a 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1233,24 +1233,38 @@ link_program(struct gl_context *ctx, struct
gl_shader_program *shProg,
if (shProg->_LinkedShaders[stage])
prog = shProg->_LinkedShaders[stage]->Program;
_mesa_use_program(ctx, stage, shProg, prog, ctx->_Shader);
}
}
/* Capture .shader_test files. */
const char *capture_path = _mesa_get_shader_capture_path();
if (shProg->Name != 0 && shProg->Name != ~0 && capture_path != NULL) {
- FILE *file;
- char *filename = ralloc_asprintf(NULL, "%s/%u.shader_test",
+ /* Find an unused filename. */
+ char *filename = NULL;
+ for (unsigned i = 0;; i++) {
+ if (i) {
+filename = ralloc_asprintf(NULL, "%s/%u-%u.shader_test",
+ capture_path, shProg->Name, i);
+ } else {
+filename = ralloc_asprintf(NULL, "%s/%u.shader_test",
capture_path, shProg->Name);
How about just having the counter always there, to simplify a bit and
have consistent filename scheme? Just a suggestion.
- file = fopen(filename, "w");
+ }
+ FILE *file = fopen(filename, "r");
+ if (!file)
+break;
I'm surprised we don't have some helper like 'util_path_exists' but this
works, I guess then we should have 'util_path_isdir|isfile' and others
as well.
With or without the suggestion;
Reviewed-by: Tapani Pälli
+ fclose(file);
+ ralloc_free(filename);
+ }
+
+ FILE *file = fopen(filename, "w");
if (file) {
fprintf(file, "[require]\nGLSL%s >= %u.%02u\n",
shProg->IsES ? " ES" : "",
shProg->data->Version / 100, shProg->data->Version % 100);
if (shProg->SeparateShader)
fprintf(file, "GL_ARB_separate_shader_objects\nSSO ENABLED\n");
fprintf(file, "\n");
for (unsigned i = 0; i < shProg->NumShaders; i++) {
fprintf(file, "[%s shader]\n%s\n",
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] st/nine: skip position checks in SetCursorPosition()
For HW cursors, "cursor.pos" doesn't hold the current position of the
pointer, just the position of the last call to SetCursorPosition().
Skip the check against stale values and bump the d3dadapter9 drm version
to expose this change of behaviour.
Signed-off-by: Andre Heider
---
V3: improve version description in d3dadapter/drm.h
include/d3dadapter/drm.h | 7 +--
src/gallium/state_trackers/nine/device9.c | 8 +---
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/d3dadapter/drm.h b/include/d3dadapter/drm.h
index 647f017fc7f..6939dd4f239 100644
--- a/include/d3dadapter/drm.h
+++ b/include/d3dadapter/drm.h
@@ -29,11 +29,14 @@
#define D3DADAPTER9DRM_NAME "drm"
/* current version */
#define D3DADAPTER9DRM_MAJOR 0
-#define D3DADAPTER9DRM_MINOR 1
+#define D3DADAPTER9DRM_MINOR 2
/* version 0.0: Initial release
* 0.1: All IDirect3D objects can be assumed to have a pointer to the
- * internal vtable in second position of the structure */
+ * internal vtable in second position of the structure
+ * 0.2: IDirect3DDevice9_SetCursorPosition always calls
+ * ID3DPresent_SetCursorPos for hardware cursors
+ */
struct D3DAdapter9DRM
{
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index c777f843b67..f165f24ee46 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -793,9 +793,11 @@ 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;
+/* present >= v1.4 handles this itself */
+if (This->minor_version_num < 4) {
+if (This->cursor.pos.x == X && This->cursor.pos.y == Y)
+return;
+}
This->cursor.pos.x = X;
This->cursor.pos.y = Y;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110402] checking validations
https://bugs.freedesktop.org/show_bug.cgi?id=110402 Bug ID: 110402 Summary: checking validations Product: Mesa Version: 5.0.2 Hardware: PowerPC URL: http://219.91.142.54:1515/GreyOrder OS: Windows (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: rjrohan...@rediffmail.com Reporter: rjrohan...@rediffmail.com QA Contact: mesa-dev@lists.freedesktop.org CC: rjrohan...@rediffmail.com Created attachment 143934 --> https://bugs.freedesktop.org/attachment.cgi?id=143934&action=edit validation not proper -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 102227] Commit 26aee6f4d5 causes crash-loop on android-x86 (surfaceflinger to exit with status 1)
https://bugs.freedesktop.org/show_bug.cgi?id=102227 --- Comment #6 from Pokemon --- You can need to visit the site online here http://documentswindows10.com and find to all way for where are scanned documents windows 10. -- 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] [Nouveau] Questions on GPU syncpoint handling from inside the GPU
On Wed, 10 Apr 2019 at 22:45, Ilia Mirkin wrote: > > All docs are in the proper method address, i.e. "in bytes" -- in the > future, please refer to them that way since all the code and > documentation do. > > There is no reference to method 2c8 in the mesa driver (except the > GLOBAL_BASE thing that's only on fermi, I won't get into the details > of what that does, but it's completely irrelevant to what you're > looking at, and gone on Kepler). > > There's also no reference to method 2c8 in libdrm_nouveau nor in the > nouveau kernel driver (that I can see). > > Some notes I have do indicate that method 2c8 does in fact exist > starting with the KeplerC 3d class (GK208 iirc), and has something to > do with "sync points" whatever those are. However we've never used it, > and I don't have any details on how it operates. Syncpoints are only available on Tegra HW as far as I know, and are used to implement some android synchronization method. We don't use them, nor do I know any of their details off the top of my head. The NVGPU driver source appears to indicate it makes use of them, and would probably be a reasonable reference for you. Ben. > > All the waiting is done using the SEMAPHORE_* methods I pointed at in > my earlier email. If the CPU has to wait for the GPU to finish > something, we can use a kernel-based wait, which basically waits for > an interrupt to occur, or we can use a CPU-based wait which spins and > waits for some value in memory to get to a particular number. If the > CPU does not have to wait, you just want the command stream processing > to wait inside the GPU, then you can also use those SEMAPHORE_* > methods, e.g. nvc0_hw_query_fifo_wait in nvc0_query_hw.c. > > Hope this helps, > > -ilia > > On Wed, Apr 10, 2019 at 6:59 AM Fernando Sahmkow wrote: > > > > yeah 0xB2 in words not bytes (*4). Nouveau does write this method in > > Maxwell GPUs (we have compiled test apps with nouveau and asserted it was > > written). Here's what my colleague fincs REed: > > https://github.com/devkitPro/libdrm_nouveau/blob/master/source/pushbuf.c#L399-L407 > > methods are word aligned (so multiplied by 4 for bytes). As far as I know > > the driver side writes some syncpoints to set fences, this method seems to > > tamper with those syncpoints, the thing is that I don't know why or how. > > > > I think this is related to glFencSync and glWaitClientSync. How are this > > methods implemented from both sides (within the gpu and within the > > driver/host communication) ? > > > > El mié., 10 abr. 2019 a las 0:56, Ilia Mirkin () > > escribió: > >> > >> Hi Fernando, > >> > >> Perhaps you can elaborate? The question doesn't really make sense to me. > >> > >> What register are you talking about? Do you perhaps mean a method call > >> in the b197 class? (And what's 0xB2? Methods are always at multiples > >> of 4... do you mean 0x2c8 perhaps? If so, that's not documented post > >> Fermi in the 3d class.) And lastly, what do you mean by syncpoints > >> exactly? There are various class methods that will allow you to wait > >> for a value in memory to be equal (or greater) than a value in the > >> command stream, for example (e.g. QUERY_GET -- method 0x1b0c, or the > >> fifo-level 0x10..0x1c SEMAPHORE_* methods) -- is that what you're > >> talking about? > >> > >> -ilia > >> > >> On Tue, Apr 9, 2019 at 9:46 PM Fernando Sahmkow > >> wrote: > >> > > >> > bump > >> > > >> > El mar., 2 abr. 2019 a las 11:11, Fernando Sahmkow > >> > () escribió: > >> >> > >> >> Hi guys how are you doing? I have some questions on how the GPU handles > >> >> syncpoints from the commandlist. > >> >> > >> >> I do know the register 0xB2 is the one written in the Maxwell3D Engine. > >> >> As far as I know bits 0:15 are the syncpoint id, bit 16 is unknown for > >> >> me, bit 20 is increment? What other bits are set and what should be > >> >> done on increment? > >> >> > >> >> Thanks in advance. > >> > > >> > > >> > > >> > -- > >> > Atentamente, > >> > Fernando A. Sahmkow > >> > Móvil: +584242280286 > >> > Correo: fsahmko...@gmail.com > >> > ___ > >> > Nouveau mailing list > >> > nouv...@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/nouveau > > > > > > > > -- > > Atentamente, > > Fernando A. Sahmkow > > Móvil: +584242280286 > > Correo: fsahmko...@gmail.com > ___ > 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] [ANNOUNCE] mesa 19.0.2
Hi list, I'm pleased to announce the availability of mesa 19.0.2. It's a bit late, and I need to apologize for that, Dad duties have been trumping other things. On the release side it's been a pretty tame cycle. Just a few fixes for radeon, a few for nir, a couple for radv, a couple for v3d, and a few other patches here and there. Dylan shortlog: Boyuan Zhang (1): st/va: reverse qt matrix back to its original order Caio Marcelo de Oliveira Filho (1): nir: Take if_uses into account when repairing SSA Dylan Baker (2): VERSION: bump version for 19.0.2 docs: Add release notes for 19.0.2 Eric Anholt (3): dri3: Return the current swap interval from glXGetSwapIntervalMESA(). v3d: Bump the maximum texture size to 4k for V3D 4.x. v3d: Don't try to use the TFU blit path if a scissor is enabled. Eric Engestrom (1): meson: strip rpath from megadrivers Jason Ekstrand (1): Revert "anv/radv: release memory allocated by glsl types during spirv_to_nir" Karol Herbst (1): nir/print: fix printing the image_array intrinsic index Leo Liu (2): radeon/vcn: add H.264 constrained baseline support radeon/vcn/vp9: search the render target from the whole list Lionel Landwerlin (1): intel: add dependency on genxml generated files Marek Olšák (1): radeonsi: fix assertion failure by using the correct type Samuel Pitoiset (2): radv: skip updating depth/color metadata for conditional rendering radv: do not always initialize HTILE in compressed state git tag: mesa-19.0.2 https://mesa.freedesktop.org/archive/mesa-19.0.2.tar.gz MD5: 1b3eaaf4235c8062a8dea52ea319f713 mesa-19.0.2.tar.gz SHA1: ee11c855260be8141081f16f898f5fb47c392f92 mesa-19.0.2.tar.gz SHA256: eb972fc11d4e1261d34ec0b91a701f158d4870c0428fb108353ae7eab64b1118 mesa-19.0.2.tar.gz SHA512: a0e68625e69c0b7f4aaf62cfd5fd0b5023d5193293c8fe56cd596c273b465a05048c0c56eab839cec0aede39574d71d7e303439e0770766101be4f073248f740 mesa-19.0.2.tar.gz PGP: https://mesa.freedesktop.org/archive/mesa-19.0.2.tar.gz.sig https://mesa.freedesktop.org/archive/mesa-19.0.2.tar.xz MD5: 7f84af1c3fe2078c35a7a991d1469921 mesa-19.0.2.tar.xz SHA1: 554dad1da57f9de09ac5732ba9a27ef26f9c3005 mesa-19.0.2.tar.xz SHA256: 1a2edc3ce56906a676c91e6851298db45903df1f5cb9827395a922c1452db802 mesa-19.0.2.tar.xz SHA512: 6b317205efa7d62150fae23489fbad5f062ecde99fb5b210fa7ccbed2e0ef60aee1f1e66e2c606ea5d59193c3218f732556706ab3b645b175044342d88984d51 mesa-19.0.2.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-19.0.2.tar.xz.sig signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110291] Vega 64 GPU hang running Space Engineers
https://bugs.freedesktop.org/show_bug.cgi?id=110291 --- Comment #2 from Peter --- Space Engineers only began to run in the last couple of months. I haven't been able to get into the game at all with older LLVM+Mesa versions to test. -- 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] gallium/aux: Report error if loading of a pipe driver fails.
On Wed, Apr 10, 2019 at 9:33 PM Marek Olšák wrote:
>
> Reviewed-by: Marek Olšák
thank you. pushed.
Jan
>
> Marek
>
> On Wed, Apr 3, 2019 at 2:02 AM Jan Vesely wrote:
>>
>> Skip over non-existent files.
>> Signed-off-by: Jan Vesely
>> ---
>> This should help detect instances of messed up/missing symbols in the driver.
>> windows build seems OK:
>> https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
>> .../auxiliary/pipe-loader/pipe_loader.c | 5 +-
>> src/gallium/auxiliary/util/u_file.h | 58 +++
>> 2 files changed, 62 insertions(+), 1 deletion(-)
>> create mode 100644 src/gallium/auxiliary/util/u_file.h
>>
>> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> index 6fd15527e53..fc8ee8e8dcd 100644
>> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> @@ -31,6 +31,7 @@
>> #include "util/u_memory.h"
>> #include "util/u_string.h"
>> #include "util/u_dl.h"
>> +#include "util/u_file.h"
>> #include "util/xmlconfig.h"
>> #include "util/xmlpool.h"
>>
>> @@ -158,11 +159,13 @@ pipe_loader_find_module(const char *driver_name,
>> ret = util_snprintf(path, sizeof(path), "%s%s%s",
>> MODULE_PREFIX, driver_name, UTIL_DL_EXT);
>>
>> - if (ret > 0 && ret < sizeof(path)) {
>> + if (ret > 0 && ret < sizeof(path) && u_file_access(path, 0) != -1) {
>> lib = util_dl_open(path);
>> if (lib) {
>> return lib;
>> }
>> + fprintf(stderr, "ERROR: Failed to load pipe driver at `%s': %s\n",
>> + path, util_dl_error());
>>}
>> }
>>
>> diff --git a/src/gallium/auxiliary/util/u_file.h
>> b/src/gallium/auxiliary/util/u_file.h
>> new file mode 100644
>> index 000..f337dc9761e
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/util/u_file.h
>> @@ -0,0 +1,58 @@
>> +/**
>> + *
>> + * Copyright 2009 VMware, Inc.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, 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 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 NON-INFRINGEMENT. IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS 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.
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial portions
>> + * of the Software.
>> + *
>> + **/
>> +
>> +
>> +#ifndef U_FILE_H_
>> +#define U_FILE_H_
>> +
>> +#if defined(PIPE_OS_UNIX)
>> +#include
>> +#endif
>> +#if defined(PIPE_OS_WINDOWS)
>> +#include
>> +#endif
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +static inline int
>> +u_file_access(const char *path, int mode) {
>> +#if defined(PIPE_OS_UNIX)
>> + return access(path, mode);
>> +#elif defined(PIPE_OS_WINDOWS)
>> + return _access(path, mode);
>> +#else
>> + return 0;
>> +#endif
>> +}
>> +
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +
>> +#endif /* U_FILE_H_ */
>> --
>> 2.21.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [rfc] st/mesa: don't update fb state is raster discard is set.
Consider this sequence of calls:
1) Enable rasterizer discard
2) Update the framebuffer (skipped by your patch)
3) Draw
4) Disable rasterizer discard
5) Draw (not using the correct framebuffer)
Marek
On Wed, Apr 10, 2019 at 2:10 AM Dave Airlie wrote:
> From: Dave Airlie
>
> This avoid softpipe trying to get image when no window has ever
> been exposed, and no image will be exposed.
>
> I'm not entirely sure this is correct or useful, but it definitely
> helps with some softpipe get images when we haven't got a window.
> ---
> src/mesa/state_tracker/st_atom.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_atom.c
> b/src/mesa/state_tracker/st_atom.c
> index 49f79ad9d49..3aeb526e56b 100644
> --- a/src/mesa/state_tracker/st_atom.c
> +++ b/src/mesa/state_tracker/st_atom.c
> @@ -246,6 +246,9 @@ void st_validate_state( struct st_context *st, enum
> st_pipeline pipeline )
>unreachable("Invalid pipeline specified");
> }
>
> + if (ctx->RasterDiscard)
> + st->dirty &= ~ST_NEW_FB_STATE;
> +
> dirty = st->dirty & pipeline_mask;
> if (!dirty)
>return;
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/aux: Report error if loading of a pipe driver fails.
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 2:02 AM Jan Vesely wrote:
> Skip over non-existent files.
> Signed-off-by: Jan Vesely
> ---
> This should help detect instances of messed up/missing symbols in the
> driver.
> windows build seems OK:
> https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
> .../auxiliary/pipe-loader/pipe_loader.c | 5 +-
> src/gallium/auxiliary/util/u_file.h | 58 +++
> 2 files changed, 62 insertions(+), 1 deletion(-)
> create mode 100644 src/gallium/auxiliary/util/u_file.h
>
> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> index 6fd15527e53..fc8ee8e8dcd 100644
> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> @@ -31,6 +31,7 @@
> #include "util/u_memory.h"
> #include "util/u_string.h"
> #include "util/u_dl.h"
> +#include "util/u_file.h"
> #include "util/xmlconfig.h"
> #include "util/xmlpool.h"
>
> @@ -158,11 +159,13 @@ pipe_loader_find_module(const char *driver_name,
> ret = util_snprintf(path, sizeof(path), "%s%s%s",
> MODULE_PREFIX, driver_name, UTIL_DL_EXT);
>
> - if (ret > 0 && ret < sizeof(path)) {
> + if (ret > 0 && ret < sizeof(path) && u_file_access(path, 0) != -1) {
> lib = util_dl_open(path);
> if (lib) {
> return lib;
> }
> + fprintf(stderr, "ERROR: Failed to load pipe driver at `%s':
> %s\n",
> + path, util_dl_error());
>}
> }
>
> diff --git a/src/gallium/auxiliary/util/u_file.h
> b/src/gallium/auxiliary/util/u_file.h
> new file mode 100644
> index 000..f337dc9761e
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_file.h
> @@ -0,0 +1,58 @@
>
> +/**
> + *
> + * Copyright 2009 VMware, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, 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 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 NON-INFRINGEMENT. IN NO EVENT
> SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS 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.
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> +
> **/
> +
> +
> +#ifndef U_FILE_H_
> +#define U_FILE_H_
> +
> +#if defined(PIPE_OS_UNIX)
> +#include
> +#endif
> +#if defined(PIPE_OS_WINDOWS)
> +#include
> +#endif
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +static inline int
> +u_file_access(const char *path, int mode) {
> +#if defined(PIPE_OS_UNIX)
> + return access(path, mode);
> +#elif defined(PIPE_OS_WINDOWS)
> + return _access(path, mode);
> +#else
> + return 0;
> +#endif
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* U_FILE_H_ */
> --
> 2.21.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: trace: Add missing fence related wrappers
Pushed, thanks!
Marek
On Tue, Apr 9, 2019 at 7:33 AM Guido Günther wrote:
> Hi,
> On Fri, Mar 29, 2019 at 05:48:31PM +0100, Guido Günther wrote:
> > Without that kmscube with GALLIUM_TRACE would segfault like:
> >
> > #0 0x in ()
> > #1 0x8f311760 in dri2_create_fence_fd (_ctx=0xe266b8b0,
> fd=10) at ../src/gallium/state_trackers/dri/dri_helpers.c:122
> > #2 0x90788670 in dri2_create_sync (drv=0xe2667910,
> disp=0xe26691f0, type=12612, attrib_list=0xe26b9290) at
> ../src/egl/drivers/dri2/egl_dri2.c:2993
> > #3 0x90776a9c in _eglCreateSync (disp=0xe26691f0,
> type=12612, attrib_list=0xe26b9290, orig_is_EGLAttrib=0,
> invalid_type_error=12292) at ../src/egl/main/eglapi.c:1823
> > #4 0x90776be4 in eglCreateSyncKHR (dpy=0xe26691f0,
> type=12612, int_list=0xf662e828) at ../src/egl/main/eglapi.c:1848
> >
> > Signed-off-by: Guido Günther
>
> These are similar to the already applied (thanks Lucas!) GALLIUM_DDEBUG
> fixes:
>
> https://lists.freedesktop.org/archives/mesa-dev/2019-April/217422.html
>
> but for GALLIUM_TRACE - just in case they looked to similar when flying
> by.
> Cheers,
> -- Guido
>
> > ---
> > .../auxiliary/driver_trace/tr_context.c | 44 +++
> > .../auxiliary/driver_trace/tr_screen.c| 24 ++
> > 2 files changed, 68 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/driver_trace/tr_context.c
> b/src/gallium/auxiliary/driver_trace/tr_context.c
> > index 7859a3395ca..9f3926a32a4 100644
> > --- a/src/gallium/auxiliary/driver_trace/tr_context.c
> > +++ b/src/gallium/auxiliary/driver_trace/tr_context.c
> > @@ -1314,6 +1314,48 @@ trace_context_flush(struct pipe_context *_pipe,
> > }
> >
> >
> > +static void
> > +trace_context_create_fence_fd(struct pipe_context *_pipe,
> > + struct pipe_fence_handle **fence,
> > + int fd,
> > + enum pipe_fd_type type)
> > +{
> > + struct trace_context *tr_ctx = trace_context(_pipe);
> > + struct pipe_context *pipe = tr_ctx->pipe;
> > +
> > + trace_dump_call_begin("pipe_context", "create_fence_fd");
> > +
> > + trace_dump_arg(ptr, pipe);
> > + trace_dump_arg(int, fd);
> > + trace_dump_arg(uint, type);
> > +
> > + pipe->create_fence_fd(pipe, fence, fd, type);
> > +
> > + if (fence)
> > + trace_dump_ret(ptr, *fence);
> > +
> > + trace_dump_call_end();
> > +}
> > +
> > +
> > +static void
> > +trace_context_fence_server_sync(struct pipe_context *_pipe,
> > +struct pipe_fence_handle *fence)
> > +{
> > + struct trace_context *tr_ctx = trace_context(_pipe);
> > + struct pipe_context *pipe = tr_ctx->pipe;
> > +
> > + trace_dump_call_begin("pipe_context", "fence_server_sync");
> > +
> > + trace_dump_arg(ptr, pipe);
> > + trace_dump_arg(ptr, fence);
> > +
> > + pipe->fence_server_sync(pipe, fence);
> > +
> > + trace_dump_call_end();
> > +}
> > +
> > +
> > static inline boolean
> > trace_context_generate_mipmap(struct pipe_context *_pipe,
> >struct pipe_resource *res,
> > @@ -1946,6 +1988,8 @@ trace_context_create(struct trace_screen *tr_scr,
> > TR_CTX_INIT(clear_depth_stencil);
> > TR_CTX_INIT(clear_texture);
> > TR_CTX_INIT(flush);
> > + TR_CTX_INIT(create_fence_fd);
> > + TR_CTX_INIT(fence_server_sync);
> > TR_CTX_INIT(generate_mipmap);
> > TR_CTX_INIT(texture_barrier);
> > TR_CTX_INIT(memory_barrier);
> > diff --git a/src/gallium/auxiliary/driver_trace/tr_screen.c
> b/src/gallium/auxiliary/driver_trace/tr_screen.c
> > index b5bd3e11c46..e42aef63552 100644
> > --- a/src/gallium/auxiliary/driver_trace/tr_screen.c
> > +++ b/src/gallium/auxiliary/driver_trace/tr_screen.c
> > @@ -495,6 +495,29 @@ trace_screen_fence_reference(struct pipe_screen
> *_screen,
> > }
> >
> >
> > +static int
> > +trace_screen_fence_get_fd(struct pipe_screen *_screen,
> > + struct pipe_fence_handle *fence)
> > +{
> > + struct trace_screen *tr_scr = trace_screen(_screen);
> > + struct pipe_screen *screen = tr_scr->screen;
> > + int result;
> > +
> > + trace_dump_call_begin("pipe_screen", "fence_get_fd");
> > +
> > + trace_dump_arg(ptr, screen);
> > + trace_dump_arg(ptr, fence);
> > +
> > + result = screen->fence_get_fd(screen, fence);
> > +
> > + trace_dump_ret(int, result);
> > +
> > + trace_dump_call_end();
> > +
> > + return result;
> > +}
> > +
> > +
> > static boolean
> > trace_screen_fence_finish(struct pipe_screen *_screen,
> >struct pipe_context *_ctx,
> > @@ -654,6 +677,7 @@ trace_screen_create(struct pipe_screen *screen)
> > SCR_INIT(resource_changed);
> > tr_scr->base.resource_destroy = trace_screen_resource_destroy;
> > tr_scr->base.fence_reference = trace_screen_fence_reference;
> > + SCR_INIT(fence_get_fd);
> > tr_scr->base.fence_finish =
[Mesa-dev] [PATCH 2/2] ac: use the common helper ac_apply_fmask_to_sample
From: Marek Olšák
---
src/amd/common/ac_nir_to_llvm.c | 70 +++--
1 file changed, 5 insertions(+), 65 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3d2f738edec..3abde6e0969 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2323,92 +2323,32 @@ static int image_type_to_components_count(enum
glsl_sampler_dim dim, bool array)
case GLSL_SAMPLER_DIM_SUBPASS:
return 2;
case GLSL_SAMPLER_DIM_SUBPASS_MS:
return 3;
default:
break;
}
return 0;
}
-
-/* Adjust the sample index according to FMASK.
- *
- * For uncompressed MSAA surfaces, FMASK should return 0x76543210,
- * which is the identity mapping. Each nibble says which physical sample
- * should be fetched to get that sample.
- *
- * For example, 0x1100 means there are only 2 samples stored and
- * the second sample covers 3/4 of the pixel. When reading samples 0
- * and 1, return physical sample 0 (determined by the first two 0s
- * in FMASK), otherwise return physical sample 1.
- *
- * The sample index should be adjusted as follows:
- * sample_index = (fmask >> (sample_index * 4)) & 0xF;
- */
static LLVMValueRef adjust_sample_index_using_fmask(struct ac_llvm_context
*ctx,
LLVMValueRef coord_x,
LLVMValueRef coord_y,
LLVMValueRef coord_z,
LLVMValueRef sample_index,
LLVMValueRef fmask_desc_ptr)
{
- struct ac_image_args args = {0};
- LLVMValueRef res;
+ unsigned sample_chan = coord_z ? 3 : 2;
+ LLVMValueRef addr[4] = {coord_x, coord_y, coord_z};
+ addr[sample_chan] = sample_index;
- args.coords[0] = coord_x;
- args.coords[1] = coord_y;
- if (coord_z)
- args.coords[2] = coord_z;
-
- args.opcode = ac_image_load;
- args.dim = coord_z ? ac_image_2darray : ac_image_2d;
- args.resource = fmask_desc_ptr;
- args.dmask = 0xf;
- args.attributes = AC_FUNC_ATTR_READNONE;
-
- res = ac_build_image_opcode(ctx, &args);
-
- res = ac_to_integer(ctx, res);
- LLVMValueRef four = LLVMConstInt(ctx->i32, 4, false);
- LLVMValueRef F = LLVMConstInt(ctx->i32, 0xf, false);
-
- LLVMValueRef fmask = LLVMBuildExtractElement(ctx->builder,
-res,
-ctx->i32_0, "");
-
- LLVMValueRef sample_index4 =
- LLVMBuildMul(ctx->builder, sample_index, four, "");
- LLVMValueRef shifted_fmask =
- LLVMBuildLShr(ctx->builder, fmask, sample_index4, "");
- LLVMValueRef final_sample =
- LLVMBuildAnd(ctx->builder, shifted_fmask, F, "");
-
- /* Don't rewrite the sample index if WORD1.DATA_FORMAT of the FMASK
-* resource descriptor is 0 (invalid),
-*/
- LLVMValueRef fmask_desc =
- LLVMBuildBitCast(ctx->builder, fmask_desc_ptr,
-ctx->v8i32, "");
-
- LLVMValueRef fmask_word1 =
- LLVMBuildExtractElement(ctx->builder, fmask_desc,
- ctx->i32_1, "");
-
- LLVMValueRef word1_is_nonzero =
- LLVMBuildICmp(ctx->builder, LLVMIntNE,
- fmask_word1, ctx->i32_0, "");
-
- /* Replace the MSAA sample index. */
- sample_index =
- LLVMBuildSelect(ctx->builder, word1_is_nonzero,
- final_sample, sample_index, "");
- return sample_index;
+ ac_apply_fmask_to_sample(ctx, fmask_desc_ptr, addr, coord_z != NULL);
+ return addr[sample_chan];
}
static nir_deref_instr *get_image_deref(const nir_intrinsic_instr *instr)
{
assert(instr->src[0].is_ssa);
return nir_instr_as_deref(instr->src[0].ssa->parent_instr);
}
static LLVMValueRef get_image_descriptor(struct ac_nir_context *ctx,
const nir_intrinsic_instr *instr,
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: set AC_FUNC_ATTR_READNONE for image opcodes where it was missing
From: Marek Olšák
---
src/amd/common/ac_llvm_build.c| 1 +
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 4
2 files changed, 5 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index a612dcefa1d..cfbca294c97 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -3293,20 +3293,21 @@ LLVMValueRef ac_unpack_param(struct ac_llvm_context
*ctx, LLVMValueRef param,
* addr[sample_index] = (fmask >> (addr[sample_index] * 4)) & 0xF;
*/
void ac_apply_fmask_to_sample(struct ac_llvm_context *ac, LLVMValueRef fmask,
LLVMValueRef *addr, bool is_array_tex)
{
struct ac_image_args fmask_load = {};
fmask_load.opcode = ac_image_load;
fmask_load.resource = fmask;
fmask_load.dmask = 0xf;
fmask_load.dim = is_array_tex ? ac_image_2darray : ac_image_2d;
+ fmask_load.attributes = AC_FUNC_ATTR_READNONE;
fmask_load.coords[0] = addr[0];
fmask_load.coords[1] = addr[1];
if (is_array_tex)
fmask_load.coords[2] = addr[2];
LLVMValueRef fmask_value = ac_build_image_opcode(ac, &fmask_load);
fmask_value = LLVMBuildExtractElement(ac->builder, fmask_value,
ac->i32_0, "");
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 727def56f65..ed67976b421 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -1035,20 +1035,21 @@ static void resq_emit(
if (inst->Memory.Texture == TGSI_TEXTURE_3D)
target = TGSI_TEXTURE_2D_ARRAY;
else
target = inst->Memory.Texture;
}
struct ac_image_args args = {};
args.opcode = ac_image_get_resinfo;
args.dim = ac_texture_dim_from_tgsi_target(ctx->screen, target);
args.dmask = 0xf;
+ args.attributes = AC_FUNC_ATTR_READNONE;
if (inst->Instruction.Opcode == TGSI_OPCODE_TXQ) {
tex_fetch_ptrs(bld_base, emit_data, &args.resource, NULL, NULL);
args.lod = lp_build_emit_fetch(bld_base, inst, 0, TGSI_CHAN_X);
} else {
image_fetch_rsrc(bld_base, reg, false, target, &args.resource);
args.lod = ctx->i32_0;
}
emit_data->output[emit_data->chan] =
@@ -1265,20 +1266,21 @@ si_lower_gather4_integer(struct si_shader_context *ctx,
lp_build_if(&if_ctx, &ctx->gallivm,
LLVMBuildNot(builder, wa_, ""));
}
/* Query the texture size. */
resinfo.opcode = ac_image_get_resinfo;
resinfo.dim = ac_texture_dim_from_tgsi_target(ctx->screen,
target);
resinfo.resource = args->resource;
resinfo.sampler = args->sampler;
resinfo.lod = ctx->ac.i32_0;
resinfo.dmask = 0xf;
+ resinfo.attributes = AC_FUNC_ATTR_READNONE;
LLVMValueRef texsize =
fix_resinfo(ctx, target,
ac_build_image_opcode(&ctx->ac, &resinfo));
/* Compute -0.5 / size. */
for (unsigned c = 0; c < 2; c++) {
half_texel[c] =
LLVMBuildExtractElement(builder, texsize,
LLVMConstInt(ctx->i32,
c, 0), "");
@@ -1769,20 +1771,22 @@ static void si_llvm_emit_fbfetch(const struct
lp_build_tgsi_action *action,
fmask = ac_build_load_to_sgpr(&ctx->ac, ptr,
LLVMConstInt(ctx->i32, SI_PS_IMAGE_COLORBUF0_FMASK / 2,
0));
ac_apply_fmask_to_sample(&ctx->ac, fmask, args.coords,
ctx->shader->key.mono.u.ps.fbfetch_layered);
}
args.opcode = ac_image_load;
args.resource = image;
args.dmask = 0xf;
+ args.attributes = AC_FUNC_ATTR_READNONE;
+
if (ctx->shader->key.mono.u.ps.fbfetch_msaa)
args.dim = ctx->shader->key.mono.u.ps.fbfetch_layered ?
ac_image_2darraymsaa : ac_image_2dmsaa;
else if (ctx->shader->key.mono.u.ps.fbfetch_is_1D)
args.dim = ctx->shader->key.mono.u.ps.fbfetch_layered ?
ac_image_1darray : ac_image_1d;
else
args.dim = ctx->shader->key.mono.u.ps.fbfetch_layered ?
ac_image_2darray : ac_image_2d;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] ac/nir: remove some useless integer casts for ALU operations
On Wed, Apr 10, 2019 at 7:44 PM Timothy Arceri wrote: > Before I attempt to review, have you run piglit on this series with > radeonsi nir? > That's a good idea. If there is no piglit regression on radeonsi, the series is: Reviewed-by: Marek Olšák Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa compatibility range
On Wed, 2019-04-10 at 15:37 +, Jonathan Jackson wrote: > 1. My question is: Is it reasonable to think that llvmpipe (or other > drivers) will grand me a much wider > array of supported system if I use that implementation over the original > Windows one? I'm reasonably sure that llvmpipe implements a newer version of OpenGL than the software renderer included with Windows. > 2. Another way to ask the question is: Is there a way of knowing which > specs a system is required to have > so it can support Mesa’s implementation of all of OpenGL 2.1? (is it common > that a system(high or low end) > will support all of Mesa’s equivalents of OpenGL 2.1 features). llvmpipe's OpenGL version does not depend on the CPU's feature level, it implements OpenGL 3.3 regardless of the instruction set. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: don't overwrite existing shader files with MESA_SHADER_CAPTURE_PATH
From: Marek Olšák
---
src/mesa/main/shaderapi.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 01342c04e8f..6b73e6c7e7a 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1233,24 +1233,38 @@ link_program(struct gl_context *ctx, struct
gl_shader_program *shProg,
if (shProg->_LinkedShaders[stage])
prog = shProg->_LinkedShaders[stage]->Program;
_mesa_use_program(ctx, stage, shProg, prog, ctx->_Shader);
}
}
/* Capture .shader_test files. */
const char *capture_path = _mesa_get_shader_capture_path();
if (shProg->Name != 0 && shProg->Name != ~0 && capture_path != NULL) {
- FILE *file;
- char *filename = ralloc_asprintf(NULL, "%s/%u.shader_test",
+ /* Find an unused filename. */
+ char *filename = NULL;
+ for (unsigned i = 0;; i++) {
+ if (i) {
+filename = ralloc_asprintf(NULL, "%s/%u-%u.shader_test",
+ capture_path, shProg->Name, i);
+ } else {
+filename = ralloc_asprintf(NULL, "%s/%u.shader_test",
capture_path, shProg->Name);
- file = fopen(filename, "w");
+ }
+ FILE *file = fopen(filename, "r");
+ if (!file)
+break;
+ fclose(file);
+ ralloc_free(filename);
+ }
+
+ FILE *file = fopen(filename, "w");
if (file) {
fprintf(file, "[require]\nGLSL%s >= %u.%02u\n",
shProg->IsES ? " ES" : "",
shProg->data->Version / 100, shProg->data->Version % 100);
if (shProg->SeparateShader)
fprintf(file, "GL_ARB_separate_shader_objects\nSSO ENABLED\n");
fprintf(file, "\n");
for (unsigned i = 0; i < shProg->NumShaders; i++) {
fprintf(file, "[%s shader]\n%s\n",
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v6 32/35] intel/compiler: validate region restrictions for mixed float mode
"Juan A. Suarez Romero" writes:
> From: Iago Toral Quiroga
>
> v2:
> - Adapted unit tests to make them consistent with the changes done
>to the validation of half-float conversions.
>
> v3 (Curro):
> - Check all the accummulators
> - Constify declarations
> - Do not check src1 type in single-source instructions.
> - Check for all instructions that read accumulator (either implicitly or
> explicitly)
> - Check restrictions in src1 too.
> - Merge conditional block
> - Add invalid test case.
> ---
> src/intel/compiler/brw_eu_validate.c| 290 +++
> src/intel/compiler/test_eu_validate.cpp | 631
> 2 files changed, 921 insertions(+)
>
> diff --git a/src/intel/compiler/brw_eu_validate.c
> b/src/intel/compiler/brw_eu_validate.c
> index cfaf126e2f5..4a735641c86 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo,
> const brw_inst *inst)
>brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
> }
>
> +static bool
> +src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> +{
> + return brw_inst_src0_reg_file(devinfo, inst) ==
> BRW_ARCHITECTURE_REGISTER_FILE &&
> + (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) ==
> BRW_ARF_ACCUMULATOR;
> +}
> +
> +static bool
> +src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> +{
> + return brw_inst_src1_reg_file(devinfo, inst) ==
> BRW_ARCHITECTURE_REGISTER_FILE &&
> + (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) ==
> BRW_ARF_ACCUMULATOR;
> +}
> +
> static bool
> src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
> {
> @@ -275,6 +289,27 @@ sources_not_null(const struct gen_device_info *devinfo,
> return error_msg;
> }
>
> +static bool
> +inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst
> *inst)
> +{
> + /* Check instructions that use implicit accumulator sources */
> + switch (brw_inst_opcode(devinfo, inst)) {
> + case BRW_OPCODE_MAC:
> + case BRW_OPCODE_MACH:
> + case BRW_OPCODE_SADA2:
> + return true;
> + }
> +
> + /* Instructions with three source operands cannot use explicit accumulator
> +* operands.
> +*/
They can on Gen10+. Yeah, I know, it's quite a pain to have to
special-case 3src instructions everywhere in the validator code...
> + const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + if (num_sources > 2)
> + return false;
> +
> + return src0_is_acc(devinfo, inst) || (num_sources > 1 &&
> src1_is_acc(devinfo, inst));
> +}
> +
> static struct string
> send_restrictions(const struct gen_device_info *devinfo,
>const brw_inst *inst)
> @@ -938,6 +973,260 @@ general_restrictions_on_region_parameters(const struct
> gen_device_info *devinfo,
> return error_msg;
> }
>
> +static struct string
> +special_restrictions_for_mixed_float_mode(const struct gen_device_info
> *devinfo,
> + const brw_inst *inst)
> +{
> + struct string error_msg = { .str = NULL, .len = 0 };
> +
> + const unsigned opcode = brw_inst_opcode(devinfo, inst);
> + const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + if (num_sources >= 3)
> + return error_msg;
> +
> + if (!is_mixed_float(devinfo, inst))
> + return error_msg;
> +
> + unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
> + bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
> +
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> + enum brw_reg_type src1_type = num_sources > 1 ?
> + brw_inst_src1_type(devinfo, inst) : 0;
> + enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> +
> + unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
> + bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size,
> dst_stride);
> +
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"Indirect addressing on source is not supported when source and
> +* destination data types are mixed float."
> +*/
> + ERROR_IF((types_are_mixed_float(dst_type, src0_type) &&
> + brw_inst_src0_address_mode(devinfo, inst) !=
> BRW_ADDRESS_DIRECT) ||
> +(num_sources > 1 &&
> + types_are_mixed_float(dst_type, src1_type) &&
> + brw_inst_src1_address_mode(devinfo, inst) !=
> BRW_ADDRESS_DIRECT),
> +"Indirect addressing on source is not supported when source and "
> +"destination data types are mixed float");
> +
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is f32. Instruction
> +* execution size must be no more than 8.
Re: [Mesa-dev] Mesa compatibility range
Not really answering your question directly but Desktop chips have had 2.1 support for the past 12+ years. IMO trying to support systems older than that is going to be more trouble than its worth, llvmpipe is unlikely to give you very good performance on a system that old. On 11/4/19 1:37 am, Jonathan Jackson wrote: Hi all, I am currently building an application using VTK 8.1 which requires OpenGL 2.1, or more recent, Support. Because I want to be able to run my application on as many systems as possible, I am Contemplating using a software renderer for cases where the system does not support OpenGL 2.1. As Mesa is already offered on linux, this is mostly a Windows question. 1.My question is: Is it reasonable to think that llvmpipe (or other drivers) will grand me a much wider array of supported system if I use that implementation over the original Windows one? It would mean that systems that have no support for OpenGL 2.1 would benefit from using Mesa over Windows’ OpenGL and that Mesa is usable on much older/weaker systems. 2.Another way to ask the question is: Is there a way of knowing which specs a system is required to have so it can support Mesa’s implementation of all of OpenGL 2.1? (is it common that a system(high or low end) will support all of Mesa’s equivalents of OpenGL 2.1 features). Thank you for your support. Jonathan Jackson ___ 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 v6 30/35] intel/compiler: validate region restrictions for half-float conversions
"Juan A. Suarez Romero" writes:
> From: Iago Toral Quiroga
>
> v2:
> - Consider implicit conversions in 2-src instructions too (Curro)
> - For restrictions that involve destination stride requirements
>only validate them for Align1, since Align16 always requires
>packed data.
> - Skip general rule for the dst/execution type size ratio for
>mixed float instructions on CHV and SKL+, these have their own
>set of rules that we'll be validated separately.
>
> v3 (Curro):
> - Do not check src1 type in single-source instructions.
> - Check restriction on src1.
> - Remove invalid test.
Reviewed-by: Francisco Jerez
> ---
> src/intel/compiler/brw_eu_validate.c| 155 +++-
> src/intel/compiler/test_eu_validate.cpp | 116 ++
> 2 files changed, 270 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_eu_validate.c
> b/src/intel/compiler/brw_eu_validate.c
> index bd0e48a5e5c..54bffb3af03 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -469,6 +469,66 @@ is_packed(unsigned vstride, unsigned width, unsigned
> hstride)
> return false;
> }
>
> +/**
> + * Returns whether an instruction is an explicit or implicit conversion
> + * to/from half-float.
> + */
> +static bool
> +is_half_float_conversion(const struct gen_device_info *devinfo,
> + const brw_inst *inst)
> +{
> + enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> +
> + unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> +
> + if (dst_type != src0_type &&
> + (dst_type == BRW_REGISTER_TYPE_HF || src0_type ==
> BRW_REGISTER_TYPE_HF)) {
> + return true;
> + } else if (num_sources > 1) {
> + enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
> + return dst_type != src1_type &&
> +(dst_type == BRW_REGISTER_TYPE_HF ||
> + src1_type == BRW_REGISTER_TYPE_HF);
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Returns whether an instruction is using mixed float operation mode
> + */
> +static bool
> +is_mixed_float(const struct gen_device_info *devinfo, const brw_inst *inst)
> +{
> + if (devinfo->gen < 8)
> + return false;
> +
> + if (inst_is_send(devinfo, inst))
> + return false;
> +
> + unsigned opcode = brw_inst_opcode(devinfo, inst);
> + const struct opcode_desc *desc = brw_opcode_desc(devinfo, opcode);
> + if (desc->ndst == 0)
> + return false;
> +
> + /* FIXME: support 3-src instructions */
> + unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + assert(num_sources < 3);
> +
> + enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> +
> + if (num_sources == 1)
> + return types_are_mixed_float(src0_type, dst_type);
> +
> + enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
> +
> + return types_are_mixed_float(src0_type, src1_type) ||
> + types_are_mixed_float(src0_type, dst_type) ||
> + types_are_mixed_float(src1_type, dst_type);
> +}
> +
> /**
> * Checks restrictions listed in "General Restrictions Based on Operand
> Types"
> * in the "Register Region Restrictions" section.
> @@ -539,7 +599,100 @@ general_restrictions_based_on_operand_types(const
> struct gen_device_info *devinf
> exec_type_size == 8 && dst_type_size == 4)
>dst_type_size = 8;
>
> - if (exec_type_size > dst_type_size) {
> + if (is_half_float_conversion(devinfo, inst)) {
> + /**
> + * A helper to validate used in the validation of the following
> restriction
> + * from the BDW+ PRM, Volume 2a, Command Reference, Instructions - MOV:
> + *
> + *"There is no direct conversion from HF to DF or DF to HF.
> + * There is no direct conversion from HF to Q/UQ or Q/UQ to HF."
> + *
> + * Even if these restrictions are listed for the MOV instruction, we
> + * validate this more generally, since there is the possibility
> + * of implicit conversions from other instructions, such us implicit
> + * conversion from integer to HF with the ADD instruction in SKL+.
> + */
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> + enum brw_reg_type src1_type = num_sources > 1 ?
> +brw_inst_src1_type(devinfo, inst) : 0;
> + ERROR_IF(dst_type == BRW_REGISTER_TYPE_HF &&
> + (type_sz(src0_type) == 8 ||
> +(num_sources > 1 && type_sz(src1_type) == 8)),
> + "There are no direct conversions between 64-bit types and
> HF");
> +
> + ERROR_IF(type_sz(dst_type) == 8 &&
> + (src0_type == BRW_REGISTER_TYPE_HF ||
> +(num_sources > 1 && src1_type == BRW_REGISTER_TYPE_HF)),
> + "The
Re: [Mesa-dev] [PATCH 10/10] ac/nir: remove some useless integer casts for ALU operations
Before I attempt to review, have you run piglit on this series with radeonsi nir? On 11/4/19 1:16 am, Samuel Pitoiset wrote: Sources are always casted to integers. Signed-off-by: Samuel Pitoiset --- src/amd/common/ac_nir_to_llvm.c | 16 1 file changed, 16 deletions(-) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 3dfcbacdef4..f1c082c1130 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -874,13 +874,11 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) case nir_op_i2f16: case nir_op_i2f32: case nir_op_i2f64: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = LLVMBuildSIToFP(ctx->ac.builder, src[0], ac_to_float_type(&ctx->ac, def_type), ""); break; case nir_op_u2f16: case nir_op_u2f32: case nir_op_u2f64: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = LLVMBuildUIToFP(ctx->ac.builder, src[0], ac_to_float_type(&ctx->ac, def_type), ""); break; case nir_op_f2f16_rtz: @@ -905,7 +903,6 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) case nir_op_u2u16: case nir_op_u2u32: case nir_op_u2u64: - src[0] = ac_to_integer(&ctx->ac, src[0]); if (ac_get_elem_bits(&ctx->ac, LLVMTypeOf(src[0])) < ac_get_elem_bits(&ctx->ac, def_type)) result = LLVMBuildZExt(ctx->ac.builder, src[0], def_type, ""); else @@ -915,7 +912,6 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) case nir_op_i2i16: case nir_op_i2i32: case nir_op_i2i64: - src[0] = ac_to_integer(&ctx->ac, src[0]); if (ac_get_elem_bits(&ctx->ac, LLVMTypeOf(src[0])) < ac_get_elem_bits(&ctx->ac, def_type)) result = LLVMBuildSExt(ctx->ac.builder, src[0], def_type, ""); else @@ -925,25 +921,18 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) result = emit_bcsel(&ctx->ac, src[0], src[1], src[2]); break; case nir_op_find_lsb: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = ac_find_lsb(&ctx->ac, ctx->ac.i32, src[0]); break; case nir_op_ufind_msb: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = ac_build_umsb(&ctx->ac, src[0], ctx->ac.i32); break; case nir_op_ifind_msb: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = ac_build_imsb(&ctx->ac, src[0], ctx->ac.i32); break; case nir_op_uadd_carry: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_uint_carry(&ctx->ac, "llvm.uadd.with.overflow.i32", src[0], src[1]); break; case nir_op_usub_borrow: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_uint_carry(&ctx->ac, "llvm.usub.with.overflow.i32", src[0], src[1]); break; case nir_op_b2f16: @@ -961,20 +950,15 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) result = emit_b2i(&ctx->ac, src[0], instr->dest.dest.ssa.bit_size); break; case nir_op_i2b32: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = emit_i2b(&ctx->ac, src[0]); break; case nir_op_fquantize2f16: result = emit_f2f16(&ctx->ac, src[0]); break; case nir_op_umul_high: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_umul_high(&ctx->ac, src[0], src[1]); break; case nir_op_imul_high: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_imul_high(&ctx->ac, src[0], src[1]); break; case nir_op_pack_half_2x16: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: initialise some variables in opt_if_loop_last_continue()
Fixes a couple of Coverity warnings CID 1444626.
Fixes: e30804c6024f ("nir/radv: remove restrictions on
opt_if_loop_last_continue()")
---
src/compiler/nir/nir_opt_if.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 713bdf0c38a..d0aaf9f7133 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -839,8 +839,8 @@ static bool
opt_if_loop_last_continue(nir_loop *loop, bool aggressive_last_continue)
{
nir_if *nif;
- bool then_ends_in_continue;
- bool else_ends_in_continue;
+ bool then_ends_in_continue = false;
+ bool else_ends_in_continue = false;
/* Scan the control flow of the loop from the last to the first node
* looking for an if-statement we can optimise.
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110337] Mesa 19.0.0(1)
https://bugs.freedesktop.org/show_bug.cgi?id=110337 --- Comment #2 from Andre Klapper --- Hi Berg, please edit the ticket summary and summarize the actual topic of this ticket. Thanks! -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] anv/ehl: 36bits ppgtt support
From: "Xiong, James"
The vma high heap's capacity and maximum address were pre-defined based
on 48bits ppgtt support, and the buffers allocated from the vma high heap
had invalid vma addresses to the ehl platform that only supports 36bits
ppgtt. As a result, KMD rejected all batchbuffers submitted by vulkan.
This patch:
1) initializes the vma high heap by retrieving the gtt capacity from KMD
and calculating the size and max address on the fly.
2) enables softpin when full ppgtt is enabled
V2: change commit messages and comments to refect the changes [Bob, Jason]
remove define HIGH_HEAP_SIZE [Bob]
make sure there's enough space to enable softspin [Jason]
Signed-off-by: Xiong, James
---
src/intel/vulkan/anv_device.c | 30 +++---
src/intel/vulkan/anv_private.h | 7 ---
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 88b34c4..c3eff1c 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -434,7 +434,12 @@ anv_physical_device_init(struct anv_physical_device
*device,
anv_gem_supports_syncobj_wait(fd);
device->has_context_priority = anv_gem_has_context_priority(fd);
+ /*
+* make sure there are enough VA space(i.e. 32+bit support) and full ggtt
+* is enabled.
+*/
device->use_softpin = anv_gem_get_param(fd, I915_PARAM_HAS_EXEC_SOFTPIN)
+ && (anv_gem_get_param(fd, I915_PARAM_HAS_ALIASING_PPGTT) > 1)
&& device->supports_48bit_addresses;
device->has_context_isolation =
@@ -1981,14 +1986,25 @@ VkResult anv_CreateDevice(
device->vma_lo_available =
physical_device->memory.heaps[physical_device->memory.heap_count -
1].size;
- /* Leave the last 4GiB out of the high vma range, so that no state base
- * address + size can overflow 48 bits. For more information see the
- * comment about Wa32bitGeneralStateOffset in anv_allocator.c
- */
- util_vma_heap_init(&device->vma_hi, HIGH_HEAP_MIN_ADDRESS,
- HIGH_HEAP_SIZE);
device->vma_hi_available = physical_device->memory.heap_count == 1 ? 0 :
physical_device->memory.heaps[0].size;
+
+ /* Retrieve the GTT's capacity and leave the last 4GiB out of the high
vma
+ * range, so that no state base address + size can overflow the vma
range. For
+ * more information see the comment about Wa32bitGeneralStateOffset in
+ * anv_allocator.c
+ */
+ uint64_t size = 0;
+ anv_gem_get_context_param(device->fd, 0, I915_CONTEXT_PARAM_GTT_SIZE,
+&size);
+ if(size > HIGH_HEAP_MIN_ADDRESS + (1ull<<32)) {
+ size -= HIGH_HEAP_MIN_ADDRESS + (1ull<<32);
+ device->vma_hi_max_addr = HIGH_HEAP_MIN_ADDRESS + size - 1;
+ } else {
+ size = device->vma_hi_max_addr = 0;
+ }
+
+ util_vma_heap_init(&device->vma_hi, HIGH_HEAP_MIN_ADDRESS, size);
}
/* As per spec, the driver implementation may deny requests to acquire
@@ -2456,7 +2472,7 @@ anv_vma_free(struct anv_device *device, struct anv_bo *bo)
device->vma_lo_available += bo->size;
} else {
assert(addr_48b >= HIGH_HEAP_MIN_ADDRESS &&
- addr_48b <= HIGH_HEAP_MAX_ADDRESS);
+ addr_48b <= device->vma_hi_max_addr);
util_vma_heap_free(&device->vma_hi, addr_48b, bo->size);
device->vma_hi_available += bo->size;
}
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 1664918..ef9b012 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -109,6 +109,9 @@ struct gen_l3_config;
* heap. Various hardware units will read past the end of an object for
* various reasons. This healthy margin prevents reads from wrapping around
* 48-bit addresses.
+ *
+ * (4) the high vma heap size and max address are calculated based on the
+ * gtt capacity retrieved from KMD.
*/
#define LOW_HEAP_MIN_ADDRESS 0x1000ULL /* 4 KiB */
#define LOW_HEAP_MAX_ADDRESS 0xbfffULL
@@ -121,12 +124,9 @@ struct gen_l3_config;
#define INSTRUCTION_STATE_POOL_MIN_ADDRESS 0x00018000ULL /* 6 GiB */
#define INSTRUCTION_STATE_POOL_MAX_ADDRESS 0x0001bfffULL
#define HIGH_HEAP_MIN_ADDRESS 0x0001c000ULL /* 7 GiB */
-#define HIGH_HEAP_MAX_ADDRESS 0xfffeULL
#define LOW_HEAP_SIZE \
(LOW_HEAP_MAX_ADDRESS - LOW_HEAP_MIN_ADDRESS + 1)
-#define HIGH_HEAP_SIZE \
- (HIGH_HEAP_MAX_ADDRESS - HIGH_HEAP_MIN_ADDRESS + 1)
#define DYNAMIC_STATE_POOL_SIZE \
(DYNAMIC_STATE_POOL_MAX_ADDRESS - DYNAMIC_STATE_POOL_MIN_ADDRESS + 1)
#define BINDING_TABLE_POOL_SIZE \
@@ -1093,6 +1093,7 @@ struct anv_device {
struct util_vma_heapvma_hi;
uint64_tvma_lo_available;
uint64_t
Re: [Mesa-dev] [PATCH v7 28/35] intel/compiler: implement SIMD16 restrictions for mixed-float instructions
Iago Toral writes:
> On Mon, 2019-04-08 at 12:00 -0700, Francisco Jerez wrote:
>> "Juan A. Suarez Romero" writes:
>>
>> > From: Iago Toral Quiroga
>> >
>> > v2: f32to16/f16to32 can use a :W destination (Curro)
>> > ---
>> > src/intel/compiler/brw_fs.cpp | 71
>> > +++
>> > 1 file changed, 71 insertions(+)
>> >
>> > diff --git a/src/intel/compiler/brw_fs.cpp
>> > b/src/intel/compiler/brw_fs.cpp
>> > index d4803c63b93..48b5cc6c403 100644
>> > --- a/src/intel/compiler/brw_fs.cpp
>> > +++ b/src/intel/compiler/brw_fs.cpp
>> > @@ -5606,6 +5606,48 @@ fs_visitor::lower_logical_sends()
>> > return progress;
>> > }
>> >
>> > +static bool
>> > +is_mixed_float_with_fp32_dst(const fs_inst *inst)
>> > +{
>> > + /* This opcode sometimes uses :W type on the source even if the
>> > operand is
>> > +* a :HF, because in gen7 there is no support for :HF, and thus
>> > it uses :W.
>> > +*/
>> > + if (inst->opcode == BRW_OPCODE_F16TO32)
>> > + return true;
>> > +
>> > + if (inst->dst.type != BRW_REGISTER_TYPE_F)
>> > + return false;
>> > +
>> > + for (int i = 0; i < inst->sources; i++) {
>> > + if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
>> > + return true;
>> > + }
>> > +
>> > + return false;
>> > +}
>> > +
>> > +static bool
>> > +is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
>> > +{
>> > + /* This opcode sometimes uses :W type on the destination even
>> > if the
>> > +* destination is a :HF, because in gen7 there is no support
>> > for :HF, and
>> > +* thus it uses :W.
>> > +*/
>> > + if (inst->opcode == BRW_OPCODE_F32TO16)
>>
>> Don't you need to check whether the destination is packed here?
>
> Yes, we also need that, like in the code below.
>
Patch would be Reviewed-by: Francisco Jerez with
that change.
>> > + return true;
>> > +
>> > + if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
>> > + inst->dst.stride != 1)
>> > + return false;
>> > +
>> > + for (int i = 0; i < inst->sources; i++) {
>> > + if (inst->src[i].type == BRW_REGISTER_TYPE_F)
>> > + return true;
>> > + }
>> > +
>> > + return false;
>> > +}
>> > +
>> > /**
>> > * Get the closest allowed SIMD width for instruction \p inst
>> > accounting for
>> > * some common regioning and execution control restrictions that
>> > apply to FPU
>> > @@ -5768,6 +5810,35 @@ get_fpu_lowered_simd_width(const struct
>> > gen_device_info *devinfo,
>> > max_width = MIN2(max_width, 4);
>> > }
>> >
>> > + /* From the SKL PRM, Special Restrictions for Handling Mixed
>> > Mode
>> > +* Float Operations:
>> > +*
>> > +*"No SIMD16 in mixed mode when destination is f32.
>> > Instruction
>> > +* execution size must be no more than 8."
>> > +*
>> > +* FIXME: the simulator doesn't seem to complain if we don't do
>> > this and
>> > +* empirical testing with existing CTS tests show that they
>> > pass just fine
>> > +* without implementing this, however, since our interpretation
>> > of the PRM
>> > +* is that conversion MOVs between HF and F are still mixed-
>> > float
>> > +* instructions (and therefore subject to this restriction) we
>> > decided to
>> > +* split them to be safe. Might be useful to do additional
>> > investigation to
>> > +* lift the restriction if we can ensure that it is safe
>> > though, since these
>> > +* conversions are common when half-float types are involved
>> > since many
>> > +* instructions do not support HF types and conversions from/to
>> > F are
>> > +* required.
>> > +*/
>> > + if (is_mixed_float_with_fp32_dst(inst))
>> > + max_width = MIN2(max_width, 8);
>> > +
>> > + /* From the SKL PRM, Special Restrictions for Handling Mixed
>> > Mode
>> > +* Float Operations:
>> > +*
>> > +*"No SIMD16 in mixed mode when destination is packed f16
>> > for both
>> > +* Align1 and Align16."
>> > +*/
>> > + if (is_mixed_float_with_packed_fp16_dst(inst))
>> > + max_width = MIN2(max_width, 8);
>> > +
>> > /* Only power-of-two execution sizes are representable in the
>> > instruction
>> > * control fields.
>> > */
>> > --
>> > 2.20.1
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Partially revert "gallium: fix autotools build of pipe_msm.la"
On Tue, Apr 9, 2019 at 5:36 PM Vinson Lee wrote: > > On Tue, Apr 9, 2019 at 1:29 PM Jan Vesely wrote: > > > > On Sat, Apr 6, 2019 at 10:11 PM Dieter Nützel wrote: > > > > > > Tested-by: Dieter Nützel > > > Acked-by: Dieter Nützel > > > > Thanks Dieter, > > > > Timur, Vinson, are you OK with this temporary solution? > > > > Jan > > > > Tested-by: Vinson Lee thanks to both of you. pushed. Jan > > > > > > > Thank you Jan! > > > > > > BTW More about 'meson' with radeonsi and Clover in some hours. > > > > > > Dieter > > > > > > Am 06.04.2019 06:43, schrieb Jan Vesely: > > > > This partially reverts commit 356ec7a21960d77db282f67af577dcdb46966b5a. > > > > There are missing symbols needed by libglsl, so we might as well skip > > > > the entire library (which should be present in the mesa stat tracker). > > > > > > > > Signed-off-by: Jan Vesely > > > > --- > > > > > > > > Hi Timur, Vinson, > > > > > > > > this patch is enough to get clover working again in autotools build, > > > > until a proper solution lands (which should reinstate -Wl,-no-undefined > > > > for pipe drivers). > > > > Vinson, I tested freedreno and it builds, but I don't have hw to test > > > > anything more, let me know if things still work or you with this patch. > > > > > > > > regards, > > > > Jan > > > > > > > > src/gallium/targets/pipe-loader/Makefile.am | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/src/gallium/targets/pipe-loader/Makefile.am > > > > b/src/gallium/targets/pipe-loader/Makefile.am > > > > index 807a100a7d0..864ee8d50d3 100644 > > > > --- a/src/gallium/targets/pipe-loader/Makefile.am > > > > +++ b/src/gallium/targets/pipe-loader/Makefile.am > > > > @@ -53,7 +53,8 @@ endif > > > > > > > > PIPE_LIBS += \ > > > > $(top_builddir)/src/gallium/auxiliary/libgallium.la \ > > > > - $(top_builddir)/src/compiler/glsl/libglsl.la \ > > > > + $(top_builddir)/src/compiler/nir/libnir.la \ > > > > + $(top_builddir)/src/util/libmesautil.la \ > > > > $(GALLIUM_COMMON_LIB_DEPS) > > > > > > > > AM_LDFLAGS = \ > > > ___ > > > 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] [Bug 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 --- Comment #7 from Thomas Rohloff --- Thanks for all the helpful advice. Sadly I still didn't find a way to reproduce it better. Anyway, I tried your env var for around 8 hours without a freeze. While that might be just luck I'll do more testing (just started a replay with only two of the four options to let it run overnight). Hopefully it will pinpoint which of the four options does the trick, so expect a new reply in two to four days. :) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107391] feature request: enforceable vsync and anisotropic filtering via environment variables
https://bugs.freedesktop.org/show_bug.cgi?id=107391 --- Comment #8 from tempel.jul...@gmail.com --- I've tested it in vkquake, works like a charm. Again: Huge thanks! -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110252] swr software rasterizer fall back to OpenGL 2.1
https://bugs.freedesktop.org/show_bug.cgi?id=110252 --- Comment #1 from Alok Hota --- Thanks for reporting this, and for the sample program. We are looking into this. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa compatibility range
Hi all, I am currently building an application using VTK 8.1 which requires OpenGL 2.1, or more recent, Support. Because I want to be able to run my application on as many systems as possible, I am Contemplating using a software renderer for cases where the system does not support OpenGL 2.1. As Mesa is already offered on linux, this is mostly a Windows question. 1. My question is: Is it reasonable to think that llvmpipe (or other drivers) will grand me a much wider array of supported system if I use that implementation over the original Windows one? It would mean that systems that have no support for OpenGL 2.1 would benefit from using Mesa over Windows’ OpenGL and that Mesa is usable on much older/weaker systems. 2. Another way to ask the question is: Is there a way of knowing which specs a system is required to have so it can support Mesa’s implementation of all of OpenGL 2.1? (is it common that a system(high or low end) will support all of Mesa’s equivalents of OpenGL 2.1 features). Thank you for your support. Jonathan Jackson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] ac/nir: remove some useless integer casts for ALU operations
Sources are always casted to integers. Signed-off-by: Samuel Pitoiset --- src/amd/common/ac_nir_to_llvm.c | 16 1 file changed, 16 deletions(-) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 3dfcbacdef4..f1c082c1130 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -874,13 +874,11 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) case nir_op_i2f16: case nir_op_i2f32: case nir_op_i2f64: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = LLVMBuildSIToFP(ctx->ac.builder, src[0], ac_to_float_type(&ctx->ac, def_type), ""); break; case nir_op_u2f16: case nir_op_u2f32: case nir_op_u2f64: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = LLVMBuildUIToFP(ctx->ac.builder, src[0], ac_to_float_type(&ctx->ac, def_type), ""); break; case nir_op_f2f16_rtz: @@ -905,7 +903,6 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) case nir_op_u2u16: case nir_op_u2u32: case nir_op_u2u64: - src[0] = ac_to_integer(&ctx->ac, src[0]); if (ac_get_elem_bits(&ctx->ac, LLVMTypeOf(src[0])) < ac_get_elem_bits(&ctx->ac, def_type)) result = LLVMBuildZExt(ctx->ac.builder, src[0], def_type, ""); else @@ -915,7 +912,6 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) case nir_op_i2i16: case nir_op_i2i32: case nir_op_i2i64: - src[0] = ac_to_integer(&ctx->ac, src[0]); if (ac_get_elem_bits(&ctx->ac, LLVMTypeOf(src[0])) < ac_get_elem_bits(&ctx->ac, def_type)) result = LLVMBuildSExt(ctx->ac.builder, src[0], def_type, ""); else @@ -925,25 +921,18 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) result = emit_bcsel(&ctx->ac, src[0], src[1], src[2]); break; case nir_op_find_lsb: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = ac_find_lsb(&ctx->ac, ctx->ac.i32, src[0]); break; case nir_op_ufind_msb: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = ac_build_umsb(&ctx->ac, src[0], ctx->ac.i32); break; case nir_op_ifind_msb: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = ac_build_imsb(&ctx->ac, src[0], ctx->ac.i32); break; case nir_op_uadd_carry: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_uint_carry(&ctx->ac, "llvm.uadd.with.overflow.i32", src[0], src[1]); break; case nir_op_usub_borrow: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_uint_carry(&ctx->ac, "llvm.usub.with.overflow.i32", src[0], src[1]); break; case nir_op_b2f16: @@ -961,20 +950,15 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) result = emit_b2i(&ctx->ac, src[0], instr->dest.dest.ssa.bit_size); break; case nir_op_i2b32: - src[0] = ac_to_integer(&ctx->ac, src[0]); result = emit_i2b(&ctx->ac, src[0]); break; case nir_op_fquantize2f16: result = emit_f2f16(&ctx->ac, src[0]); break; case nir_op_umul_high: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_umul_high(&ctx->ac, src[0], src[1]); break; case nir_op_imul_high: - src[0] = ac_to_integer(&ctx->ac, src[0]); - src[1] = ac_to_integer(&ctx->ac, src[1]); result = emit_imul_high(&ctx->ac, src[0], src[1]); break; case nir_op_pack_half_2x16: -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] ac: add ac_build_ddxy_interp() helper
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 20 ++
src/amd/common/ac_llvm_build.h | 3 +++
src/amd/common/ac_nir_to_llvm.c | 23 +---
src/gallium/drivers/radeonsi/si_shader.c | 27 +---
4 files changed, 25 insertions(+), 48 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 6a1ba5de0e0..d305af280d5 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -4037,3 +4037,23 @@ ac_build_frexp_mant(struct ac_llvm_context *ctx,
LLVMValueRef src0,
return ac_build_intrinsic(ctx, intr, type, params, 1,
AC_FUNC_ATTR_READNONE);
}
+
+/*
+ * this takes an I,J coordinate pair,
+ * and works out the X and Y derivatives.
+ * it returns DDX(I), DDX(J), DDY(I), DDY(J).
+ */
+LLVMValueRef
+ac_build_ddxy_interp(struct ac_llvm_context *ctx, LLVMValueRef interp_ij)
+{
+ LLVMValueRef result[4], a;
+ unsigned i;
+
+ for (i = 0; i < 2; i++) {
+ a = LLVMBuildExtractElement(ctx->builder, interp_ij,
+ LLVMConstInt(ctx->i32, i, false),
"");
+ result[i] = ac_build_ddxy(ctx, AC_TID_MASK_TOP_LEFT, 1, a);
+ result[2+i] = ac_build_ddxy(ctx, AC_TID_MASK_TOP_LEFT, 2, a);
+ }
+ return ac_build_gather_values(ctx, result, 4);
+}
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 61689f6a07e..64b6894538e 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -686,6 +686,9 @@ LLVMValueRef
ac_build_frexp_mant(struct ac_llvm_context *ctx, LLVMValueRef src0,
unsigned bitsize);
+LLVMValueRef
+ac_build_ddxy_interp(struct ac_llvm_context *ctx, LLVMValueRef interp_ij);
+
#ifdef __cplusplus
}
#endif
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 1287507628a..733c535c378 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -540,27 +540,6 @@ static LLVMValueRef emit_ddxy(struct ac_nir_context *ctx,
return result;
}
-/*
- * this takes an I,J coordinate pair,
- * and works out the X and Y derivatives.
- * it returns DDX(I), DDX(J), DDY(I), DDY(J).
- */
-static LLVMValueRef emit_ddxy_interp(
- struct ac_nir_context *ctx,
- LLVMValueRef interp_ij)
-{
- LLVMValueRef result[4], a;
- unsigned i;
-
- for (i = 0; i < 2; i++) {
- a = LLVMBuildExtractElement(ctx->ac.builder, interp_ij,
- LLVMConstInt(ctx->ac.i32, i,
false), "");
- result[i] = emit_ddxy(ctx, nir_op_fddx, a);
- result[2+i] = emit_ddxy(ctx, nir_op_fddy, a);
- }
- return ac_build_gather_values(&ctx->ac, result, 4);
-}
-
static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr)
{
LLVMValueRef src[4], result = NULL;
@@ -3038,7 +3017,7 @@ static LLVMValueRef visit_interp(struct ac_nir_context
*ctx,
if (location == INTERP_CENTER) {
LLVMValueRef ij_out[2];
- LLVMValueRef ddxy_out = emit_ddxy_interp(ctx, interp_param);
+ LLVMValueRef ddxy_out = ac_build_ddxy_interp(&ctx->ac,
interp_param);
/*
* take the I then J parameters, and the DDX/Y for it, and
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index efae02ee91c..8ebc8d39e99 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -3924,31 +3924,6 @@ static void si_llvm_emit_ddxy(
emit_data->output[emit_data->chan] = val;
}
-/*
- * this takes an I,J coordinate pair,
- * and works out the X and Y derivatives.
- * it returns DDX(I), DDX(J), DDY(I), DDY(J).
- */
-static LLVMValueRef si_llvm_emit_ddxy_interp(
- struct lp_build_tgsi_context *bld_base,
- LLVMValueRef interp_ij)
-{
- struct si_shader_context *ctx = si_shader_context(bld_base);
- LLVMValueRef result[4], a;
- unsigned i;
-
- for (i = 0; i < 2; i++) {
- a = LLVMBuildExtractElement(ctx->ac.builder, interp_ij,
- LLVMConstInt(ctx->i32, i, 0), "");
- result[i] = ac_build_ddxy(&ctx->ac, AC_TID_MASK_TOP_LEFT, 1,
- ac_to_integer(&ctx->ac, a)); /* DDX */
- result[2+i] = ac_build_ddxy(&ctx->ac, AC_TID_MASK_TOP_LEFT, 2,
- ac_to_integer(&ctx->ac, a)); /* DDY
*/
- }
-
- return ac_build_gather_values(&ctx->ac, result, 4);
-}
-
static void build_interp_intrinsic(const struct lp_build_tgsi_action *action,
struct lp_build_tgsi_context *bld_base,
struct lp_build_emit_data *emit_data)
@@ -4062,7
[Mesa-dev] [PATCH 09/10] ac/nir: remove useless integer cast in visit_image_load()
ac_build_image_opcode() casts if necessary and buffer images are casted too. Signed-off-by: Samuel Pitoiset --- src/amd/common/ac_nir_to_llvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index cef665d0630..3dfcbacdef4 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -2535,7 +2535,7 @@ static LLVMValueRef visit_image_load(struct ac_nir_context *ctx, res = ac_build_image_opcode(&ctx->ac, &args); } - return ac_to_integer(&ctx->ac, res); + return res; } static void visit_image_store(struct ac_nir_context *ctx, -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] ac/nir: make use of ac_build_umin() where possible
This changes the predicate from LessThan to Equal.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3d90fd42318..69c418f2ca0 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -757,7 +757,7 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = emit_minmax_int(&ctx->ac, LLVMIntUGT, src[0], src[1]);
break;
case nir_op_umin:
- result = emit_minmax_int(&ctx->ac, LLVMIntULT, src[0], src[1]);
+ result = ac_build_umin(&ctx->ac, src[0], src[1]);
break;
case nir_op_isign:
result = ac_build_isign(&ctx->ac, src[0],
@@ -1105,8 +1105,8 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
ac_to_float_type(&ctx->ac,
def_type), result, src[2]);
break;
case nir_op_umin3:
- result = emit_minmax_int(&ctx->ac, LLVMIntULT, src[0], src[1]);
- result = emit_minmax_int(&ctx->ac, LLVMIntULT, result, src[2]);
+ result = ac_build_umin(&ctx->ac, src[0], src[1]);
+ result = ac_build_umin(&ctx->ac, result, src[2]);
break;
case nir_op_imin3:
result = ac_build_imin(&ctx->ac, src[0], src[1]);
@@ -1142,9 +1142,9 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
break;
}
case nir_op_umed3: {
- LLVMValueRef tmp1 = emit_minmax_int(&ctx->ac, LLVMIntULT,
src[0], src[1]);
+ LLVMValueRef tmp1 = ac_build_umin(&ctx->ac, src[0], src[1]);
LLVMValueRef tmp2 = emit_minmax_int(&ctx->ac, LLVMIntUGT,
src[0], src[1]);
- tmp2 = emit_minmax_int(&ctx->ac, LLVMIntULT, tmp2, src[2]);
+ tmp2 = ac_build_umin(&ctx->ac, tmp2, src[2]);
result = emit_minmax_int(&ctx->ac, LLVMIntUGT, tmp1, tmp2);
break;
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] ac/nir: remove useles LLVMGetUndef for nir_op_pack_64_2x32_split
Trivial.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index c29098bf179..0318786d25b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1013,8 +1013,7 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
}
case nir_op_pack_64_2x32_split: {
- LLVMValueRef tmp = LLVMGetUndef(ctx->ac.v2i32);
- tmp = ac_build_gather_values(&ctx->ac, src, 2);
+ LLVMValueRef tmp = ac_build_gather_values(&ctx->ac, src, 2);
result = LLVMBuildBitCast(ctx->ac.builder, tmp, ctx->ac.i64,
"");
break;
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] ac/nir: remove useless integer cast in adjust_sample_index_using_fmask()
It's already casted if necessary in ac_build_image_opcode(). Signed-off-by: Samuel Pitoiset --- src/amd/common/ac_nir_to_llvm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 0318786d25b..cef665d0630 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -2334,7 +2334,6 @@ static LLVMValueRef adjust_sample_index_using_fmask(struct ac_llvm_context *ctx, res = ac_build_image_opcode(ctx, &args); - res = ac_to_integer(ctx, res); LLVMValueRef four = LLVMConstInt(ctx->i32, 4, false); LLVMValueRef F = LLVMConstInt(ctx->i32, 0xf, false); -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] ac: add ac_build_load_helper_invocation() helper
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 10 ++
src/amd/common/ac_llvm_build.h | 3 +++
src/amd/common/ac_nir_to_llvm.c | 13 +
src/gallium/drivers/radeonsi/si_shader.c | 7 +--
4 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index d305af280d5..19496519165 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -4057,3 +4057,13 @@ ac_build_ddxy_interp(struct ac_llvm_context *ctx,
LLVMValueRef interp_ij)
}
return ac_build_gather_values(ctx, result, 4);
}
+
+LLVMValueRef
+ac_build_load_helper_invocation(struct ac_llvm_context *ctx)
+{
+ LLVMValueRef result = ac_build_intrinsic(ctx, "llvm.amdgcn.ps.live",
+ctx->i1, NULL, 0,
+AC_FUNC_ATTR_READNONE);
+ result = LLVMBuildNot(ctx->builder, result, "");
+ return LLVMBuildSExt(ctx->builder, result, ctx->i32, "");
+}
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 64b6894538e..debc029f192 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -689,6 +689,9 @@ ac_build_frexp_mant(struct ac_llvm_context *ctx,
LLVMValueRef src0,
LLVMValueRef
ac_build_ddxy_interp(struct ac_llvm_context *ctx, LLVMValueRef interp_ij);
+LLVMValueRef
+ac_build_load_helper_invocation(struct ac_llvm_context *ctx);
+
#ifdef __cplusplus
}
#endif
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 733c535c378..c29098bf179 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2790,17 +2790,6 @@ static void emit_discard(struct ac_nir_context *ctx,
ctx->abi->emit_kill(ctx->abi, cond);
}
-static LLVMValueRef
-visit_load_helper_invocation(struct ac_nir_context *ctx)
-{
- LLVMValueRef result = ac_build_intrinsic(&ctx->ac,
-"llvm.amdgcn.ps.live",
-ctx->ac.i1, NULL, 0,
-AC_FUNC_ATTR_READNONE);
- result = LLVMBuildNot(ctx->ac.builder, result, "");
- return LLVMBuildSExt(ctx->ac.builder, result, ctx->ac.i32, "");
-}
-
static LLVMValueRef
visit_load_local_invocation_index(struct ac_nir_context *ctx)
{
@@ -3214,7 +3203,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = ctx->abi->front_face;
break;
case nir_intrinsic_load_helper_invocation:
- result = visit_load_helper_invocation(ctx);
+ result = ac_build_load_helper_invocation(&ctx->ac);
break;
case nir_intrinsic_load_instance_id:
result = ctx->abi->instance_id;
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 8ebc8d39e99..d783555ca33 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2218,12 +2218,7 @@ void si_load_system_value(struct si_shader_context *ctx,
break;
case TGSI_SEMANTIC_HELPER_INVOCATION:
- value = ac_build_intrinsic(&ctx->ac,
- "llvm.amdgcn.ps.live",
- ctx->i1, NULL, 0,
- AC_FUNC_ATTR_READNONE);
- value = LLVMBuildNot(ctx->ac.builder, value, "");
- value = LLVMBuildSExt(ctx->ac.builder, value, ctx->i32, "");
+ value = ac_build_load_helper_invocation(&ctx->ac);
break;
case TGSI_SEMANTIC_SUBGROUP_SIZE:
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] ac/nir: make use of ac_build_imax() where possible
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3d2f738edec..7c7f2456e72 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -290,8 +290,7 @@ static LLVMValueRef emit_minmax_int(struct ac_llvm_context
*ctx,
static LLVMValueRef emit_iabs(struct ac_llvm_context *ctx,
LLVMValueRef src0)
{
- return emit_minmax_int(ctx, LLVMIntSGT, src0,
- LLVMBuildNeg(ctx->builder, src0, ""));
+ return ac_build_imax(ctx, src0, LLVMBuildNeg(ctx->builder, src0, ""));
}
static LLVMValueRef emit_uint_carry(struct ac_llvm_context *ctx,
@@ -749,7 +748,7 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = emit_iabs(&ctx->ac, src[0]);
break;
case nir_op_imax:
- result = emit_minmax_int(&ctx->ac, LLVMIntSGT, src[0], src[1]);
+ result = ac_build_imax(&ctx->ac, src[0], src[1]);
break;
case nir_op_imin:
result = emit_minmax_int(&ctx->ac, LLVMIntSLT, src[0], src[1]);
@@ -1124,8 +1123,8 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = emit_minmax_int(&ctx->ac, LLVMIntUGT, result, src[2]);
break;
case nir_op_imax3:
- result = emit_minmax_int(&ctx->ac, LLVMIntSGT, src[0], src[1]);
- result = emit_minmax_int(&ctx->ac, LLVMIntSGT, result, src[2]);
+ result = ac_build_imax(&ctx->ac, src[0], src[1]);
+ result = ac_build_imax(&ctx->ac, result, src[2]);
break;
case nir_op_fmed3: {
src[0] = ac_to_float(&ctx->ac, src[0]);
@@ -1137,9 +1136,9 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
}
case nir_op_imed3: {
LLVMValueRef tmp1 = emit_minmax_int(&ctx->ac, LLVMIntSLT,
src[0], src[1]);
- LLVMValueRef tmp2 = emit_minmax_int(&ctx->ac, LLVMIntSGT,
src[0], src[1]);
+ LLVMValueRef tmp2 = ac_build_imax(&ctx->ac, src[0], src[1]);
tmp2 = emit_minmax_int(&ctx->ac, LLVMIntSLT, tmp2, src[2]);
- result = emit_minmax_int(&ctx->ac, LLVMIntSGT, tmp1, tmp2);
+ result = ac_build_imax(&ctx->ac, tmp1, tmp2);
break;
}
case nir_op_umed3: {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] ac/nir: make use of ac_build_imin() where possible
This changes the predicate from LessThan to Equal.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 7c7f2456e72..3d90fd42318 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -751,7 +751,7 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = ac_build_imax(&ctx->ac, src[0], src[1]);
break;
case nir_op_imin:
- result = emit_minmax_int(&ctx->ac, LLVMIntSLT, src[0], src[1]);
+ result = ac_build_imin(&ctx->ac, src[0], src[1]);
break;
case nir_op_umax:
result = emit_minmax_int(&ctx->ac, LLVMIntUGT, src[0], src[1]);
@@ -1109,8 +1109,8 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = emit_minmax_int(&ctx->ac, LLVMIntULT, result, src[2]);
break;
case nir_op_imin3:
- result = emit_minmax_int(&ctx->ac, LLVMIntSLT, src[0], src[1]);
- result = emit_minmax_int(&ctx->ac, LLVMIntSLT, result, src[2]);
+ result = ac_build_imin(&ctx->ac, src[0], src[1]);
+ result = ac_build_imin(&ctx->ac, result, src[2]);
break;
case nir_op_fmax3:
result = emit_intrin_2f_param(&ctx->ac, "llvm.maxnum",
@@ -1135,9 +1135,9 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
break;
}
case nir_op_imed3: {
- LLVMValueRef tmp1 = emit_minmax_int(&ctx->ac, LLVMIntSLT,
src[0], src[1]);
+ LLVMValueRef tmp1 = ac_build_imin(&ctx->ac, src[0], src[1]);
LLVMValueRef tmp2 = ac_build_imax(&ctx->ac, src[0], src[1]);
- tmp2 = emit_minmax_int(&ctx->ac, LLVMIntSLT, tmp2, src[2]);
+ tmp2 = ac_build_imin(&ctx->ac, tmp2, src[2]);
result = ac_build_imax(&ctx->ac, tmp1, tmp2);
break;
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] ac: add ac_build_umax() and use it where possible
This changes the predicate from LessThan to Equal.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 7 +++
src/amd/common/ac_llvm_build.h | 1 +
src/amd/common/ac_nir_to_llvm.c | 20 +---
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 3e3ca5c7fdb..6a1ba5de0e0 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2042,6 +2042,13 @@ LLVMValueRef ac_build_umin(struct ac_llvm_context *ctx,
LLVMValueRef a,
return LLVMBuildSelect(ctx->builder, cmp, a, b, "");
}
+LLVMValueRef ac_build_umax(struct ac_llvm_context *ctx, LLVMValueRef a,
+ LLVMValueRef b)
+{
+ LLVMValueRef cmp = LLVMBuildICmp(ctx->builder, LLVMIntUGE, a, b, "");
+ return LLVMBuildSelect(ctx->builder, cmp, a, b, "");
+}
+
LLVMValueRef ac_build_clamp(struct ac_llvm_context *ctx, LLVMValueRef value)
{
LLVMTypeRef t = LLVMTypeOf(value);
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index c3277fd2d13..61689f6a07e 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -443,6 +443,7 @@ LLVMValueRef ac_build_imin(struct ac_llvm_context *ctx,
LLVMValueRef a,
LLVMValueRef ac_build_imax(struct ac_llvm_context *ctx, LLVMValueRef a,
LLVMValueRef b);
LLVMValueRef ac_build_umin(struct ac_llvm_context *ctx, LLVMValueRef a,
LLVMValueRef b);
+LLVMValueRef ac_build_umax(struct ac_llvm_context *ctx, LLVMValueRef a,
LLVMValueRef b);
LLVMValueRef ac_build_clamp(struct ac_llvm_context *ctx, LLVMValueRef value);
struct ac_export_args {
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 69c418f2ca0..1287507628a 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -277,16 +277,6 @@ static LLVMValueRef emit_bcsel(struct ac_llvm_context *ctx,
ac_to_integer_or_pointer(ctx, src2), "");
}
-static LLVMValueRef emit_minmax_int(struct ac_llvm_context *ctx,
- LLVMIntPredicate pred,
- LLVMValueRef src0, LLVMValueRef src1)
-{
- return LLVMBuildSelect(ctx->builder,
- LLVMBuildICmp(ctx->builder, pred, src0, src1,
""),
- src0,
- src1, "");
-
-}
static LLVMValueRef emit_iabs(struct ac_llvm_context *ctx,
LLVMValueRef src0)
{
@@ -754,7 +744,7 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = ac_build_imin(&ctx->ac, src[0], src[1]);
break;
case nir_op_umax:
- result = emit_minmax_int(&ctx->ac, LLVMIntUGT, src[0], src[1]);
+ result = ac_build_umax(&ctx->ac, src[0], src[1]);
break;
case nir_op_umin:
result = ac_build_umin(&ctx->ac, src[0], src[1]);
@@ -1119,8 +1109,8 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
ac_to_float_type(&ctx->ac,
def_type), result, src[2]);
break;
case nir_op_umax3:
- result = emit_minmax_int(&ctx->ac, LLVMIntUGT, src[0], src[1]);
- result = emit_minmax_int(&ctx->ac, LLVMIntUGT, result, src[2]);
+ result = ac_build_umax(&ctx->ac, src[0], src[1]);
+ result = ac_build_umax(&ctx->ac, result, src[2]);
break;
case nir_op_imax3:
result = ac_build_imax(&ctx->ac, src[0], src[1]);
@@ -1143,9 +1133,9 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
}
case nir_op_umed3: {
LLVMValueRef tmp1 = ac_build_umin(&ctx->ac, src[0], src[1]);
- LLVMValueRef tmp2 = emit_minmax_int(&ctx->ac, LLVMIntUGT,
src[0], src[1]);
+ LLVMValueRef tmp2 = ac_build_umax(&ctx->ac, src[0], src[1]);
tmp2 = ac_build_umin(&ctx->ac, tmp2, src[2]);
- result = emit_minmax_int(&ctx->ac, LLVMIntUGT, tmp1, tmp2);
+ result = ac_build_umax(&ctx->ac, tmp1, tmp2);
break;
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [rfc] st/mesa: don't update fb state is raster discard is set.
On 04/10/2019 12:10 AM, Dave Airlie wrote:
From: Dave Airlie
This avoid softpipe trying to get image when no window has ever
been exposed, and no image will be exposed.
I'm not entirely sure this is correct or useful, but it definitely
helps with some softpipe get images when we haven't got a window.
---
src/mesa/state_tracker/st_atom.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c
index 49f79ad9d49..3aeb526e56b 100644
--- a/src/mesa/state_tracker/st_atom.c
+++ b/src/mesa/state_tracker/st_atom.c
@@ -246,6 +246,9 @@ void st_validate_state( struct st_context *st, enum
st_pipeline pipeline )
unreachable("Invalid pipeline specified");
}
+ if (ctx->RasterDiscard)
+ st->dirty &= ~ST_NEW_FB_STATE;
+
dirty = st->dirty & pipeline_mask;
if (!dirty)
return;
Yeah, this looks a little questionable.
Couldn't you add a check for ctx->RasterDiscard in
st_update_framebuffer_state() and no-op most of that function there?
I think you'd at least want to do this after flushing the bitmap and
readpix cache.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109764] [radv] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109764 --- Comment #4 from Shmerl --- (In reply to Samuel Pitoiset from comment #3) > What do you mean by 'cap'? Be able to limit to N FPS? Yes, that's the idea of the proposal. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 6/6] glsl/linker: check for xfb_offset aliasing
On Wed, Apr 10, 2019 at 7:31 AM Andres Gomez wrote: > On Wed, 2019-04-10 at 10:40 +1000, Timothy Arceri wrote: > > On 13/2/19 8:57 am, Andres Gomez wrote: > > > @@ -1764,6 +1765,8 @@ struct gl_transform_feedback_buffer > > > > > > uint32_t NumVaryings; > > > > > > + BITSET_WORD *UsedComponents; > > > > Please don't add new members here that are used only for compile time > > validation. Can be try to come up with a different solution to this please? > > v1 was trying to do this through a nested loop to avoid adding extra > data structures. IMO, the nested loop had a near O(N^2) behavior but > given the possible real max amount of loops, it shouldn't have been too > bad. > > However, Ilia didn't like it and suggested an array-based solution. I'm > using here a bitmask and the max amount of components would make this > to not use a lot of memory. > > I think both solutions are fine but, if I have to come up with > something else, I'm running out of ideas ... > > Suggestions are welcome! I believe the comment is that this shouldn't live in "struct gl_transform_feedback_buffer" but rather in tfeedback_decl somewhere. That should be easy to do, no? (I haven't gone back and looked at the code, so perhaps not?) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] Questions on GPU syncpoint handling from inside the GPU
All docs are in the proper method address, i.e. "in bytes" -- in the future, please refer to them that way since all the code and documentation do. There is no reference to method 2c8 in the mesa driver (except the GLOBAL_BASE thing that's only on fermi, I won't get into the details of what that does, but it's completely irrelevant to what you're looking at, and gone on Kepler). There's also no reference to method 2c8 in libdrm_nouveau nor in the nouveau kernel driver (that I can see). Some notes I have do indicate that method 2c8 does in fact exist starting with the KeplerC 3d class (GK208 iirc), and has something to do with "sync points" whatever those are. However we've never used it, and I don't have any details on how it operates. All the waiting is done using the SEMAPHORE_* methods I pointed at in my earlier email. If the CPU has to wait for the GPU to finish something, we can use a kernel-based wait, which basically waits for an interrupt to occur, or we can use a CPU-based wait which spins and waits for some value in memory to get to a particular number. If the CPU does not have to wait, you just want the command stream processing to wait inside the GPU, then you can also use those SEMAPHORE_* methods, e.g. nvc0_hw_query_fifo_wait in nvc0_query_hw.c. Hope this helps, -ilia On Wed, Apr 10, 2019 at 6:59 AM Fernando Sahmkow wrote: > > yeah 0xB2 in words not bytes (*4). Nouveau does write this method in Maxwell > GPUs (we have compiled test apps with nouveau and asserted it was written). > Here's what my colleague fincs REed: > https://github.com/devkitPro/libdrm_nouveau/blob/master/source/pushbuf.c#L399-L407 > methods are word aligned (so multiplied by 4 for bytes). As far as I know > the driver side writes some syncpoints to set fences, this method seems to > tamper with those syncpoints, the thing is that I don't know why or how. > > I think this is related to glFencSync and glWaitClientSync. How are this > methods implemented from both sides (within the gpu and within the > driver/host communication) ? > > El mié., 10 abr. 2019 a las 0:56, Ilia Mirkin () > escribió: >> >> Hi Fernando, >> >> Perhaps you can elaborate? The question doesn't really make sense to me. >> >> What register are you talking about? Do you perhaps mean a method call >> in the b197 class? (And what's 0xB2? Methods are always at multiples >> of 4... do you mean 0x2c8 perhaps? If so, that's not documented post >> Fermi in the 3d class.) And lastly, what do you mean by syncpoints >> exactly? There are various class methods that will allow you to wait >> for a value in memory to be equal (or greater) than a value in the >> command stream, for example (e.g. QUERY_GET -- method 0x1b0c, or the >> fifo-level 0x10..0x1c SEMAPHORE_* methods) -- is that what you're >> talking about? >> >> -ilia >> >> On Tue, Apr 9, 2019 at 9:46 PM Fernando Sahmkow wrote: >> > >> > bump >> > >> > El mar., 2 abr. 2019 a las 11:11, Fernando Sahmkow >> > () escribió: >> >> >> >> Hi guys how are you doing? I have some questions on how the GPU handles >> >> syncpoints from the commandlist. >> >> >> >> I do know the register 0xB2 is the one written in the Maxwell3D Engine. >> >> As far as I know bits 0:15 are the syncpoint id, bit 16 is unknown for >> >> me, bit 20 is increment? What other bits are set and what should be done >> >> on increment? >> >> >> >> Thanks in advance. >> > >> > >> > >> > -- >> > Atentamente, >> > Fernando A. Sahmkow >> > Móvil: +584242280286 >> > Correo: fsahmko...@gmail.com >> > ___ >> > Nouveau mailing list >> > nouv...@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/nouveau > > > > -- > Atentamente, > Fernando A. Sahmkow > Móvil: +584242280286 > Correo: fsahmko...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109764] [radv] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109764 --- Comment #3 from Samuel Pitoiset --- What do you mean by 'cap'? Be able to limit to N FPS? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 6/6] glsl/linker: check for xfb_offset aliasing
On Wed, 2019-04-10 at 10:40 +1000, Timothy Arceri wrote:
> On 13/2/19 8:57 am, Andres Gomez wrote:
> > From page 76 (page 80 of the PDF) of the GLSL 4.60 v.5 spec:
> >
> >" No aliasing in output buffers is allowed: It is a compile-time or
> > link-time error to specify variables with overlapping transform
> > feedback offsets."
> >
> > Currently, this is expected to fail, but it succeeds:
> >
> >"
> >
> > ...
> >
> > layout (xfb_offset = 0) out vec2 a;
> > layout (xfb_offset = 0) out vec4 b;
> >
> > ...
> >
> >"
> >
> > v2: use a data structure to track the used components instead of a
> > nested loop (Ilia).
> >
> > Cc: Timothy Arceri
> > Cc: Ilia Mirkin
> > Signed-off-by: Andres Gomez
> > ---
> > src/compiler/glsl/link_varyings.cpp | 89 ++---
> > src/mesa/main/mtypes.h | 3 +
> > 2 files changed, 70 insertions(+), 22 deletions(-)
> >
> > diff --git a/src/compiler/glsl/link_varyings.cpp
> > b/src/compiler/glsl/link_varyings.cpp
> > index 8c7d6c14c8f..95e9ae895d2 100644
> > --- a/src/compiler/glsl/link_varyings.cpp
> > +++ b/src/compiler/glsl/link_varyings.cpp
> > @@ -1173,6 +1173,73 @@ tfeedback_decl::store(struct gl_context *ctx, struct
> > gl_shader_program *prog,
> > unsigned location = this->location;
> > unsigned location_frac = this->location_frac;
> > unsigned num_components = this->num_components();
> > +
> > + /* From GL_EXT_transform_feedback:
> > + * A program will fail to link if:
> > + *
> > + * * the total number of components to capture is greater than
> > the
> > + * constant MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT
> > and
> > + * the buffer mode is INTERLEAVED_ATTRIBS_EXT.
> > + *
> > + * From GL_ARB_enhanced_layouts:
> > + *
> > + * "The resulting stride (implicit or explicit) must be less than
> > or
> > + *equal to the implementation-dependent constant
> > + *gl_MaxTransformFeedbackInterleavedComponents."
> > + */
> > + if ((prog->TransformFeedback.BufferMode == GL_INTERLEAVED_ATTRIBS ||
> > + has_xfb_qualifiers) &&
> > + xfb_offset + num_components >
> > + ctx->Const.MaxTransformFeedbackInterleavedComponents) {
> > + linker_error(prog,
> > + "The MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS "
> > + "limit has been exceeded.");
> > + return false;
> > + }
> > +
> > + {
>
> We don't need to do this in Mesa anymore. All compilers are now expected
> to support C99 i.e. variable declaration is no longer restricted to the
> start of a compound statement.
I can remove the brackets but I don't need those variables to outlive
beyond this piece of code for the validation either.
>
> > + /* From the OpenGL 4.60.5 spec, section 4.4.2. Output Layout
> > + * Qualifiers, Page 76, (Transform Feedback Layout Qualifiers):
> > + *
> > + * "No aliasing in output buffers is allowed: It is a
> > compile-time or
> > + * link-time error to specify variables with overlapping
> > transform
> > + * feedback offsets."
> > + */
> > + const unsigned max_components =
> > +ctx->Const.MaxTransformFeedbackInterleavedComponents;
> > + const unsigned first_component = xfb_offset;
> > + const unsigned last_component = xfb_offset + num_components - 1;
> > + const unsigned start_word = BITSET_BITWORD(first_component);
> > + const unsigned end_word = BITSET_BITWORD(last_component);
> > + assert(last_component < max_components);
> > +
> > + if (!info->Buffers[buffer].UsedComponents) {
> > +info->Buffers[buffer].UsedComponents =
> > + rzalloc_array(info, BITSET_WORD,
> > BITSET_WORDS(max_components));
> > + }
> > + BITSET_WORD *used = info->Buffers[buffer].UsedComponents;
> > +
> > + for (unsigned word = start_word; word <= end_word; word++) {
> > +unsigned start_range = 0;
> > +unsigned end_range = BITSET_WORDBITS - 1;
> > +
> > +if (word == start_word)
> > + start_range = first_component % BITSET_WORDBITS;
> > +
> > +if (word == end_word)
> > + end_range = last_component % BITSET_WORDBITS;
> > +
> > +if (used[word] & BITSET_RANGE(start_range, end_range)) {
> > + linker_error(prog,
> > +"variable '%s', xfb_offset (%d) "
> > +"is causing aliasing.",
> > +this->orig_name, xfb_offset * 4);
> > + return false;
> > +}
> > +used[word] |= BITSET_RANGE(start_range, end_range);
> > + }
> > + }
> > +
> > while (num_components > 0) {
> >unsigned output_
[Mesa-dev] [Bug 109764] [radv] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109764 --- Comment #2 from Shmerl --- (In reply to Samuel Pitoiset from comment #1) > 'export MESA_VK_WSI_PRESENT_MODE=fifo' is probably what you need. But how exactly do you set the cap using that method? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi Emil, On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote: > > Now that I have been putting together a test case for the the actual use > > I do see some issues with the pbuffer code path. Well - still investigating > > if the test is wrong or the result. > > > Actually I do recall some issues with surfaceless (which is > practically identical to this code) and some (with alpha?) formats. > My memory is pretty flaky - I would suggest trying various configs: > with, w/o alpha, 32/24 etc. Ok, yesterday evening I spent some time to look into that. Finally the egl config mechanism puts double buffer visuals to the pbuffer surface which in turn makes mesa think if should look at the back buffer which is in turn not set in the pbuffer gl_framebuffer. That one makes my drivers just throw away the rendering result so a read back does not show anything usable. With that fixed I get in principle correct results. My gitlab repo contains a branch that sketches my quick fix that I use to make at least the new piglit test case work. No further testing done. But may be that helps in getting something reasonable out. best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 --- Comment #6 from Samuel Pitoiset --- If you can find a good way for reproducing the issue that would be highly appreciated. You can also try different combinations of debug options, like: RADV_DEBUG=nodcc,nohiz,nofastclears,zerovram -- 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 107391] feature request: enforceable vsync and anisotropic filtering via environment variables
https://bugs.freedesktop.org/show_bug.cgi?id=107391 Samuel Pitoiset changed: What|Removed |Added CC||shtetl...@gmail.com --- Comment #7 from Samuel Pitoiset --- *** Bug 109764 has been marked as a duplicate of this bug. *** -- 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 109764] [radv] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109764 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Samuel Pitoiset --- 'export MESA_VK_WSI_PRESENT_MODE=fifo' is probably what you need. This is only available in mesa 19.1-git. *** This bug has been marked as a duplicate of bug 107391 *** -- 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 107391] feature request: enforceable vsync and anisotropic filtering via environment variables
https://bugs.freedesktop.org/show_bug.cgi?id=107391 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Samuel Pitoiset --- I have implemented a way [1] to override the Vulkan presentation mode with MESA_VK_WSI_PRESENT_MODE. Currently, 3 modes are accepted (fifo/mailbox/immediate). X11 supports these 3 modes while Wayland only supports fifo and mailbox. If you want to vsync, you just need to export MESA_VK_WSI_PRESENT_MODE=fifo. [1] https://cgit.freedesktop.org/mesa/mesa/commit/?id=a182adfd83ad00e326153b00a725a014e0359bf0 -- 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
