Re: [Mesa-dev] [PATCH 1/8] mesa: handle OES_texture_half_float formats in _mesa_base_tex_format()
Maybe combine common items with ARB_texture_float check below? You could introduce something like: if (ctx->Extensions.ARB_texture_float || ctx->Extensions.OES_texture_half_float) { ... } if (ctx->Extensions.ARB_texture_float || ctx->Extensions.OES_texture_float) { ... } On 10/20/2017 11:21 PM, Christian Gmeiner wrote: Signed-off-by: Christian Gmeiner --- src/mesa/main/glformats.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c index 1e797c24c2..78299aebae 100644 --- a/src/mesa/main/glformats.c +++ b/src/mesa/main/glformats.c @@ -2424,6 +2424,25 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint internalFormat) return GL_YCBCR_MESA; } + if (ctx->Extensions.OES_texture_half_float) { + switch (internalFormat) { + case GL_ALPHA16F_ARB: + return GL_ALPHA; + case GL_RGBA16F_ARB: + return GL_RGBA; + case GL_RGB16F_ARB: + return GL_RGB; + case GL_INTENSITY16F_ARB: + return GL_INTENSITY; + case GL_LUMINANCE16F_ARB: + return GL_LUMINANCE; + case GL_LUMINANCE_ALPHA16F_ARB: + return GL_LUMINANCE_ALPHA; + default: + ; /* fallthrough */ + } + } + if (ctx->Extensions.ARB_texture_float) { switch (internalFormat) { case GL_ALPHA16F_ARB: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/bufferobj: don't double negate the range
Reviewed-by: Samuel Pitoiset On 10/23/2017 02:38 AM, Dave Airlie wrote: From: Dave Airlie This fixes a regression I introduced refactoring this code, I managed to invert range twice, I moved the inversion into the common code, but forgot to stop doing it in the callee. Fixes: GL45-CTS.multi_bind.dispatch_bind_buffers_base Fixes: 35ac13ed3 (mesa/bufferobj: consolidate some codepaths between ubo/ssbo/atomics.) Reported-by: Nicolai Hähnle Signed-off-by: Dave Airlie --- src/mesa/main/bufferobj.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c index b7a9692..dfeea94 100644 --- a/src/mesa/main/bufferobj.c +++ b/src/mesa/main/bufferobj.c @@ -3815,7 +3815,7 @@ bind_uniform_buffers(struct gl_context *ctx, GLuint first, GLsizei count, } set_buffer_multi_binding(ctx, buffers, i, caller, - binding, offset, size, !range, + binding, offset, size, range, USAGE_UNIFORM_BUFFER); } @@ -3916,7 +3916,7 @@ bind_shader_storage_buffers(struct gl_context *ctx, GLuint first, } set_buffer_multi_binding(ctx, buffers, i, caller, - binding, offset, size, !range, + binding, offset, size, range, USAGE_SHADER_STORAGE_BUFFER); } @@ -4238,7 +4238,7 @@ bind_atomic_buffers(struct gl_context *ctx, } set_buffer_multi_binding(ctx, buffers, i, caller, - binding, offset, size, !range, + binding, offset, size, range, USAGE_ATOMIC_COUNTER_BUFFER); } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: Fix pipeline cache locking issues
On 21 October 2017 at 02:54, Bas Nieuwenhuizen wrote: > For radv_create_shader_variants_from_pipeline_cache I'm not really > sure why this would cause corruption. Yes we might create the variants > a few times too much, but that should not cause any corruption. > Just had another look and figured out what the actual problem is - if there's a race between multiple threads to create the variants for a single entry, then they may not update p inside the loop properly (since they only do so when the variant isn't already created), so can end up using the wrong code. I'll send a patch - I don't think it's necessary now that we're locking around there (we'll only create all or none of the variants), but may as well fix it in case things change later. Alex > > Either way, it is a fix, so > Reviewed-by: Bas Nieuwenhuizen > > and pushed. Thanks. > > On Thu, Oct 19, 2017 at 12:49 PM, Alex Smith > wrote: > > Need to lock around the whole process of retrieving cached shaders, and > > around GetPipelineCacheData. > > > > This fixes GPU hangs observed when creating multiple pipelines in > > parallel, which appeared to be due to invalid shader code being pulled > > from the cache. > > > > Signed-off-by: Alex Smith > > --- > > src/amd/vulkan/radv_pipeline_cache.c | 30 > +++--- > > 1 file changed, 23 insertions(+), 7 deletions(-) > > > > diff --git a/src/amd/vulkan/radv_pipeline_cache.c b/src/amd/vulkan/radv_ > pipeline_cache.c > > index 034dc35af8..a75356b822 100644 > > --- a/src/amd/vulkan/radv_pipeline_cache.c > > +++ b/src/amd/vulkan/radv_pipeline_cache.c > > @@ -177,15 +177,20 @@ radv_create_shader_variants_from_pipeline_cache(struct > radv_device *device, > > struct > radv_shader_variant **variants) > > { > > struct cache_entry *entry; > > - if (cache) > > - entry = radv_pipeline_cache_search(cache, sha1); > > - else > > - entry = radv_pipeline_cache_search(device->mem_cache, > sha1); > > + > > + if (!cache) > > + cache = device->mem_cache; > > + > > + pthread_mutex_lock(&cache->mutex); > > + > > + entry = radv_pipeline_cache_search_unlocked(cache, sha1); > > > > if (!entry) { > > if (!device->physical_device->disk_cache || > > - (device->instance->debug_flags & > RADV_DEBUG_NO_CACHE)) > > + (device->instance->debug_flags & > RADV_DEBUG_NO_CACHE)) { > > + pthread_mutex_unlock(&cache->mutex); > > return false; > > + } > > > > uint8_t disk_sha1[20]; > > disk_cache_compute_key(device- > >physical_device->disk_cache, > > @@ -193,8 +198,10 @@ radv_create_shader_variants_from_pipeline_cache(struct > radv_device *device, > > entry = (struct cache_entry *) > > disk_cache_get(device-> > physical_device->disk_cache, > >disk_sha1, NULL); > > - if (!entry) > > + if (!entry) { > > + pthread_mutex_unlock(&cache->mutex); > > return false; > > + } > > } > > > > char *p = entry->code; > > @@ -204,8 +211,10 @@ radv_create_shader_variants_from_pipeline_cache(struct > radv_device *device, > > struct cache_entry_variant_info info; > > > > variant = calloc(1, sizeof(struct > radv_shader_variant)); > > - if (!variant) > > + if (!variant) { > > + pthread_mutex_unlock(&cache->mutex); > > return false; > > + } > > > > memcpy(&info, p, sizeof(struct > cache_entry_variant_info)); > > p += sizeof(struct cache_entry_variant_info); > > @@ -231,6 +240,7 @@ radv_create_shader_variants_from_pipeline_cache(struct > radv_device *device, > > p_atomic_inc(&entry->variants[i]->ref_count); > > > > memcpy(variants, entry->variants, sizeof(entry->variants)); > > + pthread_mutex_unlock(&cache->mutex); > > return true; > > } > > > > @@ -509,12 +519,17 @@ VkResult radv_GetPipelineCacheData( > > RADV_FROM_HANDLE(radv_pipeline_cache, cache, _cache); > > struct cache_header *header; > > VkResult result = VK_SUCCESS; > > + > > + pthread_mutex_lock(&cache->mutex); > > + > > const size_t size = sizeof(*header) + cache->total_size; > > if (pData == NULL) { > > + pthread_mutex_unlock(&cache->mutex); > > *pDataSize = size; > > return VK_SUCCESS; > > } > > if (*pDataSize < sizeof(*header)) { > > + pthread_mutex_unlock(&cache->mutex); > > *pDataSize = 0; > > return
Re: [Mesa-dev] [PATCH 0/7] u_queue fence patches and a radeonsi fix
Is there a branch somewhere that can be pulled? Thanks On 10/22/2017 08:33 PM, Nicolai Hähnle wrote: Hi all, Another multi-threading bug I ran into, this time with radeonsi shader fences. Patches 1-5 make util_queue_fence more widely usable, and include an optional futex-based implementation. The patches themselves are on top of the simple-mutex patches, but could easily be removed to drop the futex stuff (though the memory improvements are a pretty strong argument). Please review! Thanks, Nicolai -- src/gallium/drivers/radeonsi/si_shader.c | 3 + src/gallium/drivers/radeonsi/si_shader.h | 2 +- .../drivers/radeonsi/si_state_shaders.c | 94 + src/util/Makefile.sources| 1 + src/util/futex.h | 55 src/util/meson.build | 1 + src/util/simple_mtx.h| 20 +-- src/util/u_queue.c | 8 +- src/util/u_queue.h | 121 +++-- 9 files changed, 245 insertions(+), 60 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: Update code pointer correctly if a variant is already created
This was the actual cause of GPU hangs fixed by 0fdd531457ec ("radv: Fix pipeline cache locking issues"), since multiple threads would end up trying to create the variants for a single entry. Now that we're locking around the whole of this function, this isn't really necessary (we either create all or none of the variants), but fix this anyway in case things change later. Signed-off-by: Alex Smith --- src/amd/vulkan/radv_pipeline_cache.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/amd/vulkan/radv_pipeline_cache.c b/src/amd/vulkan/radv_pipeline_cache.c index a75356b822..9ba9a3b61b 100644 --- a/src/amd/vulkan/radv_pipeline_cache.c +++ b/src/amd/vulkan/radv_pipeline_cache.c @@ -231,6 +231,8 @@ radv_create_shader_variants_from_pipeline_cache(struct radv_device *device, p += entry->code_sizes[i]; entry->variants[i] = variant; + } else if (entry->code_sizes[i]) { + p += sizeof(struct cache_entry_variant_info) + entry->code_sizes[i]; } } -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103412] gallium/wgl: Another fix to context creation without prior SetPixelFormat()
https://bugs.freedesktop.org/show_bug.cgi?id=103412 Bug ID: 103412 Summary: gallium/wgl: Another fix to context creation without prior SetPixelFormat() Product: Mesa Version: 17.2 Hardware: Other OS: Windows (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: frank.rich...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 135000 --> https://bugs.freedesktop.org/attachment.cgi?id=135000&action=edit patch: Don't blindly use GetPixelFormat() return value This is a follow-up to bug 101326. The patch for that bug blindly took the pixel format index returned by GetPixelFormat(). However, what's the guarantee that this pixel format index is actually sensible in the Mesa context, or even a valid index? Well, none actually. (It's also not an entirely theoretic problem. I received a crash report where an invalid index is indicated, though I couldn't reproduce the exact scenario.) The attached patch fixes the blind usage of the index by computing the proper Mesa pixel format index from the pixel format description. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/7] u_queue fence patches and a radeonsi fix
On 23.10.2017 11:29, Samuel Pitoiset wrote: Is there a branch somewhere that can be pulled? Thanks I just pushed https://cgit.freedesktop.org/~nh/mesa/log/?h=fences-threads-ddebug, which contains all the patches I sent out yesterday in sequence. Cheers, Nicolai On 10/22/2017 08:33 PM, Nicolai Hähnle wrote: Hi all, Another multi-threading bug I ran into, this time with radeonsi shader fences. Patches 1-5 make util_queue_fence more widely usable, and include an optional futex-based implementation. The patches themselves are on top of the simple-mutex patches, but could easily be removed to drop the futex stuff (though the memory improvements are a pretty strong argument). Please review! Thanks, Nicolai -- src/gallium/drivers/radeonsi/si_shader.c | 3 + src/gallium/drivers/radeonsi/si_shader.h | 2 +- .../drivers/radeonsi/si_state_shaders.c | 94 + src/util/Makefile.sources | 1 + src/util/futex.h | 55 src/util/meson.build | 1 + src/util/simple_mtx.h | 20 +-- src/util/u_queue.c | 8 +- src/util/u_queue.h | 121 +++-- 9 files changed, 245 insertions(+), 60 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] glsl: fix derived cs variables
Reviewed-by: Samuel Pitoiset On 10/22/2017 11:37 PM, Ilia Mirkin wrote: There are two issues with the current implementation. First, it relies on the layout(local_size_*) happening in the same shader as the main function, and secondly it doesn't work for variable group sizes. In both cases, the simplest fix is to move the setup of these derived values to a later time, similar to how the gl_VertexID workarounds are done. There already exist system values defined for both of the derived values, so we use them unconditionally, and lower them after linking is performed. While we're at it, we move to using gl_LocalGroupSizeARB instead of gl_WorkGroupSize for variable group sizes. Also the dead code elimination avoidance can be removed, since there can be situations where gl_LocalGroupSizeARB is needed but has not been inserted for the shader with main function. As a result, the lowering code has to insert its own copies of the system values if needed. Reported-by: Stephane Chevigny Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103393 Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Ilia Mirkin --- Well this all turned out to be a deeper rabbit-hole than I was anticipating. I'm going to write up some piglit tests for these cases as they are fairly subtle, and unlikely to occur in practice. I figured it was easier to just re-add the system values instead of having the dead code not-remove them, since gl_LocalGroupSizeARB might not be in the shader with the main function (it's only added if the variable size ext is enabled, which it might only be in a second shader which sets the local_size_*). So we'd have to have it anyways, might as well do it for all. src/compiler/Makefile.sources| 1 + src/compiler/glsl/builtin_variables.cpp | 94 + src/compiler/glsl/glsl_parser_extras.cpp | 2 - src/compiler/glsl/ir.h | 4 - src/compiler/glsl/ir_optimization.h | 1 + src/compiler/glsl/linker.cpp | 3 + src/compiler/glsl/lower_cs_derived.cpp | 234 +++ src/compiler/glsl/meson.build| 1 + src/compiler/glsl/opt_dead_builtin_variables.cpp | 22 --- 9 files changed, 244 insertions(+), 118 deletions(-) create mode 100644 src/compiler/glsl/lower_cs_derived.cpp diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources index 2724a41286e..27cc33ab835 100644 --- a/src/compiler/Makefile.sources +++ b/src/compiler/Makefile.sources @@ -85,6 +85,7 @@ LIBGLSL_FILES = \ glsl/lower_buffer_access.cpp \ glsl/lower_buffer_access.h \ glsl/lower_const_arrays_to_uniforms.cpp \ + glsl/lower_cs_derived.cpp \ glsl/lower_discard.cpp \ glsl/lower_discard_flow.cpp \ glsl/lower_distance.cpp \ diff --git a/src/compiler/glsl/builtin_variables.cpp b/src/compiler/glsl/builtin_variables.cpp index ea2d897cc8e..00bc99dd619 100644 --- a/src/compiler/glsl/builtin_variables.cpp +++ b/src/compiler/glsl/builtin_variables.cpp @@ -1295,15 +1295,10 @@ builtin_variable_generator::generate_cs_special_vars() uvec3_t, "gl_LocalGroupSizeARB"); } - if (state->ctx->Const.LowerCsDerivedVariables) { - add_variable("gl_GlobalInvocationID", uvec3_t, ir_var_auto, 0); - add_variable("gl_LocalInvocationIndex", uint_t, ir_var_auto, 0); - } else { - add_system_value(SYSTEM_VALUE_GLOBAL_INVOCATION_ID, - uvec3_t, "gl_GlobalInvocationID"); - add_system_value(SYSTEM_VALUE_LOCAL_INVOCATION_INDEX, - uint_t, "gl_LocalInvocationIndex"); - } + add_system_value(SYSTEM_VALUE_GLOBAL_INVOCATION_ID, +uvec3_t, "gl_GlobalInvocationID"); + add_system_value(SYSTEM_VALUE_LOCAL_INVOCATION_INDEX, +uint_t, "gl_LocalInvocationIndex"); } @@ -1474,84 +1469,3 @@ _mesa_glsl_initialize_variables(exec_list *instructions, break; } } - - -/** - * Initialize compute shader variables with values that are derived from other - * compute shader variable. - */ -static void -initialize_cs_derived_variables(gl_shader *shader, -ir_function_signature *const main_sig) -{ - assert(shader->Stage == MESA_SHADER_COMPUTE); - - ir_variable *gl_GlobalInvocationID = - shader->symbols->get_variable("gl_GlobalInvocationID"); - assert(gl_GlobalInvocationID); - ir_variable *gl_WorkGroupID = - shader->symbols->get_variable("gl_WorkGroupID"); - assert(gl_WorkGroupID); - ir_variable *gl_WorkGroupSize = - shader->symbols->get_variable("gl_WorkGroupSize"); - if (gl_WorkGroupSize == NULL) { - void *const mem_ctx = ralloc_parent(shader->ir); - gl_WorkGroupSize = new(mem_ctx) ir_variable(glsl_type::uvec3_type, - "gl_WorkGroupSize", - ir_
Re: [Mesa-dev] [PATCH v2 00/32] i965 disk shader cache
On 21 October 2017 at 00:28, Jason Ekstrand wrote: > Over-all, I'm very happy with the way this turned out. Good work to all > involved! I made a few comments here and there and a pile on patch 18. > That said, I think they should all be fairly easy to resolve and, should > Emil be willing to hold off on branching for a couple of days, think this > should be good to land. With all of the refactors and changes that have > happened (particularly about params arrays and NIR serialization), I have a > high level of confidence that we're probably getting it right. Obviously, > user testing will be needed, but I think it's all solid in concept. Let's > do this! > I fear that this request is tad late. As seen already I'm happy to hear when people plans on feature X. This was the case with Andres Rodriguez, Christian Gmeiner this release and Kenneth with earlier one. Important difference is that those where made ahead of the planned branchpoint. To help awareness, we have the preliminary schedule available month+ in advance on mesa3d.org. There are also reminders on mesa-dev/mesa-announce as we get closer to the date. I realise it may be uneasy reading this but please try to give timely heads-up. Thank you Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 100202] llvmpipe Windows scons build can't detect Visual Studio 2017 toolchain
https://bugs.freedesktop.org/show_bug.cgi?id=100202 Alex Granni changed: What|Removed |Added Resolution|NOTOURBUG |FIXED --- Comment #4 from Alex Granni --- Mesa 17.2.3 supports Scons 3.0.0 which in turn supports Visual Studio 2017. This marks this bug as fixed. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] egl/wayland: Support for KHR_partial_update
This passes 33/37 deqp tests related to partial_update, 4 are not supported. Tests not supported: dEQP-EGL.functional.negative_partial_update.not_postable_surface dEQP-EGL.functional.negative_partial_update.not_current_surface dEQP-EGL.functional.negative_partial_update.buffer_preserved dEQP-EGL.functional.negative_partial_update.not_current_surface2 Reason: No matching egl config found. v2: Remove unnecessary return statement. Keep function names consistent. (Emil Velikov) Add not supported list to commit message. (Eric Engestrom) v3: Remove explicit with_damage variable. (Eric Engestrom) Signed-off-by: Harish Krupo --- src/egl/drivers/dri2/platform_wayland.c | 54 ++--- 1 file changed, 36 insertions(+), 18 deletions(-) diff --git a/src/egl/drivers/dri2/platform_wayland.c b/src/egl/drivers/dri2/platform_wayland.c index b38eb1c335..8846099d57 100644 --- a/src/egl/drivers/dri2/platform_wayland.c +++ b/src/egl/drivers/dri2/platform_wayland.c @@ -790,27 +790,44 @@ create_wl_buffer(struct dri2_egl_display *dri2_dpy, return ret; } +/** + * Called via eglSetDamageRegionKHR(), drv->API.SetDamageRegion(). + */ static EGLBoolean -try_damage_buffer(struct dri2_egl_surface *dri2_surf, - const EGLint *rects, - EGLint n_rects) +dri2_wl_set_damage_region(_EGLDriver *drv, + _EGLDisplay *dpy, + _EGLSurface *surf, + const EGLint *rects, + EGLint n_rects) { - if (wl_proxy_get_version((struct wl_proxy *) dri2_surf->wl_surface_wrapper) - < WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION) - return EGL_FALSE; + struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf); - for (int i = 0; i < n_rects; i++) { - const int *rect = &rects[i * 4]; + /* The spec doesn't mention what should be returned in case of +* failure in setting the damage buffer with the window system, so +* setting the damage to maximum surface area +*/ + if (!n_rects || + wl_proxy_get_version((struct wl_proxy *) dri2_surf->wl_surface_wrapper) + < WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION) { + wl_surface_damage(dri2_surf->wl_surface_wrapper, +0, 0, INT32_MAX, INT32_MAX); + } else { + for (int i = 0; i < n_rects; i++) { + const int *rect = &rects[i * 4]; - wl_surface_damage_buffer(dri2_surf->wl_surface_wrapper, - rect[0], - dri2_surf->base.Height - rect[1] - rect[3], - rect[2], rect[3]); + wl_surface_damage_buffer(dri2_surf->wl_surface_wrapper, + rect[0], + dri2_surf->base.Height - rect[1] - rect[3], + rect[2], rect[3]); + } } + return EGL_TRUE; } + /** - * Called via eglSwapBuffers(), drv->API.SwapBuffers(). + * Called via eglSwapBuffersWithDamage{KHR,EXT}(), + * drv->API.SwapBuffersWithDamageEXT(). */ static EGLBoolean dri2_wl_swap_buffers_with_damage(_EGLDriver *drv, @@ -875,9 +892,8 @@ dri2_wl_swap_buffers_with_damage(_EGLDriver *drv, /* If the compositor doesn't support damage_buffer, we deliberately * ignore the damage region and post maximum damage, due to * https://bugs.freedesktop.org/78190 */ - if (!n_rects || !try_damage_buffer(dri2_surf, rects, n_rects)) - wl_surface_damage(dri2_surf->wl_surface_wrapper, -0, 0, INT32_MAX, INT32_MAX); + if (n_rects || !dri2_surf->base.SetDamageRegionCalled) + dri2_wl_set_damage_region(drv, disp, draw, rects, n_rects); if (dri2_dpy->is_different_gpu) { _EGLContext *ctx = _eglGetCurrentContext(); @@ -928,7 +944,8 @@ dri2_wl_query_buffer_age(_EGLDriver *drv, static EGLBoolean dri2_wl_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw) { - return dri2_wl_swap_buffers_with_damage(drv, disp, draw, NULL, 0); + return dri2_wl_swap_buffers_with_damage(drv, disp, draw, + NULL, 0); } static struct wl_buffer * @@ -1166,7 +1183,7 @@ static const struct dri2_egl_display_vtbl dri2_wl_display_vtbl = { .swap_buffers = dri2_wl_swap_buffers, .swap_buffers_with_damage = dri2_wl_swap_buffers_with_damage, .swap_buffers_region = dri2_fallback_swap_buffers_region, - .set_damage_region = dri2_fallback_set_damage_region, + .set_damage_region = dri2_wl_set_damage_region, .post_sub_buffer = dri2_fallback_post_sub_buffer, .copy_buffers = dri2_fallback_copy_buffers, .query_buffer_age = dri2_wl_query_buffer_age, @@ -1378,6 +1395,7 @@ dri2_initialize_wayland_drm(_EGLDriver *drv, _EGLDisplay *disp) disp->Extensions.EXT_buffer_age = EGL_TRUE; disp->Extensions.EXT_swap_buffers_with_damage = EGL_TRUE; + disp->Extensions.KHR_partial_update = EGL_TRUE; /* Fill vtbl last to prevent accidentally calling virtual functi
Re: [Mesa-dev] [PATCH 03/25] threads: update for late C11 changes
Hi Nicolai, On 22 October 2017 at 20:07, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > C11 threads were changed to use struct timespec instead of xtime, and > thrd_sleep got a second argument. > As xtime was replaced with timespec there's a couple of odd bits in the code. > See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1554.htm and > http://en.cppreference.com/w/c/thread/{thrd_sleep,cnd_timedwait,mtx_timedlock} > > Note that cnd_timedwait is spec'd to be relative to TIME_UTC / CLOCK_REALTIME. > > Cc: Jose Fonseca > --- > include/c11/threads.h | 11 --- > include/c11/threads_posix.h | 39 +++ > include/c11/threads_win32.h | 37 +++-- > src/egl/drivers/dri2/egl_dri2.c | 24 +--- > 4 files changed, 47 insertions(+), 64 deletions(-) > > diff --git a/include/c11/threads.h b/include/c11/threads.h > index 573348d8091..3c3f23a8ab8 100644 > --- a/include/c11/threads.h > +++ b/include/c11/threads.h > @@ -23,42 +23,31 @@ > * FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT > * SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE > * FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR > OTHERWISE, > * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > OTHER > * DEALINGS IN THE SOFTWARE. > */ > #ifndef EMULATED_THREADS_H_INCLUDED_ > #define EMULATED_THREADS_H_INCLUDED_ > > #include > -#ifdef _MSC_VER > -#include // for xtime > -#endif > > #ifndef TIME_UTC > #define TIME_UTC 1 > #endif > > #include "c99_compat.h" /* for `inline` */ > > /* types */ > typedef void (*tss_dtor_t)(void*); > typedef int (*thrd_start_t)(void*); > > -#ifndef _MSC_VER > -struct xtime { > -time_t sec; > -long nsec; > -}; > -typedef struct xtime xtime; > -#endif > - We don't have a fall-back declaration of the struct, yet we use it below and provide a timespec_get() implementation. I'd imagine you haven't tested this on Windows (hence Jose in CC)? Quick search suggests that MSVC 2015 was the first one that introduces the struct and timespec_get. If we're safe as-is, please add a comment with some details - I'd imagine Jose had better knowledge in the area. > /* 7.25.7 Time functions */ > // 7.25.6.1 > +#if 0 I'd just drop the hunk mentioning that timespec_get() is part of time.h Thank Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/25] threads: update for late C11 changes
On 23.10.2017 13:15, Emil Velikov wrote: Hi Nicolai, On 22 October 2017 at 20:07, Nicolai Hähnle wrote: From: Nicolai Hähnle C11 threads were changed to use struct timespec instead of xtime, and thrd_sleep got a second argument. As xtime was replaced with timespec there's a couple of odd bits in the code. See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1554.htm and http://en.cppreference.com/w/c/thread/{thrd_sleep,cnd_timedwait,mtx_timedlock} Note that cnd_timedwait is spec'd to be relative to TIME_UTC / CLOCK_REALTIME. Cc: Jose Fonseca --- include/c11/threads.h | 11 --- include/c11/threads_posix.h | 39 +++ include/c11/threads_win32.h | 37 +++-- src/egl/drivers/dri2/egl_dri2.c | 24 +--- 4 files changed, 47 insertions(+), 64 deletions(-) diff --git a/include/c11/threads.h b/include/c11/threads.h index 573348d8091..3c3f23a8ab8 100644 --- a/include/c11/threads.h +++ b/include/c11/threads.h @@ -23,42 +23,31 @@ * FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT * SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE * FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS IN THE SOFTWARE. */ #ifndef EMULATED_THREADS_H_INCLUDED_ #define EMULATED_THREADS_H_INCLUDED_ #include -#ifdef _MSC_VER -#include // for xtime -#endif #ifndef TIME_UTC #define TIME_UTC 1 #endif #include "c99_compat.h" /* for `inline` */ /* types */ typedef void (*tss_dtor_t)(void*); typedef int (*thrd_start_t)(void*); -#ifndef _MSC_VER -struct xtime { -time_t sec; -long nsec; -}; -typedef struct xtime xtime; -#endif - We don't have a fall-back declaration of the struct, yet we use it below and provide a timespec_get() implementation. I'd imagine you haven't tested this on Windows (hence Jose in CC)? Right on both counts, as I don't really have a way of testing on Windows. Quick search suggests that MSVC 2015 was the first one that introduces the struct and timespec_get. If we're safe as-is, please add a comment with some details - I'd imagine Jose had better knowledge in the area. /* 7.25.7 Time functions */ // 7.25.6.1 +#if 0 I'd just drop the hunk mentioning that timespec_get() is part of time.h I wasn't sure when timespec_get was introduced, so I thought it safer to keep it around for a while in case we run into systems where time.h doesn't provide it. I can add a comment, or remove it entirely if you think that's not a concern. Cheers, Nicolai Thank Emil -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] u_queue: add a futex-based implementation of fences
On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > Fences are now 4 bytes instead of 96 bytes (on my 64-bit system). > > Signaling a fence is a single atomic operation in the fast case plus a > syscall in the slow case. > > Testing if a fence is signaled is the same as before (a simple comparison), > but waiting on a fence is now no more expensive than just testing it in > the fast (already signaled) case. > --- > src/util/futex.h | 4 +++ > src/util/u_queue.c | 2 ++ > src/util/u_queue.h | 88 > ++ > 3 files changed, 94 insertions(+) > > ... > > diff --git a/src/util/u_queue.h b/src/util/u_queue.h > index a3e12260e30..3d9f19f4e6c 100644 > --- a/src/util/u_queue.h > +++ b/src/util/u_queue.h > @@ -28,30 +28,117 @@ > * > * Jobs can be added from any thread. After that, the wait call can be used > * to wait for completion of the job. > */ > > #ifndef U_QUEUE_H > #define U_QUEUE_H > > #include > > +#include "util/futex.h" > #include "util/list.h" > +#include "util/macros.h" > #include "util/u_thread.h" > > #ifdef __cplusplus > extern "C" { > #endif > > #define UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY (1 << 0) > #define UTIL_QUEUE_INIT_RESIZE_IF_FULL(1 << 1) > > +#if defined(__GNUC__) && defined(HAVE_FUTEX) > +#define UTIL_QUEUE_FENCE_FUTEX > +#else > +#define UTIL_QUEUE_FENCE_STANDARD > +#endif > + > +#ifdef UTIL_QUEUE_FENCE_FUTEX > +/* Job completion fence. > + * Put this into your job structure. > + */ > +struct util_queue_fence { > + /* The fence can be in one of three states: > +* 0 - signaled > +* 1 - unsignaled > +* 2 - unsignaled, may have waiters > +*/ > + uint32_t val; > +}; > + > +static inline void > +util_queue_fence_init(struct util_queue_fence *fence) > +{ > + fence->val = 0; > +} > + > +static inline void > +util_queue_fence_destroy(struct util_queue_fence *fence) > +{ > + assert(fence->val == 0); > + /* no-op */ > +} > + > +static inline void > +util_queue_fence_wait(struct util_queue_fence *fence) > +{ > + uint32_t v = fence->val; > + > + if (likely(v == 0)) > + return; > + > + do { > + if (v != 2) > + v = __sync_val_compare_and_swap(&fence->val, 1, 2); > + > + futex_wait(&fence->val, 2); > + v = fence->val; > + } while(v != 0); > +} > + > +static inline void > +util_queue_fence_signal(struct util_queue_fence *fence) > +{ > + uint32_t val = __sync_lock_test_and_set(&fence->val, 0); As this is _signal(), don't you need a full barrier here? > + > + assert(val != 0); > + > + if (val == 2) The documentation says some architectures may only support a constant of 1 here... > + futex_wake_all(&fence->val); > +} Gražvydas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] radeonsi: reduce the scope of sel->mutex in si_shader_select_with_key
On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > We only need the lock to guard changes in the variant linked list. The > actual compilation can happen outside the lock, since we use the ready > fence as a guard. > --- > src/gallium/drivers/radeonsi/si_state_shaders.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c > b/src/gallium/drivers/radeonsi/si_state_shaders.c > index 8c589928b8c..d0bef09748f 100644 > --- a/src/gallium/drivers/radeonsi/si_state_shaders.c > +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c > @@ -1618,41 +1618,42 @@ current_not_ready: > if (thread_index < 0) > util_queue_fence_wait(&sel->ready); > > mtx_lock(&sel->mutex); > > /* Find the shader variant. */ > for (iter = sel->first_variant; iter; iter = iter->next_variant) { > /* Don't check the "current" shader. We checked it above. */ > if (current != iter && > memcmp(&iter->key, key, sizeof(*key)) == 0) { > + mtx_unlock(&sel->mutex); > + > if > (unlikely(!util_queue_fence_is_signalled(&iter->ready))) { > /* If it's an optimized shader and its > compilation has > * been started but isn't done, use the > unoptimized > * shader so as not to cause a stall due to > compilation. > */ > if (iter->is_optimized) { > memset(&key->opt, 0, > sizeof(key->opt)); > mtx_unlock(&sel->mutex); Double unlock > goto again; > } > > util_queue_fence_wait(&iter->ready); > } > > if (iter->compilation_failed) { > mtx_unlock(&sel->mutex); here too. > return -1; /* skip the draw call */ > } > > state->current = iter; > - mtx_unlock(&sel->mutex); > return 0; > } > } > > /* Build a new shader. */ > shader = CALLOC_STRUCT(si_shader); > if (!shader) { > mtx_unlock(&sel->mutex); > return -ENOMEM; > } Gražvydas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] Move src/eg/wayland/wayland-drm into src/wsi
Hi Dylan, I'm not 100% sure how autotools deals with cross-directory dependencies for generated files, but assuming this works, the series is: Reviewed-by: Daniel Stone Thanks for doing this! Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] automake: intel: correctly append to the LIBADD variable
From: Emil Velikov Commit 05fc62d89f5 sets the variable, yet it forgot the update the existing reference to append (instead of assign). Thus as-is the expat library was discarded from the link chain when building with Android. Fixes: 05fc62d89f5 ("automake: intel: move expat handling where it's used") Cc: Hongxu Jia Signed-off-by: Emil Velikov --- src/intel/Makefile.common.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am index 894dbb5208c..443cefc522a 100644 --- a/src/intel/Makefile.common.am +++ b/src/intel/Makefile.common.am @@ -27,5 +27,5 @@ common_libintel_common_la_LIBADD = $(EXPAT_LIBS) if HAVE_PLATFORM_ANDROID common_libintel_common_la_CFLAGS += $(ANDROID_CFLAGS) -common_libintel_common_la_LIBADD = $(ANDROID_LIBS) +common_libintel_common_la_LIBADD += $(ANDROID_LIBS) endif -- 2.14.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] u_queue: add a futex-based implementation of fences
On 23.10.2017 13:50, Grazvydas Ignotas wrote: On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle wrote: From: Nicolai Hähnle Fences are now 4 bytes instead of 96 bytes (on my 64-bit system). Signaling a fence is a single atomic operation in the fast case plus a syscall in the slow case. Testing if a fence is signaled is the same as before (a simple comparison), but waiting on a fence is now no more expensive than just testing it in the fast (already signaled) case. --- src/util/futex.h | 4 +++ src/util/u_queue.c | 2 ++ src/util/u_queue.h | 88 ++ 3 files changed, 94 insertions(+) ... diff --git a/src/util/u_queue.h b/src/util/u_queue.h index a3e12260e30..3d9f19f4e6c 100644 --- a/src/util/u_queue.h +++ b/src/util/u_queue.h @@ -28,30 +28,117 @@ * * Jobs can be added from any thread. After that, the wait call can be used * to wait for completion of the job. */ #ifndef U_QUEUE_H #define U_QUEUE_H #include +#include "util/futex.h" #include "util/list.h" +#include "util/macros.h" #include "util/u_thread.h" #ifdef __cplusplus extern "C" { #endif #define UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY (1 << 0) #define UTIL_QUEUE_INIT_RESIZE_IF_FULL(1 << 1) +#if defined(__GNUC__) && defined(HAVE_FUTEX) +#define UTIL_QUEUE_FENCE_FUTEX +#else +#define UTIL_QUEUE_FENCE_STANDARD +#endif + +#ifdef UTIL_QUEUE_FENCE_FUTEX +/* Job completion fence. + * Put this into your job structure. + */ +struct util_queue_fence { + /* The fence can be in one of three states: +* 0 - signaled +* 1 - unsignaled +* 2 - unsignaled, may have waiters +*/ + uint32_t val; +}; + +static inline void +util_queue_fence_init(struct util_queue_fence *fence) +{ + fence->val = 0; +} + +static inline void +util_queue_fence_destroy(struct util_queue_fence *fence) +{ + assert(fence->val == 0); + /* no-op */ +} + +static inline void +util_queue_fence_wait(struct util_queue_fence *fence) +{ + uint32_t v = fence->val; + + if (likely(v == 0)) + return; + + do { + if (v != 2) + v = __sync_val_compare_and_swap(&fence->val, 1, 2); + + futex_wait(&fence->val, 2); + v = fence->val; + } while(v != 0); +} + +static inline void +util_queue_fence_signal(struct util_queue_fence *fence) +{ + uint32_t val = __sync_lock_test_and_set(&fence->val, 0); As this is _signal(), don't you need a full barrier here? You're right. It's a bit surprising that __sync_lock_test_and_set isn't one. + + assert(val != 0); + + if (val == 2) The documentation says some architectures may only support a constant of 1 here... Again, surprising, but you're right. I believe both of these could be addressed by using __sync_val_compare_and_swap instead, right? Or we could move to new-style gcc atomic built-ins, but I'm not sure off-hand how widely available those are. Thanks, Nicolai + futex_wake_all(&fence->val); +} Gražvydas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] radeonsi: reduce the scope of sel->mutex in si_shader_select_with_key
On 23.10.2017 13:53, Grazvydas Ignotas wrote: On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle wrote: From: Nicolai Hähnle We only need the lock to guard changes in the variant linked list. The actual compilation can happen outside the lock, since we use the ready fence as a guard. --- src/gallium/drivers/radeonsi/si_state_shaders.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c b/src/gallium/drivers/radeonsi/si_state_shaders.c index 8c589928b8c..d0bef09748f 100644 --- a/src/gallium/drivers/radeonsi/si_state_shaders.c +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c @@ -1618,41 +1618,42 @@ current_not_ready: if (thread_index < 0) util_queue_fence_wait(&sel->ready); mtx_lock(&sel->mutex); /* Find the shader variant. */ for (iter = sel->first_variant; iter; iter = iter->next_variant) { /* Don't check the "current" shader. We checked it above. */ if (current != iter && memcmp(&iter->key, key, sizeof(*key)) == 0) { + mtx_unlock(&sel->mutex); + if (unlikely(!util_queue_fence_is_signalled(&iter->ready))) { /* If it's an optimized shader and its compilation has * been started but isn't done, use the unoptimized * shader so as not to cause a stall due to compilation. */ if (iter->is_optimized) { memset(&key->opt, 0, sizeof(key->opt)); mtx_unlock(&sel->mutex); Double unlock goto again; } util_queue_fence_wait(&iter->ready); } if (iter->compilation_failed) { mtx_unlock(&sel->mutex); here too. Right on both counts. No idea what happened there :) I'll fix it. Cheers, Nicolai return -1; /* skip the draw call */ } state->current = iter; - mtx_unlock(&sel->mutex); return 0; } } /* Build a new shader. */ shader = CALLOC_STRUCT(si_shader); if (!shader) { mtx_unlock(&sel->mutex); return -ENOMEM; } Gražvydas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] create src/wsi
On 21.10.2017 03:00, Dylan Baker wrote: This very short series creates a new src/wsi folder, and moves wayland-drm into it. Basically wsi stuff is scattered about, and is needed by multiple components within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan wayland-wsi. I think there's more that could be moved into wsi, we could move EGL, GBM, and GLX, and vulkan/wsi, for example. The general thrust sounds good to me. Is there a clean model for what should go into src/wsi and what shouldn't? Where's the boundary? For an example of the type of headaches, does DRI driver code (stuff that ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then what about gallium/state_trackers/dri? What about mesa/drivers/dri/common? I don't have a full picture of all this code so it's hard for me to say, but I really hope your changes will lead to a clearer picture overall :) Cheers, Nicolai ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 17.3.0-rc1
The first release candidate for Mesa 17.3.0 is now available. The plan is to have one release candidate every Friday, until the final release on 11th November 2017. The expectation is that the 17.2 branch will remain alive with bi-weekly releases until the 17.3.1 release. Here are the people which helped shape the current release. 4 Aaron Watry 10 Adam Jackson 5 Alex Smith 1 Alexandru-Liviu Prodea 12 Andres Gomez 28 Andres Rodriguez 8 Anuj Phogat 100 Bas Nieuwenhuizen 5 Ben Crocker 4 Ben Widawsky 2 Benedikt Schemmer 1 Boris Brezillon 1 Boyuan Zhang 50 Brian Paul 1 Bruce Cherniak 19 Chad Versace 6 Charmaine Lee 1 Cherniak, Bruce 1 Chih-Wei Huang 21 Chris Wilson 10 Christian Gmeiner 1 Christian König 1 Christoph Berliner 1 Christoph Haag 1 Chuck Atkins 12 Connor Abbott 2 Constantine Charlamov 10 Daniel Stone 2 Darren Salt 121 Dave Airlie 4 David Airlie 1 Denis Pauk 1 Derek Foreman 56 Dylan Baker 1 Eduardo Lima Mitev 1 Eleni Maria Stea 91 Emil Velikov 111 Eric Anholt 74 Eric Engestrom 4 Francisco Jerez 3 Frank Richter 1 Fredrik Höglund 5 George Kyriazis 13 Gert Wollny 7 Grazvydas Ignotas 1 Grigori Goronzy 7 Gurchetan Singh 1 Gurkirpal Singh 12 Gwan-gyeong Mun 1 Henri Verbeet 1 Hongxu Jia 22 Iago Toral Quiroga 20 Ian Romanick 20 Ilia Mirkin 1 Jakob Bornecrantz 11 Jan Vesely 170 Jason Ekstrand 2 Jeremy Huddleston 1 Jon Turney 1 Jonas Pfeil 1 Jordan Justen 3 José Fonseca 18 Juan A. Suarez Romero 1 Julien Isorce 5 Józef Kucia 1 Kai Chen 2 Kamil Páral 3 Karol Herbst 125 Kenneth Graunke 2 Kevin Rogovin 1 Krzysztof Sobiecki 56 Leo Liu 45 Lionel Landwerlin 2 Louis-Francis Ratté-Boulianne 11 Lucas Stach 233 Marek Olšák 1 Mario Kleiner 1 Mark Janes 5 Mark Thompson 103 Matt Turner 4 Mauro Rossi 1 Micah Fedke 1 Michael Olbrich 1 Michal Srb 6 Michel Dänzer 2 Miklós Máté 2 Neha Bhende 2 Nicholas Miell 1 Nicolai Hähnle 3 Nicolai Hähnle 270 Nicolai Hähnle 4 Plamena Manolova 2 Rafael Antognolli 1 Ray Strode 4 Rob Clark 11 Rob Herring 14 Roland Scheidegger 6 Samuel Iglesias Gonsálvez 298 Samuel Pitoiset 3 Scott D Phillips 1 Stefan Schake 24 Tapani Pälli 7 Thomas Helland 26 Thomas Hellstrom 60 Tim Rowley 98 Timothy Arceri 3 Tobias Klausmann 1 Tomasz Figa 4 Topi Pohjolainen 2 Ville Syrjälä 3 Vinson Lee 12 Wladimir J. van der Laan 1 Xavier Bouchoux 1 Yogesh Marathe 3 Zhongmin Wu 1 tournier.elie git tag: mesa-17.3.0-rc1 https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.gz MD5: b9d56f841f6bcdefbbb817ab46748323 mesa-17.3.0-rc1.tar.gz SHA1: bec1cfa8578bb474f23672a9889a300622ba59df mesa-17.3.0-rc1.tar.gz SHA256: e399c7a9af6228334b28eb888ce9050042dfbde05ee6cd0afcf1bb6c546bff4b mesa-17.3.0-rc1.tar.gz SHA512: 0ef8519d6efa0435085fd5102254f5f597fca7d7a3fe5ab51dfe9ee283a915ab965027b40227fc4e49e6d31579ab30d8a796e29ba77af8706f38a86a51a93b51 mesa-17.3.0-rc1.tar.gz PGP: https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.gz.sig https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.xz MD5: 54bc51619a0309b09df190b8d96f4d92 mesa-17.3.0-rc1.tar.xz SHA1: 5806030c27d9b91613e04b2e8339415422457813 mesa-17.3.0-rc1.tar.xz SHA256: 290b162e85ad1baa6d8cf59828eeaa6bfd03db122a954dee73cd7a0a87ebd880 mesa-17.3.0-rc1.tar.xz SHA512: 573dff68ed757b2787162fd2fdc3bcaca33cf51901d60321066d9e29e014c2ba7398942941e067871311b4e3dd002574fea37b5afd2c9fd58530f69aca32a7cb mesa-17.3.0-rc1.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.xz.sig ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] clover: Fix compilation after clang r315871
On Sun, 2017-10-22 at 20:40 -0700, Francisco Jerez wrote: > Jan Vesely writes: > > > From: Jan Vesely > > > > v2: use a more generic compat function > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103388 > > Signed-off-by: Jan Vesely > > --- > > src/gallium/state_trackers/clover/llvm/codegen/common.cpp | 5 ++--- > > src/gallium/state_trackers/clover/llvm/compat.hpp | 12 ++-- > > 2 files changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp > > b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp > > index 075183400a..dd9d02ab11 100644 > > --- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp > > +++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp > > @@ -70,7 +70,6 @@ namespace { > > make_kernel_args(const Module &mod, const std::string &kernel_name, > > const clang::CompilerInstance &c) { > >std::vector args; > > - const auto address_spaces = c.getTarget().getAddressSpaceMap(); > >const Function &f = *mod.getFunction(kernel_name); > >::llvm::DataLayout dl(&mod); > >const auto size_type = > > @@ -128,8 +127,8 @@ namespace { > > const unsigned address_space = > >cast< > > ::llvm::PointerType>(actual_type)->getAddressSpace(); > > > > - if (address_space == > > address_spaces[clang::LangAS::opencl_local > > - - > > compat::lang_as_offset]) { > > + if (address_space == compat::target_lang_address_space( > > + c.getTarget(), > > clang::LangAS::opencl_local)) { > >args.emplace_back(module::argument::local, arg_api_size, > > target_size, target_align, > > module::argument::zero_ext); > > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp > > b/src/gallium/state_trackers/clover/llvm/compat.hpp > > index f8b56516d5..3e34f0dd94 100644 > > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp > > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp > > @@ -69,11 +69,19 @@ namespace clover { > > typedef ::llvm::TargetLibraryInfo target_library_info; > > #endif > > > > + template > > + unsigned target_lang_address_space(const T& target, const AS > > lang_as) { > > Can you name this "target_address_space" (to me lang address space means > the LangAS enum, i.e. the non-target-dependent representation, which is > not what you get as result from this function), and place the '&' sign > consistently in the argument declaration? Does this refer only to whitespace around "T& target", or would you prefer to pass lang_as as reference as well? (it's an integral type so I did not consider it necessary). Jan > With that cleaned up patch > is: > > Reviewed-by: Francisco Jerez > > Thanks! > > > +const auto &map = target.getAddressSpaceMap(); > > +#if HAVE_LLVM >= 0x0500 > > +return map[static_cast(lang_as)]; > > +#else > > +return map[lang_as - clang::LangAS::Offset]; > > +#endif > > + } > > + > > #if HAVE_LLVM >= 0x0500 > > - const auto lang_as_offset = 0; > > const clang::InputKind ik_opencl = clang::InputKind::OpenCL; > > #else > > - const auto lang_as_offset = clang::LangAS::Offset; > > const clang::InputKind ik_opencl = clang::IK_OpenCL; > > #endif > > > > -- > > 2.13.6 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] u_queue: add a futex-based implementation of fences
On Mon, Oct 23, 2017 at 4:04 PM, Nicolai Hähnle wrote: > On 23.10.2017 13:50, Grazvydas Ignotas wrote: >> >> On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle >> wrote: >>> >>> From: Nicolai Hähnle >>> >>> Fences are now 4 bytes instead of 96 bytes (on my 64-bit system). >>> >>> Signaling a fence is a single atomic operation in the fast case plus a >>> syscall in the slow case. >>> >>> Testing if a fence is signaled is the same as before (a simple >>> comparison), >>> but waiting on a fence is now no more expensive than just testing it in >>> the fast (already signaled) case. >>> --- >>> src/util/futex.h | 4 +++ >>> src/util/u_queue.c | 2 ++ >>> src/util/u_queue.h | 88 >>> ++ >>> 3 files changed, 94 insertions(+) >>> >>> ... >>> >>> diff --git a/src/util/u_queue.h b/src/util/u_queue.h >>> index a3e12260e30..3d9f19f4e6c 100644 >>> --- a/src/util/u_queue.h >>> +++ b/src/util/u_queue.h >>> @@ -28,30 +28,117 @@ >>>* >>>* Jobs can be added from any thread. After that, the wait call can be >>> used >>>* to wait for completion of the job. >>>*/ >>> >>> #ifndef U_QUEUE_H >>> #define U_QUEUE_H >>> >>> #include >>> >>> +#include "util/futex.h" >>> #include "util/list.h" >>> +#include "util/macros.h" >>> #include "util/u_thread.h" >>> >>> #ifdef __cplusplus >>> extern "C" { >>> #endif >>> >>> #define UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY (1 << 0) >>> #define UTIL_QUEUE_INIT_RESIZE_IF_FULL(1 << 1) >>> >>> +#if defined(__GNUC__) && defined(HAVE_FUTEX) >>> +#define UTIL_QUEUE_FENCE_FUTEX >>> +#else >>> +#define UTIL_QUEUE_FENCE_STANDARD >>> +#endif >>> + >>> +#ifdef UTIL_QUEUE_FENCE_FUTEX >>> +/* Job completion fence. >>> + * Put this into your job structure. >>> + */ >>> +struct util_queue_fence { >>> + /* The fence can be in one of three states: >>> +* 0 - signaled >>> +* 1 - unsignaled >>> +* 2 - unsignaled, may have waiters >>> +*/ >>> + uint32_t val; >>> +}; >>> + >>> +static inline void >>> +util_queue_fence_init(struct util_queue_fence *fence) >>> +{ >>> + fence->val = 0; >>> +} >>> + >>> +static inline void >>> +util_queue_fence_destroy(struct util_queue_fence *fence) >>> +{ >>> + assert(fence->val == 0); >>> + /* no-op */ >>> +} >>> + >>> +static inline void >>> +util_queue_fence_wait(struct util_queue_fence *fence) >>> +{ >>> + uint32_t v = fence->val; >>> + >>> + if (likely(v == 0)) >>> + return; >>> + >>> + do { >>> + if (v != 2) >>> + v = __sync_val_compare_and_swap(&fence->val, 1, 2); >>> + >>> + futex_wait(&fence->val, 2); >>> + v = fence->val; >>> + } while(v != 0); >>> +} >>> + >>> +static inline void >>> +util_queue_fence_signal(struct util_queue_fence *fence) >>> +{ >>> + uint32_t val = __sync_lock_test_and_set(&fence->val, 0); >> >> >> As this is _signal(), don't you need a full barrier here? > > > You're right. It's a bit surprising that __sync_lock_test_and_set isn't one. > > >>> + >>> + assert(val != 0); >>> + >>> + if (val == 2) >> >> >> The documentation says some architectures may only support a constant >> of 1 here... > > > Again, surprising, but you're right. > > I believe both of these could be addressed by using > __sync_val_compare_and_swap instead, right? I believe so too. > Or we could move to new-style gcc atomic built-ins, but I'm not sure > off-hand how widely available those are. There's u_atomic.h that already uses some __atomic_*() built-ins, p_atomic_cmpxchg is just __sync_val_compare_and_swap but could use it for consistency with other mesa code. Gražvydas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] create src/wsi
On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle wrote: > On 21.10.2017 03:00, Dylan Baker wrote: > >> This very short series creates a new src/wsi folder, and moves >> wayland-drm into >> it. Basically wsi stuff is scattered about, and is needed by multiple >> components >> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan >> wayland-wsi. >> >> I think there's more that could be moved into wsi, we could move EGL, >> GBM, and >> GLX, and vulkan/wsi, for example. >> > > The general thrust sounds good to me. > > Is there a clean model for what should go into src/wsi and what shouldn't? > Where's the boundary? > > For an example of the type of headaches, does DRI driver code (stuff that > ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then > what about gallium/state_trackers/dri? What about mesa/drivers/dri/common? > Maybe? I guess it depends on what it does and how much sense it makes to share it higher than the gallium level. > I don't have a full picture of all this code so it's hard for me to say, > but I really hope your changes will lead to a clearer picture overall :) > Dylan and I talked about it quite a bit off-line so I have a few opinions. :) In particular, here's what I envison: src/wsi/gbm src/wsi/egl src/wsi/wayland-drm src/wsi/dri3 (currently src/loader) src/wsi/glx src/wsi/vulkan (currently src/vulkan/wsi) src/wsi/hgl So, basically, it's window system integration layers and the helpers we want to share among them. I wasn't envisioning it containing anything to handle the DRI layer though I suppose it probably could. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] create src/wsi
On 23 October 2017 at 16:03, Jason Ekstrand wrote: > On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle wrote: >> >> On 21.10.2017 03:00, Dylan Baker wrote: >>> >>> This very short series creates a new src/wsi folder, and moves >>> wayland-drm into >>> it. Basically wsi stuff is scattered about, and is needed by multiple >>> components >>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan >>> wayland-wsi. >>> >>> I think there's more that could be moved into wsi, we could move EGL, >>> GBM, and >>> GLX, and vulkan/wsi, for example. >> >> >> The general thrust sounds good to me. >> >> Is there a clean model for what should go into src/wsi and what shouldn't? >> Where's the boundary? >> >> For an example of the type of headaches, does DRI driver code (stuff that >> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then >> what about gallium/state_trackers/dri? What about mesa/drivers/dri/common? > > > Maybe? I guess it depends on what it does and how much sense it makes to > share it higher than the gallium level. > >> >> I don't have a full picture of all this code so it's hard for me to say, >> but I really hope your changes will lead to a clearer picture overall :) > > > Dylan and I talked about it quite a bit off-line so I have a few opinions. > :) In particular, here's what I envison: > > src/wsi/gbm > src/wsi/egl > src/wsi/wayland-drm > src/wsi/dri3 (currently src/loader) > src/wsi/glx > src/wsi/vulkan (currently src/vulkan/wsi) > src/wsi/hgl > Idea is mostly ok, but there's a bit of a snafu: Things are not as clean cut/split as per above. Here are some of the current inter-dependencies. src/loader - loader.c WSI agnostic DRI loader code. src/loader - loader_dri3.c X11 DRI3 code. gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl egl - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one of the AMD devs to attempt this) vulkan - has completely different wayland-drm/X11 dri3 code. One could be able to flatten and use uniform interface across the board. I would be weary as above code gets limited testing with piglit/CTS/dEQP. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] egl/wayland: Support for KHR_partial_update
On 23 October 2017 at 11:50, Harish Krupo wrote: > This passes 33/37 deqp tests related to partial_update, 4 are not > supported. Tests not supported: > dEQP-EGL.functional.negative_partial_update.not_postable_surface > dEQP-EGL.functional.negative_partial_update.not_current_surface > dEQP-EGL.functional.negative_partial_update.buffer_preserved > dEQP-EGL.functional.negative_partial_update.not_current_surface2 > Reason: No matching egl config found. > > v2: Remove unnecessary return statement. Keep function names > consistent. (Emil Velikov) > Add not supported list to commit message. (Eric Engestrom) > > v3: Remove explicit with_damage variable. (Eric Engestrom) > Did you send the wrong version by any chance? The summary does not reflect the actual changes. Why did you rework try_damage_buffer into dri2_wl_set_damage_region? It seems harder to follow over the previous patches. > @@ -928,7 +944,8 @@ dri2_wl_query_buffer_age(_EGLDriver *drv, > static EGLBoolean > dri2_wl_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw) > { > - return dri2_wl_swap_buffers_with_damage(drv, disp, draw, NULL, 0); > + return dri2_wl_swap_buffers_with_damage(drv, disp, draw, > + NULL, 0); Unrelated noop change. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] create src/wsi
On Mon, Oct 23, 2017 at 8:16 AM, Emil Velikov wrote: > On 23 October 2017 at 16:03, Jason Ekstrand wrote: > > On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle > wrote: > >> > >> On 21.10.2017 03:00, Dylan Baker wrote: > >>> > >>> This very short series creates a new src/wsi folder, and moves > >>> wayland-drm into > >>> it. Basically wsi stuff is scattered about, and is needed by multiple > >>> components > >>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan > >>> wayland-wsi. > >>> > >>> I think there's more that could be moved into wsi, we could move EGL, > >>> GBM, and > >>> GLX, and vulkan/wsi, for example. > >> > >> > >> The general thrust sounds good to me. > >> > >> Is there a clean model for what should go into src/wsi and what > shouldn't? > >> Where's the boundary? > >> > >> For an example of the type of headaches, does DRI driver code (stuff > that > >> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, > then > >> what about gallium/state_trackers/dri? What about > mesa/drivers/dri/common? > > > > > > Maybe? I guess it depends on what it does and how much sense it makes to > > share it higher than the gallium level. > > > >> > >> I don't have a full picture of all this code so it's hard for me to say, > >> but I really hope your changes will lead to a clearer picture overall :) > > > > > > Dylan and I talked about it quite a bit off-line so I have a few > opinions. > > :) In particular, here's what I envison: > > > > src/wsi/gbm > > src/wsi/egl > > src/wsi/wayland-drm > > src/wsi/dri3 (currently src/loader) > > src/wsi/glx > > src/wsi/vulkan (currently src/vulkan/wsi) > > src/wsi/hgl > > > Idea is mostly ok, but there's a bit of a snafu: > > Things are not as clean cut/split as per above. Here are some of the > current inter-dependencies. > > src/loader - loader.c WSI agnostic DRI loader code. > src/loader - loader_dri3.c X11 DRI3 code. > Ok, so maybe src/wsi/dri3 isn't quite the right name. Maybe we need a src/wsi/dri-loader. > gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), > egl > egl - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one > of the AMD devs to attempt this) > vulkan - has completely different wayland-drm/X11 dri3 code. > It does share some code with EGL which is implemented terribly at the moment. In particular, we need to share all of the Wayland XML and generated headers and protocol source files. If we ever did a server-side Wayland Vulkan extension (which I think is probably unlikely), we could possibly re-use the rest of wayland-drm. This was part of the motivation for doing this rework. > One could be able to flatten and use uniform interface across the > board. I'm not sure what you mean by that. I don't think it's worth it to try and make a common core codebase to share between GLX, EGL, and Vulkan WSI. Vulkan is enough different, that I think the current plan of re-rolling the WSI bits almost entirely is the best plan. > I would be weary as above code gets limited testing with > piglit/CTS/dEQP. > Agreed! However, what Dylan is trying to do doesn't involve changing anything more than some include directories so it should be reasonably safe. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get
Hi Emil, On 28 September 2017 at 13:36, Emil Velikov wrote: > On 20 September 2017 at 15:06, Daniel Stone wrote: >> On 19 September 2017 at 11:25, Emil Velikov wrote: >>> It looks a bit icky and my Wayland knowledge is limited to actually review >>> it. >>> >>> I still think that we're trying to do different things - me simplify >>> things, while you're focusing on fixing a bug. >> >> I like the idea of the simplification, but it's just that a) it can't >> actually be simplified that far, and b) whilst we still rely on >> consistent resolution of wl_buffer_interface, your proposed change may >> actually _introduce_ a bug. > > Right, I did not see that one. Can you share your train of thought? Happily! When a compositor creates a client buffer, the request is dispatched by libwayland-server.so into libEGL.so (libEGL explicitly links libwayland-server). This lands in src/egl/wayland/wayland-drm/wayland-drm.c's create_buffer(), which calls wl_resource_create() with 'wl_buffer_interface'. Since libEGL.so is explicitly linked against both libwayland-client and libwayland-server, and both of those DSOs provide a resolution of wl_buffer_interface, resource->interface could be libwayland-server.so::wl_buffer_interface, or libwayland-client.so::wl_buffer_interface. When a compositor wants to import a buffer into GBM, it calls gbm_bo_import(), which will call wl_drm_buffer_get(). wl_drm_buffer_get will test (resource->interface == &wl_buffer_interface). Previously, both create_buffer() and wl_drm_buffer_get() at least came from the same compilation unit, but now they are built and linked separately. This seems to make an existing problem (ambiguity of 'wl_buffer_interface') worse (symbol resolution now performed in separate compilation units). I don't really see a solution to this, apart from no longer relying on having a single canonical resolution of wl_buffer_interface. The above patch implements that, by removing the interface-address-equal test and replacing it with the destroy-listener test. The patch I provided is equally valid both with and without your series. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 1/4] i965/gen10: Implement WaSampleOffsetIZ workaround
Ping. Patches 2-4 in this series are still waiting for review. Anyone interested? Thanks! On Fri, Oct 13, 2017 at 3:35 PM, Rafael Antognolli wrote: > Hi Anuj, sorry that I missed this patch. Please see below. > > On Fri, Oct 06, 2017 at 04:30:47PM -0700, Anuj Phogat wrote: >> There are few other (duplicate) workarounds which have similar >> recommendations: >> WaFlushHangWhenNonPipelineStateAndMarkerStalled >> WaCSStallBefore3DSamplePattern >> WaPipeControlBefore3DStateSamplePattern >> >> WaPipeControlBefore3DStateSamplePattern has some extra recommendations if >> driver is using mid batch context restore. Ignoring it for now because We're >> not doing mid-batch context restore in Mesa. >> >> Cc: mesa-sta...@lists.freedesktop.org >> Cc: Jason Ekstrand >> Cc: Rafael Antognolli >> Signed-off-by: Anuj Phogat >> --- >> src/mesa/drivers/dri/i965/brw_context.h| 2 + >> src/mesa/drivers/dri/i965/brw_defines.h| 1 + >> src/mesa/drivers/dri/i965/brw_pipe_control.c | 50 >> ++ >> src/mesa/drivers/dri/i965/gen8_multisample_state.c | 8 >> 4 files changed, 61 insertions(+) >> >> diff --git a/src/mesa/drivers/dri/i965/brw_context.h >> b/src/mesa/drivers/dri/i965/brw_context.h >> index 92fc16de13..f0e8d562e9 100644 >> --- a/src/mesa/drivers/dri/i965/brw_context.h >> +++ b/src/mesa/drivers/dri/i965/brw_context.h >> @@ -1647,6 +1647,8 @@ void brw_emit_post_sync_nonzero_flush(struct >> brw_context *brw); >> void brw_emit_depth_stall_flushes(struct brw_context *brw); >> void gen7_emit_vs_workaround_flush(struct brw_context *brw); >> void gen7_emit_cs_stall_flush(struct brw_context *brw); >> +void gen10_emit_wa_cs_stall_flush(struct brw_context *brw); >> +void gen10_emit_wa_lri_to_cache_mode_zero(struct brw_context *brw); >> >> /* brw_queryformat.c */ >> void brw_query_internal_format(struct gl_context *ctx, GLenum target, >> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h >> b/src/mesa/drivers/dri/i965/brw_defines.h >> index 4abb790612..270cdf29db 100644 >> --- a/src/mesa/drivers/dri/i965/brw_defines.h >> +++ b/src/mesa/drivers/dri/i965/brw_defines.h >> @@ -1609,6 +1609,7 @@ enum brw_pixel_shader_coverage_mask_mode { >> #define GEN7_GPGPU_DISPATCHDIMY 0x2504 >> #define GEN7_GPGPU_DISPATCHDIMZ 0x2508 >> >> +#define GEN7_CACHE_MODE_0 0x7000 >> #define GEN7_CACHE_MODE_1 0x7004 >> # define GEN9_FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4) >> # define GEN8_HIZ_NP_PMA_FIX_ENABLE(1 << 11) >> diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c >> b/src/mesa/drivers/dri/i965/brw_pipe_control.c >> index 460b8f73b6..156f5c25ec 100644 >> --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c >> +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c >> @@ -278,6 +278,56 @@ gen7_emit_cs_stall_flush(struct brw_context *brw) >> brw->workaround_bo, 0, 0); >> } >> >> +static void >> +brw_flush_gpu_caches(struct brw_context *brw) { >> + brw_emit_pipe_control_flush(brw, >> + PIPE_CONTROL_CACHE_FLUSH_BITS | >> + PIPE_CONTROL_CACHE_INVALIDATE_BITS); >> +} > > This function is only calling another function without any extra logic, so I > would just call brw_emit_pipe_control_flush() and remove this declaration. But > that's just cosmetic. > > With or without this change, this patch correctly implements the workaround > imho, so it is > > Reviewed-by: Rafael Antognolli > >> +/** >> + * From Gen10 Workarounds page in h/w specs: >> + * WaSampleOffsetIZ: >> + * Prior to the 3DSTATE_SAMPLE_PATTERN driver must ensure there are no >> + * markers in the pipeline by programming a PIPE_CONTROL with stall. >> + */ >> +void >> +gen10_emit_wa_cs_stall_flush(struct brw_context *brw) >> +{ >> + const struct gen_device_info *devinfo = &brw->screen->devinfo; >> + assert(devinfo->gen == 10); >> + brw_emit_pipe_control_flush(brw, >> + PIPE_CONTROL_CS_STALL | >> + PIPE_CONTROL_STALL_AT_SCOREBOARD); >> +} >> + >> +/** >> + * From Gen10 Workarounds page in h/w specs: >> + * WaSampleOffsetIZ: >> + * When 3DSTATE_SAMPLE_PATTERN is programmed, driver must then issue an >> + * MI_LOAD_REGISTER_IMM command to an offset between 0x7000 and 0x7FFF(SVL) >> + * after the command to ensure the state has been delivered prior to any >> + * command causing a marker in the pipeline. >> + */ >> +void >> +gen10_emit_wa_lri_to_cache_mode_zero(struct brw_context *brw) >> +{ >> + const struct gen_device_info *devinfo = &brw->screen->devinfo; >> + assert(devinfo->gen == 10); >> + >> + /* Before changing the value of CACHE_MODE_0 register, GFX pipeline must >> +* be idle; i.e., full flush is required. >> +*/ >> + brw_flush_gpu_caches(brw); >> + >> + /* Write to CACHE_MODE_0 (0x7000) */ >> + BEGIN_BATCH(3); >> + OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2)); >> + OUT_BATCH(GEN7_CAC
[Mesa-dev] [PATCH] Haiku: convert to autotools
* configure.ac: -pthread is not available on Haiku. Haiku doesn't require --enable-dri build hgl on Haiku * egl/Makefile.am: define backendfiles for Haiku * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and targets/haiku-softpipe on Haiku. * src/gallium/targets/haiku-softpipe: add Makefile.am * src/gallium/state_trackers/hgl: add Makefile.am * winsys/sw/hgl: add Makefile.am * src/hgl/Makefile.am: add Makefile.am --- configure.ac | 30 +- src/Makefile.am| 4 ++ src/egl/Makefile.am| 20 ++- src/gallium/Makefile.am| 9 ++- src/gallium/state_trackers/hgl/Makefile.am | 39 src/gallium/state_trackers/hgl/Makefile.sources| 3 + src/gallium/targets/haiku-softpipe/Makefile.am | 69 ++ .../targets/haiku-softpipe/SoftwareRenderer.cpp| 2 + src/gallium/winsys/sw/hgl/Makefile.am | 34 +++ src/gallium/winsys/sw/hgl/Makefile.sources | 3 + src/hgl/Makefile.am| 50 src/hgl/Makefile.sources | 8 +++ src/hgl/gl.pc.in | 11 13 files changed, 277 insertions(+), 5 deletions(-) create mode 100644 src/gallium/state_trackers/hgl/Makefile.am create mode 100644 src/gallium/state_trackers/hgl/Makefile.sources create mode 100644 src/gallium/targets/haiku-softpipe/Makefile.am create mode 100644 src/gallium/winsys/sw/hgl/Makefile.am create mode 100644 src/gallium/winsys/sw/hgl/Makefile.sources create mode 100644 src/hgl/Makefile.am create mode 100644 src/hgl/Makefile.sources create mode 100644 src/hgl/gl.pc.in diff --git a/configure.ac b/configure.ac index add3830..1d8efc5 100644 --- a/configure.ac +++ b/configure.ac @@ -272,6 +272,9 @@ case "$host_os" in *-android*) android=yes ;; +*haiku) +haiku=yes +;; linux*|*-gnu*|gnu*|cygwin*) DEFINES="$DEFINES -D_GNU_SOURCE" ;; @@ -281,6 +284,7 @@ solaris*) esac AM_CONDITIONAL(HAVE_ANDROID, test "x$android" = xyes) +AM_CONDITIONAL(HAVE_HAIKU, test "x$haiku" = xyes) dnl dnl Check compiler flags @@ -863,12 +867,18 @@ dnl According to the manual when using pthreads, one should add -pthread to dnl both compile and link-time arguments. dnl In practise that should be sufficient for all platforms, since any dnl platforms build with GCC and Clang support the flag. -PTHREAD_LIBS="$PTHREAD_LIBS -pthread" +case "$host_os" in +haiku*) +;; +* ) +PTHREAD_LIBS="$PTHREAD_LIBS -pthread" +;; +esac dnl pthread-stubs is mandatory on BSD platforms, due to the nature of the dnl project. Even then there's a notable issue as described in the project README case "$host_os" in -linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu*) +linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu* | haiku*) pthread_stubs_possible="no" ;; * ) @@ -1518,7 +1528,12 @@ require_dri_shared_libs_and_glapi() { if test "x$enable_dri" != xyes; then # There is only a single backend which won't be build/used otherwise. # XXX: Revisit this as the egl/haiku is a thing. -AC_MSG_ERROR([$1 requires --enable-dri]) +case "$host_os" in +haiku*) +;; +*) +AC_MSG_ERROR([$1 requires --enable-dri]) ;; + esac fi if test "x$enable_shared_glapi" != xyes; then @@ -1748,6 +1763,10 @@ for plat in $platforms; do DEFINES="$DEFINES -DHAVE_ANDROID_PLATFORM" ;; +haiku) +DEFINES="$DEFINES -DHAVE_HAIKU_PLATFORM" +;; + *) AC_MSG_ERROR([platform '$plat' does not exist]) ;; @@ -2891,6 +2910,7 @@ AC_CONFIG_FILES([Makefile src/gallium/state_trackers/clover/Makefile src/gallium/state_trackers/dri/Makefile src/gallium/state_trackers/glx/xlib/Makefile + src/gallium/state_trackers/hgl/Makefile src/gallium/state_trackers/nine/Makefile src/gallium/state_trackers/omx_bellagio/Makefile src/gallium/state_trackers/osmesa/Makefile @@ -2901,6 +2921,7 @@ AC_CONFIG_FILES([Makefile src/gallium/targets/d3dadapter9/Makefile src/gallium/targets/d3dadapter9/d3d.pc src/gallium/targets/dri/Makefile + src/gallium/targets/haiku-softpipe/Makefile src/gallium/targets/libgl-xlib/Makefile src/gallium/targets/omx-bellagio/Makefile src/gallium/targets/opencl/Makefile @@ -2925,6 +2946,7 @@ AC_CONFIG_FILES([Makefile src/gallium/winsys/amdgpu/drm/Makefile src/gallium/winsys/svga/drm/Makefile src/gallium/winsys/sw/dri/Makefile + src/gallium/winsys/sw/hgl/Makefile
Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.0-rc1
On 23.10.2017 15:46, Emil Velikov wrote: 1 Nicolai Hähnle 3 Nicolai Hähnle 270 Nicolai Hähnle :( I blame Ubuntu 17.04. Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] create src/wsi
On 23.10.2017 17:16, Emil Velikov wrote: On 23 October 2017 at 16:03, Jason Ekstrand wrote: On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle wrote: On 21.10.2017 03:00, Dylan Baker wrote: This very short series creates a new src/wsi folder, and moves wayland-drm into it. Basically wsi stuff is scattered about, and is needed by multiple components within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan wayland-wsi. I think there's more that could be moved into wsi, we could move EGL, GBM, and GLX, and vulkan/wsi, for example. The general thrust sounds good to me. Is there a clean model for what should go into src/wsi and what shouldn't? Where's the boundary? For an example of the type of headaches, does DRI driver code (stuff that ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then what about gallium/state_trackers/dri? What about mesa/drivers/dri/common? Maybe? I guess it depends on what it does and how much sense it makes to share it higher than the gallium level. I don't have a full picture of all this code so it's hard for me to say, but I really hope your changes will lead to a clearer picture overall :) Dylan and I talked about it quite a bit off-line so I have a few opinions. :) In particular, here's what I envison: src/wsi/gbm src/wsi/egl src/wsi/wayland-drm src/wsi/dri3 (currently src/loader) src/wsi/glx src/wsi/vulkan (currently src/vulkan/wsi) src/wsi/hgl Idea is mostly ok, but there's a bit of a snafu: Things are not as clean cut/split as per above. Here are some of the current inter-dependencies. src/loader - loader.c WSI agnostic DRI loader code. src/loader - loader_dri3.c X11 DRI3 code. gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl egl - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one of the AMD devs to attempt this) Which part / what do you mean? I'm perfectly fine with keeping the state_tracker/dri/ and dri/common bits where they are, I just wanted to get some clarification :) Cheers, Nicolai vulkan - has completely different wayland-drm/X11 dri3 code. One could be able to flatten and use uniform interface across the board. I would be weary as above code gets limited testing with piglit/CTS/dEQP. -Emil -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 1/2] glsl: allow any l-value of an input variable as interpolant in interpolateAt*
Ping? On 10.10.2017 14:09, Nicolai Hähnle wrote: From: Nicolai Hähnle The intended rule has been clarified in GLSL 4.60, Section 8.13.2 (Interpolation Functions): "For all of the interpolation functions, interpolant must be an l-value from an in declaration; this can include a variable, a block or structure member, an array element, or some combination of these. Component selection operators (e.g., .xy) may be used when specifying interpolant." For members of interface blocks, var->data.must_be_shader_input must be determined on-the-fly after lowering interface blocks, since we don't want to disable varying packing for an entire block just because one input in it is used in interpolateAt*. v2: keep setting must_be_shader_input in ast_function (Ian) v3: follow the relaxed rule of GLSL 4.60 v4: only apply the relaxed rules to desktop GL (the ES WG decided that the relaxed rules may apply in a future version but not retroactively; see also dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at_centroid.negative.*) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101378 Reviewed-by: Ian Romanick (v1) --- src/compiler/glsl/ast_function.cpp | 19 ++- src/compiler/glsl/lower_named_interface_blocks.cpp | 18 ++ 2 files changed, 32 insertions(+), 5 deletions(-) diff --git a/src/compiler/glsl/ast_function.cpp b/src/compiler/glsl/ast_function.cpp index 46a61e46fd5..d1596c272e6 100644 --- a/src/compiler/glsl/ast_function.cpp +++ b/src/compiler/glsl/ast_function.cpp @@ -220,33 +220,42 @@ verify_parameter_modes(_mesa_glsl_parse_state *state, if (val->ir_type == ir_type_swizzle) { if (!state->is_version(440, 0)) { _mesa_glsl_error(&loc, state, "parameter `%s` must not be swizzled", formal->name); return false; } val = ((ir_swizzle *)val)->val; } - while (val->ir_type == ir_type_dereference_array) { -val = ((ir_dereference_array *)val)->array; + for (;;) { +if (val->ir_type == ir_type_dereference_array) { + val = ((ir_dereference_array *)val)->array; +} else if (val->ir_type == ir_type_dereference_record && + !state->es_shader) { + val = ((ir_dereference_record *)val)->record; +} else + break; } - if (!val->as_dereference_variable() || - val->variable_referenced()->data.mode != ir_var_shader_in) { + ir_variable *var = NULL; + if (const ir_dereference_variable *deref_var = val->as_dereference_variable()) +var = deref_var->variable_referenced(); + + if (!var || var->data.mode != ir_var_shader_in) { _mesa_glsl_error(&loc, state, "parameter `%s` must be a shader input", formal->name); return false; } - val->variable_referenced()->data.must_be_shader_input = 1; + var->data.must_be_shader_input = 1; } /* Verify that 'out' and 'inout' actual parameters are lvalues. */ if (formal->data.mode == ir_var_function_out || formal->data.mode == ir_var_function_inout) { const char *mode = NULL; switch (formal->data.mode) { case ir_var_function_out: mode = "out"; break; case ir_var_function_inout: mode = "inout"; break; default:assert(false); break; diff --git a/src/compiler/glsl/lower_named_interface_blocks.cpp b/src/compiler/glsl/lower_named_interface_blocks.cpp index 064694128bf..136352a131b 100644 --- a/src/compiler/glsl/lower_named_interface_blocks.cpp +++ b/src/compiler/glsl/lower_named_interface_blocks.cpp @@ -108,20 +108,21 @@ public: flatten_named_interface_blocks_declarations(void *mem_ctx) : mem_ctx(mem_ctx), interface_namespace(NULL) { } void run(exec_list *instructions); virtual ir_visitor_status visit_leave(ir_assignment *); + virtual ir_visitor_status visit_leave(ir_expression *); virtual void handle_rvalue(ir_rvalue **rvalue); }; } /* anonymous namespace */ void flatten_named_interface_blocks_declarations::run(exec_list *instructions) { interface_namespace = _mesa_hash_table_create(NULL, _mesa_key_hash_string, _mesa_key_string_equal); @@ -231,20 +232,37 @@ flatten_named_interface_blocks_declarations::visit_leave(ir_assignment *ir) } ir_variable *lhs_var = lhs_rec_tmp->variable_referenced(); if (lhs_var) { lhs_var->data.assigned = 1; } } return rvalue_visit(ir); } +ir_visitor_status +flatten_named_inter
Re: [Mesa-dev] [PATCH 4/4] radeonsi: postponed KILL isn't postponed anymore, but maintains WQM
I found my peace with the new intrinsic for now. This series is Reviewed-by: Nicolai Hähnle On 14.10.2017 02:58, Marek Olšák wrote: From: Marek Olšák This restores performance for the drirc workaround, i.e. KILL_IF does: visible = src0 >= 0; kill_flag &= visible; // accumulate kills amdgcn_kill(wqm_vote(visible)); // kill fully dead quads only And all helper pixels are killed at the end of the shader: amdgcn_kill(kill_flag); --- src/amd/common/ac_llvm_build.c| 7 +++ src/amd/common/ac_llvm_build.h| 1 + src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 6 ++ 3 files changed, 14 insertions(+) diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c index 0550f80..2f8f59f 100644 --- a/src/amd/common/ac_llvm_build.c +++ b/src/amd/common/ac_llvm_build.c @@ -1398,20 +1398,27 @@ LLVMValueRef ac_build_cvt_pkrtz_f16(struct ac_llvm_context *ctx, v2f16, args, 2, AC_FUNC_ATTR_READNONE); return LLVMBuildBitCast(ctx->builder, res, ctx->i32, ""); } return ac_build_intrinsic(ctx, "llvm.SI.packf16", ctx->i32, args, 2, AC_FUNC_ATTR_READNONE | AC_FUNC_ATTR_LEGACY); } +LLVMValueRef ac_build_wqm_vote(struct ac_llvm_context *ctx, LLVMValueRef i1) +{ + assert(HAVE_LLVM >= 0x0600); + return ac_build_intrinsic(ctx, "llvm.amdgcn.wqm.vote", ctx->i1, + &i1, 1, AC_FUNC_ATTR_READNONE); +} + void ac_build_kill_if_false(struct ac_llvm_context *ctx, LLVMValueRef i1) { if (HAVE_LLVM >= 0x0600) { ac_build_intrinsic(ctx, "llvm.amdgcn.kill", ctx->voidt, &i1, 1, 0); return; } LLVMValueRef value = LLVMBuildSelect(ctx->builder, i1, LLVMConstReal(ctx->f32, 1), diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h index b721782..088a986 100644 --- a/src/amd/common/ac_llvm_build.h +++ b/src/amd/common/ac_llvm_build.h @@ -258,20 +258,21 @@ struct ac_image_args { LLVMValueRef addr; unsigned dmask; bool unorm; bool da; }; LLVMValueRef ac_build_image_opcode(struct ac_llvm_context *ctx, struct ac_image_args *a); LLVMValueRef ac_build_cvt_pkrtz_f16(struct ac_llvm_context *ctx, LLVMValueRef args[2]); +LLVMValueRef ac_build_wqm_vote(struct ac_llvm_context *ctx, LLVMValueRef i1); void ac_build_kill_if_false(struct ac_llvm_context *ctx, LLVMValueRef i1); LLVMValueRef ac_build_bfe(struct ac_llvm_context *ctx, LLVMValueRef input, LLVMValueRef offset, LLVMValueRef width, bool is_signed); void ac_get_image_intr_name(const char *base_name, LLVMTypeRef data_type, LLVMTypeRef coords_type, LLVMTypeRef rsrc_type, char *out_name, unsigned out_len); diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c index 283a889..913b6c3 100644 --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c @@ -62,20 +62,26 @@ static void kil_emit(const struct lp_build_tgsi_action *action, LLVMValueRef visible; if (emit_data->inst->Instruction.Opcode == TGSI_OPCODE_KILL_IF) { visible = emit_data->args[0]; } else { assert(emit_data->inst->Instruction.Opcode == TGSI_OPCODE_KILL); visible = LLVMConstInt(ctx->i1, false, 0); } if (ctx->shader->selector->force_correct_derivs_after_kill) { + /* LLVM 6.0 can kill immediately while maintaining WQM. */ + if (HAVE_LLVM >= 0x0600) { + ac_build_kill_if_false(&ctx->ac, + ac_build_wqm_vote(&ctx->ac, visible)); + } + LLVMValueRef mask = LLVMBuildLoad(builder, ctx->postponed_kill, ""); mask = LLVMBuildAnd(builder, mask, visible, ""); LLVMBuildStore(builder, mask, ctx->postponed_kill); return; } ac_build_kill_if_false(&ctx->ac, visible); } static void emit_icmp(const struct lp_build_tgsi_action *action, -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] ac: Silence a compiler warning about results[0].
Both patches: Reviewed-by: Nicolai Hähnle On 17.10.2017 22:50, Eric Anholt wrote: We know that num_components will be > 0, but it doesn't. --- src/amd/common/ac_nir_to_llvm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 3ba3ebf051e2..07fa3fdf84b5 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -2390,6 +2390,7 @@ static LLVMValueRef visit_load_buffer(struct ac_nir_context *ctx, } + assume(results[0]); LLVMValueRef ret = results[0]; if (num_components > 4 || num_components == 3) { LLVMValueRef masks[] = { -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] gallium/util: don't call close() on Windows in u_tests.c
For the series: Reviewed-by: Nicolai Hähnle On 17.10.2017 23:17, Brian Paul wrote: --- src/gallium/auxiliary/util/u_tests.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/auxiliary/util/u_tests.c b/src/gallium/auxiliary/util/u_tests.c index 3cc79af..2548b46 100644 --- a/src/gallium/auxiliary/util/u_tests.c +++ b/src/gallium/auxiliary/util/u_tests.c @@ -567,6 +567,7 @@ test_sync_file_fences(struct pipe_context *ctx) pass = pass && screen->fence_finish(screen, NULL, final_fence, 0); /* Cleanup. */ +#ifndef PIPE_OS_WINDOWS if (buf_fd >= 0) close(buf_fd); if (tex_fd >= 0) @@ -575,6 +576,7 @@ test_sync_file_fences(struct pipe_context *ctx) close(merged_fd); if (final_fd >= 0) close(final_fd); +#endif screen->fence_reference(screen, &buf_fence, NULL); screen->fence_reference(screen, &tex_fence, NULL); -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] glsl/parser: Track built-in types using the glsl_type directly
On 18.10.2017 16:39, Ian Romanick wrote: On 10/17/2017 12:54 PM, Nicolai Hähnle wrote: On 17.10.2017 20:14, Ian Romanick wrote: From: Ian Romanick text data bss dec hex filename 8255243 268856 294072 8818171 868dfb 32-bit i965_dri.so before 8255291 268856 294072 8818219 868e2b 32-bit i965_dri.so after 7815195 345592 420592 8581379 82f103 64-bit i965_dri.so before 7815339 345592 420592 8581523 82f193 64-bit i965_dri.so after How does this change lead to such a big reduction, and shouldn't the lexer changes be in a separate patch? Without the lexer changes, tests/glslparsertest/glsl2/tex_rect-02.frag fails. Before this change, the parser would determine that sampler2DRect is not a valid type because the call to state->symbols->get_type() in ast_type_specifier::glsl_type() would return NULL. Since ast_type_specifier::glsl_type() is now going to return the glsl_type pointer that it received from the lexer, it doesn't have an opportunity to generate an error. It took me a bit to remember why I did it like this, so, at the very least, I will add that text to the commit message. Seems reasonable, thanks for the explanation. With the explanation added, this patch has my R-b as well. Cheers, Nicolai Cheers, Nicolai Signed-off-by: Ian Romanick --- src/compiler/glsl/ast.h | 13 +++-- src/compiler/glsl/ast_to_hir.cpp | 4 +++- src/compiler/glsl/glsl_lexer.ll | 21 + src/compiler/glsl/glsl_parser.yy | 2 +- 4 files changed, 28 insertions(+), 12 deletions(-) diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h index 1be86ac..eee2248 100644 --- a/src/compiler/glsl/ast.h +++ b/src/compiler/glsl/ast.h @@ -27,6 +27,7 @@ #include "list.h" #include "glsl_parser_extras.h" +#include "compiler/glsl_types.h" struct _mesa_glsl_parse_state; @@ -853,7 +854,7 @@ class ast_type_specifier : public ast_node { public: /** Construct a type specifier from a type name */ ast_type_specifier(const char *name) - : type_name(name), structure(NULL), array_specifier(NULL), + : type(NULL), type_name(name), structure(NULL), array_specifier(NULL), default_precision(ast_precision_none) { /* empty */ @@ -861,12 +862,19 @@ public: /** Construct a type specifier from a structure definition */ ast_type_specifier(ast_struct_specifier *s) - : type_name(s->name), structure(s), array_specifier(NULL), + : type(NULL), type_name(s->name), structure(s), array_specifier(NULL), default_precision(ast_precision_none) { /* empty */ } + ast_type_specifier(const glsl_type *t) + : type(t), type_name(t->name), structure(NULL), array_specifier(NULL), + default_precision(ast_precision_none) + { + /* empty */ + } + const struct glsl_type *glsl_type(const char **name, struct _mesa_glsl_parse_state *state) const; @@ -875,6 +883,7 @@ public: ir_rvalue *hir(exec_list *, struct _mesa_glsl_parse_state *); + const struct glsl_type *type; const char *type_name; ast_struct_specifier *structure; diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp index d7c8b47..6090ee9 100644 --- a/src/compiler/glsl/ast_to_hir.cpp +++ b/src/compiler/glsl/ast_to_hir.cpp @@ -2361,7 +2361,9 @@ ast_type_specifier::glsl_type(const char **name, { const struct glsl_type *type; - if (structure) + if (this->type != NULL) + type = this->type; + else if (structure) type = structure->type; else type = state->symbols->get_type(this->type_name); diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll index 5dad6ee..d2278ba 100644 --- a/src/compiler/glsl/glsl_lexer.ll +++ b/src/compiler/glsl/glsl_lexer.ll @@ -132,18 +132,23 @@ static int classify_identifier(struct _mesa_glsl_parse_state *, const char *, /** * Like DEPRECATED_ES_KEYWORD, but for types */ -#define DEPRECATED_ES_TYPE(gtype) \ +#define DEPRECATED_ES_TYPE_WITH_ALT(alt_expr, gtype) \ do { \ if (yyextra->is_version(0, 300)) { \ - _mesa_glsl_error(yylloc, yyextra, \ - "illegal use of reserved word `%s'", yytext); \ - return ERROR_TOK; \ - } else { \ - yylval->type = gtype; \ + _mesa_glsl_error(yylloc, yyextra, \ + "illegal use of reserved word `%s'", yytext); \ + return ERROR_TOK; \ + } else if (alt_expr) { \ + yylval->type = gtype; \ return BASIC_TYPE_TOK; \ +
Re: [Mesa-dev] create src/wsi
On 23 October 2017 at 17:05, Nicolai Hähnle wrote: > On 23.10.2017 17:16, Emil Velikov wrote: >> >> On 23 October 2017 at 16:03, Jason Ekstrand wrote: >>> >>> On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle >>> wrote: On 21.10.2017 03:00, Dylan Baker wrote: > > > This very short series creates a new src/wsi folder, and moves > wayland-drm into > it. Basically wsi stuff is scattered about, and is needed by multiple > components > within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan > wayland-wsi. > > I think there's more that could be moved into wsi, we could move EGL, > GBM, and > GLX, and vulkan/wsi, for example. The general thrust sounds good to me. Is there a clean model for what should go into src/wsi and what shouldn't? Where's the boundary? For an example of the type of headaches, does DRI driver code (stuff that ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then what about gallium/state_trackers/dri? What about mesa/drivers/dri/common? >>> >>> >>> >>> Maybe? I guess it depends on what it does and how much sense it makes to >>> share it higher than the gallium level. >>> I don't have a full picture of all this code so it's hard for me to say, but I really hope your changes will lead to a clearer picture overall :) >>> >>> >>> >>> Dylan and I talked about it quite a bit off-line so I have a few >>> opinions. >>> :) In particular, here's what I envison: >>> >>> src/wsi/gbm >>> src/wsi/egl >>> src/wsi/wayland-drm >>> src/wsi/dri3 (currently src/loader) >>> src/wsi/glx >>> src/wsi/vulkan (currently src/vulkan/wsi) >>> src/wsi/hgl >>> >> Idea is mostly ok, but there's a bit of a snafu: >> >> Things are not as clean cut/split as per above. Here are some of the >> current inter-dependencies. >> >> src/loader - loader.c WSI agnostic DRI loader code. >> src/loader - loader_dri3.c X11 DRI3 code. >> >> gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), >> egl For the gbm <> wayland-drm bits https://lists.freedesktop.org/archives/mesa-dev/2017-September/168952.html Although Daniel has some concerns https://lists.freedesktop.org/archives/mesa-dev/2017-October/173915.html >> egl - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one >> of the AMD devs to attempt this) The egl <> gbm bits https://lists.freedesktop.org/archives/mesa-dev/2017-October/173088.html > > > Which part / what do you mean? > > I'm perfectly fine with keeping the state_tracker/dri/ and dri/common bits > where they are, I just wanted to get some clarification :) > Fwiw - if anyone can suggest a reasonable way to rework/fold/split I'm all ears. Otherwise I fear that just moving things won't help much. Things are quite interconnected. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get
On 23 October 2017 at 16:41, Daniel Stone wrote: > Hi Emil, > > On 28 September 2017 at 13:36, Emil Velikov wrote: >> On 20 September 2017 at 15:06, Daniel Stone wrote: >>> On 19 September 2017 at 11:25, Emil Velikov >>> wrote: It looks a bit icky and my Wayland knowledge is limited to actually review it. I still think that we're trying to do different things - me simplify things, while you're focusing on fixing a bug. >>> >>> I like the idea of the simplification, but it's just that a) it can't >>> actually be simplified that far, and b) whilst we still rely on >>> consistent resolution of wl_buffer_interface, your proposed change may >>> actually _introduce_ a bug. >> >> Right, I did not see that one. Can you share your train of thought? > > Happily! > > When a compositor creates a client buffer, the request is dispatched > by libwayland-server.so into libEGL.so (libEGL explicitly links > libwayland-server). This lands in > src/egl/wayland/wayland-drm/wayland-drm.c's create_buffer(), which > calls wl_resource_create() with 'wl_buffer_interface'. Since libEGL.so > is explicitly linked against both libwayland-client and > libwayland-server, and both of those DSOs provide a resolution of > wl_buffer_interface, resource->interface could be > libwayland-server.so::wl_buffer_interface, or > libwayland-client.so::wl_buffer_interface. > > When a compositor wants to import a buffer into GBM, it calls > gbm_bo_import(), which will call wl_drm_buffer_get(). > wl_drm_buffer_get will test (resource->interface == > &wl_buffer_interface). Previously, both create_buffer() and > wl_drm_buffer_get() at least came from the same compilation unit, but > now they are built and linked separately. This seems to make an > existing problem (ambiguity of 'wl_buffer_interface') worse (symbol > resolution now performed in separate compilation units). > > I don't really see a solution to this, apart from no longer relying on > having a single canonical resolution of wl_buffer_interface. The above > patch implements that, by removing the interface-address-equal test > and replacing it with the destroy-listener test. The patch I provided > is equally valid both with and without your series. > Ouch, that's something I did not expect looking at the Mesa code alone. Generally, this type of issues are not specific to Mesa, but come due to the implementation/use of wl_resource_instance_of. Is that correct? I'm itching to bring back my suggestions to fix this in its root, but let's ignore that for a moment ;-) Having a look at the wl_resource_instance_of() implementation WL_EXPORT int wl_resource_instance_of(struct wl_resource *resource, const struct wl_interface *interface, const void *implementation) { return wl_interface_equal(resource->object.interface, interface) && resource->object.implementation == implementation; } ... and wl_interface_equal() int wl_interface_equal(const struct wl_interface *a, const struct wl_interface *b) { /* In most cases the pointer equality test is sufficient. * However, in some cases, depending on how things are split * across shared objects, we can end up with multiple * instances of the interface metadata constants. So if the * pointers match, the interfaces are equal, if they don't * match we have to compare the interface names. */ return a == b || strcmp(a->name, b->name) == 0; } Am I reading it incorrectly, or you forgot about the name check? It seems like the name check was added explicitly to workaround the issue you're talking about. Thus wl_resource_instance_of() should return the same result with or without my patch? Or perhaps the interface check is safe, but the implementation one isn't? Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa] intel/eu/validate: avoid null deref
src/intel/compiler/brw_eu_validate.c:50:11: warning: argument 1 null where non-null expected [-Wnonnull] return memmem(haystack.str, haystack.len, needle.str, needle.len) != NULL; ^~ In file included from src/gallium/include/pipe/p_compiler.h:39:0, from src/gallium/auxiliary/util/u_math.h:42, from src/mesa/main/macros.h:35, from src/intel/compiler/brw_reg.h:47, from src/intel/compiler/brw_eu.h:39, from src/intel/compiler/brw_eu_validate.c:29: /usr/include/string.h:368:14: note: in a call to function ‘memmem’ declared here extern void *memmem (const void *__haystack, size_t __haystacklen, ^~ Signed-off-by: Eric Engestrom --- Looks to me like error_msg.str always starts off being NULL, so I would have expected this to have blown up already? I feel like I must be missing something here. --- src/intel/compiler/brw_eu_validate.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/intel/compiler/brw_eu_validate.c b/src/intel/compiler/brw_eu_validate.c index 9f72c650ddbd67ac6e18..a1c9e27ea2f8c1b466fd 100644 --- a/src/intel/compiler/brw_eu_validate.c +++ b/src/intel/compiler/brw_eu_validate.c @@ -47,6 +47,8 @@ cat(struct string *dest, const struct string src) static bool contains(const struct string haystack, const struct string needle) { + if (!haystack.str || !needle.str) + return false; return memmem(haystack.str, haystack.len, needle.str, needle.len) != NULL; } #define CONTAINS(haystack, needle) \ -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: Allow android as an EGL platform
On Friday, 2017-10-20 15:34:57 -0600, Benjamin Gordon wrote: > I'm working on radeonsi support in the Chrome OS Android container > (ARC++). Mesa in ARC++ uses autotools instead of Android.mk, but all > the necessary EGL bits are there, so the existing check is too strict. > > Signed-off-by: Benjamin Gordon Didn't double-check that all the android bits are wired, but I don't think this can break anything outside android, so: Reviewed-by: Eric Engestrom Do you need someone to push this for you? > --- > configure.ac | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index e05c34eb7b..b971b36333 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2393,12 +2393,13 @@ dnl Surfaceless is an alternative for the last one. > dnl > require_basic_egl() { > case "$with_platforms" in > -*drm*|*surfaceless*) > +*drm*|*surfaceless*|*android*) > ;; > *) > AC_MSG_ERROR([$1 requires one of these: >1) --with-platforms=drm (X, Wayland, offscreen rendering > based on DRM) >2) --with-platforms=surfaceless (offscreen only) > + 3) --with-platforms=android (Android only) >Recommended options: drm,x11]) > ;; > esac > -- > 2.15.0.rc0.271.g36b669edcc-goog Side note, do you guys have google builds of git? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix memmem compiler warnings.
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] intel/eu/validate: avoid null deref
On Mon, Oct 23, 2017 at 10:08 AM, Eric Engestrom wrote: > src/intel/compiler/brw_eu_validate.c:50:11: warning: argument 1 null where > non-null expected [-Wnonnull] > return memmem(haystack.str, haystack.len, needle.str, needle.len) != NULL; >^~ > In file included from src/gallium/include/pipe/p_compiler.h:39:0, > from src/gallium/auxiliary/util/u_math.h:42, > from src/mesa/main/macros.h:35, > from src/intel/compiler/brw_reg.h:47, > from src/intel/compiler/brw_eu.h:39, > from src/intel/compiler/brw_eu_validate.c:29: > /usr/include/string.h:368:14: note: in a call to function ‘memmem’ declared > here > extern void *memmem (const void *__haystack, size_t __haystacklen, > ^~ > > Signed-off-by: Eric Engestrom > --- > Looks to me like error_msg.str always starts off being NULL, so I would > have expected this to have blown up already? I feel like I must be > missing something here. Thanks. Strange that I don't see this. Must require a newer gcc than what I have. I just reviewed Eric Anholt's similar patch to solve this problem, so we can drop this one. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] intel: fix memmem() warning first arg shouldn't be NULL
On Sun, Oct 22, 2017 at 6:26 PM, Timothy Arceri wrote: > --- > src/intel/compiler/brw_eu_validate.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/intel/compiler/brw_eu_validate.c > b/src/intel/compiler/brw_eu_validate.c > index 9f72c650ddb..07318b9d3c0 100644 > --- a/src/intel/compiler/brw_eu_validate.c > +++ b/src/intel/compiler/brw_eu_validate.c > @@ -47,6 +47,9 @@ cat(struct string *dest, const struct string src) > static bool > contains(const struct string haystack, const struct string needle) > { > + if (!haystack.str) > + return false; > + Thanks. Strange that I don't see this. Must require a newer gcc than what I have. I just reviewed Eric Anholt's similar patch to solve this problem, so we can drop this one. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED
https://bugs.freedesktop.org/show_bug.cgi?id=103427 Bug ID: 103427 Summary: VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: cristian...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Tested with mesa 17.2.3, but have also tested with git master and the results were the same. https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/2152 All the information and logs you might need or want are there^. Apart from that, feel free to make any requests. Relevant in case you refuse to click on the link above: The error doesn't occur until until the application calls vkEnumeratePhysicalDevices. At that point, the driver is returning the VK_ERROR_INITIALIZATION_FAILED error. It appears that the first call into the driver is actually working just fine, but the loader calls vkEnumeratePhysicalDevices twice (once to get the count and once to get the content) and only the second call fails. The loader just passes this error up to the user. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED
https://bugs.freedesktop.org/show_bug.cgi?id=103427 Bas Nieuwenhuizen changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #1 from Bas Nieuwenhuizen --- So according to the glxinfo log, you're still using the radeon kernel driver.(See the DRM version bit in the renderer string? 2.x is radeon, 3.x is amdgpu). radv doesn't support the radeon driver currently. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED
https://bugs.freedesktop.org/show_bug.cgi?id=103427 --- Comment #2 from Cris --- (In reply to Bas Nieuwenhuizen from comment #1) > So according to the glxinfo log, you're still using the radeon kernel > driver.(See the DRM version bit in the renderer string? 2.x is radeon, 3.x > is amdgpu). radv doesn't support the radeon driver currently. Oh yeah, I blacklisted radeon (and checked with lsmod | grep radeon) and it still didn't work. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965: Drop a bunch of downcasting and upcasting of gl_program pointers.
We have a gl_program and we want a gl_program. There's no point in converting to brw_program and back again. This probably made more sense in the old days before Tim dropped a layer of subclassing. --- src/mesa/drivers/dri/i965/genX_state_upload.c | 31 +++ 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c b/src/mesa/drivers/dri/i965/genX_state_upload.c index 66b1ad9dbda..f2b3e4570b2 100644 --- a/src/mesa/drivers/dri/i965/genX_state_upload.c +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c @@ -3138,12 +3138,11 @@ genX(upload_vs_push_constants)(struct brw_context *brw) struct brw_stage_state *stage_state = &brw->vs.base; /* BRW_NEW_VERTEX_PROGRAM */ - const struct brw_program *vp = - brw_program_const(brw->programs[MESA_SHADER_VERTEX]); + const struct gl_program *vp = brw->programs[MESA_SHADER_VERTEX]; /* BRW_NEW_VS_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->vs.base.prog_data; - gen6_upload_push_constants(brw, &vp->program, prog_data, stage_state); + gen6_upload_push_constants(brw, vp, prog_data, stage_state); } static const struct brw_tracked_state genX(vs_push_constants) = { @@ -3164,14 +3163,13 @@ genX(upload_gs_push_constants)(struct brw_context *brw) struct brw_stage_state *stage_state = &brw->gs.base; /* BRW_NEW_GEOMETRY_PROGRAM */ - const struct brw_program *gp = - brw_program_const(brw->programs[MESA_SHADER_GEOMETRY]); + const struct gl_program *gp = brw->programs[MESA_SHADER_GEOMETRY]; if (gp) { /* BRW_NEW_GS_PROG_DATA */ struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data; - gen6_upload_push_constants(brw, &gp->program, prog_data, stage_state); + gen6_upload_push_constants(brw, gp, prog_data, stage_state); } } @@ -3192,12 +3190,11 @@ genX(upload_wm_push_constants)(struct brw_context *brw) { struct brw_stage_state *stage_state = &brw->wm.base; /* BRW_NEW_FRAGMENT_PROGRAM */ - const struct brw_program *fp = - brw_program_const(brw->programs[MESA_SHADER_FRAGMENT]); + const struct gl_program *fp = brw->programs[MESA_SHADER_FRAGMENT]; /* BRW_NEW_FS_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->wm.base.prog_data; - gen6_upload_push_constants(brw, &fp->program, prog_data, stage_state); + gen6_upload_push_constants(brw, fp, prog_data, stage_state); } static const struct brw_tracked_state genX(wm_push_constants) = { @@ -4028,13 +4025,12 @@ genX(upload_tes_push_constants)(struct brw_context *brw) { struct brw_stage_state *stage_state = &brw->tes.base; /* BRW_NEW_TESS_PROGRAMS */ - const struct brw_program *tep = - brw_program_const(brw->programs[MESA_SHADER_TESS_EVAL]); + const struct gl_program *tep = brw->programs[MESA_SHADER_TESS_EVAL]; if (tep) { /* BRW_NEW_TES_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data; - gen6_upload_push_constants(brw, &tep->program, prog_data, stage_state); + gen6_upload_push_constants(brw, tep, prog_data, stage_state); } } @@ -4054,15 +4050,14 @@ genX(upload_tcs_push_constants)(struct brw_context *brw) { struct brw_stage_state *stage_state = &brw->tcs.base; /* BRW_NEW_TESS_PROGRAMS */ - const struct brw_program *tcp = - brw_program_const(brw->programs[MESA_SHADER_TESS_CTRL]); + const struct gl_program *tcp = brw->programs[MESA_SHADER_TESS_CTRL]; bool active = brw->programs[MESA_SHADER_TESS_EVAL]; if (active) { /* BRW_NEW_TCS_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data; - gen6_upload_push_constants(brw, &tcp->program, prog_data, stage_state); + gen6_upload_push_constants(brw, tcp, prog_data, stage_state); } } @@ -4089,8 +4084,7 @@ genX(upload_cs_push_constants)(struct brw_context *brw) struct brw_stage_state *stage_state = &brw->cs.base; /* BRW_NEW_COMPUTE_PROGRAM */ - const struct brw_program *cp = - (struct brw_program *) brw->programs[MESA_SHADER_COMPUTE]; + const struct gl_program *cp = brw->programs[MESA_SHADER_COMPUTE]; if (cp) { /* BRW_NEW_CS_PROG_DATA */ @@ -4098,8 +4092,7 @@ genX(upload_cs_push_constants)(struct brw_context *brw) brw_cs_prog_data(brw->cs.base.prog_data); _mesa_shader_write_subroutine_indices(&brw->ctx, MESA_SHADER_COMPUTE); - brw_upload_cs_push_constants(brw, &cp->program, cs_prog_data, - stage_state); + brw_upload_cs_push_constants(brw, cp, cs_prog_data, stage_state); } } -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: Call gen6_upload_push_constants() even when the stage is disabled.
This properly sets stage_state->push_constant_dirty = true, so that we emit 3DSTATE_CONSTANT_XS to disable the constant buffer for the shader stage. It also sets stage_state->push_const_size = 0. --- src/mesa/drivers/dri/i965/gen6_constant_state.c | 9 +++-- src/mesa/drivers/dri/i965/genX_state_upload.c | 25 + 2 files changed, 16 insertions(+), 18 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c b/src/mesa/drivers/dri/i965/gen6_constant_state.c index 6b5d2e66cc9..acf7454cef5 100644 --- a/src/mesa/drivers/dri/i965/gen6_constant_state.c +++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c @@ -130,9 +130,14 @@ gen6_upload_push_constants(struct brw_context *brw, const struct gen_device_info *devinfo = &brw->screen->devinfo; struct gl_context *ctx = &brw->ctx; - _mesa_shader_write_subroutine_indices(ctx, stage_state->stage); + bool active = prog_data && + (stage_state->stage != MESA_SHADER_TESS_CTRL || + brw->programs[MESA_SHADER_TESS_EVAL]); - if (prog_data->nr_params == 0) { + if (active) + _mesa_shader_write_subroutine_indices(ctx, stage_state->stage); + + if (!active || prog_data->nr_params == 0) { stage_state->push_const_size = 0; } else { /* Updates the ParamaterValues[i] pointers for all parameters of the diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c b/src/mesa/drivers/dri/i965/genX_state_upload.c index f2b3e4570b2..4ccfd489191 100644 --- a/src/mesa/drivers/dri/i965/genX_state_upload.c +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c @@ -3165,12 +3165,10 @@ genX(upload_gs_push_constants)(struct brw_context *brw) /* BRW_NEW_GEOMETRY_PROGRAM */ const struct gl_program *gp = brw->programs[MESA_SHADER_GEOMETRY]; - if (gp) { - /* BRW_NEW_GS_PROG_DATA */ - struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data; + /* BRW_NEW_GS_PROG_DATA */ + struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data; - gen6_upload_push_constants(brw, gp, prog_data, stage_state); - } + gen6_upload_push_constants(brw, gp, prog_data, stage_state); } static const struct brw_tracked_state genX(gs_push_constants) = { @@ -4027,11 +4025,9 @@ genX(upload_tes_push_constants)(struct brw_context *brw) /* BRW_NEW_TESS_PROGRAMS */ const struct gl_program *tep = brw->programs[MESA_SHADER_TESS_EVAL]; - if (tep) { - /* BRW_NEW_TES_PROG_DATA */ - const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data; - gen6_upload_push_constants(brw, tep, prog_data, stage_state); - } + /* BRW_NEW_TES_PROG_DATA */ + const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data; + gen6_upload_push_constants(brw, tep, prog_data, stage_state); } static const struct brw_tracked_state genX(tes_push_constants) = { @@ -4051,14 +4047,11 @@ genX(upload_tcs_push_constants)(struct brw_context *brw) struct brw_stage_state *stage_state = &brw->tcs.base; /* BRW_NEW_TESS_PROGRAMS */ const struct gl_program *tcp = brw->programs[MESA_SHADER_TESS_CTRL]; - bool active = brw->programs[MESA_SHADER_TESS_EVAL]; - if (active) { - /* BRW_NEW_TCS_PROG_DATA */ - const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data; + /* BRW_NEW_TCS_PROG_DATA */ + const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data; - gen6_upload_push_constants(brw, tcp, prog_data, stage_state); - } + gen6_upload_push_constants(brw, tcp, prog_data, stage_state); } static const struct brw_tracked_state genX(tcs_push_constants) = { -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] i965: Move _mesa_shader_write_subroutine_indices down a level.
Now we call it in one place instead of making every caller do it. --- src/mesa/drivers/dri/i965/gen6_constant_state.c | 3 +++ src/mesa/drivers/dri/i965/genX_state_upload.c | 6 -- 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c b/src/mesa/drivers/dri/i965/gen6_constant_state.c index 121ba672575..6b5d2e66cc9 100644 --- a/src/mesa/drivers/dri/i965/gen6_constant_state.c +++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c @@ -28,6 +28,7 @@ #include "intel_batchbuffer.h" #include "intel_buffer_objects.h" #include "program/prog_parameter.h" +#include "main/shaderapi.h" static uint32_t f_as_u32(float f) @@ -129,6 +130,8 @@ gen6_upload_push_constants(struct brw_context *brw, const struct gen_device_info *devinfo = &brw->screen->devinfo; struct gl_context *ctx = &brw->ctx; + _mesa_shader_write_subroutine_indices(ctx, stage_state->stage); + if (prog_data->nr_params == 0) { stage_state->push_const_size = 0; } else { diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c b/src/mesa/drivers/dri/i965/genX_state_upload.c index 63ad02ff499..66b1ad9dbda 100644 --- a/src/mesa/drivers/dri/i965/genX_state_upload.c +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c @@ -3143,7 +3143,6 @@ genX(upload_vs_push_constants)(struct brw_context *brw) /* BRW_NEW_VS_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->vs.base.prog_data; - _mesa_shader_write_subroutine_indices(&brw->ctx, MESA_SHADER_VERTEX); gen6_upload_push_constants(brw, &vp->program, prog_data, stage_state); } @@ -3172,7 +3171,6 @@ genX(upload_gs_push_constants)(struct brw_context *brw) /* BRW_NEW_GS_PROG_DATA */ struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data; - _mesa_shader_write_subroutine_indices(&brw->ctx, MESA_SHADER_GEOMETRY); gen6_upload_push_constants(brw, &gp->program, prog_data, stage_state); } } @@ -3199,8 +3197,6 @@ genX(upload_wm_push_constants)(struct brw_context *brw) /* BRW_NEW_FS_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->wm.base.prog_data; - _mesa_shader_write_subroutine_indices(&brw->ctx, MESA_SHADER_FRAGMENT); - gen6_upload_push_constants(brw, &fp->program, prog_data, stage_state); } @@ -4038,7 +4034,6 @@ genX(upload_tes_push_constants)(struct brw_context *brw) if (tep) { /* BRW_NEW_TES_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data; - _mesa_shader_write_subroutine_indices(&brw->ctx, MESA_SHADER_TESS_EVAL); gen6_upload_push_constants(brw, &tep->program, prog_data, stage_state); } } @@ -4067,7 +4062,6 @@ genX(upload_tcs_push_constants)(struct brw_context *brw) /* BRW_NEW_TCS_PROG_DATA */ const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data; - _mesa_shader_write_subroutine_indices(&brw->ctx, MESA_SHADER_TESS_CTRL); gen6_upload_push_constants(brw, &tcp->program, prog_data, stage_state); } } -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/8] egl: add dri2_egl_surface_free_outdated_buffers_and_update_size() helper (v2)
Hi Emil and Gurchetan, Thank you for reviewing the patches. 2017-10-20 6:18 GMT+09:00 Gurchetan Singh : > De-duplicating and then trimming down works for me. > > On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov > wrote: >> >> On 18 October 2017 at 23:36, Gurchetan Singh >> wrote: >> >> Then again, I'd suggest keeping that as separate series. These patches >> >> started as a way to minimise the duplication we have in drivers/dri2. >> > >> > I'm fine with dri2_$action_$object. We can modify the existing >> > functions >> > later, but I recommend adopting more concise conventions in this >> > patchset, >> > i.e: >> > >> > dri2_egl_surface_record_buffers_and_update_back_buffer --> >> > dri2_set_back_buffer_surface >> > dri2_egl_surface_free_outdated_buffers_and_update_size --> >> > dri2_fixup_surface >> > dri2_egl_surface_update_buffer_age --> dri2_update_age_surface >> > dri2_egl_surface_get_image_front --> dri2_get_front_image_surface >> > >> Sure thing, let's use consistent names with this series. >> It seems great with your suggested helper function names. nevertheless, egl/driver/dri3/ codes also use such as dri2_surface_$action_$object naming conventions. (ie. __DRIdrawable *dri2_surface_get_dri_drawable(_EGLSurface *surf) void dri2_surface_set_out_fence_fd(_EGLSurface *surf, int fence_fd) ) If you are fine with dri2_surface_$action_$object naming convention, I suggest these function prototype. These have dri2_surface_$action_$object naming convention and change type of first argument. (struct dri2_egl_surface => _EGLSurface ) ie. void dri2_egl_surface_record_buffers_and_update_back_buffer(struct dri2_egl_surface *dri2_surf, void *buffer) => void dri2_surface_set_back_buffer(_EGLSurface *surf, void *buffer) void dri2_egl_surface_free_outdated_buffers_and_update_size(struct dri2_egl_surface *dri2_surf, int width, int height) => void dri2_surface_fixup(_EGLSurface *surf, int width, int height) void dri2_egl_surface_update_buffer_age(struct dri2_egl_surface *dri2_surf) => void dri2_surface_update_age(_EGLSurface *surf) int dri2_egl_surface_get_image_front(struct dri2_egl_surface *dri2_surf, unsigned int format) => int dri2_surface_get_front_image(_EGLSurface *surf, unsigned int format) What do you think about this? Thanks, Gwan-gyeong. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED
https://bugs.freedesktop.org/show_bug.cgi?id=103427 --- Comment #3 from Emil Velikov --- Adding some debug information in radv_EnumeratePhysicalDevices and/or stepping through it with a debugger might be a good idea. There are multiple reasons why enumeration can fail. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 6/8] egl: add dri2_egl_surface_destroy_image_front() helper (v2)
Hi Gurchetan, 2017-10-18 6:02 GMT+09:00 Gurchetan Singh : > dri2_egl_surface_destroy_image_front and dri2_egl_surface_destroy_image_back > are almost identical. Why don't you just create a > dri2_surface_free_image(struct dri2_egl_surface *dri2_surf, __DRIimage > **img) that you will call with both the front and back images? In addition, As your opinion, we can rafactor more for dri2_surface_free_image. Nevertheless however, I'd suggest keeping that as separate series. these patches started as a way to minimise the duplication we have in drivers/dri2. So that new platforms such as Tizen do not need to copy the lot. [1] > only platform_android has dri_image_back and dri_image_front -- please keep In this patch, dri2_egl_surface_destroy_image_front() helper is only used for android however it will also be used for new platform (Tizen). [2] [1] https://lists.freedesktop.org/archives/mesa-dev/2017-October/173269.html [2] https://lists.freedesktop.org/archives/mesa-dev/2017-October/172007.html Thanks, Gwan-gyeong ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #5910 failed
Build mesa 5910 failed Commit 069211f205 by Brian Paul on 10/17/2017 7:59 PM: gallium/util: don't call close() on Windows in u_tests.c\n\nReviewed-by: Nicolai Hähnle Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/util: use util_snprintf() in u_socket_connect()
Instead of plain snprintf(). To fix the MSVC build. snprintf() is used in various places in Mesa/gallium, but apparently, not in code built with MSVC. --- src/gallium/auxiliary/util/u_network.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_network.c b/src/gallium/auxiliary/util/u_network.c index a7a4d28..203205d 100644 --- a/src/gallium/auxiliary/util/u_network.c +++ b/src/gallium/auxiliary/util/u_network.c @@ -2,6 +2,7 @@ #include "pipe/p_compiler.h" #include "util/u_network.h" #include "util/u_debug.h" +#include "util/u_string.h" #include #if defined(PIPE_SUBSYSTEM_WINDOWS_USER) @@ -120,7 +121,7 @@ u_socket_connect(const char *hostname, uint16_t port) hints.ai_family = AF_UNSPEC; // AF_INET or AF_INET6 to force version hints.ai_socktype = SOCK_STREAM; - snprintf(portString, sizeof(portString), "%d", port); + util_snprintf(portString, sizeof(portString), "%d", port); r = getaddrinfo(hostname, portString, NULL, &addr); if (r != 0) { -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: Allow android as an EGL platform
On Mon, Oct 23, 2017 at 11:10 AM, Eric Engestrom wrote: > On Friday, 2017-10-20 15:34:57 -0600, Benjamin Gordon wrote: > > I'm working on radeonsi support in the Chrome OS Android container > > (ARC++). Mesa in ARC++ uses autotools instead of Android.mk, but all > > the necessary EGL bits are there, so the existing check is too strict. > > > > Signed-off-by: Benjamin Gordon > > Didn't double-check that all the android bits are wired, but I don't > think this can break anything outside android, so: > Reviewed-by: Eric Engestrom > > Do you need someone to push this for you? > Yes, please :) > > > --- > > configure.ac | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/configure.ac b/configure.ac > > index e05c34eb7b..b971b36333 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -2393,12 +2393,13 @@ dnl Surfaceless is an alternative for the last > one. > > dnl > > require_basic_egl() { > > case "$with_platforms" in > > -*drm*|*surfaceless*) > > +*drm*|*surfaceless*|*android*) > > ;; > > *) > > AC_MSG_ERROR([$1 requires one of these: > >1) --with-platforms=drm (X, Wayland, offscreen > rendering based on DRM) > >2) --with-platforms=surfaceless (offscreen only) > > + 3) --with-platforms=android (Android only) > >Recommended options: drm,x11]) > > ;; > > esac > > -- > > 2.15.0.rc0.271.g36b669edcc-goog > > Side note, do you guys have google builds of git? > We probably do, but I'm afraid I don't have any idea what's in it. There are several git contributors working here, so maybe stuff that they haven't finished upstreaming yet? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 00/34] i965 disk shader cache
On 2017-10-22 13:01:08, Jordan Justen wrote: > > Patch code review status: > > mesa/glsl: add api_enabled flag to gl_transform_feedback_info > > i965: add support for cached shaders with xfb qualifiers It sounds like Tim has a plan for supporting shader cache with transform feedback, but for now these two are: Reviewed-by: Jordan Justen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.
On 2017-10-19 16:30:44, Kristian Høgsberg wrote: > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke > wrote: > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2 > > registers at context initialization time. Instead, they're inherited > > from whatever happened to be running on the GPU prior to first run of a > > new context. So, when we started setting these, other contexts in the > > system started inheriting our values. Since this controls whether > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong > > setting is fatal for almost any process which isn't expecting this. > > > > Unfortunately, VA-API and Beignet don't initialize this (nor does older > > Mesa), so they will die horribly if we start doing this. UXA and SNA > > don't use any push constants, so they are unaffected. > > > > The kernel developers are apparently uninterested in making the proto- > > context initialize these registers to guarantee deterministic behavior. > > Could somebody from the kernel team elaborate here? This is obviously > broken and undermines the security and containerization that hw > contexts are supposed to provide. I'm really curious what the thinking > is here... > > Kristian Cc intel-gfx, maintainers > > > Apparently, the "Default Value" of registers in the documentation is a > > total lie, and cannot be relied upon by userspace. So, we need to find > > a new solution. One would be to patch VA-API and Beignet to initialize > > these, then get every distributor to ship those in tandem with the newer > > Mesa version. I'm unclear when va-intel-driver releases might happen. > > Another option would be to hack Mesa to restore the register back to the > > historical default (relative mode) at the end of each batch. This is > > also gross, as it has non-zero cost, and is also relying on userspace to > > be "polite" to other broken userspace. A large part of the motivation > > for contexts was to provide proper process isolation, so we should not > > have to do this. But, we're already doing it in some cases, because > > our kernel fixes to enforce isolation were reverted. > > > > In the meantime, I guess we'll just revert this patch and abandon using > > the feature. It will lead to fewer pushed UBOs on Broadwell+, which may > > lead to lower performance, but I don't have any data on the impact. > > > > Cc: "17.2" > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774 > > --- > > src/mesa/drivers/dri/i965/brw_state_upload.c | 24 > > src/mesa/drivers/dri/i965/intel_screen.c | 2 +- > > 2 files changed, 1 insertion(+), 25 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c > > b/src/mesa/drivers/dri/i965/brw_state_upload.c > > index 16f44d03bbe..23e4ebda259 100644 > > --- a/src/mesa/drivers/dri/i965/brw_state_upload.c > > +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c > > @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw) > >OUT_BATCH(0); > >ADVANCE_BATCH(); > > } > > - > > - /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so > > -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address. > > -* > > -* On Gen6-7.5, we use an execbuf parameter to do this for us. > > -* However, the kernel ignores that when execlists are in use. > > -* Fortunately, we can just write the registers from userspace > > -* on Gen8+, and they're context saved/restored. > > -*/ > > - if (devinfo->gen >= 9) { > > - BEGIN_BATCH(3); > > - OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2)); > > - OUT_BATCH(CS_DEBUG_MODE2); > > - OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) | > > -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE); > > - ADVANCE_BATCH(); > > - } else if (devinfo->gen == 8) { > > - BEGIN_BATCH(3); > > - OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2)); > > - OUT_BATCH(INSTPM); > > - OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) | > > -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE); > > - ADVANCE_BATCH(); > > - } > > } > > > > static inline const struct brw_tracked_state * > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c > > b/src/mesa/drivers/dri/i965/intel_screen.c > > index ea04a72e860..776c2898d5b 100644 > > --- a/src/mesa/drivers/dri/i965/intel_screen.c > > +++ b/src/mesa/drivers/dri/i965/intel_screen.c > > @@ -2510,7 +2510,7 @@ __DRIconfig **intelInitScreen2(__DRIscreen > > *dri_screen) > > screen->compiler = brw_compiler_create(screen, devinfo); > > screen->compiler->shader_debug_log = shader_debug_log_mesa; > > screen->compiler->shader_perf_log = shader_perf_log_mesa; > > - screen->compiler->constant_buffer_0_is_relative = devinfo->gen < 8; > > + screen->compiler->constant_buffer_0_is_relative = true; > > screen->compiler->supports_pull_constants = true; > > > > screen->has_exe
[Mesa-dev] [PATCH 1/2] st/program: rework basic variant interface
From: Dave Airlie This just passes st_common_program and uses it. Signed-off-by: Dave Airlie --- src/mesa/state_tracker/st_atom_shader.c | 3 +-- src/mesa/state_tracker/st_program.c | 21 ++--- src/mesa/state_tracker/st_program.h | 3 +-- 3 files changed, 12 insertions(+), 15 deletions(-) diff --git a/src/mesa/state_tracker/st_atom_shader.c b/src/mesa/state_tracker/st_atom_shader.c index b5ba33a488..c6faa3f07f 100644 --- a/src/mesa/state_tracker/st_atom_shader.c +++ b/src/mesa/state_tracker/st_atom_shader.c @@ -215,8 +215,7 @@ st_update_common_program(struct st_context *st, struct gl_program *prog, if (st->shader_has_one_variant[prog->info.stage] && stp->variants) return stp->variants->driver_shader; - return st_get_basic_variant(st, pipe_shader, &stp->tgsi, - &stp->variants)->driver_shader; + return st_get_basic_variant(st, pipe_shader, stp)->driver_shader; } diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index 41ebfa9003..1695f4835d 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -1604,8 +1604,7 @@ st_translate_geometry_program(struct st_context *st, struct st_basic_variant * st_get_basic_variant(struct st_context *st, unsigned pipe_shader, - struct pipe_shader_state *tgsi, - struct st_basic_variant **variants) + struct st_common_program *prog) { struct pipe_context *pipe = st->pipe; struct st_basic_variant *v; @@ -1615,7 +1614,7 @@ st_get_basic_variant(struct st_context *st, key.st = st->has_shareable_shaders ? NULL : st; /* Search for existing variant */ - for (v = *variants; v; v = v->next) { + for (v = prog->variants; v; v = v->next) { if (memcmp(&v->key, &key, sizeof(key)) == 0) { break; } @@ -1628,13 +1627,13 @@ st_get_basic_variant(struct st_context *st, /* fill in new variant */ switch (pipe_shader) { case PIPE_SHADER_TESS_CTRL: -v->driver_shader = pipe->create_tcs_state(pipe, tgsi); +v->driver_shader = pipe->create_tcs_state(pipe, &prog->tgsi); break; case PIPE_SHADER_TESS_EVAL: -v->driver_shader = pipe->create_tes_state(pipe, tgsi); +v->driver_shader = pipe->create_tes_state(pipe, &prog->tgsi); break; case PIPE_SHADER_GEOMETRY: -v->driver_shader = pipe->create_gs_state(pipe, tgsi); +v->driver_shader = pipe->create_gs_state(pipe, &prog->tgsi); break; default: assert(!"unhandled shader type"); @@ -1645,8 +1644,8 @@ st_get_basic_variant(struct st_context *st, v->key = key; /* insert into list */ - v->next = *variants; - *variants = v; + v->next = prog->variants; + prog->variants = v; } } @@ -2004,19 +2003,19 @@ st_precompile_shader_variant(struct st_context *st, case GL_TESS_CONTROL_PROGRAM_NV: { struct st_common_program *p = st_common_program(prog); - st_get_basic_variant(st, PIPE_SHADER_TESS_CTRL, &p->tgsi, &p->variants); + st_get_basic_variant(st, PIPE_SHADER_TESS_CTRL, p); break; } case GL_TESS_EVALUATION_PROGRAM_NV: { struct st_common_program *p = st_common_program(prog); - st_get_basic_variant(st, PIPE_SHADER_TESS_EVAL, &p->tgsi, &p->variants); + st_get_basic_variant(st, PIPE_SHADER_TESS_EVAL, p); break; } case GL_GEOMETRY_PROGRAM_NV: { struct st_common_program *p = st_common_program(prog); - st_get_basic_variant(st, PIPE_SHADER_GEOMETRY, &p->tgsi, &p->variants); + st_get_basic_variant(st, PIPE_SHADER_GEOMETRY, p); break; } diff --git a/src/mesa/state_tracker/st_program.h b/src/mesa/state_tracker/st_program.h index 8e9f4c5e82..27cc9b6e92 100644 --- a/src/mesa/state_tracker/st_program.h +++ b/src/mesa/state_tracker/st_program.h @@ -384,8 +384,7 @@ st_get_cp_variant(struct st_context *st, extern struct st_basic_variant * st_get_basic_variant(struct st_context *st, unsigned pipe_shader, - struct pipe_shader_state *tgsi, - struct st_basic_variant **variants); + struct st_common_program *p); extern void st_release_vp_variants( struct st_context *st, -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/program: add support for gs/tes/tcs nir shaders.
From: Dave Airlie This probably needs more work but this just add the initial code to convert gs/tcs/tes nir based shaders in the state tracker. Signed-off-by: Dave Airlie --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 12 + src/mesa/state_tracker/st_program.c | 45 --- src/mesa/state_tracker/st_program.h | 3 +++ 3 files changed, 56 insertions(+), 4 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker/st_glsl_to_nir.cpp index 4effd8074e..e9a8d6414e 100644 --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp @@ -359,6 +359,11 @@ st_finalize_nir(struct st_context *st, struct gl_program *prog, nir_shader *nir) case MESA_SHADER_VERTEX: shader_program = ((struct st_vertex_program *)prog)->shader_program; break; + case MESA_SHADER_GEOMETRY: + case MESA_SHADER_TESS_CTRL: + case MESA_SHADER_TESS_EVAL: + shader_program = ((struct st_common_program *)prog)->shader_program; + break; case MESA_SHADER_FRAGMENT: shader_program = ((struct st_fragment_program *)prog)->shader_program; break; @@ -451,6 +456,7 @@ st_nir_get_mesa_program(struct gl_context *ctx, _mesa_associate_uniform_storage(ctx, shader_program, prog, true); struct st_vertex_program *stvp; + struct st_common_program *stp; struct st_fragment_program *stfp; struct st_compute_program *stcp; @@ -459,6 +465,12 @@ st_nir_get_mesa_program(struct gl_context *ctx, stvp = (struct st_vertex_program *)prog; stvp->shader_program = shader_program; break; + case MESA_SHADER_GEOMETRY: + case MESA_SHADER_TESS_CTRL: + case MESA_SHADER_TESS_EVAL: + stp = (struct st_common_program *)prog; + stp->shader_program = shader_program; + break; case MESA_SHADER_FRAGMENT: stfp = (struct st_fragment_program *)prog; stfp->shader_program = shader_program; diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index 1695f4835d..335d45ba28 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -1576,6 +1576,16 @@ st_translate_geometry_program(struct st_context *st, { struct ureg_program *ureg; + if (stgp->shader_program) { + nir_shader *nir = st_glsl_to_nir(st, &stgp->Base, stgp->shader_program, + MESA_SHADER_GEOMETRY); + + stgp->tgsi.type = PIPE_SHADER_IR_NIR; + stgp->tgsi.ir.nir = nir; + + return true; + } + ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen); if (ureg == NULL) return false; @@ -1609,7 +1619,7 @@ st_get_basic_variant(struct st_context *st, struct pipe_context *pipe = st->pipe; struct st_basic_variant *v; struct st_basic_variant_key key; - + struct pipe_shader_state tgsi = {0}; memset(&key, 0, sizeof(key)); key.st = st->has_shareable_shaders ? NULL : st; @@ -1624,16 +1634,23 @@ st_get_basic_variant(struct st_context *st, /* create new */ v = CALLOC_STRUCT(st_basic_variant); if (v) { + +if (prog->tgsi.type == PIPE_SHADER_IR_NIR) { + tgsi.type = PIPE_SHADER_IR_NIR; + tgsi.ir.nir = nir_shader_clone(NULL, prog->tgsi.ir.nir); + st_finalize_nir(st, &prog->Base, tgsi.ir.nir); +} else + tgsi = prog->tgsi; /* fill in new variant */ switch (pipe_shader) { case PIPE_SHADER_TESS_CTRL: -v->driver_shader = pipe->create_tcs_state(pipe, &prog->tgsi); +v->driver_shader = pipe->create_tcs_state(pipe, &tgsi); break; case PIPE_SHADER_TESS_EVAL: -v->driver_shader = pipe->create_tes_state(pipe, &prog->tgsi); +v->driver_shader = pipe->create_tes_state(pipe, &tgsi); break; case PIPE_SHADER_GEOMETRY: -v->driver_shader = pipe->create_gs_state(pipe, &prog->tgsi); +v->driver_shader = pipe->create_gs_state(pipe, &tgsi); break; default: assert(!"unhandled shader type"); @@ -1662,6 +1679,16 @@ st_translate_tessctrl_program(struct st_context *st, { struct ureg_program *ureg; + if (sttcp->shader_program) { + nir_shader *nir = st_glsl_to_nir(st, &sttcp->Base, sttcp->shader_program, + MESA_SHADER_TESS_EVAL); + + sttcp->tgsi.type = PIPE_SHADER_IR_NIR; + sttcp->tgsi.ir.nir = nir; + + return true; + } + ureg = ureg_create_with_screen(PIPE_SHADER_TESS_CTRL, st->pipe->screen); if (ureg == NULL) return false; @@ -1687,6 +1714,16 @@ st_translate_tesseval_program(struct st_context *st, { struct ureg_program *ureg; + if (sttep->shader_program) { + nir_shader *nir = st_glsl_to_nir(st, &sttep->Base, sttep->shader_program, + MESA_SHADER_TESS_EVAL); + + sttep->
[Mesa-dev] [PATCH] st/mesa: enable nir path for all shaders.
From: Dave Airlie There is no reason to block this here, if a driver enables it, let it handle it. Signed-off-by: Dave Airlie --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index a45f0047a8..9599402056 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -6976,15 +6976,7 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) struct gl_program *linked_prog = NULL; if (preferred_ir == PIPE_SHADER_IR_NIR) { - /* TODO only for GLSL VS/FS/CS for now: */ - switch (shader->Stage) { - case MESA_SHADER_VERTEX: - case MESA_SHADER_FRAGMENT: - case MESA_SHADER_COMPUTE: -linked_prog = st_nir_get_mesa_program(ctx, prog, shader); - default: -break; - } + linked_prog = st_nir_get_mesa_program(ctx, prog, shader); } else { linked_prog = get_mesa_program_tgsi(ctx, prog, shader); } -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.
On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote: > On 2017-10-19 16:30:44, Kristian Høgsberg wrote: > > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke > > wrote: > > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2 > > > registers at context initialization time. Instead, they're inherited > > > from whatever happened to be running on the GPU prior to first run of a > > > new context. So, when we started setting these, other contexts in the > > > system started inheriting our values. Since this controls whether > > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong > > > setting is fatal for almost any process which isn't expecting this. > > > > > > Unfortunately, VA-API and Beignet don't initialize this (nor does older > > > Mesa), so they will die horribly if we start doing this. UXA and SNA > > > don't use any push constants, so they are unaffected. > > > > > > The kernel developers are apparently uninterested in making the proto- > > > context initialize these registers to guarantee deterministic behavior. > > > > Could somebody from the kernel team elaborate here? This is obviously > > broken and undermines the security and containerization that hw > > contexts are supposed to provide. I'm really curious what the thinking > > is here... > > > > Kristian > > Cc intel-gfx, maintainers Is this the null-state/golden-context related discussions? I assume we are ok for older platforms, but the problem would be only for CNL+ where we are not adding the null context initialization yet. Am I getting it right? > > > > > > Apparently, the "Default Value" of registers in the documentation is a > > > total lie, and cannot be relied upon by userspace. So, we need to find > > > a new solution. One would be to patch VA-API and Beignet to initialize > > > these, then get every distributor to ship those in tandem with the newer > > > Mesa version. I'm unclear when va-intel-driver releases might happen. > > > Another option would be to hack Mesa to restore the register back to the > > > historical default (relative mode) at the end of each batch. This is > > > also gross, as it has non-zero cost, and is also relying on userspace to > > > be "polite" to other broken userspace. A large part of the motivation > > > for contexts was to provide proper process isolation, so we should not > > > have to do this. But, we're already doing it in some cases, because > > > our kernel fixes to enforce isolation were reverted. > > > > > > In the meantime, I guess we'll just revert this patch and abandon using > > > the feature. It will lead to fewer pushed UBOs on Broadwell+, which may > > > lead to lower performance, but I don't have any data on the impact. > > > > > > Cc: "17.2" > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774 > > > --- > > > src/mesa/drivers/dri/i965/brw_state_upload.c | 24 > > > > > > src/mesa/drivers/dri/i965/intel_screen.c | 2 +- > > > 2 files changed, 1 insertion(+), 25 deletions(-) > > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c > > > b/src/mesa/drivers/dri/i965/brw_state_upload.c > > > index 16f44d03bbe..23e4ebda259 100644 > > > --- a/src/mesa/drivers/dri/i965/brw_state_upload.c > > > +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c > > > @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw) > > >OUT_BATCH(0); > > >ADVANCE_BATCH(); > > > } > > > - > > > - /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so > > > -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address. > > > -* > > > -* On Gen6-7.5, we use an execbuf parameter to do this for us. > > > -* However, the kernel ignores that when execlists are in use. > > > -* Fortunately, we can just write the registers from userspace > > > -* on Gen8+, and they're context saved/restored. > > > -*/ > > > - if (devinfo->gen >= 9) { > > > - BEGIN_BATCH(3); > > > - OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2)); > > > - OUT_BATCH(CS_DEBUG_MODE2); > > > - OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) | > > > -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE); > > > - ADVANCE_BATCH(); > > > - } else if (devinfo->gen == 8) { > > > - BEGIN_BATCH(3); > > > - OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2)); > > > - OUT_BATCH(INSTPM); > > > - OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) | > > > -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE); > > > - ADVANCE_BATCH(); > > > - } > > > } > > > > > > static inline const struct brw_tracked_state * > > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c > > > b/src/mesa/drivers/dri/i965/intel_screen.c > > > index ea04a72e860..776c2898d5b 100644 > > > --- a/src/mesa/drivers/dri/i965/intel_screen.c > > > +++ b/src/mesa/drivers/dri/i965/intel_screen.c > > > @@ -2510,7 +2510,7 @@ __
[Mesa-dev] [PATCH] radv: move nir print after linking is done
We now have linking optimisation so we want to delay dumping the nir until after these are complete. Fixes: 06f05040eb73 (radv: Link shaders) --- src/amd/vulkan/radv_pipeline.c | 9 +++-- src/amd/vulkan/radv_shader.c | 3 --- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index 30a90ac960..d6b33a5327 100644 --- a/src/amd/vulkan/radv_pipeline.c +++ b/src/amd/vulkan/radv_pipeline.c @@ -1863,22 +1863,27 @@ void radv_create_shaders(struct radv_pipeline *pipeline, code_size); } free(gs_copy_code); } radv_pipeline_cache_insert_shaders(device, cache, hash, pipeline->shaders, (const void**)codes, code_sizes); for (int i = 0; i < MESA_SHADER_STAGES; ++i) { free(codes[i]); - if (modules[i] && !pipeline->device->trace_bo) - ralloc_free(nir[i]); + if (modules[i]) { + if (device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS) + nir_print_shader(nir[i], stderr); + + if (!pipeline->device->trace_bo) + ralloc_free(nir[i]); + } } if (fs_m.nir) ralloc_free(fs_m.nir); } static VkResult radv_pipeline_init(struct radv_pipeline *pipeline, struct radv_device *device, struct radv_pipeline_cache *cache, diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c index 6176a2e590..5903917068 100644 --- a/src/amd/vulkan/radv_shader.c +++ b/src/amd/vulkan/radv_shader.c @@ -284,23 +284,20 @@ radv_shader_compile_to_nir(struct radv_device *device, }; nir_lower_tex(nir, &tex_options); nir_lower_vars_to_ssa(nir); nir_lower_var_copies(nir); nir_lower_global_vars_to_local(nir); nir_remove_dead_variables(nir, nir_var_local); radv_optimize_nir(nir); - if (device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS) - nir_print_shader(nir, stderr); - return nir; } void * radv_alloc_shader_memory(struct radv_device *device, struct radv_shader_variant *shader) { mtx_lock(&device->shader_slab_mutex); list_for_each_entry(struct radv_shader_slab, slab, &device->shader_slabs, slabs) { uint64_t offset = 0; -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: move nir print after linking is done
r-b On Tue, Oct 24, 2017 at 12:59 AM, Timothy Arceri wrote: > We now have linking optimisation so we want to delay dumping the > nir until after these are complete. > > Fixes: 06f05040eb73 (radv: Link shaders) > --- > src/amd/vulkan/radv_pipeline.c | 9 +++-- > src/amd/vulkan/radv_shader.c | 3 --- > 2 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c > index 30a90ac960..d6b33a5327 100644 > --- a/src/amd/vulkan/radv_pipeline.c > +++ b/src/amd/vulkan/radv_pipeline.c > @@ -1863,22 +1863,27 @@ void radv_create_shaders(struct radv_pipeline > *pipeline, >code_size); > } > free(gs_copy_code); > } > > radv_pipeline_cache_insert_shaders(device, cache, hash, > pipeline->shaders, >(const void**)codes, code_sizes); > > for (int i = 0; i < MESA_SHADER_STAGES; ++i) { > free(codes[i]); > - if (modules[i] && !pipeline->device->trace_bo) > - ralloc_free(nir[i]); > + if (modules[i]) { > + if (device->instance->debug_flags & > RADV_DEBUG_DUMP_SHADERS) > + nir_print_shader(nir[i], stderr); > + > + if (!pipeline->device->trace_bo) > + ralloc_free(nir[i]); > + } > } > > if (fs_m.nir) > ralloc_free(fs_m.nir); > } > > static VkResult > radv_pipeline_init(struct radv_pipeline *pipeline, >struct radv_device *device, >struct radv_pipeline_cache *cache, > diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c > index 6176a2e590..5903917068 100644 > --- a/src/amd/vulkan/radv_shader.c > +++ b/src/amd/vulkan/radv_shader.c > @@ -284,23 +284,20 @@ radv_shader_compile_to_nir(struct radv_device *device, > }; > > nir_lower_tex(nir, &tex_options); > > nir_lower_vars_to_ssa(nir); > nir_lower_var_copies(nir); > nir_lower_global_vars_to_local(nir); > nir_remove_dead_variables(nir, nir_var_local); > radv_optimize_nir(nir); > > - if (device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS) > - nir_print_shader(nir, stderr); > - > return nir; > } > > void * > radv_alloc_shader_memory(struct radv_device *device, > struct radv_shader_variant *shader) > { > mtx_lock(&device->shader_slab_mutex); > list_for_each_entry(struct radv_shader_slab, slab, > &device->shader_slabs, slabs) { > uint64_t offset = 0; > -- > 2.13.6 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.
On Monday, October 23, 2017 3:53:15 PM PDT Rodrigo Vivi wrote: > On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote: > > On 2017-10-19 16:30:44, Kristian Høgsberg wrote: > > > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke > > > wrote: > > > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2 > > > > registers at context initialization time. Instead, they're inherited > > > > from whatever happened to be running on the GPU prior to first run of a > > > > new context. So, when we started setting these, other contexts in the > > > > system started inheriting our values. Since this controls whether > > > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong > > > > setting is fatal for almost any process which isn't expecting this. > > > > > > > > Unfortunately, VA-API and Beignet don't initialize this (nor does older > > > > Mesa), so they will die horribly if we start doing this. UXA and SNA > > > > don't use any push constants, so they are unaffected. > > > > > > > > The kernel developers are apparently uninterested in making the proto- > > > > context initialize these registers to guarantee deterministic behavior. > > > > > > Could somebody from the kernel team elaborate here? This is obviously > > > broken and undermines the security and containerization that hw > > > contexts are supposed to provide. I'm really curious what the thinking > > > is here... > > > > > > Kristian > > > > Cc intel-gfx, maintainers > > Is this the null-state/golden-context related discussions? > > I assume we are ok for older platforms, but the problem would be only for > CNL+ where we are not adding the null context initialization yet. > Am I getting it right? No, this problem exists on earlier platforms as well. We saw the issue on Broadwell and Kabylake. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103312] meson/macOS: Dependency libdrm_intel found: NO
https://bugs.freedesktop.org/show_bug.cgi?id=103312 Dylan Baker changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Dylan Baker --- Okay, I've found a macbook and I'm going to look into getting meson working for macos. I need some information though. What configuration options are supposed to work on macOS? swrast? softpipe? llvmpipe? osmesa? glx? egl? obviously not dri drivers. What autotools configuration did you provide? What packages did you have to install from source/macports/homebrew/etc. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 17/34] intel/compiler: Remove final_program_size from brw_compile_*
Attached is the missing change to brw_vec4_gs_visitor.cpp, which Jason pointed out. The issue was hiding out in a compiler warning. -Jordan On 2017-10-22 13:01:25, Jordan Justen wrote: > The caller can now use brw_stage_prog_data::program_size which is set > by the brw_compile_* functions. > > Cc: Jason Ekstrand > Signed-off-by: Jordan Justen > --- > src/intel/blorp/blorp.c | 10 -- > src/intel/blorp/blorp_blit.c| 5 ++--- > src/intel/blorp/blorp_clear.c | 15 ++- > src/intel/blorp/blorp_priv.h| 6 ++ > src/intel/compiler/brw_compiler.h | 6 -- > src/intel/compiler/brw_fs.cpp | 10 ++ > src/intel/compiler/brw_shader.cpp | 8 > src/intel/compiler/brw_vec4.cpp | 8 > src/intel/compiler/brw_vec4_tcs.cpp | 8 > src/intel/vulkan/anv_pipeline.c | 23 --- > src/mesa/drivers/dri/i965/brw_cs.c | 5 ++--- > src/mesa/drivers/dri/i965/brw_gs.c | 5 ++--- > src/mesa/drivers/dri/i965/brw_tcs.c | 5 ++--- > src/mesa/drivers/dri/i965/brw_tes.c | 5 ++--- > src/mesa/drivers/dri/i965/brw_vs.c | 11 +-- > src/mesa/drivers/dri/i965/brw_wm.c | 5 ++--- > 16 files changed, 55 insertions(+), 80 deletions(-) > > diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c > index 7cc6335f2f6..5faba75b8db 100644 > --- a/src/intel/blorp/blorp.c > +++ b/src/intel/blorp/blorp.c > @@ -162,8 +162,7 @@ blorp_compile_fs(struct blorp_context *blorp, void > *mem_ctx, > struct nir_shader *nir, > struct brw_wm_prog_key *wm_key, > bool use_repclear, > - struct brw_wm_prog_data *wm_prog_data, > - unsigned *program_size) > + struct brw_wm_prog_data *wm_prog_data) > { > const struct brw_compiler *compiler = blorp->compiler; > > @@ -194,7 +193,7 @@ blorp_compile_fs(struct blorp_context *blorp, void > *mem_ctx, > const unsigned *program = >brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx, wm_key, > wm_prog_data, nir, NULL, -1, -1, false, use_repclear, > - NULL, program_size, NULL); > + NULL, NULL); > > return program; > } > @@ -202,8 +201,7 @@ blorp_compile_fs(struct blorp_context *blorp, void > *mem_ctx, > const unsigned * > blorp_compile_vs(struct blorp_context *blorp, void *mem_ctx, > struct nir_shader *nir, > - struct brw_vs_prog_data *vs_prog_data, > - unsigned *program_size) > + struct brw_vs_prog_data *vs_prog_data) > { > const struct brw_compiler *compiler = blorp->compiler; > > @@ -225,7 +223,7 @@ blorp_compile_vs(struct blorp_context *blorp, void > *mem_ctx, > const unsigned *program = >brw_compile_vs(compiler, blorp->driver_ctx, mem_ctx, > &vs_key, vs_prog_data, nir, > - false, -1, program_size, NULL); > + false, -1, NULL); > > return program; > } > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c > index 4507046dae5..9b5c1f1f8c1 100644 > --- a/src/intel/blorp/blorp_blit.c > +++ b/src/intel/blorp/blorp_blit.c > @@ -1308,7 +1308,6 @@ brw_blorp_get_blit_kernel(struct blorp_context *blorp, > void *mem_ctx = ralloc_context(NULL); > > const unsigned *program; > - unsigned program_size; > struct brw_wm_prog_data prog_data; > > nir_shader *nir = brw_blorp_build_nir_shader(blorp, mem_ctx, prog_key); > @@ -1322,11 +1321,11 @@ brw_blorp_get_blit_kernel(struct blorp_context *blorp, > wm_key.multisample_fbo = prog_key->rt_samples > 1; > > program = blorp_compile_fs(blorp, mem_ctx, nir, &wm_key, false, > - &prog_data, &program_size); > + &prog_data); > > bool result = >blorp->upload_shader(blorp, prog_key, sizeof(*prog_key), > - program, program_size, > + program, prog_data.base.program_size, > &prog_data.base, sizeof(prog_data), > ¶ms->wm_prog_kernel, ¶ms->wm_prog_data); > > diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c > index cd83fa13caf..8d758df155f 100644 > --- a/src/intel/blorp/blorp_clear.c > +++ b/src/intel/blorp/blorp_clear.c > @@ -75,14 +75,13 @@ blorp_params_get_clear_kernel(struct blorp_context *blorp, > brw_blorp_init_wm_prog_key(&wm_key); > > struct brw_wm_prog_data prog_data; > - unsigned program_size; > const unsigned *program = >blorp_compile_fs(blorp, mem_ctx, b.shader, &wm_key, > use_replicated_data, > - &prog_data, &program_size); > + &prog_data); > > bool result = >blorp->upload_shader(blorp, &blorp_key, sizeof(blorp_key), > - program, program_size,
[Mesa-dev] [PATCH 2/3] i965/blorp: Use more temporary isl_format variables
--- src/mesa/drivers/dri/i965/brw_blorp.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c b/src/mesa/drivers/dri/i965/brw_blorp.c index f7d128d..05204a9 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp.c +++ b/src/mesa/drivers/dri/i965/brw_blorp.c @@ -329,6 +329,8 @@ brw_blorp_blit_miptrees(struct brw_context *brw, intel_miptree_prepare_access(brw, src_mt, src_level, 1, src_layer, 1, src_aux_usage, src_clear_supported); + enum isl_format dst_isl_format = + brw_blorp_to_isl_format(brw, dst_format, true); enum isl_aux_usage dst_aux_usage = intel_miptree_render_aux_usage(brw, dst_mt, encode_srgb, false); const bool dst_clear_supported = dst_aux_usage != ISL_AUX_USAGE_NONE; @@ -352,10 +354,9 @@ brw_blorp_blit_miptrees(struct brw_context *brw, struct blorp_batch batch; blorp_batch_init(&brw->blorp, &batch, brw, 0); blorp_blit(&batch, &src_surf, src_level, src_layer, - brw_blorp_to_isl_format(brw, src_format, false), src_isl_swizzle, + src_isl_format, src_isl_swizzle, &dst_surf, dst_level, dst_layer, - brw_blorp_to_isl_format(brw, dst_format, true), - ISL_SWIZZLE_IDENTITY, + dst_isl_format, ISL_SWIZZLE_IDENTITY, src_x0, src_y0, src_x1, src_y1, dst_x0, dst_y0, dst_x1, dst_y1, filter, mirror_x, mirror_y); @@ -1158,6 +1159,7 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb, mesa_format format = irb->Base.Base.Format; if (!encode_srgb && _mesa_get_format_color_encoding(format) == GL_SRGB) format = _mesa_get_srgb_format_linear(format); + enum isl_format isl_format = brw->mesa_to_isl_render_format[format]; x0 = fb->_Xmin; x1 = fb->_Xmax; @@ -1256,8 +1258,7 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb, struct blorp_batch batch; blorp_batch_init(&brw->blorp, &batch, brw, 0); - blorp_fast_clear(&batch, &surf, - brw->mesa_to_isl_render_format[format], + blorp_fast_clear(&batch, &surf, isl_format, level, irb->mt_layer, num_layers, x0, y0, x1, y1); blorp_batch_finish(&batch); @@ -1290,9 +1291,7 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb, struct blorp_batch batch; blorp_batch_init(&brw->blorp, &batch, brw, 0); - blorp_clear(&batch, &surf, - brw->mesa_to_isl_render_format[format], - ISL_SWIZZLE_IDENTITY, + blorp_clear(&batch, &surf, isl_format, ISL_SWIZZLE_IDENTITY, level, irb->mt_layer, num_layers, x0, y0, x1, y1, clear_color, color_write_disable); -- 2.5.0.400.gff86faf ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965/miptree: Take an isl_format in render_aux_usage
Not all rendering matches the miptree format. We allow rendering to texture views so there are cases where it may not match. In those cases, our current scheme of just passing the value of ctx->sRGBEnabled isn't viable. Instead, just do what we do for texturing and pass the view format in directly. --- src/mesa/drivers/dri/i965/brw_blorp.c| 8 src/mesa/drivers/dri/i965/brw_draw.c | 13 +++-- src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 13 +++-- src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 23 +++ src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 9 ++--- 5 files changed, 39 insertions(+), 27 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c b/src/mesa/drivers/dri/i965/brw_blorp.c index 05204a9..58e1f8a 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp.c +++ b/src/mesa/drivers/dri/i965/brw_blorp.c @@ -332,7 +332,7 @@ brw_blorp_blit_miptrees(struct brw_context *brw, enum isl_format dst_isl_format = brw_blorp_to_isl_format(brw, dst_format, true); enum isl_aux_usage dst_aux_usage = - intel_miptree_render_aux_usage(brw, dst_mt, encode_srgb, false); + intel_miptree_render_aux_usage(brw, dst_mt, dst_isl_format, false); const bool dst_clear_supported = dst_aux_usage != ISL_AUX_USAGE_NONE; intel_miptree_prepare_access(brw, dst_mt, dst_level, 1, dst_layer, 1, dst_aux_usage, dst_clear_supported); @@ -1277,9 +1277,9 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb, irb->mt, irb->mt_level, irb->mt_layer, num_layers); enum isl_aux_usage aux_usage = - intel_miptree_render_aux_usage(brw, irb->mt, encode_srgb, false); + intel_miptree_render_aux_usage(brw, irb->mt, isl_format, false); intel_miptree_prepare_render(brw, irb->mt, level, irb->mt_layer, - num_layers, encode_srgb, false); + num_layers, isl_format, false); struct isl_surf isl_tmp[2]; struct blorp_surf surf; @@ -1298,7 +1298,7 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb, blorp_batch_finish(&batch); intel_miptree_finish_render(brw, irb->mt, level, irb->mt_layer, - num_layers, encode_srgb, false); + num_layers, isl_format, false); } return; diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index b74ab8b..1e5c499 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -25,6 +25,7 @@ #include +#include "main/blend.h" #include "main/context.h" #include "main/condrender.h" #include "main/samplerobj.h" @@ -503,9 +504,13 @@ brw_predraw_resolve_framebuffer(struct brw_context *brw) if (irb == NULL || irb->mt == NULL) continue; + mesa_format mesa_format = + _mesa_get_render_format(ctx, intel_rb_format(irb)); + enum isl_format isl_format = brw_isl_format_for_mesa_format(mesa_format); + intel_miptree_prepare_render(brw, irb->mt, irb->mt_level, irb->mt_layer, irb->layer_count, - ctx->Color.sRGBEnabled, + isl_format, ctx->Color.BlendEnabled & (1 << i)); } } @@ -571,10 +576,14 @@ brw_postdraw_set_buffers_need_resolve(struct brw_context *brw) if (!irb) continue; + mesa_format mesa_format = + _mesa_get_render_format(ctx, intel_rb_format(irb)); + enum isl_format isl_format = brw_isl_format_for_mesa_format(mesa_format); + brw_render_cache_set_add_bo(brw, irb->mt->bo); intel_miptree_finish_render(brw, irb->mt, irb->mt_level, irb->mt_layer, irb->layer_count, - ctx->Color.sRGBEnabled, + isl_format, ctx->Color.BlendEnabled & (1 << i)); } } diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index f4e9cf4..d668cd8 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -213,11 +213,6 @@ gen6_update_renderbuffer_surface(struct brw_context *brw, struct intel_renderbuffer *irb = intel_renderbuffer(rb); struct intel_mipmap_tree *mt = irb->mt; - enum isl_aux_usage aux_usage = - brw->draw_aux_buffer_disabled[unit] ? ISL_AUX_USAGE_NONE : - intel_miptree_render_aux_usage(brw, mt, ctx->Color.sRGBEnabled, - ctx->Color.BlendEnabled & (1 << unit)); - assert(brw_render_target_supported(brw, rb)); mesa_format rb_format = _mesa_get_render_format(ctx, intel_rb_format(irb)); @@ -225,9 +220,15 @@ gen6_update_r
[Mesa-dev] [PATCH 1/3] i965/blorp: Use blorp_to_isl_format for src_isl_format in blit_miptrees
--- src/mesa/drivers/dri/i965/brw_blorp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c b/src/mesa/drivers/dri/i965/brw_blorp.c index ed4f987..f7d128d 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp.c +++ b/src/mesa/drivers/dri/i965/brw_blorp.c @@ -315,7 +315,8 @@ brw_blorp_blit_miptrees(struct brw_context *brw, src_format = dst_format = MESA_FORMAT_R_FLOAT32; } - enum isl_format src_isl_format = brw_isl_format_for_mesa_format(src_format); + enum isl_format src_isl_format = + brw_blorp_to_isl_format(brw, src_format, false); enum isl_aux_usage src_aux_usage = intel_miptree_texture_aux_usage(brw, src_mt, src_isl_format); /* We do format workarounds for some depth formats so we can't reliably -- 2.5.0.400.gff86faf ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 17/34] intel/compiler: Remove final_program_size from brw_compile_*
On Mon, Oct 23, 2017 at 5:11 PM, Jordan Justen wrote: > Attached is the missing change to brw_vec4_gs_visitor.cpp, which Jason > pointed out. The issue was hiding out in a compiler warning. > We should be able to drop the final_program_size variable. I think that would be a bit more fool-proof. Other than that, this patch (with the attached squash-in) is Reviewed-by: Jason Ekstrand > -Jordan > > On 2017-10-22 13:01:25, Jordan Justen wrote: > > The caller can now use brw_stage_prog_data::program_size which is set > > by the brw_compile_* functions. > > > > Cc: Jason Ekstrand > > Signed-off-by: Jordan Justen > > --- > > src/intel/blorp/blorp.c | 10 -- > > src/intel/blorp/blorp_blit.c| 5 ++--- > > src/intel/blorp/blorp_clear.c | 15 ++- > > src/intel/blorp/blorp_priv.h| 6 ++ > > src/intel/compiler/brw_compiler.h | 6 -- > > src/intel/compiler/brw_fs.cpp | 10 ++ > > src/intel/compiler/brw_shader.cpp | 8 > > src/intel/compiler/brw_vec4.cpp | 8 > > src/intel/compiler/brw_vec4_tcs.cpp | 8 > > src/intel/vulkan/anv_pipeline.c | 23 --- > > src/mesa/drivers/dri/i965/brw_cs.c | 5 ++--- > > src/mesa/drivers/dri/i965/brw_gs.c | 5 ++--- > > src/mesa/drivers/dri/i965/brw_tcs.c | 5 ++--- > > src/mesa/drivers/dri/i965/brw_tes.c | 5 ++--- > > src/mesa/drivers/dri/i965/brw_vs.c | 11 +-- > > src/mesa/drivers/dri/i965/brw_wm.c | 5 ++--- > > 16 files changed, 55 insertions(+), 80 deletions(-) > > > > diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c > > index 7cc6335f2f6..5faba75b8db 100644 > > --- a/src/intel/blorp/blorp.c > > +++ b/src/intel/blorp/blorp.c > > @@ -162,8 +162,7 @@ blorp_compile_fs(struct blorp_context *blorp, void > *mem_ctx, > > struct nir_shader *nir, > > struct brw_wm_prog_key *wm_key, > > bool use_repclear, > > - struct brw_wm_prog_data *wm_prog_data, > > - unsigned *program_size) > > + struct brw_wm_prog_data *wm_prog_data) > > { > > const struct brw_compiler *compiler = blorp->compiler; > > > > @@ -194,7 +193,7 @@ blorp_compile_fs(struct blorp_context *blorp, void > *mem_ctx, > > const unsigned *program = > >brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx, wm_key, > > wm_prog_data, nir, NULL, -1, -1, false, > use_repclear, > > - NULL, program_size, NULL); > > + NULL, NULL); > > > > return program; > > } > > @@ -202,8 +201,7 @@ blorp_compile_fs(struct blorp_context *blorp, void > *mem_ctx, > > const unsigned * > > blorp_compile_vs(struct blorp_context *blorp, void *mem_ctx, > > struct nir_shader *nir, > > - struct brw_vs_prog_data *vs_prog_data, > > - unsigned *program_size) > > + struct brw_vs_prog_data *vs_prog_data) > > { > > const struct brw_compiler *compiler = blorp->compiler; > > > > @@ -225,7 +223,7 @@ blorp_compile_vs(struct blorp_context *blorp, void > *mem_ctx, > > const unsigned *program = > >brw_compile_vs(compiler, blorp->driver_ctx, mem_ctx, > > &vs_key, vs_prog_data, nir, > > - false, -1, program_size, NULL); > > + false, -1, NULL); > > > > return program; > > } > > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c > > index 4507046dae5..9b5c1f1f8c1 100644 > > --- a/src/intel/blorp/blorp_blit.c > > +++ b/src/intel/blorp/blorp_blit.c > > @@ -1308,7 +1308,6 @@ brw_blorp_get_blit_kernel(struct blorp_context > *blorp, > > void *mem_ctx = ralloc_context(NULL); > > > > const unsigned *program; > > - unsigned program_size; > > struct brw_wm_prog_data prog_data; > > > > nir_shader *nir = brw_blorp_build_nir_shader(blorp, mem_ctx, > prog_key); > > @@ -1322,11 +1321,11 @@ brw_blorp_get_blit_kernel(struct blorp_context > *blorp, > > wm_key.multisample_fbo = prog_key->rt_samples > 1; > > > > program = blorp_compile_fs(blorp, mem_ctx, nir, &wm_key, false, > > - &prog_data, &program_size); > > + &prog_data); > > > > bool result = > >blorp->upload_shader(blorp, prog_key, sizeof(*prog_key), > > - program, program_size, > > + program, prog_data.base.program_size, > > &prog_data.base, sizeof(prog_data), > > ¶ms->wm_prog_kernel, > ¶ms->wm_prog_data); > > > > diff --git a/src/intel/blorp/blorp_clear.c > b/src/intel/blorp/blorp_clear.c > > index cd83fa13caf..8d758df155f 100644 > > --- a/src/intel/blorp/blorp_clear.c > > +++ b/src/intel/blorp/blorp_clear.c > > @@ -75,14 +75,13 @@ blorp_params_get_clear_kernel(struct blorp_context > *blorp, > > brw_blorp_init
Re: [Mesa-dev] [PATCH v3] egl/wayland: Support for KHR_partial_update
Hi Emil, Emil Velikov writes: > On 23 October 2017 at 11:50, Harish Krupo wrote: >> This passes 33/37 deqp tests related to partial_update, 4 are not >> supported. Tests not supported: >> dEQP-EGL.functional.negative_partial_update.not_postable_surface >> dEQP-EGL.functional.negative_partial_update.not_current_surface >> dEQP-EGL.functional.negative_partial_update.buffer_preserved >> dEQP-EGL.functional.negative_partial_update.not_current_surface2 >> Reason: No matching egl config found. >> >> v2: Remove unnecessary return statement. Keep function names >> consistent. (Emil Velikov) >> Add not supported list to commit message. (Eric Engestrom) >> >> v3: Remove explicit with_damage variable. (Eric Engestrom) >> > Did you send the wrong version by any chance? > The summary does not reflect the actual changes. > Sorry, should have actually been: v3: Remove explicit with_damage variable and swap_buffers_common function. Make SwapBuffers and SwapBuffersWithDamage(NULL,0) equivalent in behavior. Fix called via comment for swap_buffers_with_damage. (Eric Engestrom) Rework try_buffer_damage into set_damage_region as it is being called only from set_damage_region. > Why did you rework try_damage_buffer into dri2_wl_set_damage_region? > It seems harder to follow over the previous patches. > As try_damage_buffer was being used only in dri2_wl_set_damage_region and swap_buffers_with_damage was calling set_damage_region so I removed the unnecessary (extra) call to try_damage_region from set_damage_region and reworked try_damage_region to set_damage_region. Do we need to keep try_damage_region? If so, I will break them into two separate functions. > >> @@ -928,7 +944,8 @@ dri2_wl_query_buffer_age(_EGLDriver *drv, >> static EGLBoolean >> dri2_wl_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw) >> { >> - return dri2_wl_swap_buffers_with_damage(drv, disp, draw, NULL, 0); >> + return dri2_wl_swap_buffers_with_damage(drv, disp, draw, >> + NULL, 0); > > Unrelated noop change. > I had previously broken it into two lines to accomodate the EGL_TRUE change. After removing it I forgot to set it back to the same line. Will fix this. Thank you Regards Harish Krupo > Thanks > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fix GL_{COLOR, DEPTH, STENCIL}_COMPONENTS queries for TBOs
From: Marek Olšák --- src/mesa/main/formatquery.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c index 05b7810..9c53d7c 100644 --- a/src/mesa/main/formatquery.c +++ b/src/mesa/main/formatquery.c @@ -1094,43 +1094,54 @@ _mesa_GetInternalformativ(GLenum target, GLenum internalformat, GLenum pname, } case GL_COLOR_COMPONENTS: /* The ARB_internalformat_query2 spec says: * * "- COLOR_COMPONENTS: If the internal format contains any color * components (R, G, B, or A), TRUE is returned in . * If the internal format is unsupported or contains no color * components, FALSE is returned." */ + if (target == GL_TEXTURE_BUFFER && + _mesa_validate_texbuffer_format(ctx, internalformat) == + MESA_FORMAT_NONE) + break; + if (_mesa_is_color_format(internalformat)) buffer[0] = GL_TRUE; break; case GL_DEPTH_COMPONENTS: /* The ARB_internalformat_query2 spec says: * * "- DEPTH_COMPONENTS: If the internal format contains a depth * component (D), TRUE is returned in . If the internal format * is unsupported or contains no depth component, FALSE is returned." */ + if (target == GL_TEXTURE_BUFFER) + break; + if (_mesa_is_depth_format(internalformat) || _mesa_is_depthstencil_format(internalformat)) buffer[0] = GL_TRUE; break; case GL_STENCIL_COMPONENTS: /* The ARB_internalformat_query2 spec says: * * "- STENCIL_COMPONENTS: If the internal format contains a stencil * component (S), TRUE is returned in . If the internal format * is unsupported or contains no stencil component, FALSE is returned. */ + if (target == GL_TEXTURE_BUFFER) + break; + if (_mesa_is_stencil_format(internalformat) || _mesa_is_depthstencil_format(internalformat)) buffer[0] = GL_TRUE; break; case GL_COLOR_RENDERABLE: case GL_DEPTH_RENDERABLE: case GL_STENCIL_RENDERABLE: if (!_is_renderable(ctx, internalformat)) goto end; -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix GL_{COLOR, DEPTH, STENCIL}_COMPONENTS queries for TBOs
On Mon, Oct 23, 2017 at 9:16 PM, Marek Olšák wrote: > From: Marek Olšák > > --- > src/mesa/main/formatquery.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c > index 05b7810..9c53d7c 100644 > --- a/src/mesa/main/formatquery.c > +++ b/src/mesa/main/formatquery.c > @@ -1094,43 +1094,54 @@ _mesa_GetInternalformativ(GLenum target, GLenum > internalformat, GLenum pname, > } > > case GL_COLOR_COMPONENTS: >/* The ARB_internalformat_query2 spec says: > * > * "- COLOR_COMPONENTS: If the internal format contains any color > * components (R, G, B, or A), TRUE is returned in . > * If the internal format is unsupported or contains no color > * components, FALSE is returned." > */ > + if (target == GL_TEXTURE_BUFFER && > + _mesa_validate_texbuffer_format(ctx, internalformat) == > + MESA_FORMAT_NONE) > + break; Because not all color formats are supported for TBO's, right? Although _mesa_is_color_format returns true for unsupported formats as well... although that's probably a separate bug. Reviewed-by: Ilia Mirkin > + >if (_mesa_is_color_format(internalformat)) > buffer[0] = GL_TRUE; >break; > > case GL_DEPTH_COMPONENTS: >/* The ARB_internalformat_query2 spec says: > * > * "- DEPTH_COMPONENTS: If the internal format contains a depth > * component (D), TRUE is returned in . If the internal > format > * is unsupported or contains no depth component, FALSE is > returned." > */ > + if (target == GL_TEXTURE_BUFFER) > + break; > + >if (_mesa_is_depth_format(internalformat) || >_mesa_is_depthstencil_format(internalformat)) > buffer[0] = GL_TRUE; >break; > > case GL_STENCIL_COMPONENTS: >/* The ARB_internalformat_query2 spec says: > * > * "- STENCIL_COMPONENTS: If the internal format contains a stencil > * component (S), TRUE is returned in . If the internal > format > * is unsupported or contains no stencil component, FALSE is > returned. > */ > + if (target == GL_TEXTURE_BUFFER) > + break; > + >if (_mesa_is_stencil_format(internalformat) || >_mesa_is_depthstencil_format(internalformat)) > buffer[0] = GL_TRUE; >break; > > case GL_COLOR_RENDERABLE: > case GL_DEPTH_RENDERABLE: > case GL_STENCIL_RENDERABLE: >if (!_is_renderable(ctx, internalformat)) > goto end; > -- > 2.7.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/5] FreeBSD compatibility patches
This set of patches includes a bunch of simple fixes from FreeBSD ports and a loader patch that fixes Wayland/EGL clients not reading GPU device name correctly on FreeBSD. Greg V (5): anv: add ETIME fallback define loader: use drmGetDeviceNameFromFd2 from libdrm compiler: define endian for FreeBSD winsys/svga/drm: add ERESTART define for *BSD util: use OpenBSD/NetBSD code on FreeBSD/DragonFly src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 5 src/intel/vulkan/anv_device.c | 4 +++ src/intel/vulkan/anv_gem.c | 4 +++ src/intel/vulkan/anv_queue.c | 4 +++ src/loader/loader.c| 36 +- src/mesa/main/compiler.h | 3 +++ src/util/u_endian.h| 2 +- 7 files changed, 22 insertions(+), 36 deletions(-) -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] anv: add ETIME fallback define
FreeBSD only has ETIMEDOUT, not ETIME --- src/intel/vulkan/anv_device.c | 4 src/intel/vulkan/anv_gem.c| 4 src/intel/vulkan/anv_queue.c | 4 3 files changed, 12 insertions(+) diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c index 67028e8da9..fab2a394ca 100644 --- a/src/intel/vulkan/anv_device.c +++ b/src/intel/vulkan/anv_device.c @@ -39,6 +39,10 @@ #include "genxml/gen7_pack.h" +#ifndef ETIME +#define ETIME ETIMEDOUT +#endif + static void compiler_debug_log(void *data, const char *fmt, ...) { } diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c index 34c0989108..4a885617ab 100644 --- a/src/intel/vulkan/anv_gem.c +++ b/src/intel/vulkan/anv_gem.c @@ -31,6 +31,10 @@ #include "anv_private.h" +#ifndef ETIME +#define ETIME ETIMEDOUT +#endif + static int anv_ioctl(int fd, unsigned long request, void *arg) { diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c index c6b2e01c62..b1662c1720 100644 --- a/src/intel/vulkan/anv_queue.c +++ b/src/intel/vulkan/anv_queue.c @@ -34,6 +34,10 @@ #include "genxml/gen7_pack.h" +#ifndef ETIME +#define ETIME ETIMEDOUT +#endif + VkResult anv_device_execbuf(struct anv_device *device, struct drm_i915_gem_execbuffer2 *execbuf, -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] util: use OpenBSD/NetBSD code on FreeBSD/DragonFly
Obtained from: FreeBSD ports --- src/util/u_endian.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/u_endian.h b/src/util/u_endian.h index b9d563dd43..7be33dd3a5 100644 --- a/src/util/u_endian.h +++ b/src/util/u_endian.h @@ -54,7 +54,7 @@ # define PIPE_ARCH_BIG_ENDIAN #endif -#elif defined(__OpenBSD__) || defined(__NetBSD__) +#elif defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__) || defined(__DragonFly__) #include #include -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] compiler: define endian for FreeBSD
Obtained from: FreeBSD ports --- src/mesa/main/compiler.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index 43a06b4313..8652aac36c 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -51,6 +51,9 @@ #if defined(__linux__) #include #define CPU_TO_LE32( x ) bswap_32( x ) +#elif defined(__FreeBSD__) +#include +#define CPU_TO_LE32( x ) bswap32( x ) #elif defined(__APPLE__) #include #define CPU_TO_LE32( x ) CFSwapInt32HostToLittle( x ) -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] loader: use drmGetDeviceNameFromFd2 from libdrm
Reduce code duplication and automatically benefit from OS-specific fixes to libdrm (e.g. in FreeBSD ports). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103283 --- src/loader/loader.c | 36 +--- 1 file changed, 1 insertion(+), 35 deletions(-) diff --git a/src/loader/loader.c b/src/loader/loader.c index 182ba90a0d..f7f85e37c2 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -244,29 +244,6 @@ int loader_get_user_preferred_fd(int default_fd, bool *different_device) } #endif -#if defined(HAVE_LIBDRM) -static int -dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min) -{ - struct stat buf; - - if (fstat(fd, &buf) < 0) { - log_(_LOADER_WARNING, "MESA-LOADER: failed to stat fd %d\n", fd); - return -1; - } - - if (!S_ISCHR(buf.st_mode)) { - log_(_LOADER_WARNING, "MESA-LOADER: fd %d not a character device\n", fd); - return -1; - } - - *maj = major(buf.st_rdev); - *min = minor(buf.st_rdev); - - return 0; -} -#endif - #if defined(HAVE_LIBDRM) static int @@ -312,18 +289,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id) static char * drm_get_device_name_for_fd(int fd) { - unsigned int maj, min; - char buf[0x40]; - int n; - - if (dev_node_from_fd(fd, &maj, &min) < 0) - return NULL; - - n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, min); - if (n == -1 || n >= sizeof(buf)) - return NULL; - - return strdup(buf); + return drmGetDeviceNameFromFd2(fd); } #endif -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: intel: correctly append to the LIBADD variable
On 2017年10月23日 20:29, Emil Velikov wrote: From: Emil Velikov Commit 05fc62d89f5 sets the variable, yet it forgot the update the existing reference to append (instead of assign). Thus as-is the expat library was discarded from the link chain when building with Android. Fixes: 05fc62d89f5 ("automake: intel: move expat handling where it's used") Cc: Hongxu Jia Thanks for pointing it out //Hongxu Signed-off-by: Emil Velikov --- src/intel/Makefile.common.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am index 894dbb5208c..443cefc522a 100644 --- a/src/intel/Makefile.common.am +++ b/src/intel/Makefile.common.am @@ -27,5 +27,5 @@ common_libintel_common_la_LIBADD = $(EXPAT_LIBS) if HAVE_PLATFORM_ANDROID common_libintel_common_la_CFLAGS += $(ANDROID_CFLAGS) -common_libintel_common_la_LIBADD = $(ANDROID_LIBS) +common_libintel_common_la_LIBADD += $(ANDROID_LIBS) endif ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] winsys/svga/drm: add ERESTART define for *BSD
Obtained from: FreeBSD ports --- src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c index 79f9d950d9..62a2af6d65 100644 --- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c +++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c @@ -70,6 +70,11 @@ vmw_region_size(struct vmw_region *region) return region->size; } +#if defined(__DragonFly__) || defined(__FreeBSD__) || \ +defined(__NetBSD__) || defined(__OpenBSD__) +#define ERESTART EINTR +#endif + uint32 vmw_ioctl_context_create(struct vmw_winsys_screen *vws) { -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] compiler: define endian for FreeBSD
On 10/23/2017 02:20 PM, Greg V wrote: Obtained from: FreeBSD ports --- src/mesa/main/compiler.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index 43a06b4313..8652aac36c 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -51,6 +51,9 @@ #if defined(__linux__) #include #define CPU_TO_LE32( x ) bswap_32( x ) +#elif defined(__FreeBSD__) +#include +#define CPU_TO_LE32( x ) bswap32( x ) #elif defined(__APPLE__) #include #define CPU_TO_LE32( x ) CFSwapInt32HostToLittle( x ) I think "compiler:" in the subject line could be just "mesa:". Otherwise, for patches 3,4,5: Reviewed-by: Brian Paul I'll leave 1,2 to others. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 21/34] i965: add initial implementation of on disk shader cache
I made one minor comment below. Reviewed-by: Jason Ekstrand On Sun, Oct 22, 2017 at 1:01 PM, Jordan Justen wrote: > From: Timothy Arceri > > This uses the recently-added disk_cache.c to write out the final > linked binary for vertex and fragment shader programs. > > This is based off the initial implementation done by Carl Worth. > > v2: > * Squash 'i965: add image param shader cache support' > * Squash 'i965: add shader cache support for pull param pointers' > * Sustantially simplified by a rework on top of Jason's 2975e4c56a7a. > * Rename load_program_data to read_program_data. (Jason) > > v3: > * Simplify and align program read/write. (Jason) > > [jordan.l.jus...@intel.com: *_cached_program => brw_disk_cache_*_program] > [jordan.l.jus...@intel.com: brw_shader_cache.c => brw_disk_cache.c] > [jordan.l.jus...@intel.com: don't map to write program when LLC is > present] > [jordan.l.jus...@intel.com: set program_written_to_cache on read from > cache] > [jordan.l.jus...@intel.com: only try cache when status is linking_skipped] > [jordan.l.jus...@intel.com: rework based on uniforms rework 2975e4c56a7a] > [jordan.l.jus...@intel.com: Simplify and align program read/write] > Signed-off-by: Jordan Justen > --- > src/mesa/drivers/dri/i965/Makefile.sources | 1 + > src/mesa/drivers/dri/i965/brw_disk_cache.c | 329 > + > src/mesa/drivers/dri/i965/brw_state.h | 5 + > src/mesa/drivers/dri/i965/meson.build | 1 + > 4 files changed, 336 insertions(+) > create mode 100644 src/mesa/drivers/dri/i965/brw_disk_cache.c > > diff --git a/src/mesa/drivers/dri/i965/Makefile.sources > b/src/mesa/drivers/dri/i965/Makefile.sources > index 053d89b81ec..2980cdb3c54 100644 > --- a/src/mesa/drivers/dri/i965/Makefile.sources > +++ b/src/mesa/drivers/dri/i965/Makefile.sources > @@ -14,6 +14,7 @@ i965_FILES = \ > brw_cs.h \ > brw_curbe.c \ > brw_defines.h \ > + brw_disk_cache.c \ > brw_draw.c \ > brw_draw.h \ > brw_draw_upload.c \ > diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c > b/src/mesa/drivers/dri/i965/brw_disk_cache.c > new file mode 100644 > index 000..186cbe83706 > --- /dev/null > +++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c > @@ -0,0 +1,329 @@ > +/* > + * Copyright © 2014 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the > "Software"), > + * to deal in the Software without restriction, including without > limitation > + * the rights to use, copy, modify, merge, publish, distribute, > sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the > next > + * paragraph) shall be included in all copies or substantial portions of > the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS > + * IN THE SOFTWARE. > + */ > + > +#include "compiler/blob.h" > +#include "compiler/glsl/ir_uniform.h" > +#include "compiler/glsl/shader_cache.h" > +#include "main/mtypes.h" > +#include "util/disk_cache.h" > +#include "util/macros.h" > +#include "util/mesa-sha1.h" > + > +#include "brw_context.h" > +#include "brw_state.h" > +#include "brw_vs.h" > +#include "brw_wm.h" > + > +static void > +gen_shader_sha1(struct brw_context *brw, struct gl_program *prog, > +gl_shader_stage stage, void *key, unsigned char *out_sha1) > +{ > + char sha1_buf[41]; > + unsigned char sha1[20]; > + char manifest[256]; > + int offset = 0; > + > + _mesa_sha1_format(sha1_buf, prog->sh.data->sha1); > + offset += snprintf(manifest, sizeof(manifest), "program: %s\n", > sha1_buf); > + > + _mesa_sha1_compute(key, brw_prog_key_size(stage), sha1); > + _mesa_sha1_format(sha1_buf, sha1); > + offset += snprintf(manifest + offset, sizeof(manifest) - offset, > + "%s_key: %s\n", _mesa_shader_stage_to_abbrev( > stage), > + sha1_buf); > + > + _mesa_sha1_compute(manifest, strlen(manifest), out_sha1); > +} > + > +static void > +write_blob_program_data(struct blob *binary, const void *program, > +size_t program_size, > +struct brw_stage_prog_data *prog_data, > +size_t prog_data_size) > +{ > + /* Write program to blob. */ > + blob_write_uint32(binary, program_size); >
Re: [Mesa-dev] [PATCH v3 00/34] i965 disk shader cache
I didn't re-read every thing in v3 but I did read all of v2 on Friday. Assuming you didn't make any massive changes other than those detailed here, the series is Reviewed-by: Jason Ekstrand Except, of course, for the couple of patches written by me. Also, I can't really say I properly reviewed the nir_serialize patch so best to keep that one to an Ack. I think Ken still has some right of review here and, since it's not going in 17.3, we do have some time. Hopefully me reviewing it will give him a bit more confidence. :-) --Jason On Mon, Oct 23, 2017 at 2:42 PM, Jordan Justen wrote: > On 2017-10-22 13:01:08, Jordan Justen wrote: > > > > Patch code review status: > > > > mesa/glsl: add api_enabled flag to gl_transform_feedback_info > > > > i965: add support for cached shaders with xfb qualifiers > > It sounds like Tim has a plan for supporting shader cache with > transform feedback, but for now these two are: > > Reviewed-by: Jordan Justen > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: only emit dfsm packets if dfsm is allowed.
From: Dave Airlie radeonsi only emits these when dfsm is enabled, so for now just hinge them on a flag we never set. Signed-off-by: Dave Airlie --- src/amd/vulkan/radv_cmd_buffer.c | 6 +++--- src/amd/vulkan/radv_private.h| 1 + 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index ba382c8691b..807283be1d8 100644 --- a/src/amd/vulkan/radv_cmd_buffer.c +++ b/src/amd/vulkan/radv_cmd_buffer.c @@ -551,7 +551,7 @@ radv_update_multisample_state(struct radv_cmd_buffer *cmd_buffer, radv_cayman_emit_msaa_sample_locs(cmd_buffer->cs, num_samples); /* GFX9: Flush DFSM when the AA mode changes. */ - if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) { + if (cmd_buffer->device->dfsm_allowed) { radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0)); radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) | EVENT_INDEX(0)); } @@ -956,7 +956,7 @@ radv_emit_fragment_shader(struct radv_cmd_buffer *cmd_buffer, radeon_set_context_reg(cmd_buffer->cs, R_028238_CB_TARGET_MASK, blend->cb_target_mask); radeon_set_context_reg(cmd_buffer->cs, R_02823C_CB_SHADER_MASK, blend->cb_shader_mask); - if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) { + if (cmd_buffer->device->dfsm_allowed) { /* optimise this? */ radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0)); radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) | EVENT_INDEX(0)); @@ -1443,7 +1443,7 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer *cmd_buffer) S_028208_BR_X(framebuffer->width) | S_028208_BR_Y(framebuffer->height)); - if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) { + if (cmd_buffer->device->dfsm_allowed) { radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0)); radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_BREAK_BATCH) | EVENT_INDEX(0)); } diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h index a4e52b25306..83529015c5d 100644 --- a/src/amd/vulkan/radv_private.h +++ b/src/amd/vulkan/radv_private.h @@ -531,6 +531,7 @@ struct radv_device { bool llvm_supports_spill; bool has_distributed_tess; + bool dfsm_allowed; uint32_t tess_offchip_block_dw_size; uint32_t scratch_waves; -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: enum checks for GL_EXT_occlusion_query_boolean
gentle ping .. (after this we could also enable GL_EXT_disjoint_timer_query and have more queries available for gles) On 10/04/2017 02:56 PM, Tapani Pälli wrote: Some of the checks are valid for generic ES 3.2 as well. Signed-off-by: Tapani Pälli --- src/mesa/main/queryobj.c | 44 1 file changed, 44 insertions(+) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index 46535d7b4c..d966814a76 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -165,6 +165,20 @@ get_pipe_stats_binding_point(struct gl_context *ctx, static struct gl_query_object ** get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index) { + + /* From GL_EXT_occlusion_query_boolean spec: +* +*"Accepted by the parameter of BeginQueryEXT, EndQueryEXT, +*and GetQueryivEXT: +* +* ANY_SAMPLES_PASSED_EXT 0x8C2F +* ANY_SAMPLES_PASSED_CONSERVATIVE_EXT0x8D6A" +*/ + if ((_mesa_is_gles(ctx) && ctx->Version == 20) && + (target != GL_ANY_SAMPLES_PASSED && +target != GL_ANY_SAMPLES_PASSED_CONSERVATIVE)) + return NULL; + switch (target) { case GL_SAMPLES_PASSED_ARB: if (ctx->Extensions.ARB_occlusion_query) @@ -649,6 +663,19 @@ _mesa_GetQueryIndexediv(GLenum target, GLuint index, GLenum pname, if (!query_error_check_index(ctx, target, index)) return; + /* From the GL_EXT_occlusion_query_boolean spec: +* +* "The error INVALID_ENUM is generated if GetQueryivEXT is called where +* is not CURRENT_QUERY_EXT." +* +* Same rule is present also in ES 3.2 spec. +*/ + if (_mesa_is_gles(ctx) && pname != GL_CURRENT_QUERY) { + _mesa_error(ctx, GL_INVALID_ENUM, "glGetQueryivEXT(%s)", + _mesa_enum_to_string(pname)); + return; + } + if (target == GL_TIMESTAMP) { if (!ctx->Extensions.ARB_timer_query) { _mesa_error(ctx, GL_INVALID_ENUM, "glGetQueryARB(target)"); @@ -775,6 +802,23 @@ get_query_object(struct gl_context *ctx, const char *func, return; } + /* From GL_EXT_occlusion_query_boolean spec: +* +*"Accepted by the parameter of GetQueryObjectivEXT and +*GetQueryObjectuivEXT: +* +*QUERY_RESULT_EXT 0x8866 +*QUERY_RESULT_AVAILABLE_EXT 0x8867" +* +* Same rule is present also in ES 3.2 spec. +*/ + if (_mesa_is_gles(ctx) && + (pname != GL_QUERY_RESULT && pname != GL_QUERY_RESULT_AVAILABLE)) { + _mesa_error(ctx, GL_INVALID_ENUM, "%s(%s)", func, + _mesa_enum_to_string(pname)); + return; + } + if (buf && buf != ctx->Shared->NullBufferObj) { bool is_64bit = ptype == GL_INT64_ARB || ptype == GL_UNSIGNED_INT64_ARB; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Don't disable CCS for RT dependencies when dispatching compute.
Compute shaders don't have access to the framebuffer, so there's no point in worrying whether a texture is bound as a render target. This saves a bunch of resolves in GFXBench4 Manhattan 3.1, but doesn't seem to impact performance at all, at least on Apollolake. --- src/mesa/drivers/dri/i965/brw_compute.c | 2 +- src/mesa/drivers/dri/i965/brw_context.h | 2 +- src/mesa/drivers/dri/i965/brw_draw.c| 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_compute.c b/src/mesa/drivers/dri/i965/brw_compute.c index c1b2df590b7..9be7523bab3 100644 --- a/src/mesa/drivers/dri/i965/brw_compute.c +++ b/src/mesa/drivers/dri/i965/brw_compute.c @@ -177,7 +177,7 @@ brw_dispatch_compute_common(struct gl_context *ctx) brw_validate_textures(brw); - brw_predraw_resolve_inputs(brw); + brw_predraw_resolve_inputs(brw, false); /* Flush the batch if the batch/state buffers are nearly full. We can * grow them if needed, but this is not free, so we'd like to avoid it. diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 26e71e62b54..0102f154248 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -1234,7 +1234,7 @@ void intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable); void intel_prepare_render(struct brw_context *brw); -void brw_predraw_resolve_inputs(struct brw_context *brw); +void brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering); void intel_resolve_for_dri2_flush(struct brw_context *brw, __DRIdrawable *drawable); diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index b74ab8bde23..80d4891f6f6 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -381,7 +381,7 @@ intel_disable_rb_aux_buffer(struct brw_context *brw, * enabled depth texture, and flush the render cache for any dirty textures. */ void -brw_predraw_resolve_inputs(struct brw_context *brw) +brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering) { struct gl_context *ctx = &brw->ctx; struct intel_texture_object *tex_obj; @@ -416,7 +416,7 @@ brw_predraw_resolve_inputs(struct brw_context *brw) num_layers = INTEL_REMAINING_LAYERS; } - const bool disable_aux = + const bool disable_aux = rendering && intel_disable_rb_aux_buffer(brw, tex_obj->mt, min_level, num_levels, "for sampling"); @@ -678,7 +678,7 @@ brw_prepare_drawing(struct gl_context *ctx, * and finalizing textures but before setting up any hardware state for * this draw call. */ - brw_predraw_resolve_inputs(brw); + brw_predraw_resolve_inputs(brw, true); brw_predraw_resolve_framebuffer(brw); /* Bind all inputs, derive varying and size information: -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't disable CCS for RT dependencies when dispatching compute.
Rb On October 23, 2017 22:21:47 Kenneth Graunke wrote: Compute shaders don't have access to the framebuffer, so there's no point in worrying whether a texture is bound as a render target. This saves a bunch of resolves in GFXBench4 Manhattan 3.1, but doesn't seem to impact performance at all, at least on Apollolake. --- src/mesa/drivers/dri/i965/brw_compute.c | 2 +- src/mesa/drivers/dri/i965/brw_context.h | 2 +- src/mesa/drivers/dri/i965/brw_draw.c| 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_compute.c b/src/mesa/drivers/dri/i965/brw_compute.c index c1b2df590b7..9be7523bab3 100644 --- a/src/mesa/drivers/dri/i965/brw_compute.c +++ b/src/mesa/drivers/dri/i965/brw_compute.c @@ -177,7 +177,7 @@ brw_dispatch_compute_common(struct gl_context *ctx) brw_validate_textures(brw); - brw_predraw_resolve_inputs(brw); + brw_predraw_resolve_inputs(brw, false); /* Flush the batch if the batch/state buffers are nearly full. We can * grow them if needed, but this is not free, so we'd like to avoid it. diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 26e71e62b54..0102f154248 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -1234,7 +1234,7 @@ void intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable); void intel_prepare_render(struct brw_context *brw); -void brw_predraw_resolve_inputs(struct brw_context *brw); +void brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering); void intel_resolve_for_dri2_flush(struct brw_context *brw, __DRIdrawable *drawable); diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index b74ab8bde23..80d4891f6f6 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -381,7 +381,7 @@ intel_disable_rb_aux_buffer(struct brw_context *brw, * enabled depth texture, and flush the render cache for any dirty textures. */ void -brw_predraw_resolve_inputs(struct brw_context *brw) +brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering) { struct gl_context *ctx = &brw->ctx; struct intel_texture_object *tex_obj; @@ -416,7 +416,7 @@ brw_predraw_resolve_inputs(struct brw_context *brw) num_layers = INTEL_REMAINING_LAYERS; } - const bool disable_aux = + const bool disable_aux = rendering && intel_disable_rb_aux_buffer(brw, tex_obj->mt, min_level, num_levels, "for sampling"); @@ -678,7 +678,7 @@ brw_prepare_drawing(struct gl_context *ctx, * and finalizing textures but before setting up any hardware state for * this draw call. */ - brw_predraw_resolve_inputs(brw); + brw_predraw_resolve_inputs(brw, true); brw_predraw_resolve_framebuffer(brw); /* Bind all inputs, derive varying and size information: -- 2.14.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get
On Mon, 23 Oct 2017 16:41:14 +0100 Daniel Stone wrote: > Hi Emil, > > On 28 September 2017 at 13:36, Emil Velikov wrote: > > On 20 September 2017 at 15:06, Daniel Stone wrote: > >> On 19 September 2017 at 11:25, Emil Velikov > >> wrote: > >>> It looks a bit icky and my Wayland knowledge is limited to actually > >>> review it. > >>> > >>> I still think that we're trying to do different things - me simplify > >>> things, while you're focusing on fixing a bug. > >> > >> I like the idea of the simplification, but it's just that a) it can't > >> actually be simplified that far, and b) whilst we still rely on > >> consistent resolution of wl_buffer_interface, your proposed change may > >> actually _introduce_ a bug. > > > > Right, I did not see that one. Can you share your train of thought? > > Happily! > > When a compositor creates a client buffer, the request is dispatched > by libwayland-server.so into libEGL.so (libEGL explicitly links > libwayland-server). This lands in > src/egl/wayland/wayland-drm/wayland-drm.c's create_buffer(), which > calls wl_resource_create() with 'wl_buffer_interface'. Since libEGL.so > is explicitly linked against both libwayland-client and > libwayland-server, and both of those DSOs provide a resolution of > wl_buffer_interface, resource->interface could be > libwayland-server.so::wl_buffer_interface, or > libwayland-client.so::wl_buffer_interface. > > When a compositor wants to import a buffer into GBM, it calls > gbm_bo_import(), which will call wl_drm_buffer_get(). > wl_drm_buffer_get will test (resource->interface == > &wl_buffer_interface). Previously, both create_buffer() and > wl_drm_buffer_get() at least came from the same compilation unit, but > now they are built and linked separately. This seems to make an > existing problem (ambiguity of 'wl_buffer_interface') worse (symbol > resolution now performed in separate compilation units). Hi, this is not the whole truth. At least, if wl_drm_buffer_get() uses wl_resource_instance_of() rather than open-coding a broken version of the same. > I don't really see a solution to this, apart from no longer relying on > having a single canonical resolution of wl_buffer_interface. The above > patch implements that, by removing the interface-address-equal test > and replacing it with the destroy-listener test. The patch I provided > is equally valid both with and without your series. There is no relying on having a single canonical resolution of wl_buffer_interface, and there has never been as long as any part of libwayland has been stable. See: https://cgit.freedesktop.org/wayland/wayland/tree/src/connection.c?id=0.99.0#n840 I suppose one might argue that libwayland-server and libwayland-client might be different versions in some wacky distribution, but that argument is moot because wl_buffer_interface can never change due to the multiple factory interfaces issue. Thanks, pq pgp8WroCrBCuk.pgp Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: enable nir path for all shaders.
Reviewed-by: Timothy Arceri On 24/10/17 09:44, Dave Airlie wrote: From: Dave Airlie There is no reason to block this here, if a driver enables it, let it handle it. Signed-off-by: Dave Airlie --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index a45f0047a8..9599402056 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -6976,15 +6976,7 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) struct gl_program *linked_prog = NULL; if (preferred_ir == PIPE_SHADER_IR_NIR) { - /* TODO only for GLSL VS/FS/CS for now: */ - switch (shader->Stage) { - case MESA_SHADER_VERTEX: - case MESA_SHADER_FRAGMENT: - case MESA_SHADER_COMPUTE: -linked_prog = st_nir_get_mesa_program(ctx, prog, shader); - default: -break; - } + linked_prog = st_nir_get_mesa_program(ctx, prog, shader); } else { linked_prog = get_mesa_program_tgsi(ctx, prog, shader); } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/program: add support for gs/tes/tcs nir shaders.
Series: Reviewed-by: Timothy Arceri On 24/10/17 09:41, Dave Airlie wrote: From: Dave Airlie This probably needs more work but this just add the initial code to convert gs/tcs/tes nir based shaders in the state tracker. Signed-off-by: Dave Airlie --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 12 + src/mesa/state_tracker/st_program.c | 45 --- src/mesa/state_tracker/st_program.h | 3 +++ 3 files changed, 56 insertions(+), 4 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker/st_glsl_to_nir.cpp index 4effd8074e..e9a8d6414e 100644 --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp @@ -359,6 +359,11 @@ st_finalize_nir(struct st_context *st, struct gl_program *prog, nir_shader *nir) case MESA_SHADER_VERTEX: shader_program = ((struct st_vertex_program *)prog)->shader_program; break; + case MESA_SHADER_GEOMETRY: + case MESA_SHADER_TESS_CTRL: + case MESA_SHADER_TESS_EVAL: + shader_program = ((struct st_common_program *)prog)->shader_program; + break; case MESA_SHADER_FRAGMENT: shader_program = ((struct st_fragment_program *)prog)->shader_program; break; @@ -451,6 +456,7 @@ st_nir_get_mesa_program(struct gl_context *ctx, _mesa_associate_uniform_storage(ctx, shader_program, prog, true); struct st_vertex_program *stvp; + struct st_common_program *stp; struct st_fragment_program *stfp; struct st_compute_program *stcp; @@ -459,6 +465,12 @@ st_nir_get_mesa_program(struct gl_context *ctx, stvp = (struct st_vertex_program *)prog; stvp->shader_program = shader_program; break; + case MESA_SHADER_GEOMETRY: + case MESA_SHADER_TESS_CTRL: + case MESA_SHADER_TESS_EVAL: + stp = (struct st_common_program *)prog; + stp->shader_program = shader_program; + break; case MESA_SHADER_FRAGMENT: stfp = (struct st_fragment_program *)prog; stfp->shader_program = shader_program; diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index 1695f4835d..335d45ba28 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -1576,6 +1576,16 @@ st_translate_geometry_program(struct st_context *st, { struct ureg_program *ureg; + if (stgp->shader_program) { + nir_shader *nir = st_glsl_to_nir(st, &stgp->Base, stgp->shader_program, + MESA_SHADER_GEOMETRY); + + stgp->tgsi.type = PIPE_SHADER_IR_NIR; + stgp->tgsi.ir.nir = nir; + + return true; + } + ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen); if (ureg == NULL) return false; @@ -1609,7 +1619,7 @@ st_get_basic_variant(struct st_context *st, struct pipe_context *pipe = st->pipe; struct st_basic_variant *v; struct st_basic_variant_key key; - + struct pipe_shader_state tgsi = {0}; memset(&key, 0, sizeof(key)); key.st = st->has_shareable_shaders ? NULL : st; @@ -1624,16 +1634,23 @@ st_get_basic_variant(struct st_context *st, /* create new */ v = CALLOC_STRUCT(st_basic_variant); if (v) { + +if (prog->tgsi.type == PIPE_SHADER_IR_NIR) { + tgsi.type = PIPE_SHADER_IR_NIR; + tgsi.ir.nir = nir_shader_clone(NULL, prog->tgsi.ir.nir); + st_finalize_nir(st, &prog->Base, tgsi.ir.nir); +} else + tgsi = prog->tgsi; /* fill in new variant */ switch (pipe_shader) { case PIPE_SHADER_TESS_CTRL: -v->driver_shader = pipe->create_tcs_state(pipe, &prog->tgsi); +v->driver_shader = pipe->create_tcs_state(pipe, &tgsi); break; case PIPE_SHADER_TESS_EVAL: -v->driver_shader = pipe->create_tes_state(pipe, &prog->tgsi); +v->driver_shader = pipe->create_tes_state(pipe, &tgsi); break; case PIPE_SHADER_GEOMETRY: -v->driver_shader = pipe->create_gs_state(pipe, &prog->tgsi); +v->driver_shader = pipe->create_gs_state(pipe, &tgsi); break; default: assert(!"unhandled shader type"); @@ -1662,6 +1679,16 @@ st_translate_tessctrl_program(struct st_context *st, { struct ureg_program *ureg; + if (sttcp->shader_program) { + nir_shader *nir = st_glsl_to_nir(st, &sttcp->Base, sttcp->shader_program, + MESA_SHADER_TESS_EVAL); + + sttcp->tgsi.type = PIPE_SHADER_IR_NIR; + sttcp->tgsi.ir.nir = nir; + + return true; + } + ureg = ureg_create_with_screen(PIPE_SHADER_TESS_CTRL, st->pipe->screen); if (ureg == NULL) return false; @@ -1687,6 +1714,16 @@ st_translate_tesseval_program(struct st_context *st, { struct ureg_program *ureg; + if (sttep->shader_program) { + nir_shader *n
Re: [Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get
On Mon, 23 Oct 2017 18:05:12 +0100 Emil Velikov wrote: > On 23 October 2017 at 16:41, Daniel Stone wrote: > > Hi Emil, > > > > On 28 September 2017 at 13:36, Emil Velikov > > wrote: > >> On 20 September 2017 at 15:06, Daniel Stone wrote: > >>> On 19 September 2017 at 11:25, Emil Velikov > >>> wrote: > It looks a bit icky and my Wayland knowledge is limited to actually > review it. > > I still think that we're trying to do different things - me simplify > things, while you're focusing on fixing a bug. > >>> > >>> I like the idea of the simplification, but it's just that a) it can't > >>> actually be simplified that far, and b) whilst we still rely on > >>> consistent resolution of wl_buffer_interface, your proposed change may > >>> actually _introduce_ a bug. > >> > >> Right, I did not see that one. Can you share your train of thought? > > > > Happily! > > > > When a compositor creates a client buffer, the request is dispatched > > by libwayland-server.so into libEGL.so (libEGL explicitly links > > libwayland-server). This lands in > > src/egl/wayland/wayland-drm/wayland-drm.c's create_buffer(), which > > calls wl_resource_create() with 'wl_buffer_interface'. Since libEGL.so > > is explicitly linked against both libwayland-client and > > libwayland-server, and both of those DSOs provide a resolution of > > wl_buffer_interface, resource->interface could be > > libwayland-server.so::wl_buffer_interface, or > > libwayland-client.so::wl_buffer_interface. > > > > When a compositor wants to import a buffer into GBM, it calls > > gbm_bo_import(), which will call wl_drm_buffer_get(). > > wl_drm_buffer_get will test (resource->interface == > > &wl_buffer_interface). Previously, both create_buffer() and > > wl_drm_buffer_get() at least came from the same compilation unit, but > > now they are built and linked separately. This seems to make an > > existing problem (ambiguity of 'wl_buffer_interface') worse (symbol > > resolution now performed in separate compilation units). > > > > I don't really see a solution to this, apart from no longer relying on > > having a single canonical resolution of wl_buffer_interface. The above > > patch implements that, by removing the interface-address-equal test > > and replacing it with the destroy-listener test. The patch I provided > > is equally valid both with and without your series. > > > Ouch, that's something I did not expect looking at the Mesa code alone. > > Generally, this type of issues are not specific to Mesa, but come due > to the implementation/use of wl_resource_instance_of. Is that correct? > > I'm itching to bring back my suggestions to fix this in its root, but > let's ignore that for a moment ;-) > > Having a look at the wl_resource_instance_of() implementation > > WL_EXPORT int > wl_resource_instance_of(struct wl_resource *resource, >const struct wl_interface *interface, >const void *implementation) > { >return wl_interface_equal(resource->object.interface, interface) && >resource->object.implementation == implementation; > } > > ... and wl_interface_equal() > > int > wl_interface_equal(const struct wl_interface *a, const struct wl_interface *b) > { > /* In most cases the pointer equality test is sufficient. > * However, in some cases, depending on how things are split > * across shared objects, we can end up with multiple > * instances of the interface metadata constants. So if the > * pointers match, the interfaces are equal, if they don't > * match we have to compare the interface names. > */ > return a == b || strcmp(a->name, b->name) == 0; > } > > Am I reading it incorrectly, or you forgot about the name check? > It seems like the name check was added explicitly to workaround the > issue you're talking about. > > Thus wl_resource_instance_of() should return the same result with or > without my patch? > Or perhaps the interface check is safe, but the implementation one isn't? Hi Emil, your analysis is correct, there should be no problem. The implementation check is safe as well, because the thing that is being compared there is the 'struct wl_buffer_interface' pointer. Looking at your original patch, it seems that the implementation check ensures the wl_buffer was created with the specific 'struct wl_drm' instance and therefore has no relation to any DSO identity (I assume 'struct wl_drm' is allocated dynamically). Thanks, pq pgpOn5G0YUl2i.pgp Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965/blorp: Use more temporary isl_format variables
On Mon, Oct 23, 2017 at 05:23:08PM -0700, Jason Ekstrand wrote: > --- > src/mesa/drivers/dri/i965/brw_blorp.c | 15 +++ > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c > b/src/mesa/drivers/dri/i965/brw_blorp.c > index f7d128d..05204a9 100644 > --- a/src/mesa/drivers/dri/i965/brw_blorp.c > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c > @@ -329,6 +329,8 @@ brw_blorp_blit_miptrees(struct brw_context *brw, > intel_miptree_prepare_access(brw, src_mt, src_level, 1, src_layer, 1, > src_aux_usage, src_clear_supported); > > + enum isl_format dst_isl_format = > + brw_blorp_to_isl_format(brw, dst_format, true); > enum isl_aux_usage dst_aux_usage = >intel_miptree_render_aux_usage(brw, dst_mt, encode_srgb, false); > const bool dst_clear_supported = dst_aux_usage != ISL_AUX_USAGE_NONE; > @@ -352,10 +354,9 @@ brw_blorp_blit_miptrees(struct brw_context *brw, > struct blorp_batch batch; > blorp_batch_init(&brw->blorp, &batch, brw, 0); > blorp_blit(&batch, &src_surf, src_level, src_layer, > - brw_blorp_to_isl_format(brw, src_format, false), > src_isl_swizzle, > + src_isl_format, src_isl_swizzle, This is functional change, isn't it? It effectively switches from brw_blorp_to_isl_format() to brw_isl_format_for_mesa_format(). >&dst_surf, dst_level, dst_layer, > - brw_blorp_to_isl_format(brw, dst_format, true), > - ISL_SWIZZLE_IDENTITY, > + dst_isl_format, ISL_SWIZZLE_IDENTITY, >src_x0, src_y0, src_x1, src_y1, >dst_x0, dst_y0, dst_x1, dst_y1, >filter, mirror_x, mirror_y); > @@ -1158,6 +1159,7 @@ do_single_blorp_clear(struct brw_context *brw, struct > gl_framebuffer *fb, > mesa_format format = irb->Base.Base.Format; > if (!encode_srgb && _mesa_get_format_color_encoding(format) == GL_SRGB) >format = _mesa_get_srgb_format_linear(format); > + enum isl_format isl_format = brw->mesa_to_isl_render_format[format]; > > x0 = fb->_Xmin; > x1 = fb->_Xmax; > @@ -1256,8 +1258,7 @@ do_single_blorp_clear(struct brw_context *brw, struct > gl_framebuffer *fb, > >struct blorp_batch batch; >blorp_batch_init(&brw->blorp, &batch, brw, 0); > - blorp_fast_clear(&batch, &surf, > - brw->mesa_to_isl_render_format[format], > + blorp_fast_clear(&batch, &surf, isl_format, > level, irb->mt_layer, num_layers, > x0, y0, x1, y1); >blorp_batch_finish(&batch); > @@ -1290,9 +1291,7 @@ do_single_blorp_clear(struct brw_context *brw, struct > gl_framebuffer *fb, > >struct blorp_batch batch; >blorp_batch_init(&brw->blorp, &batch, brw, 0); > - blorp_clear(&batch, &surf, > - brw->mesa_to_isl_render_format[format], > - ISL_SWIZZLE_IDENTITY, > + blorp_clear(&batch, &surf, isl_format, ISL_SWIZZLE_IDENTITY, >level, irb->mt_layer, num_layers, >x0, y0, x1, y1, >clear_color, color_write_disable); > -- > 2.5.0.400.gff86faf > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 15/34] i965: Don't rely on nir for uses_texture_gather
On Sunday, October 22, 2017 1:01:23 PM PDT Jordan Justen wrote: > When a program is restored from the shader cache, prog->nir will be > NULL, but prog->info will be restored. > > Signed-off-by: Jordan Justen Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] i965: Call gen6_upload_push_constants() even when the stage is disabled.
On Mon, Oct 23, 2017 at 11:57:53AM -0700, Kenneth Graunke wrote: > This properly sets stage_state->push_constant_dirty = true, so that we > emit 3DSTATE_CONSTANT_XS to disable the constant buffer for the shader > stage. It also sets stage_state->push_const_size = 0. > --- > src/mesa/drivers/dri/i965/gen6_constant_state.c | 9 +++-- > src/mesa/drivers/dri/i965/genX_state_upload.c | 25 > + > 2 files changed, 16 insertions(+), 18 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c > b/src/mesa/drivers/dri/i965/gen6_constant_state.c > index 6b5d2e66cc9..acf7454cef5 100644 > --- a/src/mesa/drivers/dri/i965/gen6_constant_state.c > +++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c > @@ -130,9 +130,14 @@ gen6_upload_push_constants(struct brw_context *brw, > const struct gen_device_info *devinfo = &brw->screen->devinfo; > struct gl_context *ctx = &brw->ctx; > > - _mesa_shader_write_subroutine_indices(ctx, stage_state->stage); > + bool active = prog_data && > + (stage_state->stage != MESA_SHADER_TESS_CTRL || > + brw->programs[MESA_SHADER_TESS_EVAL]); Had to read this condition a few times but it looks to do exactly what you wrote in the commit. Series: Reviewed-by: Topi Pohjolainen > > - if (prog_data->nr_params == 0) { > + if (active) > + _mesa_shader_write_subroutine_indices(ctx, stage_state->stage); > + > + if (!active || prog_data->nr_params == 0) { >stage_state->push_const_size = 0; > } else { >/* Updates the ParamaterValues[i] pointers for all parameters of the > diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c > b/src/mesa/drivers/dri/i965/genX_state_upload.c > index f2b3e4570b2..4ccfd489191 100644 > --- a/src/mesa/drivers/dri/i965/genX_state_upload.c > +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c > @@ -3165,12 +3165,10 @@ genX(upload_gs_push_constants)(struct brw_context > *brw) > /* BRW_NEW_GEOMETRY_PROGRAM */ > const struct gl_program *gp = brw->programs[MESA_SHADER_GEOMETRY]; > > - if (gp) { > - /* BRW_NEW_GS_PROG_DATA */ > - struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data; > + /* BRW_NEW_GS_PROG_DATA */ > + struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data; > > - gen6_upload_push_constants(brw, gp, prog_data, stage_state); > - } > + gen6_upload_push_constants(brw, gp, prog_data, stage_state); > } > > static const struct brw_tracked_state genX(gs_push_constants) = { > @@ -4027,11 +4025,9 @@ genX(upload_tes_push_constants)(struct brw_context > *brw) > /* BRW_NEW_TESS_PROGRAMS */ > const struct gl_program *tep = brw->programs[MESA_SHADER_TESS_EVAL]; > > - if (tep) { > - /* BRW_NEW_TES_PROG_DATA */ > - const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data; > - gen6_upload_push_constants(brw, tep, prog_data, stage_state); > - } > + /* BRW_NEW_TES_PROG_DATA */ > + const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data; > + gen6_upload_push_constants(brw, tep, prog_data, stage_state); > } > > static const struct brw_tracked_state genX(tes_push_constants) = { > @@ -4051,14 +4047,11 @@ genX(upload_tcs_push_constants)(struct brw_context > *brw) > struct brw_stage_state *stage_state = &brw->tcs.base; > /* BRW_NEW_TESS_PROGRAMS */ > const struct gl_program *tcp = brw->programs[MESA_SHADER_TESS_CTRL]; > - bool active = brw->programs[MESA_SHADER_TESS_EVAL]; > > - if (active) { > - /* BRW_NEW_TCS_PROG_DATA */ > - const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data; > + /* BRW_NEW_TCS_PROG_DATA */ > + const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data; > > - gen6_upload_push_constants(brw, tcp, prog_data, stage_state); > - } > + gen6_upload_push_constants(brw, tcp, prog_data, stage_state); > } > > static const struct brw_tracked_state genX(tcs_push_constants) = { > -- > 2.14.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 19/34] intel/compiler: Add union types for prog_data and prog_key stages
On Sunday, October 22, 2017 1:01:27 PM PDT Jordan Justen wrote: > Signed-off-by: Jordan Justen > --- > src/intel/compiler/brw_compiler.h | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/src/intel/compiler/brw_compiler.h > b/src/intel/compiler/brw_compiler.h > index 701b4a80bf1..9359b767e35 100644 > --- a/src/intel/compiler/brw_compiler.h > +++ b/src/intel/compiler/brw_compiler.h > @@ -403,6 +403,15 @@ struct brw_cs_prog_key { > struct brw_sampler_prog_key_data tex; > }; > > +typedef union { > + struct brw_vs_prog_key vs; > + struct brw_tcs_prog_key tcs; > + struct brw_tes_prog_key tes; > + struct brw_gs_prog_key gs; > + struct brw_wm_prog_key wm; > + struct brw_cs_prog_key cs; > +} brw_any_prog_key; > + > /* > * Image metadata structure as laid out in the shader parameter > * buffer. Entries have to be 16B-aligned for the vec4 back-end to be > @@ -1066,6 +1075,15 @@ struct brw_clip_prog_data { > uint32_t total_grf; > }; > > +typedef union { > + struct brw_vs_prog_data vs; > + struct brw_tcs_prog_data tcs; > + struct brw_tes_prog_data tes; > + struct brw_gs_prog_data gs; > + struct brw_wm_prog_data wm; > + struct brw_cs_prog_data cs; > +} brw_any_prog_data; > + > #define DEFINE_PROG_DATA_DOWNCAST(stage) \ > static inline struct brw_##stage##_prog_data * \ > brw_##stage##_prog_data(struct brw_stage_prog_data *prog_data) \ > Might be worth leaving a comment that this aren't usable for SF, Clip, BLORP blit, or BLORP clear programs. It's...most any :) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 20/34] intel/compiler: Add functions to get prog_data and prog_key sizes for a stage
On Sunday, October 22, 2017 1:01:28 PM PDT Jordan Justen wrote: > Signed-off-by: Jordan Justen > --- > src/intel/compiler/brw_compiler.c | 36 > src/intel/compiler/brw_compiler.h | 6 ++ > 2 files changed, 42 insertions(+) > > diff --git a/src/intel/compiler/brw_compiler.c > b/src/intel/compiler/brw_compiler.c > index 2f6af7d2c3f..33046dc906c 100644 > --- a/src/intel/compiler/brw_compiler.c > +++ b/src/intel/compiler/brw_compiler.c > @@ -168,3 +168,39 @@ brw_compiler_create(void *mem_ctx, const struct > gen_device_info *devinfo) > > return compiler; > } > + > +size_t Can we just use "unsigned" here instead of size_t? size_t can be either 4 bytes (x86) or 8 bytes (amd64), and you have to use the semi-standard %zu to print it...generally a pain to deal with, and not useful here. Otherwise, Reviewed-by: Kenneth Graunke > +brw_prog_data_size(gl_shader_stage stage) > +{ > + STATIC_ASSERT(MESA_SHADER_VERTEX == 0); > + STATIC_ASSERT(MESA_SHADER_TESS_CTRL == 1); > + STATIC_ASSERT(MESA_SHADER_TESS_EVAL == 2); > + STATIC_ASSERT(MESA_SHADER_GEOMETRY == 3); > + STATIC_ASSERT(MESA_SHADER_FRAGMENT == 4); > + STATIC_ASSERT(MESA_SHADER_COMPUTE == 5); > + static const size_t stage_sizes[] = { > + sizeof(struct brw_vs_prog_data), > + sizeof(struct brw_tcs_prog_data), > + sizeof(struct brw_tes_prog_data), > + sizeof(struct brw_gs_prog_data), > + sizeof(struct brw_wm_prog_data), > + sizeof(struct brw_cs_prog_data), > + }; > + assert((int)stage >= 0 && stage < ARRAY_SIZE(stage_sizes)); > + return stage_sizes[stage]; > +} > + > +size_t > +brw_prog_key_size(gl_shader_stage stage) > +{ > + static const size_t stage_sizes[] = { > + sizeof(struct brw_vs_prog_key), > + sizeof(struct brw_tcs_prog_key), > + sizeof(struct brw_tes_prog_key), > + sizeof(struct brw_gs_prog_key), > + sizeof(struct brw_wm_prog_key), > + sizeof(struct brw_cs_prog_key), > + }; > + assert((int)stage >= 0 && stage < ARRAY_SIZE(stage_sizes)); > + return stage_sizes[stage]; > +} > diff --git a/src/intel/compiler/brw_compiler.h > b/src/intel/compiler/brw_compiler.h > index 9359b767e35..68a12a43370 100644 > --- a/src/intel/compiler/brw_compiler.h > +++ b/src/intel/compiler/brw_compiler.h > @@ -1107,6 +1107,12 @@ DEFINE_PROG_DATA_DOWNCAST(sf) > struct brw_compiler * > brw_compiler_create(void *mem_ctx, const struct gen_device_info *devinfo); > > +size_t > +brw_prog_data_size(gl_shader_stage stage); > + > +size_t > +brw_prog_key_size(gl_shader_stage stage); > + > /** > * Compile a vertex shader. > * > signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 19/34] intel/compiler: Add union types for prog_data and prog_key stages
On 2017-10-23 23:23:27, Kenneth Graunke wrote: > On Sunday, October 22, 2017 1:01:27 PM PDT Jordan Justen wrote: > > Signed-off-by: Jordan Justen > > --- > > src/intel/compiler/brw_compiler.h | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/src/intel/compiler/brw_compiler.h > > b/src/intel/compiler/brw_compiler.h > > index 701b4a80bf1..9359b767e35 100644 > > --- a/src/intel/compiler/brw_compiler.h > > +++ b/src/intel/compiler/brw_compiler.h > > @@ -403,6 +403,15 @@ struct brw_cs_prog_key { > > struct brw_sampler_prog_key_data tex; > > }; > > > > +typedef union { > > + struct brw_vs_prog_key vs; > > + struct brw_tcs_prog_key tcs; > > + struct brw_tes_prog_key tes; > > + struct brw_gs_prog_key gs; > > + struct brw_wm_prog_key wm; > > + struct brw_cs_prog_key cs; > > +} brw_any_prog_key; > > + > > /* > > * Image metadata structure as laid out in the shader parameter > > * buffer. Entries have to be 16B-aligned for the vec4 back-end to be > > @@ -1066,6 +1075,15 @@ struct brw_clip_prog_data { > > uint32_t total_grf; > > }; > > > > +typedef union { > > + struct brw_vs_prog_data vs; > > + struct brw_tcs_prog_data tcs; > > + struct brw_tes_prog_data tes; > > + struct brw_gs_prog_data gs; > > + struct brw_wm_prog_data wm; > > + struct brw_cs_prog_data cs; > > +} brw_any_prog_data; > > + > > #define DEFINE_PROG_DATA_DOWNCAST(stage) \ > > static inline struct brw_##stage##_prog_data * \ > > brw_##stage##_prog_data(struct brw_stage_prog_data *prog_data) \ > > > > Might be worth leaving a comment that this aren't usable for SF, Clip, > BLORP blit, or BLORP clear programs. It's...most any :) Would brw_any_stage_prog_key and brw_any_stage_prog_data help, or just cause confusion with brw_stage_prog_data? I not too happy with 'any' here as well. :\ -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev