Re: [Mesa-dev] [PATCH] r600g: fix and optimize tgsi_cmp when using ABS and NEG modifier
On 2016-04-07 08:10 AM, Dave Airlie wrote: > On 7 April 2016 at 15:43, Ian Romanick wrote: >> On 04/02/2016 02:45 AM, Patrick Rudolph wrote: >>> Are there optimizations done on TGSI ? >>> I can't find any file in src/gallium/auxiliary/tgsi that does so. >> >> What I meant was, at some point the driver translates TGSI into its own >> representation. When that translation occurs, generate the smarter code. > > Good one :-P > > We do tgsi->r600 asm->sb. > > So this is pretty much the place we do translations to the r600 > assembly, so it's probably > the best place for now. > > Dave. Are you going to push this fix ? Regards, Patrick. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95071] [bisected] Wrong colors in KDE/Qt applications
https://bugs.freedesktop.org/show_bug.cgi?id=95071 --- Comment #3 from Marek Olšák --- Created attachment 123198 --> https://bugs.freedesktop.org/attachment.cgi?id=123198&action=edit possible fix Could you please try this patch? -- 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 0/3] Support for Android RGBX/RGBA formats
On Sat, Apr 23, 2016 at 6:43 PM, Rob Herring wrote: > On Thu, Apr 21, 2016 at 8:42 AM, Emil Velikov > wrote: >> Hi Rob, >> >> On 19 April 2016 at 20:38, Rob Herring wrote: >>> The RGBX/RGBA pixel formats used in the Android EGL don't get configs >>> created due to the missing formats in the DRI state tracker. This series >>> adds the necessary formats for configs and DRI images. Support in GBM is >>> also added as it will be needed soon for Android. >>> >>> AFAICT, this has been a long standing bug in Android-x86 which was >>> worked around with the patch "GLSurfaceView: Be less picky about >>> EGLConfig alpha sizes". With this series, this patch is no longer needed >>> and several other bugs like wallpaper not getting displayed are fixed. >>> >> In the past similar changes has caused unexpected bugs and/or pert >> regressions. >> >> Although I doubt we'll notice them with the patches on the ML, thus >> I've pushed the lot to get some wider testing. >> Please keep an eye for fires ;-) > > Looks like you were right: > > https://bugs.freedesktop.org/show_bug.cgi?id=95071 > > Revert that one patch (ccdcf91104a5f07127) and I'll look into. If you > have any suggestions on how to fix it, that would be helpful. I've attached a possible fix in the bug report. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] winsys/radeon: remove use_reusable_pool parameter from buffer_create
For the series:
Reviewed-by: Marek Olšák
Marek
On Sat, Apr 23, 2016 at 6:01 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> All callers set this parameter to true.
> ---
> src/gallium/drivers/r300/r300_query.c | 2 +-
> src/gallium/drivers/r300/r300_render.c | 2 +-
> src/gallium/drivers/r300/r300_screen_buffer.c | 4 ++--
> src/gallium/drivers/r300/r300_texture.c | 2 +-
> src/gallium/drivers/radeon/r600_buffer_common.c | 1 -
> src/gallium/drivers/radeon/radeon_video.c | 2 +-
> src/gallium/drivers/radeon/radeon_winsys.h | 1 -
> src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 14 +-
> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 2 +-
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 11 ---
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
> 11 files changed, 17 insertions(+), 26 deletions(-)
>
> diff --git a/src/gallium/drivers/r300/r300_query.c
> b/src/gallium/drivers/r300/r300_query.c
> index 8557eb7..f788f58 100644
> --- a/src/gallium/drivers/r300/r300_query.c
> +++ b/src/gallium/drivers/r300/r300_query.c
> @@ -58,7 +58,7 @@ static struct pipe_query *r300_create_query(struct
> pipe_context *pipe,
> else
> q->num_pipes = r300screen->info.r300_num_gb_pipes;
>
> -q->buf = r300->rws->buffer_create(r300->rws, 4096, 4096, TRUE,
> +q->buf = r300->rws->buffer_create(r300->rws, 4096, 4096,
>RADEON_DOMAIN_GTT, 0);
> if (!q->buf) {
> FREE(q);
> diff --git a/src/gallium/drivers/r300/r300_render.c
> b/src/gallium/drivers/r300/r300_render.c
> index 7eda675..43860f3 100644
> --- a/src/gallium/drivers/r300/r300_render.c
> +++ b/src/gallium/drivers/r300/r300_render.c
> @@ -904,7 +904,7 @@ static boolean r300_render_allocate_vertices(struct
> vbuf_render* render,
>
> r300->vbo = rws->buffer_create(rws,
> MAX2(R300_MAX_DRAW_VBO_SIZE, size),
> - R300_BUFFER_ALIGNMENT, TRUE,
> + R300_BUFFER_ALIGNMENT,
> RADEON_DOMAIN_GTT, 0);
> if (!r300->vbo) {
> return FALSE;
> diff --git a/src/gallium/drivers/r300/r300_screen_buffer.c
> b/src/gallium/drivers/r300/r300_screen_buffer.c
> index 42c8e3a..5b69b24 100644
> --- a/src/gallium/drivers/r300/r300_screen_buffer.c
> +++ b/src/gallium/drivers/r300/r300_screen_buffer.c
> @@ -102,7 +102,7 @@ r300_buffer_transfer_map( struct pipe_context *context,
>
> /* Create a new one in the same pipe_resource. */
> new_buf = r300->rws->buffer_create(r300->rws, rbuf->b.b.width0,
> - R300_BUFFER_ALIGNMENT, TRUE,
> + R300_BUFFER_ALIGNMENT,
> rbuf->domain, 0);
> if (new_buf) {
> /* Discard the old buffer. */
> @@ -183,7 +183,7 @@ struct pipe_resource *r300_buffer_create(struct
> pipe_screen *screen,
>
> rbuf->buf =
> r300screen->rws->buffer_create(r300screen->rws, rbuf->b.b.width0,
> - R300_BUFFER_ALIGNMENT, TRUE,
> + R300_BUFFER_ALIGNMENT,
> rbuf->domain, 0);
> if (!rbuf->buf) {
> FREE(rbuf);
> diff --git a/src/gallium/drivers/r300/r300_texture.c
> b/src/gallium/drivers/r300/r300_texture.c
> index da51661..df01673 100644
> --- a/src/gallium/drivers/r300/r300_texture.c
> +++ b/src/gallium/drivers/r300/r300_texture.c
> @@ -1047,7 +1047,7 @@ r300_texture_create_object(struct r300_screen *rscreen,
>
> /* Create the backing buffer if needed. */
> if (!tex->buf) {
> -tex->buf = rws->buffer_create(rws, tex->tex.size_in_bytes, 2048,
> TRUE,
> +tex->buf = rws->buffer_create(rws, tex->tex.size_in_bytes, 2048,
>tex->domain, 0);
>
> if (!tex->buf) {
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index 1955dab..6b46dfa 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -176,7 +176,6 @@ bool r600_init_resource(struct r600_common_screen
> *rscreen,
>
> /* Allocate a new resource. */
> new_buf = rscreen->ws->buffer_create(rscreen->ws, size, alignment,
> -true,
> res->domains, flags);
> if (!new_buf) {
> return false;
> diff --git a/src/gallium/drivers/radeon/radeon_video.c
> b/src/gallium/drivers/radeon/radeon_video.c
> index 8dd32ea..e2ff037 100644
> --- a/src/gallium/drivers/radeon/radeon_video.c
> +++ b/src/gallium/drivers/radeon/radeon_video.c
> @@ -185,7 +185,7 @@ void r
[Mesa-dev] [PATCH] r300g: set endian controls on big endian
From: Marek Olšák
---
src/gallium/drivers/r300/r300_reg.h | 20 +++--
src/gallium/drivers/r300/r300_texture.c | 38 ++---
2 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_reg.h
b/src/gallium/drivers/r300/r300_reg.h
index 9c373c5..9c93b84 100644
--- a/src/gallium/drivers/r300/r300_reg.h
+++ b/src/gallium/drivers/r300/r300_reg.h
@@ -1700,10 +1700,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#define R300_TX_OFFSET_60x4558
#define R300_TX_OFFSET_70x455C
-# define R300_TXO_ENDIAN_NO_SWAP (0 << 0)
-# define R300_TXO_ENDIAN_BYTE_SWAP (1 << 0)
-# define R300_TXO_ENDIAN_WORD_SWAP (2 << 0)
-# define R300_TXO_ENDIAN_HALFDW_SWAP (3 << 0)
+# define R300_TXO_ENDIAN(x)((x) << 0)
# define R300_TXO_MACRO_TILE_LINEAR(0 << 2)
# define R300_TXO_MACRO_TILE_TILED (1 << 2)
# define R300_TXO_MACRO_TILE(x)((x) << 2)
@@ -2418,10 +2415,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
# define R300_COLOR_MICROTILE_ENABLE(1 << 17)
# define R300_COLOR_MICROTILE_ENABLE_SQUARE (2 << 17) /* Only available
in 16-bit */
# define R300_COLOR_MICROTILE(x)((x) << 17)
-# define R300_COLOR_ENDIAN_NO_SWAP (0 << 19)
-# define R300_COLOR_ENDIAN_WORD_SWAP(1 << 19)
-# define R300_COLOR_ENDIAN_DWORD_SWAP (2 << 19)
-# define R300_COLOR_ENDIAN_HALF_DWORD_SWAP (3 << 19)
+# define R300_COLOR_ENDIAN(x) ((x) << 19)
# define R500_COLOR_FORMAT_ARGB10101010 (0 << 21)
# define R500_COLOR_FORMAT_UV1010 (1 << 21)
# define R500_COLOR_FORMAT_CI8 (2 << 21) /* 2D only */
@@ -2693,10 +2687,12 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
# define R300_DEPTHMICROTILE_TILED(1 << 17)
# define R300_DEPTHMICROTILE_TILED_SQUARE (2 << 17)
# define R300_DEPTHMICROTILE(x) ((x) << 17)
-# define R300_DEPTHENDIAN_NO_SWAP (0 << 18)
-# define R300_DEPTHENDIAN_WORD_SWAP (1 << 18)
-# define R300_DEPTHENDIAN_DWORD_SWAP (2 << 18)
-# define R300_DEPTHENDIAN_HALF_DWORD_SWAP (3 << 18)
+# define R300_DEPTHENDIAN(x) ((x) << 19)
+
+#define R300_SURF_NO_SWAP 0
+#define R300_SURF_WORD_SWAP 1
+#define R300_SURF_DWORD_SWAP 2
+#define R300_SURF_HALF_DWORD_SWAP 3
/* Z Buffer Clear Value */
#define R300_ZB_DEPTHCLEARVALUE 0x4f28
diff --git a/src/gallium/drivers/r300/r300_texture.c
b/src/gallium/drivers/r300/r300_texture.c
index da51661..825d811 100644
--- a/src/gallium/drivers/r300/r300_texture.c
+++ b/src/gallium/drivers/r300/r300_texture.c
@@ -837,6 +837,35 @@ boolean r300_is_sampler_format_supported(enum pipe_format
format)
return r300_translate_texformat(format, 0, TRUE, FALSE) != ~0;
}
+static unsigned r300_get_endian_swap(enum pipe_format format)
+{
+const struct util_format_description *desc;
+unsigned swap_size;
+
+if (PIPE_ENDIAN_NATIVE != PIPE_ENDIAN_BIG)
+return R300_SURF_NO_SWAP;
+
+desc = util_format_description(format);
+if (!desc)
+return R300_SURF_NO_SWAP;
+
+/* Compressed formats should be in the little endian format. */
+if (desc->block.width != 1 || desc->block.height != 1)
+return R300_SURF_NO_SWAP;
+
+swap_size = desc->is_array ? desc->channel[0].size : desc->block.bits;
+
+switch (swap_size) {
+default: /* shouldn't happen? */
+case 8:
+return R300_SURF_NO_SWAP;
+case 16:
+return R300_SURF_WORD_SWAP;
+case 32:
+return R300_SURF_DWORD_SWAP;
+}
+}
+
void r300_texture_setup_format_state(struct r300_screen *screen,
struct r300_resource *tex,
enum pipe_format format,
@@ -918,7 +947,8 @@ void r300_texture_setup_format_state(struct r300_screen
*screen,
}
out->tile_config = R300_TXO_MACRO_TILE(desc->macrotile[level]) |
- R300_TXO_MICRO_TILE(desc->microtile);
+ R300_TXO_MICRO_TILE(desc->microtile) |
+ R300_TXO_ENDIAN(r300_get_endian_swap(tex->b.b.format));
}
static void r300_texture_setup_fb_state(struct r300_surface *surf)
@@ -933,7 +963,8 @@ static void r300_texture_setup_fb_state(struct r300_surface
*surf)
surf->pitch =
stride |
R300_DEPTHMACROTILE(tex->tex.macrotile[level]) |
-R300_DEPTHMICROTILE(tex->tex.microtile);
+R300_DEPTHMICROTILE(tex->tex.microtile) |
+R300_DEPTHENDIAN(r300_get_endian_swap(tex->b.b.format));
surf->format = r300_translate_zsformat(surf->base.format);
surf->pitch_zmask = tex->tex.zmask_stride_in_pixels[level];
surf->pitch_hiz = tex->t
[Mesa-dev] [Bug 95071] [bisected] Wrong colors in KDE/Qt applications
https://bugs.freedesktop.org/show_bug.cgi?id=95071 --- Comment #4 from Kai --- Created attachment 123200 --> https://bugs.freedesktop.org/attachment.cgi?id=123200&action=edit More wrong colours in more places (In reply to Marek Olšák from comment #3) > Created attachment 123198 [details] [review] > possible fix > > Could you please try this patch? I've tested it with the stack detailed below and this is worse than without the patch (see attached screenshot, I'll attach one without your patch as well), now the taskbar shows the switched colours as well. I restarted X/SDDM to make sure everything was using the new library versions. The following stack (Debian testing as a base) was used: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/147a2d25ad libdrm: 2.4.67-1 LLVM: SVN:trunk/r267209 (3.9 devel) X.Org: 2:1.18.3-1 Linux: 4.5.1 Firmware: firmware-amd-graphics/20160110-1 libclc: Git:master/20d977a3e6 DDX: 1:7.7.0-1 Let me know, if you need something else. -- 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 95071] [bisected] Wrong colors in KDE/Qt applications
https://bugs.freedesktop.org/show_bug.cgi?id=95071 --- Comment #5 from Kai --- Created attachment 123201 --> https://bugs.freedesktop.org/attachment.cgi?id=123201&action=edit Taskbar with correct colours The attached image shows the taskbar without the patch (again, after a restart of X/SDDM). -- 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] [r300g] Visuals not found in (default) depth = 24
On Fri, Apr 22, 2016 at 9:02 AM, Mathieu Malaterre wrote: > Dear all, > > I am trying to resurrect an old effort: > > https://lists.freedesktop.org/archives/mesa-dev/2013-December/050218.html > > After some exchanges with Oded Gabbay and Michel Dänzer, it appears > that I should be able to import some of the changes made lately on > r600 onto r300. "Import" is not the right word. Big endian support needs to be reimplemented based on the same "ideas". Would you please test this: https://lists.freedesktop.org/archives/mesa-dev/2016-April/114409.html Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95071] [bisected] Wrong colors in KDE/Qt applications
https://bugs.freedesktop.org/show_bug.cgi?id=95071 Marek Olšák changed: What|Removed |Added CC|mar...@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 0/3] Support for Android RGBX/RGBA formats
On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang wrote: > 2016-04-21 21:42 GMT+08:00 Emil Velikov : >> >> On 19 April 2016 at 20:38, Rob Herring wrote: >>> The RGBX/RGBA pixel formats used in the Android EGL don't get configs >>> created due to the missing formats in the DRI state tracker. This series >>> adds the necessary formats for configs and DRI images. Support in GBM is >>> also added as it will be needed soon for Android. >>> >>> AFAICT, this has been a long standing bug in Android-x86 which was >>> worked around with the patch "GLSurfaceView: Be less picky about >>> EGLConfig alpha sizes". With this series, this patch is no longer needed >>> and several other bugs like wallpaper not getting displayed are fixed. >>> >> In the past similar changes has caused unexpected bugs and/or pert >> regressions. >> >> Although I doubt we'll notice them with the patches on the ML, thus >> I've pushed the lot to get some wider testing. >> Please keep an eye for fires ;-) > > Could these be back-ported to 11.2? DEFINITELY NOT. It's too risky and it has already broken GLX. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/25] Vulkan (build et al.) fixes
On Thu, Apr 21, 2016 at 02:16:00PM +0100, Emil Velikov wrote: > Hi all, > > While tryting to get a tarball and things went a bit strange, thus I've > 'tweaked' the vulkan makefile and simplified things a fair bit. > > The series can be found in branch for-upstream/vulkan-makefile-cleanups > in my github repo. > > Comments and review are greatly appreciated. > Emil Speaking of build fixes, shouldn't configure be changed to check for memfd and futexes? The intel vulkan code in anv_allocator.c/anv_gem_stubs.c directly does linux specific syscalls for these (and strangely includes values.h instead of limits.h). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94168] Incorrect rendering when running Populous 3 on wine using DDraw->WineD3D->OpenGL wrapper [apitrace]
https://bugs.freedesktop.org/show_bug.cgi?id=94168 Sven Arvidsson changed: What|Removed |Added CC||s...@whiz.se -- 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 0/3] Support for Android RGBX/RGBA formats
On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák wrote: > On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang > wrote: >> 2016-04-21 21:42 GMT+08:00 Emil Velikov : >>> >>> On 19 April 2016 at 20:38, Rob Herring wrote: The RGBX/RGBA pixel formats used in the Android EGL don't get configs created due to the missing formats in the DRI state tracker. This series adds the necessary formats for configs and DRI images. Support in GBM is also added as it will be needed soon for Android. AFAICT, this has been a long standing bug in Android-x86 which was worked around with the patch "GLSurfaceView: Be less picky about EGLConfig alpha sizes". With this series, this patch is no longer needed and several other bugs like wallpaper not getting displayed are fixed. >>> In the past similar changes has caused unexpected bugs and/or pert >>> regressions. >>> >>> Although I doubt we'll notice them with the patches on the ML, thus >>> I've pushed the lot to get some wider testing. >>> Please keep an eye for fires ;-) >> >> Could these be back-ported to 11.2? > > DEFINITELY NOT. > > It's too risky and it has already broken GLX. OK so the problem is libGL ignores the red/green/blue mask, therefore it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes it's BGRA on the X server side. This patch series also ignores the red/green/blue mask for imported buffers. That's why DRI2 mostly works. I haven't tested DRI3. libGL could be fixed not to expose RGBA visuals, but that's insufficient, because Mesa drivers must be loadable by older libGL too. The bottom line is st/dri can't expose RGBA, because it would break Mesa with old libGL. Unless you guys come up with a solution, I'll have to revert the st/dri change. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95071] [bisected] Wrong colors in KDE/Qt applications
https://bugs.freedesktop.org/show_bug.cgi?id=95071 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Olšák --- Closing. I've revert the problematic commit. -- 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 0/3] Support for Android RGBX/RGBA formats
On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák wrote: > On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák wrote: >> On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang >> wrote: >>> 2016-04-21 21:42 GMT+08:00 Emil Velikov : On 19 April 2016 at 20:38, Rob Herring wrote: > The RGBX/RGBA pixel formats used in the Android EGL don't get configs > created due to the missing formats in the DRI state tracker. This series > adds the necessary formats for configs and DRI images. Support in GBM is > also added as it will be needed soon for Android. > > AFAICT, this has been a long standing bug in Android-x86 which was > worked around with the patch "GLSurfaceView: Be less picky about > EGLConfig alpha sizes". With this series, this patch is no longer needed > and several other bugs like wallpaper not getting displayed are fixed. > In the past similar changes has caused unexpected bugs and/or pert regressions. Although I doubt we'll notice them with the patches on the ML, thus I've pushed the lot to get some wider testing. Please keep an eye for fires ;-) >>> >>> Could these be back-ported to 11.2? >> >> DEFINITELY NOT. >> >> It's too risky and it has already broken GLX. > > OK so the problem is libGL ignores the red/green/blue mask, therefore > it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes > it's BGRA on the X server side. This patch series also ignores the > red/green/blue mask for imported buffers. That's why DRI2 mostly > works. I haven't tested DRI3. > > libGL could be fixed not to expose RGBA visuals, but that's > insufficient, because Mesa drivers must be loadable by older libGL > too. > > The bottom line is st/dri can't expose RGBA, because it would break > Mesa with old libGL. > > Unless you guys come up with a solution, I'll have to revert the st/dri > change. FYI, I've decided to revert the st/dri commit now to fix the KDE issue. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats
On 24 April 2016 at 14:20, Marek Olšák wrote: > On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák wrote: >> On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák wrote: >>> On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang >>> wrote: 2016-04-21 21:42 GMT+08:00 Emil Velikov : > > On 19 April 2016 at 20:38, Rob Herring wrote: >> The RGBX/RGBA pixel formats used in the Android EGL don't get configs >> created due to the missing formats in the DRI state tracker. This series >> adds the necessary formats for configs and DRI images. Support in GBM is >> also added as it will be needed soon for Android. >> >> AFAICT, this has been a long standing bug in Android-x86 which was >> worked around with the patch "GLSurfaceView: Be less picky about >> EGLConfig alpha sizes". With this series, this patch is no longer needed >> and several other bugs like wallpaper not getting displayed are fixed. >> > In the past similar changes has caused unexpected bugs and/or pert > regressions. > > Although I doubt we'll notice them with the patches on the ML, thus > I've pushed the lot to get some wider testing. > Please keep an eye for fires ;-) Could these be back-ported to 11.2? >>> >>> DEFINITELY NOT. >>> >>> It's too risky and it has already broken GLX. >> >> OK so the problem is libGL ignores the red/green/blue mask, therefore >> it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes >> it's BGRA on the X server side. This patch series also ignores the >> red/green/blue mask for imported buffers. That's why DRI2 mostly >> works. I haven't tested DRI3. >> >> libGL could be fixed not to expose RGBA visuals, but that's >> insufficient, because Mesa drivers must be loadable by older libGL >> too. >> >> The bottom line is st/dri can't expose RGBA, because it would break >> Mesa with old libGL. >> Speaking of which... I while back I was asking/proposing that we deprecate 'too old' loader (libGL) <> dri modules combos. Something like ~3 year difference came to mind (functionality based). Do we have (m)any people who explicitly test dri module from today and libGL form 5-6, 10 years ago ? How do you feel on the topic ? >> Unless you guys come up with a solution, I'll have to revert the st/dri >> change. > > FYI, I've decided to revert the st/dri commit now to fix the KDE > issue. > Ack. Thanks for looking into it Marek ! Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95020] a bug asking for an account
https://bugs.freedesktop.org/show_bug.cgi?id=95020 --- Comment #13 from Jan Ziak <0xe2.0x9a.0...@gmail.com> --- Just a note: I resolved the situation by Q1.A4 in http://github.com/tul-project/tul/blob/0ebe302b0c0d8f81d50c5303506f95a96b353846/FAQ.md -- 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 0/3] Support for Android RGBX/RGBA formats
2016-04-24 21:50 GMT+08:00 Emil Velikov : > On 24 April 2016 at 14:20, Marek Olšák wrote: >> On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák wrote: >>> On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák wrote: On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang wrote: > 2016-04-21 21:42 GMT+08:00 Emil Velikov : >> >> On 19 April 2016 at 20:38, Rob Herring wrote: >>> The RGBX/RGBA pixel formats used in the Android EGL don't get configs >>> created due to the missing formats in the DRI state tracker. This series >>> adds the necessary formats for configs and DRI images. Support in GBM is >>> also added as it will be needed soon for Android. >>> >>> AFAICT, this has been a long standing bug in Android-x86 which was >>> worked around with the patch "GLSurfaceView: Be less picky about >>> EGLConfig alpha sizes". With this series, this patch is no longer needed >>> and several other bugs like wallpaper not getting displayed are fixed. >>> >> In the past similar changes has caused unexpected bugs and/or pert >> regressions. >> >> Although I doubt we'll notice them with the patches on the ML, thus >> I've pushed the lot to get some wider testing. >> Please keep an eye for fires ;-) > > Could these be back-ported to 11.2? DEFINITELY NOT. It's too risky and it has already broken GLX. >>> >>> OK so the problem is libGL ignores the red/green/blue mask, therefore >>> it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes >>> it's BGRA on the X server side. This patch series also ignores the >>> red/green/blue mask for imported buffers. That's why DRI2 mostly >>> works. I haven't tested DRI3. >>> >>> libGL could be fixed not to expose RGBA visuals, but that's >>> insufficient, because Mesa drivers must be loadable by older libGL >>> too. >>> >>> The bottom line is st/dri can't expose RGBA, because it would break >>> Mesa with old libGL. >>> > Speaking of which... I while back I was asking/proposing that we > deprecate 'too old' loader (libGL) <> dri modules combos. Something > like ~3 year difference came to mind (functionality based). Do we have > (m)any people who explicitly test dri module from today and libGL form > 5-6, 10 years ago ? >>> > Ack. Thanks for looking into it Marek ! > > Emil > How do you feel on the topic ? > >>> Unless you guys come up with a solution, I'll have to revert the st/dri >>> change. >> >> FYI, I've decided to revert the st/dri commit now to fix the KDE >> issue. Why not just limit this commit to Android only? The RGBA is possibly only used by Android? Android-x86 community has waited such a fix for a very long time. Don't just drop it because it breaks others. -- Chih-Wei Android-x86 project http://www.android-x86.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95020] a bug asking for an account
https://bugs.freedesktop.org/show_bug.cgi?id=95020 --- Comment #14 from Jan Ziak <0xe2.0x9a.0...@gmail.com> --- Comment on attachment 123210 --> https://bugs.freedesktop.org/attachment.cgi?id=123210 attachment-24439-0.html >Just a note: I resolved the situation >by Q0.A4 in href="http://github.com/tul-project/tul/blob/0ebe302b0c0d8f81d50c5303506f95a96b353846/FAQ.md";>http://github.com/tul-project/tul/blob/0ebe302b0c0d8f81d50c5303506f95a96b353846/FAQ.md -- 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 95020] a bug asking for an account
https://bugs.freedesktop.org/show_bug.cgi?id=95020 Jan Ziak <0xe2.0x9a.0...@gmail.com> changed: What|Removed |Added Attachment #123210|0 |1 is obsolete|| -- 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] [PATCH] c11/threads: create mutexattrs only when needed
From: Emil Velikov
If the mutexattrs are the default one can just pass NULL to
pthread_mutex_init. As the compiler does not know this detail it
unnecessarily creates/destroys the attrs.
Signed-off-by: Emil Velikov
---
While going through GLVND, I've noticed that it (sort of) breaks its
assumptions/goals - 'we don't want the heavy locking/etc. brought by
pthreads' [for single threaded uses]
Thus I gave mesa a quick look and the following popped up:
- pthread_once - libglapi, classic + dri
Replace with an atomic test & set combo ?
- pthread_mutexattr_* - all dri modules, libGL-apple
Using a recursive lock in src/mesa/main/shared.c and
src/glx/apple/apple_glx_drawable.c
- pthread_key_* - EGL
- pthread_.etspecific - EGL
Extend pthread-stubs explicitly required it by mesa ?
Note: the original code that pthread-stubs is based on (libX11) does
have these ;-)
- pthread_barrier_* - llvmpipe
Fall-back to the mutex + cond implementation ?
- pthread_setname_np - llvmpipe
Do we need this ? Afaict the Windows build does not have an equivalent.
- pthread_join - nine, llvmpipe, radeon(s), rbug, omx (thanks bellagio)
- pthread_create - nine, llvmpipe, radeon(s), rbug
- pthread_sigmask - nine, llvmpipe, radeon(s), rbug
These four (five inc bellagio/omx) want more than one thread. How do we
get others pthread free, while keeping these happy ?
Please let me know how you feel on the topic. Do you see this as worthy
goal ? Does the proposed solutions sound OK ? Can you think of any
alternatives?
-Emil
P.S. For anyone who wonders, libc (GNU one only iirc) provides
lightweight stubs, thus single-threaded apps work without the overhead.
---
include/c11/threads_posix.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index ce9853b..11d36e4 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -180,9 +180,14 @@ mtx_init(mtx_t *mtx, int type)
&& type != (mtx_timed|mtx_recursive)
&& type != (mtx_try|mtx_recursive))
return thrd_error;
+
+if ((type & mtx_recursive) == 0) {
+pthread_mutex_init(mtx, NULL);
+return thrd_success;
+}
+
pthread_mutexattr_init(&attr);
-if ((type & mtx_recursive) != 0)
-pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
+pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(mtx, &attr);
pthread_mutexattr_destroy(&attr);
return thrd_success;
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95085] Invalid sampling of second texture in fragment shader that have two samplers with different parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=95085 Ilia Mirkin changed: What|Removed |Added QA Contact|intel-3d-bugs@lists.freedes |mesa-dev@lists.freedesktop. |ktop.org|org -- 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
Re: [Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats
On 24 April 2016 at 15:41, Chih-Wei Huang wrote: > 2016-04-24 21:50 GMT+08:00 Emil Velikov : >> On 24 April 2016 at 14:20, Marek Olšák wrote: >>> On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák wrote: On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák wrote: > On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang > wrote: >> 2016-04-21 21:42 GMT+08:00 Emil Velikov : >>> >>> On 19 April 2016 at 20:38, Rob Herring wrote: The RGBX/RGBA pixel formats used in the Android EGL don't get configs created due to the missing formats in the DRI state tracker. This series adds the necessary formats for configs and DRI images. Support in GBM is also added as it will be needed soon for Android. AFAICT, this has been a long standing bug in Android-x86 which was worked around with the patch "GLSurfaceView: Be less picky about EGLConfig alpha sizes". With this series, this patch is no longer needed and several other bugs like wallpaper not getting displayed are fixed. >>> In the past similar changes has caused unexpected bugs and/or pert >>> regressions. >>> >>> Although I doubt we'll notice them with the patches on the ML, thus >>> I've pushed the lot to get some wider testing. >>> Please keep an eye for fires ;-) >> >> Could these be back-ported to 11.2? > > DEFINITELY NOT. > > It's too risky and it has already broken GLX. OK so the problem is libGL ignores the red/green/blue mask, therefore it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes it's BGRA on the X server side. This patch series also ignores the red/green/blue mask for imported buffers. That's why DRI2 mostly works. I haven't tested DRI3. libGL could be fixed not to expose RGBA visuals, but that's insufficient, because Mesa drivers must be loadable by older libGL too. The bottom line is st/dri can't expose RGBA, because it would break Mesa with old libGL. >> Speaking of which... I while back I was asking/proposing that we >> deprecate 'too old' loader (libGL) <> dri modules combos. Something >> like ~3 year difference came to mind (functionality based). Do we have >> (m)any people who explicitly test dri module from today and libGL form >> 5-6, 10 years ago ? >> Ack. Thanks for looking into it Marek ! >> >> Emil > >> How do you feel on the topic ? >> Unless you guys come up with a solution, I'll have to revert the st/dri change. >>> >>> FYI, I've decided to revert the st/dri commit now to fix the KDE >>> issue. > > Why not just limit this commit to Android only? > The RGBA is possibly only used by Android? > I won't object if we keep it under some form of a switch - be that envvar, compile guard or others. If we cannot afford the android/cros approach and enforce and "X must run with Y" > Android-x86 community has waited such a fix > for a very long time. > Don't just drop it because it breaks others. > Sadly 'others' is the fast majority, so you can see why it was nuked. Although I think I can avoid the nasty solutions proposed above - just wire up a new flag to __DRIimageExtension::getCapabilities. This way loaders will probe the DRI module if it's ok with RGBX/RGBA formats keeping everyone happy ? -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] main: select ES3.2 version when all extensions are available
Signed-off-by: Ilia Mirkin
---
src/mesa/main/version.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index b9c1bcb..ffb7787 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -529,8 +529,24 @@ compute_version_es2(const struct gl_extensions *extensions,
extensions->ARB_texture_multisample &&
extensions->ARB_gpu_shader5 &&
extensions->EXT_shader_integer_mix);
+ const bool ver_3_2 = (ver_3_1 &&
+ /*extensions->KHR_blend_equation_advanced*/ false &&
+ extensions->KHR_texture_compression_astc_ldr &&
+ extensions->OES_copy_image &&
+ extensions->ARB_draw_buffers_blend &&
+ extensions->ARB_draw_elements_base_vertex &&
+ extensions->OES_geometry_shader &&
+ /*extensions->OES_primitive_bounding_box*/ false &&
+ extensions->OES_sample_variables &&
+ extensions->ARB_tessellation_shader &&
+ extensions->ARB_texture_border_clamp &&
+ extensions->OES_texture_buffer &&
+ extensions->ARB_texture_cube_map_array &&
+ extensions->ARB_texture_stencil8);
- if (ver_3_1) {
+ if (ver_3_2) {
+ return 32;
+ } else if (ver_3_1) {
return 31;
} else if (ver_3_0) {
return 30;
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: add ability to use essl 3.20
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/glsl_parser_extras.cpp | 7 +++
src/compiler/glsl/glsl_parser_extras.h | 2 ++
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 1 +
4 files changed, 11 insertions(+)
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index f097469..fea378f 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -231,6 +231,12 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct
gl_context *_ctx,
this->supported_versions[this->num_supported_versions].es = true;
this->num_supported_versions++;
}
+ if ((ctx->API == API_OPENGLES2 && ctx->Version >= 32) ||
+ ctx->Extensions.ARB_ES3_2_compatibility) {
+ this->supported_versions[this->num_supported_versions].ver = 320;
+ this->supported_versions[this->num_supported_versions].es = true;
+ this->num_supported_versions++;
+ }
/* Create a string for use in error messages to tell the user which GLSL
* versions are supported.
@@ -567,6 +573,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
/* ARB extensions go here, sorted alphabetically.
*/
EXT(ARB_ES3_1_compatibility, true, false,
ARB_ES3_1_compatibility),
+ EXT(ARB_ES3_2_compatibility, true, false,
ARB_ES3_2_compatibility),
EXT(ARB_arrays_of_arrays, true, false,
ARB_arrays_of_arrays),
EXT(ARB_compute_shader, true, false, ARB_compute_shader),
EXT(ARB_conservative_depth, true, false,
ARB_conservative_depth),
diff --git a/src/compiler/glsl/glsl_parser_extras.h
b/src/compiler/glsl/glsl_parser_extras.h
index 7d63d5b..d424b5f 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -512,6 +512,8 @@ struct _mesa_glsl_parse_state {
*/
bool ARB_ES3_1_compatibility_enable;
bool ARB_ES3_1_compatibility_warn;
+ bool ARB_ES3_2_compatibility_enable;
+ bool ARB_ES3_2_compatibility_warn;
bool ARB_arrays_of_arrays_enable;
bool ARB_arrays_of_arrays_warn;
bool ARB_compute_shader_enable;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 4769e37..13bcc2e 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -28,6 +28,7 @@ EXT(APPLE_vertex_array_object , dummy_true
EXT(ARB_ES2_compatibility , ARB_ES2_compatibility
, GLL, GLC, x , x , 2009)
EXT(ARB_ES3_1_compatibility , ARB_ES3_1_compatibility
, x , GLC, x , x , 2014)
+EXT(ARB_ES3_2_compatibility , ARB_ES3_2_compatibility
, x , GLC, x , x , 2015)
EXT(ARB_ES3_compatibility , ARB_ES3_compatibility
, GLL, GLC, x , x , 2012)
EXT(ARB_arrays_of_arrays, ARB_arrays_of_arrays
, GLL, GLC, x , x , 2012)
EXT(ARB_base_instance , ARB_base_instance
, GLL, GLC, x , x , 2011)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ccc8610..2b35c79 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3729,6 +3729,7 @@ struct gl_extensions
GLboolean ARB_ES2_compatibility;
GLboolean ARB_ES3_compatibility;
GLboolean ARB_ES3_1_compatibility;
+ GLboolean ARB_ES3_2_compatibility;
GLboolean ARB_arrays_of_arrays;
GLboolean ARB_base_instance;
GLboolean ARB_blend_func_extended;
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95110] Some Ogre 2.1 demos doesn't render properly
https://bugs.freedesktop.org/show_bug.cgi?id=95110 Bug ID: 95110 Summary: Some Ogre 2.1 demos doesn't render properly Product: Mesa Version: 11.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: megwa...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Some Ogre 2.1 demos (for example the "Sample_Hdr" demo) are misrendered with mesa drivers. For the "Sample_Hdr" demo, no shadows are rendered. Tested with r600g on JUNIPER XT chip. I also got this bug with LLVMPIPE. i965 on Skylake iGPU seems to have additional problems. I'll upload an apitrace as well as an image of what should be rendered. -- 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 95110] Some Ogre 2.1 demos doesn't render properly
https://bugs.freedesktop.org/show_bug.cgi?id=95110 --- Comment #1 from MWATTT --- Created attachment 123218 --> https://bugs.freedesktop.org/attachment.cgi?id=123218&action=edit Apitrace of "Sample_Hdr" demo -- 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] i965: Unroll SIMD16 DDY_FINE on Sandybridge.
On Tue, Mar 29, 2016 at 5:00 PM, Matt Turner wrote:
> On Tue, Mar 29, 2016 at 1:32 AM, Kenneth Graunke
> wrote:
>> I'm not sure why this is necessary, but it fixes 10 dEQP-GLES3 subtests
>> from dEQP-GLES3.functional.shaders.derivate.dfdy.texture.float_nicest.*.
>
> Okay, so we have to suspect that this is working around some related
> problem and it isn't that SIMD16 align16 instructions simply don't
> work on SNB. If this were the case we should have seen any of the
> piglit dfdy tests failing.
>
> If I had to guess, it could be that we're not accounting for
> even-register alignment, which I think applies to Sandybridge.
>
> I do notice that the add(16) instruction generated by the deqp tests
> you cite writes to an odd register, and the piglit tests write to an
> even register.
>
> If that is indeed the problem, it should apply to Gen5 (where we
> currently emit a SIMD16 align16 instruction) as well.
>
> Maybe we can hack up the deqp test to run on Gen5? If we could show
> that this code can't work in all circumstances on Gen5, we can
> simplify that condition greatly.
I tested on Sandybridge, and the tests pass sporadically. Using
INTEL_DEBUG=no16 allows them to pass always, which lends credence to
my hypothesis.
The simulator does not complain about sourcing an odd-aligned register
in an align16 add(16) instruction.
I also hacked up i965 to expose GLES3 on G45 and ran the test there.
The vec{2,3,4}_highp tests fail regardless of INTEL_DEBUG=no16.
Strangely all of the other tests pass, including the float_highp case.
The assembly generated for the passing mediump and failing highp cases
are the same. No idea what's going on.
Curro has my Ironlake, otherwise I'd test there. I suppose it's not a
problem there because the register allocator even-aligns all registers
used in SIMD16 operations.
Short of adding a register class on Sandybridge just for this case, I
think your patch is the right thing to do. With a comment added to the
block above stating that empirically Sandybridge cannot access
odd-aligned registers in compressed align16 instructions, this patch
gets my
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nouveau: codegen: combineLd/St do not combine indirect loads
On Fri, Apr 22, 2016 at 7:06 AM, Hans de Goede wrote:
> Hi,
>
>
> On 21-04-16 17:52, Ilia Mirkin wrote:
>>
>> On Thu, Apr 21, 2016 at 11:40 AM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 21-04-16 17:09, Samuel Pitoiset wrote:
On 04/21/2016 04:46 PM, Hans de Goede wrote:
>
>
> Hi,
>
> On 21-04-16 16:28, Ilia Mirkin wrote:
>>
>>
>> On Thu, Apr 21, 2016 at 9:55 AM, Hans de Goede
>> wrote:
>>>
>>>
>>> combineLd/St would combine, i.e. :
>>>
>>> st u32 # g[$r2+0x0] $r2
>>> st u32 # g[$r2+0x4] $r3
>>>
>>> into:
>>>
>>> st u64 # g[$r2+0x0] $r2d
>>>
>>> But this is only valid if r2 contains an 8 byte aligned address,
>>> which is unknown.
>>>
>>> This commit checks for src0 dim 0 not being indirect when combining
>>> loads / stores as combining indirect loads / stores may break
>>> alignment
>>> rules.
>>
>>
>>
>> I believe the assumption is that all indirect addresses are 16-byte
>> aligned. This works out for GL, I think. Although hm... I wonder what
>> happens if you have a
>>
>> layout (std430) buffer foo {
>> int x[16];
>> }
>>
>> And you access x[i], x[i+1], and i == 1. I think we end up doing a ton
>> of size-based validation which might avoid the problem.
>>
>> My concern is that now constbufs will get the same treatment, and for
>> constbufs the alignment is always 16 :(
>>
>> What do you think? Just drop those, or add extra conditionals to allow
>> it for constbufs?
>
>
>
> I'm not sure we've the alignment guarantee for constbufs, IIRC we lower
> const buf accesses to be indirect because we want to provide more then
> 8
> UBO-s,
> right ? So we read the offset from NVC0_CB_AUX_BUF_INFO and then end up
> with e.g.:
Right. This is because the launch descriptor used for compute shaders on
kepler only allows to set up 8 CBs. But OpenGL requires at least 14
UBOs, so
the logic is to stick UBOs' information into the driver constant buffer.
As you can, we do this dance for all UBOs because it's simpler that
testing if an UBO has been described in the launch descriptor or not (so
if
it's mapped as c1[], c2[], etc).
The lowering pass should properly handle indirect UBO accesses (I did
write a piglit test for that and looked at blob). But I'm not sure if we
can
break alignment here.
Do you have a simple shader that might hit the issue?
>>>
>>>
>>>
>>> I'm definitely hitting the issue with opencl programs,
>>> specifically with:
>>>
>>> piglit/tests/cl/program/execute/get-num-groups.cl
>>>
>>> Which contains:
>>>
>>> kernel void fill3d(global int* out) {
>>> unsigned int id = get_global_id(0) +
>>> get_global_size(0)*get_global_id(1
>>> out[3*id] = get_num_groups(0);
>>> out[3*id+1] = get_num_groups(1);
>>> out[3*id+2] = get_num_groups(2);
>>> }
>>>
>>> Notice the 3 * id, we end up combining
>>> get_num_groups(0) and get_num_groups(1)
>>> into a single 64 bit store, which for
>>> (id % 2 == 1) results in an unaligned trap
>>> on the gpu.
>>>
>>> Interestingly enough this is the only piglet cl
>>> test which triggers this, but still this is a real
>>> problem AFAICT.
>>>
>>> Note this gets translated into:
>>>
>>> COMP
>>> DCL SV[0], BLOCK_ID
>>> DCL SV[1], BLOCK_SIZE
>>> DCL SV[2], GRID_SIZE
>>> DCL SV[3], THREAD_ID
>>> DCL MEMORY[0], GLOBAL
>>> DCL MEMORY[1], SHARED
>>> DCL MEMORY[2], PRIVATE
>>> DCL MEMORY[3], INPUT
>>>
>>> IMM[0] UINT32 {2, 0, 0, 0}
>>> IMM[1] UINT32 {0, 0, 0, 0}
>>>0: BGNSUB :0
>>>1: UMUL TEMP[1].x, SV[1]., SV[0].
>>>2: UADD TEMP[1].x, SV[3]., TEMP[1].
>>>3: SHL TEMP[1].x, TEMP[1]., IMM[0].
>>>4: LOAD TEMP[1].y, MEMORY[3]., IMM[1]
>>>5: UADD TEMP[1].x, TEMP[1]., TEMP[1].
>>>6: STORE MEMORY[0].x, TEMP[1]., SV[2].
>>>7: RET
>>>8: ENDSUB
>>> IMM[2] UINT32 {3, 0, 0, 0}
>>> IMM[3] UINT32 {4, 0, 0, 0}
>>>9: BGNSUB :0
>>> 10: UMUL TEMP[1].x, SV[1]., SV[0].
>>> 11: UADD TEMP[1].x, SV[3]., TEMP[1].
>>> 12: UMUL TEMP[1].x, TEMP[1]., SV[2].
>>> 13: UADD TEMP[1].x, TEMP[1]., SV[0].
>>> 14: UMUL TEMP[1].x, TEMP[1]., SV[1].
>>> 15: UADD TEMP[1].x, TEMP[1]., SV[3].
>>> 16: SHL TEMP[1].x, TEMP[1]., IMM[2].
>>> 17: LOAD TEMP[1].y, MEMORY[3]., IMM[1]
>>> 18: UADD TEMP[1].z, TEMP[1]., TEMP[1].
>>> 19: STORE MEMORY[0].x, TEMP[1]., SV[2].
>>> 20: OR TEMP[1].x, TEMP[1]., IMM[3].
>>> 21: UADD TEMP[1].x, TEMP[1]., TEMP[1].
>>> 22: STORE MEMORY[0].x, TEMP[1]., SV[2].
>>> 23: RET
>>> 24: ENDSUB
>>> IMM[4] UINT32 {12, 0, 0, 0}
>>> IMM[5] UINT32 {8, 0, 0, 0}
>>> 25: BGNSUB :0
>>> 2
[Mesa-dev] [Bug 95085] Invalid sampling of second texture in fragment shader that have two samplers with different parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=95085 --- Comment #7 from Leonid Maksymchuk --- Thank for your help Ilia, tomorrow I'll make changes to geometry shader and post here the results. -- 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
Re: [Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats
On Sun, Apr 24, 2016 at 7:06 PM, Emil Velikov wrote: > On 24 April 2016 at 15:41, Chih-Wei Huang wrote: >> 2016-04-24 21:50 GMT+08:00 Emil Velikov : >>> On 24 April 2016 at 14:20, Marek Olšák wrote: On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák wrote: > On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák wrote: >> On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang >> wrote: >>> 2016-04-21 21:42 GMT+08:00 Emil Velikov : On 19 April 2016 at 20:38, Rob Herring wrote: > The RGBX/RGBA pixel formats used in the Android EGL don't get configs > created due to the missing formats in the DRI state tracker. This > series > adds the necessary formats for configs and DRI images. Support in GBM > is > also added as it will be needed soon for Android. > > AFAICT, this has been a long standing bug in Android-x86 which was > worked around with the patch "GLSurfaceView: Be less picky about > EGLConfig alpha sizes". With this series, this patch is no longer > needed > and several other bugs like wallpaper not getting displayed are fixed. > In the past similar changes has caused unexpected bugs and/or pert regressions. Although I doubt we'll notice them with the patches on the ML, thus I've pushed the lot to get some wider testing. Please keep an eye for fires ;-) >>> >>> Could these be back-ported to 11.2? >> >> DEFINITELY NOT. >> >> It's too risky and it has already broken GLX. > > OK so the problem is libGL ignores the red/green/blue mask, therefore > it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes > it's BGRA on the X server side. This patch series also ignores the > red/green/blue mask for imported buffers. That's why DRI2 mostly > works. I haven't tested DRI3. > > libGL could be fixed not to expose RGBA visuals, but that's > insufficient, because Mesa drivers must be loadable by older libGL > too. > > The bottom line is st/dri can't expose RGBA, because it would break > Mesa with old libGL. > >>> Speaking of which... I while back I was asking/proposing that we >>> deprecate 'too old' loader (libGL) <> dri modules combos. Something >>> like ~3 year difference came to mind (functionality based). Do we have >>> (m)any people who explicitly test dri module from today and libGL form >>> 5-6, 10 years ago ? > >>> Ack. Thanks for looking into it Marek ! >>> >>> Emil >> >>> How do you feel on the topic ? >>> > Unless you guys come up with a solution, I'll have to revert the st/dri > change. FYI, I've decided to revert the st/dri commit now to fix the KDE issue. >> >> Why not just limit this commit to Android only? >> The RGBA is possibly only used by Android? >> > I won't object if we keep it under some form of a switch - be that > envvar, compile guard or others. If we cannot afford the android/cros > approach and enforce and "X must run with Y" > >> Android-x86 community has waited such a fix >> for a very long time. >> Don't just drop it because it breaks others. >> > Sadly 'others' is the fast majority, so you can see why it was nuked. > > Although I think I can avoid the nasty solutions proposed above - just > wire up a new flag to __DRIimageExtension::getCapabilities. This way > loaders will probe the DRI module if it's ok with RGBX/RGBA formats > keeping everyone happy ? Well, it is the DRI modules that need to be told that it's okay to expose RGBA. You need a function that will send such a message to those modules before visuals are queried. Speaking of the compatibility with old libGL, I don't care about it, but there are others who care, such as Red Hat. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: add ability to use essl 3.20
For the two,
Reviewed-by: Dave Airlie
On 25 April 2016 at 03:35, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
> src/compiler/glsl/glsl_parser_extras.cpp | 7 +++
> src/compiler/glsl/glsl_parser_extras.h | 2 ++
> src/mesa/main/extensions_table.h | 1 +
> src/mesa/main/mtypes.h | 1 +
> 4 files changed, 11 insertions(+)
>
> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
> b/src/compiler/glsl/glsl_parser_extras.cpp
> index f097469..fea378f 100644
> --- a/src/compiler/glsl/glsl_parser_extras.cpp
> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
> @@ -231,6 +231,12 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct
> gl_context *_ctx,
>this->supported_versions[this->num_supported_versions].es = true;
>this->num_supported_versions++;
> }
> + if ((ctx->API == API_OPENGLES2 && ctx->Version >= 32) ||
> + ctx->Extensions.ARB_ES3_2_compatibility) {
> + this->supported_versions[this->num_supported_versions].ver = 320;
> + this->supported_versions[this->num_supported_versions].es = true;
> + this->num_supported_versions++;
> + }
>
> /* Create a string for use in error messages to tell the user which GLSL
> * versions are supported.
> @@ -567,6 +573,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> /* ARB extensions go here, sorted alphabetically.
> */
> EXT(ARB_ES3_1_compatibility, true, false,
> ARB_ES3_1_compatibility),
> + EXT(ARB_ES3_2_compatibility, true, false,
> ARB_ES3_2_compatibility),
> EXT(ARB_arrays_of_arrays, true, false,
> ARB_arrays_of_arrays),
> EXT(ARB_compute_shader, true, false,
> ARB_compute_shader),
> EXT(ARB_conservative_depth, true, false,
> ARB_conservative_depth),
> diff --git a/src/compiler/glsl/glsl_parser_extras.h
> b/src/compiler/glsl/glsl_parser_extras.h
> index 7d63d5b..d424b5f 100644
> --- a/src/compiler/glsl/glsl_parser_extras.h
> +++ b/src/compiler/glsl/glsl_parser_extras.h
> @@ -512,6 +512,8 @@ struct _mesa_glsl_parse_state {
> */
> bool ARB_ES3_1_compatibility_enable;
> bool ARB_ES3_1_compatibility_warn;
> + bool ARB_ES3_2_compatibility_enable;
> + bool ARB_ES3_2_compatibility_warn;
> bool ARB_arrays_of_arrays_enable;
> bool ARB_arrays_of_arrays_warn;
> bool ARB_compute_shader_enable;
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index 4769e37..13bcc2e 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -28,6 +28,7 @@ EXT(APPLE_vertex_array_object , dummy_true
>
> EXT(ARB_ES2_compatibility , ARB_ES2_compatibility
> , GLL, GLC, x , x , 2009)
> EXT(ARB_ES3_1_compatibility , ARB_ES3_1_compatibility
> , x , GLC, x , x , 2014)
> +EXT(ARB_ES3_2_compatibility , ARB_ES3_2_compatibility
> , x , GLC, x , x , 2015)
> EXT(ARB_ES3_compatibility , ARB_ES3_compatibility
> , GLL, GLC, x , x , 2012)
> EXT(ARB_arrays_of_arrays, ARB_arrays_of_arrays
> , GLL, GLC, x , x , 2012)
> EXT(ARB_base_instance , ARB_base_instance
> , GLL, GLC, x , x , 2011)
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index ccc8610..2b35c79 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3729,6 +3729,7 @@ struct gl_extensions
> GLboolean ARB_ES2_compatibility;
> GLboolean ARB_ES3_compatibility;
> GLboolean ARB_ES3_1_compatibility;
> + GLboolean ARB_ES3_2_compatibility;
> GLboolean ARB_arrays_of_arrays;
> GLboolean ARB_base_instance;
> GLboolean ARB_blend_func_extended;
> --
> 2.7.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] nir/lower_double_ops: lower trunc()
On Fri, 2016-04-22 at 15:06 -0700, Jason Ekstrand wrote:
> Reviewed-by: Jason Ekstrand
>
>
> Did the v2 fix anything other than newly added tests?
No, only the new tests that targeted the cases where the unbiased
exponent was between 0 and 52.
Iago
> --Jason
>
>
> On Thu, Apr 21, 2016 at 10:13 PM, Samuel Iglesias Gonsálvez
> wrote:
> From: Iago Toral Quiroga
>
> At least i965 hardware does not have native support for
> truncating doubles.
>
> v2:
> - Simplified the implementation significantly.
> - Fixed the else branch, that was not doing what we wanted.
> ---
> src/compiler/nir/nir.h | 1 +
> src/compiler/nir/nir_lower_double_ops.c | 60
> +
> 2 files changed, 61 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 9bfb24a..ab8ae99 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2330,6 +2330,7 @@ typedef enum {
> nir_lower_drcp = (1 << 0),
> nir_lower_dsqrt = (1 << 1),
> nir_lower_drsq = (1 << 2),
> + nir_lower_dtrunc = (1 << 3),
> } nir_lower_doubles_options;
>
> void nir_lower_doubles(nir_shader *shader,
> nir_lower_doubles_options options);
> diff --git a/src/compiler/nir/nir_lower_double_ops.c
> b/src/compiler/nir/nir_lower_double_ops.c
> index e22e822..e8ae884 100644
> --- a/src/compiler/nir/nir_lower_double_ops.c
> +++ b/src/compiler/nir/nir_lower_double_ops.c
> @@ -299,6 +299,58 @@ lower_sqrt_rsq(nir_builder *b,
> nir_ssa_def *src, bool sqrt)
> return res;
> }
>
> +static nir_ssa_def *
> +lower_trunc(nir_builder *b, nir_ssa_def *src)
> +{
> + nir_ssa_def *unbiased_exp = nir_isub(b, get_exponent(b,
> src),
> +nir_imm_int(b,
> 1023));
> +
> + nir_ssa_def *frac_bits = nir_isub(b, nir_imm_int(b, 52),
> unbiased_exp);
> +
> + /*
> +* Decide the operation to apply depending on the unbiased
> exponent:
> +*
> +* if (unbiased_exp < 0)
> +*return 0
> +* else if (unbiased_exp > 52)
> +*return src
> +* else
> +*return src & (~0 << frac_bits)
> +*
> +* Notice that the else branch is a 64-bit integer
> operation that we need
> +* to implement in terms of 32-bit integer arithmetics (at
> least until we
> +* support 64-bit integer arithmetics).
> +*/
> +
> + /* Compute "~0 << frac_bits" in terms of hi/lo 32-bit
> integer math */
> + nir_ssa_def *mask_lo =
> + nir_bcsel(b,
> +nir_ige(b, frac_bits, nir_imm_int(b, 32)),
> +nir_imm_int(b, 0),
> +nir_ishl(b, nir_imm_int(b, ~0), frac_bits));
> +
> + nir_ssa_def *mask_hi =
> + nir_bcsel(b,
> +nir_ilt(b, frac_bits, nir_imm_int(b, 33)),
> +nir_imm_int(b, ~0),
> +nir_ishl(b,
> + nir_imm_int(b, ~0),
> + nir_isub(b, frac_bits,
> nir_imm_int(b, 32;
> +
> + nir_ssa_def *src_lo = nir_unpack_double_2x32_split_x(b,
> src);
> + nir_ssa_def *src_hi = nir_unpack_double_2x32_split_y(b,
> src);
> +
> + return
> + nir_bcsel(b,
> +nir_ilt(b, unbiased_exp, nir_imm_int(b, 0)),
> +nir_imm_double(b, 0.0),
> +nir_bcsel(b, nir_ige(b, unbiased_exp,
> nir_imm_int(b, 53)),
> + src,
> + nir_pack_double_2x32_split(b,
> +
> nir_iand(b, mask_lo, src_lo),
> +
> nir_iand(b, mask_hi, src_hi;
> +}
> +
> static void
> lower_doubles_instr(nir_alu_instr *instr,
> nir_lower_doubles_options options)
> {
> @@ -322,6 +374,11 @@ lower_doubles_instr(nir_alu_instr *instr,
> nir_lower_doubles_options options)
> return;
>break;
>
> + case nir_op_ftrunc:
> + if (!(options & nir_lower_dtrunc))
> + return;
> + break;
> +
> default:
>return;
> }
> @@ -345,6 +402,9 @@ lower_doubles_instr(nir_alu_instr *instr,
> nir_lower_doubles_options options)
> case nir_op_frsq:
>
Re: [Mesa-dev] [PATCH 06/13] nir/lower_double_ops: lower floor()
On 23/04/16 00:13, Jason Ekstrand wrote:
> On Tue, Apr 12, 2016 at 1:05 AM, Samuel Iglesias Gonsálvez <
> sigles...@igalia.com> wrote:
>
>> From: Iago Toral Quiroga
>>
>> At least i965 hardware does not have native support for floor on doubles.
>> ---
>> src/compiler/nir/nir.h | 1 +
>> src/compiler/nir/nir_lower_double_ops.c | 29 +
>> 2 files changed, 30 insertions(+)
>>
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index f83b2e0..b7231a7 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -2287,6 +2287,7 @@ typedef enum {
>> nir_lower_dsqrt = (1 << 1),
>> nir_lower_drsq = (1 << 2),
>> nir_lower_dtrunc = (1 << 3),
>> + nir_lower_dfloor = (1 << 4),
>> } nir_lower_doubles_options;
>>
>> void nir_lower_doubles(nir_shader *shader, nir_lower_doubles_options
>> options);
>> diff --git a/src/compiler/nir/nir_lower_double_ops.c
>> b/src/compiler/nir/nir_lower_double_ops.c
>> index 9eec858..e1ec6da 100644
>> --- a/src/compiler/nir/nir_lower_double_ops.c
>> +++ b/src/compiler/nir/nir_lower_double_ops.c
>> @@ -377,6 +377,27 @@ lower_trunc(nir_builder *b, nir_ssa_def *src)
>> return nir_pack_double_2x32_split(b, new_src_lo, new_src_hi);
>> }
>>
>> +static nir_ssa_def *
>> +lower_floor(nir_builder *b, nir_ssa_def *src)
>> +{
>> + /*
>> +* For x >= 0, floor(x) = trunc(x)
>> +* For x < 0,
>> +*- if x is integer, floor(x) = x
>> +*- otherwise, floor(x) = trunc(x) - 1
>> +*/
>> + nir_ssa_def *tr = nir_ftrunc(b, src);
>> + return nir_bcsel(b,
>> +nir_fge(b, src, nir_imm_double(b, 0.0)),
>> +tr,
>> +nir_bcsel(b,
>> + nir_fne(b,
>> + nir_fsub(b, src, tr),
>> + nir_imm_double(b, 0.0)),
>>
>
> As an aside, you can just as easily check "x is integer" by "x ==
> truc(x)". That might be simpler. Same goes for ceil().
>
OK, I will do this change here and in ceil().
Sam
>
>> + nir_fsub(b, tr, nir_imm_double(b, 1.0)),
>> + src));
>> +}
>> +
>> static void
>> lower_doubles_instr(nir_alu_instr *instr, nir_lower_doubles_options
>> options)
>> {
>> @@ -405,6 +426,11 @@ lower_doubles_instr(nir_alu_instr *instr,
>> nir_lower_doubles_options options)
>> return;
>>break;
>>
>> + case nir_op_ffloor:
>> + if (!(options & nir_lower_dfloor))
>> + return;
>> + break;
>> +
>> default:
>>return;
>> }
>> @@ -431,6 +457,9 @@ lower_doubles_instr(nir_alu_instr *instr,
>> nir_lower_doubles_options options)
>> case nir_op_ftrunc:
>>result = lower_trunc(&bld, src);
>>break;
>> + case nir_op_ffloor:
>> + result = lower_floor(&bld, src);
>> + break;
>> default:
>>unreachable("unhandled opcode");
>> }
>> --
>> 2.5.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 10/13] nir: verify destination bit size when checking algebraic optimizations
On 24/04/16 06:49, Jason Ekstrand wrote:
> On Apr 12, 2016 1:06 AM, "Samuel Iglesias Gonsálvez"
> wrote:
>>
>> Some instructions (like flrp in i965) cannot be lowered depending on the
>> bit size because it doesn't support all bit sizes.
>>
>> If the bit size field is defined in nir_opt_algebraic.py, take it into
>> account.
>
> I'm sorry I keep punting on this patch. I've never really like tacking yet
> another argument on to the end of the expression but for a long time i
> couldn't cone up with anything better. How about this: Add a bit_size
> field to nir_search_value and allow you to write 'flrp@64' to indicate a
> 64-bit destination on an ALU op, 'x@64' to indicate a 64-bit "variable",
> and '1.0@64' to indicate a 64-bit constant. Then it could be used both to
> check for a particular bit-size in the search expression and to allow you
> to specify a bit-size when constructing a value in case it's ambiguous.
>
> If you're amenable to the idea, I'll hack on it a bit on Monday. I've been
> meaning to add a bit-size validator to nir_algebraic.py for some time now
> anyway.
>
Yeah, I like your proposal. Go ahead :)
Thanks for taking care of this.
Sam
> --Jason
>
>> Signed-off-by: Samuel Iglesias Gonsálvez
>> ---
>> src/compiler/nir/nir_algebraic.py | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/compiler/nir/nir_algebraic.py
> b/src/compiler/nir/nir_algebraic.py
>> index 53a7907..f3630e0 100644
>> --- a/src/compiler/nir/nir_algebraic.py
>> +++ b/src/compiler/nir/nir_algebraic.py
>> @@ -180,6 +180,11 @@ class SearchAndReplace(object):
>>else:
>> self.condition = 'true'
>>
>> + if len(transform) > 3:
>> + self.bit_size = transform[3]
>> + else:
>> + self.bit_size = 0
>> +
>>if self.condition not in condition_list:
>> condition_list.append(self.condition)
>>self.condition_index = condition_list.index(self.condition)
>> @@ -208,6 +213,7 @@ struct transform {
>> const nir_search_expression *search;
>> const nir_search_value *replace;
>> unsigned condition_offset;
>> + unsigned bit_size;
>> };
>>
>> struct opt_state {
>> @@ -226,7 +232,7 @@ struct opt_state {
>>
>> static const struct transform ${pass_name}_${opcode}_xforms[] = {
>> % for xform in xform_list:
>> - { &${xform.search.name}, ${xform.replace.c_ptr},
> ${xform.condition_index} },
>> + { &${xform.search.name}, ${xform.replace.c_ptr},
> ${xform.condition_index}, ${xform.bit_size}},
>> % endfor
>> };
>> % endfor
>> @@ -249,6 +255,9 @@ ${pass_name}_block(nir_block *block, void *void_state)
>>case nir_op_${opcode}:
>> for (unsigned i = 0; i <
> ARRAY_SIZE(${pass_name}_${opcode}_xforms); i++) {
>> const struct transform *xform =
> &${pass_name}_${opcode}_xforms[i];
>> +if (xform->bit_size != 0 &&
>> +alu->dest.dest.ssa.bit_size != xform->bit_size)
>> + continue;
>> if (state->condition_flags[xform->condition_offset] &&
>> nir_replace_instr(alu, xform->search, xform->replace,
>>state->mem_ctx)) {
>> --
>> 2.5.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 06/13] nir/lower_double_ops: lower floor()
On 23/04/16 00:17, Jason Ekstrand wrote:
> On Fri, Apr 22, 2016 at 3:13 PM, Jason Ekstrand
> wrote:
>
>>
>>
>> On Tue, Apr 12, 2016 at 1:05 AM, Samuel Iglesias Gonsálvez <
>> sigles...@igalia.com> wrote:
>>
>>> From: Iago Toral Quiroga
>>>
>>> At least i965 hardware does not have native support for floor on doubles.
>>> ---
>>> src/compiler/nir/nir.h | 1 +
>>> src/compiler/nir/nir_lower_double_ops.c | 29
>>> +
>>> 2 files changed, 30 insertions(+)
>>>
>>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>>> index f83b2e0..b7231a7 100644
>>> --- a/src/compiler/nir/nir.h
>>> +++ b/src/compiler/nir/nir.h
>>> @@ -2287,6 +2287,7 @@ typedef enum {
>>> nir_lower_dsqrt = (1 << 1),
>>> nir_lower_drsq = (1 << 2),
>>> nir_lower_dtrunc = (1 << 3),
>>> + nir_lower_dfloor = (1 << 4),
>>> } nir_lower_doubles_options;
>>>
>>> void nir_lower_doubles(nir_shader *shader, nir_lower_doubles_options
>>> options);
>>> diff --git a/src/compiler/nir/nir_lower_double_ops.c
>>> b/src/compiler/nir/nir_lower_double_ops.c
>>> index 9eec858..e1ec6da 100644
>>> --- a/src/compiler/nir/nir_lower_double_ops.c
>>> +++ b/src/compiler/nir/nir_lower_double_ops.c
>>> @@ -377,6 +377,27 @@ lower_trunc(nir_builder *b, nir_ssa_def *src)
>>> return nir_pack_double_2x32_split(b, new_src_lo, new_src_hi);
>>> }
>>>
>>> +static nir_ssa_def *
>>> +lower_floor(nir_builder *b, nir_ssa_def *src)
>>> +{
>>> + /*
>>> +* For x >= 0, floor(x) = trunc(x)
>>> +* For x < 0,
>>> +*- if x is integer, floor(x) = x
>>> +*- otherwise, floor(x) = trunc(x) - 1
>>> +*/
>>> + nir_ssa_def *tr = nir_ftrunc(b, src);
>>> + return nir_bcsel(b,
>>> +nir_fge(b, src, nir_imm_double(b, 0.0)),
>>> +tr,
>>> +nir_bcsel(b,
>>> + nir_fne(b,
>>> + nir_fsub(b, src, tr),
>>> + nir_imm_double(b, 0.0)),
>>>
>>
>> As an aside, you can just as easily check "x is integer" by "x ==
>> truc(x)". That might be simpler. Same goes for ceil().
>>
>
> One more thought (Sorry for all the e-mails): It might be better to
> implement this as
>
> floor(x) = (x >= 0 || x == trunc(x)) ? trunc(x) : trunc(x) - 1;
>
> That way you only have one bcsel and fewer 64-bit values floating around.
> It *might* reduce register pressure (not sure if it actually will).
> --Jason
>
Yeah, good idea. I will do this change for floor() and ceil() and check
if it reduces register pressure. Anyway, it saves one bcsel which is great.
Thanks!
Sam
>
>> + nir_fsub(b, tr, nir_imm_double(b, 1.0)),
>>> + src));
>>> +}
>>> +
>>> static void
>>> lower_doubles_instr(nir_alu_instr *instr, nir_lower_doubles_options
>>> options)
>>> {
>>> @@ -405,6 +426,11 @@ lower_doubles_instr(nir_alu_instr *instr,
>>> nir_lower_doubles_options options)
>>> return;
>>>break;
>>>
>>> + case nir_op_ffloor:
>>> + if (!(options & nir_lower_dfloor))
>>> + return;
>>> + break;
>>> +
>>> default:
>>>return;
>>> }
>>> @@ -431,6 +457,9 @@ lower_doubles_instr(nir_alu_instr *instr,
>>> nir_lower_doubles_options options)
>>> case nir_op_ftrunc:
>>>result = lower_trunc(&bld, src);
>>>break;
>>> + case nir_op_ffloor:
>>> + result = lower_floor(&bld, src);
>>> + break;
>>> default:
>>>unreachable("unhandled opcode");
>>> }
>>> --
>>> 2.5.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 2/5] i965: Mark URB reads as volatile.
Patches 1 and 2 are: Reviewed-by: Eduardo Lima Mitev On 04/22/2016 07:32 AM, Kenneth Graunke wrote: > They can be affected by URB writes. > > In the upcoming scalar TCS backend, this prevents read-modify-write > cycles from being broken by CSE removing reads. > > Signed-off-by: Kenneth Graunke > --- > src/mesa/drivers/dri/i965/brw_shader.cpp | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp > b/src/mesa/drivers/dri/i965/brw_shader.cpp > index b3aade1..d9e654c 100644 > --- a/src/mesa/drivers/dri/i965/brw_shader.cpp > +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp > @@ -961,6 +961,9 @@ backend_instruction::is_volatile() const > case SHADER_OPCODE_UNTYPED_SURFACE_READ_LOGICAL: > case SHADER_OPCODE_TYPED_SURFACE_READ: > case SHADER_OPCODE_TYPED_SURFACE_READ_LOGICAL: > + case SHADER_OPCODE_URB_READ_SIMD8: > + case SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT: > + case VEC4_OPCODE_URB_READ: >return true; > default: >return false; > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
