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
