[Mesa-dev] [Bug 109183] GPU Hangs randomly with GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=109183 --- Comment #2 from Samuel Pitoiset --- Can you explain why it's actually invalid? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On 1/25/19 8:25 AM, Stéphane Marchesin wrote: On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote: Hi; On 1/25/19 4:57 AM, Stéphane Marchesin wrote: Hi, We'd like to expose fp64 functionality on Chrome OS where we only have GLES. It seems like a simple approach is to enable this extension for GLES: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt Anyone knows if what's the right thing to do? It seems to me that the extension might just work on GLES without any changes, but I could be missing something. Sorry for not responding the the actual question but could you share the usecase? Back when this was enabled for HW that supports it we did not find applications (just some fractal shadertoy things), would be interesting to know how it is being used. Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on the guest side, we need fp64 on the host... OK thanks. One thing that comes to mind (specific to GLSL ES) is that should double type have precision qualifier support? Maybe some specific rules what happens when expression has both floats and doubles with some precision qualifiers ... there might be a lot more things to this but this is what comes first to my mind. // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote: > > Hi; > > On 1/25/19 4:57 AM, Stéphane Marchesin wrote: > > Hi, > > > > We'd like to expose fp64 functionality on Chrome OS where we only have > > GLES. It seems like a simple approach is to enable this extension for > > GLES: > > https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt > > > > Anyone knows if what's the right thing to do? It seems to me that the > > extension might just work on GLES without any changes, but I could be > > missing something. > > Sorry for not responding the the actual question but could you share the > usecase? Back when this was enabled for HW that supports it we did not > find applications (just some fractal shadertoy things), would be > interesting to know how it is being used. Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on the guest side, we need fp64 on the host... Stéphane > > Thanks; > > // Tapani > ___ > 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] Thoughts on fp64 for GLES?
Hi; On 1/25/19 4:57 AM, Stéphane Marchesin wrote: Hi, We'd like to expose fp64 functionality on Chrome OS where we only have GLES. It seems like a simple approach is to enable this extension for GLES: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt Anyone knows if what's the right thing to do? It seems to me that the extension might just work on GLES without any changes, but I could be missing something. Sorry for not responding the the actual question but could you share the usecase? Back when this was enabled for HW that supports it we did not find applications (just some fractal shadertoy things), would be interesting to know how it is being used. Thanks; // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] pipe-loader: Fallback to kmsro driver when no matching driver name found
Eric Anholt writes: > [ Unknown signature status ] > Rob Herring writes: > >> If we can't find a driver matching by name, then use the kmsro driver. >> This removes the need for needing a driver descriptor for every possible >> KMS driver. >> >> Signed-off-by: Rob Herring > > Oh, very nice. > > There's some risk here -- for example, vkms (with prime enabled, which > it doesn't currently) will fail badly at prime sharing buffers with > hardware drivers doing WC mappings of buffers. But I guess we should be > preventing that at the kernel level when we enable prime, and having > userspace maybe test creating a shared resource when loading kmsro with > a particular backend. That is to say, Reviewed-by: Eric Anholt If you've got display-only KMS and a render node, we should make sure that Mesa glues those two together. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Thoughts on fp64 for GLES?
Hi, We'd like to expose fp64 functionality on Chrome OS where we only have GLES. It seems like a simple approach is to enable this extension for GLES: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt Anyone knows if what's the right thing to do? It seems to me that the extension might just work on GLES without any changes, but I could be missing something. Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] kmsro: Add etnaviv renderonly support
Rob Herring writes:
> Enable using etnaviv for KMS renderonly. This still needs KMS driver
> name mapping to kmsro to be used automatically.
>
> Signed-off-by: Rob Herring
> diff --git a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> index 4448150cc0c6..e086c0858f05 100644
> --- a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> +++ b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> @@ -27,6 +27,7 @@
>
> #include "kmsro_drm_public.h"
> #include "vc4/drm/vc4_drm_public.h"
> +#include "etnaviv/drm/etnaviv_drm_public.h"
> #include "xf86drm.h"
>
> #include "pipe/p_screen.h"
> @@ -34,22 +35,39 @@
>
> struct pipe_screen *kmsro_drm_screen_create(int fd)
> {
> + struct pipe_screen *screen = NULL;
> struct renderonly ro = {
> + .kms_fd = fd,
> + .gpu_fd = -1,
> + };
> +
> +#if defined(GALLIUM_VC4)
> + ro.gpu_fd = drmOpenWithType("vc4", NULL, DRM_NODE_RENDER);
> + if (ro.gpu_fd >= 0) {
>/* Passes the vc4-allocated BO through to the KMS-only DRM device using
> * PRIME buffer sharing. The VC4 BO must be linear, which the SCANOUT
> * flag on allocation will have ensured.
> */
> - .create_for_resource = renderonly_create_gpu_import_for_resource,
> - .kms_fd = fd,
> - .gpu_fd = drmOpenWithType("vc4", NULL, DRM_NODE_RENDER),
> - };
> + ro.create_for_resource = renderonly_create_gpu_import_for_resource,
> + screen = vc4_drm_screen_create_renderonly();
> + if (!screen)
> + close(ro.gpu_fd);
> +
> + return screen;
> + }
> +#endif
>
> - if (ro.gpu_fd < 0)
> - return NULL;
> +#if defined(GALLIUM_ETNAVIV)
> + ro.gpu_fd = drmOpenWithType("etnaviv", NULL, DRM_NODE_RENDER);
> + if (ro.gpu_fd >= 0) {
> + ro.create_for_resource =
> renderonly_create_kms_dumb_buffer_for_resource,
> + screen = etna_drm_screen_create_renderonly();
> + if (!screen)
> + close(ro.gpu_fd);
>
> - struct pipe_screen *screen = vc4_drm_screen_create_renderonly();
> - if (!screen)
> - close(ro.gpu_fd);
> + return screen;
> + }
> +#endif
Would it make more sense to open the first render node once, then check
if its name matches any of the drivers we support and calling their
setup function?
Either way, this would have my ack.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] pipe-loader: Fallback to kmsro driver when no matching driver name found
Rob Herring writes: > If we can't find a driver matching by name, then use the kmsro driver. > This removes the need for needing a driver descriptor for every possible > KMS driver. > > Signed-off-by: Rob Herring Oh, very nice. There's some risk here -- for example, vkms (with prime enabled, which it doesn't currently) will fail badly at prime sharing buffers with hardware drivers doing WC mappings of buffers. But I guess we should be preventing that at the kernel level when we enable prime, and having userspace maybe test creating a shared resource when loading kmsro with a particular backend. 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 1/4] pl111: Rename the pl111 driver to "kmsro".
Rob Herring writes: > From: Eric Anholt > > The vc4 driver can do prime sharing to many different KMS-only devices, > such as the various tinydrm drivers for SPI-attached displays. Rename the > driver away from "pl111" to represent what it will actually support: > various sorts of KMS displays with the renderonly layer used to attach a > GPU. > > Acked-by: Emil Velikov > Signed-off-by: Rob Herring Looks like you missed the other r-bs? Reviewed-by: Eric Engestrom Reviewed-by: Christian Gmeiner signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] pipe-loader: Fallback to kmsro driver when no matching driver name found
Reviewed-by: Alyssa Rosenzweig ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] pipe-loader: Fallback to kmsro driver when no matching driver name found
If we can't find a driver matching by name, then use the kmsro driver.
This removes the need for needing a driver descriptor for every possible
KMS driver.
Signed-off-by: Rob Herring
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 230bafe5e159..c1323ac65906 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -106,11 +106,6 @@ static const struct drm_driver_descriptor
driver_descriptors[] = {
.create_screen = pipe_freedreno_create_screen,
.configuration = pipe_default_configuration_query,
},
-{
- .driver_name = "pl111",
-.create_screen = pipe_kmsro_create_screen,
-.configuration = pipe_default_configuration_query,
-},
{
.driver_name = "virtio_gpu",
.create_screen = pipe_virgl_create_screen,
@@ -142,6 +137,13 @@ static const struct drm_driver_descriptor
driver_descriptors[] = {
.configuration = pipe_default_configuration_query,
},
};
+
+static const struct drm_driver_descriptor default_driver_descriptor = {
+.driver_name = "kmsro",
+.create_screen = pipe_kmsro_create_screen,
+.configuration = pipe_default_configuration_query,
+};
+
#endif
static const struct drm_driver_descriptor *
@@ -152,6 +154,7 @@ get_driver_descriptor(const char *driver_name, struct
util_dl_library **plib)
if (strcmp(driver_descriptors[i].driver_name, driver_name) == 0)
return _descriptors[i];
}
+ return _driver_descriptor;
#else
*plib = pipe_loader_find_module(driver_name, PIPE_SEARCH_DIR);
if (!*plib)
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] kmsro: Add etnaviv renderonly support
Enable using etnaviv for KMS renderonly. This still needs KMS driver
name mapping to kmsro to be used automatically.
Signed-off-by: Rob Herring
---
meson.build | 4 +--
src/gallium/meson.build | 12 +++
src/gallium/winsys/kmsro/drm/Makefile.am | 8 +
.../winsys/kmsro/drm/kmsro_drm_winsys.c | 36 ++-
src/gallium/winsys/kmsro/drm/meson.build | 11 --
5 files changed, 52 insertions(+), 19 deletions(-)
diff --git a/meson.build b/meson.build
index a7082f1057cf..5d2ae2a446df 100644
--- a/meson.build
+++ b/meson.build
@@ -205,8 +205,8 @@ endif
if with_gallium_imx and not with_gallium_etnaviv
error('IMX driver requires etnaviv driver')
endif
-if with_gallium_kmsro and not with_gallium_vc4
- error('kmsro driver requires vc4 driver')
+if with_gallium_kmsro and not (with_gallium_vc4 or with_gallium_etnaviv)
+ error('kmsro driver requires one or more renderonly drivers (vc4, etnaviv)')
endif
if with_gallium_tegra and not with_gallium_nouveau
error('tegra driver requires nouveau driver')
diff --git a/src/gallium/meson.build b/src/gallium/meson.build
index a3679e5ef629..5b0ce81d1e47 100644
--- a/src/gallium/meson.build
+++ b/src/gallium/meson.build
@@ -89,6 +89,12 @@ if with_gallium_vc4
else
driver_vc4 = declare_dependency()
endif
+if with_gallium_etnaviv
+ subdir('winsys/etnaviv/drm')
+ subdir('drivers/etnaviv')
+else
+ driver_etnaviv = declare_dependency()
+endif
if with_gallium_kmsro
subdir('winsys/kmsro/drm')
else
@@ -100,12 +106,6 @@ if with_gallium_v3d
else
driver_v3d = declare_dependency()
endif
-if with_gallium_etnaviv
- subdir('winsys/etnaviv/drm')
- subdir('drivers/etnaviv')
-else
- driver_etnaviv = declare_dependency()
-endif
if with_gallium_imx
subdir('winsys/imx/drm')
else
diff --git a/src/gallium/winsys/kmsro/drm/Makefile.am
b/src/gallium/winsys/kmsro/drm/Makefile.am
index ad471d31d4fa..0092206539c3 100644
--- a/src/gallium/winsys/kmsro/drm/Makefile.am
+++ b/src/gallium/winsys/kmsro/drm/Makefile.am
@@ -29,6 +29,14 @@ AM_CFLAGS = \
$(GALLIUM_WINSYS_CFLAGS) \
$(LIBDRM_CFLAGS)
+if HAVE_GALLIUM_ETNAVIV
+AM_CFLAGS += -DGALLIUM_ETNAVIV
+endif
+
+if HAVE_GALLIUM_VC4
+AM_CFLAGS += -DGALLIUM_VC4
+endif
+
noinst_LTLIBRARIES = libkmsrodrm.la
libkmsrodrm_la_SOURCES = $(C_SOURCES)
diff --git a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
index 4448150cc0c6..e086c0858f05 100644
--- a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
+++ b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
@@ -27,6 +27,7 @@
#include "kmsro_drm_public.h"
#include "vc4/drm/vc4_drm_public.h"
+#include "etnaviv/drm/etnaviv_drm_public.h"
#include "xf86drm.h"
#include "pipe/p_screen.h"
@@ -34,22 +35,39 @@
struct pipe_screen *kmsro_drm_screen_create(int fd)
{
+ struct pipe_screen *screen = NULL;
struct renderonly ro = {
+ .kms_fd = fd,
+ .gpu_fd = -1,
+ };
+
+#if defined(GALLIUM_VC4)
+ ro.gpu_fd = drmOpenWithType("vc4", NULL, DRM_NODE_RENDER);
+ if (ro.gpu_fd >= 0) {
/* Passes the vc4-allocated BO through to the KMS-only DRM device using
* PRIME buffer sharing. The VC4 BO must be linear, which the SCANOUT
* flag on allocation will have ensured.
*/
- .create_for_resource = renderonly_create_gpu_import_for_resource,
- .kms_fd = fd,
- .gpu_fd = drmOpenWithType("vc4", NULL, DRM_NODE_RENDER),
- };
+ ro.create_for_resource = renderonly_create_gpu_import_for_resource,
+ screen = vc4_drm_screen_create_renderonly();
+ if (!screen)
+ close(ro.gpu_fd);
+
+ return screen;
+ }
+#endif
- if (ro.gpu_fd < 0)
- return NULL;
+#if defined(GALLIUM_ETNAVIV)
+ ro.gpu_fd = drmOpenWithType("etnaviv", NULL, DRM_NODE_RENDER);
+ if (ro.gpu_fd >= 0) {
+ ro.create_for_resource = renderonly_create_kms_dumb_buffer_for_resource,
+ screen = etna_drm_screen_create_renderonly();
+ if (!screen)
+ close(ro.gpu_fd);
- struct pipe_screen *screen = vc4_drm_screen_create_renderonly();
- if (!screen)
- close(ro.gpu_fd);
+ return screen;
+ }
+#endif
return screen;
}
diff --git a/src/gallium/winsys/kmsro/drm/meson.build
b/src/gallium/winsys/kmsro/drm/meson.build
index f157982d7288..e8c350e081bc 100644
--- a/src/gallium/winsys/kmsro/drm/meson.build
+++ b/src/gallium/winsys/kmsro/drm/meson.build
@@ -18,6 +18,14 @@
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
+kmsro_c_args = []
+if with_gallium_etnaviv
+ kmsro_c_args += '-DGALLIUM_ETNAVIV'
+endif
+if with_gallium_vc4
+ kmsro_c_args += '-DGALLIUM_VC4'
+endif
+
libkmsrowinsys = static_library(
'kmsrowinsys',
files('kmsro_drm_winsys.c'),
@@ -25,9 +33,8 @@ libkmsrowinsys = static_library(
inc_src, inc_include,
inc_gallium, inc_gallium_aux, inc_gallium_winsys,
],
- c_args : [c_vis_args],
[Mesa-dev] [PATCH 0/4] Common KMS renderonly support
This series aims to make supporting new platforms containing
renderonly GPUs easier with less copy-n-paste. This hasn't been a big
issue so far as the current renderonly drivers (vc4 and etnaviv) only
exists on a few platforms. This is changing with i.MX+freedreno,
armada+etnaviv and a slew of platforms using Mali lima and panfrost
drivers.
I've taken the kmsro winsys from Eric, extended the pipe-loader to
fall back to kmsro, added etnaviv support, and switched imx to use
kmsro.
I've tested this with the panfrost tree. Help testing on i.MX would be
nice. A git branch is here[1].
Rob
[1] https://github.com/robherring/mesa winsys-renderonly
Eric Anholt (1):
pl111: Rename the pl111 driver to "kmsro".
Rob Herring (3):
pipe-loader: Fallback to kmsro driver when no matching driver name
found
kmsro: Add etnaviv renderonly support
Switch imx to kmsro and remove the imx winsys
.travis.yml | 2 +-
Android.mk| 7 ++-
Makefile.am | 2 +-
configure.ac | 28 ---
meson.build | 12 ++---
meson_options.txt | 4 +-
src/gallium/Android.mk| 3 +-
src/gallium/Makefile.am | 8 +--
.../auxiliary/pipe-loader/pipe_loader_drm.c | 18 +++
.../auxiliary/target-helpers/drm_helper.h | 35 +++--
.../target-helpers/drm_helper_public.h| 2 +-
src/gallium/drivers/imx/Automake.inc | 9
.../drivers/{pl111 => kmsro}/Android.mk | 6 +--
src/gallium/drivers/kmsro/Automake.inc| 9
.../drivers/{imx => kmsro}/Makefile.am| 4 +-
.../drivers/{pl111 => kmsro}/Makefile.sources | 0
src/gallium/drivers/pl111/Automake.inc| 9
src/gallium/drivers/pl111/Makefile.am | 8 ---
src/gallium/meson.build | 23 -
src/gallium/targets/dri/Makefile.am | 3 +-
src/gallium/targets/dri/meson.build | 8 +--
src/gallium/targets/dri/target.c | 2 +-
src/gallium/winsys/imx/drm/Android.mk | 40 ---
src/gallium/winsys/imx/drm/Makefile.am| 35 -
src/gallium/winsys/imx/drm/Makefile.sources | 3 --
src/gallium/winsys/imx/drm/imx_drm_public.h | 34 -
src/gallium/winsys/imx/drm/imx_drm_winsys.c | 50 ---
src/gallium/winsys/imx/drm/meson.build| 33
.../winsys/{pl111 => kmsro}/drm/Android.mk| 2 +-
.../winsys/{pl111 => kmsro}/drm/Makefile.am | 12 -
src/gallium/winsys/kmsro/drm/Makefile.sources | 3 ++
.../drm/kmsro_drm_public.h} | 8 +--
.../drm/kmsro_drm_winsys.c} | 42 +++-
.../winsys/{pl111 => kmsro}/drm/meson.build | 23 ++---
src/gallium/winsys/pl111/drm/Makefile.sources | 3 --
35 files changed, 130 insertions(+), 360 deletions(-)
delete mode 100644 src/gallium/drivers/imx/Automake.inc
rename src/gallium/drivers/{pl111 => kmsro}/Android.mk (91%)
create mode 100644 src/gallium/drivers/kmsro/Automake.inc
rename src/gallium/drivers/{imx => kmsro}/Makefile.am (55%)
rename src/gallium/drivers/{pl111 => kmsro}/Makefile.sources (100%)
delete mode 100644 src/gallium/drivers/pl111/Automake.inc
delete mode 100644 src/gallium/drivers/pl111/Makefile.am
delete mode 100644 src/gallium/winsys/imx/drm/Android.mk
delete mode 100644 src/gallium/winsys/imx/drm/Makefile.am
delete mode 100644 src/gallium/winsys/imx/drm/Makefile.sources
delete mode 100644 src/gallium/winsys/imx/drm/imx_drm_public.h
delete mode 100644 src/gallium/winsys/imx/drm/imx_drm_winsys.c
delete mode 100644 src/gallium/winsys/imx/drm/meson.build
rename src/gallium/winsys/{pl111 => kmsro}/drm/Android.mk (97%)
rename src/gallium/winsys/{pl111 => kmsro}/drm/Makefile.am (87%)
create mode 100644 src/gallium/winsys/kmsro/drm/Makefile.sources
rename src/gallium/winsys/{pl111/drm/pl111_drm_public.h =>
kmsro/drm/kmsro_drm_public.h} (89%)
rename src/gallium/winsys/{pl111/drm/pl111_drm_winsys.c =>
kmsro/drm/kmsro_drm_winsys.c} (63%)
rename src/gallium/winsys/{pl111 => kmsro}/drm/meson.build (76%)
delete mode 100644 src/gallium/winsys/pl111/drm/Makefile.sources
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] Switch imx to kmsro and remove the imx winsys
The kmsro winsys is equivalent to the imx winsys, so we can switch to it and remove the imx one. Signed-off-by: Rob Herring --- Android.mk| 5 +- Makefile.am | 2 +- configure.ac | 14 +- meson.build | 6 +-- meson_options.txt | 2 +- src/gallium/Android.mk| 1 - src/gallium/Makefile.am | 4 -- .../auxiliary/pipe-loader/pipe_loader_drm.c | 5 -- .../auxiliary/target-helpers/drm_helper.h | 23 - src/gallium/drivers/imx/Automake.inc | 9 src/gallium/drivers/imx/Makefile.am | 8 --- src/gallium/meson.build | 5 -- src/gallium/targets/dri/Makefile.am | 1 - src/gallium/targets/dri/meson.build | 4 +- src/gallium/winsys/imx/drm/Android.mk | 40 --- src/gallium/winsys/imx/drm/Makefile.am| 35 - src/gallium/winsys/imx/drm/Makefile.sources | 3 -- src/gallium/winsys/imx/drm/imx_drm_public.h | 34 - src/gallium/winsys/imx/drm/imx_drm_winsys.c | 50 --- src/gallium/winsys/imx/drm/meson.build| 33 20 files changed, 9 insertions(+), 275 deletions(-) delete mode 100644 src/gallium/drivers/imx/Automake.inc delete mode 100644 src/gallium/drivers/imx/Makefile.am delete mode 100644 src/gallium/winsys/imx/drm/Android.mk delete mode 100644 src/gallium/winsys/imx/drm/Makefile.am delete mode 100644 src/gallium/winsys/imx/drm/Makefile.sources delete mode 100644 src/gallium/winsys/imx/drm/imx_drm_public.h delete mode 100644 src/gallium/winsys/imx/drm/imx_drm_winsys.c delete mode 100644 src/gallium/winsys/imx/drm/meson.build diff --git a/Android.mk b/Android.mk index 1a0bdd1736cf..9d999835ebb4 100644 --- a/Android.mk +++ b/Android.mk @@ -24,7 +24,7 @@ # BOARD_GPU_DRIVERS should be defined. The valid values are # # classic drivers: i915 i965 -# gallium drivers: swrast freedreno i915g nouveau kmsro r300g r600g radeonsi vc4 virgl vmwgfx etnaviv imx +# gallium drivers: swrast freedreno i915g nouveau kmsro r300g r600g radeonsi vc4 virgl vmwgfx etnaviv # # The main target is libGLES_mesa. For each classic driver enabled, a DRI # module will also be built. DRI modules will be loaded by libGLES_mesa. @@ -59,8 +59,7 @@ gallium_drivers := \ vmwgfx.HAVE_GALLIUM_VMWGFX \ vc4.HAVE_GALLIUM_VC4 \ virgl.HAVE_GALLIUM_VIRGL \ - etnaviv.HAVE_GALLIUM_ETNAVIV \ - imx.HAVE_GALLIUM_IMX + etnaviv.HAVE_GALLIUM_ETNAVIV ifeq ($(BOARD_GPU_DRIVERS),all) MESA_BUILD_CLASSIC := $(filter HAVE_%, $(subst ., , $(classic_drivers))) diff --git a/Makefile.am b/Makefile.am index 62c755aeca7f..e7e14f5b3cdd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -45,7 +45,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \ --enable-libunwind \ --with-platforms=x11,wayland,drm,surfaceless \ --with-dri-drivers=i915,i965,nouveau,radeon,r200,swrast \ - --with-gallium-drivers=i915,nouveau,r300,kmsro,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv,imx \ + --with-gallium-drivers=i915,nouveau,r300,kmsro,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv \ --with-vulkan-drivers=intel,radeon ACLOCAL_AMFLAGS = -I m4 diff --git a/configure.ac b/configure.ac index 8f668fb10ad1..858da79f4d0a 100644 --- a/configure.ac +++ b/configure.ac @@ -1408,7 +1408,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast" AC_ARG_WITH([gallium-drivers], [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@], [comma delimited Gallium drivers list, e.g. - "i915,nouveau,r300,r600,radeonsi,freedreno,kmsro,svga,swrast,swr,tegra,v3d,vc4,virgl,etnaviv,imx" + "i915,nouveau,r300,r600,radeonsi,freedreno,kmsro,svga,swrast,swr,tegra,v3d,vc4,virgl,etnaviv" @<:@default=r300,r600,svga,swrast@:>@])], [with_gallium_drivers="$withval"], [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"]) @@ -2741,9 +2741,6 @@ if test -n "$with_gallium_drivers"; then PKG_CHECK_MODULES([ETNAVIV], [libdrm >= $LIBDRM_ETNAVIV_REQUIRED libdrm_etnaviv >= $LIBDRM_ETNAVIV_REQUIRED]) require_libdrm "etnaviv" ;; - ximx) -HAVE_GALLIUM_IMX=yes -;; xtegra) HAVE_GALLIUM_TEGRA=yes require_libdrm "tegra" @@ -2864,10 +2861,6 @@ AM_CONDITIONAL(HAVE_SWR_BUILTIN, test "x$HAVE_SWR_BUILTIN" = xyes) dnl We need to validate some needed dependencies for renderonly drivers. -if test "x$HAVE_GALLIUM_ETNAVIV" != xyes -a "x$HAVE_GALLIUM_IMX" = xyes ; then -AC_MSG_ERROR([Building with imx requires etnaviv]) -fi - if test "x$HAVE_GALLIUM_VC4" != xyes -a "x$HAVE_GALLIUM_KMSRO" = xyes ; then AC_MSG_ERROR([Building with kmsro requires vc4]) fi @@ -2952,7 +2945,7 @@ if test
[Mesa-dev] [PATCH 1/4] pl111: Rename the pl111 driver to "kmsro".
From: Eric Anholt
The vc4 driver can do prime sharing to many different KMS-only devices,
such as the various tinydrm drivers for SPI-attached displays. Rename the
driver away from "pl111" to represent what it will actually support:
various sorts of KMS displays with the renderonly layer used to attach a
GPU.
Acked-by: Emil Velikov
Signed-off-by: Rob Herring
---
.travis.yml | 2 +-
Android.mk | 4 ++--
Makefile.am | 2 +-
configure.ac | 16
meson.build | 8
meson_options.txt| 2 +-
src/gallium/Android.mk | 2 +-
src/gallium/Makefile.am | 4 ++--
.../auxiliary/pipe-loader/pipe_loader_drm.c | 2 +-
.../auxiliary/target-helpers/drm_helper.h| 12 ++--
.../auxiliary/target-helpers/drm_helper_public.h | 2 +-
src/gallium/drivers/{pl111 => kmsro}/Android.mk | 6 +++---
src/gallium/drivers/kmsro/Automake.inc | 9 +
src/gallium/drivers/{pl111 => kmsro}/Makefile.am | 4 ++--
.../drivers/{pl111 => kmsro}/Makefile.sources| 0
src/gallium/drivers/pl111/Automake.inc | 9 -
src/gallium/meson.build | 6 +++---
src/gallium/targets/dri/Makefile.am | 2 +-
src/gallium/targets/dri/meson.build | 4 ++--
src/gallium/targets/dri/target.c | 2 +-
.../winsys/{pl111 => kmsro}/drm/Android.mk | 2 +-
.../winsys/{pl111 => kmsro}/drm/Makefile.am | 4 ++--
src/gallium/winsys/kmsro/drm/Makefile.sources| 3 +++
.../drm/kmsro_drm_public.h} | 8
.../drm/kmsro_drm_winsys.c} | 6 +++---
.../winsys/{pl111 => kmsro}/drm/meson.build | 12 ++--
src/gallium/winsys/pl111/drm/Makefile.sources| 3 ---
27 files changed, 68 insertions(+), 68 deletions(-)
rename src/gallium/drivers/{pl111 => kmsro}/Android.mk (91%)
create mode 100644 src/gallium/drivers/kmsro/Automake.inc
rename src/gallium/drivers/{pl111 => kmsro}/Makefile.am (55%)
rename src/gallium/drivers/{pl111 => kmsro}/Makefile.sources (100%)
delete mode 100644 src/gallium/drivers/pl111/Automake.inc
rename src/gallium/winsys/{pl111 => kmsro}/drm/Android.mk (97%)
rename src/gallium/winsys/{pl111 => kmsro}/drm/Makefile.am (94%)
create mode 100644 src/gallium/winsys/kmsro/drm/Makefile.sources
rename src/gallium/winsys/{pl111/drm/pl111_drm_public.h =>
kmsro/drm/kmsro_drm_public.h} (89%)
rename src/gallium/winsys/{pl111/drm/pl111_drm_winsys.c =>
kmsro/drm/kmsro_drm_winsys.c} (92%)
rename src/gallium/winsys/{pl111 => kmsro}/drm/meson.build (87%)
delete mode 100644 src/gallium/winsys/pl111/drm/Makefile.sources
diff --git a/.travis.yml b/.travis.yml
index 67bbf592a901..6936699cfac3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -352,7 +352,7 @@ matrix:
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
- DRI_DRIVERS=""
- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa
--disable-nine --disable-xvmc --disable-vdpau --disable-va
--disable-omx-bellagio --disable-gallium-osmesa"
--
GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,freedreno,svga,swrast,v3d,vc4,virgl,etnaviv,imx"
+-
GALLIUM_DRIVERS="i915,nouveau,kmsro,r300,r600,freedreno,svga,swrast,v3d,vc4,virgl,etnaviv,imx"
- VULKAN_DRIVERS=""
- LIBUNWIND_FLAGS="--enable-libunwind"
addons:
diff --git a/Android.mk b/Android.mk
index 914854c27d63..1a0bdd1736cf 100644
--- a/Android.mk
+++ b/Android.mk
@@ -24,7 +24,7 @@
# BOARD_GPU_DRIVERS should be defined. The valid values are
#
# classic drivers: i915 i965
-# gallium drivers: swrast freedreno i915g nouveau pl111 r300g r600g radeonsi
vc4 virgl vmwgfx etnaviv imx
+# gallium drivers: swrast freedreno i915g nouveau kmsro r300g r600g radeonsi
vc4 virgl vmwgfx etnaviv imx
#
# The main target is libGLES_mesa. For each classic driver enabled, a DRI
# module will also be built. DRI modules will be loaded by libGLES_mesa.
@@ -52,7 +52,7 @@ gallium_drivers := \
freedreno.HAVE_GALLIUM_FREEDRENO \
i915g.HAVE_GALLIUM_I915 \
nouveau.HAVE_GALLIUM_NOUVEAU \
- pl111.HAVE_GALLIUM_PL111 \
+ kmsro.HAVE_GALLIUM_KMSRO \
r300g.HAVE_GALLIUM_R300 \
r600g.HAVE_GALLIUM_R600 \
radeonsi.HAVE_GALLIUM_RADEONSI \
diff --git a/Makefile.am b/Makefile.am
index 9e27db046e52..62c755aeca7f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-libunwind \
--with-platforms=x11,wayland,drm,surfaceless \
--with-dri-drivers=i915,i965,nouveau,radeon,r200,swrast \
-
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv,imx
Re: [Mesa-dev] [PATCH] intel/compiler: Add a file-level description of brw_eu_validate.c
On Thu, Jan 24, 2019 at 12:16 PM Francisco Jerez wrote: > > Matt Turner writes: > > > --- > > src/intel/compiler/brw_eu_validate.c | 14 +- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/src/intel/compiler/brw_eu_validate.c > > b/src/intel/compiler/brw_eu_validate.c > > index a25010b225c..7f1580a5bb3 100644 > > --- a/src/intel/compiler/brw_eu_validate.c > > +++ b/src/intel/compiler/brw_eu_validate.c > > @@ -1,5 +1,5 @@ > > /* > > - * Copyright © 2015 Intel Corporation > > + * Copyright © 2015-2019 Intel Corporation > > * > > * Permission is hereby granted, free of charge, to any person obtaining a > > * copy of this software and associated documentation files (the > > "Software"), > > @@ -24,6 +24,18 @@ > > /** @file brw_eu_validate.c > > * > > * This file implements a pass that validates shader assembly. > > + * > > + * The restrictions implemented herein are intended to verify that > > instructions > > + * in shader assembly do not violate restrictions documented in the > > graphics > > + * programming reference manuals. > > + * > > + * The restrictions are difficult for humans to quickly verify due to their > > + * complexity and abundance. > > + * > > + * It is critical that this code is thoroughly unit tested because false > > + * results it will lead developers astray, which is worse than having no > > Redundant "it". > > > + * validator at all. Patches to this file without corresponding unit tests > > (in > > + * test_eu_validate.cpp) will be rejected. > > Strictly by that rule this patch should be rejected ;). Maybe say > "functional changes" instead of "patches"? Other than that: > > Reviewed-by: Francisco Jerez Fair point :) Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)
https://bugs.freedesktop.org/show_bug.cgi?id=109201 --- Comment #12 from Alexander --- Created attachment 143229 --> https://bugs.freedesktop.org/attachment.cgi?id=143229=edit Fireball works in Dense Biozone (Video) I noticed that the gpu hang doesn't happen in the location "Dense Biozone". -- 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 109183] GPU Hangs randomly with GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=109183 Alexander changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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] intel/compiler: Add a file-level description of brw_eu_validate.c
Matt Turner writes: > --- > src/intel/compiler/brw_eu_validate.c | 14 +- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/src/intel/compiler/brw_eu_validate.c > b/src/intel/compiler/brw_eu_validate.c > index a25010b225c..7f1580a5bb3 100644 > --- a/src/intel/compiler/brw_eu_validate.c > +++ b/src/intel/compiler/brw_eu_validate.c > @@ -1,5 +1,5 @@ > /* > - * Copyright © 2015 Intel Corporation > + * Copyright © 2015-2019 Intel Corporation > * > * Permission is hereby granted, free of charge, to any person obtaining a > * copy of this software and associated documentation files (the "Software"), > @@ -24,6 +24,18 @@ > /** @file brw_eu_validate.c > * > * This file implements a pass that validates shader assembly. > + * > + * The restrictions implemented herein are intended to verify that > instructions > + * in shader assembly do not violate restrictions documented in the graphics > + * programming reference manuals. > + * > + * The restrictions are difficult for humans to quickly verify due to their > + * complexity and abundance. > + * > + * It is critical that this code is thoroughly unit tested because false > + * results it will lead developers astray, which is worse than having no Redundant "it". > + * validator at all. Patches to this file without corresponding unit tests > (in > + * test_eu_validate.cpp) will be rejected. Strictly by that rule this patch should be rejected ;). Maybe say "functional changes" instead of "patches"? Other than that: Reviewed-by: Francisco Jerez > */ > > #include "brw_eu.h" > -- > 2.19.2 signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/compiler: Add a file-level description of brw_eu_validate.c
--- src/intel/compiler/brw_eu_validate.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_eu_validate.c b/src/intel/compiler/brw_eu_validate.c index a25010b225c..7f1580a5bb3 100644 --- a/src/intel/compiler/brw_eu_validate.c +++ b/src/intel/compiler/brw_eu_validate.c @@ -1,5 +1,5 @@ /* - * Copyright © 2015 Intel Corporation + * Copyright © 2015-2019 Intel Corporation * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the "Software"), @@ -24,6 +24,18 @@ /** @file brw_eu_validate.c * * This file implements a pass that validates shader assembly. + * + * The restrictions implemented herein are intended to verify that instructions + * in shader assembly do not violate restrictions documented in the graphics + * programming reference manuals. + * + * The restrictions are difficult for humans to quickly verify due to their + * complexity and abundance. + * + * It is critical that this code is thoroughly unit tested because false + * results it will lead developers astray, which is worse than having no + * validator at all. Patches to this file without corresponding unit tests (in + * test_eu_validate.cpp) will be rejected. */ #include "brw_eu.h" -- 2.19.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion
Iago Toral writes:
> On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
>> Iago Toral Quiroga writes:
>>
>> > Commit c84ec70b3a72 implemented execution type promotion to 32-bit
>> > for
>> > conversions involving half-float registers, which empirical testing
>> > suggested
>> > was required, but it did not incorporate this change into the
>> > assembly validator
>> > logic. This commits adds that, preventing validation errors like
>> > this:
>> >
>>
>> I don't think we should be validating empirical assumptions in the EU
>> validator.
>
> I am not sure I get your point, isn't c84ec70b3a72 also based on
> empirical testing after all?
>
To some extent, but it doesn't attempt to enforce ISA restrictions based
on information obtained empirically.
>
>> > mov(16) g9<4>B g3<16,8,2>HF { align1 1H };
>> > ERROR: Destination stride must be equal to the ratio of the sizes
>> > of the
>> >execution data type to the destination type
>> >
>> > Fixes: c84ec70b3a72 "intel/fs: Promote execution type to 32-bit
>> > when any half-float conversion is needed."
>>
>> I don't think this "fixes" anything that ever worked.
>
> It is true that the code in that trace above is not something we can
> produce right now, because it is a conversion from HF to B and that
> should only happen within the context of VK_KHR_shader_float16_int8,
> however, this is a consequence of the fact that since c84ec70b3a72
> there is an inconsistency between what we do at the IR level regarding
> execution size of HF conversions and what the EU validator is doing,
> and from that perspective this is really fixing an inconsistency that
> didn't exist before, and I thought we would want to address that sooner
> rather than later and track it down to the original change that
> introduced that inconsistency so we know where this is coming from.
>
The "inconsistency" between the IR's get_exec_type() and the EU
validator's execution_type() has existed ever since a05b6f25bf4bfad7
removed the HF assert from get_exec_type() without actually implementing
the code required to handle HF operands (which is what my commit
c84ec70b3a72 did).
> Anyway, that was my rationale for the Fixes tag, but if you think this
> is not useful I am happy to drop this patch and just include it as part
> of my series without the tag.
>
I'd like to see the actual regioning restrictions for HF types
implemented in the EU validator as part of your series. I don't see the
need to introduce any empirical assumptions into the EU validator's
execution_type() in order to achieve that, even if that means that
get_exec_type() and execution_type() don't do the exact same calculation
-- What you call an inconsistency is the consequence of execution_type()
being the hardware spec's opinion on what the execution type is, which
we assume is what we need to use while enforcing a regioning restriction
that refers to the execution type of the instruction.
>> The validator is
>> still missing an implementation of the quirky HF restrictions, and it
>> wasn't the purpose of c84ec70b3a72 to do such a thing.
>
> While this is true in general, the EU validator does consider the
> execution type of the instruction to validate general rules such as the
> one I mentioned in the commit message in this patch. And that part of
> the validator is inconsistent with c84ec70b3a72.
That part of the validator was also inconsistent with the code generated
by your original VK_KHR_shader_float16_int8 series even before I
committed c84ec70b3a72. The reason is that it is trying to validate a
restriction that rejects working code, because the "general" rule it's
trying to enforce isn't supposed to apply to instructions with HF
operands, which is the real bug.
> In fact, the EU validator is accounting for execution size promotion
> of HF instructions to 32-bit in SKL+ and CHV only, for conversions
> from HF->F and mixed float mode instructions... which is part of what
> c84ec70b3a72 addresses at the IR level, which it actually does for all
> hardware platforms and in more cases.
>
I'm fine with fixing execution_type() to do the right thing in more
cases and platforms, but I don't think that should involve making
empirical assumptions in the validator.
>> You *should*
>> definitely implement those restrictions (as they're stated in the
>> hardware spec, without empirical assumptions) in the validator as
>> part
>> of your VK_KHR_shader_float16_int8 series,
>
> Again, I am not sure what you mean by "without empirical assumptions".
I was just paraphrasing your comment. If you feel the need to write a
comment justifying the existence of some code in the validator based on
empirical testing, it probably doesn't belong in the validator.
> According to the commit message in c84ec70b3a72 "the docs are fairly
> imcomplete and inconsistent" and you explained here that you had to do
> some experimentation of your own using the simulator (where you found
> its results to also be
[Mesa-dev] [AppVeyor] mesa master #9842 failed
Build mesa 9842 failed Commit c1efa240c9 by Dylan Baker on 1/14/2019 11:23 PM: meson: Add warnings and errors when using ICC\n\nICC tries to be helpful by not erroring when it sees something that it\ndoesn't understand, which is completely the opposite of helpful. Meson\n0.49.0 does much better at handling this by really trying to make ICC\nerror, but there are some things in mesa that still get ignored until\n0.49.1\n\nv2: - Fix id check, which is 'intel' not 'icc'\n\nCc: 18.3 \nReviewed-by: Eric Engestrom (v1) Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion
On Wed, Jan 23, 2019 at 6:03 AM Francisco Jerez wrote: > > Iago Toral Quiroga writes: > > > Commit c84ec70b3a72 implemented execution type promotion to 32-bit for > > conversions involving half-float registers, which empirical testing > > suggested > > was required, but it did not incorporate this change into the assembly > > validator > > logic. This commits adds that, preventing validation errors like this: > > > > I don't think we should be validating empirical assumptions in the EU > validator. I kind of agree. I don't really know what we should do though. I guess it's better to err on the side of caution in the EU validator and only check restrictions that have documentation. Is that your thinking? Many instructions can only take certain conditional modifiers. XOR is documented to only take .z/.nz. However we emit XOR with a .l conditional mod for nir_op_imod. It works, and we think the documentation is incomplete. Separately it describes how the conditional modifiers operate, and .l only reads the high bit of the result so it makes sense that XOR with .l should work like we see that it does. So, (1) empirically it works, (2) the documentation says it's not allowed, but (3) there's a plausible explanation that the documentation is wrong. What should we do if we implement the conditional modifier checks in the validator? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #9839 failed
Build mesa 9839 failed Commit 281421e1bc by Emil Velikov on 11/14/2018 2:18 PM: mapi: remove machinery handling CSV files\n\nWe haven't have one in years, so just drop the code.\n\nSigned-off-by: Emil Velikov \nReviewed-by: Erik Faye-Lund Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion
On Wed, Jan 23, 2019 at 4:18 AM Iago Toral Quiroga wrote:
>
> Commit c84ec70b3a72 implemented execution type promotion to 32-bit for
> conversions involving half-float registers, which empirical testing suggested
> was required, but it did not incorporate this change into the assembly
> validator
> logic. This commits adds that, preventing validation errors like this:
>
> mov(16) g9<4>B g3<16,8,2>HF { align1 1H };
> ERROR: Destination stride must be equal to the ratio of the sizes of the
>execution data type to the destination type
>
> Fixes: c84ec70b3a72 "intel/fs: Promote execution type to 32-bit when any
> half-float conversion is needed."
> ---
> src/intel/compiler/brw_eu_validate.c | 27 ++-
New rule: New restrictions (or relaxations) may not be added to
brw_eu_validate.c without accompanying unit tests. I'll send a patch
to add a comment to brw_eu_validate.c saying as much.
Rationale: the reason I wrote brw_eu_validate.c was because I wasted a
week debugging an issue where fulsim not only failed to inform me that
one instruction was invalid but also incorrectly told me that one
correct instruction *was* invalid. I would have been better off
without such a tool.
If the EU validator loses people's trust, then it's useless, but if it
is incorrect it's worse than useless.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] gallium: Enable ASIMD/NEON on aarch64.
Matt Turner writes: > NEON (now called ASIMD) is available on all aarch64 CPUs. Our code was > missing an aarch64 path, leading to util_cpu_caps.has_neon always being > false on aarch64. > --- > Here's the simpler patch to just always enable NEON on aarch64. It suits > my purposes, but I can imagine that you may prefer the original patch if > you ever want to do runtime detection of other features on aarch64. Reviewed-by: Eric Anholt 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 1/2] pl111: Rename the pl111 driver to "kmsro".
On Thu, 24 Jan 2019 at 16:22, Rob Herring wrote: > > On Thu, Jan 24, 2019 at 9:14 AM Emil Velikov wrote: > > > > Hi all, > > > > Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a > > partial solution. > > Never the less is some solution for the problem we have. > > > > With that said the series is: > > Acked-by: Emil Velikov > > > > On Wed, 23 Jan 2019 at 23:42, Alyssa Rosenzweig > > wrote: > > > > > > > I've started looking at the lima and panfrost drivers. The many > > > > combinations of Mali GPUs and DC isn't going to scale. The lima and > > > > panfrost trees can't even co-exist as both define a rockchip winsys > > > > which load different GPU drivers. The same will be true for meson, > > > > hisilicon, allwinner, etc. i.MX is about to be in the same boat > > > > needing to support both etnaviv and freedreno. > > > > > > As Rob stated, Mali being used by basically everyone at one point or > > > another has led to a nightmare in the winsys. I agree that dealing with > > > the loader can happen later, but honestly, just having the centralised > > > kmsro winsys (that all of pl111/rockchip/meson/sunxi/etc point to) that > > > tries all of vc4/v3d/panfrost/lima/etc would be a marked improvement on > > > the present situation. > > > > > > There are a lot of DRM drivers out there, sure, and it _is_ better to > > > handle something generically in the loader. But for the much more > > > immediate goal of letting both Lima and Panfrost coexist on > > > Rockchip/Meson, this is a good start. > > > > AFAICT for a comprehensive solution, that handles the above usescases, > > we would need: > > > > - a form or drm driver name to kms_ro mapping > > Personally I'm leaning towards a drirc style file. Thus no patching or > > rebuilding of mesa is needed and no more symlinks. > > That would be nice. Based on the discussion on patch 2, I'm not really > clear on where all the support for this needs to go. That's just my > lack of X11 details. > > > - a form of KMSRO to GPU device mapping > > Thus we can use that instead of the hardcoded vc4 in the proposed KMSRO. > > Ideally they would live alongside the previous mappings, to avoid > > patching/rebuilding. > > I don't think we have any cases of 2 different embedded GPUs in one > system (but SoC vendors have done crazier things) and the number of > GPUs is not a huge set. > Multiple devices is another concern and as you pointed out not that pressing. > Also, if we require some config file to tell us what GPU, then we > still have to update that config file for each and every new system. > I'd rather see things work by default and we only need a config file > for the special cases. > Something that picks a driver from a known list sounds like a good enough default. Aka your drmOpenWithType() patch, if I understood you correctly. Obviously we can polish that when needed. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 2019 X.Org Foundation Membership deadline for voting in the election
There have been a bunch of sign-ups without names which makes for a confusing list on https://members.x.org/members If you get chance please update your name and affiliation in your profile (username > Your Profile). Harry On 2019-01-24 9:42 a.m., Wentland, Harry wrote: > Note that you will have to re-register in the new system. Your previous > credentials won't work. > > Harry > > On 2019-01-24 8:42 a.m., Wentland, Harry wrote: >> The 2019 X.Org Foundation elections are rapidly approaching. We will be >> forwarding the nominating process to the membership shortly. Please find the >> election schedule below. >> >> Please note that only current members can vote in the upcoming election, and >> that the deadline for new memberships or renewals to vote in the upcoming >> election is 21 February 2019 at 23:59 UTC. >> >> If you are interested in joining the X.Org Foundation or in renewing your >> membership, please visit the membership system site at: >> https://members.x.org/ >> >> Note that this year the membership site got a complete overhaul. If you >> experience any problems please open a ticket here: >> https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/issues/new?issue%5Bassignee_id%5D=%5Bmilestone_id%5D= >> >> Election Schedule: >> Jan 31 - nomination period begins >> Feb 14 - nomination period ends >> Feb 21 - publish candidates, membership deadline >> Feb 28 - election period begins >> Mar 14 - election period ends >> >> >> Harry Wentland, on behalf of the X.Org elections committee >> >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] pl111: Rename the pl111 driver to "kmsro".
> I don't think we have any cases of 2 different embedded GPUs in one > system (but SoC vendors have done crazier things) and the number of > GPUs is not a huge set. > > Also, if we require some config file to tell us what GPU, then we > still have to update that config file for each and every new system. > I'd rather see things work by default and we only need a config file > for the special cases. I agree with this -- Panfrost/Rockchip and Panfrost/Meson are identical, just as Lima/Rockchip and Panfrost/Sunxi are identical, etc. If hypothetically we had an i.MX Mali SoC, well, great, that's still identical to Panfrost/imx! No need for further special cases on our end. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] pl111: Rename the pl111 driver to "kmsro".
On Thu, Jan 24, 2019 at 9:14 AM Emil Velikov wrote:
>
> Hi all,
>
> Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a
> partial solution.
> Never the less is some solution for the problem we have.
>
> With that said the series is:
> Acked-by: Emil Velikov
>
> On Wed, 23 Jan 2019 at 23:42, Alyssa Rosenzweig wrote:
> >
> > > I've started looking at the lima and panfrost drivers. The many
> > > combinations of Mali GPUs and DC isn't going to scale. The lima and
> > > panfrost trees can't even co-exist as both define a rockchip winsys
> > > which load different GPU drivers. The same will be true for meson,
> > > hisilicon, allwinner, etc. i.MX is about to be in the same boat
> > > needing to support both etnaviv and freedreno.
> >
> > As Rob stated, Mali being used by basically everyone at one point or
> > another has led to a nightmare in the winsys. I agree that dealing with
> > the loader can happen later, but honestly, just having the centralised
> > kmsro winsys (that all of pl111/rockchip/meson/sunxi/etc point to) that
> > tries all of vc4/v3d/panfrost/lima/etc would be a marked improvement on
> > the present situation.
> >
> > There are a lot of DRM drivers out there, sure, and it _is_ better to
> > handle something generically in the loader. But for the much more
> > immediate goal of letting both Lima and Panfrost coexist on
> > Rockchip/Meson, this is a good start.
>
> AFAICT for a comprehensive solution, that handles the above usescases,
> we would need:
>
> - a form or drm driver name to kms_ro mapping
> Personally I'm leaning towards a drirc style file. Thus no patching or
> rebuilding of mesa is needed and no more symlinks.
That would be nice. Based on the discussion on patch 2, I'm not really
clear on where all the support for this needs to go. That's just my
lack of X11 details.
> - a form of KMSRO to GPU device mapping
> Thus we can use that instead of the hardcoded vc4 in the proposed KMSRO.
> Ideally they would live alongside the previous mappings, to avoid
> patching/rebuilding.
The one other thing besides which gpu we have is whether we alloc
scanout buffers in the gpu or dc, but that could be a flag.
For now, I was working on a patch to just try each gpu with a series
of drmOpenwithType calls like this:
#if defined(GALLIUM_ETNAVIV)
ro.gpu_fd = drmOpenWithType("etnaviv", NULL, DRM_NODE_RENDER);
if (ro.gpu_fd >= 0) {
ro.create_for_resource = renderonly_create_kms_dumb_buffer_for_resource,
screen = etna_drm_screen_create_renderonly();
if (!screen)
close(ro.gpu_fd);
return screen;
}
#endif
I don't think we have any cases of 2 different embedded GPUs in one
system (but SoC vendors have done crazier things) and the number of
GPUs is not a huge set.
Also, if we require some config file to tell us what GPU, then we
still have to update that config file for each and every new system.
I'd rather see things work by default and we only need a config file
for the special cases.
Rob
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] pl111: Rename the pl111 driver to "kmsro".
Hi all, Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a partial solution. Never the less is some solution for the problem we have. With that said the series is: Acked-by: Emil Velikov On Wed, 23 Jan 2019 at 23:42, Alyssa Rosenzweig wrote: > > > I've started looking at the lima and panfrost drivers. The many > > combinations of Mali GPUs and DC isn't going to scale. The lima and > > panfrost trees can't even co-exist as both define a rockchip winsys > > which load different GPU drivers. The same will be true for meson, > > hisilicon, allwinner, etc. i.MX is about to be in the same boat > > needing to support both etnaviv and freedreno. > > As Rob stated, Mali being used by basically everyone at one point or > another has led to a nightmare in the winsys. I agree that dealing with > the loader can happen later, but honestly, just having the centralised > kmsro winsys (that all of pl111/rockchip/meson/sunxi/etc point to) that > tries all of vc4/v3d/panfrost/lima/etc would be a marked improvement on > the present situation. > > There are a lot of DRM drivers out there, sure, and it _is_ better to > handle something generically in the loader. But for the much more > immediate goal of letting both Lima and Panfrost coexist on > Rockchip/Meson, this is a good start. AFAICT for a comprehensive solution, that handles the above usescases, we would need: - a form or drm driver name to kms_ro mapping Personally I'm leaning towards a drirc style file. Thus no patching or rebuilding of mesa is needed and no more symlinks. - a form of KMSRO to GPU device mapping Thus we can use that instead of the hardcoded vc4 in the proposed KMSRO. Ideally they would live alongside the previous mappings, to avoid patching/rebuilding. An extra bonus here is that the integrator can toggle a simple file if their hx8357d is connected to a vc4 or another device. Or an IMX DC with freedreno/etnaviv/other GPU. HTH -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 2019 X.Org Foundation Membership deadline for voting in the election
Note that you will have to re-register in the new system. Your previous credentials won't work. Harry On 2019-01-24 8:42 a.m., Wentland, Harry wrote: > The 2019 X.Org Foundation elections are rapidly approaching. We will be > forwarding the nominating process to the membership shortly. Please find the > election schedule below. > > Please note that only current members can vote in the upcoming election, and > that the deadline for new memberships or renewals to vote in the upcoming > election is 21 February 2019 at 23:59 UTC. > > If you are interested in joining the X.Org Foundation or in renewing your > membership, please visit the membership system site at: https://members.x.org/ > > Note that this year the membership site got a complete overhaul. If you > experience any problems please open a ticket here: > https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/issues/new?issue%5Bassignee_id%5D=%5Bmilestone_id%5D= > > Election Schedule: > Jan 31 - nomination period begins > Feb 14 - nomination period ends > Feb 21 - publish candidates, membership deadline > Feb 28 - election period begins > Mar 14 - election period ends > > > Harry Wentland, on behalf of the X.Org elections committee > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 2019 X.Org Foundation Membership deadline for voting in the election
The 2019 X.Org Foundation elections are rapidly approaching. We will be forwarding the nominating process to the membership shortly. Please find the election schedule below. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 21 February 2019 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Note that this year the membership site got a complete overhaul. If you experience any problems please open a ticket here: https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/issues/new?issue%5Bassignee_id%5D=%5Bmilestone_id%5D= Election Schedule: Jan 31 - nomination period begins Feb 14 - nomination period ends Feb 21 - publish candidates, membership deadline Feb 28 - election period begins Mar 14 - election period ends Harry Wentland, on behalf of the X.Org elections committee ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
On Wed, 2019-01-23 at 14:47 +, Eric Engestrom wrote: > On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote: > > It could have been made obvious for instance by showing the commit- > > graph next to the commit-list, decorating it with the branch head > > in > > one end and clear continuation in the other. > > I'd love that, it would really help a lot! > > Care to raise an issue at gitlab asking for this? :) > https://gitlab.com/gitlab-org/gitlab-ce/issues/new > Done: https://gitlab.com/gitlab-org/gitlab-ce/issues/56799 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)
https://bugs.freedesktop.org/show_bug.cgi?id=109201 Evan Goers changed: What|Removed |Added CC||megatog...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support
Am Donnerstag, den 24.01.2019, 07:46 +0100 schrieb Christian Gmeiner:
> Am Mo., 21. Jan. 2019 um 10:10 Uhr schrieb Lucas Stach
> :
> >
> > Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> > > If the GPU supports linear sampling, linear addressing mode
> > > will be used as default.
> > >
> > > > Signed-off-by: Christian Gmeiner
> > >
> > > ---
> > > src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
> > > src/gallium/drivers/etnaviv/etnaviv_texture.c | 4 +++-
> > > 2 files changed, 10 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > index 9a7ebf3064e..7d24b1f03bd 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
> > > {
> > > struct etna_screen *screen = etna_screen(pscreen);
> > >
> > > - /* Figure out what tiling and address mode to use -- for now, assume
> > > that
> > > -* texture cannot be linear. there is a capability
> > > LINEAR_TEXTURE_SUPPORT
> > > -* (supported on gc880 and gc2000 at least), but not sure how it
> > > works.
> > > + /* Figure out what tiling and address mode to use.
> > > +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability
> > > is
> > > +* available LINEAR gets prefered.
> > > * Buffers always have LINEAR layout.
> > > */
> > > unsigned layout = ETNA_LAYOUT_LINEAR;
> > > @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
> > >
> > > if (util_format_is_compressed(templat->format))
> > > layout = ETNA_LAYOUT_LINEAR;
> > > + else if (VIV_FEATURE(screen, chipMinorFeatures1,
> > > LINEAR_TEXTURE_SUPPORT)) {
> > > + layout = ETNA_LAYOUT_LINEAR;
> > > + mode = ETNA_ADDRESSING_MODE_LINEAR;
> > > + }
> >
> > Did you do any performance measurements with this change? I don't think
> > we generally want to prefer linear textures, as in theory they have
> > much worse texture cache hit rates. Also a lot of the async transfer
> > stuff currently depends on hitting the RS linear->tiled blit path for
> > optimal performance on uploads.
> >
>
> I have not done any performance measurements yet - I only tried to get it
> render correctly (piglit and amoeba) and get some feedback asap.
> But I will keep an eye on perf for v2.
FWIW, I did some preliminary testing and couldn't find a big perf
difference. Even after a hack to use linear textures more often (in
most cases we end up with textures being allocated with both SAMPLER
and RENDER binding, where we still end up with tiled resources.
But my tests didn't pound very hard on sampler performance.
> Regarding the async transfer staff I have the feeling that we lose the shadow
> resource (etna_transfer->rsc) handling if we are using linear, which saves us
> from some RS blits. Or?
That's right, but at the price that the CPU side of the transfer needs
to synchronize with the GPU job. Getting rid of those synchronization
points was one of the key performance optimizations up until now.
Basically we are trading the overhead of a temporary buffer allocation
and a RS blit (which is only done to the part of the buffer that is
actually updated) against a full GPU stall in most cases. I'm not
saying that getting rid of the RS blit for some of the transfers won't
be beneficial, but we need to carefully weight the performance
implications here. Being able to directly map the texture resource and
blindly doing this when possible (what our current transfer code does)
will not be a net win in performance in most cases.
> > There are 2 cases where I think linear textures are useful:
> >
> > 1. Imported external buffers, where we might need to update the
> > internal tiled copy on each resource update. Getting rid of this blit
> > should help performance a good bit.
> >
>
> You are taking about etna_resource_from_handle(..). I *think* for this we
> need support for linear in the pixel engine too - based on the binding flag
> combinations I have seen.
That would be ideal, but for a start we can just keep the external
imported resource as linear and keep a tiled base resource, just as we
do now. Linear texture sampling support would already allow us to
sample the external import directly, without the need to do a copy into
a tiled texture resource.
> > 2. 8bpp formats that can't be tiled with the RS and would hit the
> > software fallback path. The tradeoff software tiling path vs. reduced
> > texture cache hit rates might still prefer linear textures.
> >
>
> Yes that I something to look into.
>
Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] etnaviv: extend etna_resource with an addressing mode
Am Donnerstag, den 24.01.2019, 07:31 +0100 schrieb Christian Gmeiner: > Hi Lucas > > Am Mo., 21. Jan. 2019 um 10:03 Uhr schrieb Lucas Stach > : > > > > Hi Christian, > > > > first of all, thanks for figuring this out. This is really nice > > to finally know how it works. > > > > Am Montag, den 21.01.2019, 07:49 +0100 schrieb Christian Gmeiner: > > > Defines how sampler (and pixel pipes) needs to access the data > > > represented with a resource. The used default is mode is > > > ETNA_ADDRESSING_MODE_TILED. > > > > Do you see any reason why we need a separate property for this? IMHO > > etna_resource is already a bit too fat and from this set of patches I > > can't see why we can't infer the addressing mode from the layout. Do > > you have something specific in mind, that I don't see right now? > > > > We are using ETNA_LAYOUT_LINEAR for compressed textures with an > addressing mode of TILED (register value of 0). That is the root cause why > was forced to add something new to etna_resource as I can not trust that > ETNA_LAYOUT_LINEAR for sampler resources implies an linear addressing > mode. Ah, right. This had escaped my mind. With this out of the way, patch looks good. Regards, Lucas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion
On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > Commit c84ec70b3a72 implemented execution type promotion to 32-bit
> > for
> > conversions involving half-float registers, which empirical testing
> > suggested
> > was required, but it did not incorporate this change into the
> > assembly validator
> > logic. This commits adds that, preventing validation errors like
> > this:
> >
>
> I don't think we should be validating empirical assumptions in the EU
> validator.
I am not sure I get your point, isn't c84ec70b3a72 also based on
empirical testing after all?
> > mov(16) g9<4>B g3<16,8,2>HF { align1 1H };
> > ERROR: Destination stride must be equal to the ratio of the sizes
> > of the
> >execution data type to the destination type
> >
> > Fixes: c84ec70b3a72 "intel/fs: Promote execution type to 32-bit
> > when any half-float conversion is needed."
>
> I don't think this "fixes" anything that ever worked.
It is true that the code in that trace above is not something we can
produce right now, because it is a conversion from HF to B and that
should only happen within the context of VK_KHR_shader_float16_int8,
however, this is a consequence of the fact that since c84ec70b3a72
there is an inconsistency between what we do at the IR level regarding
execution size of HF conversions and what the EU validator is doing,
and from that perspective this is really fixing an inconsistency that
didn't exist before, and I thought we would want to address that sooner
rather than later and track it down to the original change that
introduced that inconsistency so we know where this is coming from.
Anyway, that was my rationale for the Fixes tag, but if you think this
is not useful I am happy to drop this patch and just include it as part
of my series without the tag.
> The validator is
> still missing an implementation of the quirky HF restrictions, and it
> wasn't the purpose of c84ec70b3a72 to do such a thing.
While this is true in general, the EU validator does consider the
execution type of the instruction to validate general rules such as the
one I mentioned in the commit message in this patch. And that part of
the validator is inconsistent with c84ec70b3a72. In fact, the EU
validator is accounting for execution size promotion of HF instructions
to 32-bit in SKL+ and CHV only, for conversions from HF->F and mixed
float mode instructions... which is part of what c84ec70b3a72 addresses
at the IR level, which it actually does for all hardware platforms and
in more cases.
> You *should*
> definitely implement those restrictions (as they're stated in the
> hardware spec, without empirical assumptions) in the validator as
> part
> of your VK_KHR_shader_float16_int8 series,
Again, I am not sure what you mean by "without empirical assumptions".
According to the commit message in c84ec70b3a72 "the docs are fairly
imcomplete and inconsistent" and you explained here that you had to do
some experimentation of your own using the simulator (where you found
its results to also be inconsistent with the hardware docs) to try and
guess what is happening. That's why I was using the term "empirical"
here, since the hardware docs alone aren't clear or correct enough to
understand what is really happening, when and in what platforms.
Anyway, if you don't like the term "empirical" to refer to all this,
that's fine by me, but what I need to know is if we agree that we need
to implement the same type promotion rules in the validator that we are
implementing in the IR, indepedently of whether refer to them as "based
on empirical testing" or not.
> if anything because currently
> it will reject working code that uses HF types.
Just for the sake of clarity, since that sentence above could be
interpreted as if all HF code would be rejected: we have been using HF
types since we landed VK_KHR_16bit_storage, which includes conversions
between HF and F and the EU validator is not complaining about any of
that. It is currently a problem only with conversions to smaller types
(so only conversions to Byte) because that's where we check for that
restriction on the stride, which is based on the execution type of the
instruction.
>
> > ---
> > src/intel/compiler/brw_eu_validate.c | 27 ++
> > -
> > 1 file changed, 14 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/intel/compiler/brw_eu_validate.c
> > b/src/intel/compiler/brw_eu_validate.c
> > index a25010b225c..3bb37677672 100644
> > --- a/src/intel/compiler/brw_eu_validate.c
> > +++ b/src/intel/compiler/brw_eu_validate.c
> > @@ -325,17 +325,20 @@ execution_type(const struct gen_device_info
> > *devinfo, const brw_inst *inst)
> > unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > enum brw_reg_type src0_exec_type, src1_exec_type;
> >
> > - /* Execution data type is independent of destination data type,
> > except in
> > -* mixed F/HF instructions on CHV and SKL+.
> >
