Re: [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
op 21-06-14 14:12, Ilia Mirkin schreef: On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the new way is (if any) for the various concepts. I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures that the previous context is flushed. This change doesn't have any of the locking -- is that coming in a future change? Otherwise we're still vulnerable to multiple threads trying to render at the same time. (Now with screen sharing, even if they end up with separate screens, we'd still be in trouble.) I haven't done any locking changes, because I don't believe locking is the answer here. With each context having its own pushbuf we can ensure that things aren't flushed, so on flush it should assume all state is dirty. After this is done the PUSH_KICK of the old context on context switch can be removed, and suddenly the driver is thread-safe because only the pushbuf to kernel command submission could race. ;-) I'm still a bit concerned with moving the fence stuff to the context... there might be an assumption in gallium that fences are context-independent, in which case you need to make sure to have just a single fence shared by everything... I don't think that this is the case, because it's very rare that gallium uses multiple contexts simultaneously. (Except vdpau interop, which does flush explicitly.) Have you done a full piglit run on this (with the glx tests, for good measure) on nv30/nv50/nvc0? If so, can you share the results files somewhere? No not yet. But I did confirm that glxgears and glxinfo didn't regress on my nv43, nv96 and nvc0. :-) ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
On Mon, Jun 23, 2014 at 5:17 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: op 21-06-14 14:12, Ilia Mirkin schreef: On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the new way is (if any) for the various concepts. I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures that the previous context is flushed. This change doesn't have any of the locking -- is that coming in a future change? Otherwise we're still vulnerable to multiple threads trying to render at the same time. (Now with screen sharing, even if they end up with separate screens, we'd still be in trouble.) I haven't done any locking changes, because I don't believe locking is the answer here. With each context having its own pushbuf we can ensure that things aren't flushed, so on flush it should assume all state is dirty. After this is done the PUSH_KICK of the old context on context switch can be removed, and suddenly the driver is thread-safe because only the pushbuf to kernel command submission could race. ;-) It would be interesting to see some numbers on the impact of assuming all state is lost each flush vs doing the locking. I'm still a bit concerned with moving the fence stuff to the context... there might be an assumption in gallium that fences are context-independent, in which case you need to make sure to have just a single fence shared by everything... I don't think that this is the case, because it's very rare that gallium uses multiple contexts simultaneously. (Except vdpau interop, which does flush explicitly.) Have you done a full piglit run on this (with the glx tests, for good measure) on nv30/nv50/nvc0? If so, can you share the results files somewhere? No not yet. But I did confirm that glxgears and glxinfo didn't regress on my nv43, nv96 and nvc0. :-) ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
op 23-06-14 09:24, Ben Skeggs schreef: On Mon, Jun 23, 2014 at 5:17 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: op 21-06-14 14:12, Ilia Mirkin schreef: On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the new way is (if any) for the various concepts. I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures that the previous context is flushed. This change doesn't have any of the locking -- is that coming in a future change? Otherwise we're still vulnerable to multiple threads trying to render at the same time. (Now with screen sharing, even if they end up with separate screens, we'd still be in trouble.) I haven't done any locking changes, because I don't believe locking is the answer here. With each context having its own pushbuf we can ensure that things aren't flushed, so on flush it should assume all state is dirty. After this is done the PUSH_KICK of the old context on context switch can be removed, and suddenly the driver is thread-safe because only the pushbuf to kernel command submission could race. ;-) It would be interesting to see some numbers on the impact of assuming all state is lost each flush vs doing the locking. Using locking would mean only a single thread could do command submission at a time, so it still wouldn't be true multithreaded opengl. And there still seem to be some cases in which this isn't enough, for example the query stuff should probably become a dirty flag for validation. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
On Mon, Jun 23, 2014 at 5:39 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: op 23-06-14 09:24, Ben Skeggs schreef: On Mon, Jun 23, 2014 at 5:17 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: op 21-06-14 14:12, Ilia Mirkin schreef: On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the new way is (if any) for the various concepts. I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures that the previous context is flushed. This change doesn't have any of the locking -- is that coming in a future change? Otherwise we're still vulnerable to multiple threads trying to render at the same time. (Now with screen sharing, even if they end up with separate screens, we'd still be in trouble.) I haven't done any locking changes, because I don't believe locking is the answer here. With each context having its own pushbuf we can ensure that things aren't flushed, so on flush it should assume all state is dirty. After this is done the PUSH_KICK of the old context on context switch can be removed, and suddenly the driver is thread-safe because only the pushbuf to kernel command submission could race. ;-) It would be interesting to see some numbers on the impact of assuming all state is lost each flush vs doing the locking. Using locking would mean only a single thread could do command submission at a time, so it still wouldn't be true multithreaded opengl. And there still seem to be some cases in which this isn't enough, for example the query stuff should probably become a dirty flag for validation. Well, other threads are free to do everything else except the final draw call still. But yes, that's potentially a good chunk of the work. That can possibly be worked around in a couple of ways if the numbers show it's worth bothering. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/11] GLX/DRI3: Add GPU offloading support.
On 19.06.2014 12:27, Axel Davy wrote: The differences with DRI2 GPU offloading are: . There's no logic for GPU offloading needed in the Xserver . for DRI2, the card would render to a back buffer, and the content would be copied to the front buffer (the same buffers everytime). Here we can potentially use several back buffers and copy to buffers with no tiling to share with X. We send them with the Present extension. That means than the DRI2 solution is forced to have tearings with GPU offloading. In the ideal scenario, this DRI3 solution doesn't have this problem. However without dma-buf fences, a race can appear (if the card is slow and the rendering hasn't finished before the server card reads the buffer), and then old content is displayed. If a user hits this, he should probably revert to the DRI2 solution (LIBGL_DRI3_DISABLE). Users with cards fast enough seem to not hit this in practice (I have an Amd hd 7730m, and I don't hit this, except if I force a low dpm mode) . for non-fullscreen apps, the DRI2 GPU offloading solution requires compositing. This DRI3 solution doesn't have this requirement. Rendering to a pixmap also works. . There is no need to have a DDX loaded for the secondary card. If X doesn't know anything about the secondary card, the secondary card must use the server side GLX information from the driver of the primary card, right? That seems rather hackish to me, and like it can only work as long as the cards / drivers are 'similar enough'... Patches 1, 2 and 10 look good to me though FWIW. The radeonsi piglit multisampling regressions with DRI3 compared to DRI2 can be addressed later as far as I'm concerned. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meta: Use AMD_vertex_shader_layer instead of a GS for layered clears.
Reviewed-by: Chris Forbes chr...@ijw.co.nz Have you got a case where this makes a noticeable difference to performance? On Mon, Jun 23, 2014 at 5:27 PM, Kenneth Graunke kenn...@whitecape.org wrote: On i965, enabling and disabling the GS is not free: you have to do a full pipeline stall, reconfigure the URB and push constant space, and emit a bunch of state. Most clears aren't layered, so the GS isn't needed in the common case. But we turned it on anyway. As far as I know, most GPUs that support layered rendering can support the GL_AMD_vertex_shader_layer extension. i965 does, and it's also the only driver using this path that does layered rendering. Doing so allows us to skip setting up the GS. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/common/meta.c | 53 +- 1 file changed, 16 insertions(+), 37 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index cab0dd8..a4634a3 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -1515,23 +1515,15 @@ static void meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) { const char *vs_source = + #extension GL_AMD_vertex_shader_layer : enable\n attribute vec4 position;\n - void main()\n - {\n - gl_Position = position;\n - }\n; - const char *gs_source = - #version 150\n - layout(triangles) in;\n - layout(triangle_strip, max_vertices = 4) out;\n uniform int layer;\n void main()\n {\n -for (int i = 0; i 3; i++) {\n - gl_Layer = layer;\n - gl_Position = gl_in[i].gl_Position;\n - EmitVertex();\n -}\n + #ifdef GL_AMD_vertex_shader_layer\n + gl_Layer = layer;\n + #endif\n + gl_Position = position;\n }\n; const char *fs_source = uniform vec4 color;\n @@ -1539,7 +1531,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) {\n gl_FragColor = color;\n }\n; - GLuint vs, gs = 0, fs; + GLuint vs, fs; bool has_integer_textures; _mesa_meta_setup_vertex_objects(clear-VAO, clear-VBO, true, 3, 0, 0); @@ -1551,12 +1543,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) _mesa_ShaderSource(vs, 1, vs_source, NULL); _mesa_CompileShader(vs); - if (_mesa_has_geometry_shaders(ctx)) { - gs = _mesa_CreateShader(GL_GEOMETRY_SHADER); - _mesa_ShaderSource(gs, 1, gs_source, NULL); - _mesa_CompileShader(gs); - } - fs = _mesa_CreateShader(GL_FRAGMENT_SHADER); _mesa_ShaderSource(fs, 1, fs_source, NULL); _mesa_CompileShader(fs); @@ -1564,20 +1550,14 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) clear-ShaderProg = _mesa_CreateProgram(); _mesa_AttachShader(clear-ShaderProg, fs); _mesa_DeleteShader(fs); - if (gs != 0) - _mesa_AttachShader(clear-ShaderProg, gs); _mesa_AttachShader(clear-ShaderProg, vs); _mesa_DeleteShader(vs); _mesa_BindAttribLocation(clear-ShaderProg, 0, position); _mesa_ObjectLabel(GL_PROGRAM, clear-ShaderProg, -1, meta clear); _mesa_LinkProgram(clear-ShaderProg); - clear-ColorLocation = _mesa_GetUniformLocation(clear-ShaderProg, - color); - if (gs != 0) { - clear-LayerLocation = _mesa_GetUniformLocation(clear-ShaderProg, - layer); - } + clear-ColorLocation = _mesa_GetUniformLocation(clear-ShaderProg, color); + clear-LayerLocation = _mesa_GetUniformLocation(clear-ShaderProg, layer); has_integer_textures = _mesa_is_gles3(ctx) || (_mesa_is_desktop_gl(ctx) ctx-Const.GLSLVersion = 130); @@ -1587,9 +1567,14 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) const char *vs_int_source = ralloc_asprintf(shader_source_mem_ctx, #version 130\n + #extension GL_AMD_vertex_shader_layer : enable\n in vec4 position;\n + uniform int layer;\n void main()\n {\n + #ifdef GL_AMD_vertex_shader_layer\n +gl_Layer = layer;\n + #endif\n gl_Position = position;\n }\n); const char *fs_int_source = @@ -1612,8 +1597,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) clear-IntegerShaderProg = _mesa_CreateProgram(); _mesa_AttachShader(clear-IntegerShaderProg, fs); _mesa_DeleteShader(fs); - if (gs != 0) - _mesa_AttachShader(clear-IntegerShaderProg, gs);
Re: [Mesa-dev] [PATCH 4/4] nvc0: enable ARB_fragment_layer_viewport
Am 22.06.2014 17:10, schrieb Ilia Mirkin: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- docs/GL3.txt| 2 +- docs/relnotes/10.3.html | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c47a54b..8cfa247 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport DONE (nv50) + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index 5e29f2d..b65e347 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,7 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li -liGL_ARB_fragment_layer_viewport on nv50/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0/li /ul diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c index 667fbc8..ad8d1b0 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c @@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned ubase) switch (sn) { case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4; case TGSI_SEMANTIC_PRIMID: return 0x060; + case TGSI_SEMANTIC_LAYER:return 0x064; + case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068; case TGSI_SEMANTIC_PSIZE:return 0x06c; case TGSI_SEMANTIC_POSITION: return 0x070; case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10; diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 2c8f1ca..c02e10a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -164,6 +164,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TEXTURE_GATHER_SM5: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 1; case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return (class_3d = NVE4_3D_CLASS) ? 1 : 0; @@ -181,7 +182,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VS_LAYER: case PIPE_CAP_FAKE_SW_MSAA: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: - case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } Is that cap bit really required? Everybody who can do layered viewports ought to be able to do this (as it's required by d3d10). Though I can't say if right now all drivers which support layered viewports can already do it (llvmpipe can), but it might be trivial to fix those up which can't. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] nvc0: enable ARB_fragment_layer_viewport
Am 23.06.2014 12:49, schrieb Roland Scheidegger: Am 22.06.2014 17:10, schrieb Ilia Mirkin: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- docs/GL3.txt| 2 +- docs/relnotes/10.3.html | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c47a54b..8cfa247 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport DONE (nv50) + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index 5e29f2d..b65e347 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,7 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li -liGL_ARB_fragment_layer_viewport on nv50/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0/li /ul diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c index 667fbc8..ad8d1b0 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c @@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned ubase) switch (sn) { case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4; case TGSI_SEMANTIC_PRIMID: return 0x060; + case TGSI_SEMANTIC_LAYER:return 0x064; + case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068; case TGSI_SEMANTIC_PSIZE:return 0x06c; case TGSI_SEMANTIC_POSITION: return 0x070; case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10; diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 2c8f1ca..c02e10a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -164,6 +164,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TEXTURE_GATHER_SM5: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 1; case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return (class_3d = NVE4_3D_CLASS) ? 1 : 0; @@ -181,7 +182,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VS_LAYER: case PIPE_CAP_FAKE_SW_MSAA: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: - case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } Is that cap bit really required? Everybody who can do layered viewports ought to be able to do this (as it's required by d3d10). Though I can't say if right now all drivers which support layered viewports can already do it (llvmpipe can), but it might be trivial to fix those up which can't. (Of course that should have been layered fbs and multiple viewports, that short-notation I used there doesn't make much sense...) roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] nvc0: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 7:55 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 12:49, schrieb Roland Scheidegger: Am 22.06.2014 17:10, schrieb Ilia Mirkin: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- docs/GL3.txt| 2 +- docs/relnotes/10.3.html | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c47a54b..8cfa247 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport DONE (nv50) + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index 5e29f2d..b65e347 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,7 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li -liGL_ARB_fragment_layer_viewport on nv50/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0/li /ul diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c index 667fbc8..ad8d1b0 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c @@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned ubase) switch (sn) { case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4; case TGSI_SEMANTIC_PRIMID: return 0x060; + case TGSI_SEMANTIC_LAYER:return 0x064; + case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068; case TGSI_SEMANTIC_PSIZE:return 0x06c; case TGSI_SEMANTIC_POSITION: return 0x070; case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10; diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 2c8f1ca..c02e10a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -164,6 +164,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TEXTURE_GATHER_SM5: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 1; case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return (class_3d = NVE4_3D_CLASS) ? 1 : 0; @@ -181,7 +182,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VS_LAYER: case PIPE_CAP_FAKE_SW_MSAA: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: - case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } Is that cap bit really required? Everybody who can do layered viewports ought to be able to do this (as it's required by d3d10). Though I can't say if right now all drivers which support layered viewports can already do it (llvmpipe can), but it might be trivial to fix those up which can't. (Of course that should have been layered fbs and multiple viewports, that short-notation I used there doesn't make much sense...) Well, I think right now the only drivers that support multiple viewports are llvmpipe, nv50, nvc0, and r600. I can test out llvmpipe but would need some help for r600. Would love not to have to add the cap :) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meta: Use AMD_vertex_shader_layer instead of a GS for layered clears.
On Mon, Jun 23, 2014 at 1:27 AM, Kenneth Graunke kenn...@whitecape.org wrote: On i965, enabling and disabling the GS is not free: you have to do a full pipeline stall, reconfigure the URB and push constant space, and emit a bunch of state. Most clears aren't layered, so the GS isn't needed in the common case. But we turned it on anyway. As far as I know, most GPUs that support layered rendering can support the GL_AMD_vertex_shader_layer extension. i965 does, and it's also the Not that this matters for meta, but FTR, NVIDIA GPU's don't support AMD_vertex_shader_layer. only driver using this path that does layered rendering. Doing so allows us to skip setting up the GS. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/common/meta.c | 53 +- 1 file changed, 16 insertions(+), 37 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index cab0dd8..a4634a3 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -1515,23 +1515,15 @@ static void meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) { const char *vs_source = + #extension GL_AMD_vertex_shader_layer : enable\n attribute vec4 position;\n - void main()\n - {\n - gl_Position = position;\n - }\n; - const char *gs_source = - #version 150\n - layout(triangles) in;\n - layout(triangle_strip, max_vertices = 4) out;\n uniform int layer;\n void main()\n {\n -for (int i = 0; i 3; i++) {\n - gl_Layer = layer;\n - gl_Position = gl_in[i].gl_Position;\n - EmitVertex();\n -}\n + #ifdef GL_AMD_vertex_shader_layer\n + gl_Layer = layer;\n + #endif\n + gl_Position = position;\n }\n; const char *fs_source = uniform vec4 color;\n @@ -1539,7 +1531,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) {\n gl_FragColor = color;\n }\n; - GLuint vs, gs = 0, fs; + GLuint vs, fs; bool has_integer_textures; _mesa_meta_setup_vertex_objects(clear-VAO, clear-VBO, true, 3, 0, 0); @@ -1551,12 +1543,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) _mesa_ShaderSource(vs, 1, vs_source, NULL); _mesa_CompileShader(vs); - if (_mesa_has_geometry_shaders(ctx)) { - gs = _mesa_CreateShader(GL_GEOMETRY_SHADER); - _mesa_ShaderSource(gs, 1, gs_source, NULL); - _mesa_CompileShader(gs); - } - fs = _mesa_CreateShader(GL_FRAGMENT_SHADER); _mesa_ShaderSource(fs, 1, fs_source, NULL); _mesa_CompileShader(fs); @@ -1564,20 +1550,14 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) clear-ShaderProg = _mesa_CreateProgram(); _mesa_AttachShader(clear-ShaderProg, fs); _mesa_DeleteShader(fs); - if (gs != 0) - _mesa_AttachShader(clear-ShaderProg, gs); _mesa_AttachShader(clear-ShaderProg, vs); _mesa_DeleteShader(vs); _mesa_BindAttribLocation(clear-ShaderProg, 0, position); _mesa_ObjectLabel(GL_PROGRAM, clear-ShaderProg, -1, meta clear); _mesa_LinkProgram(clear-ShaderProg); - clear-ColorLocation = _mesa_GetUniformLocation(clear-ShaderProg, - color); - if (gs != 0) { - clear-LayerLocation = _mesa_GetUniformLocation(clear-ShaderProg, - layer); - } + clear-ColorLocation = _mesa_GetUniformLocation(clear-ShaderProg, color); + clear-LayerLocation = _mesa_GetUniformLocation(clear-ShaderProg, layer); has_integer_textures = _mesa_is_gles3(ctx) || (_mesa_is_desktop_gl(ctx) ctx-Const.GLSLVersion = 130); @@ -1587,9 +1567,14 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) const char *vs_int_source = ralloc_asprintf(shader_source_mem_ctx, #version 130\n + #extension GL_AMD_vertex_shader_layer : enable\n in vec4 position;\n + uniform int layer;\n void main()\n {\n + #ifdef GL_AMD_vertex_shader_layer\n +gl_Layer = layer;\n + #endif\n gl_Position = position;\n }\n); const char *fs_int_source = @@ -1612,8 +1597,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear) clear-IntegerShaderProg = _mesa_CreateProgram(); _mesa_AttachShader(clear-IntegerShaderProg, fs); _mesa_DeleteShader(fs); - if (gs != 0) - _mesa_AttachShader(clear-IntegerShaderProg, gs);
[Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/3] mesa/st: handle gl_Layer input semantic
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Reviewed-by: Marek Olšák marek.ol...@amd.com --- src/mesa/state_tracker/st_program.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index 26eb978..1df411c 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -572,6 +572,11 @@ st_translate_fragment_program(struct st_context *st, input_semantic_index[slot] = 0; interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; break; + case VARYING_SLOT_LAYER: +input_semantic_name[slot] = TGSI_SEMANTIC_LAYER; +input_semantic_index[slot] = 0; +interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; +break; case VARYING_SLOT_VIEWPORT: input_semantic_name[slot] = TGSI_SEMANTIC_VIEWPORT_INDEX; input_semantic_index[slot] = 0; -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/3] nvc0: allow VIEWPORT_INDEX and LAYER to be used as input semantics
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c index 667fbc8..ad8d1b0 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c @@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned ubase) switch (sn) { case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4; case TGSI_SEMANTIC_PRIMID: return 0x060; + case TGSI_SEMANTIC_LAYER:return 0x064; + case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068; case TGSI_SEMANTIC_PSIZE:return 0x06c; case TGSI_SEMANTIC_POSITION: return 0x070; case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10; -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] patch: fix glxusexfont
On 06/22/2014 10:57 AM, Daniel Manjarres wrote: Author: Daniel Manjarres danm...@gmail.com Date: Sun Jun 22 09:47:58 2014 -0700 glx: Fix glxUseXFont for glxWindow and glxPixmaps The current implementation of glxUseXFont requires creating a temporary pixmap and graphics context, which requires a real old-school X11 Window, not a glxDrawable. This patch changes things so that glxUseXFont will also accept a glxWindow or glxPixmap, and lookup the underlying X11 Drawable. Without this patch glxUseXFont generates a giant stream of Xerrors bout bad drawables and bad graphics contexts. Bugzilla: https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D54372k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=itD%2Fq69MXejLYrMzB3dNz461S4I332LKiDT23UoMsA4%3D%0As=6ea3005f27f76e237646e9e443df7f3cc671ec21f60b7f3d5218281a5957df54 diff --git a/src/glx/xfont.c b/src/glx/xfont.c index 316c585..8735386 100644 --- a/src/glx/xfont.c +++ b/src/glx/xfont.c @@ -221,6 +221,7 @@ DRI_glXUseXFont(struct glx_context *CC, Font font, int first, int count, int lis XGCValues values; unsigned long valuemask; XFontStruct *fs; + __GLXDRIdrawable *glxdraw; GLint swapbytes, lsbfirst, rowlength; GLint skiprows, skippixels, alignment; @@ -233,6 +234,10 @@ DRI_glXUseXFont(struct glx_context *CC, Font font, int first, int count, int lis dpy = CC-currentDpy; win = CC-currentDrawable; + glxdraw = GetGLXDRIDrawable(CC-currentDpy, CC-currentDrawable); + if(glxdraw) + win = glxdraw-xDrawable; + fs = XQueryFont(dpy, font); if (!fs) { __glXSetError(CC, GL_INVALID_VALUE); Looks OK to me. Though, you could put the preceeding win = CC-currentDrawable; into an else clause. Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] glxinfo: Print XFB, TBO, and UBO limits
I happened to add some of this to glxinfo last week. I'll rebase Fredrik's patch on the latest (refactored) glxinfo... -Brian On 06/22/2014 09:55 AM, Ilia Mirkin wrote: Fredrik, What happened to this series? -ilia On Thu, Apr 10, 2014 at 10:09 AM, Brian Paul bri...@vmware.com wrote: On 04/09/2014 07:51 PM, Fredrik Höglund wrote: --- src/xdemos/glxinfo.c | 22 ++ 1 file changed, 22 insertions(+) For the series: Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=7AkDBLSZUpKwIhRoyU%2BtcL3X0hHE%2Bt98ljxNbZMJOqo%3D%0As=1cd01825e8e2e5027733672375ac05e728d6886a8a184d5854054de2ffc4d802 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glxinfo: Print XFB, TBO, and UBO limits
From: Fredrik Höglund fred...@kde.org Updated patch for refactored glxinfo/wglinfo code by Brian Paul. Signed-off-by: Brian Paul bri...@vmware.com --- src/xdemos/glinfo_common.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c index e6517d7..4864f58 100644 --- a/src/xdemos/glinfo_common.c +++ b/src/xdemos/glinfo_common.c @@ -522,6 +522,28 @@ print_limits(const char *extensions, const char *oglstring, int version, { 1, GL_MAX_COLOR_ATTACHMENTS, GL_MAX_COLOR_ATTACHMENTS, GL_ARB_framebuffer_object }, { 1, GL_MAX_SAMPLES, GL_MAX_SAMPLES, GL_ARB_framebuffer_object }, #endif +#if defined (GL_EXT_transform_feedback) + { 1, GL_MAX_TRANSFORM_FEEDBACK_BUFFERS, GL_MAX_TRANSFORM_FEEDBACK_BUFFERS, GL_EXT_transform_feedback }, + { 1, GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT, GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS, GL_EXT_transform_feedback }, + { 1, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS, GL_EXT_transform_feedback, }, + { 1, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_EXT, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS, GL_EXT_transform_feedback }, +#endif +#if defined (GL_ARB_texture_buffer_object) + { 1, GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT, GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT, GL_ARB_texture_buffer_object }, + { 1, GL_MAX_TEXTURE_BUFFER_SIZE, GL_MAX_TEXTURE_BUFFER_SIZE, GL_ARB_texture_buffer_object }, +#endif +#if defined (GL_ARB_uniform_buffer_object) + { 1, GL_MAX_VERTEX_UNIFORM_BLOCKS, GL_MAX_VERTEX_UNIFORM_BLOCKS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_FRAGMENT_UNIFORM_BLOCKS, GL_MAX_FRAGMENT_UNIFORM_BLOCKS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_GEOMETRY_UNIFORM_BLOCKS, GL_MAX_GEOMETRY_UNIFORM_BLOCKS , GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_UNIFORM_BLOCKS, GL_MAX_COMBINED_UNIFORM_BLOCKS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_UNIFORM_BUFFER_BINDINGS, GL_MAX_UNIFORM_BUFFER_BINDINGS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_UNIFORM_BLOCK_SIZE, GL_MAX_UNIFORM_BLOCK_SIZE, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS, GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS, GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS, GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS, GL_ARB_uniform_buffer_object }, + { 1, GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT, GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT, GL_ARB_uniform_buffer_object }, +#endif { 0, (GLenum) 0, NULL, NULL } }; GLint i, max[2]; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] r600: Fix use after free in compute_memory_promote_item.
The dst pointer needs to be initialized after any calls to compute_memory_grow_pool, as the function might change the pool-vbo pointer. This fixes crashes and assertion failures in two gegl tests. Signed-off-by: Jan Vesely jan.ves...@rutgers.edu CC: Bruno Jimenez brunoji...@gmail.com CC: Tom Stellard thomas.stell...@amd.com --- src/gallium/drivers/r600/compute_memory_pool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index a78ff1e..9cb16f8 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -308,8 +308,8 @@ int compute_memory_promote_item(struct compute_memory_pool *pool, { struct pipe_screen *screen = (struct pipe_screen *)pool-screen; struct r600_context *rctx = (struct r600_context *)pipe; - struct pipe_resource *dst = (struct pipe_resource *)pool-bo; struct pipe_resource *src = (struct pipe_resource *)item-real_buffer; + struct pipe_resource *dst = NULL; struct pipe_box box; struct list_head *pos; @@ -339,6 +339,7 @@ int compute_memory_promote_item(struct compute_memory_pool *pool, if (err == -1) return -1; } + dst = (struct pipe_resource *)pool-bo; COMPUTE_DBG(pool-screen, + Found space for Item %p id = %u start_in_dw = %u (%u bytes) size_in_dw = %u (%u bytes)\n, item, item-id, start_in_dw, start_in_dw * 4, -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (http://patchwork.freedesktop.org/patch/28375/ -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
On Mon, Jun 23, 2014 at 3:17 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: op 21-06-14 14:12, Ilia Mirkin schreef: On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the new way is (if any) for the various concepts. I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures that the previous context is flushed. I meant in the commit log :) This change doesn't have any of the locking -- is that coming in a future change? Otherwise we're still vulnerable to multiple threads trying to render at the same time. (Now with screen sharing, even if they end up with separate screens, we'd still be in trouble.) I haven't done any locking changes, because I don't believe locking is the answer here. With each context having its own pushbuf we can ensure that things aren't flushed, so on flush it should assume all state is dirty. After this is done the PUSH_KICK of the old context on context switch can be removed, and suddenly the driver is thread-safe because only the pushbuf to kernel command submission could race. ;-) OK. I'm concerned that PUSH_SPACE could let us down here. We'd have to make sure enough space were available for the whole pushbuf, which if an inline vertex transfer is involved, could be a tricky proposition. I'm still a bit concerned with moving the fence stuff to the context... there might be an assumption in gallium that fences are context-independent, in which case you need to make sure to have just a single fence shared by everything... I don't think that this is the case, because it's very rare that gallium uses multiple contexts simultaneously. (Except vdpau interop, which does flush explicitly.) Agreed that it's rare. vdpau interop is the main case, the minor case is 2 screens (which will now share one pipe_screen). This is the issue the other user was having (with the fd closing thing). Have you done a full piglit run on this (with the glx tests, for good measure) on nv30/nv50/nvc0? If so, can you share the results files somewhere? No not yet. But I did confirm that glxgears and glxinfo didn't regress on my nv43, nv96 and nvc0. :-) Well, would be good to get those results, and make sure there are no unexpected regressions. (*-struct-pad seems to flip between fail and pass at random, I think based on which tests were run prior... some bit of state we're missing somewhere. One or two others like that.) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. The index of the viewport itself isn't clamped but set to to zero if it exceeds 16 (PIPE_MAX_VIEWPORTS) but only for the actual selection of the viewport, again this is required by d3d10. GL has undefined results there so this should be ok (and hw will do near certainly the same anyway). The value you get in the fragment shader though will NOT be clamped, which as far as I can tell is required by both d3d10 and GL. But of course there could always be some other bug... Roland If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/28375/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=67e6d3d7200289af788142c217a7c1cb598ccbeb7122ec52a358f60ffd98be2d -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=a6d6c596fee80884f66960766ae2d42d9f8426eabc4a352bc48ed38e5bb811e2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] r600: Fix use after free in compute_memory_promote_item.
On Mon, 2014-06-23 at 10:39 -0400, Jan Vesely wrote: The dst pointer needs to be initialized after any calls to compute_memory_grow_pool, as the function might change the pool-vbo pointer. You are completely right. Good catch. Reviewed-by: Bruno Jiménez brunoji...@gmail.com Sorry for any inconvenience this may have caused. This fixes crashes and assertion failures in two gegl tests. Signed-off-by: Jan Vesely jan.ves...@rutgers.edu CC: Bruno Jimenez brunoji...@gmail.com CC: Tom Stellard thomas.stell...@amd.com --- src/gallium/drivers/r600/compute_memory_pool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index a78ff1e..9cb16f8 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -308,8 +308,8 @@ int compute_memory_promote_item(struct compute_memory_pool *pool, { struct pipe_screen *screen = (struct pipe_screen *)pool-screen; struct r600_context *rctx = (struct r600_context *)pipe; - struct pipe_resource *dst = (struct pipe_resource *)pool-bo; struct pipe_resource *src = (struct pipe_resource *)item-real_buffer; + struct pipe_resource *dst = NULL; struct pipe_box box; struct list_head *pos; @@ -339,6 +339,7 @@ int compute_memory_promote_item(struct compute_memory_pool *pool, if (err == -1) return -1; } + dst = (struct pipe_resource *)pool-bo; COMPUTE_DBG(pool-screen, + Found space for Item %p id = %u start_in_dw = %u (%u bytes) size_in_dw = %u (%u bytes)\n, item, item-id, start_in_dw, start_in_dw * 4, ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. The index of the viewport itself isn't clamped but set to to zero if it exceeds 16 (PIPE_MAX_VIEWPORTS) but only for the actual selection of the viewport, again this is required by d3d10. GL has undefined results there so this should be ok (and hw will do near certainly the same anyway). The value you get in the fragment shader though will NOT be clamped, which as far as I can tell is required by both d3d10 and GL. But of course there could always be some other bug... Bleh. Well, if GL has undefined rendering results for invalid gl_ViewportIndex, then my viewport test won't work -- it checks various out-of-bounds values. I'll scale it back to only testing legal values. Roland If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/28375/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=67e6d3d7200289af788142c217a7c1cb598ccbeb7122ec52a358f60ffd98be2d -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=a6d6c596fee80884f66960766ae2d42d9f8426eabc4a352bc48ed38e5bb811e2 ___ mesa-dev mailing list
[Mesa-dev] [PATCH] nv50/ir: make ARB_viewport_array behave like it does with other drivers
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 27 -- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h index c885c8c..a8cc97c 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h @@ -189,6 +189,7 @@ struct nv50_ir_prog_info uint16_t sampleInfoBase; /* base address for sample positions */ uint8_t msInfoCBSlot; /* cX[] used for multisample info */ uint16_t msInfoBase; /* base address for multisample info */ + int32_t viewportID; } io; /* driver callback to assign input/output locations */ diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index a0f1fe1..78e33f8 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -982,6 +982,9 @@ bool Source::scanDeclaration(const struct tgsi_full_declaration *decl) case TGSI_SEMANTIC_SAMPLEMASK: info-io.sampleMask = i; break; + case TGSI_SEMANTIC_VIEWPORT_INDEX: +info-io.viewportID = i; +break; default: break; } @@ -1258,6 +1261,8 @@ private: Stack joinBBs; // fork BB, for inserting join ops on ENDIF Stack loopBBs; // loop headers Stack breakBBs; // end of / after loop + + Value *viewport; }; Symbol * @@ -1555,8 +1560,15 @@ Converter::storeDst(const tgsi::Instruction::DstRegister dst, int c, mkOp2(OP_WRSV, TYPE_U32, NULL, dstToSym(dst, c), val); } else if (f == TGSI_FILE_OUTPUT prog-getType() != Program::TYPE_FRAGMENT) { - if (ptr || (info-out[idx].mask (1 c))) - mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + + if (ptr || (info-out[idx].mask (1 c))) { + /* Save the viewport index into a scratch register so that it can be +exported at EMIT time */ + if (info-out[dst.getIndex(0)].sn == TGSI_SEMANTIC_VIEWPORT_INDEX viewport != NULL) +mkOp1(OP_MOV, TYPE_U32, viewport, val); + else +mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + } } else if (f == TGSI_FILE_TEMPORARY || f == TGSI_FILE_PREDICATE || @@ -2523,6 +2535,14 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c)); break; case TGSI_OPCODE_EMIT: + /* export the saved viewport index */ + if (viewport != NULL) { + Symbol *VPSym = mkSymbol(FILE_SHADER_OUTPUT, info-io.viewportID, + TYPE_U32, + info-out[info-io.viewportID].slot[0] * 4); + mkStore(OP_EXPORT, TYPE_U32, VPSym, NULL, viewport); + } + /* fallthrough */ case TGSI_OPCODE_ENDPRIM: // get vertex stream if specified (must be immediate) src0 = tgsi.srcCount() ? @@ -2952,6 +2972,9 @@ Converter::run() mkOp1(OP_RCP, TYPE_F32, fragCoord[3], fragCoord[3]); } + if (info-io.viewportID 0) + viewport = getScratch(); + for (ip = 0; ip code-scan.num_instructions; ++ip) { if (!handleInstruction(code-insns[ip])) return false; -- 1.8.4.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50/ir: make ARB_viewport_array behave like it does with other drivers
On Mon, Jun 23, 2014 at 11:24 AM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: Please add a brief description of what your change does and how it achieves this. [Let me know if you're not comfortable writing that, and I can compose it for you.] Among other things, note that it fixes some piglit tests. And instead of saying make it work like the others, try to provide an explanation of how it works and then mention that other drivers appear to work that way. Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 27 -- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h index c885c8c..a8cc97c 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h @@ -189,6 +189,7 @@ struct nv50_ir_prog_info uint16_t sampleInfoBase; /* base address for sample positions */ uint8_t msInfoCBSlot; /* cX[] used for multisample info */ uint16_t msInfoBase; /* base address for multisample info */ + int32_t viewportID; viewportId to match the capitalization of the other ones (the reason you see e.g. CB is because it's a Const Buffer). Could you also place it next to sampleMask/fragDepth? And add a comment like they have. } io; /* driver callback to assign input/output locations */ diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index a0f1fe1..78e33f8 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -982,6 +982,9 @@ bool Source::scanDeclaration(const struct tgsi_full_declaration *decl) case TGSI_SEMANTIC_SAMPLEMASK: info-io.sampleMask = i; break; + case TGSI_SEMANTIC_VIEWPORT_INDEX: +info-io.viewportID = i; +break; default: break; } @@ -1258,6 +1261,8 @@ private: Stack joinBBs; // fork BB, for inserting join ops on ENDIF Stack loopBBs; // loop headers Stack breakBBs; // end of / after loop + + Value *viewport; }; Symbol * @@ -1555,8 +1560,15 @@ Converter::storeDst(const tgsi::Instruction::DstRegister dst, int c, mkOp2(OP_WRSV, TYPE_U32, NULL, dstToSym(dst, c), val); } else if (f == TGSI_FILE_OUTPUT prog-getType() != Program::TYPE_FRAGMENT) { - if (ptr || (info-out[idx].mask (1 c))) - mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + + if (ptr || (info-out[idx].mask (1 c))) { + /* Save the viewport index into a scratch register so that it can be +exported at EMIT time */ + if (info-out[dst.getIndex(0)].sn == TGSI_SEMANTIC_VIEWPORT_INDEX viewport != NULL) +mkOp1(OP_MOV, TYPE_U32, viewport, val); + else +mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + } } else if (f == TGSI_FILE_TEMPORARY || f == TGSI_FILE_PREDICATE || @@ -2523,6 +2535,14 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c)); break; case TGSI_OPCODE_EMIT: + /* export the saved viewport index */ + if (viewport != NULL) { + Symbol *VPSym = mkSymbol(FILE_SHADER_OUTPUT, info-io.viewportID, Pretty sure you should just pass '0' as the second arg to mkSymbol -- it takes the file index, which makes sense for e.g. constbufs of which there can be many. Also, how about Symbol *vp or Symbol *vpSym to conform to the variable naming convention used throughout this file. + TYPE_U32, + info-out[info-io.viewportID].slot[0] * 4); + mkStore(OP_EXPORT, TYPE_U32, VPSym, NULL, viewport); + } + /* fallthrough */ case TGSI_OPCODE_ENDPRIM: // get vertex stream if specified (must be immediate) src0 = tgsi.srcCount() ? @@ -2952,6 +2972,9 @@ Converter::run() mkOp1(OP_RCP, TYPE_F32, fragCoord[3], fragCoord[3]); } + if (info-io.viewportID 0) What if it's the first output? You need to initialize viewportId to 0xff somewhere... like right before the code that calls scanDeclarations() and then here check that it's 0xff. [There can't be 255 outputs IIRC... the max is like 64 or 16 or something.] + viewport = getScratch(); else viewport = NULL; + for (ip = 0; ip code-scan.num_instructions; ++ip) { if (!handleInstruction(code-insns[ip])) return false; -- 1.8.4.5 ___ mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am 23.06.2014 17:18, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. Yes it should be - the viewport should be set somewhere (I'm not exactly sure where it gets set) and since in GL the old commands just set all viewports this should work. The index of the viewport itself isn't clamped but set to to zero if it exceeds 16 (PIPE_MAX_VIEWPORTS) but only for the actual selection of the viewport, again this is required by d3d10. GL has undefined results there so this should be ok (and hw will do near certainly the same anyway). The value you get in the fragment shader though will NOT be clamped, which as far as I can tell is required by both d3d10 and GL. But of course there could always be some other bug... Bleh. Well, if GL has undefined rendering results for invalid gl_ViewportIndex, then my viewport test won't work -- it checks various out-of-bounds values. I'll scale it back to only testing legal values. Well I suspect for most hw it should still work (even if technically undefined in GL) due to d3d10 requirements which hw is likely to follow in any case. It definitely should work in llvmpipe. Roland Roland If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/28375/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=67e6d3d7200289af788142c217a7c1cb598ccbeb7122ec52a358f60ffd98be2d -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Mon, Jun 23, 2014 at 1:07 PM, Aaron Watry awa...@gmail.com wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? libvdpau only loads files from a fixed location, as determined by the --prefix you use to compile it. So if you're putting mesa into a different prefix than libvdpau it won't work. --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Emil Velikov wrote: Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. No, it fails to install anything to do with libvdpau_gallium* which is present in the tree in /src/gallium/targets/vdpau/.libs some output below. Additionally it copies/makes the links for libvdpau_radeonsi* but doesn't install the target libvdpau_radeonsi.so.1.0.0, which is present in tree in lib/gallium. /bin/mkdir -p '/usr/lib/vdpau' /bin/sh ../../../../libtool --mode=install /bin/install -c libvdpau_gallium.la '/usr/lib/vdpau' libtool: install: /bin/install -c .libs/libvdpau_gallium.so.1.0.0 /usr/lib/vdpau/libvdpau_gallium.so.1.0.0 libtool: install: (cd /usr/lib/vdpau { ln -s -f libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1 || { rm -f libvdpau_gallium.so.1 ln -s libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1; }; }) libtool: install: (cd /usr/lib/vdpau { ln -s -f libvdpau_gallium.so.1.0.0 libvdpau_gallium.so || { rm -f libvdpau_gallium.so ln -s libvdpau_gallium.so.1.0.0 libvdpau_gallium.so; }; }) libtool: install: /bin/install -c .libs/libvdpau_gallium.lai /usr/lib/vdpau/libvdpau_gallium.la libtool: finish: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/sbin ldconfig -n /usr/lib/vdpau -- Libraries have been installed in: /usr/lib/vdpau If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- make install-data-hook make[5]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' GEN install-data-hook ln: failed to create hard link ‘//usr/lib/vdpau/libvdpau_radeonsi.so.1.0.0’ = ‘.libs/libvdpau_gallium.so.1.0.0’: Invalid cross-device link make[5]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[4]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[3]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxinfo: Print XFB, TBO, and UBO limits
On Mon, Jun 23, 2014 at 9:48 AM, Brian Paul bri...@vmware.com wrote: From: Fredrik Höglund fred...@kde.org Updated patch for refactored glxinfo/wglinfo code by Brian Paul. There were more patches that added more things... http://patchwork.freedesktop.org/project/mesa/list/?q=glxinfo BTW, is the intention of glxinfo -l to print all limits, or is there some filter on what's useful? Signed-off-by: Brian Paul bri...@vmware.com --- src/xdemos/glinfo_common.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c index e6517d7..4864f58 100644 --- a/src/xdemos/glinfo_common.c +++ b/src/xdemos/glinfo_common.c @@ -522,6 +522,28 @@ print_limits(const char *extensions, const char *oglstring, int version, { 1, GL_MAX_COLOR_ATTACHMENTS, GL_MAX_COLOR_ATTACHMENTS, GL_ARB_framebuffer_object }, { 1, GL_MAX_SAMPLES, GL_MAX_SAMPLES, GL_ARB_framebuffer_object }, #endif +#if defined (GL_EXT_transform_feedback) + { 1, GL_MAX_TRANSFORM_FEEDBACK_BUFFERS, GL_MAX_TRANSFORM_FEEDBACK_BUFFERS, GL_EXT_transform_feedback }, + { 1, GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT, GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS, GL_EXT_transform_feedback }, + { 1, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS, GL_EXT_transform_feedback, }, + { 1, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_EXT, GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS, GL_EXT_transform_feedback }, +#endif +#if defined (GL_ARB_texture_buffer_object) + { 1, GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT, GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT, GL_ARB_texture_buffer_object }, + { 1, GL_MAX_TEXTURE_BUFFER_SIZE, GL_MAX_TEXTURE_BUFFER_SIZE, GL_ARB_texture_buffer_object }, +#endif +#if defined (GL_ARB_uniform_buffer_object) + { 1, GL_MAX_VERTEX_UNIFORM_BLOCKS, GL_MAX_VERTEX_UNIFORM_BLOCKS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_FRAGMENT_UNIFORM_BLOCKS, GL_MAX_FRAGMENT_UNIFORM_BLOCKS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_GEOMETRY_UNIFORM_BLOCKS, GL_MAX_GEOMETRY_UNIFORM_BLOCKS , GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_UNIFORM_BLOCKS, GL_MAX_COMBINED_UNIFORM_BLOCKS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_UNIFORM_BUFFER_BINDINGS, GL_MAX_UNIFORM_BUFFER_BINDINGS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_UNIFORM_BLOCK_SIZE, GL_MAX_UNIFORM_BLOCK_SIZE, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS, GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS, GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS, GL_ARB_uniform_buffer_object }, + { 1, GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS, GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS, GL_ARB_uniform_buffer_object }, + { 1, GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT, GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT, GL_ARB_uniform_buffer_object }, +#endif { 0, (GLenum) 0, NULL, NULL } }; GLint i, max[2]; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] targets/(vdpau|xvmc): hardlink against the installed library
Previous two commits, resolved the symlink generation required by the versioning of the library and incorrectly changed the way hardlinks are created by linking the ones from the build tree. If the device used for building differs from the one set as destination linking will fail. Reported-by: Andy Furniss adf.li...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Andy does this fixes the problem ? Cheers Emil src/gallium/targets/vdpau/Makefile.am | 4 ++-- src/gallium/targets/xvmc/Makefile.am | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/targets/vdpau/Makefile.am b/src/gallium/targets/vdpau/Makefile.am index 9920bd9..2059274 100644 --- a/src/gallium/targets/vdpau/Makefile.am +++ b/src/gallium/targets/vdpau/Makefile.am @@ -131,7 +131,7 @@ install-data-hook: j=libvdpau_gallium.$(LIB_EXT); \ k=libvdpau_$${i}.$(LIB_EXT);\ l=$${k}.$(VDPAU_MAJOR).$(VDPAU_MINOR).0;\ - ln -f .libs/$${j}.$(VDPAU_MAJOR).$(VDPAU_MINOR).0 \ + ln -f $${dest_dir}/$${j}.$(VDPAU_MAJOR).$(VDPAU_MINOR).0 \ $${dest_dir}/$${l}; \ ln -sf $${l}\ $${dest_dir}/$${k}.$(VDPAU_MAJOR).$(VDPAU_MINOR); \ @@ -140,4 +140,4 @@ install-data-hook: ln -sf $${l}\ $${dest_dir}/$${k}; \ done; \ - $(RM) -f $$dest_dir/libvdpau_gallium.* + $(RM) -f $${dest_dir}/libvdpau_gallium.* diff --git a/src/gallium/targets/xvmc/Makefile.am b/src/gallium/targets/xvmc/Makefile.am index 6e81e08..bf986f4 100644 --- a/src/gallium/targets/xvmc/Makefile.am +++ b/src/gallium/targets/xvmc/Makefile.am @@ -88,7 +88,7 @@ install-data-hook: j=libXvMCgallium.$(LIB_EXT);\ k=libXvMC$${i}.$(LIB_EXT); \ l=$${k}.$(XVMC_MAJOR).$(XVMC_MINOR).0; \ - ln -f .libs/$${j}.$(XVMC_MAJOR).$(XVMC_MINOR).0 \ + ln -f $${dest_dir}/$${j}.$(XVMC_MAJOR).$(XVMC_MINOR).0 \ $${dest_dir}/$${l}; \ ln -sf $${l}\ $${dest_dir}/$${k}.$(XVMC_MAJOR).$(XVMC_MINOR); \ -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/13] glsl: Add a lowering pass for gl_VertexID
On 06/22/2014 04:32 AM, Marek Olšák wrote: If you define enums in a struct or class, it then works like a namespace. E.g. the proper form to use such an enum would be: ctx-Const.VertexID = gl_constants::gl_VertexID_native; I'd swear that I tried that... I know I tried a bunch of other variations that failed. Anyway, I'll change it to have the enum inside the struct. Thanks for the tip. Marek On Sat, Jun 21, 2014 at 3:01 AM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Converts gl_VertexID to (gl_VertexIDMESA + gl_BaseVertex). gl_VertexIDMESA is backed by SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, and gl_BaseVertex is backed by a built-in uniform from {STATE_INTERNAL, STATE_BASE_VERTEX}. NOTE: The enum has to be declared outside the struct or C++ just cannot find the values. I tried many variations of scope resolution in linker.cpp, but could not make it do-the-right-thing. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/glsl/Makefile.sources| 1 + src/glsl/ir_optimization.h | 2 + src/glsl/linker.cpp | 7 ++ src/glsl/lower_vertex_id.cpp | 152 +++ src/mesa/main/context.c | 5 ++ src/mesa/main/mtypes.h | 14 6 files changed, 181 insertions(+) create mode 100644 src/glsl/lower_vertex_id.cpp diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources index b54eae7..b884d66 100644 --- a/src/glsl/Makefile.sources +++ b/src/glsl/Makefile.sources @@ -77,6 +77,7 @@ LIBGLSL_FILES = \ $(GLSL_SRCDIR)/lower_vec_index_to_swizzle.cpp \ $(GLSL_SRCDIR)/lower_vector.cpp \ $(GLSL_SRCDIR)/lower_vector_insert.cpp \ + $(GLSL_SRCDIR)/lower_vertex_id.cpp \ $(GLSL_SRCDIR)/lower_output_reads.cpp \ $(GLSL_SRCDIR)/lower_ubo_reference.cpp \ $(GLSL_SRCDIR)/opt_algebraic.cpp \ diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h index b83c225..2892dc2 100644 --- a/src/glsl/ir_optimization.h +++ b/src/glsl/ir_optimization.h @@ -125,6 +125,8 @@ bool optimize_redundant_jumps(exec_list *instructions); bool optimize_split_arrays(exec_list *instructions, bool linked); bool lower_offset_arrays(exec_list *instructions); +bool lower_vertex_id(gl_shader *shader); + ir_rvalue * compare_index_block(exec_list *instructions, ir_variable *index, unsigned base, unsigned components, void *mem_ctx); diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 813108c..2e9a0b6 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -1623,6 +1623,13 @@ link_intrastage_shaders(void *mem_ctx, } } + if (ctx-Const.VertexID != gl_VertexID_native) { + /* FINISHME: The other lowering method is not yet implemented. + */ + assert(ctx-Const.VertexID == gl_VertexID_using_uniform_gl_BaseVertex); + lower_vertex_id(linked); + } + /* Make a pass over all variable declarations to ensure that arrays with * unspecified sizes have a size specified. The size is inferred from the * max_array_access field. diff --git a/src/glsl/lower_vertex_id.cpp b/src/glsl/lower_vertex_id.cpp new file mode 100644 index 000..c9cced1 --- /dev/null +++ b/src/glsl/lower_vertex_id.cpp @@ -0,0 +1,152 @@ +/* + * 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. + */ + +/** + * \file lower_vertex_id.cpp + * + * There exists hardware, such as i965, that does not implement the OpenGL + * semantic for gl_VertexID. Instead, that hardware does not include the + * value of basevertex in the gl_VertexID value. To implement the OpenGL + * semantic, we'll have to convert gl_Vertex_ID to + * gl_VertexIDMESA+gl_BaseVertexMESA. + */ + +#include glsl_symbol_table.h
Re: [Mesa-dev] [PATCH 00/13] Fix gl_VertexID on i965
On 06/21/2014 08:36 AM, Roland Scheidegger wrote: Am 21.06.2014 03:00, schrieb Ian Romanick: This patch series fixes bugs in the i965 w.r.t. several uses of gl_VertexID. OpenGL (desktop and ES) have the following expectations of gl_VertexID: 1. When used with BaseVertex drawing commands, gl_VertexID will include the value of basevertex. This differens from the other API, but the change in OpenGL was based on feedback from application developers. This only affects OpenGL 3.2+. I don't question this, but note some binary drivers may not agree. There are unforunately lots of man pages around of glDrawElementsInstancedBaseVertexBaseInstance too which state: The basevertex has no effect on the shader-visible value of gl_VertexID. There's a bug filed about this (https://www.khronos.org/bugzilla/show_bug.cgi?id=932) which is still open though maybe it has all been resolved... (I'll just mention that llvmpipe right now will do d3d10-style vertexID though I guess indeed at some point we need to make it either switchable or implement GL_ARB_shader_draw_parameters so it can be worked around easily in the state tracker.) It doesn't matter what their documentation says... there are desktop OpenGL conformance tests that expect this behavior. :( See also the overview of GL_ARB_shader_draw_parameters (emphasis mine): In unextended GL, vertex shaders have inputs named gl_VertexID and gl_InstanceID, which contain, respectively the index of the vertex and instance. The value of gl_VertexID is the implicitly passed index of the vertex being processed, which *includes the value of baseVertex*, for those commands that accept it. Meanwhile, gl_InstanceID is the integer index of the current instance being processed, but, even for commands that accept a baseInstance parameter, it does not include the value of this argument. Furthermore, the equivalents to these variables in other graphics APIs do not necessarily follow these conventions. The reason for this inconsistency is that there are legitimate use cases for both inclusion and exclusion of the baseVertex or baseInstance parameters in gl_VertexID and gl_InstanceID, respectively. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Allow the blorp blit between BGR and RGB
Previously the blorp blitter would only be used if the format is identical or there is only a difference between whether there is an alpha component or not. This patch makes it also allow the blorp blitter if the only difference is the ordering of the RGB components (ie, RGB or BGR). This is particularly useful since commit 61e264f4fcdba3623 because Mesa now prefers RGB ordering for textures but the window system buffers are still created as BGR. That means that the blorp blitter won't be used for the (probably) common case of blitting from a texture to the window system buffer. This doesn't cause any regressions in the FBO piglit tests on Haswell. On Sandybridge it causes the fbo-blit-stretch test to fail but that is only because it was failing anyway before the above commit and that commit hid the problem. https://bugs.freedesktop.org/show_bug.cgi?id=68365 --- src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 28 +--- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp index 118af27..d7f5f7d 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp @@ -120,20 +120,34 @@ do_blorp_blit(struct brw_context *brw, GLbitfield buffer_bit, } static bool +format_is_rgba_or_rgbx_byte(mesa_format format) +{ + switch (format) { + case MESA_FORMAT_B8G8R8X8_UNORM: + case MESA_FORMAT_B8G8R8A8_UNORM: + case MESA_FORMAT_R8G8B8X8_UNORM: + case MESA_FORMAT_R8G8B8A8_UNORM: + return true; + default: + return false; + } +} + +static bool color_formats_match(mesa_format src_format, mesa_format dst_format) { mesa_format linear_src_format = _mesa_get_srgb_format_linear(src_format); mesa_format linear_dst_format = _mesa_get_srgb_format_linear(dst_format); - /* Normally, we require the formats to be equal. However, we also support + /* Normally, we require the formats to be equal. However, we also support * blitting from ARGB to XRGB (discarding alpha), and from XRGB to ARGB -* (overriding alpha to 1.0 via blending). +* (overriding alpha to 1.0 via blending) as well as swizzling between BGR +* and RGB. */ - return linear_src_format == linear_dst_format || - (linear_src_format == MESA_FORMAT_B8G8R8X8_UNORM - linear_dst_format == MESA_FORMAT_B8G8R8A8_UNORM) || - (linear_src_format == MESA_FORMAT_B8G8R8A8_UNORM - linear_dst_format == MESA_FORMAT_B8G8R8X8_UNORM); + + return (linear_src_format == linear_dst_format || + (format_is_rgba_or_rgbx_byte(linear_src_format) +format_is_rgba_or_rgbx_byte(linear_dst_format))); } static bool -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it afaik. -Emil [1] http://patchwork.freedesktop.org/patch/28378/ --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --e--prefix you use to compile it. So if you're putting mesa into anable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] nv50/ir: make ARB_viewport_array behave like it does with other drivers
previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not tested on nv50 Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de --- V2: provide description fix naming of vars .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 30 -- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h index c885c8c..b4086f7 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h @@ -177,6 +177,7 @@ struct nv50_ir_prog_info uint8_t vertexId; /* system value index of VertexID */ uint8_t edgeFlagIn; uint8_t edgeFlagOut; + int8_t viewportId;/* output index of ViewportId */ uint8_t fragDepth; /* output index of FragDepth */ uint8_t sampleMask;/* output index of SampleMask */ boolean sampleInterp; /* perform sample interp on all fp inputs */ diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index a0f1fe1..a77b342 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -790,6 +790,8 @@ bool Source::scanSource() info-prop.gp.instanceCount = 1; // default value } + info-io.viewportId = -1; + info-immd.data = (uint32_t *)MALLOC(scan.immediate_count * 16); info-immd.type = (ubyte *)MALLOC(scan.immediate_count * sizeof(ubyte)); @@ -982,6 +984,9 @@ bool Source::scanDeclaration(const struct tgsi_full_declaration *decl) case TGSI_SEMANTIC_SAMPLEMASK: info-io.sampleMask = i; break; + case TGSI_SEMANTIC_VIEWPORT_INDEX: +info-io.viewportId = i; +break; default: break; } @@ -1258,6 +1263,8 @@ private: Stack joinBBs; // fork BB, for inserting join ops on ENDIF Stack loopBBs; // loop headers Stack breakBBs; // end of / after loop + + Value *viewport; }; Symbol * @@ -1555,8 +1562,15 @@ Converter::storeDst(const tgsi::Instruction::DstRegister dst, int c, mkOp2(OP_WRSV, TYPE_U32, NULL, dstToSym(dst, c), val); } else if (f == TGSI_FILE_OUTPUT prog-getType() != Program::TYPE_FRAGMENT) { - if (ptr || (info-out[idx].mask (1 c))) - mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + + if (ptr || (info-out[idx].mask (1 c))) { + /* Save the viewport index into a scratch register so that it can be +exported at EMIT time */ + if (info-out[dst.getIndex(0)].sn == TGSI_SEMANTIC_VIEWPORT_INDEX viewport != NULL) +mkOp1(OP_MOV, TYPE_U32, viewport, val); + else +mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + } } else if (f == TGSI_FILE_TEMPORARY || f == TGSI_FILE_PREDICATE || @@ -2523,6 +2537,14 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c)); break; case TGSI_OPCODE_EMIT: + /* export the saved viewport index */ + if (viewport != NULL) { + Symbol *vpSym = mkSymbol(FILE_SHADER_OUTPUT, info-io.viewportId, + TYPE_U32, + info-out[info-io.viewportId].slot[0] * 4); + mkStore(OP_EXPORT, TYPE_U32, vpSym, NULL, viewport); + } + /* fallthrough */ case TGSI_OPCODE_ENDPRIM: // get vertex stream if specified (must be immediate) src0 = tgsi.srcCount() ? @@ -2952,6 +2974,10 @@ Converter::run() mkOp1(OP_RCP, TYPE_F32, fragCoord[3], fragCoord[3]); } + if (info-io.viewportId = 0) + viewport = getScratch(); + else viewport = NULL; + for (ip = 0; ip code-scan.num_instructions; ++ip) { if (!handleInstruction(code-insns[ip])) return false; -- 1.8.4.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it afaik. -Emil [1] http://patchwork.freedesktop.org/patch/28378/ --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --e--prefix you use to compile it. So if you're putting mesa into anable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list
Re: [Mesa-dev] [PATCH] i965: Allow the blorp blit between BGR and RGB
On Mon, Jun 23, 2014 at 11:02 AM, Neil Roberts n...@linux.intel.com wrote: Previously the blorp blitter would only be used if the format is identical or there is only a difference between whether there is an alpha component or not. This patch makes it also allow the blorp blitter if the only difference is the ordering of the RGB components (ie, RGB or BGR). This is particularly useful since commit 61e264f4fcdba3623 because Mesa now prefers RGB ordering for textures but the window system buffers are still created as BGR. That means that the blorp blitter won't be used for the (probably) common case of blitting from a texture to the window system buffer. This doesn't cause any regressions in the FBO piglit tests on Haswell. On Sandybridge it causes the fbo-blit-stretch test to fail but that is only because it was failing anyway before the above commit and that commit hid the problem. https://bugs.freedesktop.org/show_bug.cgi?id=68365 We typically write Bugzilla: https:/// Reviewed-by: Matt Turner matts...@gmail.com Do you have commit access? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On a different note, do we really need the suffixes .1.0.0 etc.? It's not like the version is going to change. Marek On Mon, Jun 23, 2014 at 8:31 PM, Aaron Watry awa...@gmail.com wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it afaik. -Emil [1] http://patchwork.freedesktop.org/patch/28378/ --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-vdpau --e--prefix you use to compile it. So if you're putting mesa into anable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5
Re: [Mesa-dev] [PATCH 2/5] clover: Fix not setting build log if the build succeeds.
On Sat, Jun 21, 2014 at 06:33:17PM +0200, Francisco Jerez wrote: Tom Stellard thomas.stell...@amd.com writes: From: Matt Arsenault arse...@gmail.com If there were only warnings, they would not be added to the log. Also fixes valgrind use after free errors. --- src/gallium/state_trackers/clover/core/compiler.hpp | 3 ++- src/gallium/state_trackers/clover/core/error.hpp | 2 +- src/gallium/state_trackers/clover/core/program.cpp| 11 +++ src/gallium/state_trackers/clover/llvm/invocation.cpp | 14 +++--- 4 files changed, 17 insertions(+), 13 deletions(-) diff --git a/src/gallium/state_trackers/clover/core/compiler.hpp b/src/gallium/state_trackers/clover/core/compiler.hpp index 49cd022..3ce132f 100644 --- a/src/gallium/state_trackers/clover/core/compiler.hpp +++ b/src/gallium/state_trackers/clover/core/compiler.hpp @@ -32,7 +32,8 @@ namespace clover { module compile_program_llvm(const compat::string source, pipe_shader_ir ir, const compat::string target, - const compat::string opts); + const compat::string opts, + std::string log_out); This doesn't work. I'm afraid you need to use compat::string on the compiler interface because the C++98 and C++11 versions of std::string are not guaranteed to be binary compatible. This mess will go away once we can drop support for the non-C++11 versions of LLVM. Have a look at the attached patch for the memory management issues with compat::string. Even with your patch, I'm still having trouble getting this to work. What is the correct pattern here? I know I need to use compat::string in the function signature, but what type should I pass to the compile_program_llvm() function from program::build()? A std::string a compat::string, something else? -Tom And maybe rename the output argument to r_log as is usual everywhere else in clover? module compile_program_tgsi(const compat::string source); } diff --git a/src/gallium/state_trackers/clover/core/error.hpp b/src/gallium/state_trackers/clover/core/error.hpp index 28459f3..9802195 100644 --- a/src/gallium/state_trackers/clover/core/error.hpp +++ b/src/gallium/state_trackers/clover/core/error.hpp @@ -66,7 +66,7 @@ namespace clover { class build_error : public error { public: - build_error(const compat::string log) : + build_error(const compat::string log = ) : Can you rename the argument to what as it's no longer going to hold the compilation log? error(CL_BUILD_PROGRAM_FAILURE, log) { } }; diff --git a/src/gallium/state_trackers/clover/core/program.cpp b/src/gallium/state_trackers/clover/core/program.cpp index 3aaa652..91ee553 100644 --- a/src/gallium/state_trackers/clover/core/program.cpp +++ b/src/gallium/state_trackers/clover/core/program.cpp @@ -52,15 +52,18 @@ program::build(const ref_vectordevice devs, const char *opts) { _opts.insert({ dev, opts }); + std::string build_log; + try { auto module = (dev.ir_format() == PIPE_SHADER_IR_TGSI ? compile_program_tgsi(_source) : compile_program_llvm(_source, dev.ir_format(), -dev.ir_target(), build_opts(dev))); +dev.ir_target(), build_opts(dev), +build_log)); _binaries.insert({ dev, module }); - - } catch (build_error e) { -_logs.insert({ dev, e.what() }); +_logs.insert({ dev, build_log }); + } catch (const build_error ) { +_logs.insert({ dev, build_log }); throw; } } diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp index 48810bd..0dc1f50 100644 --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp @@ -120,12 +120,11 @@ namespace { compile(llvm::LLVMContext llvm_ctx, const std::string source, const std::string name, const std::string triple, const std::string processor, const std::string opts, - clang::LangAS::Map address_spaces) { + clang::LangAS::Map address_spaces, std::string log_out) { clang::CompilerInstance c; clang::EmitLLVMOnlyAction act(llvm_ctx); - std::string log; - llvm::raw_string_ostream s_log(log); + llvm::raw_string_ostream s_log(log_out); std::string libclc_path = LIBCLC_LIBEXECDIR + processor + - + triple + .bc;
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 23/06/14 19:31, Aaron Watry wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 In case you're interested you can check the i-node for each file (ls -i) where both libvdpau*1.0.0 should link to the same one. Above files look good. I'm guessing that this is with the linked patch ? Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig Rather silly question but why ? AFAIK the vdpau backend explicitly dlopened, thus you should not need ldconfig here. And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ Looks good. Are there any extra messages/warning/errors during the build stage ? Cheers, Emil On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it afaik. -Emil [1] http://patchwork.freedesktop.org/patch/28378/ --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed. Let me know if latest master work for you. -Emil Of course I do if I leave the old libs in place it still uses them, but if I remove them I get no new links installed. ./autogen.sh --prefix=/usr
Re: [Mesa-dev] [PATCH] targets/(vdpau|xvmc): hardlink against the installed library
Emil Velikov wrote: Previous two commits, resolved the symlink generation required by the versioning of the library and incorrectly changed the way hardlinks are created by linking the ones from the build tree. If the device used for building differs from the one set as destination linking will fail. Reported-by: Andy Furniss adf.li...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Andy does this fixes the problem ? I still don't get libvdpau_gallium installed. I do with this get the usual one installed properly now - ls -lh /usr/lib/vdpau/ total 11M lrwxrwxrwx 1 root root 26 Jun 23 19:17 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 19:17 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 19:17 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 1 root root 11M Jun 23 19:17 libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 1 root root 987 Jun 23 15:51 libvdpau_trace.la lrwxrwxrwx 1 root root 23 Jun 23 15:51 libvdpau_trace.so - libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 23 Jun 23 15:51 libvdpau_trace.so.1 - libvdpau_trace.so.1.0.0 -rwxr-xr-x 1 root root 173K Jun 23 15:51 libvdpau_trace.so.1.0.0 Making install in gallium/targets make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets' Making install in vdpau make[3]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' GEN all-local make[4]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/usr/lib/vdpau' /bin/sh ../../../../libtool --mode=install /bin/install -c libvdpau_gallium.la '/usr/lib/vdpau' libtool: install: /bin/install -c .libs/libvdpau_gallium.so.1.0.0 /usr/lib/vdpau/libvdpau_gallium.so.1.0.0 libtool: install: (cd /usr/lib/vdpau { ln -s -f libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1 || { rm -f libvdpau_gallium.so.1 ln -s libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1; }; }) libtool: install: (cd /usr/lib/vdpau { ln -s -f libvdpau_gallium.so.1.0.0 libvdpau_gallium.so || { rm -f libvdpau_gallium.so ln -s libvdpau_gallium.so.1.0.0 libvdpau_gallium.so; }; }) libtool: install: /bin/install -c .libs/libvdpau_gallium.lai /usr/lib/vdpau/libvdpau_gallium.la libtool: finish: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/sbin ldconfig -n /usr/lib/vdpau -- Libraries have been installed in: /usr/lib/vdpau If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- make install-data-hook make[5]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' GEN install-data-hook make[5]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[4]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[3]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] nv50/ir: make ARB_viewport_array behave like it does with other drivers
On Mon, Jun 23, 2014 at 2:15 PM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not tested on nv50 I'll be sure to test it out. Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de --- V2: provide description fix naming of vars .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 30 -- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h index c885c8c..b4086f7 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h @@ -177,6 +177,7 @@ struct nv50_ir_prog_info uint8_t vertexId; /* system value index of VertexID */ uint8_t edgeFlagIn; uint8_t edgeFlagOut; + int8_t viewportId;/* output index of ViewportId */ output index of ViewportIndex. (Hm, perhaps the var should be called viewportIndex? Whatever... I don't really care.) uint8_t fragDepth; /* output index of FragDepth */ uint8_t sampleMask;/* output index of SampleMask */ boolean sampleInterp; /* perform sample interp on all fp inputs */ diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index a0f1fe1..a77b342 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -790,6 +790,8 @@ bool Source::scanSource() info-prop.gp.instanceCount = 1; // default value } + info-io.viewportId = -1; + info-immd.data = (uint32_t *)MALLOC(scan.immediate_count * 16); info-immd.type = (ubyte *)MALLOC(scan.immediate_count * sizeof(ubyte)); @@ -982,6 +984,9 @@ bool Source::scanDeclaration(const struct tgsi_full_declaration *decl) case TGSI_SEMANTIC_SAMPLEMASK: info-io.sampleMask = i; break; + case TGSI_SEMANTIC_VIEWPORT_INDEX: +info-io.viewportId = i; +break; default: break; } @@ -1258,6 +1263,8 @@ private: Stack joinBBs; // fork BB, for inserting join ops on ENDIF Stack loopBBs; // loop headers Stack breakBBs; // end of / after loop + + Value *viewport; }; Symbol * @@ -1555,8 +1562,15 @@ Converter::storeDst(const tgsi::Instruction::DstRegister dst, int c, mkOp2(OP_WRSV, TYPE_U32, NULL, dstToSym(dst, c), val); } else if (f == TGSI_FILE_OUTPUT prog-getType() != Program::TYPE_FRAGMENT) { - if (ptr || (info-out[idx].mask (1 c))) - mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + + if (ptr || (info-out[idx].mask (1 c))) { + /* Save the viewport index into a scratch register so that it can be +exported at EMIT time */ + if (info-out[dst.getIndex(0)].sn == TGSI_SEMANTIC_VIEWPORT_INDEX viewport != NULL) Just noticed this now, but should this just be info-out[idx] ? +mkOp1(OP_MOV, TYPE_U32, viewport, val); + else +mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + } } else if (f == TGSI_FILE_TEMPORARY || f == TGSI_FILE_PREDICATE || @@ -2523,6 +2537,14 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c)); break; case TGSI_OPCODE_EMIT: + /* export the saved viewport index */ + if (viewport != NULL) { + Symbol *vpSym = mkSymbol(FILE_SHADER_OUTPUT, info-io.viewportId, Pretty sure the second arg should be 0, not index of the vp in info-out. Can you verify? + TYPE_U32, + info-out[info-io.viewportId].slot[0] * 4); + mkStore(OP_EXPORT, TYPE_U32, vpSym, NULL, viewport); + } + /* fallthrough */ case TGSI_OPCODE_ENDPRIM: // get vertex stream if specified (must be immediate) src0 = tgsi.srcCount() ? @@ -2952,6 +2974,10 @@ Converter::run() mkOp1(OP_RCP, TYPE_F32, fragCoord[3], fragCoord[3]); } + if (info-io.viewportId = 0) + viewport = getScratch(); + else viewport = NULL; viewport=NULL should be on a separate line. (I used shorthand in my earlier email... sorry.) + for (ip = 0; ip code-scan.num_instructions; ++ip) { if
Re: [Mesa-dev] [PATCH] targets/(vdpau|xvmc): hardlink against the installed library
On 23/06/14 19:58, Andy Furniss wrote: Emil Velikov wrote: Previous two commits, resolved the symlink generation required by the versioning of the library and incorrectly changed the way hardlinks are created by linking the ones from the build tree. If the device used for building differs from the one set as destination linking will fail. Reported-by: Andy Furniss adf.li...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Andy does this fixes the problem ? I still don't get libvdpau_gallium installed. Not sure what made you believe that libvdpau_gallium should be installed, but that truly is not the case. I do with this get the usual one installed properly now - ls -lh /usr/lib/vdpau/ total 11M lrwxrwxrwx 1 root root 26 Jun 23 19:17 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 19:17 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 19:17 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 1 root root 11M Jun 23 19:17 libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 1 root root 987 Jun 23 15:51 libvdpau_trace.la lrwxrwxrwx 1 root root 23 Jun 23 15:51 libvdpau_trace.so - libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 23 Jun 23 15:51 libvdpau_trace.so.1 - libvdpau_trace.so.1.0.0 -rwxr-xr-x 1 root root 173K Jun 23 15:51 libvdpau_trace.so.1.0.0 Great thanks for reporting and testing. Making install in gallium/targets make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets' Making install in vdpau make[3]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' GEN all-local make[4]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/usr/lib/vdpau' /bin/sh ../../../../libtool --mode=install /bin/install -c libvdpau_gallium.la '/usr/lib/vdpau' libtool: install: /bin/install -c .libs/libvdpau_gallium.so.1.0.0 /usr/lib/vdpau/libvdpau_gallium.so.1.0.0 libtool: install: (cd /usr/lib/vdpau { ln -s -f libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1 || { rm -f libvdpau_gallium.so.1 ln -s libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1; }; }) libtool: install: (cd /usr/lib/vdpau { ln -s -f libvdpau_gallium.so.1.0.0 libvdpau_gallium.so || { rm -f libvdpau_gallium.so ln -s libvdpau_gallium.so.1.0.0 libvdpau_gallium.so; }; }) libtool: install: /bin/install -c .libs/libvdpau_gallium.lai /usr/lib/vdpau/libvdpau_gallium.la libtool: finish: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/sbin ldconfig -n /usr/lib/vdpau -- Libraries have been installed in: /usr/lib/vdpau If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- One should never link against the vdpau backends so we can ignore the above message. I'm assuming that vdpau works as expected now ? Cheers Emil make install-data-hook make[5]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' GEN install-data-hook make[5]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[4]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' make[3]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Allow the blorp blit between BGR and RGB
Matt Turner matts...@gmail.com writes: We typically write Bugzilla: https:/// Reviewed-by: Matt Turner matts...@gmail.com Do you have commit access? Thanks for the review. I do have commit access so I've pushed the patch with the suggested change to the commit message. I've also started to try and look at why that bug is happening on SandyBridge. Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
The vdpau loader requires only major, and falls back to an unversioned SO. Thus IMHO we should keep at least the major. In the future we might want to move to a versioning scheme similar to nvidia, which lacks the revision number, thus we'll be OK with the BSD guys :) libvdpau_nvidia.so - libvdpau_nvidia.so.1 libvdpau_nvidia.so.1 - libvdpau_nvidia.so.319.22 libvdpau_nvidia.so.319.22 libvdpau_nouveau.so - libvdpau_nouveau.so.1 libvdpau_nouveau.so.1 - libvdpau_nouveau.so.10.2 libvdpau_nouveau.so.10.2 -Emil On 23/06/14 19:45, Marek Olšák wrote: On a different note, do we really need the suffixes .1.0.0 etc.? It's not like the version is going to change. Marek On Mon, Jun 23, 2014 at 8:31 PM, Aaron Watry awa...@gmail.com wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it afaik. -Emil [1] http://patchwork.freedesktop.org/patch/28378/ --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. How is this supposed to work from a users point of view, by which I mean that it seems if I build current mesa I no longer have vdpau. Yes I had a few copy/paste typos that were causing make install to fall short
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 17:18, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. Yes it should be - the viewport should be set somewhere (I'm not exactly sure where it gets set) and since in GL the old commands just set all viewports this should work. This is the first time I'm looking at llvmpipe in detail, so forgive the potential stupidity... It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the viewport index. Should it be? [Or is there some non-obvious place where it's actually being clamped?] It seems like the layer is clamped explicitly in lp_setup_tri and lp_setup_point. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Allow the blorp blit between BGR and RGB
On Mon, Jun 23, 2014 at 12:06 PM, Neil Roberts n...@linux.intel.com wrote: Matt Turner matts...@gmail.com writes: We typically write Bugzilla: https:/// Reviewed-by: Matt Turner matts...@gmail.com Do you have commit access? Thanks for the review. I do have commit access so I've pushed the patch with the suggested change to the commit message. Excellent. Thanks Neil! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/(vdpau|xvmc): hardlink against the installed library
Emil Velikov wrote: On 23/06/14 19:58, Andy Furniss wrote: I still don't get libvdpau_gallium installed. Not sure what made you believe that libvdpau_gallium should be installed, but that truly is not the case. Ahh, it was looking at the output of make install, which usually flies past and is ignored, seeing the word install combined with the expectation that something new/different was going to happen :-) I'm assuming that vdpau works as expected now ? Yes, working OK. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
If the version is always going to be 1.0.0, it's pointless. If it's going to be equal to the Mesa version, then it might find some use. Marek On Mon, Jun 23, 2014 at 9:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: The vdpau loader requires only major, and falls back to an unversioned SO. Thus IMHO we should keep at least the major. In the future we might want to move to a versioning scheme similar to nvidia, which lacks the revision number, thus we'll be OK with the BSD guys :) libvdpau_nvidia.so - libvdpau_nvidia.so.1 libvdpau_nvidia.so.1 - libvdpau_nvidia.so.319.22 libvdpau_nvidia.so.319.22 libvdpau_nouveau.so - libvdpau_nouveau.so.1 libvdpau_nouveau.so.1 - libvdpau_nouveau.so.10.2 libvdpau_nouveau.so.10.2 -Emil On 23/06/14 19:45, Marek Olšák wrote: On a different note, do we really need the suffixes .1.0.0 etc.? It's not like the version is going to change. Marek On Mon, Jun 23, 2014 at 8:31 PM, Aaron Watry awa...@gmail.com wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it afaik. -Emil [1] http://patchwork.freedesktop.org/patch/28378/ --Aaron On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 16:10, Andy Furniss wrote: Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
I'm afraid that I cannot predict the future (is always going to be..). IMHO we should keep the major, for when the loader gains different codepaths for v1.0 vs v2.0 etc. Adding the mesa version will easily allow us to check for broken/manged installs and possibly other issues. Don't plan on touching any of the above yet, but would be nice to see if my rationale is not completely bonkers :) Emil On 23/06/14 20:21, Marek Olšák wrote: If the version is always going to be 1.0.0, it's pointless. If it's going to be equal to the Mesa version, then it might find some use. Marek On Mon, Jun 23, 2014 at 9:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: The vdpau loader requires only major, and falls back to an unversioned SO. Thus IMHO we should keep at least the major. In the future we might want to move to a versioning scheme similar to nvidia, which lacks the revision number, thus we'll be OK with the BSD guys :) libvdpau_nvidia.so - libvdpau_nvidia.so.1 libvdpau_nvidia.so.1 - libvdpau_nvidia.so.319.22 libvdpau_nvidia.so.319.22 libvdpau_nouveau.so - libvdpau_nouveau.so.1 libvdpau_nouveau.so.1 - libvdpau_nouveau.so.10.2 libvdpau_nouveau.so.10.2 -Emil On 23/06/14 19:45, Marek Olšák wrote: On a different note, do we really need the suffixes .1.0.0 etc.? It's not like the version is going to change. Marek On Mon, Jun 23, 2014 at 8:31 PM, Aaron Watry awa...@gmail.com wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an ldconfig ? Does [1] help ? For some reason, while the files are in the same place, mplayer -vo vdpau chokes on loading these files now. If I copy libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then mplayer (-vo vdpau) picks it up and plays without issue. Is the VDPAU backend loader looking in the wrong directory? The path of the vdpau backends is hard-coded in libvdapu at build time. vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau release that has it
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am 23.06.2014 21:14, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 17:18, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. Yes it should be - the viewport should be set somewhere (I'm not exactly sure where it gets set) and since in GL the old commands just set all viewports this should work. This is the first time I'm looking at llvmpipe in detail, so forgive the potential stupidity... It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the viewport index. Should it be? [Or is there some non-obvious place where it's actually being clamped?] It seems like the layer is clamped explicitly in lp_setup_tri and lp_setup_point. This is sort of complicated. Note that for ordinary fs input handling, you don't see viewport index handling anywhere in llvmpipe - this is just handled like any other ordinary attribute (through the interpolation stuff). The code in lp_state_fs for viewport handling is just to get the correct depth range, so you are right the viewport index must be clamped. The clamping is done in lp_setup_tri() however (watch out for viewport_index), the value then gets passed to rasterization (via tri-inputs) and there written into the thread_data (in lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the code in lp_state_fs.c will then pick up to fetch the correct depthrange values (for depth clamping). Though now that I look at it, this looks wrong in draw: draw_clamp_viewport_idx(int idx) { return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0); } The same clamping in llvmpipe looks like this: lp_clamp_viewport_idx(int idx) { return (PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0; } Would only make a difference for negative viewport indices though (and don't ask me what would happen but draw might indeed fetch the viewport values from random memory locations so the result might be quite unpredictable...). Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 3:50 PM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 21:14, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 17:18, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. Yes it should be - the viewport should be set somewhere (I'm not exactly sure where it gets set) and since in GL the old commands just set all viewports this should work. This is the first time I'm looking at llvmpipe in detail, so forgive the potential stupidity... It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the viewport index. Should it be? [Or is there some non-obvious place where it's actually being clamped?] It seems like the layer is clamped explicitly in lp_setup_tri and lp_setup_point. This is sort of complicated. Note that for ordinary fs input handling, you don't see viewport index handling anywhere in llvmpipe - this is just handled like any other ordinary attribute (through the interpolation stuff). The code in lp_state_fs for viewport handling is just to get the correct depth range, so you are right the viewport index must be clamped. The clamping is done in lp_setup_tri() however (watch out for viewport_index), the value then gets passed to rasterization (via tri-inputs) and there written into the thread_data (in lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the code in lp_state_fs.c will then pick up to fetch the correct depthrange values (for depth clamping). Though now that I look at it, this looks wrong in draw: draw_clamp_viewport_idx(int idx) { return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0); } The same clamping in llvmpipe looks like this: lp_clamp_viewport_idx(int idx) { return (PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0; } Would only make a difference for negative viewport indices though (and don't ask me what would happen but draw might indeed fetch the viewport values from random memory locations so the result might be quite unpredictable...). Roland And a viewport index of -1 was one of my test cases. That's probably it! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] draw: (trivial) fix clamping of viewport index
From: Roland Scheidegger srol...@vmware.com The old logic would let all negative values go through unclamped, with potentially disastrous results (probably trying to fetch viewport values from random memory locations). GL has undefined rendering for vp indices outside valid range but that's a bit too undefined... (The logic is now the same as in llvmpipe.) CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/auxiliary/draw/draw_private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_private.h b/src/gallium/auxiliary/draw/draw_private.h index 783c3ef..d8dc2ab 100644 --- a/src/gallium/auxiliary/draw/draw_private.h +++ b/src/gallium/auxiliary/draw/draw_private.h @@ -493,7 +493,7 @@ draw_stats_clipper_primitives(struct draw_context *draw, static INLINE unsigned draw_clamp_viewport_idx(int idx) { - return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0); + return ((PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0); } /** -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: (trivial) fix clamping of viewport index
On Mon, Jun 23, 2014 at 4:08 PM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com The old logic would let all negative values go through unclamped, with potentially disastrous results (probably trying to fetch viewport values from random memory locations). GL has undefined rendering for vp indices outside valid range but that's a bit too undefined... (The logic is now the same as in llvmpipe.) CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org Reviewed-by: Ilia Mirkin imir...@alum.mit.edu I haven't tested whether this fixes my issues (don't have the right patches/setup on this comp) but this seems obviously correct. --- src/gallium/auxiliary/draw/draw_private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_private.h b/src/gallium/auxiliary/draw/draw_private.h index 783c3ef..d8dc2ab 100644 --- a/src/gallium/auxiliary/draw/draw_private.h +++ b/src/gallium/auxiliary/draw/draw_private.h @@ -493,7 +493,7 @@ draw_stats_clipper_primitives(struct draw_context *draw, static INLINE unsigned draw_clamp_viewport_idx(int idx) { - return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0); + return ((PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0); } /** -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Mon, Jun 23, 2014 at 1:54 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 19:31, Aaron Watry wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 In case you're interested you can check the i-node for each file (ls -i) where both libvdpau*1.0.0 should link to the same one. Above files look good. I'm guessing that this is with the linked patch ? Yeah, that's with the patch. I just did an ls -i, and the files do indeed reference the same i-node. This matches with the previous check I had done before the patch (du -sk /usr/local/lib/vdpau roughly matched the size of one of the links, not the sum of both). Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig Rather silly question but why ? AFAIK the vdpau backend explicitly dlopened, thus you should not need ldconfig here. The first time that I discovered this was before I knew that libvdpau only checked it's compile-time prefix for back-end drivers. I had added /usr/local/lib/vdpau to /etc/ld.so.conf.d/vdpau.conf on my system in an attempt to add my vdpau libraries to the library path. It was a dead-end because of the hard-coded vdpau back-end paths, but the discovery that the link is getting created after install by the next ldconfig run was intriguing which is why I called it out. My system is set up with all distro-provided packages under /usr/lib/{arch}/, and all of my hand-compiled stuff under /usr/local/lib (64-bit only). My library path allows /usr/local/lib to override /usr/lib/{arch}, but only for packages that I've bothered to rebuild myself. At this point, that includes waffle, glamor, mesa, libclc, xf86-video-ati, and LLVM. It does NOT include libvdpau, as I had never known a reason to build that myself. Now, I'll either rely on my distro's vdpau-backend drivers, add libvdpau to the list of packages I'm building myself, or just symlink /usr/lib/x86_64-linux-gnu/vdpau to /usr/local/lib/vdpau. --Aaron And now /usr/local/lib/vdpau/ contains: lrwxrwxrwx 1 root root 22 Jun 23 13:27 libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 Configuration: $ ./configure --with-dri-drivers= --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-opencl --enable-opencl-icd --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2 --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls --enable-dri3 --enable-omx And just in case it's useful,after building ${mesa_src_root}/lib/gallium has: awatry@ws-awatry:~/src/mesa/lib/gallium$ ls libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0 libvdpau_radeonsi.so.1.0 radeonsi_dri.so libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so libvdpau_radeonsi.so.1.0.0 libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1 r600_dri.so awatry@ws-awatry:~/src/mesa/lib/gallium$ Looks good. Are there any extra messages/warning/errors during the build stage ? Cheers, Emil On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 18:07, Aaron Watry wrote: On my machine, ${PREFIX}/lib/vdpau contains: libvdpau_gallium.so.1 - libvdpau_r600.so.1.0.0 libvdpau_r600.so* libvdpau_radeonsi.so* Note that libvdpau_gallium.so.1 is only created when I force an ldconfig on my system (until then, I just have libvdpau_[r600|radeonsi]*) What do you mean with force an
[Mesa-dev] [PATCH 1/3] i965/vec4: Don't return void from a void function.
--- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 7fd8c2b..f3316f8 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -366,9 +366,9 @@ vec4_visitor::emit_math(opcode opcode, dst_reg dst, src_reg src) } if (brw-gen = 6) { - return emit_math1_gen6(opcode, dst, src); + emit_math1_gen6(opcode, dst, src); } else { - return emit_math1_gen4(opcode, dst, src); + emit_math1_gen4(opcode, dst, src); } } @@ -418,9 +418,9 @@ vec4_visitor::emit_math(enum opcode opcode, } if (brw-gen = 6) { - return emit_math2_gen6(opcode, dst, src0, src1); + emit_math2_gen6(opcode, dst, src0, src1); } else { - return emit_math2_gen4(opcode, dst, src0, src1); + emit_math2_gen4(opcode, dst, src0, src1); } } -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965/fs: Don't fix_math_operand() on Gen = 8.
--- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index d7b969e..185a1f6 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -1386,7 +1386,7 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst, fs_reg src) * Gen 6 hardware ignores source modifiers (negate and abs) on math * instructions, so we also move to a temp to set those up. */ - if (brw-gen = 6) + if (brw-gen == 6 || brw-gen == 7) src = fix_math_operand(src); fs_inst *inst = emit(opcode, dst, src); @@ -1418,7 +1418,9 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst, fs_reg src0, fs_reg src1) return NULL; } - if (brw-gen = 6) { + if (brw-gen = 8) { + inst = emit(opcode, dst, src0, src1); + } else if (brw-gen = 6) { src0 = fix_math_operand(src0); src1 = fix_math_operand(src1); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965/vec4: Don't fix_math_operand() on Gen = 8.
The emit_math?_gen? functions serve to implement workarounds for the math instruction, none of which exist on Gen8+. --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index f3316f8..3a360d4 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -365,7 +365,9 @@ vec4_visitor::emit_math(opcode opcode, dst_reg dst, src_reg src) return; } - if (brw-gen = 6) { + if (brw-gen = 8) { + emit(opcode, dst, src); + } else if (brw-gen = 6) { emit_math1_gen6(opcode, dst, src); } else { emit_math1_gen4(opcode, dst, src); @@ -417,7 +419,9 @@ vec4_visitor::emit_math(enum opcode opcode, return; } - if (brw-gen = 6) { + if (brw-gen = 8) { + emit(opcode, dst, src0, src1); + } else if (brw-gen = 6) { emit_math2_gen6(opcode, dst, src0, src1); } else { emit_math2_gen4(opcode, dst, src0, src1); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/11] [RFC v2] Solve the mapping bug
On Sun, Jun 22, 2014 at 04:05:49PM +0200, Francisco Jerez wrote: Bruno Jimenez brunoji...@gmail.com writes: On Sat, 2014-06-21 at 17:39 +0200, Francisco Jerez wrote: [...] The implementation of PIPE_TRANSFER_MAP_DIRECTLY introduced in PATCH 10 has somewhat worrying semantics: A mapping with this flag might become stale unpredictably if a kernel is run, maybe from a different command queue. Clover's transfer functions don't hit that path right now on single-threaded applications, but they might in the future as we start accelerating the APIs we currently implement with soft_copy_op(). This is a bug IMHO: even direct mappings should last until the corresponding unmap call. I think I'm not fully understanding you here. I tried to use PIPE_TRANSFER_MAP_DIRECTLY only with clEnqueue{Write,Read} functions, which map the resource, copy it and unmap it when finished. Is it possible for another kernel to access the memory of a buffer that is being read/written? AFAICT, yes. All command queues created on the same device share the same memory pool, so a kernel being queued for execution in one could invalidate a concurrent mapping done with PIPE_TRANSFER_MAP_DIRECTLY by one of the transfer functions. On top of that the transfer functions might start queuing kernels themselves in the future to accelerate certain operations we currently do on the CPU, which would make this scenario more likely. I had no intention of having user mappings made with that flag. [Although a possible solution, with a lot of warnings of course, for the avobe problem could be to allow a user to use this flag] I'm not advocating a revert of the series because it fixes a serious bug, but please don't push patches 10-11, we should probably start looking for a different solution. Some suggestions are: I also asked for them to not to be pushed. And with your reasons, until we find a better way or we change how buffers are handled, I won't propose them again. - Why do you even need a pool? Wouldn't it be possible to create a huge RAT, e.g. covering a 4GB portion of the GPU memory and then use a special memory domain or some sort of flag to tell the kernel to allocate a buffer from that region (or relocate if it's already been allocated elsewhere)? This is especially easy on hardware with virtual memory, as you could simply reserve an arbitrarily large block of virtual memory, bind it as e.g. RAT0, and then map other buffer objects into the block on-demand as they're bound to the compute pipeline -- There would be no need to move the actual bits around. This is similar to the approach I used in my original proof-of-concept implementation of the compute API on nv50. This is one of the things I have been wondering recently, given that radeonsi doesn't use a pool, why r600 needs one? I still have to understand AMD docs and how *exactly* everything works. Probably because on SI compute kernels can access random locations of memory without going through an RAT? I have little actual experience with radeons, Tom should know the low-level details. The reason there is no memory pool in radeonsi is because SI and newer support virtual memory, so there is already one contiguous address space and also because there is no limit to the number of resources that can be accessed by a shader. -Tom 4GB seems like a big amount of memory for me, my little cedar has only 512MB :) - If you insist on using a pool, you could (mostly) avoid the storage duplication and the mapping copies by allocating buffer objects directly from the pool as it was before this series, and then keep some sort of reference count specific to the pool storage that would be incremented on map and decremented on unmap. Once you need to grow the pool you'd keep the old storage around temporarily and migrate buffers to the new storage lazily as they are required or unmapped. Once the reference count drops to zero you'd be free to release the backing BO to the system. The fact that you'd keep both storage buffers around for a bit means that you'd be able to use DMA to migrate the pool contents instead of the CPU copies you're doing now, which is likely to be substantially more efficient. I see how this would solve the slow mappings problem, but I think that it could mean a higher memory usage. In the case of a user creating some buffers, mapping one of them and them adding more so that the pool has to grow, we would have to keep the full size of the old pool just for a buffer, plus the new pool. That's a fair point, this solution would only get rid of the extra copying but it wouldn't solve memory usage problem in some situations (long-lived mappings). IMHO the former is more worrying because it has an impact on every map operation no matter what, while the increased
Re: [Mesa-dev] [PATCH 4/4] nvc0: enable ARB_fragment_layer_viewport
The cap can be removed later if needed. Marek On Mon, Jun 23, 2014 at 2:50 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 7:55 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 12:49, schrieb Roland Scheidegger: Am 22.06.2014 17:10, schrieb Ilia Mirkin: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- docs/GL3.txt| 2 +- docs/relnotes/10.3.html | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c47a54b..8cfa247 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport DONE (nv50) + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index 5e29f2d..b65e347 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,7 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li -liGL_ARB_fragment_layer_viewport on nv50/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0/li /ul diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c index 667fbc8..ad8d1b0 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c @@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned ubase) switch (sn) { case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4; case TGSI_SEMANTIC_PRIMID: return 0x060; + case TGSI_SEMANTIC_LAYER:return 0x064; + case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068; case TGSI_SEMANTIC_PSIZE:return 0x06c; case TGSI_SEMANTIC_POSITION: return 0x070; case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10; diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 2c8f1ca..c02e10a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -164,6 +164,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TEXTURE_GATHER_SM5: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 1; case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return (class_3d = NVE4_3D_CLASS) ? 1 : 0; @@ -181,7 +182,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VS_LAYER: case PIPE_CAP_FAKE_SW_MSAA: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: - case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } Is that cap bit really required? Everybody who can do layered viewports ought to be able to do this (as it's required by d3d10). Though I can't say if right now all drivers which support layered viewports can already do it (llvmpipe can), but it might be trivial to fix those up which can't. (Of course that should have been layered fbs and multiple viewports, that short-notation I used there doesn't make much sense...) Well, I think right now the only drivers that support multiple viewports are llvmpipe, nv50, nvc0, and r600. I can test out llvmpipe but would need some help for r600. Would love not to have to add the cap :) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: (trivial) fix clamping of viewport index
LGTM. Jose From: srol...@vmware.com srol...@vmware.com Sent: 23 June 2014 21:08 To: Jose Fonseca; mesa-dev@lists.freedesktop.org; imir...@alum.mit.edu Cc: Roland Scheidegger; 10.1 10.2 Subject: [PATCH] draw: (trivial) fix clamping of viewport index From: Roland Scheidegger srol...@vmware.com The old logic would let all negative values go through unclamped, with potentially disastrous results (probably trying to fetch viewport values from random memory locations). GL has undefined rendering for vp indices outside valid range but that's a bit too undefined... (The logic is now the same as in llvmpipe.) CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/auxiliary/draw/draw_private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_private.h b/src/gallium/auxiliary/draw/draw_private.h index 783c3ef..d8dc2ab 100644 --- a/src/gallium/auxiliary/draw/draw_private.h +++ b/src/gallium/auxiliary/draw/draw_private.h @@ -493,7 +493,7 @@ draw_stats_clipper_primitives(struct draw_context *draw, static INLINE unsigned draw_clamp_viewport_idx(int idx) { - return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0); + return ((PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0); } /** -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] nv50/ir: make ARB_viewport_array behave like it does with other drivers
previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not tested on nv50 Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de --- V2: provide description fix naming of vars V3: spare a function call, use the idx we already have second arg to mkSymbol changed to 0, the other one was just wrong (double checked) .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 31 -- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h index c885c8c..002ac8f 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h @@ -177,6 +177,7 @@ struct nv50_ir_prog_info uint8_t vertexId; /* system value index of VertexID */ uint8_t edgeFlagIn; uint8_t edgeFlagOut; + int8_t viewportId; /* output index of ViewportId */ uint8_t fragDepth; /* output index of FragDepth */ uint8_t sampleMask;/* output index of SampleMask */ boolean sampleInterp; /* perform sample interp on all fp inputs */ diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index a0f1fe1..4911995 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -790,6 +790,8 @@ bool Source::scanSource() info-prop.gp.instanceCount = 1; // default value } + info-io.viewportId = -1; + info-immd.data = (uint32_t *)MALLOC(scan.immediate_count * 16); info-immd.type = (ubyte *)MALLOC(scan.immediate_count * sizeof(ubyte)); @@ -982,6 +984,9 @@ bool Source::scanDeclaration(const struct tgsi_full_declaration *decl) case TGSI_SEMANTIC_SAMPLEMASK: info-io.sampleMask = i; break; + case TGSI_SEMANTIC_VIEWPORT_INDEX: +info-io.viewportId = i; +break; default: break; } @@ -1258,6 +1263,8 @@ private: Stack joinBBs; // fork BB, for inserting join ops on ENDIF Stack loopBBs; // loop headers Stack breakBBs; // end of / after loop + + Value *viewport; }; Symbol * @@ -1555,8 +1562,16 @@ Converter::storeDst(const tgsi::Instruction::DstRegister dst, int c, mkOp2(OP_WRSV, TYPE_U32, NULL, dstToSym(dst, c), val); } else if (f == TGSI_FILE_OUTPUT prog-getType() != Program::TYPE_FRAGMENT) { - if (ptr || (info-out[idx].mask (1 c))) - mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + + if (ptr || (info-out[idx].mask (1 c))) { + /* Save the viewport index into a scratch register so that it can be +exported at EMIT time */ + if (info-out[idx].sn == TGSI_SEMANTIC_VIEWPORT_INDEX + viewport != NULL) +mkOp1(OP_MOV, TYPE_U32, viewport, val); + else +mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + } } else if (f == TGSI_FILE_TEMPORARY || f == TGSI_FILE_PREDICATE || @@ -2523,6 +2538,13 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c)); break; case TGSI_OPCODE_EMIT: + /* export the saved viewport index */ + if (viewport != NULL) { + Symbol *vpSym = mkSymbol(FILE_SHADER_OUTPUT, 0, TYPE_U32, + info-out[info-io.viewportId].slot[0] * 4); + mkStore(OP_EXPORT, TYPE_U32, vpSym, NULL, viewport); + } + /* fallthrough */ case TGSI_OPCODE_ENDPRIM: // get vertex stream if specified (must be immediate) src0 = tgsi.srcCount() ? @@ -2952,6 +2974,11 @@ Converter::run() mkOp1(OP_RCP, TYPE_F32, fragCoord[3], fragCoord[3]); } + if (info-io.viewportId = 0) + viewport = getScratch(); + else + viewport = NULL; + for (ip = 0; ip code-scan.num_instructions; ++ip) { if (!handleInstruction(code-insns[ip])) return false; -- 1.8.4.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] nv50/ir: make ARB_viewport_array behave like it does with other drivers
On Mon, Jun 23, 2014 at 5:01 PM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not tested on nv50 Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de Looks great! I'll test this out tonight on my nv50 and push it out if it works. I think I'll also CC it to 10.2. Thanks, -ilia --- V2: provide description fix naming of vars V3: spare a function call, use the idx we already have second arg to mkSymbol changed to 0, the other one was just wrong (double checked) .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 31 -- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h index c885c8c..002ac8f 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h @@ -177,6 +177,7 @@ struct nv50_ir_prog_info uint8_t vertexId; /* system value index of VertexID */ uint8_t edgeFlagIn; uint8_t edgeFlagOut; + int8_t viewportId; /* output index of ViewportId */ uint8_t fragDepth; /* output index of FragDepth */ uint8_t sampleMask;/* output index of SampleMask */ boolean sampleInterp; /* perform sample interp on all fp inputs */ diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index a0f1fe1..4911995 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -790,6 +790,8 @@ bool Source::scanSource() info-prop.gp.instanceCount = 1; // default value } + info-io.viewportId = -1; + info-immd.data = (uint32_t *)MALLOC(scan.immediate_count * 16); info-immd.type = (ubyte *)MALLOC(scan.immediate_count * sizeof(ubyte)); @@ -982,6 +984,9 @@ bool Source::scanDeclaration(const struct tgsi_full_declaration *decl) case TGSI_SEMANTIC_SAMPLEMASK: info-io.sampleMask = i; break; + case TGSI_SEMANTIC_VIEWPORT_INDEX: +info-io.viewportId = i; +break; default: break; } @@ -1258,6 +1263,8 @@ private: Stack joinBBs; // fork BB, for inserting join ops on ENDIF Stack loopBBs; // loop headers Stack breakBBs; // end of / after loop + + Value *viewport; }; Symbol * @@ -1555,8 +1562,16 @@ Converter::storeDst(const tgsi::Instruction::DstRegister dst, int c, mkOp2(OP_WRSV, TYPE_U32, NULL, dstToSym(dst, c), val); } else if (f == TGSI_FILE_OUTPUT prog-getType() != Program::TYPE_FRAGMENT) { - if (ptr || (info-out[idx].mask (1 c))) - mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + + if (ptr || (info-out[idx].mask (1 c))) { + /* Save the viewport index into a scratch register so that it can be +exported at EMIT time */ + if (info-out[idx].sn == TGSI_SEMANTIC_VIEWPORT_INDEX + viewport != NULL) +mkOp1(OP_MOV, TYPE_U32, viewport, val); + else +mkStore(OP_EXPORT, TYPE_U32, dstToSym(dst, c), ptr, val); + } } else if (f == TGSI_FILE_TEMPORARY || f == TGSI_FILE_PREDICATE || @@ -2523,6 +2538,13 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c)); break; case TGSI_OPCODE_EMIT: + /* export the saved viewport index */ + if (viewport != NULL) { + Symbol *vpSym = mkSymbol(FILE_SHADER_OUTPUT, 0, TYPE_U32, + info-out[info-io.viewportId].slot[0] * 4); + mkStore(OP_EXPORT, TYPE_U32, vpSym, NULL, viewport); + } + /* fallthrough */ case TGSI_OPCODE_ENDPRIM: // get vertex stream if specified (must be immediate) src0 = tgsi.srcCount() ? @@ -2952,6 +2974,11 @@ Converter::run() mkOp1(OP_RCP, TYPE_F32, fragCoord[3], fragCoord[3]); } + if (info-io.viewportId = 0) + viewport = getScratch(); + else + viewport = NULL; + for (ip = 0; ip code-scan.num_instructions; ++ip) { if (!handleInstruction(code-insns[ip])) return false; -- 1.8.4.5 ___ mesa-dev mailing list
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 23/06/14 21:21, Aaron Watry wrote: On Mon, Jun 23, 2014 at 1:54 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/06/14 19:31, Aaron Watry wrote: Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory to start, after make install of mesa I end up with /usr/local/lib/vdpau/ containing: awatry@ws-awatry:/usr/local/lib/vdpau$ ls -l total 26944 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1 - libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Jun 23 13:25 libvdpau_r600.so.1.0 - libvdpau_r600.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1 - libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Jun 23 13:25 libvdpau_radeonsi.so.1.0 - libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0 In case you're interested you can check the i-node for each file (ls -i) where both libvdpau*1.0.0 should link to the same one. Above files look good. I'm guessing that this is with the linked patch ? Yeah, that's with the patch. I just did an ls -i, and the files do indeed reference the same i-node. This matches with the previous check I had done before the patch (du -sk /usr/local/lib/vdpau roughly matched the size of one of the links, not the sum of both). Great, now all we need is for distros to package them properly preserving the hardlink :) Then I run ldconfig: awatry@ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig Rather silly question but why ? AFAIK the vdpau backend explicitly dlopened, thus you should not need ldconfig here. The first time that I discovered this was before I knew that libvdpau only checked it's compile-time prefix for back-end drivers. I had added /usr/local/lib/vdpau to /etc/ld.so.conf.d/vdpau.conf on my system in an attempt to add my vdpau libraries to the library path. It was a dead-end because of the hard-coded vdpau back-end paths, but the discovery that the link is getting created after install by the next ldconfig run was intriguing which is why I called it out. My system is set up with all distro-provided packages under /usr/lib/{arch}/, and all of my hand-compiled stuff under /usr/local/lib (64-bit only). My library path allows /usr/local/lib to override /usr/lib/{arch}, but only for packages that I've bothered to rebuild myself. At this point, that includes waffle, glamor, mesa, libclc, xf86-video-ati, and LLVM. It does NOT include libvdpau, as I had never known a reason to build that myself. Now, I'll either rely on my distro's vdpau-backend drivers, add libvdpau to the list of packages I'm building myself, or just symlink /usr/lib/x86_64-linux-gnu/vdpau to /usr/local/lib/vdpau. Makes sense, thanks for clarifying. AFAIK pretty much every library provided by mesa follows the rule - Is it installed in ${libdir} ? - No, dlopen only. - Yes, dlopen/link against it. -Emil --Aaron ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] i965/vec4: Don't return void from a void function.
Series is Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 06/23/2014 01:30 PM, Matt Turner wrote: --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 7fd8c2b..f3316f8 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -366,9 +366,9 @@ vec4_visitor::emit_math(opcode opcode, dst_reg dst, src_reg src) } if (brw-gen = 6) { - return emit_math1_gen6(opcode, dst, src); + emit_math1_gen6(opcode, dst, src); } else { - return emit_math1_gen4(opcode, dst, src); + emit_math1_gen4(opcode, dst, src); } } @@ -418,9 +418,9 @@ vec4_visitor::emit_math(enum opcode opcode, } if (brw-gen = 6) { - return emit_math2_gen6(opcode, dst, src0, src1); + emit_math2_gen6(opcode, dst, src0, src1); } else { - return emit_math2_gen4(opcode, dst, src0, src1); + emit_math2_gen4(opcode, dst, src0, src1); } } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: (trivial) fix clamping of viewport index
On Mon, Jun 23, 2014 at 4:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 4:08 PM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com The old logic would let all negative values go through unclamped, with potentially disastrous results (probably trying to fetch viewport values from random memory locations). GL has undefined rendering for vp indices outside valid range but that's a bit too undefined... (The logic is now the same as in llvmpipe.) CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org Reviewed-by: Ilia Mirkin imir...@alum.mit.edu I haven't tested whether this fixes my issues (don't have the right patches/setup on this comp) but this seems obviously correct. FTR, just tested it out, and it fixes the viewport case with ARB_fragment_layer_viewport. So you can add my Tested-by as well if you want. --- src/gallium/auxiliary/draw/draw_private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_private.h b/src/gallium/auxiliary/draw/draw_private.h index 783c3ef..d8dc2ab 100644 --- a/src/gallium/auxiliary/draw/draw_private.h +++ b/src/gallium/auxiliary/draw/draw_private.h @@ -493,7 +493,7 @@ draw_stats_clipper_primitives(struct draw_context *draw, static INLINE unsigned draw_clamp_viewport_idx(int idx) { - return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0); + return ((PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0); } /** -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] nvc0: enable ARB_fragment_layer_viewport
Well, with Roland's fix to the draw module, llvmpipe works with my tests as well. Is it likely that r600 will work as-is, or do you think it'll require some fixes? I can try to find someone with the requisite hw... On Mon, Jun 23, 2014 at 4:57 PM, Marek Olšák mar...@gmail.com wrote: The cap can be removed later if needed. Marek On Mon, Jun 23, 2014 at 2:50 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 7:55 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 12:49, schrieb Roland Scheidegger: Am 22.06.2014 17:10, schrieb Ilia Mirkin: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- docs/GL3.txt| 2 +- docs/relnotes/10.3.html | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c47a54b..8cfa247 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport DONE (nv50) + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index 5e29f2d..b65e347 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,7 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li -liGL_ARB_fragment_layer_viewport on nv50/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0/li /ul diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c index 667fbc8..ad8d1b0 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c @@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned ubase) switch (sn) { case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4; case TGSI_SEMANTIC_PRIMID: return 0x060; + case TGSI_SEMANTIC_LAYER:return 0x064; + case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068; case TGSI_SEMANTIC_PSIZE:return 0x06c; case TGSI_SEMANTIC_POSITION: return 0x070; case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10; diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 2c8f1ca..c02e10a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -164,6 +164,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TEXTURE_GATHER_SM5: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 1; case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return (class_3d = NVE4_3D_CLASS) ? 1 : 0; @@ -181,7 +182,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VS_LAYER: case PIPE_CAP_FAKE_SW_MSAA: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: - case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } Is that cap bit really required? Everybody who can do layered viewports ought to be able to do this (as it's required by d3d10). Though I can't say if right now all drivers which support layered viewports can already do it (llvmpipe can), but it might be trivial to fix those up which can't. (Of course that should have been layered fbs and multiple viewports, that short-notation I used there doesn't make much sense...) Well, I think right now the only drivers that support multiple viewports are llvmpipe, nv50, nvc0, and r600. I can test out llvmpipe but would need some help for r600. Would love not to have to add the cap :) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Don't use derived vertex state in api_arrayelt.c
Brian Paul brian.e.p...@gmail.com writes: On Friday 28 February 2014, Fredrik Höglund wrote: It's possible that this patch fixes a segfault in FlightGear (see bug 73504), so I think it's a candidate for the 10.1 branch, but maybe not for 10.1.0. Ping? I took a look. I guess we don't have much (any?) test coverage of glArrayElement(). The patch looks good AFAICT. Reviewed-by: Brian Paul bri...@vmware.com This patch has been sitting on my queue for 10.1 since it was first nominated. But I've never seen it committed to the master branch. Did I miss anything or was this patch just missed somewhere? -Carl -- carl.d.wo...@intel.com pgpS4nhLUFFML.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] Fix gl_VertexID on i965
On 06/21/2014 06:59 PM, Marek Olšák wrote: That's right. A uniform won't work with ARB_draw_indirect unless you lower it to direct draws, which would be very bad if it was applied to all drivers. Radeonsi indeed supports BaseVertex and BaseInstance as system values in the vertex shader. Well, vertex fetching has to be done in the vertex shader on that hardware, so the system values are kinda required there. You have to opt-in to the lowering pass. The only lowering that is currently implemented is the lowering to a uniform, but lowering to system value should be trivial. It would just need the enum passed in and use it to select between creating gl_BaseVertex as a uniform or a system value based on that. Marek On Sun, Jun 22, 2014 at 12:27 AM, Chris Forbes chr...@ijw.co.nz wrote: This will be broken for indirect draws too, and possibly Good point... I've just sent out an additional test for this case. It does glDrawArraysIndirect and glDrawElementsIndirect. I haven't done the Multi versions. performance-crippling to fix there, since we don't have the baseVertex value available to shove into a uniform. On Sun, Jun 22, 2014 at 3:36 AM, Roland Scheidegger srol...@vmware.com wrote: Am 21.06.2014 03:00, schrieb Ian Romanick: This patch series fixes bugs in the i965 w.r.t. several uses of gl_VertexID. OpenGL (desktop and ES) have the following expectations of gl_VertexID: 1. When used with BaseVertex drawing commands, gl_VertexID will include the value of basevertex. This differens from the other API, but the change in OpenGL was based on feedback from application developers. This only affects OpenGL 3.2+. I don't question this, but note some binary drivers may not agree. There are unforunately lots of man pages around of glDrawElementsInstancedBaseVertexBaseInstance too which state: The basevertex has no effect on the shader-visible value of gl_VertexID. There's a bug filed about this (https://www.khronos.org/bugzilla/show_bug.cgi?id=932) which is still open though maybe it has all been resolved... (I'll just mention that llvmpipe right now will do d3d10-style vertexID though I guess indeed at some point we need to make it either switchable or implement GL_ARB_shader_draw_parameters so it can be worked around easily in the state tracker.) Roland 2. When used with DrawArrays drawing commands, gl_VertexID will count from the 'start' value instead of zero. This affects OpenGL 3.0+ and OpenGL ES 3.0+. The i965 driver botched both of these for slightly different reasons. For #1, our hardware was designed with the other API's semantic in mind, so gl_VertexID doesn't include the basevertex value. For #2, we implement DrawArrays with a non-zero start index by reprogramming the array base offset. As a result, gl_VertexID always counts from zero. I suspect other hardware may suffer from one or both of these issues. I have sent tests to the piglit list to reproduce them. To fix both of these issues, the shader needs to know the basevertex value. A later GL extension, GL_ARB_shader_draw_parameters, adds gl_BaseVertex and gl_BaseInstance as built-in variables. I believe some hardware implements these as system values much like gl_VertexID. I started this series with the assumption that we could have a SYSTEM_VALUE_BASE_VERTEX that might come from a uniform. In the end, I couldn't make that work. I left patch 7 in the series, but we may want to remove it. I added a STATE_BASE_VERTEX uniform instead. There is now a lowering pass that converts gl_VertexID to gl_VertexIDMESA + gl_BaseVertex (backed by a uniform). Some of these names should probably be changed. I have also contemplated adding an extension that exposes the other semantic for gl_VertexID for applications that actually want that. This is primarily things that are porting content (or bridging content) from the other API. That, however, can happen later. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/15] glsl: Do not allow undefining the built-in macros
Anuj Phogat anuj.pho...@gmail.com writes: Fixes piglit tests in spec/glsl-es-3.00/compile: ... Cc: mesa-sta...@lists.freedesktop.org For this change, (and other similar changes in the series, as well as subsequent pre-processor changes that I am writing), I'm deciding to generally not pick these over to the stable branch. For one, my series is getting fairly long (21 patches and counting) and would add quite a lot of clutter to the stable branch. More importantly, though, these changes all improve conformance (as measured by a very picky test suite), most of them don't actually fix bugs. That is, they don't make mesa start accepting valid GLSL programs that were previously being rejected. Instead, some make mesa more correct to generate errors in case an application does something pointless and bizarre, like: #undef __LINE__ Some of the patches do make mesa start accepting valid programs, but they are in cases where the program would have to do something bizarre and pointless such as: # /* Hah-ha! */ define FOO bar I just don't see anything like that coming up in the wild, (outside of stress-testing in test suites). So, these are all good improvements to mesa, but not important for the stable branch. -Carl -- carl.d.wo...@intel.com pgpwel1ie7Bps.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] Fix zero-division in llvmpipe_texture_layout()
Roland Scheidegger srol...@vmware.com writes: Am 07.06.2014 20:38, schrieb Johannes Obermayr: From: Takashi Iwai ti...@suse.de Fix the crash of gnome-control-center info invocation on QEMU where zero height is passed at init. ... Cc: 10.2 mesa-sta...@lists.freedesktop.org ... Reviewed-by: Roland Scheidegger srol...@vmware.com Johannes, Roland, Presumably Takashi doesn't have access to push changes to mesa? Do either of you feel comfortable pushing this patch? I don't want code to be neglected and forgotten on the list here. -Carl -- carl.d.wo...@intel.com pgp7cY3kzZvBg.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Don't emit SURFACE_STATEs for gather workarounds on Broadwell.
It did not. But, I just ran all of those tests with and without this patch, and there were no regressions. So, I think we're good. Pushed - thanks for the review! On Thursday, May 29, 2014 07:32:21 PM Chris Forbes wrote: Did this test run include forcing ARB_gpu_shader5 on? On Thu, May 29, 2014 at 7:06 PM, Kenneth Graunke kenn...@whitecape.org wrote: As far as I can tell, Broadwell doesn't need any of the SURFACE_STATE workarounds for textureGather() bugs, so there's no need to emit a second set of identical copies. To keep things simple, just point the gather surface index base to the same place as the texture surface index base. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/dri/i965/brw_shader.cpp | 9 +++-- src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 14 -- 2 files changed, 15 insertions(+), 8 deletions(-) No Piglit regressions on Broadwell with -t texture. diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp b/src/mesa/drivers/dri/i965/brw_shader.cpp index f4f1334..7fae416 100644 --- a/src/mesa/drivers/dri/i965/brw_shader.cpp +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp @@ -740,8 +740,13 @@ backend_visitor::assign_common_binding_table_offsets(uint32_t next_binding_table } if (prog-UsesGather) { - stage_prog_data-binding_table.gather_texture_start = next_binding_table_offset; - next_binding_table_offset += num_textures; + if (brw-gen = 8) { + stage_prog_data-binding_table.gather_texture_start = +stage_prog_data-binding_table.texture_start; + } else { + stage_prog_data-binding_table.gather_texture_start = next_binding_table_offset; + next_binding_table_offset += num_textures; + } } else { stage_prog_data-binding_table.gather_texture_start = 0xd0d0d0d0; } 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 c9d9614..3279d3b 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -829,12 +829,14 @@ brw_update_texture_surfaces(struct brw_context *brw) /* emit alternate set of surface state for gather. this * allows the surface format to be overriden for only the * gather4 messages. */ - if (vs vs-UsesGather) - update_stage_texture_surfaces(brw, vs, brw-vs.base, true); - if (gs gs-UsesGather) - update_stage_texture_surfaces(brw, gs, brw-gs.base, true); - if (fs fs-UsesGather) - update_stage_texture_surfaces(brw, fs, brw-wm.base, true); + if (brw-gen 8) { + if (vs vs-UsesGather) + update_stage_texture_surfaces(brw, vs, brw-vs.base, true); + if (gs gs-UsesGather) + update_stage_texture_surfaces(brw, gs, brw-gs.base, true); + if (fs fs-UsesGather) + update_stage_texture_surfaces(brw, fs, brw-wm.base, true); + } brw-state.dirty.brw |= BRW_NEW_SURFACES; } -- 1.9.1 ___ mesa-stable mailing list mesa-sta...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-stable signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/4] nvc0/ir: clear subop when folding constant expressions
Tobias Klausmann tobias.johannes.klausm...@mni.thm.de writes: Some operations (e.g. OP_MUL/OP_MAD/OP_EXTBF might have a subop set. After folding, make sure that it is cleared Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org Hi Tobias and Ilia, This patch isn't picking cleanly over to the 10.1 branch. Can you give me some guidance here? Either of the following replies would be great: Don't worry about this for 10.1 because... Here's a backported patch for 10.1... Thanks! -Carl -- carl.d.wo...@intel.com pgpcC36ssxo25.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] android, egl: typo dri2_fallback_pixmap_surface - dri2_fallback_create_pixmap_surface
Adrian Negreanu gro...@gmail.com writes: I used commit bc8b07a6 as reference, and only the droid_display_vtbl had this issue. ... CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org - .create_pixmap_surface = dri2_fallback_pixmap_surface, + .create_pixmap_surface = dri2_fallback_create_pixmap_surface, This patch isn't picking cleanly to the 10.1 branch. And the grepping I did in 10.1 didn't find either of these function names, (neither dri2_fallback_pixmap_surface nor dri2_fallback_create_pixmap_surface). Adrian, can you confirm whether this patch is needed for 10.1? I've picked over all of your other nominated android patches, and I'm a little nervous to botch things here, (since I won't be testing an android build). I have pushed out my cherry-picked changes to the 10.1 branch so that you can test them if you would like. -Carl -- carl.d.wo...@intel.com pgpJYYXe_C5M4.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] radeon/uvd: disable VC-1 simple/main on UVD 2.x
Grigori Goronzy g...@chown.ath.cx writes: It's about as broken as on later UVD revisions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66452 Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org This patch isn't picking over cleanly to 10.1. I didn't investigate what happened (a file rename?) so perhaps the backport is actually trivial. Would someone interested in the patch care to backport this? -Carl -- carl.d.wo...@intel.com pgpg5kZIS4Jrt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/4] nvc0/ir: clear subop when folding constant expressions
On Mon, Jun 23, 2014 at 7:25 PM, Carl Worth cwo...@cworth.org wrote: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de writes: Some operations (e.g. OP_MUL/OP_MAD/OP_EXTBF might have a subop set. After folding, make sure that it is cleared Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org Hi Tobias and Ilia, This patch isn't picking cleanly over to the 10.1 branch. Can you give me some guidance here? Either of the following replies would be great: Don't worry about this for 10.1 because... Here's a backported patch for 10.1... Here's a backported patch for 10.1... -ilia From db30c022ff9e83e8bf42177642af8663d26c0cac Mon Sep 17 00:00:00 2001 From: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de Date: Wed, 4 Jun 2014 00:35:47 +0200 Subject: [PATCH] nv50/ir: clear subop when folding constant expressions Some operations (e.g. OP_MUL/OP_MAD/OP_EXTBF) might have a subop set. After folding, make sure that it is cleared Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp index 1ea278b..fde5616 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp @@ -535,6 +535,7 @@ ConstantFolding::expr(Instruction *i, } else { i-op = OP_MOV; } + i-subOp = 0; } void -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Candidate branches for 10.2.2 and 10.1.6
Hi folks, I'm nearly done preparing the 10.1 and 10.2 branches for the next stable releases, (which will also be the final release on the 10.1 branch). The status of my 10.2 branch can be examined here: http://cworth.org/~cworth/mesa-stable-queue/ I'm pretty happy with what it looks like. There are about 41 new patches on the 10.2 branch. (A few of these aren't shown in the above report only because I couldn't find that they ever went by on the mesa-dev mailing list). Meanwhile, there's a fairly long list of nominated, awaiting review patches. I would normally be fairly concerned about that, but the majority are very recent, (last 5 days or so), so I expect that these will get reviewed and committed to master soon, (and be ready for the 10.2.3 release in a couple of weeks). But take a look at the report above, and if your favorite patches don't appear queued up, do something about it! I've pushed out most all of the queued patches to the upstream 10.1 and 10.2 branches so that anyone can test them. Feedback is always appreciated. I plan to release both of these branches tomorrow. Thanks all, for your patience with your stable-release manager. -Carl -- carl.d.wo...@intel.com pgpmCR2OGuiF_.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Candidate branches for 10.2.2 and 10.1.6
Hi folks, I'm nearly done preparing the 10.1 and 10.2 branches for the next stable releases, (which will also be the final release on the 10.1 branch). The status of my 10.2 branch can be examined here: http://cworth.org/~cworth/mesa-stable-queue/ I'm pretty happy with what it looks like. There are about 41 new patches on the 10.2 branch. (A few of these aren't shown in the above report only because I couldn't find that they ever went by on the mesa-dev mailing list). Meanwhile, there's a fairly long list of nominated, awaiting review patches. I would normally be fairly concerned about that, but the majority are very recent, (last 5 days or so), so I expect that these will get reviewed and committed to master soon, (and be ready for the 10.2.3 release in a couple of weeks). But take a look at the report above, and if your favorite patches don't appear queued up, do something about it! As for 10.1, I don't have a fancy web report, but I've applied all nominated patches except for three that didn't apply cleanly, and for which I recently emailed authors/reviewers asking for backports. Here are those three patches: 3164bfc73418e2e046c7 nv50/ir: clear subop when folding constant expressions 6980cae6aeb6671b6b02 android, egl: typo dri2_fallback_pixmap_surface - dri2_fallback_create_pixmap_surface 6cd30f5d730c3c23251a radeon/uvd: disable VC-1 simple/main on UVD 2.x I've pushed out most all of the queued patches to the upstream 10.1 and 10.2 branches so that anyone can test them. Feedback is always appreciated. I plan to release both of these branches tomorrow. Thanks all, for your patience with your stable-release manager. -Carl -- carl.d.wo...@intel.com pgpx_RrmpFm0n.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Allow the blorp blit between BGR and RGB
On Monday, June 23, 2014 07:02:59 PM Neil Roberts wrote: Previously the blorp blitter would only be used if the format is identical or there is only a difference between whether there is an alpha component or not. This patch makes it also allow the blorp blitter if the only difference is the ordering of the RGB components (ie, RGB or BGR). This is particularly useful since commit 61e264f4fcdba3623 because Mesa now prefers RGB ordering for textures but the window system buffers are still created as BGR. That means that the blorp blitter won't be used for the (probably) common case of blitting from a texture to the window system buffer. This doesn't cause any regressions in the FBO piglit tests on Haswell. On Sandybridge it causes the fbo-blit-stretch test to fail but that is only because it was failing anyway before the above commit and that commit hid the problem. https://bugs.freedesktop.org/show_bug.cgi?id=68365 FWIW, I relaxed the format restrictions in brw_blorp_copytexsubimage, so it can handle general format conversions as well (i.e. RGBA_FLOAT16 - RGBA_UNORM). There's no reason we couldn't do that for BlitFramebuffer as well, I just forgot to do it (and then we decided to make it a newbie task, and then the newbie didn't do said task, and...oops.) A couple of games do BlitFramebuffer with format conversions, IIRC. I think DOTA 2 does 1010102 - blits. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] android, egl: typo dri2_fallback_pixmap_surface - dri2_fallback_create_pixmap_surface
On 24/06/14 00:31, Carl Worth wrote: Adrian Negreanu gro...@gmail.com writes: I used commit bc8b07a6 as reference, and only the droid_display_vtbl had this issue. ... CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org Believe that I'm the one to blame for adding the stable tag on the series. - .create_pixmap_surface = dri2_fallback_pixmap_surface, + .create_pixmap_surface = dri2_fallback_create_pixmap_surface, This patch isn't picking cleanly to the 10.1 branch. And the grepping I did in 10.1 didn't find either of these function names, (neither dri2_fallback_pixmap_surface nor dri2_fallback_create_pixmap_surface). Adrian, can you confirm whether this patch is needed for 10.1? Indeed the Chad's eglGetPlatformDisplay work went in with mesa 10.2 so I believe that this patch can be dropped. Pardon for that :) -Emil I've picked over all of your other nominated android patches, and I'm a little nervous to botch things here, (since I won't be testing an android build). I have pushed out my cherry-picked changes to the 10.1 branch so that you can test them if you would like. -Carl ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] how to enable the display on wayland
Hi all, Recently, I've tried to enable my opengles application run on tizen-ivi, tizen-ivi use wayland to display, how to enable the opengles part show on it? My latest patch crashed again, the following sequences describe what I do on for the opengles parts: 1. wl_display_connect(NULL) à return a global g_nativeDisplay object, I see someone do it, so that I do it. 2. wl_display_get_registry, wl_registry_add_listener, wl_display_dispatch - some APIs I'm not familiar, I see someone do it, so that I do it. 3. wl_egl_window_create(NULL,1280,720) à return a nativeWindow object which will be passed for EGL to Create Window Surface, I believe that the NULL(wl_surface*) parameter lead to the crash. But I have no idea how to get a wl_surface object. 4. eglGetDisplay, eglInitialize, eglChooseConfig, eglCreateContext, eglCreateWindowSurface, eglMakeCurrent, eglQuerySurface, these APIs all work fine, return no error. 5. eglSwapBuffers, lead to the crash, trace the bt, I find that it is because wl_surface is NULL, (gdb) bt #0 0xb7e35a85 in wl_proxy_create () from /lib/libwayland-client.so.0 #1 0xb7e1ac10 in wl_surface_frame (wl_surface=0x0) at /home/jacky/Apps/Wayland/include/wayland-client-protocol.h:1355 #2 0xb7e1bfbb in dri2_wl_swap_buffers_with_damage (drv=0x8730f88, disp=0x8730300, draw=0x87cc380, rects=0x0, n_rects=0) at platform_wayland.c:617 #3 0xb7e1c309 in dri2_wl_swap_buffers (drv=0x8730f88, disp=0x8730300, draw=0x87cc380) at platform_wayland.c:702 #4 0xb7e19739 in dri2_swap_buffers (drv=0x8730f88, dpy=0x8730300, surf=0x87cc380) at egl_dri2.c:1074 #5 0xb7e0cd03 in eglSwapBuffers (dpy=0x8730300, surface=0x87cc380) at eglapi.c:811 I searched the internet but get less useful information, even now , I plan to make some fake data to initialize the wl_surface, but I have not got the definition for the struct wl_surface, just a url(http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_surface.html ) describe how to use its function, no initialize function... It is so different from X11 who only need to prepare a window passed to EGL, So far, I've learned I need prepare a wl_egl_window and a wl_surface for EGL on wayland, wl_egl_window need three parameters wl_surface, width and height to create,but wl_surface seems need compositor(API:wl_compositor_create_surface )to create, so compositor need what to create? May I need to create a compositor firstly? Could someone help me lists how to use the wayland's API and EGL's wayland API to enable the display on wayland? Best Regards, Jacky Ni CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965/vec4: Don't fix_math_operand() on Gen = 8.
On Mon, Jun 23, 2014 at 01:30:14PM -0700, Matt Turner wrote: The emit_math?_gen? functions serve to implement workarounds for the math instruction, none of which exist on Gen8+. There are still several restrictions with the math instruction on gen8. Looking at the existing code, I realize I do not quite see even all the gen7 restrictions, so I am not qualified to determine if you accounted for gen8. In particular, stride of src, and dest must be the same, and Regioning must ensure Src.Vstride = Src.Width * Src.Hstride The rest of the series is: Reviewed-by: Ben Widawsky b...@bwidawsk.net If you can convince me these cases are solid here, this one is also r-b Thanks. (sorry for my ignorance) --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index f3316f8..3a360d4 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -365,7 +365,9 @@ vec4_visitor::emit_math(opcode opcode, dst_reg dst, src_reg src) return; } - if (brw-gen = 6) { + if (brw-gen = 8) { + emit(opcode, dst, src); + } else if (brw-gen = 6) { emit_math1_gen6(opcode, dst, src); } else { emit_math1_gen4(opcode, dst, src); @@ -417,7 +419,9 @@ vec4_visitor::emit_math(enum opcode opcode, return; } - if (brw-gen = 6) { + if (brw-gen = 8) { + emit(opcode, dst, src0, src1); + } else if (brw-gen = 6) { emit_math2_gen6(opcode, dst, src0, src1); } else { emit_math2_gen4(opcode, dst, src0, src1); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Ben Widawsky, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/14] ir_to_mesa, glsl_to_tgsi: Add support for ir_unop_saturate
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/program/ir_to_mesa.cpp| 6 ++ src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 ++ 2 files changed, 12 insertions(+) diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp index 17ccb64..4f32b7d 100644 --- a/src/mesa/program/ir_to_mesa.cpp +++ b/src/mesa/program/ir_to_mesa.cpp @@ -1177,6 +1177,12 @@ ir_to_mesa_visitor::visit(ir_expression *ir) emit(ir, OPCODE_DDY, result_dst, op[0]); break; + case ir_unop_saturate: { + ir_to_mesa_instruction *inst = emit(ir, OPCODE_MOV, + result_dst, op[0]); + inst-saturate = true; + break; + } case ir_unop_noise: { const enum prog_opcode opcode = prog_opcode(OPCODE_NOISE1 diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index a4dd18a..5381abd 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -1466,6 +1466,12 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir) case ir_unop_cos_reduced: emit_scs(ir, TGSI_OPCODE_COS, result_dst, op[0]); break; + case ir_unop_saturate: { + glsl_to_tgsi_instruction *inst; + inst = emit(ir, TGSI_OPCODE_MOV, result_dst, op[0]); + inst-saturate = true; + break; + } case ir_unop_dFdx: emit(ir, TGSI_OPCODE_DDX, result_dst, op[0]); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/14] i965/fs: Remove try_emit_saturate
Now that sature is implemented natively as instruction, we can cut down on uneeded functionality. Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_fs.h | 1 - src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 37 2 files changed, 38 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.h b/src/mesa/drivers/dri/i965/brw_fs.h index cda344e..ef0576e 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.h +++ b/src/mesa/drivers/dri/i965/brw_fs.h @@ -424,7 +424,6 @@ public: const fs_reg a); void emit_minmax(uint32_t conditionalmod, const fs_reg dst, const fs_reg src0, const fs_reg src1); - bool try_emit_saturate(ir_expression *ir); bool try_emit_mad(ir_expression *ir); void try_replace_with_sel(); bool opt_peephole_sel(); diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 106eea6..445010f 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -261,41 +261,6 @@ fs_visitor::emit_minmax(uint32_t conditionalmod, const fs_reg dst, } } -/* Instruction selection: Produce a MOV.sat instead of - * MIN(MAX(val, 0), 1) when possible. - */ -bool -fs_visitor::try_emit_saturate(ir_expression *ir) -{ - ir_rvalue *sat_val = ir-as_rvalue_to_saturate(); - - if (!sat_val) - return false; - - fs_inst *pre_inst = (fs_inst *) this-instructions.get_tail(); - - sat_val-accept(this); - fs_reg src = this-result; - - fs_inst *last_inst = (fs_inst *) this-instructions.get_tail(); - - /* If the last instruction from our accept() didn't generate our -* src, generate a saturated MOV -*/ - fs_inst *modify = get_instruction_generating_reg(pre_inst, last_inst, src); - if (!modify || modify-regs_written != 1) { - this-result = fs_reg(this, ir-type); - fs_inst *inst = emit(MOV(this-result, src)); - inst-saturate = true; - } else { - modify-saturate = true; - this-result = src; - } - - - return true; -} - bool fs_visitor::try_emit_mad(ir_expression *ir) { @@ -347,8 +312,6 @@ fs_visitor::visit(ir_expression *ir) assert(ir-get_num_operands() = 3); - if (try_emit_saturate(ir)) - return; if (ir-operation == ir_binop_add) { if (try_emit_mad(ir)) return; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Don't use derived vertex state in api_arrayelt.c
On Tuesday 24 June 2014, Carl Worth wrote: Brian Paul brian.e.p...@gmail.com writes: On Friday 28 February 2014, Fredrik Höglund wrote: It's possible that this patch fixes a segfault in FlightGear (see bug 73504), so I think it's a candidate for the 10.1 branch, but maybe not for 10.1.0. Ping? I took a look. I guess we don't have much (any?) test coverage of glArrayElement(). The patch looks good AFAICT. Reviewed-by: Brian Paul bri...@vmware.com This patch has been sitting on my queue for 10.1 since it was first nominated. But I've never seen it committed to the master branch. Did I miss anything or was this patch just missed somewhere? It was, thanks for the reminder :) I've pushed it to the master branch now. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/14] i965/vec4: Remove try_emit_saturate
Now that sature is implemented natively as an instruction, we can cut down on uneeded functionality. Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_vec4.h | 1 - src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 21 - 2 files changed, 22 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h b/src/mesa/drivers/dri/i965/brw_vec4.h index c2bbd68..5e9d735 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.h +++ b/src/mesa/drivers/dri/i965/brw_vec4.h @@ -585,7 +585,6 @@ public: src_reg orig_src, int base_offset); - bool try_emit_sat(ir_expression *ir); bool try_emit_mad(ir_expression *ir); void resolve_ud_negate(src_reg *reg); diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 2112edf..b08fd87 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -1072,24 +1072,6 @@ vec4_visitor::visit(ir_function *ir) } bool -vec4_visitor::try_emit_sat(ir_expression *ir) -{ - ir_rvalue *sat_src = ir-as_rvalue_to_saturate(); - if (!sat_src) - return false; - - sat_src-accept(this); - src_reg src = this-result; - - this-result = src_reg(this, ir-type); - vec4_instruction *inst; - inst = emit(MOV(dst_reg(this-result), src)); - inst-saturate = true; - - return true; -} - -bool vec4_visitor::try_emit_mad(ir_expression *ir) { /* 3-src instructions were introduced in gen6. */ @@ -1194,9 +1176,6 @@ vec4_visitor::visit(ir_expression *ir) dst_reg result_dst; vec4_instruction *inst; - if (try_emit_sat(ir)) - return; - if (ir-operation == ir_binop_add) { if (try_emit_mad(ir)) return; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/14] i965/fs: Add support for ir_unop_saturate
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 + src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 2 files changed, 5 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp b/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp index ae5bc56..588c289 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp @@ -220,6 +220,7 @@ ir_channel_expressions_visitor::visit_leave(ir_assignment *ir) case ir_unop_bit_count: case ir_unop_find_msb: case ir_unop_find_lsb: + case ir_unop_saturate: for (i = 0; i vector_elements; i++) { ir_rvalue *op0 = get_element(op_var[0], i); diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 8858852..106eea6 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -705,6 +705,10 @@ fs_visitor::visit(ir_expression *ir) case ir_unop_find_lsb: emit(FBL(this-result, op[0])); break; + case ir_unop_saturate: + inst = emit(MOV(this-result, op[0])); + inst-saturate = true; + break; case ir_triop_bitfield_extract: /* Note that the instruction's argument order is reversed from GLSL * and the IR. -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/14] ir_to_mesa, glsl_to_tgsi: Remove try_emit_saturate
Now that sature is implemented natively as instruction, we can cut down on uneeded functionality Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/program/ir_to_mesa.cpp| 48 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 51 -- 2 files changed, 99 deletions(-) diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp index 4f32b7d..96dcd14 100644 --- a/src/mesa/program/ir_to_mesa.cpp +++ b/src/mesa/program/ir_to_mesa.cpp @@ -311,7 +311,6 @@ public: int mul_operand); bool try_emit_mad_for_and_not(ir_expression *ir, int mul_operand); - bool try_emit_sat(ir_expression *ir); void emit_swz(ir_expression *ir); @@ -872,50 +871,6 @@ ir_to_mesa_visitor::try_emit_mad_for_and_not(ir_expression *ir, int try_operand) return true; } -bool -ir_to_mesa_visitor::try_emit_sat(ir_expression *ir) -{ - /* Saturates were only introduced to vertex programs in -* NV_vertex_program3, so don't give them to drivers in the VP. -*/ - if (this-prog-Target == GL_VERTEX_PROGRAM_ARB) - return false; - - ir_rvalue *sat_src = ir-as_rvalue_to_saturate(); - if (!sat_src) - return false; - - sat_src-accept(this); - src_reg src = this-result; - - /* If we generated an expression instruction into a temporary in -* processing the saturate's operand, apply the saturate to that -* instruction. Otherwise, generate a MOV to do the saturate. -* -* Note that we have to be careful to only do this optimization if -* the instruction in question was what generated src-result. For -* example, ir_dereference_array might generate a MUL instruction -* to create the reladdr, and return us a src reg using that -* reladdr. That MUL result is not the value we're trying to -* saturate. -*/ - ir_expression *sat_src_expr = sat_src-as_expression(); - ir_to_mesa_instruction *new_inst; - new_inst = (ir_to_mesa_instruction *)this-instructions.get_tail(); - if (sat_src_expr (sat_src_expr-operation == ir_binop_mul || - sat_src_expr-operation == ir_binop_add || - sat_src_expr-operation == ir_binop_dot)) { - new_inst-saturate = true; - } else { - this-result = get_temp(ir-type); - ir_to_mesa_instruction *inst; - inst = emit(ir, OPCODE_MOV, dst_reg(this-result), src); - inst-saturate = true; - } - - return true; -} - void ir_to_mesa_visitor::reladdr_to_temp(ir_instruction *ir, src_reg *reg, int *num_reladdr) @@ -1078,9 +1033,6 @@ ir_to_mesa_visitor::visit(ir_expression *ir) return; } - if (try_emit_sat(ir)) - return; - if (ir-operation == ir_quadop_vector) { this-emit_swz(ir); return; diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 5381abd..886e304 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -445,7 +445,6 @@ public: int mul_operand); bool try_emit_mad_for_and_not(ir_expression *ir, int mul_operand); - bool try_emit_sat(ir_expression *ir); void emit_swz(ir_expression *ir); @@ -1276,53 +1275,6 @@ glsl_to_tgsi_visitor::try_emit_mad_for_and_not(ir_expression *ir, int try_operan return true; } -bool -glsl_to_tgsi_visitor::try_emit_sat(ir_expression *ir) -{ - /* Emit saturates in the vertex shader only if SM 3.0 is supported. -*/ - if (this-prog-Target == GL_VERTEX_PROGRAM_ARB - !st_context(this-ctx)-has_shader_model3) { - return false; - } - - ir_rvalue *sat_src = ir-as_rvalue_to_saturate(); - if (!sat_src) - return false; - - sat_src-accept(this); - st_src_reg src = this-result; - - /* If we generated an expression instruction into a temporary in -* processing the saturate's operand, apply the saturate to that -* instruction. Otherwise, generate a MOV to do the saturate. -* -* Note that we have to be careful to only do this optimization if -* the instruction in question was what generated src-result. For -* example, ir_dereference_array might generate a MUL instruction -* to create the reladdr, and return us a src reg using that -* reladdr. That MUL result is not the value we're trying to -* saturate. -*/ - ir_expression *sat_src_expr = sat_src-as_expression(); - if (sat_src_expr (sat_src_expr-operation == ir_binop_mul || - sat_src_expr-operation == ir_binop_add || - sat_src_expr-operation == ir_binop_dot)) { - glsl_to_tgsi_instruction *new_inst; - new_inst = (glsl_to_tgsi_instruction *)this-instructions.get_tail(); - new_inst-saturate = true; - } else { - this-result = get_temp(ir-type); - st_dst_reg result_dst =
[Mesa-dev] Add support for GLSL IR saturate()
This patch series add the plumbing to support the GLSL IR instruction saturate(). Previously, saturate is implemented as min/max instructions. Most GPUs, however, can probably perform saturate for free. With these changes, we can allow saturate to be optimized as a single instruction. In addition, the optimization try_emit_saturate was previously used to optimize min/max operations to a saturate operation. It didn't work for code such as min(max(a, b), c) where (b == 0.0 and c 1.0) and related cases. With this infrastructure in place, we can optimize those operations easily in the do_algebraic pass. This is done in the next patch set. Abdiel Janulgue (11): glsl: Add ir_unop_saturate glsl: Add constant evaluation of ir_unop_saturate glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1) ir_to_mesa, glsl_to_tgsi: lower ir_unop_saturate ir_to_mesa, glsl_to_tgsi: Add support for ir_unop_saturate ir_to_mesa, glsl_to_tgsi: Remove try_emit_saturate i965/fs: Add support for ir_unop_saturate i965/vec4: Add support for ir_unop_saturate i965/fs: Remove try_emit_saturate i965/vec4: Remove try_emit_saturate glsl: Implement saturate as ir_binop_saturate src/glsl/ir.cpp | 2 + src/glsl/ir.h| 1 + src/glsl/ir_builder.cpp | 6 +-- src/glsl/ir_constant_expression.cpp | 6 +++ src/glsl/ir_optimization.h | 1 + src/glsl/ir_validate.cpp | 1 + src/glsl/lower_instructions.cpp | 29 src/mesa/drivers/dri/i965/brw_fs.h | 1 - src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 + src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 41 ++--- src/mesa/drivers/dri/i965/brw_vec4.h | 1 - src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 25 ++ src/mesa/program/ir_to_mesa.cpp | 59 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 63 +- 14 files changed, 71 insertions(+), 166 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/14] glsl: Implement saturate as ir_binop_saturate
Now that we have the ir_binop_saturate implemented as a single instruction, generate the correct simplified expression. Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/glsl/ir_builder.cpp | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/glsl/ir_builder.cpp b/src/glsl/ir_builder.cpp index f4a1c6e..92d799c 100644 --- a/src/glsl/ir_builder.cpp +++ b/src/glsl/ir_builder.cpp @@ -271,11 +271,7 @@ clamp(operand a, operand b, operand c) ir_expression * saturate(operand a) { - void *mem_ctx = ralloc_parent(a.val); - - return expr(ir_binop_max, - expr(ir_binop_min, a, new(mem_ctx) ir_constant(1.0f)), - new(mem_ctx) ir_constant(0.0f)); + return expr(ir_unop_saturate, a); } ir_expression * -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/14] glsl: Add constant evaluation of ir_unop_saturate
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/glsl/ir_constant_expression.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/glsl/ir_constant_expression.cpp b/src/glsl/ir_constant_expression.cpp index 8afe8f7..b885a2f 100644 --- a/src/glsl/ir_constant_expression.cpp +++ b/src/glsl/ir_constant_expression.cpp @@ -1464,6 +1464,12 @@ ir_expression::constant_expression_value(struct hash_table *variable_context) } break; + case ir_unop_saturate: + for (unsigned c = 0; c components; c++) { + data.f[c] = MIN2(MAX2(op[0]-value.f[c], 0.0f), 1.0f); + } + break; + case ir_triop_bitfield_extract: { int offset = op[1]-value.i[0]; int bits = op[2]-value.i[0]; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/14] i965/vec4: Add support for ir_unop_saturate
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index ee52c07..2112edf 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -1348,6 +1348,10 @@ vec4_visitor::visit(ir_expression *ir) case ir_unop_find_lsb: emit(FBL(result_dst, op[0])); break; + case ir_unop_saturate: + inst = emit(MOV(result_dst, op[0])); + inst-saturate = true; + break; case ir_unop_noise: assert(!not reached: should be handled by lower_noise); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/14] glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1)
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/glsl/ir_optimization.h | 1 + src/glsl/lower_instructions.cpp | 29 + 2 files changed, 30 insertions(+) diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h index c63921c..a831adb 100644 --- a/src/glsl/ir_optimization.h +++ b/src/glsl/ir_optimization.h @@ -40,6 +40,7 @@ #define LDEXP_TO_ARITH 0x100 #define CARRY_TO_ARITH 0x200 #define BORROW_TO_ARITH0x400 +#define SAT_TO_CLAMP 0x800 /** * \see class lower_packing_builtins_visitor diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp index 176070c..6842853 100644 --- a/src/glsl/lower_instructions.cpp +++ b/src/glsl/lower_instructions.cpp @@ -41,6 +41,7 @@ * - BITFIELD_INSERT_TO_BFM_BFI * - CARRY_TO_ARITH * - BORROW_TO_ARITH + * - SAT_TO_CLAMP * * SUB_TO_ADD_NEG: * --- @@ -104,6 +105,10 @@ * * Converts ir_borrow into (x y). * + * SAT_TO_CLAMP: + * - + * Converts ir_unop_saturate into min(max(x, 0.0), 1.0) + * */ #include main/core.h /* for M_LOG2E */ @@ -139,6 +144,7 @@ private: void ldexp_to_arith(ir_expression *); void carry_to_arith(ir_expression *); void borrow_to_arith(ir_expression *); + void sat_to_clamp(ir_expression *); }; } /* anonymous namespace */ @@ -484,6 +490,24 @@ lower_instructions_visitor::borrow_to_arith(ir_expression *ir) this-progress = true; } +void +lower_instructions_visitor::sat_to_clamp(ir_expression *ir) +{ + /* Translates +* ir_unop_saturate x +* into +* ir_binop_min (ir_binop_max(x, 0.0), 1.0) +*/ + + ir-operation = ir_binop_min; + ir-operands[0] = new(ir) ir_expression(ir_binop_max, ir-operands[0]-type, + ir-operands[0], + new(ir) ir_constant(0.0f)); + ir-operands[1] = new(ir) ir_constant(1.0f); + + this-progress = true; +} + ir_visitor_status lower_instructions_visitor::visit_leave(ir_expression *ir) { @@ -540,6 +564,11 @@ lower_instructions_visitor::visit_leave(ir_expression *ir) borrow_to_arith(ir); break; + case ir_unop_saturate: + if (lowering(SAT_TO_CLAMP)) + sat_to_clamp(ir); + break; + default: return visit_continue; } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/14] glsl: Add ir_unop_saturate
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/glsl/ir.cpp | 2 ++ src/glsl/ir.h| 1 + src/glsl/ir_validate.cpp | 1 + 3 files changed, 4 insertions(+) diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp index 8fed768..7682e1e 100644 --- a/src/glsl/ir.cpp +++ b/src/glsl/ir.cpp @@ -251,6 +251,7 @@ ir_expression::ir_expression(int op, ir_rvalue *op0) case ir_unop_dFdx: case ir_unop_dFdy: case ir_unop_bitfield_reverse: + case ir_unop_saturate: this-type = op0-type; break; @@ -524,6 +525,7 @@ static const char *const operator_strs[] = { bit_count, find_msb, find_lsb, + sat, noise, +, -, diff --git a/src/glsl/ir.h b/src/glsl/ir.h index b4e52d3..e70bbd1 100644 --- a/src/glsl/ir.h +++ b/src/glsl/ir.h @@ -1226,6 +1226,7 @@ enum ir_expression_operation { ir_unop_find_lsb, /*@}*/ + ir_unop_saturate, ir_unop_noise, /** diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp index 17a74ea..ec30ed5 100644 --- a/src/glsl/ir_validate.cpp +++ b/src/glsl/ir_validate.cpp @@ -243,6 +243,7 @@ ir_validate::visit_leave(ir_expression *ir) case ir_unop_log: case ir_unop_exp2: case ir_unop_log2: + case ir_unop_saturate: assert(ir-operands[0]-type-base_type == GLSL_TYPE_FLOAT); assert(ir-type == ir-operands[0]-type); break; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/14] ir_to_mesa, glsl_to_tgsi: lower ir_unop_saturate
Needed when vertex programs doesn't allow saturate Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/mesa/program/ir_to_mesa.cpp| 5 - src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 +- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp index 59cf123..17ccb64 100644 --- a/src/mesa/program/ir_to_mesa.cpp +++ b/src/mesa/program/ir_to_mesa.cpp @@ -3000,9 +3000,12 @@ _mesa_ir_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) /* Lowering */ do_mat_op_to_vec(ir); +GLenum target = _mesa_shader_stage_to_program(prog-_LinkedShaders[i]-Stage); lower_instructions(ir, (MOD_TO_FRACT | DIV_TO_MUL_RCP | EXP_TO_EXP2 | LOG_TO_LOG2 | INT_DIV_TO_MUL_RCP -| ((options-EmitNoPow) ? POW_TO_EXP2 : 0))); +| ((options-EmitNoPow) ? POW_TO_EXP2 : 0) +| ((target == GL_VERTEX_PROGRAM_ARB) ? SAT_TO_CLAMP +: 0))); progress = do_lower_jumps(ir, true, true, options-EmitNoMainReturn, options-EmitNoCont, options-EmitNoLoops) || progress; diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 739e108..a4dd18a 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -5434,6 +5434,9 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) if (!pscreen-get_param(pscreen, PIPE_CAP_TEXTURE_GATHER_OFFSETS)) lower_offset_arrays(ir); do_mat_op_to_vec(ir); + /* Emit saturates in the vertex shader only if SM 3.0 is supported. */ + bool vs_sm3 = (_mesa_shader_stage_to_program(prog-_LinkedShaders[i]-Stage) == + GL_VERTEX_PROGRAM_ARB) st_context(ctx)-has_shader_model3; lower_instructions(ir, MOD_TO_FRACT | DIV_TO_MUL_RCP | @@ -5443,7 +5446,8 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) CARRY_TO_ARITH | BORROW_TO_ARITH | (options-EmitNoPow ? POW_TO_EXP2 : 0) | - (!ctx-Const.NativeIntegers ? INT_DIV_TO_MUL_RCP : 0)); + (!ctx-Const.NativeIntegers ? INT_DIV_TO_MUL_RCP : 0) | + (vs_sm3 ? SAT_TO_CLAMP : 0)); lower_ubo_reference(prog-_LinkedShaders[i], ir); do_vec_index_to_cond_assign(ir); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] glxinfo: Print XFB, TBO, and UBO limits
On Sunday 22 June 2014, Ilia Mirkin wrote: Fredrik, What happened to this series? Ian suggested that we add a build-time dependency on current GL headers, but I haven't gotten around to that yet. It's not needed for patches 1-3 though, so those could be pushed. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: Optimize clamp(x, b, 1.0), where b 0.0 as saturate(max(x, b))
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com --- src/glsl/opt_algebraic.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 0d694b6..ee52de7 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -593,6 +593,12 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) /* Found a min (max(x, 0.0) b), where b 1.0 */ if ((outer_const-get_float_component(0) 1.0f) inner_val_b-is_zero()) return saturate(expr(ir_binop_min, inner_val_a, outer_const)); + +/* Found a min (max(x, b, 1.0), where b 0.0 */ +ir_constant *inner_const = inner_val_b-as_constant(); +if (outer_const-is_one() +(inner_const inner_const-get_float_component(0) 0.0f)) + return saturate(expr(ir_binop_max, inner_val_a, inner_val_b)); } } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev