[Mesa-dev] [PATCH 2/9] i965: check malloc return value in intel_resolve_map_set()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/intel_resolve_map.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
index bf6bcf2..bb45231 100644
--- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
+++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
@@ -22,6 +22,7 @@
*/
#include "intel_resolve_map.h"
+#include "main/imports.h"
#include
#include
@@ -46,6 +47,11 @@ intel_resolve_map_set(struct exec_list *resolve_map,
}
struct intel_resolve_map *m = malloc(sizeof(struct intel_resolve_map));
+ if (m == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
exec_node_init(&m->link);
m->level = level;
m->layer = layer;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] glsl: Check calloc return value in link_intrastage_shaders()
Check calloc return value while adding build-in functions.
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/linker.cpp | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index d588bc6..2f004f1 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1705,12 +1705,19 @@ link_intrastage_shaders(void *mem_ctx,
*/
gl_shader **linking_shaders = (gl_shader **)
calloc(num_shaders + 1, sizeof(gl_shader *));
- memcpy(linking_shaders, shader_list, num_shaders * sizeof(gl_shader *));
- linking_shaders[num_shaders] = _mesa_glsl_get_builtin_function_shader();
- ok = link_function_calls(prog, linked, linking_shaders, num_shaders + 1);
+ ok = linking_shaders != NULL;
- free(linking_shaders);
+ if (ok) {
+ memcpy(linking_shaders, shader_list, num_shaders * sizeof(gl_shader
*));
+ linking_shaders[num_shaders] =
_mesa_glsl_get_builtin_function_shader();
+
+ ok = link_function_calls(prog, linked, linking_shaders, num_shaders +
1);
+
+ free(linking_shaders);
+ } else {
+ _mesa_error_no_memory(__func__);
+ }
} else {
ok = link_function_calls(prog, linked, shader_list, num_shaders);
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/9] i965: Avoid null access in intelMakeCurrent()
separate two null checks connected with && to their own if branches.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_context.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index c47ad36..f1f1f7d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -928,13 +928,17 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
struct gl_context *ctx = &brw->ctx;
struct gl_framebuffer *fb, *readFb;
- if (driDrawPriv == NULL && driReadPriv == NULL) {
+ if (driDrawPriv == NULL) {
fb = _mesa_get_incomplete_framebuffer();
- readFb = _mesa_get_incomplete_framebuffer();
} else {
fb = driDrawPriv->driverPrivate;
- readFb = driReadPriv->driverPrivate;
driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
+ }
+
+ if (driReadPriv == NULL) {
+ readFb = _mesa_get_incomplete_framebuffer();
+ } else {
+ readFb = driReadPriv->driverPrivate;
driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/9] Klocwork patches again
i965: Avoid null access in intelMakeCurrent() I was a bit iffy if its the same behavior which I replaced. i965: in set_read_rb_tex_image() check _mesa_meta_bind_rb_as_tex_image() did succeed - I tried to follow Topi's suggestion. I did not go touching brw_meta_updownsample() here, it is left for another patch. /Juha-Pekka Juha-Pekka Heikkila (9): i965: in set_read_rb_tex_image() check _mesa_meta_bind_rb_as_tex_image() did succeed i965: check malloc return value in intel_resolve_map_set() i965: Avoid null access in intelMakeCurrent() glsl: Check calloc return value in link_intrastage_shaders() loader: Check dlsym() did not fail in libudev_get_device_name_for_fd() glsl: Check realloc return value in ir_function::matching_signature() i965: Avoid null access in fs_generator::generate_code() i965: Check after malloc success in intel_miptree_alloc_hiz() mesa/main: Check allocations success in _mesa_one_time_init_extension_overrides() src/glsl/ir_function.cpp | 11 +-- src/glsl/linker.cpp | 15 +++ src/loader/loader.c | 3 +++ src/mesa/drivers/common/meta_blit.c | 10 +- src/mesa/drivers/dri/i965/brw_context.c | 10 +++--- src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 8 ++-- src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 14 ++ src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 src/mesa/drivers/dri/i965/intel_resolve_map.c | 6 ++ src/mesa/main/extensions.c| 9 + 10 files changed, 74 insertions(+), 16 deletions(-) -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 9/9] mesa/main: Check allocations success in _mesa_one_time_init_extension_overrides()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/extensions.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 92e3f0d..cd89e8f 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -602,6 +602,15 @@ _mesa_one_time_init_extension_overrides(void)
/* Copy env_const because strtok() is destructive. */
env = strdup(env_const);
+
+ if (env == NULL || extra_extensions == NULL ||
+ cant_disable_extensions == NULL) {
+ free(env);
+ free(extra_extensions);
+ free(cant_disable_extensions);
+ return;
+ }
+
for (ext = strtok(env, " "); ext != NULL; ext = strtok(NULL, " ")) {
int enable;
bool recognized;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] i965: in set_read_rb_tex_image() check _mesa_meta_bind_rb_as_tex_image() did succeed
Check if _mesa_meta_bind_rb_as_tex_image() did give the texture.
If no texture was given there is already either
GL_INVALID_VALUE or GL_OUT_OF_MEMORY error set in context.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/common/meta_blit.c | 10 +-
src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 14 ++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index bbf0c3c..1fd4d1b 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -615,13 +615,21 @@ _mesa_meta_bind_rb_as_tex_image(struct gl_context *ctx,
GLenum *target)
{
struct gl_texture_image *texImage;
+ GLuint tempTex;
if (rb->NumSamples > 1)
*target = GL_TEXTURE_2D_MULTISAMPLE;
else
*target = GL_TEXTURE_2D;
- _mesa_GenTextures(1, tex);
+ tempTex = 0;
+ _mesa_GenTextures(1, &tempTex);
+ if (tempTex == 0) {
+ return false;
+ }
+
+ *tex = tempTex;
+
_mesa_BindTexture(*target, *tex);
*texObj = _mesa_lookup_texture(ctx, *tex);
texImage = _mesa_get_tex_image(ctx, *texObj, *target, 0);
diff --git a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
index bdd642b..11ac92b 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
@@ -371,7 +371,7 @@ prepare_vertex_data(void)
_mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
}
-static void
+static bool
set_read_rb_tex_image(struct gl_context *ctx, struct fb_tex_blit_state *blit,
GLenum *target)
{
@@ -387,8 +387,10 @@ set_read_rb_tex_image(struct gl_context *ctx, struct
fb_tex_blit_state *blit,
*target = tex_obj->Target;
level = att->TextureLevel;
} else {
- _mesa_meta_bind_rb_as_tex_image(ctx, rb, &blit->tempTex, &tex_obj,
- target);
+ if (!_mesa_meta_bind_rb_as_tex_image(ctx, rb, &blit->tempTex, &tex_obj,
+ target)) {
+ return false;
+ }
}
blit->baseLevelSave = tex_obj->BaseLevel;
@@ -396,6 +398,7 @@ set_read_rb_tex_image(struct gl_context *ctx, struct
fb_tex_blit_state *blit,
blit->stencilSamplingSave = tex_obj->StencilSampling;
blit->sampler = _mesa_meta_setup_sampler(ctx, tex_obj, *target,
GL_NEAREST, level);
+ return true;
}
static void
@@ -424,7 +427,9 @@ brw_meta_stencil_blit(struct brw_context *brw,
_mesa_DrawBuffer(GL_COLOR_ATTACHMENT0);
ctx->DrawBuffer->_Status = GL_FRAMEBUFFER_COMPLETE;
- set_read_rb_tex_image(ctx, &blit, &target);
+ if (!set_read_rb_tex_image(ctx, &blit, &target)) {
+ goto error;
+ }
_mesa_TexParameteri(target, GL_DEPTH_STENCIL_TEXTURE_MODE,
GL_STENCIL_INDEX);
@@ -446,6 +451,7 @@ brw_meta_stencil_blit(struct brw_context *brw,
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
_mesa_meta_fb_tex_blit_end(ctx, target, &blit);
+error:;
_mesa_meta_end(ctx);
_mesa_DeleteRenderbuffers(1, &rbo);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9] glsl: Check realloc return value in ir_function::matching_signature()
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/ir_function.cpp | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index 7d6c2f4..04ab5ab 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -24,6 +24,7 @@
#include "glsl_types.h"
#include "ir.h"
#include "glsl_parser_extras.h"
+#include "main/errors.h"
typedef enum {
PARAMETER_LIST_NO_MATCH,
@@ -293,6 +294,7 @@ ir_function::matching_signature(_mesa_glsl_parse_state
*state,
bool *is_exact)
{
ir_function_signature **inexact_matches = NULL;
+ ir_function_signature **inexact_matches_temp;
ir_function_signature *match = NULL;
int num_inexact_matches = 0;
@@ -317,11 +319,16 @@ ir_function::matching_signature(_mesa_glsl_parse_state
*state,
free(inexact_matches);
return sig;
case PARAMETER_LIST_INEXACT_MATCH:
- inexact_matches = (ir_function_signature **)
+ inexact_matches_temp = (ir_function_signature **)
realloc(inexact_matches,
sizeof(*inexact_matches) *
(num_inexact_matches + 1));
- assert(inexact_matches);
+ if (inexact_matches_temp == NULL) {
+_mesa_error_no_memory(__func__);
+free(inexact_matches);
+return NULL;
+ }
+ inexact_matches = inexact_matches_temp;
inexact_matches[num_inexact_matches++] = sig;
continue;
case PARAMETER_LIST_NO_MATCH:
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/9] loader: Check dlsym() did not fail in libudev_get_device_name_for_fd()
Signed-off-by: Juha-Pekka Heikkila --- src/loader/loader.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/loader/loader.c b/src/loader/loader.c index 47e1f58..2205a9c 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -594,6 +594,9 @@ libudev_get_device_name_for_fd(int fd) (struct udev_device *)); UDEV_SYMBOL(struct udev *, udev_unref, (struct udev *)); + if (dlsym_failed) + return NULL; + udev = udev_new(); device = udev_device_new_from_fd(udev, fd); if (device == NULL) -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/9] i965: Check after malloc success in intel_miptree_alloc_hiz()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 2ab0faa..30030d1 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1399,6 +1399,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
for (int layer = 0; layer < mt->level[level].depth; ++layer) {
struct intel_resolve_map *m = malloc(sizeof(struct
intel_resolve_map));
+ if (!m) {
+_mesa_error_no_memory(__func__);
+return false;
+ }
exec_node_init(&m->link);
m->level = level;
m->layer = layer;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9] i965: Avoid null access in fs_generator::generate_code()
Avoid null access while printing debug infos. On the same go
change local variable name to avoid confusion because there
already is class member with same name.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 52e88d4..6e201d1 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1783,9 +1783,13 @@ fs_generator::generate_code(exec_list *instructions)
dispatch_width, before_size / 16, before_size, after_size,
100.0f * (before_size - after_size) / before_size);
- const struct gl_program *prog = fp ? &fp->Base : NULL;
+ const struct gl_program *fp_prog = fp ? &fp->Base : NULL;
+
+ if (fp_prog) {
+ dump_assembly(p->store, annotation.ann_count, annotation.ann, brw,
+ fp_prog);
+ }
- dump_assembly(p->store, annotation.ann_count, annotation.ann, brw, prog);
ralloc_free(annotation.ann);
}
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits
2014-07-02 21:59 GMT+02:00 Brian Paul : > On 07/02/2014 01:04 PM, Andreas Boll wrote: >> >> I'd like to make a new demos release on Friday, July 4th. >> The last release was on February 24th, 2013. Additionally this >> release is needed to fix the build with mesa 10.2. (fdo#78101) >> >> Any objections? > > > Sounds great. > > > >> Also I'd like to get these 3 patches included in the new release. > > > Reviewed-by: Brian Paul > > Do you need me to push these patches? > > -Brian > Thanks! I have pushed these patches myself. Andreas. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits
2014-07-03 3:09 GMT+02:00 Ilia Mirkin : > On Wed, Jul 2, 2014 at 3:04 PM, Andreas Boll > wrote: >> I'd like to make a new demos release on Friday, July 4th. >> The last release was on February 24th, 2013. Additionally this >> release is needed to fix the build with mesa 10.2. (fdo#78101) >> >> Any objections? > > Not an objection, but since there's like one of these every 2 years, > perhaps someone would be willing to go through the various GL4 > extensions and add prints for the interesting limits? Or do people > feel that the current code + the below patches capture all the > interesting stuff? > > -ilia Sure, I just wanted to get the patches from the ML merged and make a new release. If people want me to wait with the release, please speak. Otherwise I can make further releases when required. We don't have to wait another 2 years for the next release ;-) Andreas. P.S.: If someone could point me the interesting limits which are missing, I could write a patch. > >> >> Also I'd like to get these 3 patches included in the new release. >> >> Andreas. >> >> >> Fredrik Höglund (3): >> glxinfo: Print XFB, TBO, and UBO limits >> glxinfo: Print GL_ARB_vertex_attrib_binding limits >> glxinfo: Print GL_EXT_texture_array limits >> >> src/xdemos/glinfo_common.c | 30 ++ >> 1 file changed, 30 insertions(+) >> >> -- >> 2.0.0 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits
2014-07-03 7:39 GMT+02:00 Steven Newbury : > On Wed, 2014-07-02 at 21:04 +0200, Andreas Boll wrote: > >> I'd like to make a new demos release on Friday, July 4th. >> The last release was on February 24th, 2013. Additionally this >> release is needed to fix the build with mesa 10.2. (fdo#78101) >> >> Any objections? >> >> Also I'd like to get these 3 patches included in the new release. >> >> Andreas. >> >> >> Fredrik Höglund (3): >> glxinfo: Print XFB, TBO, and UBO limits >> glxinfo: Print GL_ARB_vertex_attrib_binding limits >> glxinfo: Print GL_EXT_texture_array limits >> >> src/xdemos/glinfo_common.c | 30 ++ >> 1 file changed, 30 insertions(+) >> > > What about extending eglinfo to have switches to enable printing glxinfo > style output for each supported API? > Sounds good, feel free to send a patch. Although I'm not planning to hold off this release. I can make further releases when required. Andreas. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. I tried to get EGL working with my DRM device and it always ask for an atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this point). First of all, am I mistaken in thinking this series could solve my issue ? If not, could you tell me on which branch (or which tag) you based your work ? I'm asking this because I tried to apply your patches on top of the master branch (a few days ago), and after fixing some conflict I got a segfault (sorry, I don't have the backtrace anymore :-(, but this was related to negative stride value which was implying faulty memory access). Yesterday I tried to rebase your patches on top of last master branch modifications, and it seems they've completely rework the gallium dri module architecture ([3]) and know I get an 'undefined symbol: dd_create_screen' error when mesa tries to load kms_swrast_dri.so. Sorry if my questions seem stupid to you, but I'm new in graphic related developments :-). Best Regards, Boris [1] https://lkml.org/lkml/2014/6/9/487 [2] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/66385 [3] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/78175 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Don't close the drm fd on failure
If XA fails to initialize with pipe_loader enabled, the pipe_loader's cleanup function will close the drm file descriptor. That's pretty bad because the file descriptor will probably be the X server driver's only connection to drm. Temporarily solve this by dup()'ing the file descriptor before handing it over to the pipe loader. This fixes freedesktop.org bugzilla bug #80645. Cc: "10.2" Signed-off-by: Thomas Hellstrom --- src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c index 6e4312e..268d56b 100644 --- a/src/gallium/state_trackers/xa/xa_tracker.c +++ b/src/gallium/state_trackers/xa/xa_tracker.c @@ -26,6 +26,7 @@ * Thomas Hellstrom */ +#include #include "xa_tracker.h" #include "xa_priv.h" #include "pipe/p_state.h" @@ -140,6 +141,7 @@ xa_tracker_create(int drm_fd) struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); enum xa_surface_type stype; unsigned int num_formats; +int loader_fd; if (!xa) return NULL; @@ -147,7 +149,10 @@ xa_tracker_create(int drm_fd) #if GALLIUM_STATIC_TARGETS xa->screen = dd_create_screen(drm_fd); #else -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) +loader_fd = dup(drm_fd); +if (loader_fd == -1) +return NULL; +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); #endif if (!xa->screen) -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 10:48:26 +0200 Boris BREZILLON wrote: > Hello Giovanni, > > I have recently been working on a DRM/KMS driver which does not support > OpenGL rendering (it only provides plane composition functionalities): > [1]. > > If I understand correctly you patch series might solve some of the > issues I am facing. > > I'm trying to get wayland working with HW cursor and several planes, > the problem is that it depends on GBM to provides drm plane and drm > cursor support. Which compositor? All the dependencies are in the compositors, not Wayland per se. If it is Weston, have you tried --use-pixman to avoid EGL altogether? I see Weston still tries to use GBM for cursor fbs, while primary fbs are dumb buffers, but then again, I'm not sure if cursors are supposed to support dumb buffers. Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Thanks, pq > I tried to get EGL working with my DRM device and it always ask for an > atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this > point). > > First of all, am I mistaken in thinking this series could solve my > issue ? > > If not, could you tell me on which branch (or which tag) you based > your work ? > > I'm asking this because I tried to apply your patches on top of the > master branch (a few days ago), and after fixing some conflict I got a > segfault (sorry, I don't have the backtrace anymore :-(, but this was > related to negative stride value which was implying faulty memory > access). > > Yesterday I tried to rebase your patches on top of last master branch > modifications, and it seems they've completely rework the gallium dri > module architecture ([3]) and know I get an 'undefined symbol: > dd_create_screen' error when mesa tries to load kms_swrast_dri.so. > > Sorry if my questions seem stupid to you, but I'm new in graphic > related developments :-). > > Best Regards, > > Boris > > > [1] https://lkml.org/lkml/2014/6/9/487 > [2] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/66385 > [3] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/78175 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Don't close the drm fd on failure v2
If XA fails to initialize with pipe_loader enabled, the pipe_loader's cleanup function will close the drm file descriptor. That's pretty bad because the file descriptor will probably be the X server driver's only connection to drm. Temporarily solve this by dup()'ing the file descriptor before handing it over to the pipe loader. This fixes freedesktop.org bugzilla bug #80645. v2: Fix CC addresses. Cc: "10.2" Signed-off-by: Thomas Hellstrom --- src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c index 6e4312e..268d56b 100644 --- a/src/gallium/state_trackers/xa/xa_tracker.c +++ b/src/gallium/state_trackers/xa/xa_tracker.c @@ -26,6 +26,7 @@ * Thomas Hellstrom */ +#include #include "xa_tracker.h" #include "xa_priv.h" #include "pipe/p_state.h" @@ -140,6 +141,7 @@ xa_tracker_create(int drm_fd) struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); enum xa_surface_type stype; unsigned int num_formats; +int loader_fd; if (!xa) return NULL; @@ -147,7 +149,10 @@ xa_tracker_create(int drm_fd) #if GALLIUM_STATIC_TARGETS xa->screen = dd_create_screen(drm_fd); #else -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) +loader_fd = dup(drm_fd); +if (loader_fd == -1) +return NULL; +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); #endif if (!xa->screen) -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/5] mesa/main: add ARB_clear_texture entrypoints
Ilia Mirkin writes: > I believe what this is saying is akin to "Danger! There is a hole from > 145 to 146". Since ARB_clear_texture is 145, the hole is now just 146 > (ARB_enhanced_layouts)... Whereas your comments indicate the numbers > of the actually-listed extensions. > > Note that I don't really understand what the point of extension > numbers is in the first place, or why it's important to indicate where > the holes are or what the extension numbers are. But I do think you're > changing the intent of the comment here. Ah yes, I think I misunderstood the intent of the comments. I will change it to be like this: > --- a/src/mapi/glapi/gen/gl_API.xml > +++ b/src/mapi/glapi/gen/gl_API.xml > @@ -8358,7 +8358,9 @@ > > > > - > + xmlns:xi="http://www.w3.org/2001/XIn> clude"/> > + > + > > xmlns:xi="http://www.w3.org/2001/XInclude"/> I only made the changes in the first place because your original patch had started conflicting since the GL_ARB_multi_bind extension was added. Sorry about messing it up. Yes, I'm not sure what the point of those comments are. They are bit messed up with extension number 128 as well so I think I'm not the only one struggling with them. Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xa: Don't close the drm fd on failure v2
- Original Message - > If XA fails to initialize with pipe_loader enabled, the pipe_loader's > cleanup function will close the drm file descriptor. That's pretty bad > because the file descriptor will probably be the X server driver's only > connection to drm. Temporarily solve this by dup()'ing the file descriptor > before handing it over to the pipe loader. > > This fixes freedesktop.org bugzilla bug #80645. > > v2: Fix CC addresses. > > Cc: "10.2" > Signed-off-by: Thomas Hellstrom > --- > src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Reviewed-by: Jakob Bornecrantz Cheers, Jakob. > > diff --git a/src/gallium/state_trackers/xa/xa_tracker.c > b/src/gallium/state_trackers/xa/xa_tracker.c > index 6e4312e..268d56b 100644 > --- a/src/gallium/state_trackers/xa/xa_tracker.c > +++ b/src/gallium/state_trackers/xa/xa_tracker.c > @@ -26,6 +26,7 @@ > * Thomas Hellstrom > */ > > +#include > #include "xa_tracker.h" > #include "xa_priv.h" > #include "pipe/p_state.h" > @@ -140,6 +141,7 @@ xa_tracker_create(int drm_fd) > struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); > enum xa_surface_type stype; > unsigned int num_formats; > +int loader_fd; > > if (!xa) > return NULL; > @@ -147,7 +149,10 @@ xa_tracker_create(int drm_fd) > #if GALLIUM_STATIC_TARGETS > xa->screen = dd_create_screen(drm_fd); > #else > -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) > +loader_fd = dup(drm_fd); > +if (loader_fd == -1) > +return NULL; > +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) > xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); > #endif > if (!xa->screen) > -- > 2.0.0 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 11:14:48 +0200 Giovanni Campagna wrote: > 2014-07-03 10:48 GMT+02:00 Boris BREZILLON > : > > Hello Giovanni, > > > > I have recently been working on a DRM/KMS driver which does not support > > OpenGL rendering (it only provides plane composition functionalities): > > [1]. > > > > If I understand correctly you patch series might solve some of the > > issues I am facing. > > It might get your working EGL, but it's not a complete solution, > because buffer management is limited to linear CPU-addressable "dumb" > buffers, which is probably not the most efficient choice (altough how > much slower it gets depends on the driver and on the HWl). I'm only providing DUMB ioctls (through the CMA GEM implementation), so it should be enough for me, isn't it. > > > I'm trying to get wayland working with HW cursor and several planes, > > the problem is that it depends on GBM to provides drm plane and drm > > cursor support. > > > > I tried to get EGL working with my DRM device and it always ask for an > > atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this > > point). > > > > First of all, am I mistaken in thinking this series could solve my > > issue ? > > Indeed, using my patch stack (patches 2 and 3) you will have a working > GBM device that will allocate GPU memory using the "dumb" interface. > If your driver is then able to upload this buffers to the plane HW (or > directly capable of allocating in GPU memory), that may be good enough > for you. > OTOH, this will not provide the wayland clients with the ability to > render directly to the plane buffers, because the "dumb" interface > does not provide global names that can be shared between processes, > therefore clients will have to render into a shared memory location, > that then the wayland compositor (weston, I assume) will have to > memcpy into a GBM allocated buffer. Indeed, I'm using weston (just forgot to mention it). > If you want to avoid that, you will need to design an ioctl interface > for your driver to allocate buffers, then write a "winsys" for the > userspace side that uses those ioctls (directly or through libdrm) - > first it allocates the buffer with your driver specific ioctl and then > calls GEM_FLINK to get the global name, which can be passed to weston > and in there to gbm_bo_import(). > If your HW is uncapable of GL rendering (and thus you want to use SW > rendering always) is quite likely that your driver will not be that > different from > dri_kms_swrast, except that will be able to share buffers (patch 3) > using GEM names. Okay, thanks for these enlightenment. I'll try to get the dri_kms_swrast first and then see if I need performance improvements ;-). > > > If not, could you tell me on which branch (or which tag) you based > > your work ? > > > > I'm asking this because I tried to apply your patches on top of the > > master branch (a few days ago), and after fixing some conflict I got a > > segfault (sorry, I don't have the backtrace anymore :-(, but this was > > related to negative stride value which was implying faulty memory > > access). > > The patches were made against an old version of mesa, and the build > system was updated meanwhile. Emil said he will rebase them, and that > will happen in a couple days. You should just wait until they land. Perfect! Emil, could you add me in Cc of this future submission ? Thanks for taking the time to answer to my questions. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen wrote: > On Thu, 3 Jul 2014 10:48:26 +0200 > Boris BREZILLON wrote: > > > Hello Giovanni, > > > > I have recently been working on a DRM/KMS driver which does not support > > OpenGL rendering (it only provides plane composition functionalities): > > [1]. > > > > If I understand correctly you patch series might solve some of the > > issues I am facing. > > > > I'm trying to get wayland working with HW cursor and several planes, > > the problem is that it depends on GBM to provides drm plane and drm > > cursor support. > > Which compositor? All the dependencies are in the compositors, not > Wayland per se. Sorry, I meant weston not wayland. > > If it is Weston, have you tried --use-pixman to avoid EGL altogether? > I see Weston still tries to use GBM for cursor fbs, while primary fbs > are dumb buffers, but then again, I'm not sure if cursors are supposed > to support dumb buffers. Yes weston works fine with --use-pixman, but then I can't use HW cursor and drm overlay planes (because it requires gbm). > > Weston's overlay planes code however totally depends on EGL to provide > hw-capable buffers from clients. A software renderer support in EGL-DRM > won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Another important XA patch
Hi, Carl, Patch st/xa: Don't close the drm fd on failure v2 causes some conflicts when backported to 10.2. Let me know if you need help resolving them, or if you want me to push a backported version to 10.2. Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] r600g: allow vs to write to gl_ViewportIndex
Reviewed-by: Marek Olšák
Marek
On Wed, Jul 2, 2014 at 10:30 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> Tested-by: Tobias Droste
> ---
>
> In addition to the existing ARB_fragment_layer_viewport piglits passing and
> the new AMD_vertex_shader_viewport_index piglit that is on the list passing,
> Tobias did a regression comparison to an earlier run and found no regressions.
>
> src/gallium/drivers/r600/r600_shader.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index 3767e5f..448ca80 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -2042,6 +2042,23 @@ static int r600_shader_from_tgsi(struct r600_context
> *rctx,
> output[j].type =
> V_SQ_CF_ALLOC_EXPORT_WORD0_SQ_EXPORT_POS;
> pos_emitted = true;
> break;
> + case TGSI_SEMANTIC_VIEWPORT_INDEX:
> + /* spi_sid is 0 for outputs that are
> +* not consumed by PS */
> + if (shader->output[i].spi_sid) {
> + output[j].array_base =
> next_param_base++;
> + output[j].type =
> V_SQ_CF_ALLOC_EXPORT_WORD0_SQ_EXPORT_PARAM;
> + j++;
> + memcpy(&output[j],
> &output[j-1], sizeof(struct r600_bytecode_output));
> + }
> + output[j].array_base = 61;
> + output[j].swizzle_x = 7;
> + output[j].swizzle_y = 7;
> + output[j].swizzle_z = 7;
> + output[j].swizzle_w = 0;
> + output[j].type =
> V_SQ_CF_ALLOC_EXPORT_WORD0_SQ_EXPORT_POS;
> + pos_emitted = true;
> + break;
> case TGSI_SEMANTIC_CLIPVERTEX:
> j--;
> break;
> --
> 1.8.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] mesa/st: enable AMD_vertex_shader_viewport_index
Reviewed-by: Marek Olšák Renaming the cap to include "VIEWPORT" would not be a bad idea. Marek On Wed, Jul 2, 2014 at 10:30 PM, Ilia Mirkin wrote: > The assumption is that any driver capable of emitting layer from the > vertex shader and supporting viewports should be able to also handle > emitting viewport index from the vertex shader. > > Signed-off-by: Ilia Mirkin > Tested-by: Tobias Droste > --- > docs/relnotes/10.3.html| 2 +- > src/mesa/state_tracker/st_extensions.c | 2 ++ > src/mesa/state_tracker/st_program.c| 4 > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html > index 6090a92..2e718fc 100644 > --- a/docs/relnotes/10.3.html > +++ b/docs/relnotes/10.3.html > @@ -55,7 +55,7 @@ Note: some of the new features are only available with > certain drivers. > GL_ARB_viewport_array on nvc0 > GL_ARB_seamless_cubemap_per_texture on i965, llvmpipe, nvc0, r600, > radeonsi, softpipe > GL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600 > -GL_AMD_vertex_shader_viewport_index on i965/gen7+ > +GL_AMD_vertex_shader_viewport_index on i965/gen7+, r600 > > > > diff --git a/src/mesa/state_tracker/st_extensions.c > b/src/mesa/state_tracker/st_extensions.c > index 9824135..b8b3d50 100644 > --- a/src/mesa/state_tracker/st_extensions.c > +++ b/src/mesa/state_tracker/st_extensions.c > @@ -816,6 +816,8 @@ void st_init_extensions(struct st_context *st) > ctx->Const.ViewportBounds.Max = 16384.0; > ctx->Extensions.ARB_viewport_array = GL_TRUE; > ctx->Extensions.ARB_fragment_layer_viewport = GL_TRUE; > + if (ctx->Extensions.AMD_vertex_shader_layer) > +ctx->Extensions.AMD_vertex_shader_viewport_index = GL_TRUE; >} > } > if (ctx->Const.MaxProgramTextureGatherComponents > 0) > diff --git a/src/mesa/state_tracker/st_program.c > b/src/mesa/state_tracker/st_program.c > index 1df411c..3570557 100644 > --- a/src/mesa/state_tracker/st_program.c > +++ b/src/mesa/state_tracker/st_program.c > @@ -262,6 +262,10 @@ st_prepare_vertex_program(struct gl_context *ctx, > stvp->output_semantic_name[slot] = TGSI_SEMANTIC_LAYER; > stvp->output_semantic_index[slot] = 0; > break; > + case VARYING_SLOT_VIEWPORT: > +stvp->output_semantic_name[slot] = TGSI_SEMANTIC_VIEWPORT_INDEX; > +stvp->output_semantic_index[slot] = 0; > +break; > > case VARYING_SLOT_TEX0: > case VARYING_SLOT_TEX1: > -- > 1.8.5.5 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON wrote: > On Thu, 3 Jul 2014 12:24:44 +0300 > Pekka Paalanen wrote: > > > On Thu, 3 Jul 2014 10:48:26 +0200 > > Boris BREZILLON wrote: > > > > > Hello Giovanni, > > > > > > I have recently been working on a DRM/KMS driver which does not support > > > OpenGL rendering (it only provides plane composition functionalities): > > > [1]. > > > > > > If I understand correctly you patch series might solve some of the > > > issues I am facing. > > > > > > I'm trying to get wayland working with HW cursor and several planes, > > > the problem is that it depends on GBM to provides drm plane and drm > > > cursor support. > > > > Which compositor? All the dependencies are in the compositors, not > > Wayland per se. > > Sorry, I meant weston not wayland. > > > > > If it is Weston, have you tried --use-pixman to avoid EGL altogether? > > I see Weston still tries to use GBM for cursor fbs, while primary fbs > > are dumb buffers, but then again, I'm not sure if cursors are supposed > > to support dumb buffers. > > Yes weston works fine with --use-pixman, but then I can't use HW cursor > and drm overlay planes (because it requires gbm). > > > > > Weston's overlay planes code however totally depends on EGL to provide > > hw-capable buffers from clients. A software renderer support in EGL-DRM > > won't help in that. > > Okay, if I understand correctly, this means I'll have to implement an > atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 13:49:06 +0300 Pekka Paalanen wrote: > On Thu, 3 Jul 2014 12:10:36 +0200 > Boris BREZILLON wrote: > > > On Thu, 3 Jul 2014 12:24:44 +0300 > > Pekka Paalanen wrote: > > > > > On Thu, 3 Jul 2014 10:48:26 +0200 > > > Boris BREZILLON wrote: > > > > > > > Hello Giovanni, > > > > > > > > I have recently been working on a DRM/KMS driver which does not support > > > > OpenGL rendering (it only provides plane composition functionalities): > > > > [1]. > > > > > > > > If I understand correctly you patch series might solve some of the > > > > issues I am facing. > > > > > > > > I'm trying to get wayland working with HW cursor and several planes, > > > > the problem is that it depends on GBM to provides drm plane and drm > > > > cursor support. > > > > > > Which compositor? All the dependencies are in the compositors, not > > > Wayland per se. > > > > Sorry, I meant weston not wayland. > > > > > > > > If it is Weston, have you tried --use-pixman to avoid EGL altogether? > > > I see Weston still tries to use GBM for cursor fbs, while primary fbs > > > are dumb buffers, but then again, I'm not sure if cursors are supposed > > > to support dumb buffers. > > > > Yes weston works fine with --use-pixman, but then I can't use HW cursor > > and drm overlay planes (because it requires gbm). > > > > > > > > Weston's overlay planes code however totally depends on EGL to provide > > > hw-capable buffers from clients. A software renderer support in EGL-DRM > > > won't help in that. > > > > Okay, if I understand correctly, this means I'll have to implement an > > atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? > > Well, uhh, I suppose... > > That means you need to get clients actually rendering into hw-capable > buffers, so that usually means having a GL(ES) rendering working on > EGL Wayland platform, too. > > Or, clients could use something like libva(?) to fill the buffers and > use Mesa's internal wl_drm protocol to pass those to the compositor. If > the compositor is able to initialize EGL_WL_bind_wayland_display > extension, then with Mesa, the clients will have wl_drm available. > Still probably requires working GLESv2 rendering for the EGL DRM/GBM > platform, because the pixman renderer cannot handle anything else than > wl_shm buffers. > > Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb > buffers, and put those into overlays (err, did dumb buffers support > going on overlays, or were they primary plane only?). But if you have > like less than 10 overlays in hw, that might be a net lose in > performance. I have, at most, 3 overlays (it depends on the HLCDC IP version), so this might be an acceptable solution. ITOH, I'd like to keep the implementation as clean as possible in order to be able to base future work on offical weston versions (and tell me if I'm wrong, but I'm not sure the proposed solution can ever make it to the official weston version). > > Or, you might go wild and have a hack on my hacky zlinux_dmabuf support > in weston: > http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP > It is missing pixman-renderer integration, and the test client is > intel-only, but if you hack around those, you can have clients filling > dmabufs, sending those to Weston, and Weston using GBM to import them > to put them on overlays via DRM - unless the scenegraph forces them to > go through pixman-renderer in which case you are in a slight pickle. > That sounds interesting! I'll take a closer look at it. > Warning: that weston branch may get rewritten or deleted without notice. > > I guess the take-away from this is that DRM overlay planes have not > really been considered for use with server nor client software rendering > in Weston. Yes, I kinda realize that know. My main goal here is to provide a video player demo application where the primary plane (or an overlay plane) is used to display video player controls (play, pause, ...) and another plane is used to display video content (using gstreamer or any other alternative). This needs to be done using overlays in order to get acceptable performances (avoid software rendering for plane composition), and thus should use drm overlay planes. I thought about developing or using an existing Qt application, but AFAIU, the problem remains the same with Qt DRM/KMS backend: it depends on EGL/GBM. Please let me know if you have any other ideas. Thanks. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] i965: in set_read_rb_tex_image() check _mesa_meta_bind_rb_as_tex_image() did succeed
On Thu, Jul 03, 2014 at 11:13:11AM +0300, Juha-Pekka Heikkila wrote:
> Check if _mesa_meta_bind_rb_as_tex_image() did give the texture.
> If no texture was given there is already either
> GL_INVALID_VALUE or GL_OUT_OF_MEMORY error set in context.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/common/meta_blit.c | 10 +-
> src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 14 ++
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c
> b/src/mesa/drivers/common/meta_blit.c
> index bbf0c3c..1fd4d1b 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -615,13 +615,21 @@ _mesa_meta_bind_rb_as_tex_image(struct gl_context *ctx,
> GLenum *target)
> {
> struct gl_texture_image *texImage;
> + GLuint tempTex;
>
> if (rb->NumSamples > 1)
>*target = GL_TEXTURE_2D_MULTISAMPLE;
> else
>*target = GL_TEXTURE_2D;
>
> - _mesa_GenTextures(1, tex);
> + tempTex = 0;
> + _mesa_GenTextures(1, &tempTex);
> + if (tempTex == 0) {
> + return false;
I think more often "{}" are dropped for single line blocks. In all the
contexts touched in this patch they are and hence I would drop them for
consistency.
> + }
> +
> + *tex = tempTex;
> +
> _mesa_BindTexture(*target, *tex);
> *texObj = _mesa_lookup_texture(ctx, *tex);
> texImage = _mesa_get_tex_image(ctx, *texObj, *target, 0);
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
> b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
> index bdd642b..11ac92b 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
> +++ b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
> @@ -371,7 +371,7 @@ prepare_vertex_data(void)
> _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
> }
>
> -static void
> +static bool
> set_read_rb_tex_image(struct gl_context *ctx, struct fb_tex_blit_state *blit,
>GLenum *target)
> {
> @@ -387,8 +387,10 @@ set_read_rb_tex_image(struct gl_context *ctx, struct
> fb_tex_blit_state *blit,
>*target = tex_obj->Target;
>level = att->TextureLevel;
> } else {
> - _mesa_meta_bind_rb_as_tex_image(ctx, rb, &blit->tempTex, &tex_obj,
> - target);
> + if (!_mesa_meta_bind_rb_as_tex_image(ctx, rb, &blit->tempTex, &tex_obj,
> + target)) {
> + return false;
> + }
> }
>
> blit->baseLevelSave = tex_obj->BaseLevel;
> @@ -396,6 +398,7 @@ set_read_rb_tex_image(struct gl_context *ctx, struct
> fb_tex_blit_state *blit,
> blit->stencilSamplingSave = tex_obj->StencilSampling;
> blit->sampler = _mesa_meta_setup_sampler(ctx, tex_obj, *target,
> GL_NEAREST, level);
> + return true;
> }
>
> static void
> @@ -424,7 +427,9 @@ brw_meta_stencil_blit(struct brw_context *brw,
> _mesa_DrawBuffer(GL_COLOR_ATTACHMENT0);
> ctx->DrawBuffer->_Status = GL_FRAMEBUFFER_COMPLETE;
>
> - set_read_rb_tex_image(ctx, &blit, &target);
> + if (!set_read_rb_tex_image(ctx, &blit, &target)) {
> + goto error;
> + }
>
> _mesa_TexParameteri(target, GL_DEPTH_STENCIL_TEXTURE_MODE,
> GL_STENCIL_INDEX);
> @@ -446,6 +451,7 @@ brw_meta_stencil_blit(struct brw_context *brw,
> _mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
>
> _mesa_meta_fb_tex_blit_end(ctx, target, &blit);
> +error:;
Extra ; crept in, and I would include _mesa_meta_fb_tex_blit_end() in the
error path as _mesa_meta_fb_tex_blit_begin() has been called. Currently
there is no difference as nothing is really altered by the time the error
is detected. But that may change in the future and we might forget to update
the error path.
With these changes:
Reviewed-by: Topi Pohjolainen
> _mesa_meta_end(ctx);
>
> _mesa_DeleteRenderbuffers(1, &rbo);
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 14:15:34 +0200 Boris BREZILLON wrote: > On Thu, 3 Jul 2014 13:49:06 +0300 > Pekka Paalanen wrote: > > > On Thu, 3 Jul 2014 12:10:36 +0200 > > Boris BREZILLON wrote: > > > > > On Thu, 3 Jul 2014 12:24:44 +0300 > > > Pekka Paalanen wrote: > > > > Weston's overlay planes code however totally depends on EGL to provide > > > > hw-capable buffers from clients. A software renderer support in EGL-DRM > > > > won't help in that. > > > > > > Okay, if I understand correctly, this means I'll have to implement an > > > atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? > > > > Well, uhh, I suppose... > > > > That means you need to get clients actually rendering into hw-capable > > buffers, so that usually means having a GL(ES) rendering working on > > EGL Wayland platform, too. > > > > Or, clients could use something like libva(?) to fill the buffers and > > use Mesa's internal wl_drm protocol to pass those to the compositor. If > > the compositor is able to initialize EGL_WL_bind_wayland_display > > extension, then with Mesa, the clients will have wl_drm available. > > Still probably requires working GLESv2 rendering for the EGL DRM/GBM > > platform, because the pixman renderer cannot handle anything else than > > wl_shm buffers. > > > > Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb > > buffers, and put those into overlays (err, did dumb buffers support > > going on overlays, or were they primary plane only?). But if you have > > like less than 10 overlays in hw, that might be a net lose in > > performance. > > I have, at most, 3 overlays (it depends on the HLCDC IP version), so > this might be an acceptable solution. > > ITOH, I'd like to keep the implementation as clean as possible in order > to be able to base future work on offical weston versions (and tell me > if I'm wrong, but I'm not sure the proposed solution can ever make it to > the official weston version). > > > > > Or, you might go wild and have a hack on my hacky zlinux_dmabuf support > > in weston: > > http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP > > It is missing pixman-renderer integration, and the test client is > > intel-only, but if you hack around those, you can have clients filling > > dmabufs, sending those to Weston, and Weston using GBM to import them > > to put them on overlays via DRM - unless the scenegraph forces them to > > go through pixman-renderer in which case you are in a slight pickle. > > > > That sounds interesting! > I'll take a closer look at it. Note, that the protocol there does not address the problem of compatibility at all, and the implementation does not even advertise any pixel formats. It is all based on luck and clairvoyance, that the client just happens to create exactly the right kind of dmabufs that the compositor can use. If you fail that, the client gets kicked or you get a mess on the screen. Obviously not upstreamable material. ;-) > > Warning: that weston branch may get rewritten or deleted without notice. > > > > I guess the take-away from this is that DRM overlay planes have not > > really been considered for use with server nor client software rendering > > in Weston. > > Yes, I kinda realize that know. > > My main goal here is to provide a video player demo application where > the primary plane (or an overlay plane) is used to display video player > controls (play, pause, ...) and another plane is used to display video > content (using gstreamer or any other alternative). > > This needs to be done using overlays in order to get acceptable > performances (avoid software rendering for plane composition), and > thus should use drm overlay planes. Oh, a video player! How do you get the video frames? Do you have hardware decoding? Can you perhaps decode straight into dmabufs? If yes, then you could use zlinux_dmabuf to throw those video frames to Weston zero-copy. Then the tricky part is to make Weston cope with those video frame buffers, as if they even attempt to go through the pixman-renderer, Weston will... hm, not sure what it does, but it won't work. So you have to somehow guarantee, that the surface which those buffers are targeting will *always* be assigned to an overlay. That may be a fair amount of hacking. Good luck! :-) Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 15:46:14 +0300 Pekka Paalanen wrote: > On Thu, 3 Jul 2014 14:15:34 +0200 > Boris BREZILLON wrote: > > > On Thu, 3 Jul 2014 13:49:06 +0300 > > Pekka Paalanen wrote: > > > > > On Thu, 3 Jul 2014 12:10:36 +0200 > > > Boris BREZILLON wrote: > > > > > > > On Thu, 3 Jul 2014 12:24:44 +0300 > > > > Pekka Paalanen wrote: > > > > > Weston's overlay planes code however totally depends on EGL to provide > > > > > hw-capable buffers from clients. A software renderer support in > > > > > EGL-DRM > > > > > won't help in that. > > > > > > > > Okay, if I understand correctly, this means I'll have to implement an > > > > atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? > > > > > > Well, uhh, I suppose... > > > > > > That means you need to get clients actually rendering into hw-capable > > > buffers, so that usually means having a GL(ES) rendering working on > > > EGL Wayland platform, too. > > > > > > Or, clients could use something like libva(?) to fill the buffers and > > > use Mesa's internal wl_drm protocol to pass those to the compositor. If > > > the compositor is able to initialize EGL_WL_bind_wayland_display > > > extension, then with Mesa, the clients will have wl_drm available. > > > Still probably requires working GLESv2 rendering for the EGL DRM/GBM > > > platform, because the pixman renderer cannot handle anything else than > > > wl_shm buffers. > > > > > > Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb > > > buffers, and put those into overlays (err, did dumb buffers support > > > going on overlays, or were they primary plane only?). But if you have > > > like less than 10 overlays in hw, that might be a net lose in > > > performance. > > > > I have, at most, 3 overlays (it depends on the HLCDC IP version), so > > this might be an acceptable solution. > > > > ITOH, I'd like to keep the implementation as clean as possible in order > > to be able to base future work on offical weston versions (and tell me > > if I'm wrong, but I'm not sure the proposed solution can ever make it to > > the official weston version). > > > > > > > > Or, you might go wild and have a hack on my hacky zlinux_dmabuf support > > > in weston: > > > http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP > > > It is missing pixman-renderer integration, and the test client is > > > intel-only, but if you hack around those, you can have clients filling > > > dmabufs, sending those to Weston, and Weston using GBM to import them > > > to put them on overlays via DRM - unless the scenegraph forces them to > > > go through pixman-renderer in which case you are in a slight pickle. > > > > > > > That sounds interesting! > > I'll take a closer look at it. > > Note, that the protocol there does not address the problem of > compatibility at all, and the implementation does not even advertise any > pixel formats. It is all based on luck and clairvoyance, that the client > just happens to create exactly the right kind of dmabufs that the > compositor can use. If you fail that, the client gets kicked or you > get a mess on the screen. Obviously not upstreamable material. ;-) > > > > Warning: that weston branch may get rewritten or deleted without notice. > > > > > > I guess the take-away from this is that DRM overlay planes have not > > > really been considered for use with server nor client software rendering > > > in Weston. > > > > Yes, I kinda realize that know. > > > > My main goal here is to provide a video player demo application where > > the primary plane (or an overlay plane) is used to display video player > > controls (play, pause, ...) and another plane is used to display video > > content (using gstreamer or any other alternative). > > > > This needs to be done using overlays in order to get acceptable > > performances (avoid software rendering for plane composition), and > > thus should use drm overlay planes. > > Oh, a video player! How do you get the video frames? Do you have > hardware decoding? Can you perhaps decode straight into dmabufs? If > yes, then you could use zlinux_dmabuf to throw those video frames to > Weston zero-copy. Then the tricky part is to make Weston cope with those > video frame buffers, as if they even attempt to go through the > pixman-renderer, Weston will... hm, not sure what it does, but it won't > work. So you have to somehow guarantee, that the surface which those > buffers are targeting will *always* be assigned to an overlay. Some SoCs have an HW decoder and yes I had dmabuf in mind to provide zero copy from video decoder to DRM device ;-). But I'm not even sure this video decoder is supported in mainline and I'd like to get software decoding working first :-). > > That may be a fair amount of hacking. Good luck! :-) Yes that's what I'm realizing now. I thought the kernel driver would be the most complicated part, but now that I'm working on user space support I'd say developing the driver was quite easy :
Re: [Mesa-dev] [PATCH 7/9] i965: Avoid null access in fs_generator::generate_code()
On Thu, Jul 03, 2014 at 11:13:17AM +0300, Juha-Pekka Heikkila wrote:
> Avoid null access while printing debug infos. On the same go
> change local variable name to avoid confusion because there
> already is class member with same name.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index 52e88d4..6e201d1 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -1783,9 +1783,13 @@ fs_generator::generate_code(exec_list *instructions)
>dispatch_width, before_size / 16, before_size, after_size,
>100.0f * (before_size - after_size) / before_size);
>
I had to check the context a bit, just before there is:
if (prog) {
...
} else if (fp) {
...
} else {
fprintf(stderr, "Native code for blorp program (SIMD%d dispatch):\n",
dispatch_width);
}
As I remembered you are now addressing the special case of blorp programs.
After your change we can't dump them anymore (using env setting
INTEL_DEBUG=blorp).
> - const struct gl_program *prog = fp ? &fp->Base : NULL;
> + const struct gl_program *fp_prog = fp ? &fp->Base : NULL;
> +
> + if (fp_prog) {
> + dump_assembly(p->store, annotation.ann_count, annotation.ann, brw,
> + fp_prog);
> + }
>
> - dump_assembly(p->store, annotation.ann_count, annotation.ann, brw,
> prog);
>ralloc_free(annotation.ann);
> }
> }
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix duplicated layout qualifier detection for GS
On Wed, 2014-07-02 at 12:47 -0700, Jordan Justen wrote: > Reviewed-by: Jordan Justen > I don't have commit access to the repository. Would you mind pushing this patch to master? Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glxinfo: remove query of GL_MAX_VERTEX_ATTRIB_STRIDE
This is not part of the GL_ARB_vertex_attrib_binding extension.
It's part of OpenGL 4.4.
Fixes compilation failure if glext.h doesn't have the GL 4.4 #defines.
---
src/xdemos/glinfo_common.c |1 -
1 file changed, 1 deletion(-)
diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
index 1326a86..4360e53 100644
--- a/src/xdemos/glinfo_common.c
+++ b/src/xdemos/glinfo_common.c
@@ -563,7 +563,6 @@ print_limits(const char *extensions, const char *oglstring,
int version,
#endif
#if defined (GL_ARB_vertex_attrib_binding)
{ 1, GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET,
"GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET", "GL_ARB_vertex_attrib_binding" },
- { 1, GL_MAX_VERTEX_ATTRIB_STRIDE, "GL_MAX_VERTEX_ATTRIB_STRIDE",
"GL_ARB_vertex_attrib_binding" },
{ 1, GL_MAX_VERTEX_ATTRIB_BINDINGS, "GL_MAX_VERTEX_ATTRIB_BINDINGS",
"GL_ARB_vertex_attrib_binding" },
#endif
{ 0, (GLenum) 0, NULL, NULL }
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glxinfo: add query for OpenGL 4.4 GL_MAX_VERTEX_ATTRIB_STRIDE
And add support for qualifying a limit query with an OpenGL version
instead of an extension string.
---
src/xdemos/glinfo_common.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
index 4360e53..248b937 100644
--- a/src/xdemos/glinfo_common.c
+++ b/src/xdemos/glinfo_common.c
@@ -20,6 +20,7 @@
*/
#include
+#include
#include
#include
#include
@@ -331,6 +332,29 @@ extension_supported(const char *ext, const char
*extensionsList)
}
+/**
+ * Is verNum >= verString?
+ * \param verString such as "2.1", "3.0", etc.
+ * \param verNum such as 20, 21, 30, 31, 32, etc.
+ */
+static GLboolean
+version_supported(const char *verString, int verNum)
+{
+ int v;
+
+ if (!verString ||
+ !isdigit(verString[0]) ||
+ verString[1] != '.' ||
+ !isdigit(verString[2])) {
+ return GL_FALSE;
+ }
+
+ v = (verString[0] - '0') * 10 + (verString[2] - '0');
+
+ return verNum >= v;
+}
+
+
struct token_name
{
GLenum token;
@@ -486,7 +510,7 @@ print_limits(const char *extensions, const char *oglstring,
int version,
GLuint count;
GLenum token;
const char *name;
- const char *extension;
+ const char *extension; /* NULL or GL extension name or version string */
};
static const struct token_name limits[] = {
{ 1, GL_MAX_ATTRIB_STACK_DEPTH, "GL_MAX_ATTRIB_STACK_DEPTH", NULL },
@@ -565,6 +589,9 @@ print_limits(const char *extensions, const char *oglstring,
int version,
{ 1, GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET,
"GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET", "GL_ARB_vertex_attrib_binding" },
{ 1, GL_MAX_VERTEX_ATTRIB_BINDINGS, "GL_MAX_VERTEX_ATTRIB_BINDINGS",
"GL_ARB_vertex_attrib_binding" },
#endif
+#if defined(GL_VERSION_4_4)
+ { 1, GL_MAX_VERTEX_ATTRIB_STRIDE, "GL_MAX_VERTEX_ATTRIB_STRIDE", "4.4" },
+#endif
{ 0, (GLenum) 0, NULL, NULL }
};
GLint i, max[2];
@@ -572,6 +599,7 @@ print_limits(const char *extensions, const char *oglstring,
int version,
printf("%s limits:\n", oglstring);
for (i = 0; limits[i].count; i++) {
if (!limits[i].extension ||
+ version_supported(limits[i].extension, version) ||
extension_supported(limits[i].extension, extensions)) {
glGetIntegerv(limits[i].token, max);
if (glGetError() == GL_NO_ERROR) {
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] i965: Avoid null access in fs_generator::generate_code()
On 03.07.2014 16:26, Pohjolainen, Topi wrote:
> On Thu, Jul 03, 2014 at 11:13:17AM +0300, Juha-Pekka Heikkila wrote:
>> Avoid null access while printing debug infos. On the same go
>> change local variable name to avoid confusion because there
>> already is class member with same name.
>>
>> Signed-off-by: Juha-Pekka Heikkila
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> index 52e88d4..6e201d1 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> @@ -1783,9 +1783,13 @@ fs_generator::generate_code(exec_list *instructions)
>>dispatch_width, before_size / 16, before_size, after_size,
>>100.0f * (before_size - after_size) / before_size);
>>
>
> I had to check the context a bit, just before there is:
>
> if (prog) {
> ...
> } else if (fp) {
> ...
> } else {
> fprintf(stderr, "Native code for blorp program (SIMD%d dispatch):\n",
> dispatch_width);
> }
>
> As I remembered you are now addressing the special case of blorp programs.
> After your change we can't dump them anymore (using env setting
> INTEL_DEBUG=blorp).
We should go to dump_assembly even if prog is NULL? When looking at
dump_assembly I see prog being used only at intel_asm_printer around
line 55 where it goes like:
if (last_annotation_ir != annotation[i].ir) {
last_annotation_ir = annotation[i].ir;
if (last_annotation_ir) {
fprintf(stderr, " ");
if (!prog->Instructions)
fprint_ir(stderr, annotation[i].ir);
else {
const struct prog_instruction *pi =
(const struct prog_instruction *)annotation[i].ir;
fprintf(stderr, "%d: ",
(int)(pi - prog->Instructions));
_mesa_fprint_instruction_opt(stderr,
pi,
0, PROG_PRINT_DEBUG, NULL);
}
fprintf(stderr, "\n");
}
Line 55 is that "if (!prog->Instructions)".
"if (last_annotation_ir != annotation[i].ir)" never matches when prog is
also NULL?
>> - const struct gl_program *prog = fp ? &fp->Base : NULL;
>> + const struct gl_program *fp_prog = fp ? &fp->Base : NULL;
>> +
>> + if (fp_prog) {
>> + dump_assembly(p->store, annotation.ann_count, annotation.ann, brw,
>> + fp_prog);
>> + }
>>
>> - dump_assembly(p->store, annotation.ann_count, annotation.ann, brw,
>> prog);
>>ralloc_free(annotation.ann);
>> }
>> }
>> --
>> 1.8.1.2
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
> >> Tom Stellard writes:
> >>
> >> > v2:
> >> > - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
> >> > - Only define cl_khr_fp64 if the extension is supported.
> >> > - Remove trailing space from extension string.
> >> > - Rename device query function from cl_khr_fp86() to has_doubles().
> >> > ---
> >> > src/gallium/state_trackers/clover/api/device.cpp | 6 +++---
> >> > src/gallium/state_trackers/clover/core/device.cpp | 6 ++
> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
> >> > b/src/gallium/state_trackers/clover/api/device.cpp
> >> > index 7006702..1176668 100644
> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
> >> > param,
> >> >break;
> >> >
> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
> >> > - buf.as_scalar() = 2;
> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >break;
> >> >
> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
> >> > param,
> >> >break;
> >> >
> >> > case CL_DEVICE_EXTENSIONS:
> >> > - buf.as_string() = "";
> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
> >> >break;
> >> >
> >> > case CL_DEVICE_PLATFORM:
> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
> >> > param,
> >> >break;
> >> >
> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
> >> > - buf.as_scalar() = 2;
> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >break;
> >> >
> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
> >> > b/src/gallium/state_trackers/clover/core/device.cpp
> >> > index bc6b761..6bf33e0 100644
> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
> >> > return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
> >> > }
> >> >
> >> > +bool
> >> > +device::has_doubles() const {
> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
> >> > + PIPE_SHADER_CAP_DOUBLES);
> >> > +}
> >> > +
> >> > std::vector
> >> > device::max_block_size() const {
> >> > auto v = get_compute_param(pipe,
> >> > PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
> >> > diff --git a/src/gallium/state_trackers/clover/core/device.hpp
> >> > b/src/gallium/state_trackers/clover/core/device.hpp
> >> > index 16831ab..025c648 100644
> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
> >> > @@ -66,6 +66,7 @@ namespace clover {
> >> >cl_device_fp_config single_fp_config() const;
> >> >cl_device_fp_config double_fp_config() const;
> >> >cl_device_fp_config half_fp_config() const;
> >> > + bool has_doubles() const;
> >> >
> >> >std::vector max_block_size() const;
> >> >std::string device_name() const;
> >> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp
> >> > b/src/gallium/state_trackers/clover/core/program.cpp
> >> > index e09c3aa..f65f321 100644
> >> > --- a/src/gallium/state_trackers/clover/core/program.cpp
> >> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
> >> > @@ -95,7 +95,10 @@ program::build_status(const device &dev) const {
> >> >
> >> > std::string
> >> > program::build_opts(const device &dev) const {
> >> > - return _opts.count(&dev) ? _opts.find(&dev)->second : "";
> >> > + std::string opts = _opts.count(&dev) ? _opts.find(&dev)->second : "";
> >> > + if (dev.has_doubles())
> >> > + opts.append(" -Dcl_khr_fp64");
> >> > + return opts;
> >>
> >> This define belongs in the target-specific part of libclc. With this
> >> hunk removed this patch is:
> >>
> >
> > The declarations for double functions in the libclc headers are wrapped in
> > this
> > macro, so we need to set it here in order to be able to use them from
> > clover.
> >
>
> This abuses the ::build_opts() accessor to that end, which is only
> supposed to return the compiler options that were specified by the user
> at build time, as required by the CL_PROGRAM_BUILD_OPTIONS build param.
>
You
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Wed, Jul 02, 2014 at 04:34:24PM -0500, Aaron Watry wrote:
> Previously, we were assuming that kernel metadata nodes only had 1 operand.
>
> Kernels which have attributes can have more than 1, e.g.:
> !0 = metadata !{void (i32 addrspace(1)*)* @testKernel, metadata !1}
> !1 = metadata !{metadata !"work_group_size_hint", i32 4, i32 1, i32 1}
>
> Attempting to get the kernel without the correct number of attributes led
> to memory corruption and luxrays crashing out.
>
> Fixes the cl/program/execute/attributes.cl piglit test.
>
Thanks for tracking this down.
Reviewed-by: Tom Stellard
> Signed-off-by: Aaron Watry
> CC: Tom Stellard
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
> ---
> src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
> b/src/gallium/drivers/radeon/radeon_llvm_util.c
> index 2ace91f..ec11559 100644
> --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
> +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
> @@ -100,13 +100,17 @@ LLVMModuleRef
> radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
> kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
> LLVMGetNamedMetadataOperands(mod, "opencl.kernels", kernel_metadata);
> for (i = 0; i < num_kernels; i++) {
> - LLVMValueRef kernel_signature, kernel_function;
> + LLVMValueRef kernel_signature, *kernel_function;
> + unsigned num_kernel_md_operands;
> if (i == index) {
> continue;
> }
> kernel_signature = kernel_metadata[i];
> - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
> - LLVMDeleteFunction(kernel_function);
> + num_kernel_md_operands =
> LLVMGetMDNodeNumOperands(kernel_signature);
> + kernel_function = MALLOC(num_kernel_md_operands * sizeof
> (LLVMValueRef));
> + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
> + LLVMDeleteFunction(*kernel_function);
> + FREE(kernel_function);
> }
> FREE(kernel_metadata);
> radeon_llvm_optimize(mod);
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/5] gallium: rename PIPE_CAP_TGSI_VS_LAYER to also have _VIEWPORT
Now that this cap is used to determine the availability of both, adjust
its name to reflect the new reality.
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/util/u_blitter.c | 2 +-
src/gallium/docs/source/screen.rst | 6 --
src/gallium/drivers/freedreno/freedreno_screen.c | 2 +-
src/gallium/drivers/i915/i915_screen.c | 2 +-
src/gallium/drivers/ilo/ilo_screen.c | 2 +-
src/gallium/drivers/llvmpipe/lp_screen.c | 2 +-
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 +-
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
src/gallium/drivers/r300/r300_screen.c | 2 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/softpipe/sp_screen.c | 2 +-
src/gallium/drivers/svga/svga_screen.c | 2 +-
src/gallium/include/pipe/p_defines.h | 2 +-
src/mesa/state_tracker/st_cb_clear.c | 2 +-
src/mesa/state_tracker/st_extensions.c | 2 +-
17 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 7b058fe..db0d1b8 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -325,7 +325,7 @@ struct blitter_context *util_blitter_create(struct
pipe_context *pipe)
}
if (pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_INSTANCEID) &&
- pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_VS_LAYER)) {
+ pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_VS_LAYER_VIEWPORT))
{
ctx->vs_layered = util_make_layered_clear_vertex_shader(pipe);
}
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 2ea0da8..ba583fe 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -174,8 +174,10 @@ The integer capabilities:
* ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
different sizes for fb color/zs attachments. This controls whether
ARB_framebuffer_object is provided.
-* ``PIPE_CAP_TGSI_VS_LAYER``: Whether TGSI_SEMANTIC_LAYER is supported
- as a vertex shader output.
+* ``PIPE_CAP_TGSI_VS_LAYER_VIEWPORT``: Whether ``TGSI_SEMANTIC_LAYER`` and
+ ``TGSI_SEMANTIC_VIEWPORT_INDEX`` are supported as vertex shader
+ outputs. Note that the viewport will only be used if multiple viewports are
+ exposed.
* ``PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES``: The maximum number of vertices
output by a single invocation of a geometry shader.
* ``PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS``: The maximum number of
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index ce3cf90..c574cb8 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -207,7 +207,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_USER_INDEX_BUFFERS:
case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
- case PIPE_CAP_TGSI_VS_LAYER:
+ case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_FAKE_SW_MSAA:
diff --git a/src/gallium/drivers/i915/i915_screen.c
b/src/gallium/drivers/i915/i915_screen.c
index 25432f2..86a7a67 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -230,7 +230,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap
cap)
case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
- case PIPE_CAP_TGSI_VS_LAYER:
+ case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_DRAW_INDIRECT:
return 0;
diff --git a/src/gallium/drivers/ilo/ilo_screen.c
b/src/gallium/drivers/ilo/ilo_screen.c
index 8f8e152..a7eaa1b 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -434,7 +434,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap
param)
return PIPE_ENDIAN_LITTLE;
case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES:
return true;
- case PIPE_CAP_TGSI_VS_LAYER:
+ case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 356fad7..3218eb6 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -240,7 +240,7 @@ llvmpipe_get_param(struct pipe_screen *scre
Re: [Mesa-dev] [PATCH 6/5] gallium: rename PIPE_CAP_TGSI_VS_LAYER to also have _VIEWPORT
Reviewed-by: Roland Scheidegger
Am 03.07.2014 17:17, schrieb Ilia Mirkin:
> Now that this cap is used to determine the availability of both, adjust
> its name to reflect the new reality.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/auxiliary/util/u_blitter.c | 2 +-
> src/gallium/docs/source/screen.rst | 6 --
> src/gallium/drivers/freedreno/freedreno_screen.c | 2 +-
> src/gallium/drivers/i915/i915_screen.c | 2 +-
> src/gallium/drivers/ilo/ilo_screen.c | 2 +-
> src/gallium/drivers/llvmpipe/lp_screen.c | 2 +-
> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 +-
> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
> src/gallium/drivers/r300/r300_screen.c | 2 +-
> src/gallium/drivers/r600/r600_pipe.c | 2 +-
> src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
> src/gallium/drivers/softpipe/sp_screen.c | 2 +-
> src/gallium/drivers/svga/svga_screen.c | 2 +-
> src/gallium/include/pipe/p_defines.h | 2 +-
> src/mesa/state_tracker/st_cb_clear.c | 2 +-
> src/mesa/state_tracker/st_extensions.c | 2 +-
> 17 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_blitter.c
> b/src/gallium/auxiliary/util/u_blitter.c
> index 7b058fe..db0d1b8 100644
> --- a/src/gallium/auxiliary/util/u_blitter.c
> +++ b/src/gallium/auxiliary/util/u_blitter.c
> @@ -325,7 +325,7 @@ struct blitter_context *util_blitter_create(struct
> pipe_context *pipe)
> }
>
> if (pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_INSTANCEID) &&
> - pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_VS_LAYER)) {
> + pipe->screen->get_param(pipe->screen,
> PIPE_CAP_TGSI_VS_LAYER_VIEWPORT)) {
>ctx->vs_layered = util_make_layered_clear_vertex_shader(pipe);
> }
>
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index 2ea0da8..ba583fe 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -174,8 +174,10 @@ The integer capabilities:
> * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
>different sizes for fb color/zs attachments. This controls whether
>ARB_framebuffer_object is provided.
> -* ``PIPE_CAP_TGSI_VS_LAYER``: Whether TGSI_SEMANTIC_LAYER is supported
> - as a vertex shader output.
> +* ``PIPE_CAP_TGSI_VS_LAYER_VIEWPORT``: Whether ``TGSI_SEMANTIC_LAYER`` and
> + ``TGSI_SEMANTIC_VIEWPORT_INDEX`` are supported as vertex shader
> + outputs. Note that the viewport will only be used if multiple viewports are
> + exposed.
> * ``PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES``: The maximum number of vertices
>output by a single invocation of a geometry shader.
> * ``PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS``: The maximum number of
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index ce3cf90..c574cb8 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -207,7 +207,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> case PIPE_CAP_USER_INDEX_BUFFERS:
> case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
> case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
> - case PIPE_CAP_TGSI_VS_LAYER:
> + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_FAKE_SW_MSAA:
> diff --git a/src/gallium/drivers/i915/i915_screen.c
> b/src/gallium/drivers/i915/i915_screen.c
> index 25432f2..86a7a67 100644
> --- a/src/gallium/drivers/i915/i915_screen.c
> +++ b/src/gallium/drivers/i915/i915_screen.c
> @@ -230,7 +230,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap
> cap)
> case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
> - case PIPE_CAP_TGSI_VS_LAYER:
> + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_DRAW_INDIRECT:
>return 0;
> diff --git a/src/gallium/drivers/ilo/ilo_screen.c
> b/src/gallium/drivers/ilo/ilo_screen.c
> index 8f8e152..a7eaa1b 100644
> --- a/src/gallium/drivers/ilo/ilo_screen.c
> +++ b/src/gallium/drivers/ilo/ilo_screen.c
> @@ -434,7 +434,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap
> param)
>return PIPE_ENDIAN_LITTLE;
> case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES:
>return true;
> - case PIPE_CAP_TGSI_VS_LAYER:
> + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> diff --git a/src/
Re: [Mesa-dev] [PATCH] gallium: pass in per-sample interpolation qualifier
Am 03.07.2014 03:19, schrieb Ilia Mirkin:
> On Wed, Jul 2, 2014 at 4:03 PM, Roland Scheidegger wrote:
>> Actually on second thought, because centroid and sample are mutually
>> exclusive (or more generally, the "Interpolate" member determines "how"
>> interpolation is done, whereas these two determine the "where")
>> something like this might be better:
>>
>> struct tgsi_declaration_interp
>> {
>>unsigned Interpolate : 4; /**< one of TGSI_INTERPOLATE_x */
>>unsigned Location: 2; /**< one of TGSI_INTERPOLATE_LOC_x */
>>unsigned CylindricalWrap:4; /**< TGSI_CYLINDRICAL_WRAP_x flags */
>>unsigned Padding : 22;
>> };
>>
>> TGSI_INTERPOLATE_LOC_CENTER 0
>> TGSI_INTERPOLATE_LOC_CENTROID 1
>> TGSI_INTERPOLATE_LOC_SAMPLE 2
>>
>> Or something like that. Not sure though...
>
> Yeah, that was the alternative I was mentioning of "combining" it with
> Centroid. Happy to do it either way. Obviously this would cause a lot
> more driver updates, but I don't mind -- I suspect the uses of
> Centroid are fairly few, probably 1-2 per driver.
>
> Let me know what you prefer.
I think this would be cleaner. But I could live with the other solution
if others prefer that. You'd just have to mention somewhere in the docs
that combination of sample/centroid is invalid (or otherwise say which
takes precedence though I don't think that would make sense).
Roland
> -ilia
>
>>
>> Roland
>>
>>
>>
>> Am 02.07.2014 19:04, schrieb Roland Scheidegger:
>>> I don't have much of an idea how the interaction with per sample shading
>>> should look like, but this looks alright to me.
>>>
>>> Roland
>>>
>>> Am 02.07.2014 03:55, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin
---
Not sure if this is the right approach or if I should combine it with
Centroid
more directly. More modifications will be required wrt per-sample shading
since we'll need to distinguish the min samples case where everything is
per-sample-interpolated vs this case where only some inputs are to be
sample-interpolated but the min samples would still be > 1. (Perhaps that
case
should be handled by instead manually annotating each input as
per-sample-interpolated and sticking the overall per-sample-shading into a
variant key. This is roughly what i965 does.)
But I thought I'd send this out to get some early feedback.
src/gallium/auxiliary/tgsi/tgsi_dump.c | 4
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 12 +---
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 7 ---
src/gallium/include/pipe/p_shader_tokens.h | 3 ++-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 +-
src/mesa/state_tracker/st_glsl_to_tgsi.h | 1 +
src/mesa/state_tracker/st_program.c| 5 +
7 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index 8e09bac..cce7858 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -353,6 +353,10 @@ iter_declaration(
TXT( ", CENTROID" );
}
+ if (decl->Interp.Sample) {
+ TXT( ", SAMPLE" );
+ }
+
if (decl->Interp.CylindricalWrap) {
TXT(", CYLWRAP_");
if (decl->Interp.CylindricalWrap & TGSI_CYLINDRICAL_WRAP_X) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index bd0a3f7..b21339e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -104,6 +104,7 @@ struct ureg_program
unsigned interp;
unsigned char cylindrical_wrap;
unsigned char centroid;
+ unsigned char sample;
} fs_input[UREG_MAX_INPUT];
unsigned nr_fs_inputs;
@@ -345,7 +346,8 @@ ureg_DECL_fs_input_cyl_centroid(struct ureg_program
*ureg,
unsigned semantic_index,
unsigned interp_mode,
unsigned cylindrical_wrap,
- unsigned centroid)
+ unsigned centroid,
+ unsigned sample)
{
unsigned i;
@@ -362,6 +364,7 @@ ureg_DECL_fs_input_cyl_centroid(struct ureg_program
*ureg,
ureg->fs_input[i].interp = interp_mode;
ureg->fs_input[i].cylindrical_wrap = cylindrical_wrap;
ureg->fs_input[i].centroid = centroid;
+ ureg->fs_input[i].sample = sample;
ureg->nr_fs_inputs++;
} else {
set_bad(ureg);
@@ -1288,7 +1291,8 @@ emit_decl_fs(struct ureg_program *ureg,
unsigned semantic_index,
unsigned interpolate,
unsigned cylindrical_wrap,
-
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Thu, Jul 3, 2014 at 9:56 AM, Tom Stellard wrote:
> On Wed, Jul 02, 2014 at 04:34:24PM -0500, Aaron Watry wrote:
>> Previously, we were assuming that kernel metadata nodes only had 1 operand.
>>
>> Kernels which have attributes can have more than 1, e.g.:
>> !0 = metadata !{void (i32 addrspace(1)*)* @testKernel, metadata !1}
>> !1 = metadata !{metadata !"work_group_size_hint", i32 4, i32 1, i32 1}
>>
>> Attempting to get the kernel without the correct number of attributes led
>> to memory corruption and luxrays crashing out.
>>
>> Fixes the cl/program/execute/attributes.cl piglit test.
>>
>
> Thanks for tracking this down.
>
no problem. It was driving me nuts. I've now got the luxmark kernels
building successfully on evergreen (followed by a machine hang and
loss of signal to the monitor, but that could be the kernel or the
fact that CEDAR seems extra crashy compared to my other EG/NI cards)
and I'm getting an instruction selection error on radeonsi. Haven't
managed to track that down yet, but at least it means that all
required built-ins/defines for luxrays are now present (at least with
my own libclc tree), at least with image support disabled in luxrays.
If you enable image support, I believe that it is still going to fail
due to mismatches/oddness with the number of supported pixel formats.
--Aaron
> Reviewed-by: Tom Stellard
>
>> Signed-off-by: Aaron Watry
>> CC: Tom Stellard
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
>> ---
>> src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
>> b/src/gallium/drivers/radeon/radeon_llvm_util.c
>> index 2ace91f..ec11559 100644
>> --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
>> +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
>> @@ -100,13 +100,17 @@ LLVMModuleRef
>> radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
>> kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
>> LLVMGetNamedMetadataOperands(mod, "opencl.kernels", kernel_metadata);
>> for (i = 0; i < num_kernels; i++) {
>> - LLVMValueRef kernel_signature, kernel_function;
>> + LLVMValueRef kernel_signature, *kernel_function;
>> + unsigned num_kernel_md_operands;
>> if (i == index) {
>> continue;
>> }
>> kernel_signature = kernel_metadata[i];
>> - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
>> - LLVMDeleteFunction(kernel_function);
>> + num_kernel_md_operands =
>> LLVMGetMDNodeNumOperands(kernel_signature);
>> + kernel_function = MALLOC(num_kernel_md_operands * sizeof
>> (LLVMValueRef));
>> + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
>> + LLVMDeleteFunction(*kernel_function);
>> + FREE(kernel_function);
>> }
>> FREE(kernel_metadata);
>> radeon_llvm_optimize(mod);
>> --
>> 1.9.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Thu, Jul 3, 2014 at 11:46 AM, Aaron Watry wrote:
> On Thu, Jul 3, 2014 at 9:56 AM, Tom Stellard wrote:
>> On Wed, Jul 02, 2014 at 04:34:24PM -0500, Aaron Watry wrote:
>>> Previously, we were assuming that kernel metadata nodes only had 1 operand.
>>>
>>> Kernels which have attributes can have more than 1, e.g.:
>>> !0 = metadata !{void (i32 addrspace(1)*)* @testKernel, metadata !1}
>>> !1 = metadata !{metadata !"work_group_size_hint", i32 4, i32 1, i32 1}
>>>
>>> Attempting to get the kernel without the correct number of attributes led
>>> to memory corruption and luxrays crashing out.
>>>
>>> Fixes the cl/program/execute/attributes.cl piglit test.
>>>
>>
>> Thanks for tracking this down.
>>
>
> no problem. It was driving me nuts. I've now got the luxmark kernels
> building successfully on evergreen (followed by a machine hang and
> loss of signal to the monitor, but that could be the kernel or the
> fact that CEDAR seems extra crashy compared to my other EG/NI cards)
Someone mentioned stability issues with cedar with the golden register
kernel patch. Can you see if skipping the golden register setup
helps? If so can you narrow down which registers are problematic?
Alex
> and I'm getting an instruction selection error on radeonsi. Haven't
> managed to track that down yet, but at least it means that all
> required built-ins/defines for luxrays are now present (at least with
> my own libclc tree), at least with image support disabled in luxrays.
>
> If you enable image support, I believe that it is still going to fail
> due to mismatches/oddness with the number of supported pixel formats.
>
> --Aaron
>
>> Reviewed-by: Tom Stellard
>>
>>> Signed-off-by: Aaron Watry
>>> CC: Tom Stellard
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
>>> ---
>>> src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
>>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
>>> b/src/gallium/drivers/radeon/radeon_llvm_util.c
>>> index 2ace91f..ec11559 100644
>>> --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
>>> +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
>>> @@ -100,13 +100,17 @@ LLVMModuleRef
>>> radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
>>> kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
>>> LLVMGetNamedMetadataOperands(mod, "opencl.kernels", kernel_metadata);
>>> for (i = 0; i < num_kernels; i++) {
>>> - LLVMValueRef kernel_signature, kernel_function;
>>> + LLVMValueRef kernel_signature, *kernel_function;
>>> + unsigned num_kernel_md_operands;
>>> if (i == index) {
>>> continue;
>>> }
>>> kernel_signature = kernel_metadata[i];
>>> - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
>>> - LLVMDeleteFunction(kernel_function);
>>> + num_kernel_md_operands =
>>> LLVMGetMDNodeNumOperands(kernel_signature);
>>> + kernel_function = MALLOC(num_kernel_md_operands * sizeof
>>> (LLVMValueRef));
>>> + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
>>> + LLVMDeleteFunction(*kernel_function);
>>> + FREE(kernel_function);
>>> }
>>> FREE(kernel_metadata);
>>> radeon_llvm_optimize(mod);
>>> --
>>> 1.9.1
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/5] gallium: rename PIPE_CAP_TGSI_VS_LAYER to also have _VIEWPORT
Reviewed-by: Marek Olšák
Marek
On Thu, Jul 3, 2014 at 5:17 PM, Ilia Mirkin wrote:
> Now that this cap is used to determine the availability of both, adjust
> its name to reflect the new reality.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/auxiliary/util/u_blitter.c | 2 +-
> src/gallium/docs/source/screen.rst | 6 --
> src/gallium/drivers/freedreno/freedreno_screen.c | 2 +-
> src/gallium/drivers/i915/i915_screen.c | 2 +-
> src/gallium/drivers/ilo/ilo_screen.c | 2 +-
> src/gallium/drivers/llvmpipe/lp_screen.c | 2 +-
> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 +-
> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
> src/gallium/drivers/r300/r300_screen.c | 2 +-
> src/gallium/drivers/r600/r600_pipe.c | 2 +-
> src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
> src/gallium/drivers/softpipe/sp_screen.c | 2 +-
> src/gallium/drivers/svga/svga_screen.c | 2 +-
> src/gallium/include/pipe/p_defines.h | 2 +-
> src/mesa/state_tracker/st_cb_clear.c | 2 +-
> src/mesa/state_tracker/st_extensions.c | 2 +-
> 17 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_blitter.c
> b/src/gallium/auxiliary/util/u_blitter.c
> index 7b058fe..db0d1b8 100644
> --- a/src/gallium/auxiliary/util/u_blitter.c
> +++ b/src/gallium/auxiliary/util/u_blitter.c
> @@ -325,7 +325,7 @@ struct blitter_context *util_blitter_create(struct
> pipe_context *pipe)
> }
>
> if (pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_INSTANCEID) &&
> - pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_VS_LAYER)) {
> + pipe->screen->get_param(pipe->screen,
> PIPE_CAP_TGSI_VS_LAYER_VIEWPORT)) {
>ctx->vs_layered = util_make_layered_clear_vertex_shader(pipe);
> }
>
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index 2ea0da8..ba583fe 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -174,8 +174,10 @@ The integer capabilities:
> * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
>different sizes for fb color/zs attachments. This controls whether
>ARB_framebuffer_object is provided.
> -* ``PIPE_CAP_TGSI_VS_LAYER``: Whether TGSI_SEMANTIC_LAYER is supported
> - as a vertex shader output.
> +* ``PIPE_CAP_TGSI_VS_LAYER_VIEWPORT``: Whether ``TGSI_SEMANTIC_LAYER`` and
> + ``TGSI_SEMANTIC_VIEWPORT_INDEX`` are supported as vertex shader
> + outputs. Note that the viewport will only be used if multiple viewports are
> + exposed.
> * ``PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES``: The maximum number of vertices
>output by a single invocation of a geometry shader.
> * ``PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS``: The maximum number of
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index ce3cf90..c574cb8 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -207,7 +207,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> case PIPE_CAP_USER_INDEX_BUFFERS:
> case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
> case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
> - case PIPE_CAP_TGSI_VS_LAYER:
> + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_FAKE_SW_MSAA:
> diff --git a/src/gallium/drivers/i915/i915_screen.c
> b/src/gallium/drivers/i915/i915_screen.c
> index 25432f2..86a7a67 100644
> --- a/src/gallium/drivers/i915/i915_screen.c
> +++ b/src/gallium/drivers/i915/i915_screen.c
> @@ -230,7 +230,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap
> cap)
> case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
> - case PIPE_CAP_TGSI_VS_LAYER:
> + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_DRAW_INDIRECT:
>return 0;
> diff --git a/src/gallium/drivers/ilo/ilo_screen.c
> b/src/gallium/drivers/ilo/ilo_screen.c
> index 8f8e152..a7eaa1b 100644
> --- a/src/gallium/drivers/ilo/ilo_screen.c
> +++ b/src/gallium/drivers/ilo/ilo_screen.c
> @@ -434,7 +434,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap
> param)
>return PIPE_ENDIAN_LITTLE;
> case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES:
>return true;
> - case PIPE_CAP_TGSI_VS_LAYER:
> + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
[Mesa-dev] [PATCH 1/2] R600/SI: fix shadow mapping for 1D and 2D array textures
From: Marek Olšák
It was conflicting with def TEX_SHADOW_ARRAY, which also handles them.
---
lib/Target/R600/R600Instructions.td | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 73fa345..704507d 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -216,7 +216,7 @@ class R600_REDUCTION inst, dag ins, string asm,
list pattern,
def TEX_SHADOW : PatLeaf<
(imm),
[{uint32_t TType = (uint32_t)N->getZExtValue();
-return (TType >= 6 && TType <= 8) || (TType >= 11 && TType <= 13);
+return (TType >= 6 && TType <= 8) || TType == 13;
}]
>;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: fix u_default_transfer_inline_write for textures
From: Marek Olšák
This doesn't fix any known issue. In fact, radeon drivers ignore all
the discard flags for textures and implicitly do "discard range"
for any write transfer.
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/auxiliary/util/u_transfer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_transfer.c
b/src/gallium/auxiliary/util/u_transfer.c
index 7804f2a..71da35d 100644
--- a/src/gallium/auxiliary/util/u_transfer.c
+++ b/src/gallium/auxiliary/util/u_transfer.c
@@ -25,8 +25,8 @@ void u_default_transfer_inline_write( struct pipe_context
*pipe,
usage |= PIPE_TRANSFER_WRITE;
/* transfer_inline_write implicitly discards the rewritten buffer range */
- /* XXX this looks very broken for non-buffer resources having more than one
dim. */
- if (box->x == 0 && box->width == resource->width0) {
+ if (resource->target == PIPE_BUFFER &&
+ box->x == 0 && box->width == resource->width0) {
usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
} else {
usage |= PIPE_TRANSFER_DISCARD_RANGE;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Thu, Jul 03, 2014 at 10:56:24AM -0400, Tom Stellard wrote:
> On Wed, Jul 02, 2014 at 04:34:24PM -0500, Aaron Watry wrote:
> > Previously, we were assuming that kernel metadata nodes only had 1 operand.
> >
> > Kernels which have attributes can have more than 1, e.g.:
> > !0 = metadata !{void (i32 addrspace(1)*)* @testKernel, metadata !1}
> > !1 = metadata !{metadata !"work_group_size_hint", i32 4, i32 1, i32 1}
> >
> > Attempting to get the kernel without the correct number of attributes led
> > to memory corruption and luxrays crashing out.
> >
> > Fixes the cl/program/execute/attributes.cl piglit test.
> >
>
> Thanks for tracking this down.
>
> Reviewed-by: Tom Stellard
I forgot to mention we should CC stable on this patch.
>
> > Signed-off-by: Aaron Watry
> > CC: Tom Stellard
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
> > ---
> > src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
> > b/src/gallium/drivers/radeon/radeon_llvm_util.c
> > index 2ace91f..ec11559 100644
> > --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
> > +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
> > @@ -100,13 +100,17 @@ LLVMModuleRef
> > radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
> > kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
> > LLVMGetNamedMetadataOperands(mod, "opencl.kernels", kernel_metadata);
> > for (i = 0; i < num_kernels; i++) {
> > - LLVMValueRef kernel_signature, kernel_function;
> > + LLVMValueRef kernel_signature, *kernel_function;
> > + unsigned num_kernel_md_operands;
> > if (i == index) {
> > continue;
> > }
> > kernel_signature = kernel_metadata[i];
> > - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
> > - LLVMDeleteFunction(kernel_function);
> > + num_kernel_md_operands =
> > LLVMGetMDNodeNumOperands(kernel_signature);
> > + kernel_function = MALLOC(num_kernel_md_operands * sizeof
> > (LLVMValueRef));
> > + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
> > + LLVMDeleteFunction(*kernel_function);
> > + FREE(kernel_function);
> > }
> > FREE(kernel_metadata);
> > radeon_llvm_optimize(mod);
> > --
> > 1.9.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands\
On Thu, Jul 03, 2014 at 11:59:00AM -0400, Alex Deucher wrote:
> On Thu, Jul 3, 2014 at 11:46 AM, Aaron Watry wrote:
> > On Thu, Jul 3, 2014 at 9:56 AM, Tom Stellard wrote:
> >> On Wed, Jul 02, 2014 at 04:34:24PM -0500, Aaron Watry wrote:
> >>> Previously, we were assuming that kernel metadata nodes only had 1
> >>> operand.
> >>>
> >>> Kernels which have attributes can have more than 1, e.g.:
> >>> !0 = metadata !{void (i32 addrspace(1)*)* @testKernel, metadata !1}
> >>> !1 = metadata !{metadata !"work_group_size_hint", i32 4, i32 1, i32 1}
> >>>
> >>> Attempting to get the kernel without the correct number of attributes led
> >>> to memory corruption and luxrays crashing out.
> >>>
> >>> Fixes the cl/program/execute/attributes.cl piglit test.
> >>>
> >>
> >> Thanks for tracking this down.
> >>
> >
> > no problem. It was driving me nuts. I've now got the luxmark kernels
> > building successfully on evergreen (followed by a machine hang and
> > loss of signal to the monitor, but that could be the kernel or the
> > fact that CEDAR seems extra crashy compared to my other EG/NI cards)
>
> Someone mentioned stability issues with cedar with the golden register
> kernel patch. Can you see if skipping the golden register setup
> helps? If so can you narrow down which registers are problematic?
>
Another possibility is that we aren't correctly implementing the
workaround for the control flow stack hw bug on Cedar. Since
it has a different wavefront size than other GPUs the bug is not handled
the same way.
You could try using FeatureWavefrontSize64 for cedar in Processors.td,
which would force the backend to use the same work-around on cedar as
it does for other GPUs.
-Tom
> Alex
>
> > and I'm getting an instruction selection error on radeonsi. Haven't
> > managed to track that down yet, but at least it means that all
> > required built-ins/defines for luxrays are now present (at least with
> > my own libclc tree), at least with image support disabled in luxrays.
> >
> > If you enable image support, I believe that it is still going to fail
> > due to mismatches/oddness with the number of supported pixel formats.
> >
> > --Aaron
> >
> >> Reviewed-by: Tom Stellard
> >>
> >>> Signed-off-by: Aaron Watry
> >>> CC: Tom Stellard
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
> >>> ---
> >>> src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
> >>> 1 file changed, 7 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
> >>> b/src/gallium/drivers/radeon/radeon_llvm_util.c
> >>> index 2ace91f..ec11559 100644
> >>> --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
> >>> +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
> >>> @@ -100,13 +100,17 @@ LLVMModuleRef
> >>> radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
> >>> kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
> >>> LLVMGetNamedMetadataOperands(mod, "opencl.kernels",
> >>> kernel_metadata);
> >>> for (i = 0; i < num_kernels; i++) {
> >>> - LLVMValueRef kernel_signature, kernel_function;
> >>> + LLVMValueRef kernel_signature, *kernel_function;
> >>> + unsigned num_kernel_md_operands;
> >>> if (i == index) {
> >>> continue;
> >>> }
> >>> kernel_signature = kernel_metadata[i];
> >>> - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
> >>> - LLVMDeleteFunction(kernel_function);
> >>> + num_kernel_md_operands =
> >>> LLVMGetMDNodeNumOperands(kernel_signature);
> >>> + kernel_function = MALLOC(num_kernel_md_operands * sizeof
> >>> (LLVMValueRef));
> >>> + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
> >>> + LLVMDeleteFunction(*kernel_function);
> >>> + FREE(kernel_function);
> >>> }
> >>> FREE(kernel_metadata);
> >>> radeon_llvm_optimize(mod);
> >>> --
> >>> 1.9.1
> >>>
> >>> ___
> >>> mesa-dev mailing list
> >>> mesa-dev@lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Thu, Jul 3, 2014 at 11:29 AM, Tom Stellard wrote:
> On Thu, Jul 03, 2014 at 10:56:24AM -0400, Tom Stellard wrote:
>> On Wed, Jul 02, 2014 at 04:34:24PM -0500, Aaron Watry wrote:
>> > Previously, we were assuming that kernel metadata nodes only had 1 operand.
>> >
>> > Kernels which have attributes can have more than 1, e.g.:
>> > !0 = metadata !{void (i32 addrspace(1)*)* @testKernel, metadata !1}
>> > !1 = metadata !{metadata !"work_group_size_hint", i32 4, i32 1, i32 1}
>> >
>> > Attempting to get the kernel without the correct number of attributes led
>> > to memory corruption and luxrays crashing out.
>> >
>> > Fixes the cl/program/execute/attributes.cl piglit test.
>> >
>>
>> Thanks for tracking this down.
>>
>> Reviewed-by: Tom Stellard
>
> I forgot to mention we should CC stable on this patch.
I'll add it in the commit message before I push.
--Aaron
>>
>> > Signed-off-by: Aaron Watry
>> > CC: Tom Stellard
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
>> > ---
>> > src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
>> > 1 file changed, 7 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
>> > b/src/gallium/drivers/radeon/radeon_llvm_util.c
>> > index 2ace91f..ec11559 100644
>> > --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
>> > +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
>> > @@ -100,13 +100,17 @@ LLVMModuleRef
>> > radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
>> > kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
>> > LLVMGetNamedMetadataOperands(mod, "opencl.kernels", kernel_metadata);
>> > for (i = 0; i < num_kernels; i++) {
>> > - LLVMValueRef kernel_signature, kernel_function;
>> > + LLVMValueRef kernel_signature, *kernel_function;
>> > + unsigned num_kernel_md_operands;
>> > if (i == index) {
>> > continue;
>> > }
>> > kernel_signature = kernel_metadata[i];
>> > - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
>> > - LLVMDeleteFunction(kernel_function);
>> > + num_kernel_md_operands =
>> > LLVMGetMDNodeNumOperands(kernel_signature);
>> > + kernel_function = MALLOC(num_kernel_md_operands * sizeof
>> > (LLVMValueRef));
>> > + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
>> > + LLVMDeleteFunction(*kernel_function);
>> > + FREE(kernel_function);
>> > }
>> > FREE(kernel_metadata);
>> > radeon_llvm_optimize(mod);
>> > --
>> > 1.9.1
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Thu, Jul 3, 2014 at 10:59 AM, Alex Deucher wrote:
> Someone mentioned stability issues with cedar with the golden register
> kernel patch. Can you see if skipping the golden register setup
> helps? If so can you narrow down which registers are problematic?
I'll give it a shot and see if it helps. I can reliably break the
machine currently with luxrays' slg4 program, and the gpu doesn't
recover after 10-sec as it should.
I tried Tom's wavefront-size workaround with no apparent change. It's
possible that we're messing something up in the instruction
selection/lowering, but I'll give the kernel change a try first.
--Aaron
>
> Alex
>
>> and I'm getting an instruction selection error on radeonsi. Haven't
>> managed to track that down yet, but at least it means that all
>> required built-ins/defines for luxrays are now present (at least with
>> my own libclc tree), at least with image support disabled in luxrays.
>>
>> If you enable image support, I believe that it is still going to fail
>> due to mismatches/oddness with the number of supported pixel formats.
>>
>> --Aaron
>>
>>> Reviewed-by: Tom Stellard
>>>
Signed-off-by: Aaron Watry
CC: Tom Stellard
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index 2ace91f..ec11559 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_util.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
@@ -100,13 +100,17 @@ LLVMModuleRef
radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
LLVMGetNamedMetadataOperands(mod, "opencl.kernels", kernel_metadata);
for (i = 0; i < num_kernels; i++) {
- LLVMValueRef kernel_signature, kernel_function;
+ LLVMValueRef kernel_signature, *kernel_function;
+ unsigned num_kernel_md_operands;
if (i == index) {
continue;
}
kernel_signature = kernel_metadata[i];
- LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
- LLVMDeleteFunction(kernel_function);
+ num_kernel_md_operands =
LLVMGetMDNodeNumOperands(kernel_signature);
+ kernel_function = MALLOC(num_kernel_md_operands * sizeof
(LLVMValueRef));
+ LLVMGetMDNodeOperands(kernel_signature, kernel_function);
+ LLVMDeleteFunction(*kernel_function);
+ FREE(kernel_function);
}
FREE(kernel_metadata);
radeon_llvm_optimize(mod);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Allocate space for kernel metadata operands
On Thu, Jul 03, 2014 at 11:55:25AM -0500, Aaron Watry wrote:
> On Thu, Jul 3, 2014 at 10:59 AM, Alex Deucher wrote:
> > Someone mentioned stability issues with cedar with the golden register
> > kernel patch. Can you see if skipping the golden register setup
> > helps? If so can you narrow down which registers are problematic?
>
> I'll give it a shot and see if it helps. I can reliably break the
> machine currently with luxrays' slg4 program, and the gpu doesn't
> recover after 10-sec as it should.
>
Can you file a bug for this and post the output of R600_DEBUG=cs for this
program? If I look at it I should be able to get an idea of what might
be causing the lockup.
-Tom
> I tried Tom's wavefront-size workaround with no apparent change. It's
> possible that we're messing something up in the instruction
> selection/lowering, but I'll give the kernel change a try first.
>
> --Aaron
>
> >
> > Alex
> >
> >> and I'm getting an instruction selection error on radeonsi. Haven't
> >> managed to track that down yet, but at least it means that all
> >> required built-ins/defines for luxrays are now present (at least with
> >> my own libclc tree), at least with image support disabled in luxrays.
> >>
> >> If you enable image support, I believe that it is still going to fail
> >> due to mismatches/oddness with the number of supported pixel formats.
> >>
> >> --Aaron
> >>
> >>> Reviewed-by: Tom Stellard
> >>>
> Signed-off-by: Aaron Watry
> CC: Tom Stellard
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76223
> ---
> src/gallium/drivers/radeon/radeon_llvm_util.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
> b/src/gallium/drivers/radeon/radeon_llvm_util.c
> index 2ace91f..ec11559 100644
> --- a/src/gallium/drivers/radeon/radeon_llvm_util.c
> +++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
> @@ -100,13 +100,17 @@ LLVMModuleRef
> radeon_llvm_get_kernel_module(LLVMContextRef ctx, unsigned index,
> kernel_metadata = MALLOC(num_kernels * sizeof(LLVMValueRef));
> LLVMGetNamedMetadataOperands(mod, "opencl.kernels",
> kernel_metadata);
> for (i = 0; i < num_kernels; i++) {
> - LLVMValueRef kernel_signature, kernel_function;
> + LLVMValueRef kernel_signature, *kernel_function;
> + unsigned num_kernel_md_operands;
> if (i == index) {
> continue;
> }
> kernel_signature = kernel_metadata[i];
> - LLVMGetMDNodeOperands(kernel_signature, &kernel_function);
> - LLVMDeleteFunction(kernel_function);
> + num_kernel_md_operands =
> LLVMGetMDNodeNumOperands(kernel_signature);
> + kernel_function = MALLOC(num_kernel_md_operands * sizeof
> (LLVMValueRef));
> + LLVMGetMDNodeOperands(kernel_signature, kernel_function);
> + LLVMDeleteFunction(*kernel_function);
> + FREE(kernel_function);
> }
> FREE(kernel_metadata);
> radeon_llvm_optimize(mod);
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix duplicated layout qualifier detection for GS
On 2014-07-03 07:18:42, Samuel Iglesias Gonsálvez wrote: > On Wed, 2014-07-02 at 12:47 -0700, Jordan Justen wrote: > > Reviewed-by: Jordan Justen > > I don't have commit access to the repository. > > Would you mind pushing this patch to master? Pushed. Thanks for the patch! -Jordan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Viewport extents print (don't push)
Just to verify the code does what we want...
---
src/mesa/drivers/dri/i965/gen8_viewport_state.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
index 2bf5fbb..cfbcb12 100644
--- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
@@ -93,6 +93,10 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
*/
float viewport_Xmax = ctx->ViewportArray[i].X +
ctx->ViewportArray[i].Width;
float viewport_Ymax = ctx->ViewportArray[i].Y +
ctx->ViewportArray[i].Height;
+ if (viewport_Ymax < ctx->DrawBuffer->_Ymax ||
+viewport_Xmax < ctx->DrawBuffer->_Xmax) {
+perf_debug("Using viewport extents for savings\n");
+ }
if (render_to_fbo) {
vp[12] = ctx->ViewportArray[i].X;
vp[13] = viewport_Xmax - 1;
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Viewport extents on gen8
Viewport extents are a 3rd rectangle that defines which pixels get
discarded as part of the rasterization process. This can potentially
improve performance by reducing cache usage, and freeing up PS cycles.
This will get hit if one's viewport is smaller than the full
renderbuffer, and scissoring is not used.
The functionality itself very much resembles scissoring.
---
src/mesa/drivers/dri/i965/gen8_viewport_state.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
index b366246..2bf5fbb 100644
--- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
@@ -86,17 +86,23 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
vp[10] = -gby; /* y-min */
vp[11] = gby; /* y-max */
- /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport */
+ /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport
+ * The hardware will take the intersection of the drawing rectangle,
+ * scissor rectangle, and the viewport extents. We don't need to be
+ * smart, and can therefore just program the viewport extents.
+ */
+ float viewport_Xmax = ctx->ViewportArray[i].X +
ctx->ViewportArray[i].Width;
+ float viewport_Ymax = ctx->ViewportArray[i].Y +
ctx->ViewportArray[i].Height;
if (render_to_fbo) {
- vp[12] = ctx->DrawBuffer->_Xmin;
- vp[13] = ctx->DrawBuffer->_Xmax - 1;
- vp[14] = ctx->DrawBuffer->_Ymin;
- vp[15] = ctx->DrawBuffer->_Ymax - 1;
+ vp[12] = ctx->ViewportArray[i].X;
+ vp[13] = viewport_Xmax - 1;
+ vp[14] = ctx->ViewportArray[i].Y;
+ vp[15] = viewport_Ymax - 1;
} else {
- vp[12] = ctx->DrawBuffer->_Xmin;
- vp[13] = ctx->DrawBuffer->_Xmax - 1;
- vp[14] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymax;
- vp[15] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymin - 1;
+ vp[12] = ctx->ViewportArray[i].X;
+ vp[13] = viewport_Xmax - 1;
+ vp[14] = ctx->DrawBuffer->Height - viewport_Ymax;
+ vp[15] = ctx->DrawBuffer->Height - ctx->ViewportArray[i].Y - 1;
}
vp += 16;
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/2] nv50/ir: Handle OP_CVT when folding constant expressions
Folding for conversions: F32/64->(U16/32, S16/32) and (U16/32, S16/32)->F32
No piglit regressions observed on nv50 and nvc0!
Signed-off-by: Tobias Klausmann
---
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 74 ++
1 file changed, 74 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index b89da43..007c730 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -970,6 +970,80 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue
&imm0, int s)
i->op = OP_MOV;
break;
}
+ case OP_CVT: {
+ Storage res;
+ bld.setPosition(i, true); /* make sure bld is init'ed */
+
+ switch(i->dType) {
+ case TYPE_U16:
+ switch (i->sType) {
+ case TYPE_F32: res.data.u16 = util_iround(imm0.reg.data.f32); break;
+ case TYPE_F64: res.data.u16 = util_iround(imm0.reg.data.f64); break;
+ default:
+return;
+ }
+ i->setSrc(0, bld.mkImm(res.data.u16));
+ break;
+ case TYPE_U32:
+ switch (i->sType) {
+ case TYPE_F32: res.data.u32 = util_iround(imm0.reg.data.f32); break;
+ case TYPE_F64: res.data.u32 = util_iround(imm0.reg.data.f64); break;
+ default:
+return;
+ }
+ i->setSrc(0, bld.mkImm(res.data.u32));
+ break;
+ case TYPE_S16:
+ switch (i->sType) {
+ case TYPE_F32: res.data.s16 = util_iround(imm0.reg.data.f32); break;
+ case TYPE_F64: res.data.s16 = util_iround(imm0.reg.data.f64); break;
+ default:
+return;
+ }
+ i->setSrc(0, bld.mkImm(res.data.s16));
+ break;
+ case TYPE_S32:
+ switch (i->sType) {
+ case TYPE_F32: res.data.s32 = util_iround(imm0.reg.data.f32); break;
+ case TYPE_F64: res.data.s32 = util_iround(imm0.reg.data.f64); break;
+ default:
+return;
+ }
+ i->setSrc(0, bld.mkImm(res.data.s32));
+ break;
+ case TYPE_F32:
+ switch (i->sType) {
+ case TYPE_U16: res.data.f32 = (float) imm0.reg.data.u16; break;
+ case TYPE_U32: res.data.f32 = (float) imm0.reg.data.u32; break;
+ case TYPE_S16: res.data.f32 = (float) imm0.reg.data.s16; break;
+ case TYPE_S32: res.data.f32 = (float) imm0.reg.data.s32; break;
+ default:
+return;
+ }
+ i->setSrc(0, bld.mkImm(res.data.f32));
+ break;
+ case TYPE_F64:
+ /* TODO: Check if this works, after F64 support is available */
+ switch (i->sType) {
+ case TYPE_U16: res.data.f64 = (double) imm0.reg.data.u16; break;
+ case TYPE_U32: res.data.f64 = (double) imm0.reg.data.u32; break;
+ case TYPE_S16: res.data.f64 = (double) imm0.reg.data.s16; break;
+ case TYPE_S32: res.data.f64 = (double) imm0.reg.data.s32; break;
+ default:
+return;
+ }
+ i->setSrc(0, bld.mkImm(res.data.f64));
+ break;
+ default:
+ return;
+ }
+ i->setType(i->dType); /* Remove i->sType, which we don't need anymore */
+ i->setSrc(1, NULL);
+ i->op = OP_MOV;
+
+ i->src(0).mod = Modifier(0); /* Clear the already applied modifier */
+ break;
+ }
default:
return;
}
--
1.8.4.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/2] nv50/ir: Add support for the double Type to BuildUtil
Signed-off-by: Tobias Klausmann
---
.../drivers/nouveau/codegen/nv50_ir_build_util.cpp | 17 +
.../drivers/nouveau/codegen/nv50_ir_build_util.h| 2 ++
2 files changed, 19 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.cpp
index 6d9c830..44daece 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.cpp
@@ -391,6 +391,17 @@ BuildUtil::mkImm(float f)
return mkImm(u.u32);
}
+ImmediateValue *
+BuildUtil::mkImm(double f)
+{
+ union {
+ double f64;
+ uint64_t u64;
+ } u;
+ u.f64 = f;
+ return mkImm(u.u64);
+}
+
Value *
BuildUtil::loadImm(Value *dst, float f)
{
@@ -398,6 +409,12 @@ BuildUtil::loadImm(Value *dst, float f)
}
Value *
+BuildUtil::loadImm(Value *dst, double u)
+{
+ return mkOp1v(OP_MOV, TYPE_F64, dst ? dst : getScratch(8), mkImm(u));
+}
+
+Value *
BuildUtil::loadImm(Value *dst, uint32_t u)
{
return mkOp1v(OP_MOV, TYPE_U32, dst ? dst : getScratch(), mkImm(u));
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.h
index a610c77..2abf736 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_build_util.h
@@ -90,12 +90,14 @@ public:
void mkClobber(DataFile file, uint32_t regMask, int regUnitLog2);
ImmediateValue *mkImm(float);
+ ImmediateValue *mkImm(double);
ImmediateValue *mkImm(uint32_t);
ImmediateValue *mkImm(uint64_t);
ImmediateValue *mkImm(int i) { return mkImm((uint32_t)i); }
Value *loadImm(Value *dst, float);
+ Value *loadImm(Value *dst, double);
Value *loadImm(Value *dst, uint32_t);
Value *loadImm(Value *dst, uint64_t);
--
1.8.4.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: Don't unnecessarily reemit BindGBShader commands v2
The Linux winsys can no longer relocate shader code, so avoid
reemitting BindGBShader commands. They are costly.
v2: Correctly handle errors from SVGA3D_BindGBShader()
Reported-by: Michael Banack
Signed-off-by: Thomas Hellstrom
Tested-by: Brian Paul
Reviewed-by: Brian Paul
Reviewed-by: Jakob Bornecrantz
---
src/gallium/drivers/svga/svga_shader.c | 9 -
src/gallium/drivers/svga/svga_state_fs.c | 8
src/gallium/drivers/svga/svga_state_vs.c | 11 ---
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_shader.c
b/src/gallium/drivers/svga/svga_shader.c
index 6b6b441..46efa07 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -45,13 +45,20 @@ svga_define_shader(struct svga_context *svga,
if (svga_have_gb_objects(svga)) {
struct svga_winsys_screen *sws = svga_screen(svga->pipe.screen)->sws;
+ enum pipe_error ret;
variant->gb_shader = sws->shader_create(sws, type,
variant->tokens, codeLen);
if (!variant->gb_shader)
return PIPE_ERROR_OUT_OF_MEMORY;
- return PIPE_OK;
+ ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
+ if (ret != PIPE_OK) {
+ sws->shader_destroy(sws, variant->gb_shader);
+ variant->gb_shader = NULL;
+ }
+
+ return ret;
}
else {
enum pipe_error ret;
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 8f419fa..e714c07 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -402,14 +402,6 @@ emit_hw_fs(struct svga_context *svga, unsigned dirty)
if (variant != svga->state.hw_draw.fs) {
if (svga_have_gb_objects(svga)) {
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
- if (ret != PIPE_OK)
-return ret;
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
variant->gb_shader);
if (ret != PIPE_OK)
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.c
index 125903b..545c9d7 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -243,17 +243,6 @@ emit_hw_vs(struct svga_context *svga, unsigned dirty)
if (svga_have_gb_objects(svga)) {
struct svga_winsys_gb_shader *gbshader =
variant ? variant->gb_shader : NULL;
-
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- if (gbshader) {
-ret = SVGA3D_BindGBShader(svga->swc, gbshader);
-if (ret != PIPE_OK)
- return ret;
- }
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
if (ret != PIPE_OK)
return ret;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: Fix up intelInitScreen2 for DRI3
Commit 442442026eb updated both i915 and i965 for DRI3 support,
but one check in intelInitScreen2 was missed for i915 causing crashes
when trying to use i915 with DRI3.
So fix that up.
Reported-by: Igor Gnatenko
Tested-by: František Zatloukal
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1115323
Cc: "10.2"
Signed-off-by: Adel Gadllah
---
src/mesa/drivers/dri/i915/intel_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 9b4e490..4c9726c 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -1152,7 +1152,8 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
{
struct intel_screen *intelScreen;
- if (psp->dri2.loader->base.version <= 2 ||
+ if (psp->image.loader) {
+ } else if (psp->dri2.loader->base.version <= 2 ||
psp->dri2.loader->getBuffersWithFormat == NULL) {
fprintf(stderr,
"\nERROR! DRI2 loader with getBuffersWithFormat() "
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: Don't unnecessarily reemit BindGBShader commands v2
The Linux winsys can no longer relocate shader code, so avoid
reemitting BindGBShader commands. They are costly.
v2: Correctly handle errors from SVGA3D_BindGBShader()
Reported-by: Michael Banack
Signed-off-by: Thomas Hellstrom
Tested-by: Brian Paul
Reviewed-by: Brian Paul
Reviewed-by: Jakob Bornecrantz
---
src/gallium/drivers/svga/svga_shader.c | 9 -
src/gallium/drivers/svga/svga_state_fs.c | 8
src/gallium/drivers/svga/svga_state_vs.c | 11 ---
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_shader.c
b/src/gallium/drivers/svga/svga_shader.c
index 6b6b441..46efa07 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -45,13 +45,20 @@ svga_define_shader(struct svga_context *svga,
if (svga_have_gb_objects(svga)) {
struct svga_winsys_screen *sws = svga_screen(svga->pipe.screen)->sws;
+ enum pipe_error ret;
variant->gb_shader = sws->shader_create(sws, type,
variant->tokens, codeLen);
if (!variant->gb_shader)
return PIPE_ERROR_OUT_OF_MEMORY;
- return PIPE_OK;
+ ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
+ if (ret != PIPE_OK) {
+ sws->shader_destroy(sws, variant->gb_shader);
+ variant->gb_shader = NULL;
+ }
+
+ return ret;
}
else {
enum pipe_error ret;
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 8f419fa..e714c07 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -402,14 +402,6 @@ emit_hw_fs(struct svga_context *svga, unsigned dirty)
if (variant != svga->state.hw_draw.fs) {
if (svga_have_gb_objects(svga)) {
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
- if (ret != PIPE_OK)
-return ret;
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
variant->gb_shader);
if (ret != PIPE_OK)
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.c
index 125903b..545c9d7 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -243,17 +243,6 @@ emit_hw_vs(struct svga_context *svga, unsigned dirty)
if (svga_have_gb_objects(svga)) {
struct svga_winsys_gb_shader *gbshader =
variant ? variant->gb_shader : NULL;
-
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- if (gbshader) {
-ret = SVGA3D_BindGBShader(svga->swc, gbshader);
-if (ret != PIPE_OK)
- return ret;
- }
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
if (ret != PIPE_OK)
return ret;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Don't enable SOL statistics during meta operations.
On Wednesday, July 02, 2014 09:08:04 PM Kristian Høgsberg wrote:
> On Tue, Jul 1, 2014 at 5:25 PM, Kenneth Graunke
wrote:
> > The GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN counter is not supposed to
> > increment during glGenerateMipmap(). I don't think either counter is
> > supposed to increment during most meta operations, so simply turn off
> > statistics during those.
> >
> > Fixes one Piglit test:
> > spec/EXT_transform_feedback/generatemipmap prims_written
> >
> > Signed-off-by: Kenneth Graunke
> > Cc: Iago Toral Quiroga
> > Cc: Chris Forbes
> > ---
> > src/mesa/drivers/dri/i965/gen7_sol_state.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> > index 558b525..eccd5a5 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> > @@ -240,7 +240,8 @@ upload_3dstate_streamout(struct brw_context *brw, bool
active,
> > * in each stream via SO_PRIMITIVE_STORAGE_NEEDED.
> > */
> > dw1 |= SO_FUNCTION_ENABLE;
> > - dw1 |= SO_STATISTICS_ENABLE;
> > + if (!brw->meta_in_progress)
> > + dw1 |= SO_STATISTICS_ENABLE;
> >
> > if (active) {
> >int urb_entry_read_offset = 0;
>
> Do we need to add BRW_NEW_META_IN_PROGRESS to gen7_sol_state.dirty.brw?
>
> Kristian
Eheheh...just keeping you on your toes...or...something.
Thanks, fixed in v2 :)
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl/glcpp: Integrate recent glcpp-test-cr-lf test into "make check"
Beyond just listing this in the TESTS variable in Makefile.am, only minor
changes were needed to make this work. The primary issue is that the build
system runs the test script from a different directory than the script
itself. So we have to use the $srcdir variable to find the test input files.
Using $srcdir in this way also ensures that this test works when using an
out-of-tree build.
---
> The new testing is not yet hooked up to "make check", but must currently be
> manually invoked by running ./glcpp-test-cr-lf.
And this patch fixes that, of course.
I'll feel much better knowing that if future changes to glcpp break the
support for shaders with alternate newlines, that at least "make check"
should catch that.
-Carl
src/glsl/Makefile.am | 1 +
src/glsl/glcpp/tests/glcpp-test-cr-lf | 40 ---
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 00261fd..866ef97 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -32,6 +32,7 @@ AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
include Makefile.sources
TESTS = glcpp/tests/glcpp-test \
+ glcpp/tests/glcpp-test-cr-lf\
tests/general-ir-test \
tests/optimization-test \
tests/ralloc-test \
diff --git a/src/glsl/glcpp/tests/glcpp-test-cr-lf
b/src/glsl/glcpp/tests/glcpp-test-cr-lf
index 708fce5..918f857 100755
--- a/src/glsl/glcpp/tests/glcpp-test-cr-lf
+++ b/src/glsl/glcpp/tests/glcpp-test-cr-lf
@@ -1,5 +1,18 @@
#!/bin/sh
+# The build system runs this test from a different working directory, and may
+# be in a build directory entirely separate from the source. So if the
+# "srcdir" variable is set, we must use it to locate the test files and the
+# glcpp-test script.
+
+if [ ! -z "$srcdir" ]; then
+ testdir="$srcdir/glcpp/tests"
+ glcpp_test="$srcdir/glcpp/tests/glcpp-test"
+else
+ testdir=.
+ glcpp_test=./glcpp-test
+fi
+
total=0
pass=0
@@ -76,36 +89,39 @@ echo "= Testing with r line terminators (old Mac
format) ="
# Prepare test files with '\r' instead of '\n'
rm -rf ./subtest-cr
mkdir subtest-cr
-for file in *.c; do
-tr "\n" "\r" < "$file" > subtest-cr/"$file"
-cp "$file".out subtest-cr/"$file".expected
+for file in "$testdir"/*.c; do
+base=$(basename "$file")
+tr "\n" "\r" < "$file" > subtest-cr/"$base"
+cp "$file".out subtest-cr/"$base".expected
done
-run_test "./glcpp-test --testdir=subtest-cr"
+run_test "${glcpp_test} --testdir=subtest-cr"
echo "= Testing with rn line terminators (DOS format) ="
# Prepare test files with '\r\n' instead of '\n'
rm -rf ./subtest-cr-lf
mkdir subtest-cr-lf
-for file in *.c; do
-sed -e 's/$/\r/' < "$file" > subtest-cr-lf/"$file"
-cp "$file".out subtest-cr-lf/"$file".expected
+for file in "$testdir"/*.c; do
+base=$(basename "$file")
+sed -e 's/$/\r/' < "$file" > subtest-cr-lf/"$base"
+cp "$file".out subtest-cr-lf/"$base".expected
done
-run_test "./glcpp-test --testdir=subtest-cr-lf"
+run_test "${glcpp_test} --testdir=subtest-cr-lf"
echo "= Testing with nr (bizarre, but allowed by GLSL spec.) ="
# Prepare test files with '\n\r' instead of '\n'
rm -rf ./subtest-lf-cr
mkdir subtest-lf-cr
-for file in *.c; do
-tr "\n" "\r" < "$file" | sed -e 's/\r/\n\r/g' > subtest-lf-cr/"$file"
-cp "$file".out subtest-lf-cr/"$file".expected
+for file in "$testdir"/*.c; do
+base=$(basename "$file")
+tr "\n" "\r" < "$file" | sed -e 's/\r/\n\r/g' > subtest-lf-cr/"$base"
+cp "$file".out subtest-lf-cr/"$base".expected
done
-run_test "./glcpp-test --testdir=subtest-lf-cr"
+run_test "${glcpp_test} --testdir=subtest-lf-cr"
echo ""
echo "$pass/$total tests returned correct results"
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Disable SOL buffers and decls when not doing transform feedback.
On Wednesday, July 02, 2014 10:09:49 AM Iago Toral wrote: > On Wed, 2014-07-02 at 08:49 +0200, Iago Toral wrote: > > Hello Kenneth, Steven: > > > > On Tue, 2014-07-01 at 17:25 -0700, Kenneth Graunke wrote: > > > Previously, we only emitted 3DSTATE_SO_BUFFER and 3DSTATE_SO_DECL_LIST > > > when transform feedback was active. When it was inactive, we disabled > > > the SOL stage in 3DSTATE_SOL so the other state would be ignored. > > > > > > In commit 3178d2474ae5bdd1102fb3d76a60d1d63c961ff5, Iago enabled the SOL > > > stage universally, so we could implement the GL_PRIMITIVES_GENERATED > > > statistics counter. This caused every Piglit test to trigger assertions > > > in the simulator, and apparently caused GPU hangs for some users. > > > > > > Apparently, we're supposed to program 3DSTATE_SO_DECL_LIST to zero when > > > output streams are inactive, but we hadn't been doing so. Now that SOL > > > is on, we need to do that properly. > > > > If that is the case then I guess the workaround I was trying to use for > > that hardware issue I mentioned in another e-mail may not be any good, > > since it required to configure a non-zero 3DSTATE_SO_DECL_LIST while > > outputting to a disabled stream... :( > > My workaround patch works here in IvyBridge and keeps working with your > patch since it only activates when TF is active, but since it relies on > this stuff I think it would be best if someone tests it on other > hardware when it gets reviewed. > > > I never get any GPU hangs though... > > > > > Experimentally, it looks like we also need to program 3DSTATE_SO_BUFFER > > > to zero as well, or else I get many GPU hangs on Haswell. > > > > > > Signed-off-by: Kenneth Graunke > > > Cc: Iago Toral Quiroga > > > Cc: Chris Forbes > > > Cc: Steven Newbury > > > --- > > > src/mesa/drivers/dri/i965/brw_state.h | 3 ++- > > > src/mesa/drivers/dri/i965/gen7_sol_state.c | 34 ++ > > > src/mesa/drivers/dri/i965/gen8_sol_state.c | 2 +- > > > 3 files changed, 28 insertions(+), 11 deletions(-) > > > > > > Iago, > > > > > > I noticed that pretty much every Piglit test broke in our simulation > > > environment after your patch to turn on SOL by default. Something about > > > SO_DECLs not being right. This patch seems to fix the issue. Does it > > > look reasonable to you? > > > > The patch is producing GPU hangs for me in the case where I have a > > geometry shader and no TF, so it seems that it introduces other > > problems. I'll see if I can find the reason for this. > > It looks like we have to send at least one decl per stream even if we > are configuring the number of declarations per stream to 0, otherwise we > get this GPU hang on IvyBridge at least. Interesting. I'm not seeing any documentation indicating that we should have to, but it seems like a fairly reasonable thing to do... > This seems to contradict clearly the documentation for IvyBridge. From > 8.5 3DSTATE_SO_DECL_LIST Command, dw2, bits 7:0, Num Entries[0]: > > "It is legal to specify Num Entries = 0 for all four streams > simultaneously. In this case there will be no SO_DECLs included in the > command (only DW 0-2). Note that all Stream to Buffer Selects bits must > be zero in this case (as no streams produce output). Yeah - that's what I was looking at. It /ought/ to work (and seems to on Haswell). > Which is exactly what Kenneth's patch does, but that produces a GPU hang > here. > > At the same time, there is this other statement at the beginning of that > same chapter: > > "Errata: All 128 decls for all four streams must be included whenever > this command is issued. The “Num Entries [n]” fields still contain the > actual numbers of valid decls." > > Not sure if that sentence is the fix to a previous errata or the errata > itself... but in any case, we are never sending all 128 decls but it > looks like at least on IvyBridge we have to send one or we get a GPU > hang. This is a documentation mistake. Looking at the latest docs, that errata clearly only applies to early pre-production hardware. Unfortunately, when they published the PRM, they stripped out the stepping information, and didn't strip out the entire errata. :( > Kenneth, following the above, this change to your patch fixes the GPU > hang I was running into: > > diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c b/src/mesa/drivers/dri/i965/gen7_sol_state.c > index 2013406..6d1b93c 100644 > --- a/src/mesa/drivers/dri/i965/gen7_sol_state.c > +++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c > @@ -108,8 +108,10 @@ gen7_upload_3dstate_so_decl_list(struct brw_context *brw, > * all zero (no buffers written to) and the corresponding Num Entries > * field to zero (no valid SO_DECLs)." > */ > - BEGIN_BATCH(3); > - OUT_BATCH(_3DSTATE_SO_DECL_LIST << 16 | (3 - 2)); > + BEGIN_BATCH(5); > + OUT_BATCH(_3DSTATE_SO_DECL_LIST << 16 | (5 - 2)); > + OUT_BATCH(0); > + OUT_BAT
Re: [Mesa-dev] [PATCH 8/9] i965: Check after malloc success in intel_miptree_alloc_hiz()
On Thursday, July 03, 2014 11:13:18 AM Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 2ab0faa..30030d1 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1399,6 +1399,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
>
>for (int layer = 0; layer < mt->level[level].depth; ++layer) {
> struct intel_resolve_map *m = malloc(sizeof(struct
intel_resolve_map));
> + if (!m) {
> +_mesa_error_no_memory(__func__);
> +return false;
> + }
> exec_node_init(&m->link);
> m->level = level;
> m->layer = layer;
>
NAK. This might shut up the tool, but it's almost certainly not correct.
You're leaving HiZ enabled for a level, but in a broken state.
At the very least, I would expect to see mt->level[level].has_hiz = false. I
don't know if that's sufficient.
On Gen7+, HiZ is just an optional optimization, so you should be able to just
turn it off, and have everything continue working, without needing to report
an GL_OUT_OF_MEMORY error.
In particular, you should be able to replace the malloc call here with "m =
NULL", simulating a 100% malloc failure rate, and run Piglit. If you've
solved this problem correctly, everything will continue working - there will
be no crashes, no extra GL errors, and all the tests should continue passing.
On Sandybridge we're probably just screwed, since failing to alloc HiZ (at
least for level 0) means we need to disable separate stencil as well. I
highly recommend ignoring that problem for now.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl/glcpp: Fix handling of commas that result from macro expansion
Here is some additional stress testing of nested macros where the expansion
of macros involves commas, (and whether those commas are interpreted as
argument separators or not in subsequent function-like macro calls).
Credit to the GCC documentation that directed my attention toward this issue:
https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Argument-Prescan.html
Fixing the bug required only removing code from glcpp. When first testing the
details of expansions involving commas, I had come to the mistaken conclusion
that an expanded comma should never be treated as an argument separator, (so
had introduced the rather ugly COMMA_FINAL token to represent this).
In fact, an expanded comma should be treated as a separator, (as tested here),
and this treatment can be avoided by judicious use of parentheses (as also
tested here).
With this simple removal of the COMMA_FINAL token, the behavior of glcpp
matches that of gcc's preprocessor for all of these hairy cases.
---
src/glsl/glcpp/glcpp-parse.y | 13 +---
.../tests/039-func-arg-obj-macro-with-comma.c | 21
.../039-func-arg-obj-macro-with-comma.c.expected | 23 ++
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 82fba20..8cf9258 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -178,7 +178,7 @@ add_builtin_define(glcpp_parser_t *parser, const char
*name, int value);
/* We use HASH_TOKEN, DEFINE_TOKEN and VERSION_TOKEN (as opposed to
* HASH, DEFINE, and VERSION) to avoid conflicts with other symbols,
* (such as the and start conditions in the lexer). */
-%token COMMA_FINAL DEFINED ELIF_EXPANDED HASH_TOKEN DEFINE_TOKEN
FUNC_IDENTIFIER OBJ_IDENTIFIER ELIF ELSE ENDIF ERROR IF IFDEF IFNDEF LINE
PRAGMA UNDEF VERSION_TOKEN GARBAGE IDENTIFIER IF_EXPANDED INTEGER
INTEGER_STRING LINE_EXPANDED NEWLINE OTHER PLACEHOLDER SPACE PLUS_PLUS
MINUS_MINUS
+%token DEFINED ELIF_EXPANDED HASH_TOKEN DEFINE_TOKEN FUNC_IDENTIFIER
OBJ_IDENTIFIER ELIF ELSE ENDIF ERROR IF IFDEF IFNDEF LINE PRAGMA UNDEF
VERSION_TOKEN GARBAGE IDENTIFIER IF_EXPANDED INTEGER INTEGER_STRING
LINE_EXPANDED NEWLINE OTHER PLACEHOLDER SPACE PLUS_PLUS MINUS_MINUS
%token PASTE
%type INTEGER operator SPACE integer_constant
%type expression
@@ -1161,9 +1161,6 @@ _token_print (char **out, size_t *len, token_t *token)
case MINUS_MINUS:
ralloc_asprintf_rewrite_tail (out, len, "--");
break;
- case COMMA_FINAL:
- ralloc_asprintf_rewrite_tail (out, len, ",");
- break;
case DEFINED:
ralloc_asprintf_rewrite_tail (out, len, "defined");
break;
@@ -1846,14 +1843,6 @@ _glcpp_parser_expand_node (glcpp_parser_t *parser,
/* We only expand identifiers */
if (token->type != IDENTIFIER) {
- /* We change any COMMA into a COMMA_FINAL to prevent
-* it being mistaken for an argument separator
-* later. */
- if (token->type == ',') {
- token->type = COMMA_FINAL;
- token->value.ival = COMMA_FINAL;
- }
-
return NULL;
}
diff --git a/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c
b/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c
index 0f7fe63..a7c053b 100644
--- a/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c
+++ b/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c
@@ -1,3 +1,24 @@
+/* This works. */
#define foo(a) (a)
#define bar two,words
foo(bar)
+
+/* So does this. */
+#define foo2(a,b) (a separate b)
+#define foo2_wrap(a) foo2(a)
+foo2_wrap(bar)
+
+/* But this generates an error. */
+#define foo_wrap(a) foo(a)
+foo_wrap(bar)
+
+/* Adding parentheses to foo_wrap fixes it. */
+#define foo_wrap_parens(a) foo((a))
+foo_wrap_parens(bar)
+
+/* As does adding parentheses to bar */
+#define bar_parens (two,words)
+foo_wrap(bar_parens)
+foo_wrap_parens(bar_parens)
+
+
diff --git a/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c.expected
b/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c.expected
index 8a15397..4cc7953 100644
--- a/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c.expected
+++ b/src/glsl/glcpp/tests/039-func-arg-obj-macro-with-comma.c.expected
@@ -1,3 +1,26 @@
+0:12(21): preprocessor error: Error: macro foo invoked with 2 arguments
(expected 1)
+
+
(two,words)
+
+
+
+
+(two separate words)
+
+
+
+foo(two,words)
+
+
+
+((two,words))
+
+
+
+((two,words))
+(((two,words)))
+
+
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/9] i965: check malloc return value in intel_resolve_map_set()
On Thursday, July 03, 2014 11:13:12 AM Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/intel_resolve_map.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
> index bf6bcf2..bb45231 100644
> --- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
> +++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
> @@ -22,6 +22,7 @@
> */
>
> #include "intel_resolve_map.h"
> +#include "main/imports.h"
>
> #include
> #include
> @@ -46,6 +47,11 @@ intel_resolve_map_set(struct exec_list *resolve_map,
> }
>
> struct intel_resolve_map *m = malloc(sizeof(struct intel_resolve_map));
> + if (m == NULL) {
> + _mesa_error_no_memory(__func__);
> + return;
> + }
> +
> exec_node_init(&m->link);
> m->level = level;
> m->layer = layer;
>
NAK.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ff_fragment_shader: Access glsl_types directly.
Originally, we didn't have direct accessors for all of the GLSL types,
so the only way to get at them was to use the symbol table. Now, we
can just get at them directly, which is simpler and faster.
---
src/mesa/main/ff_fragment_shader.cpp | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 2c4f3d7..8758b5e 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -914,54 +914,54 @@ static void load_texture( texenv_fragment_program *p,
GLuint unit )
switch (texTarget) {
case TEXTURE_1D_INDEX:
if (p->state->unit[unit].shadow)
-sampler_type = p->shader->symbols->get_type("sampler1DShadow");
+sampler_type = glsl_type::sampler1DShadow_type;
else
-sampler_type = p->shader->symbols->get_type("sampler1D");
+sampler_type = glsl_type::sampler1D_type;
coords = 1;
break;
case TEXTURE_1D_ARRAY_INDEX:
if (p->state->unit[unit].shadow)
-sampler_type = p->shader->symbols->get_type("sampler1DArrayShadow");
+sampler_type = glsl_type::sampler1DArrayShadow_type;
else
-sampler_type = p->shader->symbols->get_type("sampler1DArray");
+sampler_type = glsl_type::sampler1DArray_type;
coords = 2;
break;
case TEXTURE_2D_INDEX:
if (p->state->unit[unit].shadow)
-sampler_type = p->shader->symbols->get_type("sampler2DShadow");
+sampler_type = glsl_type::sampler2DShadow_type;
else
-sampler_type = p->shader->symbols->get_type("sampler2D");
+sampler_type = glsl_type::sampler2D_type;
coords = 2;
break;
case TEXTURE_2D_ARRAY_INDEX:
if (p->state->unit[unit].shadow)
-sampler_type = p->shader->symbols->get_type("sampler2DArrayShadow");
+sampler_type = glsl_type::sampler2DArrayShadow_type;
else
-sampler_type = p->shader->symbols->get_type("sampler2DArray");
+sampler_type = glsl_type::sampler2DArray_type;
coords = 3;
break;
case TEXTURE_RECT_INDEX:
if (p->state->unit[unit].shadow)
-sampler_type = p->shader->symbols->get_type("sampler2DRectShadow");
+sampler_type = glsl_type::sampler2DRectShadow_type;
else
-sampler_type = p->shader->symbols->get_type("sampler2DRect");
+sampler_type = glsl_type::sampler2DRect_type;
coords = 2;
break;
case TEXTURE_3D_INDEX:
assert(!p->state->unit[unit].shadow);
- sampler_type = p->shader->symbols->get_type("sampler3D");
+ sampler_type = glsl_type::sampler3D_type;
coords = 3;
break;
case TEXTURE_CUBE_INDEX:
if (p->state->unit[unit].shadow)
-sampler_type = p->shader->symbols->get_type("samplerCubeShadow");
+sampler_type = glsl_type::samplerCubeShadow_type;
else
-sampler_type = p->shader->symbols->get_type("samplerCube");
+sampler_type = glsl_type::samplerCube_type;
coords = 3;
break;
case TEXTURE_EXTERNAL_INDEX:
assert(!p->state->unit[unit].shadow);
- sampler_type = p->shader->symbols->get_type("samplerExternalOES");
+ sampler_type = glsl_type::samplerExternalOES_type;
coords = 2;
break;
}
@@ -1241,7 +1241,7 @@ create_new_program(struct gl_context *ctx, struct
state_key *key)
state->symbols->add_function(main_f);
ir_function_signature *main_sig =
- new(p.mem_ctx)
ir_function_signature(p.shader->symbols->get_type("void"));
+ new(p.mem_ctx) ir_function_signature(glsl_type::void_type);
main_sig->is_defined = true;
main_f->add_signature(main_sig);
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: properly implement texture opcodes that take an offset
From: Marek Olšák
Instead of using intr_name in lp_build_tgsi_action, this selects the names
with a switch statement in the emit function. This allows emitting
llvm.SI.sample for instructions without offsets and llvm.SI.image.sample.*.o
otherwise.
This depends on my LLVM changes.
When LLVM 3.5 is released, I'll switch all texture instructions to the new
intrinsics.
---
src/gallium/drivers/radeonsi/si_shader.c | 188 +--
1 file changed, 104 insertions(+), 84 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index f0650f4..335e43b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1532,8 +1532,6 @@ static void si_llvm_emit_fs_epilogue(struct
lp_build_tgsi_context * bld_base)
last_args, 9);
}
-static const struct lp_build_tgsi_action txf_action;
-
static void build_tex_intrinsic(const struct lp_build_tgsi_action * action,
struct lp_build_tgsi_context * bld_base,
struct lp_build_emit_data * emit_data);
@@ -1549,6 +1547,8 @@ static bool tgsi_is_shadow_sampler(unsigned target)
target == TGSI_TEXTURE_SHADOWRECT;
}
+static const struct lp_build_tgsi_action tex_action;
+
static void tex_fetch_args(
struct lp_build_tgsi_context * bld_base,
struct lp_build_emit_data * emit_data)
@@ -1566,6 +1566,7 @@ static void tex_fetch_args(
unsigned chan;
unsigned sampler_src = emit_data->inst->Instruction.NumSrcRegs - 1;
unsigned sampler_index =
emit_data->inst->Src[sampler_src].Register.Index;
+ bool has_offset = HAVE_LLVM >= 0x0305 ? inst->Texture.NumOffsets > 0 :
false;
if (target == TGSI_TEXTURE_BUFFER) {
LLVMTypeRef i128 = LLVMIntTypeInContext(gallivm->context, 128);
@@ -1604,8 +1605,7 @@ static void tex_fetch_args(
coords[3] = bld_base->base.one;
/* Pack offsets. */
- if (opcode == TGSI_OPCODE_TG4 &&
- inst->Texture.NumOffsets) {
+ if (has_offset && opcode != TGSI_OPCODE_TXF) {
/* The offsets are six-bit signed integers packed like this:
* X=[5:0], Y=[13:8], and Z=[21:16].
*/
@@ -1704,6 +1704,7 @@ static void tex_fetch_args(
struct lp_build_emit_data txf_emit_data = *emit_data;
LLVMValueRef txf_address[4];
unsigned txf_count = count;
+ struct tgsi_full_instruction inst = {};
memcpy(txf_address, address, sizeof(txf_address));
@@ -1717,16 +1718,18 @@ static void tex_fetch_args(
txf_address[txf_count++] =
LLVMGetUndef(LLVMInt32TypeInContext(gallivm->context));
/* Read FMASK using TXF. */
+ inst.Instruction.Opcode = TGSI_OPCODE_TXF;
+ inst.Texture.Texture = target == TGSI_TEXTURE_2D_MSAA ?
TGSI_TEXTURE_2D : TGSI_TEXTURE_2D_ARRAY;
+ txf_emit_data.inst = &inst;
txf_emit_data.chan = 0;
txf_emit_data.dst_type = LLVMVectorType(
LLVMInt32TypeInContext(gallivm->context), 4);
txf_emit_data.args[0] = lp_build_gather_values(gallivm,
txf_address, txf_count);
txf_emit_data.args[1] =
si_shader_ctx->resources[FMASK_TEX_OFFSET + sampler_index];
- txf_emit_data.args[2] = lp_build_const_int32(gallivm,
- target == TGSI_TEXTURE_2D_MSAA ? TGSI_TEXTURE_2D :
TGSI_TEXTURE_2D_ARRAY);
+ txf_emit_data.args[2] = lp_build_const_int32(gallivm,
inst.Texture.Texture);
txf_emit_data.arg_count = 3;
- build_tex_intrinsic(&txf_action, bld_base, &txf_emit_data);
+ build_tex_intrinsic(&tex_action, bld_base, &txf_emit_data);
/* Initialize some constants. */
LLVMValueRef four = LLVMConstInt(uint_bld->elem_type, 4, 0);
@@ -1817,7 +1820,8 @@ static void tex_fetch_args(
LLVMInt32TypeInContext(gallivm->context),
4);
} else if (opcode == TGSI_OPCODE_TG4 ||
- opcode == TGSI_OPCODE_LODQ) {
+ opcode == TGSI_OPCODE_LODQ ||
+ has_offset) {
unsigned is_array = target == TGSI_TEXTURE_1D_ARRAY ||
target == TGSI_TEXTURE_SHADOW1D_ARRAY ||
target == TGSI_TEXTURE_2D_ARRAY ||
@@ -1898,9 +1902,13 @@ static void build_tex_intrinsic(const struct
lp_build_tgsi_action * action,
struct lp_build_emit_data * emit_data)
{
struct lp_build_context * base = &bld_base->base;
+ unsigned opcode = emit_data->inst->Instruction.Opcode;
+ unsigned target = emit_data->inst->Texture.Texture;
char intr_name[127];
+ bool has_offset = H
[Mesa-dev] [PATCH 2/2] radeonsi: fix texture fetches with derivatives for 1DArray and 3D textures
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 34
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 335e43b..b4d4f22 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1652,11 +1652,37 @@ static void tex_fetch_args(
/* Pack user derivatives */
if (opcode == TGSI_OPCODE_TXD) {
- for (chan = 0; chan < 2; chan++) {
- address[count++] = lp_build_emit_fetch(bld_base, inst,
1, chan);
- if (num_coords > 1)
- address[count++] =
lp_build_emit_fetch(bld_base, inst, 2, chan);
+ int num_deriv_channels, param;
+
+ switch (target) {
+ case TGSI_TEXTURE_3D:
+ num_deriv_channels = 3;
+ break;
+ case TGSI_TEXTURE_2D:
+ case TGSI_TEXTURE_SHADOW2D:
+ case TGSI_TEXTURE_RECT:
+ case TGSI_TEXTURE_SHADOWRECT:
+ case TGSI_TEXTURE_2D_ARRAY:
+ case TGSI_TEXTURE_SHADOW2D_ARRAY:
+ case TGSI_TEXTURE_CUBE:
+ case TGSI_TEXTURE_SHADOWCUBE:
+ case TGSI_TEXTURE_CUBE_ARRAY:
+ case TGSI_TEXTURE_SHADOWCUBE_ARRAY:
+ num_deriv_channels = 2;
+ break;
+ case TGSI_TEXTURE_1D:
+ case TGSI_TEXTURE_SHADOW1D:
+ case TGSI_TEXTURE_1D_ARRAY:
+ case TGSI_TEXTURE_SHADOW1D_ARRAY:
+ num_deriv_channels = 1;
+ break;
+ default:
+ assert(0); /* no other targets are valid here */
}
+
+ for (param = 1; param <= 2; param++)
+ for (chan = 0; chan < num_deriv_channels; chan++)
+ address[count++] =
lp_build_emit_fetch(bld_base, inst, param, chan);
}
/* Pack texture coordinates */
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
Tom Stellard writes:
> On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
>> Tom Stellard writes:
>>
>> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
>> >> Tom Stellard writes:
>> >>
>> >> > v2:
>> >> > - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
>> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
>> >> > - Only define cl_khr_fp64 if the extension is supported.
>> >> > - Remove trailing space from extension string.
>> >> > - Rename device query function from cl_khr_fp86() to has_doubles().
>> >> > ---
>> >> > src/gallium/state_trackers/clover/api/device.cpp | 6 +++---
>> >> > src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
>> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
>> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
>> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
>> >> >
>> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
>> >> > b/src/gallium/state_trackers/clover/api/device.cpp
>> >> > index 7006702..1176668 100644
>> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
>> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> >> > param,
>> >> >break;
>> >> >
>> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
>> >> > - buf.as_scalar() = 2;
>> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>> >> >break;
>> >> >
>> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
>> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> >> > param,
>> >> >break;
>> >> >
>> >> > case CL_DEVICE_EXTENSIONS:
>> >> > - buf.as_string() = "";
>> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
>> >> >break;
>> >> >
>> >> > case CL_DEVICE_PLATFORM:
>> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> >> > param,
>> >> >break;
>> >> >
>> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
>> >> > - buf.as_scalar() = 2;
>> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>> >> >break;
>> >> >
>> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
>> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>> >> > b/src/gallium/state_trackers/clover/core/device.cpp
>> >> > index bc6b761..6bf33e0 100644
>> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
>> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
>> >> > return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
>> >> > }
>> >> >
>> >> > +bool
>> >> > +device::has_doubles() const {
>> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
>> >> > + PIPE_SHADER_CAP_DOUBLES);
>> >> > +}
>> >> > +
>> >> > std::vector
>> >> > device::max_block_size() const {
>> >> > auto v = get_compute_param(pipe,
>> >> > PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
>> >> > diff --git a/src/gallium/state_trackers/clover/core/device.hpp
>> >> > b/src/gallium/state_trackers/clover/core/device.hpp
>> >> > index 16831ab..025c648 100644
>> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
>> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
>> >> > @@ -66,6 +66,7 @@ namespace clover {
>> >> >cl_device_fp_config single_fp_config() const;
>> >> >cl_device_fp_config double_fp_config() const;
>> >> >cl_device_fp_config half_fp_config() const;
>> >> > + bool has_doubles() const;
>> >> >
>> >> >std::vector max_block_size() const;
>> >> >std::string device_name() const;
>> >> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp
>> >> > b/src/gallium/state_trackers/clover/core/program.cpp
>> >> > index e09c3aa..f65f321 100644
>> >> > --- a/src/gallium/state_trackers/clover/core/program.cpp
>> >> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
>> >> > @@ -95,7 +95,10 @@ program::build_status(const device &dev) const {
>> >> >
>> >> > std::string
>> >> > program::build_opts(const device &dev) const {
>> >> > - return _opts.count(&dev) ? _opts.find(&dev)->second : "";
>> >> > + std::string opts = _opts.count(&dev) ? _opts.find(&dev)->second :
>> >> > "";
>> >> > + if (dev.has_doubles())
>> >> > + opts.append(" -Dcl_khr_fp64");
>> >> > + return opts;
>> >>
>> >> This define belongs in the target-specific part of libclc. With this
>> >> hunk removed this patch is:
>> >>
>> >
>> > The declarations for double functions in the libclc headers are wrapped in
>> > this
>> > macro, so we need to set it here in order to be able to use them from
>> > clover.
>> >
>>
>> This abuses the ::build_opts() accessor to that end, which is only
>> suppos
Re: [Mesa-dev] [PATCH 2/3] radeonsi: add sampling of 4:2:2 subsampled textures
Andy Furniss wrote: Grigori Goronzy wrote: On 02.07.2014 22:18, Andy Furniss wrote: Before I knew how to get field sync to use my TVs deinterlacer I had to modify mesa so that I could use the vdpau de-interlacer(s), when I did this I noticed that 422 didn't work and looked the same as it does now this has gone in with my si. Are you trying to use the temporal deinterlacer with 4:2:2? Sorry, that isn't implemented yet! The temporal deinterlacer pass always outputs 4:2:0. No, I am not using the deinterlacer. I also just noticed I am getting below probably 1/frame when playing 422, I am using mplayer software decode. [25491.054338] VM fault (0x00, vmid 0) at page 0, read from unknown (0) [25491.054341] radeon :01:00.0: GPU fault detected: 146 0x06031014 [25491.054342] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [25491.054343] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ff_fragment_shader: Access glsl_types directly.
Reviewed-by: Ben Widawsky
On Thu, Jul 03, 2014 at 02:47:14PM -0700, Kenneth Graunke wrote:
> Originally, we didn't have direct accessors for all of the GLSL types,
> so the only way to get at them was to use the symbol table. Now, we
> can just get at them directly, which is simpler and faster.
> ---
> src/mesa/main/ff_fragment_shader.cpp | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp
> b/src/mesa/main/ff_fragment_shader.cpp
> index 2c4f3d7..8758b5e 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -914,54 +914,54 @@ static void load_texture( texenv_fragment_program *p,
> GLuint unit )
> switch (texTarget) {
> case TEXTURE_1D_INDEX:
>if (p->state->unit[unit].shadow)
> - sampler_type = p->shader->symbols->get_type("sampler1DShadow");
> + sampler_type = glsl_type::sampler1DShadow_type;
>else
> - sampler_type = p->shader->symbols->get_type("sampler1D");
> + sampler_type = glsl_type::sampler1D_type;
>coords = 1;
>break;
> case TEXTURE_1D_ARRAY_INDEX:
>if (p->state->unit[unit].shadow)
> - sampler_type = p->shader->symbols->get_type("sampler1DArrayShadow");
> + sampler_type = glsl_type::sampler1DArrayShadow_type;
>else
> - sampler_type = p->shader->symbols->get_type("sampler1DArray");
> + sampler_type = glsl_type::sampler1DArray_type;
>coords = 2;
>break;
> case TEXTURE_2D_INDEX:
>if (p->state->unit[unit].shadow)
> - sampler_type = p->shader->symbols->get_type("sampler2DShadow");
> + sampler_type = glsl_type::sampler2DShadow_type;
>else
> - sampler_type = p->shader->symbols->get_type("sampler2D");
> + sampler_type = glsl_type::sampler2D_type;
>coords = 2;
>break;
> case TEXTURE_2D_ARRAY_INDEX:
>if (p->state->unit[unit].shadow)
> - sampler_type = p->shader->symbols->get_type("sampler2DArrayShadow");
> + sampler_type = glsl_type::sampler2DArrayShadow_type;
>else
> - sampler_type = p->shader->symbols->get_type("sampler2DArray");
> + sampler_type = glsl_type::sampler2DArray_type;
>coords = 3;
>break;
> case TEXTURE_RECT_INDEX:
>if (p->state->unit[unit].shadow)
> - sampler_type = p->shader->symbols->get_type("sampler2DRectShadow");
> + sampler_type = glsl_type::sampler2DRectShadow_type;
>else
> - sampler_type = p->shader->symbols->get_type("sampler2DRect");
> + sampler_type = glsl_type::sampler2DRect_type;
>coords = 2;
>break;
> case TEXTURE_3D_INDEX:
>assert(!p->state->unit[unit].shadow);
> - sampler_type = p->shader->symbols->get_type("sampler3D");
> + sampler_type = glsl_type::sampler3D_type;
>coords = 3;
>break;
> case TEXTURE_CUBE_INDEX:
>if (p->state->unit[unit].shadow)
> - sampler_type = p->shader->symbols->get_type("samplerCubeShadow");
> + sampler_type = glsl_type::samplerCubeShadow_type;
>else
> - sampler_type = p->shader->symbols->get_type("samplerCube");
> + sampler_type = glsl_type::samplerCube_type;
>coords = 3;
>break;
> case TEXTURE_EXTERNAL_INDEX:
>assert(!p->state->unit[unit].shadow);
> - sampler_type = p->shader->symbols->get_type("samplerExternalOES");
> + sampler_type = glsl_type::samplerExternalOES_type;
>coords = 2;
>break;
> }
> @@ -1241,7 +1241,7 @@ create_new_program(struct gl_context *ctx, struct
> state_key *key)
> state->symbols->add_function(main_f);
>
> ir_function_signature *main_sig =
> - new(p.mem_ctx)
> ir_function_signature(p.shader->symbols->get_type("void"));
> + new(p.mem_ctx) ir_function_signature(glsl_type::void_type);
> main_sig->is_defined = true;
> main_f->add_signature(main_sig);
>
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
On Fri, Jul 04, 2014 at 12:28:20AM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
> >> Tom Stellard writes:
> >>
> >> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
> >> >> Tom Stellard writes:
> >> >>
> >> >> > v2:
> >> >> > - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
> >> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
> >> >> > - Only define cl_khr_fp64 if the extension is supported.
> >> >> > - Remove trailing space from extension string.
> >> >> > - Rename device query function from cl_khr_fp86() to has_doubles().
> >> >> > ---
> >> >> > src/gallium/state_trackers/clover/api/device.cpp | 6 +++---
> >> >> > src/gallium/state_trackers/clover/core/device.cpp | 6 ++
> >> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
> >> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
> >> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
> >> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
> >> >> >
> >> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
> >> >> > b/src/gallium/state_trackers/clover/api/device.cpp
> >> >> > index 7006702..1176668 100644
> >> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
> >> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
> >> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> > cl_device_info param,
> >> >> >break;
> >> >> >
> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
> >> >> > - buf.as_scalar() = 2;
> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >> >break;
> >> >> >
> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
> >> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> > cl_device_info param,
> >> >> >break;
> >> >> >
> >> >> > case CL_DEVICE_EXTENSIONS:
> >> >> > - buf.as_string() = "";
> >> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
> >> >> >break;
> >> >> >
> >> >> > case CL_DEVICE_PLATFORM:
> >> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> > cl_device_info param,
> >> >> >break;
> >> >> >
> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
> >> >> > - buf.as_scalar() = 2;
> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >> >break;
> >> >> >
> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
> >> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
> >> >> > b/src/gallium/state_trackers/clover/core/device.cpp
> >> >> > index bc6b761..6bf33e0 100644
> >> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
> >> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
> >> >> > return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
> >> >> > }
> >> >> >
> >> >> > +bool
> >> >> > +device::has_doubles() const {
> >> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
> >> >> > + PIPE_SHADER_CAP_DOUBLES);
> >> >> > +}
> >> >> > +
> >> >> > std::vector
> >> >> > device::max_block_size() const {
> >> >> > auto v = get_compute_param(pipe,
> >> >> > PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
> >> >> > diff --git a/src/gallium/state_trackers/clover/core/device.hpp
> >> >> > b/src/gallium/state_trackers/clover/core/device.hpp
> >> >> > index 16831ab..025c648 100644
> >> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
> >> >> > @@ -66,6 +66,7 @@ namespace clover {
> >> >> >cl_device_fp_config single_fp_config() const;
> >> >> >cl_device_fp_config double_fp_config() const;
> >> >> >cl_device_fp_config half_fp_config() const;
> >> >> > + bool has_doubles() const;
> >> >> >
> >> >> >std::vector max_block_size() const;
> >> >> >std::string device_name() const;
> >> >> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp
> >> >> > b/src/gallium/state_trackers/clover/core/program.cpp
> >> >> > index e09c3aa..f65f321 100644
> >> >> > --- a/src/gallium/state_trackers/clover/core/program.cpp
> >> >> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
> >> >> > @@ -95,7 +95,10 @@ program::build_status(const device &dev) const {
> >> >> >
> >> >> > std::string
> >> >> > program::build_opts(const device &dev) const {
> >> >> > - return _opts.count(&dev) ? _opts.find(&dev)->second : "";
> >> >> > + std::string opts = _opts.count(&dev) ? _opts.find(&dev)->second :
> >> >> > "";
> >> >> > + if (dev.has_doubles())
> >> >> > + opts.append(" -Dcl_khr_fp64");
> >> >> > + return opts;
> >> >>
> >> >> This define belongs in the target-specific part of libclc. With this
> >> >> hunk removed this patch is:
>
Re: [Mesa-dev] [PATCH 2/3] radeonsi: add sampling of 4:2:2 subsampled textures
Andy Furniss wrote: Andy Furniss wrote: Grigori Goronzy wrote: On 02.07.2014 22:18, Andy Furniss wrote: Before I knew how to get field sync to use my TVs deinterlacer I had to modify mesa so that I could use the vdpau de-interlacer(s), when I did this I noticed that 422 didn't work and looked the same as it does now this has gone in with my si. Are you trying to use the temporal deinterlacer with 4:2:2? Sorry, that isn't implemented yet! The temporal deinterlacer pass always outputs 4:2:0. No, I am not using the deinterlacer. I also just noticed I am getting below probably 1/frame when playing 422, I am using mplayer software decode. [25491.054338] VM fault (0x00, vmid 0) at page 0, read from unknown (0) [25491.054341] radeon :01:00.0: GPU fault detected: 146 0x06031014 [25491.054342] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [25491.054343] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x Maybe not 1/frame but anyway the first couple of a run have numbers rather than s [27977.386795] radeon :01:00.0: GPU fault detected: 146 0x0c035014 [27977.386800] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x15E0 [27977.386802] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03050014 [27977.386804] VM fault (0x04, vmid 1) at page 5600, write from CB (80) [27977.386841] radeon :01:00.0: GPU fault detected: 146 0x0c03e014 [27977.386842] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x15E0 [27977.386844] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x030E0014 [27977.386846] VM fault (0x04, vmid 1) at page 5600, write from CB (224) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: Don't use derived vertex state in api_arrayelt.c
Fredrik Höglund writes:
> Cc: "10.1"
(And "10.2" as pushed to master)
Hi Fredrik,
I helped prod you into pushing this patch to master, which brought it
more directly into my view as a candidate for the 10.2 branch.
Now that I'm taking a closer look at the patch, I think it's missing
something in its current form to be a candidate for the stable branch.
Specifically, the commit message is a single-line, ("Don't use derived
vertex state..."), but without any explanation of what kind of bug this
is fixing, what the severity might be, etc.
And the patch is long enough that it's not trivial to just look at it
and have some confidence that there's just the bug fix here, (whatever
that bug fix might be). [The patch could be shorter without some
renaming going on here.]
Could you prepare another version of this patch with a bit more content
in the commit message?
Your email here does have some hints:
> It's possible that this patch fixes a segfault in FlightGear (see bug 73504),
> so I think it's a candidate for the 10.1 branch, but maybe not for 10.1.0.
If there's a segfault-fix here, I'd like to see that described in the
commit message. (Like I said, I didn't find the segault fix in my
attempt to read the patch.)
And if there's a fix for a bug in bugzilla, then that should be in the
commit message as well.
I do recognize that you qualified things with "it's possible" and that
may be why this text was not in the commit message itself.
I'd like to see a little more certainty about bug fixes before pulling
them over to the stable branch.
Thanks,
-Carl
--
carl.d.wo...@intel.com
pgpYOld9xY14_.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL on Wayland
On Wed, Jul 2, 2014 at 6:37 PM, Thomas Daede wrote: > What Mesa version are you using? IIRC OpenGL 3.3 is only supported in > llvmpipe in mesa 10.3 and newer. Using MESA_GL_VERISON_OVERRIDE just fakes > the version string, it doesn't change what functions you can actually link > to. > > Also, that also means for compatibility reasons you might want to request > a slightly older OpenGL version, unless you actually use functions provided > in OpenGL 3.3 that don't exist in an older version? > I'm using a built package of Mesa git from here[1]. I hadn't noticed what you state, because my program is still almost nothing (although it uses shaders with the "#version 330 core" directive, is it normal that they compile fine?). As for your advice, my program will need OpenGL 3.2 or 3.3 in the future, and it's unlikely that r200 will support it by then :), so I need the extension. FWIW, I have filed a bug report with the 'enhancement' tag, which is hosted here[2]. 1: http://pkgbuild.com/~lcarlier/mesa-git/ 2: https://bugs.freedesktop.org/show_bug.cgi?id=80821 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
2014-07-03 10:48 GMT+02:00 Boris BREZILLON : > Hello Giovanni, > > I have recently been working on a DRM/KMS driver which does not support > OpenGL rendering (it only provides plane composition functionalities): > [1]. > > If I understand correctly you patch series might solve some of the > issues I am facing. It might get your working EGL, but it's not a complete solution, because buffer management is limited to linear CPU-addressable "dumb" buffers, which is probably not the most efficient choice (altough how much slower it gets depends on the driver and on the HWl). > I'm trying to get wayland working with HW cursor and several planes, > the problem is that it depends on GBM to provides drm plane and drm > cursor support. > > I tried to get EGL working with my DRM device and it always ask for an > atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this > point). > > First of all, am I mistaken in thinking this series could solve my > issue ? Indeed, using my patch stack (patches 2 and 3) you will have a working GBM device that will allocate GPU memory using the "dumb" interface. If your driver is then able to upload this buffers to the plane HW (or directly capable of allocating in GPU memory), that may be good enough for you. OTOH, this will not provide the wayland clients with the ability to render directly to the plane buffers, because the "dumb" interface does not provide global names that can be shared between processes, therefore clients will have to render into a shared memory location, that then the wayland compositor (weston, I assume) will have to memcpy into a GBM allocated buffer. If you want to avoid that, you will need to design an ioctl interface for your driver to allocate buffers, then write a "winsys" for the userspace side that uses those ioctls (directly or through libdrm) - first it allocates the buffer with your driver specific ioctl and then calls GEM_FLINK to get the global name, which can be passed to weston and in there to gbm_bo_import(). If your HW is uncapable of GL rendering (and thus you want to use SW rendering always) is quite likely that your driver will not be that different from dri_kms_swrast, except that will be able to share buffers (patch 3) using GEM names. > If not, could you tell me on which branch (or which tag) you based > your work ? > > I'm asking this because I tried to apply your patches on top of the > master branch (a few days ago), and after fixing some conflict I got a > segfault (sorry, I don't have the backtrace anymore :-(, but this was > related to negative stride value which was implying faulty memory > access). The patches were made against an old version of mesa, and the build system was updated meanwhile. Emil said he will rebase them, and that will happen in a couple days. You should just wait until they land. Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Another important XA patch
Thomas Hellstrom writes: > Patch st/xa: Don't close the drm fd on failure v2 causes some conflicts > when backported to 10.2. Let me know if > you need help resolving them, or if you want me to push a backported > version to 10.2. Thanks for the heads-up, Thomas. The conflict resolution seemed quite straightforward. Take a look and let me know if you think I botched anything. -Carl From ff02e7995c09278be06c34d596d3d8ca11e26ded Mon Sep 17 00:00:00 2001 From: Thomas Hellstrom Date: Thu, 3 Jul 2014 02:07:36 -0700 Subject: [PATCH] st/xa: Don't close the drm fd on failure v2 If XA fails to initialize with pipe_loader enabled, the pipe_loader's cleanup function will close the drm file descriptor. That's pretty bad because the file descriptor will probably be the X server driver's only connection to drm. Temporarily solve this by dup()'ing the file descriptor before handing it over to the pipe loader. This fixes freedesktop.org bugzilla bug #80645. v2: Fix CC addresses. Cc: "10.2" Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz (cherry picked from commit 35cf3831d71770211f29da6608313dc1f6213d7b) Conflicts: src/gallium/state_trackers/xa/xa_tracker.c --- src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c index 9add584..be16964 100644 --- a/src/gallium/state_trackers/xa/xa_tracker.c +++ b/src/gallium/state_trackers/xa/xa_tracker.c @@ -26,6 +26,7 @@ * Thomas Hellstrom */ +#include #include "xa_tracker.h" #include "xa_priv.h" #include "pipe/p_state.h" @@ -140,11 +141,15 @@ xa_tracker_create(int drm_fd) struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); enum xa_surface_type stype; unsigned int num_formats; +int loader_fd; if (!xa) return NULL; -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) +loader_fd = dup(drm_fd); +if (loader_fd == -1) +return NULL; +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); if (!xa->screen) goto out_no_screen; -- 2.0.0 pgplwa_5QMIyY.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Patches prepped for 10.2.3 release
I've just made a pass over the patches nominated for inclusion in the 10.2 branch. The results can be seen here: http://cworth.org/~cworth/mesa-stable-queue/ After a bit more testing, I expect to push the queued patches to the 10.2 branch. Then I'll likely let this sit over the weekend and release 10.2.3 next Monday. Obviously, I'll appreciate any feedback from testing or review. The list of patches "nominated, awaiting review", (that is, not yet on master), is starting to grow a bit beyond my comfort level. Fortunately, nothing there is over a month old, (but getting close in some cases). If people can take a look at that list and review some, that will be great, and will help give us a head-start for the next 10.2 release. As always, thanks to everyone for your careful code and review! That's what makes this project so awesome. -Carl -- carl.d.wo...@intel.com pgpNEXdcL_odW.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] What are some good beginner's tasks for Mesa?
Hello. I'm trying to get my feet wet with Mesa, and I was wondering what some good tasks for me would be. Thanks again. - Darius Goad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What are some good beginner's tasks for Mesa?
On Thu, Jul 3, 2014 at 11:33 PM, Darius Goad wrote: > Hello. I'm trying to get my feet wet with Mesa, and I was wondering what > some good tasks for me would be. Thanks again. Take a look at http://wiki.freedesktop.org/dri/NewbieProjects/ Also depending on the hardware you have available to you, the specific drivers might have more specific TODO's. For example, if you have NVIDIA hw and looking to work on nouveau: https://trello.com/b/ZudRDiTL/nouveau . For i965, http://wiki.freedesktop.org/dri/I965Todo/ . I suspect other drivers have similar lists, but I don't know where they are. A lot of discussion happens on freenode (IRC), so feel free to join #dri-devel and/or some of the more driver-specific channels like #nouveau, #radeon, #intel-gfx. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80266] Many instances of 1<<31, which is undefined in C99
https://bugs.freedesktop.org/show_bug.cgi?id=80266 --- Comment #13 from Vittorio --- More issues: u_pack_color.h:365 "uc->ui = (a << 24) | (r << 16) | (g << 8) | b;" should be "uc->ui = ((unsigned int)a << 24) | (r << 16) | (g << 8) | b;" m_matrix.c line 1156 "#define ONE(x) (1<<(x+16))" should be "#define ONE(x) (1U<<(x+16))" because of ONE(15). At line 1215 "if (m[15] == 1.0F) mask |= (1<<31);" should be "if (m[15] == 1.0F) mask |= (1U<<31);" -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80888] New: draw_cliptest_tmp.h computes zero/zero It is better to use NAN macro
https://bugs.freedesktop.org/show_bug.cgi?id=80888 Priority: medium Bug ID: 80888 Assignee: mesa-dev@lists.freedesktop.org Summary: draw_cliptest_tmp.h computes zero/zero It is better to use NAN macro Severity: normal Classification: Unclassified OS: Linux (All) Reporter: zec...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 Component: Other Product: Mesa draw_cliptest_tmp.h:180 "position[3] = zero / zero; /* MSVC doesn't accept 0.0 / 0.0 */" is wrong in my opinion. The NAN macro from math.h should be used instead "position[3] = NAN;" see man NAN. I believe zero/zero is against any programming language standard that I know. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80889] New: draw_pipe_clip.c division by zero in interp
https://bugs.freedesktop.org/show_bug.cgi?id=80889 Priority: medium Bug ID: 80889 Assignee: mesa-dev@lists.freedesktop.org Summary: draw_pipe_clip.c division by zero in interp Severity: normal Classification: Unclassified OS: Linux (All) Reporter: zec...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 Component: Other Product: Mesa In draw_pipe_clip.c:166 "const float oow = 1.0f / pos[3];" I found that running a geant4 example pos[3] is zero. Unfortunately I do not remember which example ran. I believe an "assert(pos[3]);" or equivalent should be put immediately before to avoid a division by zero. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Another important XA patch
Hi! On 07/04/2014 04:59 AM, Carl Worth wrote: > Thomas Hellstrom writes: >> Patch st/xa: Don't close the drm fd on failure v2 causes some conflicts >> when backported to 10.2. Let me know if >> you need help resolving them, or if you want me to push a backported >> version to 10.2. > > Thanks for the heads-up, Thomas. > > The conflict resolution seemed quite straightforward. Take a look and > let me know if you think I botched anything. > > -Carl Looks good to me. Thanks! Thomas > > From ff02e7995c09278be06c34d596d3d8ca11e26ded Mon Sep 17 00:00:00 2001 > From: Thomas Hellstrom > Date: Thu, 3 Jul 2014 02:07:36 -0700 > Subject: [PATCH] st/xa: Don't close the drm fd on failure v2 > > If XA fails to initialize with pipe_loader enabled, the pipe_loader's > cleanup function will close the drm file descriptor. That's pretty bad > because the file descriptor will probably be the X server driver's only > connection to drm. Temporarily solve this by dup()'ing the file descriptor > before handing it over to the pipe loader. > > This fixes freedesktop.org bugzilla bug #80645. > > v2: Fix CC addresses. > > Cc: "10.2" > Signed-off-by: Thomas Hellstrom > Reviewed-by: Jakob Bornecrantz > (cherry picked from commit 35cf3831d71770211f29da6608313dc1f6213d7b) > > Conflicts: > src/gallium/state_trackers/xa/xa_tracker.c > --- > src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c > index 9add584..be16964 100644 > --- a/src/gallium/state_trackers/xa/xa_tracker.c > +++ b/src/gallium/state_trackers/xa/xa_tracker.c > @@ -26,6 +26,7 @@ > * Thomas Hellstrom > */ > > +#include > #include "xa_tracker.h" > #include "xa_priv.h" > #include "pipe/p_state.h" > @@ -140,11 +141,15 @@ xa_tracker_create(int drm_fd) > struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); > enum xa_surface_type stype; > unsigned int num_formats; > +int loader_fd; > > if (!xa) > return NULL; > > -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) > +loader_fd = dup(drm_fd); > +if (loader_fd == -1) > +return NULL; > +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) > xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); > if (!xa->screen) > goto out_no_screen; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80889] draw_pipe_clip.c division by zero in interp
https://bugs.freedesktop.org/show_bug.cgi?id=80889 Roland Scheidegger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Roland Scheidegger --- Division by zero is just fine with floats, the code should be able to deal with the resulting infs (or perhaps nans in some places), if not this would be a bug. Since these values are out of our control (as they might come directly from user supplied shader) there is nothing which we could do to prevent those from happening. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80888] draw_cliptest_tmp.h computes zero/zero It is better to use NAN macro
https://bugs.freedesktop.org/show_bug.cgi?id=80888 Roland Scheidegger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Roland Scheidegger --- Unfortunately msvc (at least pre 2013) doesn't support NAN. There's only one other method I can think of to do it there which would be to use a float/uint union, set the uint to some nan bit pattern then use the float part. No idea if it would actually work and not really nicer neither. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
