On Thu, Sep 29, 2016 at 10:20 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > On 29.09.2016 00:00, Bas Nieuwenhuizen wrote: >> >> On Wed, Sep 28, 2016 at 6:27 PM, Nicolai Hähnle <nhaeh...@gmail.com> >> wrote: >>> >>> On 28.09.2016 16:20, Ilia Mirkin wrote: >>>> >>>> >>>> On Wed, Sep 28, 2016 at 6:25 AM, Nicolai Hähnle <nhaeh...@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> From: Nicolai Hähnle <nicolai.haeh...@amd.com> >>>>> >>>>> The difference to the virtually identical ARB_robustness (which is >>>>> already >>>>> enabled unconditionally) is miniscule and handled elsewhere, but this >>>>> set >>>>> of caps seems like the right thing to require for this extension. >>>>> --- >>>>> docs/features.txt | 2 +- >>>>> docs/relnotes/12.1.0.html | 1 + >>>>> src/mesa/state_tracker/st_extensions.c | 4 ++++ >>>>> 3 files changed, 6 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/docs/features.txt b/docs/features.txt >>>>> index fbb3952..52d194e 100644 >>>>> --- a/docs/features.txt >>>>> +++ b/docs/features.txt >>>>> @@ -211,21 +211,21 @@ GL 4.5, GLSL 4.50: >>>>> GL_ARB_ES3_1_compatibility DONE >>>>> (i965/hsw+, >>>>> nvc0, radeonsi) >>>>> GL_ARB_clip_control DONE (i965, >>>>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr) >>>>> GL_ARB_conditional_render_inverted DONE (i965, >>>>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr) >>>>> GL_ARB_cull_distance DONE (i965, >>>>> nv50, nvc0, radeonsi, llvmpipe, softpipe, swr) >>>>> GL_ARB_derivative_control DONE (i965, >>>>> nv50, nvc0, r600, radeonsi) >>>>> GL_ARB_direct_state_access DONE (all >>>>> drivers) >>>>> GL_ARB_get_texture_sub_image DONE (all >>>>> drivers) >>>>> GL_ARB_shader_texture_image_samples DONE (i965, >>>>> nv50, nvc0, r600, radeonsi) >>>>> GL_ARB_texture_barrier DONE (i965, >>>>> nv50, nvc0, r600, radeonsi) >>>>> GL_KHR_context_flush_control DONE (all - >>>>> but >>>>> needs GLX/EGL extension to be useful) >>>>> - GL_KHR_robustness DONE (i965) >>>>> + GL_KHR_robustness DONE (i965, >>>>> radeonsi) >>>>> GL_EXT_shader_integer_mix DONE (all >>>>> drivers that support GLSL) >>>>> >>>>> These are the extensions cherry-picked to make GLES 3.1 >>>>> GLES3.1, GLSL ES 3.1 -- all DONE: i965/hsw+, nvc0, radeonsi >>>>> >>>>> GL_ARB_arrays_of_arrays DONE (all >>>>> drivers that support GLSL 1.30) >>>>> GL_ARB_compute_shader DONE >>>>> (i965/gen7+, softpipe) >>>>> GL_ARB_draw_indirect DONE >>>>> (i965/gen7+, r600, llvmpipe, softpipe, swr) >>>>> GL_ARB_explicit_uniform_location DONE (all >>>>> drivers that support GLSL) >>>>> GL_ARB_framebuffer_no_attachments DONE >>>>> (i965/gen7+, r600, softpipe) >>>>> diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html >>>>> index cdd8909..0c99f19 100644 >>>>> --- a/docs/relnotes/12.1.0.html >>>>> +++ b/docs/relnotes/12.1.0.html >>>>> @@ -52,20 +52,21 @@ Note: some of the new features are only available >>>>> with certain drivers. >>>>> <li>GL_ARB_cull_distance on radeonsi</li> >>>>> <li>GL_ARB_enhanced_layouts on i965</li> >>>>> <li>GL_ARB_indirect_parameters on radeonsi</li> >>>>> <li>GL_ARB_shader_draw_parameters on radeonsi</li> >>>>> <li>GL_ARB_shader_group_vote on nvc0</li> >>>>> <li>GL_ARB_shader_viewport_layer_array on i965/gen6+</li> >>>>> <li>GL_ARB_stencil_texturing on i965/hsw</li> >>>>> <li>GL_ARB_texture_stencil8 on i965/hsw</li> >>>>> <li>GL_EXT_window_rectangles on nv50, nvc0</li> >>>>> <li>GL_KHR_blend_equation_advanced on i965</li> >>>>> +<li>GL_KHR_robustness on radeonsi</li> >>>>> <li>GL_KHR_texture_compression_astc_sliced_3d on i965</li> >>>>> <li>GL_OES_copy_image on nv50, nvc0, r600, radeonsi, softpipe, >>>>> llvmpipe</li> >>>>> <li>GL_OES_geometry_shader on i965/gen8+, nvc0, radeonsi</li> >>>>> <li>GL_OES_primitive_bounding_box on i965/gen7+, nvc0, radeonsi</li> >>>>> <li>GL_OES_texture_cube_map_array on i965/gen8+, nvc0, radeonsi</li> >>>>> <li>GL_OES_tessellation_shader on i965/gen7+, nvc0, radeonsi</li> >>>>> <li>GL_OES_viewport_array on nvc0, radeonsi</li> >>>>> <li>GL_ANDROID_extension_pack_es31a on i965/gen9+</li> >>>>> </ul> >>>>> >>>>> diff --git a/src/mesa/state_tracker/st_extensions.c >>>>> b/src/mesa/state_tracker/st_extensions.c >>>>> index 4f42217..4789f2c 100644 >>>>> --- a/src/mesa/state_tracker/st_extensions.c >>>>> +++ b/src/mesa/state_tracker/st_extensions.c >>>>> @@ -1192,20 +1192,24 @@ void st_init_extensions(struct pipe_screen >>>>> *screen, >>>>> consts->MaxComputeWorkGroupCount[i] = grid_size[i]; >>>>> consts->MaxComputeWorkGroupSize[i] = block_size[i]; >>>>> } >>>>> >>>>> extensions->ARB_compute_shader = >>>>> >>>>> extensions->ARB_shader_image_load_store && >>>>> >>>>> extensions->ARB_shader_atomic_counters; >>>>> } >>>>> } >>>>> >>>>> + extensions->KHR_robustness = >>>>> + extensions->ARB_robust_buffer_access_behavior && >>>>> + screen->get_param(screen, PIPE_CAP_DEVICE_RESET_STATUS_QUERY); >>>> >>>> >>>> >>>> Is that necessary? From what I can tell, a no-op implementation is >>>> sufficient for KHR_robustness. >>> >>> >>> >>> The extension does talk about buffer robustness. For the reset >>> notification >>> business, I also don't think the spec really has a lot of teeth. I just >>> thought that checking this cap is what's most in line with the spirit of >>> the >>> extension. >> >> >> I think it has some teeth though: >> >> "After a graphics reset has occurred on a context, subsequent GL commands >> on that context (or any context which shares with that context) will >> generate a CONTEXT_LOST error." >> (https://www.opengl.org/registry/specs/KHR/robustness.txt) >> >> Since IIRC gallium uses LOSE_CONTEXT_ON_RESET as reset notification >> behavior, we should at least generate the CONTEXT_LOST errors after a >> GetGraphicsResetStatus call that indicates a reset. >> >> I agree that this can be somewhat theoretical though. > > > Mesa core does that for us, already -- see _mesa_GetGraphicsResetStatusARB. > > Now to be honest, I was also wondering about how to interpret that spec > fragment precisely. What Mesa does is start the CONTEXT_LOST behavior only > if the application calls GetGraphicsResetStatus. Perhaps we should start > returning CONTEXT_LOST also if an application doesn't do that? Checking for > resets on every command is clearly too much; the intel driver does it on > flush, I guess we could do the same.
I would also check when a fence wait has timed out and it has been too long since submission of that CS. That way we get all places where the result of a reset could become visible. - Bas > > Cheers, > Nicolai > > >> - Bas >> >> >> >>> >>> Right now, I think it only makes a difference for nvc0. I can drop that >>> part >>> of the check if you prefer. I really don't have a strong opinion about >>> this. >>> >>> Cheers, >>> Nicolai >>> >>> >>>> >>>>> + >>>>> /* If we support ES 3.1, we support the ES3_1_compatibility ext. >>>>> However >>>>> * there's no clean way of telling whether we would support ES 3.1 >>>>> from >>>>> * here, so copy the condition from compute_version_es2 here. A lot >>>>> of >>>>> * these are redunant, but simpler to just have a (near-)exact copy >>>>> here. >>>>> */ >>>>> extensions->ARB_ES3_1_compatibility = >>>>> extensions->ARB_ES3_compatibility && >>>>> extensions->ARB_arrays_of_arrays && >>>>> extensions->ARB_compute_shader && >>>>> extensions->ARB_draw_indirect && >>>>> -- >>>>> 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 mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
