[Mesa-dev] [Bug 80034] compile error eglGetSyncValuesCHROMIUM undeclared
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #2 from charlie bug0xa...@hushmail.com ---
Which version of mesa is this ? Is this a regression ?
mesa git and probably a regression.
I'm assuming that you have some thing that is messing with CFLAGS.
I don't believe the CFLAGS have changed since I last successfully built mesa
with them.
export CFLAGS=-m${LIBDIRSUFFIX} -O3 -march=native -pipe
export CXXFLAGS=${CFLAGS} -fvisibility-inlines-hidden
export CPPFLAGS=${CXXLAGS} -I${XBUILD}/include
-L${XBUILD}/lib${LIBDIRSUFFIX}:${XBUILD}/lib:/usr/lib${LIBDIRSUFFIX}
I disabled the CFLAGS/CXXFLAGS/CPPFLAGS variables and mesa built successfully.
Missing ${XBUILD} ? Might be worth dropping this one as well.
Not missing--it is a variable pointing to the installation directory.
These seem like libdrm configure flags. Not sure what are they doing here.
What are these doing here ?
The above statements suggest you never used
http://cgit.freedesktop.org/xorg/util/modular/plain/build.sh to build all of X.
I assume you are compiling mesa by hand or are on another platform.
Please avoid setting these if they are identical. IIRC there was a bug
(automake/autoconf) that was incorrectly setting the cross-compile variable.
Thanks for the heads up. Unsetting build/host/target has no effect on the
building bug.
My conclusion is that something changed in the mesa code that will not allow me
to use my old CFLAGS/CXXFLAGS/CPPFLAGS.
It might take me a while to figure out where in git the change effects the
build.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/13] glsl: Remove 'struct' from ir_variable declaration.
This set (1..13) Reviewed-by: Tapani Pälli tapani.pa...@intel.com There's still some unused variables and one unused function (svga_draw.c:294) left but this set makes build much more silent. On 06/15/2014 08:15 PM, Matt Turner wrote: --- src/glsl/opt_dead_builtin_varyings.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/opt_dead_builtin_varyings.cpp b/src/glsl/opt_dead_builtin_varyings.cpp index 6612592..50c8aa7 100644 --- a/src/glsl/opt_dead_builtin_varyings.cpp +++ b/src/glsl/opt_dead_builtin_varyings.cpp @@ -334,7 +334,7 @@ public: } void prepare_array(exec_list *ir, - struct ir_variable **new_var, + ir_variable **new_var, int max_elements, unsigned start_location, const char *var_name, const char *mode_str, unsigned usage, unsigned external_usage) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/13] glsl: Remove 'struct' from ir_variable declaration.
On 06/16/2014 09:55 AM, Tapani Pälli wrote: This set (1..13) Reviewed-by: Tapani Pälli tapani.pa...@intel.com There's still some unused variables and one unused function (svga_draw.c:294) left but this set makes build much more silent. now I see that this func is for debugging so it is ok On 06/15/2014 08:15 PM, Matt Turner wrote: --- src/glsl/opt_dead_builtin_varyings.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/opt_dead_builtin_varyings.cpp b/src/glsl/opt_dead_builtin_varyings.cpp index 6612592..50c8aa7 100644 --- a/src/glsl/opt_dead_builtin_varyings.cpp +++ b/src/glsl/opt_dead_builtin_varyings.cpp @@ -334,7 +334,7 @@ public: } void prepare_array(exec_list *ir, - struct ir_variable **new_var, + ir_variable **new_var, int max_elements, unsigned start_location, const char *var_name, const char *mode_str, unsigned usage, unsigned external_usage) ___ 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 11/18] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
Hi Chris,
On Sat, 2014-06-14 at 08:34 +1200, Chris Forbes wrote:
Right, this happens because ir_emit_vertex doesn't take a proper
operand, so it can't keep it alive.
What I think you want to do is change the stream in ir_emit_vertex and
ir_end_primitive to be a pointer to ir_rvalue (and apply the various
tweaks required to consider it alive; have rvalue visitors descend
into it; etc) then emit:
thanks for the tip, I will look into this. I am not sure about what you
mean by applying the various tweaks required to consider the stream
alive (unless you mean the rvalue visitor stuff specifically), but I'll
try to look for clues in other built-in functions.
Iago
(function EmitStreamVertex
(signature void
(parameters
(declare (const_in ) int stream)
)
(
(emit-vertex (var_ref stream))
))
)
which would inline in your case to
(declare () int stream)
(assign (x) (var_ref stream) (constant int (0)) )
(emit-vertex (var_ref stream))
and then after constant propagation,
(emit-vertex (constant int (0)) )
which you can then pick out in your later visitors just as easily as
you can with the integer you're currently storing.
On Fri, Jun 13, 2014 at 11:52 PM, Iago Toral ito...@igalia.com wrote:
On Fri, 2014-06-13 at 10:28 +0200, Iago Toral wrote:
I forgot to add an important piece of info. I also had to add this in
the opt_dead_code.cpp, do_dead_code():
if (strcmp(entry-var-name, stream) == 0)
continue;
without that, the variable referenced by ir_emit_vertex() gets trashed
anyway, whether the ralloc context in link_shaders is detroyed or not.
The variable is killed because it is not used, as I was anticipating in
my patch, but I don't think the optimization passes are broken, I think
this is expected to happen:
This is the code generated for EmitStreamVertex(0) after function
inlining:
(declare () int stream)
(assign (x) (var_ref stream) (constant int (0)) )
(emit-vertex)
(...)
(function EmitStreamVertex
(signature void
(parameters
(declare (const_in ) int stream)
)
(
(emit-vertex)
))
)
And this is after the dead code elimination passes (dead_code and
dead_code_local), first the assignment is removed:
(declare () int stream)
(emit-vertex)
And finally, in a second pass, it removes the declaration too, leaving:
(emit-vertex)
Seems to make sense: it is killing a variable that is, at this stage,
not used for anything. So, as I was saying in the original patch, I
think we can't do EmitStreamVertex(n) like any other built-in function
because we won't be using its input parameter in the body of the
function for anything, the variable's value is to be used in the visitor
when it is time to generate the native code and that happens after the
optimization passes, so we need to grab its constant value before the
optimization passes (as my original patch did) or we have to find a way
to tell the optimization passes that it should not touch this variable
specifically (and then we would still have to figure out how to access
that temporary variable holding the stream value from the visitor).
Iago
Iago
On Fri, 2014-06-13 at 10:09 +0200, Iago Toral wrote:
After debugging I have more information about what is going on. There
are two problems, one is that the stream variable in ir_emit_vertex gets
trashed and the other one is that even if we manage to avoid that it
won't get its value assigned. I explain how these two come to happen
below and maybe someone can point me to what I am doing wrong:
first, this is how I am defining EmitStreamVertex():
ir_function_signature *
builtin_builder::_EmitStreamVertex(builtin_available_predicate avail,
const glsl_type *stream_type)
{
ir_variable *stream =
new(mem_ctx) ir_variable(stream_type, stream, ir_var_const_in);
MAKE_SIG(glsl_type::void_type, avail, 1, stream);
ir_emit_vertex *ir = new(mem_ctx) ir_emit_vertex();
ir-stream = var_ref(stream);
body.emit(ir);
return sig;
}
The pattern is similar to other built-in functions. Notice how
ir_stream_vertex will take a reference to the input stream variable.
And this is how I am defining ir_emit_vertex:
class ir_emit_vertex : public ir_instruction {
public:
ir_emit_vertex() : ir_instruction(ir_type_emit_vertex), stream(NULL) {}
virtual void accept(ir_visitor *v) { v-visit(this); }
virtual ir_emit_vertex *clone(void *mem_ctx, struct hash_table *ht)
const
{
ir_emit_vertex *ir = new(mem_ctx) ir_emit_vertex();
if (this-stream)
ir-stream = this-stream-clone(mem_ctx, ht);
return ir;
}
virtual ir_visitor_status accept(ir_hierarchical_visitor *);
ir_dereference_variable *stream;
};
Again, I don't see anything special
Re: [Mesa-dev] [PATCH 11/18] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
Have a look at the ir_texture stuff -- it's complex, but it has a
whole bunch of ir_value* for the various texture parameters. You'll be
able to do something simpler, but will probably have to touch most of
the same places that currently treat texturing specially.
On Mon, Jun 16, 2014 at 7:04 PM, Iago Toral ito...@igalia.com wrote:
Hi Chris,
On Sat, 2014-06-14 at 08:34 +1200, Chris Forbes wrote:
Right, this happens because ir_emit_vertex doesn't take a proper
operand, so it can't keep it alive.
What I think you want to do is change the stream in ir_emit_vertex and
ir_end_primitive to be a pointer to ir_rvalue (and apply the various
tweaks required to consider it alive; have rvalue visitors descend
into it; etc) then emit:
thanks for the tip, I will look into this. I am not sure about what you
mean by applying the various tweaks required to consider the stream
alive (unless you mean the rvalue visitor stuff specifically), but I'll
try to look for clues in other built-in functions.
Iago
(function EmitStreamVertex
(signature void
(parameters
(declare (const_in ) int stream)
)
(
(emit-vertex (var_ref stream))
))
)
which would inline in your case to
(declare () int stream)
(assign (x) (var_ref stream) (constant int (0)) )
(emit-vertex (var_ref stream))
and then after constant propagation,
(emit-vertex (constant int (0)) )
which you can then pick out in your later visitors just as easily as
you can with the integer you're currently storing.
On Fri, Jun 13, 2014 at 11:52 PM, Iago Toral ito...@igalia.com wrote:
On Fri, 2014-06-13 at 10:28 +0200, Iago Toral wrote:
I forgot to add an important piece of info. I also had to add this in
the opt_dead_code.cpp, do_dead_code():
if (strcmp(entry-var-name, stream) == 0)
continue;
without that, the variable referenced by ir_emit_vertex() gets trashed
anyway, whether the ralloc context in link_shaders is detroyed or not.
The variable is killed because it is not used, as I was anticipating in
my patch, but I don't think the optimization passes are broken, I think
this is expected to happen:
This is the code generated for EmitStreamVertex(0) after function
inlining:
(declare () int stream)
(assign (x) (var_ref stream) (constant int (0)) )
(emit-vertex)
(...)
(function EmitStreamVertex
(signature void
(parameters
(declare (const_in ) int stream)
)
(
(emit-vertex)
))
)
And this is after the dead code elimination passes (dead_code and
dead_code_local), first the assignment is removed:
(declare () int stream)
(emit-vertex)
And finally, in a second pass, it removes the declaration too, leaving:
(emit-vertex)
Seems to make sense: it is killing a variable that is, at this stage,
not used for anything. So, as I was saying in the original patch, I
think we can't do EmitStreamVertex(n) like any other built-in function
because we won't be using its input parameter in the body of the
function for anything, the variable's value is to be used in the visitor
when it is time to generate the native code and that happens after the
optimization passes, so we need to grab its constant value before the
optimization passes (as my original patch did) or we have to find a way
to tell the optimization passes that it should not touch this variable
specifically (and then we would still have to figure out how to access
that temporary variable holding the stream value from the visitor).
Iago
Iago
On Fri, 2014-06-13 at 10:09 +0200, Iago Toral wrote:
After debugging I have more information about what is going on. There
are two problems, one is that the stream variable in ir_emit_vertex gets
trashed and the other one is that even if we manage to avoid that it
won't get its value assigned. I explain how these two come to happen
below and maybe someone can point me to what I am doing wrong:
first, this is how I am defining EmitStreamVertex():
ir_function_signature *
builtin_builder::_EmitStreamVertex(builtin_available_predicate avail,
const glsl_type *stream_type)
{
ir_variable *stream =
new(mem_ctx) ir_variable(stream_type, stream, ir_var_const_in);
MAKE_SIG(glsl_type::void_type, avail, 1, stream);
ir_emit_vertex *ir = new(mem_ctx) ir_emit_vertex();
ir-stream = var_ref(stream);
body.emit(ir);
return sig;
}
The pattern is similar to other built-in functions. Notice how
ir_stream_vertex will take a reference to the input stream variable.
And this is how I am defining ir_emit_vertex:
class ir_emit_vertex : public ir_instruction {
public:
ir_emit_vertex() : ir_instruction(ir_type_emit_vertex), stream(NULL) {}
virtual void accept(ir_visitor *v) { v-visit(this); }
virtual ir_emit_vertex *clone(void *mem_ctx, struct hash_table
Re: [Mesa-dev] [PATCH 06/13] mesa: Remove unused functions from perfomance query code.
On 06/15/2014 08:17 PM, Matt Turner wrote:
Perhaps useful for debugging? Never used otherwise. Added by commit
8cf5bdad.
---
src/mesa/main/performance_monitor.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/src/mesa/main/performance_monitor.c
b/src/mesa/main/performance_monitor.c
index 9d1a6b4..c26eda4 100644
--- a/src/mesa/main/performance_monitor.c
+++ b/src/mesa/main/performance_monitor.c
@@ -164,19 +164,6 @@ counterid_to_index(GLuint counterid)
return counterid - 1;
}
-static inline GLuint
-index_to_counterid(GLuint index)
-{
- return index + 1;
-}
-
-static inline bool
-counterid_valid(const struct gl_perf_monitor_group *group_obj,
-GLuint counterid)
-{
- return get_counter(group_obj, counterid_to_index(counterid)) != NULL;
-}
-
/*/
void GLAPIENTRY
Oh, bugger. Those functions were used at some point, but their lack of
use after refactoring never came up.
Reviewed-by: Petri Latvala petri.latv...@intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80034] compile error eglGetSyncValuesCHROMIUM undeclared
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #3 from Tapani Pälli lem...@gmail.com ---
(In reply to comment #2)
export CFLAGS=-m${LIBDIRSUFFIX} -O3 -march=native -pipe
export CXXFLAGS=${CFLAGS} -fvisibility-inlines-hidden
export CPPFLAGS=${CXXLAGS} -I${XBUILD}/include
-L${XBUILD}/lib${LIBDIRSUFFIX}:${XBUILD}/lib:/usr/lib${LIBDIRSUFFIX}
Note that there is typo setting CPPFLAGS (CXXLAGS). Also feeding CXXFLAGS to
CPPFLAGS can potentially cause problems (?) At least you should see following
errors when compiling:
cc1: warning: command line option '-fvisibility-inlines-hidden' is valid for
C++/ObjC++ but not for C [enabled by default]
(just noticed this when I tried to reproduce the bug)
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/18] Multi-stream support for geometry shaders
On Sun, 2014-06-15 at 19:18 -0400, Ilia Mirkin wrote:
On Wed, Jun 11, 2014 at 12:31 PM, Jordan Justen jljus...@gmail.com wrote:
On Wed, Jun 11, 2014 at 2:49 AM, Iago Toral ito...@igalia.com wrote:
Hi Chris,
thanks for the quick review!
On Wed, 2014-06-11 at 21:45 +1200, Chris Forbes wrote:
I sent comments on patches 1, 3, 5, 9, 11, 16, 18
We will look into these.
Patches 2, 4, 6-8, 10, 12-15, 17 are:
Reviewed-by: Chris Forbes chr...@ijw.co.nz
You should also include a patch to docs/GL3.txt marking off this
subfeature for i965 :)
Do you have a bunch of piglits which exercise all the tricky corners
of this? I see a few tests
which require the existence of the stream layout qualifier, but not
covering all the behavior.
No, so far we have been testing this with a standalone program. We will
check what already exists in piglit and add missing test cases.
This is the only piglit test that I know about:
http://patchwork.freedesktop.org/patch/19224/
Note that it passed on nvidia, but failed on catalyst.
I just ran that test against this code (+ a few changes to add support
in gallium) and I got:
$ MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5
bin/arb_gpu_shader5-xfb-streams -fbo -auto
Failed to compile geometry shader: 0:3(1): error: invalid input layout
qualifiers used
source:
#version 150
#extension GL_ARB_gpu_shader5 : enable
layout(points, invocations = 32) in;
layout(points, max_vertices = 4) out;
out float stream0_0_out;
layout(stream = 1) out vec2 stream1_0_out;
layout(stream = 2) out float stream2_0_out;
layout(stream = 3) out vec3 stream3_0_out;
layout(stream = 1) out vec3 stream1_1_out;
layout(stream = 2) out vec4 stream2_1_out;
void main() {
gl_Position = gl_in[0].gl_Position;
stream0_0_out = 1.0 + gl_InvocationID;
EmitVertex();
EndPrimitive();
stream3_0_out = vec3(12.0 + gl_InvocationID, 13.0 + gl_InvocationID,
14.0 + gl_InvocationID);
EmitStreamVertex(3);
EndStreamPrimitive(3);
stream2_0_out = 7.0 + gl_InvocationID;
stream2_1_out = vec4(8.0 + gl_InvocationID, 9.0 + gl_InvocationID,
10.0 + gl_InvocationID, 11.0 + gl_InvocationID);
EmitStreamVertex(2);
EndStreamPrimitive(2);
stream1_0_out = vec2(2.0 + gl_InvocationID, 3.0 + gl_InvocationID);
stream1_1_out = vec3(4.0 + gl_InvocationID, 5.0 + gl_InvocationID,
6.0 + gl_InvocationID);
EmitStreamVertex(1);
EndStreamPrimitive(1);
}PIGLIT: {'result': 'fail' }
I guess it doesn't like
layout(points, invocations=32) in? Not sure. I could also have
messed something up... doing a bisect over your patches blames
glsl: Add parsing support for multi-stream output in geometry shaders.
Before that, it goes until the first stream=1 layout and fails there
(which is expected).
-ilia
I will take a look at it.
Thanks for reporting!
Sam
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: fix p_atomic_dec_zero macros
op 13-06-14 07:39, Michel Dänzer schreef:
On 12.06.2014 17:00, Maarten Lankhorst wrote:
I'm pretty sure that p_atomic_dec_zero should return 1 if the count
drops to zero.
Cc: 10.2 10.1 10.0 mesa-sta...@lists.freedesktop.org
I don't think the stable tag is justified: These bugs have been there
for more than four years. Nothing in Gallium can work properly if the
return value of p_atomic_dec_zero() is inverted, so if there was
significant use of the broken variants, we should have heard about it
long ago.
Yeah, they're just the fallbacks I guess.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 2f2b42b..08cadb4 100644
--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -183,7 +183,7 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#define p_atomic_set(_v, _i) (*(_v) = (_i))
#define p_atomic_read(_v) (*(_v))
-#define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
+#define p_atomic_dec_zero(_v) (!(boolean) --(*(_v)))
Will this compile (with the intended result) without another set of parens?
Compiling the following in g++ and gcc seems to confirm it works correctly:
#include stdio.h
int main() {
int i = 1;
printf(dropped to 0: %i\n, (!(unsigned)--(*(i;
return 0;
}
Output:
dropped to 0: 1
@@ -324,7 +324,7 @@ p_atomic_dec_zero(int32_t *v)
{
uint32_t n = atomic_dec_32_nv((uint32_t *) v);
- return n != 0;
+ return n == 0;
}
This looks good, but there are more variants which look similarly broken?
Is this intended to be a question or a statement? The other p_atomic_dec_zero
definitions look fine afaict.
~Maarten
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74010] mesa-10.0.2: z-buffer issue with opengl 3.3 context on intel
https://bugs.freedesktop.org/show_bug.cgi?id=74010 Tapani Pälli lem...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #11 from Tapani Pälli lem...@gmail.com --- took some time to figure this out but the attributelist you pass to GLX (via glXChooseFBConfig) is broken, you should have attribute-value pairs, instead there is a single 'GLX_RGBA' in the middle of the list which screws things up badly. Take that GLX_RGBA away and things will work just fine. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80034] compile error eglGetSyncValuesCHROMIUM undeclared
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #4 from Emil Velikov emil.l.veli...@gmail.com ---
(In reply to comment #2)
...
I don't believe the CFLAGS have changed since I last successfully built mesa
with them.
export CFLAGS=-m${LIBDIRSUFFIX} -O3 -march=native -pipe
export CXXFLAGS=${CFLAGS} -fvisibility-inlines-hidden
export CPPFLAGS=${CXXLAGS} -I${XBUILD}/include
-L${XBUILD}/lib${LIBDIRSUFFIX}:${XBUILD}/lib:/usr/lib${LIBDIRSUFFIX}
I disabled the CFLAGS/CXXFLAGS/CPPFLAGS variables and mesa built
successfully.
I would recommend setting PKG_CONFIG_PATH/PKG_CONFIG_LIBDIR which should make
the above CPPFLAGS obsolete. Your choice of CPPFLAGS is very hacky imho.
Also as Tapani mentioned CPPFLAGS=${CXXLAGS}... may not be the best of ideas.
Missing ${XBUILD} ? Might be worth dropping this one as well.
Not missing--it is a variable pointing to the installation directory.
AFAIK as one provides a new sysconfdir, the value is independent of
PREFIX/EPREFIX. Thus setting it to /etc while the latter two are ${XBUILD} is
not something I've seen and/or encourage.
These seem like libdrm configure flags. Not sure what are they doing here.
What are these doing here ?
The above statements suggest you never used
http://cgit.freedesktop.org/xorg/util/modular/plain/build.sh to build all of
X. I assume you are compiling mesa by hand or are on another platform.
Guilty, I've never used the script as mesa's build has changed substantially
since it originated. I use a simple 10-liner script that sets the options that
I need from mesa.
...
It might take me a while to figure out where in git the change effects the
build.
Please set PKG_CONFIG_... as suggested above and drop the CPPFLAGS altogether.
Mesa's build has always been less than stellar, and allowed people to exploit
it to the limits. Recent changes have made things a bit saner.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] mesa/main: Add generic bits of ARB_clear_texture implementation
Ilia Mirkin imir...@alum.mit.edu writes:
+ if (ctx-Version = 30 || ctx-Extensions.EXT_texture_integer) {
Just ctx-Extensions.EXT_texture_integer should be enough here, no?
I'm reluctant to change this because every other place in the code that
checks for integer textures does it in the same way. Perhaps if we
wanted to change it then we should do it in a separate patch and change
it everywhere. I think it might theoretically make sense to expose GL 3
without GL_EXT_texture_integer in some cases because the extension
implies supporting luminance integer textures whereas GL 3 does not.
This bit of code implies that Mesa treats the two types of support for
integer textures distinctly:
http://is.gd/HM3SIw
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 3/3] Add a new capabilities for drivers that can't share buffers
Does the new CAP cover resource_from_handle or resource_get_handle or both?
Marek
On Sun, Jun 15, 2014 at 1:49 PM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
From: Giovanni Campagna gcampa...@src.gnome.org
The kms-dri swrast driver cannot share buffers using the GEM,
so it must tell the loader to disable extensions relying on
that, without disabling the image DRI extension altogheter
(which would prevent the loader from working at all).
This requires a new gallium capability (which is queried on
the pipe_screen and for swrast drivers it's forwared to the
winsys), and requires a new version of the DRI image extension.
---
include/GL/internal/dri_interface.h| 17 +-
src/egl/drivers/dri2/egl_dri2.c| 10 -
src/egl/drivers/dri2/platform_drm.c| 17 +++---
src/gallium/docs/source/screen.rst | 5 -
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen.c | 2 ++
src/gallium/drivers/llvmpipe/lp_screen.c | 7 ++
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++
src/gallium/drivers/r300/r300_screen.c | 1 +
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
src/gallium/drivers/softpipe/sp_screen.c | 7 ++
src/gallium/drivers/svga/svga_screen.c | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
src/gallium/include/state_tracker/sw_winsys.h | 5 +
src/gallium/state_trackers/dri/common/dri_screen.h | 1 +
src/gallium/state_trackers/dri/drm/dri2.c | 23 +++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 26
+++---
21 files changed, 121 insertions(+), 14 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 4d57d0b..fba1cac 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1005,7 +1005,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 8
+#define __DRI_IMAGE_VERSION 9
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -1133,6 +1133,13 @@ enum __DRIChromaSiting {
#define __DRI_IMAGE_ERROR_BAD_PARAMETER 3
/*@}*/
+/**
+ * \name Capabilities that might be returned by
__DRIimageExtensionRec::getCapabilities
+ */
+/*@{*/
+#define __DRI_IMAGE_CAP_GLOBAL_NAMES 1
+/*@}*/
+
typedef struct __DRIimageRec __DRIimage;
typedef struct __DRIimageExtensionRec __DRIimageExtension;
struct __DRIimageExtensionRec {
@@ -1239,6 +1246,14 @@ struct __DRIimageExtensionRec {
enum __DRIChromaSiting vert_siting,
unsigned *error,
void *loaderPrivate);
+
+ /**
+* Query for general capabilities of the driver that concern
+* buffer sharing and image importing.
+*
+* \since 9
+*/
+ int (*getCapabilities)(__DRIscreen *screen);
};
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index eb6abfd..132ebff 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -520,7 +520,15 @@ dri2_setup_screen(_EGLDisplay *disp)
}
if (dri2_dpy-image) {
- disp-Extensions.MESA_drm_image = EGL_TRUE;
+ if (dri2_dpy-image-base.version = 9
+ dri2_dpy-image-getCapabilities != NULL) {
+ int capabilities;
+
+ capabilities =
dri2_dpy-image-getCapabilities(dri2_dpy-dri_screen);
+ disp-Extensions.MESA_drm_image = (capabilities
__DRI_IMAGE_CAP_GLOBAL_NAMES) != 0;
+ } else
+ disp-Extensions.MESA_drm_image = EGL_TRUE;
+
disp-Extensions.KHR_image_base = EGL_TRUE;
disp-Extensions.KHR_gl_renderbuffer_image = EGL_TRUE;
if (dri2_dpy-image-base.version = 5
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index 6a0dcd3..633b2ab 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -270,7 +270,10 @@ back_bo_to_dri_buffer(struct dri2_egl_surface
*dri2_surf, __DRIbuffer *buffer)
bo = (struct gbm_dri_bo *) dri2_surf-back-bo;
- dri2_dpy-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_NAME, name);
+ if (dri2_surf-base.Resource.Display-Extensions.MESA_drm_image)
+ dri2_dpy-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_NAME, name);
+ else
+ dri2_dpy-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_HANDLE,
name);
dri2_dpy-image-queryImage(bo-image,
Re: [Mesa-dev] [PATCH 4/5] texstore: Add a generic implementation of GL_ARB_clear_texture
Ilia Mirkin imir...@alum.mit.edu writes:
Will it? What about the MS case? I thought that for generic you had to
do a shader-based approach.
Ah yes, you're right the commit message is nonsense. I guess I should
also avoid enabling the extension at all until the next patch.
While I'm sure we all love the
while (height -- 0) { // as height goes to 0
construct... it's not immediately obvious (to me) that it's correct
when just glancing at it. After a few seconds of thought, it is
clearly right, but I think the more common thing is to use a for loop
where it's obvious there isn't some silly off-by-one error. I don't
think this is really used anywhere else in mesa. Here and below.
Ok, yes, I guess it is clearer to use a separate iterator variable.
However I don't think it's that uncommon in Mesa. Running ‘git grep
while (.*--’ shoes plenty of examples.
I've updated the wip/clear-texture branch on my github with these two
changes.
Thanks for the review.
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] mesa/main: Add generic bits of ARB_clear_texture implementation
The presence of EXT_texture_integer implies EXT_gpu_shader4, so I
added ctx-Version = 30 || ctx-Extensions.EXT_texture_integer
everywhere to allow drivers to disable EXT_texture_integer but not
lose integer textures from GL 3.0.
Marek
On Mon, Jun 16, 2014 at 12:49 PM, Neil Roberts n...@linux.intel.com wrote:
Ilia Mirkin imir...@alum.mit.edu writes:
+ if (ctx-Version = 30 || ctx-Extensions.EXT_texture_integer) {
Just ctx-Extensions.EXT_texture_integer should be enough here, no?
I'm reluctant to change this because every other place in the code that
checks for integer textures does it in the same way. Perhaps if we
wanted to change it then we should do it in a separate patch and change
it everywhere. I think it might theoretically make sense to expose GL 3
without GL_EXT_texture_integer in some cases because the extension
implies supporting luminance integer textures whereas GL 3 does not.
This bit of code implies that Mesa treats the two types of support for
integer textures distinctly:
http://is.gd/HM3SIw
Regards,
- Neil
___
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 1/9] r600g/compute: Add an intermediate resource for OpenCL buffers
On Fri, Jun 13, 2014 at 10:35:30PM +0200, Bruno Jiménez wrote:
This patch changes completely the way buffers are added to the
compute_memory_pool. Before this, whenever we were going to
map a buffer or write to or read from it, it would get placed
into the pool. Now, every unallocated buffer has its own
r600_resource until it is allocated in the pool.
NOTE: This patch also increase the GPU memory usage at the moment
of putting every buffer in it's place. More or less, the memory
usage is ~2x(sum of every buffer size)
v2: Cleanup
---
src/gallium/drivers/r600/compute_memory_pool.c | 21 -
src/gallium/drivers/r600/compute_memory_pool.h | 2 ++
src/gallium/drivers/r600/evergreen_compute.c | 18 +-
3 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..94ddcde 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -71,7 +71,6 @@ static void compute_memory_pool_init(struct
compute_memory_pool * pool,
if (pool-shadow == NULL)
return;
- pool-next_id = 1;
pool-size_in_dw = initial_size_in_dw;
pool-bo = (struct
r600_resource*)r600_compute_buffer_alloc_vram(pool-screen,
pool-size_in_dw * 4);
@@ -365,6 +364,18 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
pool-item_list = item;
}
+ ((struct r600_context *)pipe)-b.b.resource_copy_region(pipe,
+ (struct pipe_resource *)pool-bo,
+ 0, item-start_in_dw * 4, 0 ,0,
+ (struct pipe_resource *)item-real_buffer,
+ 0, (struct pipe_box) {.width =
item-size_in_dw * 4,
+ .height = 1, .depth = 1});
+
+ pool-screen-b.b.resource_destroy(
+ (struct pipe_screen *)pool-screen,
+ (struct pipe_resource *)item-real_buffer);
You should use temporary variables rather than inlining the casts everywhere.
It will make the code easier to read. Make sure to declare the at the beginning
of
the function or basic block.
+ item-real_buffer = NULL;
+
allocated += item-size_in_dw;
}
@@ -393,6 +404,12 @@ void compute_memory_free(struct compute_memory_pool*
pool, int64_t id)
item-next-prev = item-prev;
}
+ if (item-real_buffer) {
+ pool-screen-b.b.resource_destroy(
+ (struct pipe_screen
*)pool-screen,
+ (struct pipe_resource
*)item-real_buffer);
+ }
+
Same thing here with the casts.
free(item);
return;
@@ -426,6 +443,8 @@ struct compute_memory_item* compute_memory_alloc(
new_item-start_in_dw = -1; /* mark pending */
new_item-id = pool-next_id++;
new_item-pool = pool;
+ new_item-real_buffer = (struct
r600_resource*)r600_compute_buffer_alloc_vram(
+ pool-screen,
size_in_dw * 4);
if (pool-item_list) {
for (last_item = pool-item_list; last_item-next;
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index c711c59..e94159c 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.h
+++ b/src/gallium/drivers/r600/compute_memory_pool.h
@@ -38,6 +38,8 @@ struct compute_memory_item
int64_t start_in_dw; ///Start pointer in dwords relative in the pool bo
int64_t size_in_dw; ///Size of the chunk in dwords
+ struct r600_resource *real_buffer;
+
struct compute_memory_pool* pool;
struct compute_memory_item* prev;
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2abf15..c152e54 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -958,6 +958,17 @@ void *r600_compute_global_transfer_map(
struct r600_resource_global* buffer =
(struct r600_resource_global*)resource;
+ struct pipe_resource *dst;
+ unsigned offset = box-x;
+
+ if (buffer-chunk-real_buffer) {
+ dst = (struct pipe_resource*)buffer-chunk-real_buffer;
+ }
+ else {
+ dst = (struct pipe_resource*)buffer-chunk-pool-bo;
+ offset += (buffer-chunk-start_in_dw * 4);
+ }
+
COMPUTE_DBG(rctx-screen, * r600_compute_global_transfer_map()\n
level = %u, usage = %u, box(x = %u, y
Re: [Mesa-dev] [PATCH 2/9] r600g/compute: Add statuses to the compute_memory_items
On Fri, Jun 13, 2014 at 10:35:31PM +0200, Bruno Jiménez wrote:
These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool
---
src/gallium/drivers/r600/compute_memory_pool.h | 7 ++-
src/gallium/drivers/r600/evergreen_compute.c | 12
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index e94159c..166093d 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.h
+++ b/src/gallium/drivers/r600/compute_memory_pool.h
@@ -27,13 +27,18 @@
#include stdlib.h
+#define ITEM_MAPPED_FOR_READING (10)
+#define ITEM_MAPPED_FOR_WRITING (11)
+#define ITEM_FOR_PROMOTING (12)
+#define ITEM_FOR_DEMOTING (13)
+
struct compute_memory_pool;
struct compute_memory_item
{
int64_t id; ///ID of the memory chunk
- int untouched; ///True if the memory contains only junk, no need to
save it for defrag
+ uint32_t status; ///Will track the status of the item
int64_t start_in_dw; ///Start pointer in dwords relative in the pool bo
int64_t size_in_dw; ///Size of the chunk in dwords
This whole structure should use c style comments /* */, but that should be
fixed in a follow up patch.
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index c152e54..9123a40 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -659,6 +659,15 @@ static void evergreen_set_global_binding(
return;
}
+ /* We mark these items for promotion to the pool if they
+ * aren't already there */
+ for (int i = 0; i n; i++) {
+ struct compute_memory_item *item = buffers[i]-chunk;
+
+ if (item-start_in_dw == -1)
I would prefer to encapsulate this in an is_item_in_pool() helper function.
+ buffers[i]-chunk-status |= ITEM_FOR_PROMOTING;
+ }
+
compute_memory_finalize_pending(pool, ctx_);
for (int i = 0; i n; i++)
@@ -969,6 +978,9 @@ void *r600_compute_global_transfer_map(
offset += (buffer-chunk-start_in_dw * 4);
}
+ if (usage PIPE_TRANSFER_READ)
+ buffer-chunk-status |= ITEM_MAPPED_FOR_READING;
+
COMPUTE_DBG(rctx-screen, * r600_compute_global_transfer_map()\n
level = %u, usage = %u, box(x = %u, y = %u, z = %u
width = %u, height = %u, depth = %u)\n, level, usage,
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] r600g/compute: divide the item list in two
On Fri, Jun 13, 2014 at 10:35:32PM +0200, Bruno Jiménez wrote:
Now we will have a list with the items that are in the pool
(item_list) and the items that are outside it (unallocated_list)
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/compute_memory_pool.c | 99
+-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 49 insertions(+), 51 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 94ddcde..5a5ef12 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -108,13 +108,11 @@ int64_t compute_memory_prealloc_chunk(
size_in_dw);
for (item = pool-item_list; item; item = item-next) {
- if (item-start_in_dw -1) {
- if (last_end + size_in_dw = item-start_in_dw) {
- return last_end;
- }
-
- last_end = item-start_in_dw + align(item-size_in_dw,
ITEM_ALIGNMENT);
+ if (last_end + size_in_dw = item-start_in_dw) {
+ return last_end;
}
+
+ last_end = item-start_in_dw + align(item-size_in_dw,
ITEM_ALIGNMENT);
}
if (pool-size_in_dw - last_end size_in_dw) {
@@ -226,7 +224,6 @@ void compute_memory_shadow(struct compute_memory_pool*
pool,
int compute_memory_finalize_pending(struct compute_memory_pool* pool,
struct pipe_context * pipe)
{
- struct compute_memory_item *pending_list = NULL, *end_p = NULL;
struct compute_memory_item *item, *next;
int64_t allocated = 0;
@@ -244,45 +241,16 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
item-size_in_dw, item-size_in_dw * 4);
}
- /* Search through the list of memory items in the pool */
+ /* Calculate the total allocated size */
for (item = pool-item_list; item; item = next) {
next = item-next;
+ allocated += align(item-size_in_dw, ITEM_ALIGNMENT);
+ }
- /* Check if the item is pending. */
- if (item-start_in_dw == -1) {
- /* It is pending, so add it to the pending_list... */
- if (end_p) {
- end_p-next = item;
- }
- else {
- pending_list = item;
- }
-
- /* ... and then remove it from the item list. */
- if (item-prev) {
- item-prev-next = next;
- }
- else {
- pool-item_list = next;
- }
-
- if (next) {
- next-prev = item-prev;
- }
-
- /* This sequence makes the item be at the end of the
list */
- item-prev = end_p;
- item-next = NULL;
- end_p = item;
-
- /* Update the amount of space we will need to allocate.
*/
- unallocated += item-size_in_dw+1024;
- }
- else {
- /* The item is not pending, so update the amount of
space
- * that has already been allocated. */
- allocated += item-size_in_dw;
- }
+ /* Calculate the total unallocated size */
+ for (item = pool-unallocated_list; item; item = next) {
+ next = item-next;
+ unallocated += align(item-size_in_dw, ITEM_ALIGNMENT);
}
/* If we require more space than the size of the pool, then grow the
@@ -302,15 +270,15 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
* In this case, there are 300 units of free space in the pool, but
* they aren't contiguous, so it will be impossible to allocate Item D.
*/
- if (pool-size_in_dw allocated+unallocated) {
- err = compute_memory_grow_pool(pool, pipe,
allocated+unallocated);
+ if (pool-size_in_dw allocated + unallocated) {
+ err = compute_memory_grow_pool(pool, pipe, allocated +
unallocated);
if (err == -1)
return -1;
}
- /* Loop through all the pending items, allocate space for them and
- * add them back to the item_list. */
- for (item = pending_list; item; item = next) {
+ /* Loop through all the unallocated items, allocate space for them
+ * and add them to the item_list. */
+ for (item = pool-unallocated_list; item; item = next) {
next = item-next;
/* Search for free space in the pool for this
Re: [Mesa-dev] [PATCH] clover: Cache serialized binaries
On Sun, Jun 15, 2014 at 01:08:14PM +0200, Francisco Jerez wrote:
Tom Stellard thomas.stell...@amd.com writes:
We were serializing the binaries once when clGetProgramInfo was called
with CL_PROGRAM_BINARY_SIZES and then again when it was called with
CL_PROGRAM_BINARIES. This was slowing down some OpenCV tests which were
building binary kernel caches.
This improves the run-time of OpenCV's OCL_ImgProc/CvtColor8u.*
test from 7 minutes to 1 minute.
---
Can you give the attached two patches a try? I'm curious to see if they
have a comparable effect -- If they do I'd prefer to fix the underlying
object rather than caching binaries in serialized form.
Thanks.
[...]
These patches improve performance even more. Now it only takes 10 seconds to
run the tests instead of 7 minutes.
For both patches:
Tested-by: Tom Stellard thomas.stell...@amd.com
From a500126213b073793184b0b6f170a58229340778 Mon Sep 17 00:00:00 2001
From: Francisco Jerez curroje...@riseup.net
Date: Sat, 14 Jun 2014 20:53:35 +0200
Subject: [PATCH 1/2] clover: Optimize module serialization for vectors of
fundamental types.
---
src/gallium/state_trackers/clover/core/module.cpp | 23
++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/module.cpp
b/src/gallium/state_trackers/clover/core/module.cpp
index 3e3ad99..41de734 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -69,7 +69,9 @@ namespace {
/// (De)serialize a vector.
templatetypename T
- struct _serializercompat::vectorT {
+ struct _serializercompat::vectorT,
+ typename std::enable_if
+ !std::is_scalarT::value::type {
static void
proc(compat::ostream os, const compat::vectorT v) {
_procuint32_t(os, v.size());
@@ -87,6 +89,25 @@ namespace {
}
};
+ templatetypename T
+ struct _serializercompat::vectorT,
+ typename std::enable_if
+ std::is_scalarT::value::type {
+ static void
+ proc(compat::ostream os, const compat::vectorT v) {
+ _procuint32_t(os, v.size());
+ os.write(reinterpret_castconst char *(v.begin()),
+ v.size() * sizeof(T));
+ }
+
+ static void
+ proc(compat::istream is, compat::vectorT v) {
+ v.reserve(_procuint32_t(is));
+ is.read(reinterpret_castchar *(v.begin()),
+ v.size() * sizeof(T));
+ }
+ };
+
/// (De)serialize a module::section.
template
struct _serializermodule::section {
--
1.9.2
From 1267038c2b0621dddc3d5c7718eed7ef2beb111b Mon Sep 17 00:00:00 2001
From: Francisco Jerez curroje...@riseup.net
Date: Sat, 14 Jun 2014 21:03:02 +0200
Subject: [PATCH 2/2] clover: Calculate the serialized size of a module
efficiently.
---
src/gallium/state_trackers/clover/api/program.cpp | 5 +---
src/gallium/state_trackers/clover/core/module.cpp | 32
+++
src/gallium/state_trackers/clover/core/module.hpp | 1 +
3 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index fedc91d..a14baa3 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -190,10 +190,7 @@ clGetProgramInfo(cl_program d_prog, cl_program_info
param,
case CL_PROGRAM_BINARY_SIZES:
buf.as_vectorsize_t() = map([](const device dev) {
-compat::ostream::buffer_t bin;
-compat::ostream s(bin);
-prog.binary(dev).serialize(s);
-return bin.size();
+return prog.binary(dev).size();
},
prog.devices());
break;
diff --git a/src/gallium/state_trackers/clover/core/module.cpp
b/src/gallium/state_trackers/clover/core/module.cpp
index 41de734..55ed91a 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -52,6 +52,13 @@ namespace {
return x;
}
+ /// Calculate the size of the specified object.
+ templatetypename T
+ void
+ _proc(module::size_t sz, const T x) {
+ _serializerT::proc(sz, x);
+ }
+
/// (De)serialize a scalar value.
templatetypename T
struct _serializerT, typename std::enable_if
@@ -65,6 +72,11 @@ namespace {
proc(compat::istream is, T x) {
is.read(reinterpret_castchar *(x), sizeof(x));
}
+
+ static void
+ proc(module::size_t sz, const T x) {
+ sz += sizeof(x);
+ }
};
/// (De)serialize a vector.
@@ -87,6 +99,14 @@ namespace {
for (size_t i = 0; i v.size(); i++)
new(v[i]) T(_procT(is));
}
+
+
Re: [Mesa-dev] [PATCH 4/9] r600g/compute: only move to the pool the buffers marked for promoting
On Fri, Jun 13, 2014 at 10:35:33PM +0200, Bruno Jiménez wrote:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/compute_memory_pool.c | 140
+++--
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
2 files changed, 87 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 5a5ef12..1da4609 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -229,8 +229,6 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t allocated = 0;
int64_t unallocated = 0;
- int64_t start_in_dw = 0;
-
int err = 0;
COMPUTE_DBG(pool-screen, * compute_memory_finalize_pending()\n);
@@ -247,10 +245,12 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
allocated += align(item-size_in_dw, ITEM_ALIGNMENT);
}
- /* Calculate the total unallocated size */
+ /* Calculate the total unallocated size of the items that
+ * will be promoted to the pool */
for (item = pool-unallocated_list; item; item = next) {
next = item-next;
- unallocated += align(item-size_in_dw, ITEM_ALIGNMENT);
+ if (item-status ITEM_FOR_PROMOTING)
+ unallocated += align(item-size_in_dw, ITEM_ALIGNMENT);
}
/* If we require more space than the size of the pool, then grow the
@@ -276,83 +276,107 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
return -1;
}
- /* Loop through all the unallocated items, allocate space for them
- * and add them to the item_list. */
+ /* Loop through all the unallocated items, check if they are marked
+ * for promoting, allocate space for them and add them to the
item_list. */
for (item = pool-unallocated_list; item; item = next) {
next = item-next;
- /* Search for free space in the pool for this item. */
- while ((start_in_dw=compute_memory_prealloc_chunk(pool,
- item-size_in_dw)) == -1) {
- int64_t need = item-size_in_dw+2048 -
- (pool-size_in_dw - allocated);
-
- if (need 0) {
- need = pool-size_in_dw / 10;
- }
+ if (item-status ITEM_FOR_PROMOTING) {
+ err = compute_memory_promote_item(pool, item, pipe,
allocated);
+ item-status ^= ITEM_FOR_PROMOTING;
- need = align(need, ITEM_ALIGNMENT);
-
- err = compute_memory_grow_pool(pool,
- pipe,
- pool-size_in_dw + need);
+ allocated += align(item-size_in_dw, ITEM_ALIGNMENT);
if (err == -1)
return -1;
}
- COMPUTE_DBG(pool-screen, + Found space for Item %p id = %u
+ }
+
+ return 0;
+}
+
+int compute_memory_promote_item(struct compute_memory_pool *pool,
+ struct compute_memory_item *item, struct pipe_context *pipe,
+ int64_t allocated)
+{
+ int64_t start_in_dw;
+ int err = 0;
+
+ /* Search for free space in the pool for this item. */
+ while ((start_in_dw=compute_memory_prealloc_chunk(pool,
+ item-size_in_dw)) == -1) {
+ int64_t need = item-size_in_dw + 2048 -
+ (pool-size_in_dw - allocated);
+
+ if (need 0) {
+ need = pool-size_in_dw / 10;
+ }
+
+ need = align(need, ITEM_ALIGNMENT);
+
+ err = compute_memory_grow_pool(pool,
+ pipe,
+ pool-size_in_dw + need);
+
+ if (err == -1)
+ return -1;
+ }
+ 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,
item-size_in_dw, item-size_in_dw * 4);
- item-start_in_dw = start_in_dw;
- item-next = NULL;
- item-prev = NULL;
-
- if (pool-item_list) {
- struct compute_memory_item *pos;
-
- pos = compute_memory_postalloc_chunk(pool, start_in_dw);
- if (pos) {
- item-prev = pos;
- item-next = pos-next;
- pos-next = item;
-
Re: [Mesa-dev] [PATCH 5/9] r600g/compute: avoid problems when promoting items mapped for reading
On Fri, Jun 13, 2014 at 10:35:34PM +0200, Bruno Jiménez wrote:
Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.
With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/compute_memory_pool.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1da4609..e1f9c88 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -369,10 +369,16 @@ int compute_memory_promote_item(struct
compute_memory_pool *pool,
0, (struct pipe_box) {.width = item-size_in_dw * 4,
.height = 1, .depth = 1});
- pool-screen-b.b.resource_destroy(
- (struct pipe_screen *)pool-screen,
- (struct pipe_resource *)item-real_buffer);
- item-real_buffer = NULL;
+ /* We check if the item is mapped for reading.
+ * In this case, we need to keep the temporary buffer 'alive'
+ * because it is possible to keep a map active for reading
+ * while a kernel (that reads from it) executes */
+ if (!(item-status ITEM_MAPPED_FOR_READING)) {
+ pool-screen-b.b.resource_destroy(
+ (struct pipe_screen *)pool-screen,
+ (struct pipe_resource *)item-real_buffer);
+ item-real_buffer = NULL;
+ }
return 0;
}
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/9] r600g/compute: implement compute_memory_demote_item
On Fri, Jun 13, 2014 at 10:35:35PM +0200, Bruno Jiménez wrote:
This function will be used when we want to map an item
that it's already in the pool.
---
src/gallium/drivers/r600/compute_memory_pool.c | 45
++
src/gallium/drivers/r600/compute_memory_pool.h | 3 ++
2 files changed, 48 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index e1f9c88..624b50d 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -383,6 +383,51 @@ int compute_memory_promote_item(struct
compute_memory_pool *pool,
return 0;
}
+void compute_memory_demote_item(struct compute_memory_pool *pool,
+ struct compute_memory_item *item, struct pipe_context *pipe)
+{
+ /* First, we remove the item from the item_list */
+ if (item-prev == NULL)
+ pool-item_list = item-next;
+ else
+ item-prev-next = item-next;
+
+ if (item-next != NULL)
+ item-next-prev = item-prev;
+
+
+ /* Now we add it to the beginning of the unallocated list
+ * NOTE: we could also add it to the end, but this is easier */
+ item-next = NULL;
+ item-prev = NULL;
+ if (pool-unallocated_list) {
+ item-next = pool-unallocated_list;
+ item-next-prev = item;
+ pool-unallocated_list = item;
+ }
+ else
+ pool-unallocated_list = item;
+
+ /* We check if the intermediate buffer exists, and if it
+ * doesn't, we create it again */
+ if (item-real_buffer == NULL) {
+ item-real_buffer = (struct
r600_resource*)r600_compute_buffer_alloc_vram(
+ pool-screen, item-size_in_dw * 4);
+ }
+
+ /* We transfer the memory from the item in the pool to the
+ * temporary buffer */
+ ((struct r600_context *)pipe)-b.b.resource_copy_region(pipe,
+ (struct pipe_resource *)item-real_buffer,
+ 0, 0, 0, 0,
+ (struct pipe_resource *)pool-bo,
+ 0, (struct pipe_box) { .x = item-start_in_dw * 4,
+ .width = item-size_in_dw * 4, .height = 1, .depth = 1});
Could you use temporary variables, so we don't need so many casts.
+
+ /* Remember to mark the buffer as 'pending' by setting start_in_dw to
-1 */
+ item-start_in_dw = -1;
+}
+
void compute_memory_free(struct compute_memory_pool* pool, int64_t id)
{
struct compute_memory_item *item, *next;
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index 6a45fb2..1eb60da 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.h
+++ b/src/gallium/drivers/r600/compute_memory_pool.h
@@ -85,6 +85,9 @@ int compute_memory_promote_item(struct compute_memory_pool
*pool,
struct compute_memory_item *item, struct pipe_context *pipe,
int64_t allocated);
+void compute_memory_demote_item(struct compute_memory_pool *pool,
+ struct compute_memory_item *item, struct pipe_context *pipe);
+
void compute_memory_free(struct compute_memory_pool* pool, int64_t id);
struct compute_memory_item* compute_memory_alloc(struct compute_memory_pool*
pool, int64_t size_in_dw); ///Creates pending allocations
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] gallium: implement ARB_texture_query_levels
From: Marek Olšák marek.ol...@amd.com
The extension is always supported if GLSL 1.30 is supported.
Softpipe and llvmpipe support is also added (trivial).
Radeon and nouveau support is already done.
---
docs/GL3.txt| 2 +-
docs/relnotes/10.3.html | 1 +
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 +-
src/gallium/docs/source/tgsi.rst| 6 +-
src/gallium/drivers/softpipe/sp_tex_sample.c| 3 +++
src/mesa/state_tracker/st_extensions.c | 1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 25 ++---
7 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 237f60c..214300c 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -172,7 +172,7 @@ GL 4.3:
GL_ARB_shader_storage_buffer_object not started
GL_ARB_stencil_texturing DONE (i965/gen8+, nv50,
nvc0, r600, radeonsi)
GL_ARB_texture_buffer_range DONE (nv50, nvc0, i965,
r600, radeonsi)
- GL_ARB_texture_query_levels DONE (i965)
+ GL_ARB_texture_query_levels DONE (all drivers that
support GLSL 1.30)
GL_ARB_texture_storage_multisample DONE (all drivers that
support GL_ARB_texture_multisample)
GL_ARB_texture_view DONE (i965)
GL_ARB_vertex_attrib_binding DONE (all drivers)
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index 36e5ea7..773c73c 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -50,6 +50,7 @@ Note: some of the new features are only available with
certain drivers.
liGL_ARB_stencil_texturing on nv50, nvc0, r600, and radeonsi/li
liGL_ARB_texture_cube_map_array on radeonsi/li
liGL_ARB_texture_gather on radeonsi/li
+liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi,
softpipe/li
/ul
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 0eaa020..3d7df3e 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -2445,7 +2445,7 @@ emit_size_query( struct lp_build_tgsi_soa_context *bld,
bld-bld_base.base.gallivm,
bld-bld_base.int_bld.type,
unit, pipe_target,
- is_sviewinfo,
+ TRUE,
lod_property,
explicit_lod,
sizes_out);
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 2ca3c3b..2130e08 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -964,7 +964,9 @@ XXX doesn't look like most of the opcodes really belong
here.
As per NV_gpu_program4, retrieve the dimensions of the texture depending on
the target. For 1D (width), 2D/RECT/CUBE (width, height), 3D (width, height,
- depth), 1D array (width, layers), 2D array (width, height, layers)
+ depth), 1D array (width, layers), 2D array (width, height, layers).
+ Also return the number of accessible levels (last_level - first_level + 1)
+ in W.
.. math::
@@ -976,6 +978,8 @@ XXX doesn't look like most of the opcodes really belong
here.
dst.z = texture\_depth(unit, lod)
+ dst.w = texture\_levels(unit)
+
.. opcode:: TG4 - Texture Gather
As per ARB_texture_gather, gathers the four texels to be used in a bi-linear
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 274e56b..6d97664 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -2911,6 +2911,9 @@ sp_get_dims(struct sp_sampler_view *sp_sview, int level,
if (level view-u.tex.last_level)
return;
+ if (texture-target != PIPE_BUFFER)
+ dims[3] = view-u.tex.last_level - view-u.tex.first_level + 1;
+
dims[0] = u_minify(texture-width0, level);
switch(texture-target) {
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 94be2b8..921c78d 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -633,6 +633,7 @@ void st_init_extensions(struct st_context *st)
ctx-Extensions.ARB_shading_language_packing = GL_TRUE;
ctx-Extensions.OES_depth_texture_cube_map = GL_TRUE;
ctx-Extensions.ARB_shading_language_420pack = GL_TRUE;
+ ctx-Extensions.ARB_texture_query_levels = GL_TRUE;
if (!st-options.disable_shader_bit_encoding) {
ctx-Extensions.ARB_shader_bit_encoding = GL_TRUE;
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index
[Mesa-dev] [PATCH 1/3] st/mesa: handle array textures in st_texture_image_copy
From: Dave Airlie airl...@redhat.com
Marek: also handle cube arrays
Signed-off-by: Marek Olšák marek.ol...@amd.com
---
src/mesa/state_tracker/st_texture.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index 92035e8..c148821 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -394,6 +394,14 @@ st_texture_image_copy(struct pipe_context *pipe,
src_box.width = width;
src_box.height = height;
src_box.depth = 1;
+
+ if (src-target == PIPE_TEXTURE_1D_ARRAY ||
+ src-target == PIPE_TEXTURE_2D_ARRAY ||
+ src-target == PIPE_TEXTURE_CUBE_ARRAY) {
+ face = 0;
+ depth = src-array_size;
+ }
+
/* Loop over 3D image slices */
/* could (and probably should) use true 3d box here -
but drivers can't quite handle it yet */
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] st/mesa: set sampler_view::last_level correctly
From: Marek Olšák marek.ol...@amd.com
It was set to pipe_resource::last_level and _MaxLevel was embedded in max_lod,
that's why it worked for ordinary texturing. However, min_lod doesn't have
any effect on texelFetch and textureQueryLevels, so we must still set
last_level correctly.
---
src/mesa/state_tracker/st_atom_sampler.c | 7 ++-
src/mesa/state_tracker/st_atom_texture.c | 11 ++-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
index 3929251..17b536b 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -160,11 +160,8 @@ convert_sampler(struct st_context *st,
sampler-lod_bias = ctx-Texture.Unit[texUnit].LodBias + msamp-LodBias;
- sampler-min_lod = CLAMP(msamp-MinLod,
-0.0f,
-(GLfloat) texobj-MaxLevel - texobj-BaseLevel);
- sampler-max_lod = MIN2((GLfloat) texobj-MaxLevel - texobj-BaseLevel,
- msamp-MaxLod);
+ sampler-min_lod = MAX2(msamp-MinLod, 0.0f);
+ sampler-max_lod = msamp-MaxLod;
if (sampler-max_lod sampler-min_lod) {
/* The GL spec doesn't seem to specify what to do in this case.
* Swap the values.
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index e2d26ee..65ab2b1 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -212,6 +212,12 @@ check_sampler_swizzle(const struct st_texture_object
*stObj,
}
+static unsigned last_level(struct st_texture_object *stObj)
+{
+ return MIN2(stObj-base._MaxLevel, stObj-pt-last_level);
+}
+
+
static struct pipe_sampler_view *
st_create_texture_sampler_view_from_stobj(struct pipe_context *pipe,
struct st_texture_object *stObj,
@@ -244,6 +250,8 @@ st_create_texture_sampler_view_from_stobj(struct
pipe_context *pipe,
templ.u.buf.last_element = f + (n - 1);
} else {
templ.u.tex.first_level = stObj-base.BaseLevel;
+ templ.u.tex.last_level = last_level(stObj);
+ assert(templ.u.tex.first_level = templ.u.tex.last_level);
}
if (swizzle != SWIZZLE_NOOP) {
@@ -279,7 +287,8 @@ st_get_texture_sampler_view_from_stobj(struct st_context
*st,
if (*sv) {
if (check_sampler_swizzle(stObj, *sv) ||
(format != (*sv)-format) ||
- stObj-base.BaseLevel != (*sv)-u.tex.first_level) {
+ stObj-base.BaseLevel != (*sv)-u.tex.first_level ||
+ last_level(stObj) != (*sv)-u.tex.last_level) {
pipe_sampler_view_reference(sv, NULL);
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] r600g/compute: map only against intermediate buffers
On Fri, Jun 13, 2014 at 10:35:36PM +0200, Bruno Jiménez wrote:
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
---
src/gallium/drivers/r600/evergreen_compute.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 9123a40..e5967b5 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -970,14 +970,12 @@ void *r600_compute_global_transfer_map(
struct pipe_resource *dst;
unsigned offset = box-x;
- if (buffer-chunk-real_buffer) {
- dst = (struct pipe_resource*)buffer-chunk-real_buffer;
- }
- else {
- dst = (struct pipe_resource*)buffer-chunk-pool-bo;
- offset += (buffer-chunk-start_in_dw * 4);
+ if (buffer-chunk-start_in_dw != -1) {
We could use the is_item_in_pool() helper here that I mentioned in an
earlier patch.
+ compute_memory_demote_item(pool, buffer-chunk, ctx_);
}
+ dst = (struct pipe_resource*)buffer-chunk-real_buffer;
+
if (usage PIPE_TRANSFER_READ)
buffer-chunk-status |= ITEM_MAPPED_FOR_READING;
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: pass ARB_conservative_depth parameters to the hardware
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/radeonsi/si_shader.c | 21 -
src/gallium/drivers/radeonsi/si_shader.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c | 4
src/gallium/drivers/radeonsi/sid.h | 4
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 4ed5906..4c23090 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2745,10 +2745,29 @@ int si_pipe_shader_create(
}
break;
}
- case TGSI_PROCESSOR_FRAGMENT:
+ case TGSI_PROCESSOR_FRAGMENT: {
+ int i;
+
si_shader_ctx.radeon_bld.load_input = declare_input_fs;
bld_base-emit_epilogue = si_llvm_emit_fs_epilogue;
+ shader-shader.ps_conservative_z = V_02880C_EXPORT_ANY_Z;
+
+ for (i = 0; i shader_info.num_properties; i++) {
+ switch (shader_info.properties[i].name) {
+ case TGSI_PROPERTY_FS_DEPTH_LAYOUT:
+ switch (shader_info.properties[i].data[0]) {
+ case TGSI_FS_DEPTH_LAYOUT_GREATER:
+ shader-shader.ps_conservative_z =
V_02880C_EXPORT_GREATER_THAN_Z;
+ break;
+ case TGSI_FS_DEPTH_LAYOUT_LESS:
+ shader-shader.ps_conservative_z =
V_02880C_EXPORT_LESS_THAN_Z;
+ break;
+ }
+ break;
+ }
+ }
break;
+ }
default:
assert(!Unsupported shader type);
return -1;
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers/radeonsi/si_shader.h
index 6609788..81997c0 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -138,6 +138,7 @@ struct si_shader {
unsignedgs_input_prim;
unsignedgs_output_prim;
unsignedgs_max_out_vertices;
+ unsignedps_conservative_z;
unsignednparam;
booluses_kill;
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 52ecf26..01564eb 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -269,6 +269,10 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
if (shader-shader.uses_kill || shader-key.ps.alpha_func !=
PIPE_FUNC_ALWAYS)
db_shader_control |= S_02880C_KILL_ENABLE(1);
+ if (sctx-b.chip_class = CIK)
+ db_shader_control |=
+
S_02880C_CONSERVATIVE_Z_EXPORT(shader-shader.ps_conservative_z);
+
spi_ps_in_control = S_0286D8_NUM_INTERP(shader-shader.nparam) |
S_0286D8_BC_OPTIMIZE_DISABLE(1);
diff --git a/src/gallium/drivers/radeonsi/sid.h
b/src/gallium/drivers/radeonsi/sid.h
index 558da10..e3f788e 100644
--- a/src/gallium/drivers/radeonsi/sid.h
+++ b/src/gallium/drivers/radeonsi/sid.h
@@ -6712,6 +6712,10 @@
#define S_02880C_CONSERVATIVE_Z_EXPORT(x) (((x)
0x03) 13)
#define G_02880C_CONSERVATIVE_Z_EXPORT(x) (((x)
13) 0x03)
#define C_02880C_CONSERVATIVE_Z_EXPORT
0x9FFF
+#define V_02880C_EXPORT_ANY_Z 0
+#define V_02880C_EXPORT_LESS_THAN_Z 1
+#define V_02880C_EXPORT_GREATER_THAN_Z 2
+#define V_02880C_EXPORT_RESERVED3
/* */
#define R_028810_PA_CL_CLIP_CNTL
0x028810
#define S_028810_UCP_ENA_0(x) (((x)
0x1) 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 8/9] r600g/compute: add util functions to add and remove items from lists
On Fri, Jun 13, 2014 at 10:35:37PM +0200, Bruno Jiménez wrote:
---
src/gallium/drivers/r600/compute_memory_pool.c | 158
-
1 file changed, 78 insertions(+), 80 deletions(-)
There are double linked list helper functions in gallium util, which we
should use rather than writing our own. See auxiliary/util/u_double_list.h
I would recommend leaving these wrappers, but replacing the implementation
with the gallium helpers. Then when you are done, you can remove any wrappers
which map 1 to 1 to a gallium helper.
-Tom
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 624b50d..26b9f98 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -43,6 +43,73 @@
#include inttypes.h
#define ITEM_ALIGNMENT 1024
+
+static inline void list_add_item_front(struct compute_memory_item **list,
+struct compute_memory_item *item)
+{
+ if (*list != NULL) {
+ item-next = *list;
+ (*list)-prev = item;
+ }
+ else {
+ item-next = NULL;
+ }
+
+ *list = item;
+ item-prev = NULL;
+}
+
+static inline void list_add_item_tail(struct compute_memory_item **list,
+struct compute_memory_item *item)
+{
+ struct compute_memory_item *last_item = NULL;
+
+ if (*list != NULL) {
+ for (last_item = *list; last_item-next != NULL; last_item =
last_item-next);
+
+ last_item-next = item;
+ item-prev = last_item;
+ }
+ else {
+ *list = item;
+ item-prev = NULL;
+ }
+
+ item-next = NULL;
+}
+
+static inline void list_add_item_after(struct compute_memory_item **list,
+ struct compute_memory_item *item, struct compute_memory_item
*pos)
+{
+ if (pos == NULL) {
+ list_add_item_front(list, item);
+ }
+ else {
+ if (pos-next != NULL) {
+ pos-next-prev = item;
+ }
+
+ item-prev = pos;
+ item-next = pos-next;
+ pos-next = item;
+ }
+}
+
+static inline void list_remove_item(struct compute_memory_item **list,
+ struct compute_memory_item *item)
+{
+ if (item-prev == NULL) {
+ *list = item-next;
+ }
+ else {
+ item-prev-next = item-next;
+ }
+
+ if (item-next != NULL) {
+ item-next-prev = item-prev;
+ }
+}
+
/**
* Creates a new pool
*/
@@ -299,6 +366,7 @@ int compute_memory_promote_item(struct
compute_memory_pool *pool,
struct compute_memory_item *item, struct pipe_context *pipe,
int64_t allocated)
{
+ struct compute_memory_item *pos;
int64_t start_in_dw;
int err = 0;
@@ -327,40 +395,12 @@ int compute_memory_promote_item(struct
compute_memory_pool *pool,
item-size_in_dw, item-size_in_dw * 4);
/* Remove the item from the unallocated list */
- if (item-prev == NULL)
- pool-unallocated_list = item-next;
- else
- item-prev-next = item-next;
-
- if (item-next != NULL)
- item-next-prev = item-prev;
+ list_remove_item(pool-unallocated_list, item);
+ /* Add it back to the item_list */
+ pos = compute_memory_postalloc_chunk(pool, start_in_dw);
+ list_add_item_after(pool-item_list, item, pos);
item-start_in_dw = start_in_dw;
- item-next = NULL;
- item-prev = NULL;
-
- if (pool-item_list) {
- struct compute_memory_item *pos;
-
- pos = compute_memory_postalloc_chunk(pool, start_in_dw);
- if (pos) {
- item-prev = pos;
- item-next = pos-next;
- pos-next = item;
- if (item-next) {
- item-next-prev = item;
- }
- } else {
- /* Add item to the front of the list */
- item-next = pool-item_list;
- item-prev = pool-item_list-prev;
- pool-item_list-prev = item;
- pool-item_list = item;
- }
- }
- else {
- pool-item_list = item;
- }
((struct r600_context *)pipe)-b.b.resource_copy_region(pipe,
(struct pipe_resource *)pool-bo,
@@ -387,26 +427,11 @@ void compute_memory_demote_item(struct
compute_memory_pool *pool,
struct compute_memory_item *item, struct pipe_context *pipe)
{
/* First, we remove the item from the item_list */
- if (item-prev == NULL)
- pool-item_list = item-next;
- else
- item-prev-next = item-next;
-
- if (item-next != NULL)
- item-next-prev = item-prev;
-
+
Re: [Mesa-dev] [PATCH 9/9] r600g/compute: avoid demoting items when reading/writing
On Fri, Jun 13, 2014 at 10:35:38PM +0200, Bruno Jiménez wrote:
All the *Enqueue* functions that read/write buffers (except
clEnqueueCopyBuffer) would map the associated resource, making
it to be demoted if it was in the pool.
But we possitively know that this transfer will end before
positively
any kernel is launched, so there's no need to demote it.
NOTE: As a proof of concept I have used PIPE_TRANSFER_MAP_DIRECTLY,
but it collides with OpenCL 1.2 CL_MAP_WRITE_INVALIDATE_REGION,
so we will have to find another bitfield to use.
---
src/gallium/drivers/r600/evergreen_compute.c| 20 +++-
src/gallium/state_trackers/clover/api/transfer.cpp | 4 ++--
src/gallium/state_trackers/clover/core/resource.cpp | 2 ++
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index e5967b5..794cbe6 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -967,18 +967,28 @@ void *r600_compute_global_transfer_map(
struct r600_resource_global* buffer =
(struct r600_resource_global*)resource;
- struct pipe_resource *dst;
+ struct pipe_resource *dst =
+ (struct pipe_resource *) buffer-chunk-real_buffer;
unsigned offset = box-x;
+ /* If the item is already in the pool, and we are going
+ * to read/write it, map it directly without demoting it */
if (buffer-chunk-start_in_dw != -1) {
- compute_memory_demote_item(pool, buffer-chunk, ctx_);
+ if (usage PIPE_TRANSFER_MAP_DIRECTLY) {
+ dst = (struct pipe_resource *) buffer-chunk-pool-bo;
+ offset += (buffer-chunk-start_in_dw * 4);
+ }
+ else {
+ compute_memory_demote_item(pool, buffer-chunk, ctx_);
+ dst = (struct pipe_resource *)
buffer-chunk-real_buffer;
+ }
}
- dst = (struct pipe_resource*)buffer-chunk-real_buffer;
-
- if (usage PIPE_TRANSFER_READ)
+ if ((usage PIPE_TRANSFER_READ) !(usage
PIPE_TRANSFER_MAP_DIRECTLY))
buffer-chunk-status |= ITEM_MAPPED_FOR_READING;
+ usage = ~PIPE_TRANSFER_MAP_DIRECTLY;
+
COMPUTE_DBG(rctx-screen, * r600_compute_global_transfer_map()\n
level = %u, usage = %u, box(x = %u, y = %u, z = %u
width = %u, height = %u, depth = %u)\n, level, usage,
diff --git a/src/gallium/state_trackers/clover/api/transfer.cpp
b/src/gallium/state_trackers/clover/api/transfer.cpp
index 404ceb0..032542e 100644
--- a/src/gallium/state_trackers/clover/api/transfer.cpp
+++ b/src/gallium/state_trackers/clover/api/transfer.cpp
The changes to clover should be split out into a separate patch.
@@ -174,8 +174,8 @@ namespace {
static mapping
get(command_queue q, T obj, cl_map_flags flags,
size_t offset, size_t size) {
- return { q, obj-resource(q), flags, true,
- {{ offset }}, {{ size, 1, 1 }} };
+ return { q, obj-resource(q), flags | PIPE_TRANSFER_MAP_DIRECTLY,
+ true, {{ offset }}, {{ size, 1, 1 }} };
}
};
diff --git a/src/gallium/state_trackers/clover/core/resource.cpp
b/src/gallium/state_trackers/clover/core/resource.cpp
index 7b8a40a..bda9847 100644
--- a/src/gallium/state_trackers/clover/core/resource.cpp
+++ b/src/gallium/state_trackers/clover/core/resource.cpp
@@ -174,6 +174,8 @@ mapping::mapping(command_queue q, resource r,
pctx(q.pipe) {
unsigned usage = ((flags CL_MAP_WRITE ? PIPE_TRANSFER_WRITE : 0 ) |
(flags CL_MAP_READ ? PIPE_TRANSFER_READ : 0 ) |
+ (flags PIPE_TRANSFER_MAP_DIRECTLY ?
+ PIPE_TRANSFER_MAP_DIRECTLY : 0 ) |
(!blocking ? PIPE_TRANSFER_UNSYNCHRONIZED : 0));
p = pctx-transfer_map(pctx, r.pipe, 0, usage,
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79949] [DRI3] GTK+ Programs Not Updating Correctly
https://bugs.freedesktop.org/show_bug.cgi?id=79949 Alberto González luis6...@yahoo.com changed: What|Removed |Added CC||luis6...@yahoo.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] R600/SI: add Gather4 intrinsics (v2)
On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This adds a new type of intrinsic and SDNode: SampleRaw.
All fields of the MIMG opcodes are exposed and can be set by Mesa,
even DMASK. All GATHER4 variants are added and there are a lot of them.
v2: document DMASK behavior
---
lib/Target/R600/AMDGPUISelLowering.cpp | 24 +
lib/Target/R600/AMDGPUISelLowering.h | 31 +++
lib/Target/R600/SIISelLowering.cpp | 72 +
lib/Target/R600/SIISelLowering.h | 2 +
lib/Target/R600/SIInstrInfo.td | 91
lib/Target/R600/SIInstructions.td | 96
+-
lib/Target/R600/SIIntrinsics.td| 48 +
7 files changed, 340 insertions(+), 24 deletions(-)
diff --git a/lib/Target/R600/AMDGPUISelLowering.cpp
b/lib/Target/R600/AMDGPUISelLowering.cpp
index 849f169..359161c 100644
--- a/lib/Target/R600/AMDGPUISelLowering.cpp
+++ b/lib/Target/R600/AMDGPUISelLowering.cpp
@@ -1542,6 +1542,30 @@ const char*
AMDGPUTargetLowering::getTargetNodeName(unsigned Opcode) const {
NODE_NAME_CASE(SAMPLEB)
NODE_NAME_CASE(SAMPLED)
NODE_NAME_CASE(SAMPLEL)
+ NODE_NAME_CASE(GATHER4)
+ NODE_NAME_CASE(GATHER4_CL)
+ NODE_NAME_CASE(GATHER4_L)
+ NODE_NAME_CASE(GATHER4_B)
+ NODE_NAME_CASE(GATHER4_B_CL)
+ NODE_NAME_CASE(GATHER4_LZ)
+ NODE_NAME_CASE(GATHER4_C)
+ NODE_NAME_CASE(GATHER4_C_CL)
+ NODE_NAME_CASE(GATHER4_C_L)
+ NODE_NAME_CASE(GATHER4_C_B)
+ NODE_NAME_CASE(GATHER4_C_B_CL)
+ NODE_NAME_CASE(GATHER4_C_LZ)
+ NODE_NAME_CASE(GATHER4_O)
+ NODE_NAME_CASE(GATHER4_CL_O)
+ NODE_NAME_CASE(GATHER4_L_O)
+ NODE_NAME_CASE(GATHER4_B_O)
+ NODE_NAME_CASE(GATHER4_B_CL_O)
+ NODE_NAME_CASE(GATHER4_LZ_O)
+ NODE_NAME_CASE(GATHER4_C_O)
+ NODE_NAME_CASE(GATHER4_C_CL_O)
+ NODE_NAME_CASE(GATHER4_C_L_O)
+ NODE_NAME_CASE(GATHER4_C_B_O)
+ NODE_NAME_CASE(GATHER4_C_B_CL_O)
+ NODE_NAME_CASE(GATHER4_C_LZ_O)
You don't need to add new SDNodes for all these instructions, you can just use
the intrinsic directly in the pattern.
The only reason to add SDNodes, is if there are optimizations / special lowering
we can do for these instructions.
NODE_NAME_CASE(STORE_MSKOR)
NODE_NAME_CASE(TBUFFER_STORE_FORMAT)
}
diff --git a/lib/Target/R600/AMDGPUISelLowering.h
b/lib/Target/R600/AMDGPUISelLowering.h
index d5d821d..a9af195 100644
--- a/lib/Target/R600/AMDGPUISelLowering.h
+++ b/lib/Target/R600/AMDGPUISelLowering.h
@@ -203,6 +203,37 @@ enum {
SAMPLEB,
SAMPLED,
SAMPLEL,
+
+ // Gather4 opcodes
+ GATHER4,
+ GATHER4_CL,
+ GATHER4_L,
+ GATHER4_B,
+ GATHER4_B_CL,
+ GATHER4_LZ,
+
+ GATHER4_C,
+ GATHER4_C_CL,
+ GATHER4_C_L,
+ GATHER4_C_B,
+ GATHER4_C_B_CL,
+ GATHER4_C_LZ,
+
+ GATHER4_O,
+ GATHER4_CL_O,
+ GATHER4_L_O,
+ GATHER4_B_O,
+ GATHER4_B_CL_O,
+ GATHER4_LZ_O,
+
+ GATHER4_C_O,
+ GATHER4_C_CL_O,
+ GATHER4_C_L_O,
+ GATHER4_C_B_O,
+ GATHER4_C_B_CL_O,
+ GATHER4_C_LZ_O,
+
+ // Nemory opcodes
FIRST_MEM_OPCODE_NUMBER = ISD::FIRST_TARGET_MEMORY_OPCODE,
STORE_MSKOR,
LOAD_CONSTANT,
diff --git a/lib/Target/R600/SIISelLowering.cpp
b/lib/Target/R600/SIISelLowering.cpp
index 1a861d4..909255d 100644
--- a/lib/Target/R600/SIISelLowering.cpp
+++ b/lib/Target/R600/SIISelLowering.cpp
@@ -688,6 +688,59 @@ SDValue SITargetLowering::LowerOperation(SDValue Op,
SelectionDAG DAG) const {
Op.getOperand(1),
Op.getOperand(2),
Op.getOperand(3));
+
+// Gather4 intrinsics
+case AMDGPUIntrinsic::SI_gather4:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_CL, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_l:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_L, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_b:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_B, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_b_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_B_CL, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_lz:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_LZ, Op, DAG);
+
+case AMDGPUIntrinsic::SI_gather4_c:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_CL, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_l:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_L, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_b:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_B, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_b_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_B_CL, Op, DAG);
+case
Re: [Mesa-dev] [PATCH 2/2] R600/SI: add tests for gather4
On Thu, Jun 12, 2014 at 02:11:11AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
LGTM.
---
test/CodeGen/R600/llvm.SI.gather4.ll | 508
+++
1 file changed, 508 insertions(+)
create mode 100644 test/CodeGen/R600/llvm.SI.gather4.ll
diff --git a/test/CodeGen/R600/llvm.SI.gather4.ll
b/test/CodeGen/R600/llvm.SI.gather4.ll
new file mode 100644
index 000..8402faa
--- /dev/null
+++ b/test/CodeGen/R600/llvm.SI.gather4.ll
@@ -0,0 +1,508 @@
+;RUN: llc %s -march=r600 -mcpu=verde -verify-machineinstrs | FileCheck %s
+
+;CHECK-LABEL: @gather4_v2
+;CHECK: IMAGE_GATHER4 {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4_v2() #0 {
+main_body:
+ %r = call 4 x float @llvm.SI.gather4.v2i32(2 x i32 undef, 32 x i8
undef, 16 x i8 undef, i32 1, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0, i32
0)
+ %r0 = extractelement 4 x float %r, i32 0
+ %r1 = extractelement 4 x float %r, i32 1
+ %r2 = extractelement 4 x float %r, i32 2
+ %r3 = extractelement 4 x float %r, i32 3
+ call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 1, float %r0,
float %r1, float %r2, float %r3)
+ ret void
+}
+
+;CHECK-LABEL: @gather4
+;CHECK: IMAGE_GATHER4 {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4() #0 {
+main_body:
+ %r = call 4 x float @llvm.SI.gather4.v4i32(4 x i32 undef, 32 x i8
undef, 16 x i8 undef, i32 1, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0, i32
0)
+ %r0 = extractelement 4 x float %r, i32 0
+ %r1 = extractelement 4 x float %r, i32 1
+ %r2 = extractelement 4 x float %r, i32 2
+ %r3 = extractelement 4 x float %r, i32 3
+ call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 1, float %r0,
float %r1, float %r2, float %r3)
+ ret void
+}
+
+;CHECK-LABEL: @gather4_cl
+;CHECK: IMAGE_GATHER4_CL {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4_cl() #0 {
+main_body:
+ %r = call 4 x float @llvm.SI.gather4.cl.v4i32(4 x i32 undef, 32 x i8
undef, 16 x i8 undef, i32 1, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0, i32
0)
+ %r0 = extractelement 4 x float %r, i32 0
+ %r1 = extractelement 4 x float %r, i32 1
+ %r2 = extractelement 4 x float %r, i32 2
+ %r3 = extractelement 4 x float %r, i32 3
+ call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 1, float %r0,
float %r1, float %r2, float %r3)
+ ret void
+}
+
+;CHECK-LABEL: @gather4_l
+;CHECK: IMAGE_GATHER4_L {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4_l() #0 {
+main_body:
+ %r = call 4 x float @llvm.SI.gather4.l.v4i32(4 x i32 undef, 32 x i8
undef, 16 x i8 undef, i32 1, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0, i32
0)
+ %r0 = extractelement 4 x float %r, i32 0
+ %r1 = extractelement 4 x float %r, i32 1
+ %r2 = extractelement 4 x float %r, i32 2
+ %r3 = extractelement 4 x float %r, i32 3
+ call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 1, float %r0,
float %r1, float %r2, float %r3)
+ ret void
+}
+
+;CHECK-LABEL: @gather4_b
+;CHECK: IMAGE_GATHER4_B {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4_b() #0 {
+main_body:
+ %r = call 4 x float @llvm.SI.gather4.b.v4i32(4 x i32 undef, 32 x i8
undef, 16 x i8 undef, i32 1, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0, i32
0)
+ %r0 = extractelement 4 x float %r, i32 0
+ %r1 = extractelement 4 x float %r, i32 1
+ %r2 = extractelement 4 x float %r, i32 2
+ %r3 = extractelement 4 x float %r, i32 3
+ call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 1, float %r0,
float %r1, float %r2, float %r3)
+ ret void
+}
+
+;CHECK-LABEL: @gather4_b_cl
+;CHECK: IMAGE_GATHER4_B_CL {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4_b_cl() #0 {
+main_body:
+ %r = call 4 x float @llvm.SI.gather4.b.cl.v4i32(4 x i32 undef, 32 x
i8 undef, 16 x i8 undef, i32 1, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0,
i32 0)
+ %r0 = extractelement 4 x float %r, i32 0
+ %r1 = extractelement 4 x float %r, i32 1
+ %r2 = extractelement 4 x float %r, i32 2
+ %r3 = extractelement 4 x float %r, i32 3
+ call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 1, float %r0,
float %r1, float %r2, float %r3)
+ ret void
+}
+
+;CHECK-LABEL: @gather4_b_cl_v8
+;CHECK: IMAGE_GATHER4_B_CL {{v\[[0-9]+:[0-9]+\]}}, 1, 0, 0, -1, 0, 0, 0, 0,
{{v\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}, {{s\[[0-9]+:[0-9]+\]}}
+define void @gather4_b_cl_v8() #0 {
+main_body:
+ %r = call 4 x float
Re: [Mesa-dev] [PATCH 3/3] gallium: implement ARB_texture_query_levels
Am 16.06.2014 17:02, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
The extension is always supported if GLSL 1.30 is supported.
Softpipe and llvmpipe support is also added (trivial).
Radeon and nouveau support is already done.
---
docs/GL3.txt| 2 +-
docs/relnotes/10.3.html | 1 +
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 +-
src/gallium/docs/source/tgsi.rst| 6 +-
src/gallium/drivers/softpipe/sp_tex_sample.c| 3 +++
src/mesa/state_tracker/st_extensions.c | 1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 25
++---
7 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 237f60c..214300c 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -172,7 +172,7 @@ GL 4.3:
GL_ARB_shader_storage_buffer_object not started
GL_ARB_stencil_texturing DONE (i965/gen8+,
nv50, nvc0, r600, radeonsi)
GL_ARB_texture_buffer_range DONE (nv50, nvc0,
i965, r600, radeonsi)
- GL_ARB_texture_query_levels DONE (i965)
+ GL_ARB_texture_query_levels DONE (all drivers
that support GLSL 1.30)
GL_ARB_texture_storage_multisample DONE (all drivers
that support GL_ARB_texture_multisample)
GL_ARB_texture_view DONE (i965)
GL_ARB_vertex_attrib_binding DONE (all drivers)
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index 36e5ea7..773c73c 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -50,6 +50,7 @@ Note: some of the new features are only available with
certain drivers.
liGL_ARB_stencil_texturing on nv50, nvc0, r600, and radeonsi/li
liGL_ARB_texture_cube_map_array on radeonsi/li
liGL_ARB_texture_gather on radeonsi/li
+liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi,
softpipe/li
/ul
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 0eaa020..3d7df3e 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -2445,7 +2445,7 @@ emit_size_query( struct lp_build_tgsi_soa_context *bld,
bld-bld_base.base.gallivm,
bld-bld_base.int_bld.type,
unit, pipe_target,
- is_sviewinfo,
+ TRUE,
lod_property,
explicit_lod,
sizes_out);
It might make sense to either drop this parameter now or just use the
old is_sviewinfo and change the logic in lp_build_size_query_soa - as
this did not just make sure the number of mip levels was returned but
also had more strict error condition handling not required for gl
(though I'm not entirely sure there's not other extensions which would
require that behavior too or even if not some apps depending on it). No
biggie though.
diff --git a/src/gallium/docs/source/tgsi.rst
b/src/gallium/docs/source/tgsi.rst
index 2ca3c3b..2130e08 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -964,7 +964,9 @@ XXX doesn't look like most of the opcodes really belong
here.
As per NV_gpu_program4, retrieve the dimensions of the texture depending on
the target. For 1D (width), 2D/RECT/CUBE (width, height), 3D (width,
height,
- depth), 1D array (width, layers), 2D array (width, height, layers)
+ depth), 1D array (width, layers), 2D array (width, height, layers).
+ Also return the number of accessible levels (last_level - first_level + 1)
+ in W.
.. math::
@@ -976,6 +978,8 @@ XXX doesn't look like most of the opcodes really belong
here.
dst.z = texture\_depth(unit, lod)
+ dst.w = texture\_levels(unit)
+
.. opcode:: TG4 - Texture Gather
As per ARB_texture_gather, gathers the four texels to be used in a
bi-linear
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 274e56b..6d97664 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -2911,6 +2911,9 @@ sp_get_dims(struct sp_sampler_view *sp_sview, int level,
if (level view-u.tex.last_level)
return;
+ if (texture-target != PIPE_BUFFER)
+ dims[3] = view-u.tex.last_level - view-u.tex.first_level + 1;
+
dims[0] = u_minify(texture-width0, level);
switch(texture-target) {
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 94be2b8..921c78d 100644
---
[Mesa-dev] [PATCH 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
src/gallium/drivers/nouveau/nouveau_fence.c | 76 -
src/gallium/drivers/nouveau/nouveau_fence.h | 22 +--
src/gallium/drivers/nouveau/nouveau_screen.c| 9 +++
src/gallium/drivers/nouveau/nouveau_screen.h| 14 ++---
src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 23 +---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 4 +-
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 20 +--
src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 +-
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 19 +--
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 2 +-
12 files changed, 121 insertions(+), 78 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_fence.c
b/src/gallium/drivers/nouveau/nouveau_fence.c
index c686710..09b3b1e 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.c
+++ b/src/gallium/drivers/nouveau/nouveau_fence.c
@@ -31,14 +31,14 @@
#endif
boolean
-nouveau_fence_new(struct nouveau_screen *screen, struct nouveau_fence **fence,
+nouveau_fence_new(struct nouveau_fence_mgr *mgr, struct nouveau_fence **fence,
boolean emit)
{
*fence = CALLOC_STRUCT(nouveau_fence);
if (!*fence)
return FALSE;
- (*fence)-screen = screen;
+ (*fence)-mgr = mgr;
(*fence)-ref = 1;
LIST_INITHEAD((*fence)-work);
@@ -83,7 +83,7 @@ nouveau_fence_work(struct nouveau_fence *fence,
void
nouveau_fence_emit(struct nouveau_fence *fence)
{
- struct nouveau_screen *screen = fence-screen;
+ struct nouveau_fence_mgr *mgr = fence-mgr;
assert(fence-state == NOUVEAU_FENCE_STATE_AVAILABLE);
@@ -92,14 +92,14 @@ nouveau_fence_emit(struct nouveau_fence *fence)
++fence-ref;
- if (screen-fence.tail)
- screen-fence.tail-next = fence;
+ if (mgr-tail)
+ mgr-tail-next = fence;
else
- screen-fence.head = fence;
+ mgr-head = fence;
- screen-fence.tail = fence;
+ mgr-tail = fence;
- screen-fence.emit(screen-base, fence-sequence);
+ mgr-emit(mgr, fence-sequence);
assert(fence-state == NOUVEAU_FENCE_STATE_EMITTING);
fence-state = NOUVEAU_FENCE_STATE_EMITTED;
@@ -109,19 +109,19 @@ void
nouveau_fence_del(struct nouveau_fence *fence)
{
struct nouveau_fence *it;
- struct nouveau_screen *screen = fence-screen;
+ struct nouveau_fence_mgr *mgr = fence-mgr;
if (fence-state == NOUVEAU_FENCE_STATE_EMITTED ||
fence-state == NOUVEAU_FENCE_STATE_FLUSHED) {
- if (fence == screen-fence.head) {
- screen-fence.head = fence-next;
- if (!screen-fence.head)
-screen-fence.tail = NULL;
+ if (fence == mgr-head) {
+ mgr-head = fence-next;
+ if (!mgr-head)
+mgr-tail = NULL;
} else {
- for (it = screen-fence.head; it it-next != fence; it = it-next);
+ for (it = mgr-head; it it-next != fence; it = it-next);
it-next = fence-next;
- if (screen-fence.tail == fence)
-screen-fence.tail = it;
+ if (mgr-tail == fence)
+mgr-tail = it;
}
}
@@ -134,17 +134,17 @@ nouveau_fence_del(struct nouveau_fence *fence)
}
void
-nouveau_fence_update(struct nouveau_screen *screen, boolean flushed)
+nouveau_fence_update(struct nouveau_fence_mgr *mgr, boolean flushed)
{
struct nouveau_fence *fence;
struct nouveau_fence *next = NULL;
- u32 sequence = screen-fence.update(screen-base);
+ u32 sequence = mgr-update(mgr);
- if (screen-fence.sequence_ack == sequence)
+ if (mgr-sequence_ack == sequence)
return;
- screen-fence.sequence_ack = sequence;
+ mgr-sequence_ack = sequence;
- for (fence = screen-fence.head; fence; fence = next) {
+ for (fence = mgr-head; fence; fence = next) {
next = fence-next;
sequence = fence-sequence;
@@ -153,12 +153,12 @@ nouveau_fence_update(struct nouveau_screen *screen, boolean flushed)
nouveau_fence_trigger_work(fence);
nouveau_fence_ref(NULL, fence);
- if (sequence == screen-fence.sequence_ack)
+ if (sequence == mgr-sequence_ack)
break;
}
- screen-fence.head = next;
+ mgr-head = next;
if (!next)
- screen-fence.tail = NULL;
+ mgr-tail = NULL;
if (flushed) {
for (fence = next; fence; fence = fence-next)
@@ -172,10 +172,10 @@ nouveau_fence_update(struct nouveau_screen *screen,
boolean flushed)
boolean
nouveau_fence_signalled(struct nouveau_fence *fence)
{
- struct nouveau_screen *screen = fence-screen;
+ struct nouveau_fence_mgr *mgr = fence-mgr;
if (fence-state = NOUVEAU_FENCE_STATE_EMITTED)
- nouveau_fence_update(screen, FALSE);
+ nouveau_fence_update(mgr, FALSE);
return fence-state == NOUVEAU_FENCE_STATE_SIGNALLED;
}
@@ -183,7 +183,7 @@
Re: [Mesa-dev] [Nouveau] [PATCH 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
Not sure what you did with these patches, but the spacing is all
off... makes them hard to read (for me) and also they won't apply for
testing. Mind regenerating them? Perhaps you were doing a 2-way merge?
On Mon, Jun 16, 2014 at 12:00 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
src/gallium/drivers/nouveau/nouveau_fence.c | 76
-
src/gallium/drivers/nouveau/nouveau_fence.h | 22 +--
src/gallium/drivers/nouveau/nouveau_screen.c| 9 +++
src/gallium/drivers/nouveau/nouveau_screen.h| 14 ++---
src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 23 +---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 4 +-
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 20 +--
src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 +-
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 19 +--
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 2 +-
12 files changed, 121 insertions(+), 78 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_fence.c
b/src/gallium/drivers/nouveau/nouveau_fence.c
index c686710..09b3b1e 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.c
+++ b/src/gallium/drivers/nouveau/nouveau_fence.c
@@ -31,14 +31,14 @@
#endif
boolean
-nouveau_fence_new(struct nouveau_screen *screen, struct nouveau_fence
**fence,
+nouveau_fence_new(struct nouveau_fence_mgr *mgr, struct nouveau_fence
**fence,
boolean emit)
{
*fence = CALLOC_STRUCT(nouveau_fence);
if (!*fence)
return FALSE;
- (*fence)-screen = screen;
+ (*fence)-mgr = mgr;
(*fence)-ref = 1;
LIST_INITHEAD((*fence)-work);
@@ -83,7 +83,7 @@ nouveau_fence_work(struct nouveau_fence *fence,
void
nouveau_fence_emit(struct nouveau_fence *fence)
{
- struct nouveau_screen *screen = fence-screen;
+ struct nouveau_fence_mgr *mgr = fence-mgr;
assert(fence-state == NOUVEAU_FENCE_STATE_AVAILABLE);
@@ -92,14 +92,14 @@ nouveau_fence_emit(struct nouveau_fence *fence)
++fence-ref;
- if (screen-fence.tail)
- screen-fence.tail-next = fence;
+ if (mgr-tail)
+ mgr-tail-next = fence;
else
- screen-fence.head = fence;
+ mgr-head = fence;
- screen-fence.tail = fence;
+ mgr-tail = fence;
- screen-fence.emit(screen-base, fence-sequence);
+ mgr-emit(mgr, fence-sequence);
assert(fence-state == NOUVEAU_FENCE_STATE_EMITTING);
fence-state = NOUVEAU_FENCE_STATE_EMITTED;
@@ -109,19 +109,19 @@ void
nouveau_fence_del(struct nouveau_fence *fence)
{
struct nouveau_fence *it;
- struct nouveau_screen *screen = fence-screen;
+ struct nouveau_fence_mgr *mgr = fence-mgr;
if (fence-state == NOUVEAU_FENCE_STATE_EMITTED ||
fence-state == NOUVEAU_FENCE_STATE_FLUSHED) {
- if (fence == screen-fence.head) {
- screen-fence.head = fence-next;
- if (!screen-fence.head)
-screen-fence.tail = NULL;
+ if (fence == mgr-head) {
+ mgr-head = fence-next;
+ if (!mgr-head)
+mgr-tail = NULL;
} else {
- for (it = screen-fence.head; it it-next != fence; it =
it-next);
+ for (it = mgr-head; it it-next != fence; it = it-next);
it-next = fence-next;
- if (screen-fence.tail == fence)
-screen-fence.tail = it;
+ if (mgr-tail == fence)
+mgr-tail = it;
}
}
@@ -134,17 +134,17 @@ nouveau_fence_del(struct nouveau_fence *fence)
}
void
-nouveau_fence_update(struct nouveau_screen *screen, boolean flushed)
+nouveau_fence_update(struct nouveau_fence_mgr *mgr, boolean flushed)
{
struct nouveau_fence *fence;
struct nouveau_fence *next = NULL;
- u32 sequence = screen-fence.update(screen-base);
+ u32 sequence = mgr-update(mgr);
- if (screen-fence.sequence_ack == sequence)
+ if (mgr-sequence_ack == sequence)
return;
- screen-fence.sequence_ack = sequence;
+ mgr-sequence_ack = sequence;
- for (fence = screen-fence.head; fence; fence = next) {
+ for (fence = mgr-head; fence; fence = next) {
next = fence-next;
sequence = fence-sequence;
@@ -153,12 +153,12 @@ nouveau_fence_update(struct nouveau_screen *screen,
boolean flushed)
nouveau_fence_trigger_work(fence);
nouveau_fence_ref(NULL, fence);
- if (sequence == screen-fence.sequence_ack)
+ if (sequence == mgr-sequence_ack)
break;
}
- screen-fence.head = next;
+ mgr-head = next;
if (!next)
- screen-fence.tail = NULL;
+ mgr-tail = NULL;
if (flushed) {
for (fence = next; fence; fence = fence-next)
@@ -172,10 +172,10 @@ nouveau_fence_update(struct nouveau_screen *screen,
boolean flushed)
boolean
Re: [Mesa-dev] [PATCH 4/5] texstore: Add a generic implementation of GL_ARB_clear_texture
On Mon, Jun 16, 2014 at 8:49 AM, Neil Roberts n...@linux.intel.com wrote:
Ilia Mirkin imir...@alum.mit.edu writes:
Will it? What about the MS case? I thought that for generic you had to
do a shader-based approach.
Ah yes, you're right the commit message is nonsense. I guess I should
also avoid enabling the extension at all until the next patch.
While I'm sure we all love the
while (height -- 0) { // as height goes to 0
construct... it's not immediately obvious (to me) that it's correct
when just glancing at it. After a few seconds of thought, it is
clearly right, but I think the more common thing is to use a for loop
where it's obvious there isn't some silly off-by-one error. I don't
think this is really used anywhere else in mesa. Here and below.
Ok, yes, I guess it is clearer to use a separate iterator variable.
However I don't think it's that uncommon in Mesa. Running ‘git grep
while (.*--’ shoes plenty of examples.
git grep 'while.*--' | wc -l
57
Ironically ~half of the instances are in nouveau. I'll go fix those.
$ git grep 'for' | wc -l
50480
I think 'for' is more popular :) [and yeah, it's not a completely fair
comparison, but... people get used to coding patterns.]
I've updated the wip/clear-texture branch on my github with these two
changes.
Thanks :)
Thanks for the review.
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/18] Multi-stream support for geometry shaders
On Mon, Jun 16, 2014 at 1:05 AM, Samuel Iglesias Gonsálvez
sigles...@igalia.com wrote:
On Sun, 2014-06-15 at 19:18 -0400, Ilia Mirkin wrote:
On Wed, Jun 11, 2014 at 12:31 PM, Jordan Justen jljus...@gmail.com wrote:
On Wed, Jun 11, 2014 at 2:49 AM, Iago Toral ito...@igalia.com wrote:
Hi Chris,
thanks for the quick review!
On Wed, 2014-06-11 at 21:45 +1200, Chris Forbes wrote:
I sent comments on patches 1, 3, 5, 9, 11, 16, 18
We will look into these.
Patches 2, 4, 6-8, 10, 12-15, 17 are:
Reviewed-by: Chris Forbes chr...@ijw.co.nz
You should also include a patch to docs/GL3.txt marking off this
subfeature for i965 :)
Do you have a bunch of piglits which exercise all the tricky corners
of this? I see a few tests
which require the existence of the stream layout qualifier, but not
covering all the behavior.
No, so far we have been testing this with a standalone program. We will
check what already exists in piglit and add missing test cases.
This is the only piglit test that I know about:
http://patchwork.freedesktop.org/patch/19224/
Note that it passed on nvidia, but failed on catalyst.
I just ran that test against this code (+ a few changes to add support
in gallium) and I got:
$ MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5
bin/arb_gpu_shader5-xfb-streams -fbo -auto
Failed to compile geometry shader: 0:3(1): error: invalid input layout
qualifiers used
source:
#version 150
#extension GL_ARB_gpu_shader5 : enable
layout(points, invocations = 32) in;
layout(points, max_vertices = 4) out;
out float stream0_0_out;
layout(stream = 1) out vec2 stream1_0_out;
layout(stream = 2) out float stream2_0_out;
layout(stream = 3) out vec3 stream3_0_out;
layout(stream = 1) out vec3 stream1_1_out;
layout(stream = 2) out vec4 stream2_1_out;
void main() {
gl_Position = gl_in[0].gl_Position;
stream0_0_out = 1.0 + gl_InvocationID;
EmitVertex();
EndPrimitive();
stream3_0_out = vec3(12.0 + gl_InvocationID, 13.0 + gl_InvocationID,
14.0 + gl_InvocationID);
EmitStreamVertex(3);
EndStreamPrimitive(3);
stream2_0_out = 7.0 + gl_InvocationID;
stream2_1_out = vec4(8.0 + gl_InvocationID, 9.0 + gl_InvocationID,
10.0 + gl_InvocationID, 11.0 + gl_InvocationID);
EmitStreamVertex(2);
EndStreamPrimitive(2);
stream1_0_out = vec2(2.0 + gl_InvocationID, 3.0 + gl_InvocationID);
stream1_1_out = vec3(4.0 + gl_InvocationID, 5.0 + gl_InvocationID,
6.0 + gl_InvocationID);
EmitStreamVertex(1);
EndStreamPrimitive(1);
}PIGLIT: {'result': 'fail' }
I guess it doesn't like
layout(points, invocations=32) in? Not sure. I could also have
messed something up... doing a bisect over your patches blames
glsl: Add parsing support for multi-stream output in geometry shaders.
Before that, it goes until the first stream=1 layout and fails there
(which is expected).
-ilia
I will take a look at it.
Does anyone see any bugs in the test?
If not, perhaps I should just push it to piglit.
It never got a reviewed-by, but it certainly had time for review. :)
Thanks,
-Jordan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/18] Multi-stream support for geometry shaders
On Mon, Jun 16, 2014 at 1:20 PM, Jordan Justen jljus...@gmail.com wrote:
On Mon, Jun 16, 2014 at 1:05 AM, Samuel Iglesias Gonsálvez
sigles...@igalia.com wrote:
On Sun, 2014-06-15 at 19:18 -0400, Ilia Mirkin wrote:
On Wed, Jun 11, 2014 at 12:31 PM, Jordan Justen jljus...@gmail.com wrote:
On Wed, Jun 11, 2014 at 2:49 AM, Iago Toral ito...@igalia.com wrote:
Hi Chris,
thanks for the quick review!
On Wed, 2014-06-11 at 21:45 +1200, Chris Forbes wrote:
I sent comments on patches 1, 3, 5, 9, 11, 16, 18
We will look into these.
Patches 2, 4, 6-8, 10, 12-15, 17 are:
Reviewed-by: Chris Forbes chr...@ijw.co.nz
You should also include a patch to docs/GL3.txt marking off this
subfeature for i965 :)
Do you have a bunch of piglits which exercise all the tricky corners
of this? I see a few tests
which require the existence of the stream layout qualifier, but not
covering all the behavior.
No, so far we have been testing this with a standalone program. We will
check what already exists in piglit and add missing test cases.
This is the only piglit test that I know about:
http://patchwork.freedesktop.org/patch/19224/
Note that it passed on nvidia, but failed on catalyst.
I just ran that test against this code (+ a few changes to add support
in gallium) and I got:
$ MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5
bin/arb_gpu_shader5-xfb-streams -fbo -auto
Failed to compile geometry shader: 0:3(1): error: invalid input layout
qualifiers used
source:
#version 150
#extension GL_ARB_gpu_shader5 : enable
layout(points, invocations = 32) in;
layout(points, max_vertices = 4) out;
out float stream0_0_out;
layout(stream = 1) out vec2 stream1_0_out;
layout(stream = 2) out float stream2_0_out;
layout(stream = 3) out vec3 stream3_0_out;
layout(stream = 1) out vec3 stream1_1_out;
layout(stream = 2) out vec4 stream2_1_out;
void main() {
gl_Position = gl_in[0].gl_Position;
stream0_0_out = 1.0 + gl_InvocationID;
EmitVertex();
EndPrimitive();
stream3_0_out = vec3(12.0 + gl_InvocationID, 13.0 + gl_InvocationID,
14.0 + gl_InvocationID);
EmitStreamVertex(3);
EndStreamPrimitive(3);
stream2_0_out = 7.0 + gl_InvocationID;
stream2_1_out = vec4(8.0 + gl_InvocationID, 9.0 + gl_InvocationID,
10.0 + gl_InvocationID, 11.0 + gl_InvocationID);
EmitStreamVertex(2);
EndStreamPrimitive(2);
stream1_0_out = vec2(2.0 + gl_InvocationID, 3.0 + gl_InvocationID);
stream1_1_out = vec3(4.0 + gl_InvocationID, 5.0 + gl_InvocationID,
6.0 + gl_InvocationID);
EmitStreamVertex(1);
EndStreamPrimitive(1);
}PIGLIT: {'result': 'fail' }
I guess it doesn't like
layout(points, invocations=32) in? Not sure. I could also have
messed something up... doing a bisect over your patches blames
glsl: Add parsing support for multi-stream output in geometry shaders.
Before that, it goes until the first stream=1 layout and fails there
(which is expected).
-ilia
I will take a look at it.
Does anyone see any bugs in the test?
If not, perhaps I should just push it to piglit.
It never got a reviewed-by, but it certainly had time for review. :)
I'm not qualified to review, but it passed on nvidia blob in my tests.
You can add my Tested-by if it helps.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add test to ensure compiler won't allow #undef for some builtins
On Wed, Jun 11, 2014 at 5:32 PM, Carl Worth cwo...@cworth.org wrote: Currently verifying that an #undef of __FILE__, __LINE__, or __VERSION__ will generate an error. --- src/glsl/glcpp/tests/120-undef-builtin.c | 3 +++ src/glsl/glcpp/tests/120-undef-builtin.c.expected | 7 +++ 2 files changed, 10 insertions(+) create mode 100644 src/glsl/glcpp/tests/120-undef-builtin.c create mode 100644 src/glsl/glcpp/tests/120-undef-builtin.c.expected diff --git a/src/glsl/glcpp/tests/120-undef-builtin.c b/src/glsl/glcpp/tests/120-undef-builtin.c new file mode 100644 index 000..49e7696 --- /dev/null +++ b/src/glsl/glcpp/tests/120-undef-builtin.c @@ -0,0 +1,3 @@ +#undef __LINE__ +#undef __FILE__ +#undef __VERSION__ diff --git a/src/glsl/glcpp/tests/120-undef-builtin.c.expected b/src/glsl/glcpp/tests/120-undef-builtin.c.expected new file mode 100644 index 000..d6981dc --- /dev/null +++ b/src/glsl/glcpp/tests/120-undef-builtin.c.expected @@ -0,0 +1,7 @@ +0:1(2): preprocessor error: Built-in (pre-defined) macro names can not be undefined. +0:2(1): preprocessor error: Built-in (pre-defined) macro names can not be undefined. +0:3(1): preprocessor error: Built-in (pre-defined) macro names can not be undefined. + + + + -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Reviewed-by: Anuj Phogat anuj.pho...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fixup glcpp tests for redefining a macro with whitespace changes.
On Wed, Jun 11, 2014 at 6:11 PM, Carl Worth cwo...@cworth.org wrote: Previously, the test suite was expecting the compiler to allow a redefintion of a macro with whitespace added, but gcc is more strict and allows only for changes in the amounts of whitespace, (but insists that whitespace exist or not in exactly the same places). See: https://gcc.gnu.org/onlinedocs/cpp/Undefining-and-Redefining-Macros.html: These definitions are effectively the same: #define FOUR (2 + 2) #define FOUR (2+2) #define FOUR (2 /* two */ + 2) but these are not: #define FOUR (2 + 2) #define FOUR ( 2+2 ) #define FOUR (2 * 2) #define FOUR(score,and,seven,years,ago) (2 + 2) This change adjusts the existing redefine-macro-legitimate test to work with the more strict understanding, and adds a new redefine-whitespace test to verify that changes in the position of whitespace are flagged as errors. --- .../glcpp/tests/088-redefine-macro-legitimate.c| 2 +- src/glsl/glcpp/tests/122-redefine-whitespace.c | 16 +++ .../glcpp/tests/122-redefine-whitespace.c.expected | 23 ++ 3 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 src/glsl/glcpp/tests/122-redefine-whitespace.c create mode 100644 src/glsl/glcpp/tests/122-redefine-whitespace.c.expected diff --git a/src/glsl/glcpp/tests/088-redefine-macro-legitimate.c b/src/glsl/glcpp/tests/088-redefine-macro-legitimate.c index 0e0666b..422c654 100644 --- a/src/glsl/glcpp/tests/088-redefine-macro-legitimate.c +++ b/src/glsl/glcpp/tests/088-redefine-macro-legitimate.c @@ -1,5 +1,5 @@ #define abc 123 #define abc 123 -#define foo(x) (x)+23 #define foo(x) ( x ) + 23 +#define foo(x) ( x ) + 23 diff --git a/src/glsl/glcpp/tests/122-redefine-whitespace.c b/src/glsl/glcpp/tests/122-redefine-whitespace.c new file mode 100644 index 000..ae7ea09 --- /dev/null +++ b/src/glsl/glcpp/tests/122-redefine-whitespace.c @@ -0,0 +1,16 @@ +/* Original definitions. */ +#define TWO ( 1+1 ) +#define FOUR (2 + 2) +#define SIX (3 + 3) + +/* Redefinitions with whitespace in same places, but different amounts, (so no + * error). */ +#define TWO( 1+1 ) +#define FOUR(2 + 2) +#define SIX(3/*comment is whitespace*/+ /* collapsed */ /* to */ /* one */ /* space */ 3) + +/* Redefinitions with whitespace in different places. Each of these should + * trigger an error. */ +#define TWO (1 + 1) +#define FOUR ( 2+2 ) +#define SIX (/*not*/3 + 3/*expected*/) diff --git a/src/glsl/glcpp/tests/122-redefine-whitespace.c.expected b/src/glsl/glcpp/tests/122-redefine-whitespace.c.expected new file mode 100644 index 000..193ebc4 --- /dev/null +++ b/src/glsl/glcpp/tests/122-redefine-whitespace.c.expected @@ -0,0 +1,23 @@ +0:14(9): preprocessor error: Redefinition of macro TWO + +0:15(9): preprocessor error: Redefinition of macro FOUR + +0:16(9): preprocessor error: Redefinition of macro SIX + + + + + + + + + + + + + + + + + + -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Reviewed-by: Anuj Phogat anuj.pho...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Mon, 16 Jun 2014 17:15:47 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: 2014-06-16 7:47 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Sun, 15 Jun 2014 13:49:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Hi, this sounds cool work to me, sorry I can't really review it. Does this work also help in getting llvmpipe working with the egl_dri2 loader? If you mean in wayland, unfortunately no. Each egl platform has to implement buffer uploading differently, so the code paths are different. This patchset only tackles the DRM platform, which means mutter, weston and other wayland compositors can run with llvmpipe, but their clients will not have working egl. Yes, that was clear to me. AFAIU, currently on EGL-Wayland the only way to use llvmpipe is to use egl_gallium.so as the loader, and I don't really know what it would take to make egl_dri2 work there, apart from the Wayland-specific bits, so I was kind of hoping your work would make that easier to implement. In the end, the simple way is to implement swrastGetImage and swrastPutImage for the wayland platform, using an shm backed buffer. It would look similar to the platform_drm side (because the way drm and wayland do double buffering is quite similar, and because both are incapable of front-buffer rendering, single-buffer rendering or rendering to foreign windows), but no real code sharing. OTOH, in wayland buffer sharing exists, so it would be hugely inefficient to implement swrast support this way (it incures one extra copy, from the malloc backbuffer to the shm fake frontbuffer). It should be possible to design an swrast2 interface in terms of shm FDs, similar to prime/dma-buf FDs, and with similar semantics, just nobody is working on it right now. Ookay... I maybe got half of that, but no worries. :-) I was just under the impression, that some larger infrastructural work was needed before egl_dri2 could work with software renderers, and I was hoping your work do at least part of that infrastructure. Doesn't matter, I was just curious. :-) Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: Fix gen2 texblend setup
From: Ville Syrjälä ville.syrj...@linux.intel.com
Fix an off by one in the texture unit walk during texblend
setup on gen2. This caused the last enabled texunit to be
skipped resulting in totally messed up texturing.
This is a regression introduced here:
commit 1ad443ecdd694dd9bf3c4a5050d749fb80db6fa2
Author: Eric Anholt e...@anholt.net
Date: Wed Apr 23 15:35:27 2014 -0700
i915: Redo texture unit walking on i830.
Cc: 10.2 mesa-sta...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
src/mesa/drivers/dri/i915/i830_texblend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i915/i830_texblend.c
b/src/mesa/drivers/dri/i915/i830_texblend.c
index 6e991c4..236be59 100644
--- a/src/mesa/drivers/dri/i915/i830_texblend.c
+++ b/src/mesa/drivers/dri/i915/i830_texblend.c
@@ -445,7 +445,7 @@ i830EmitTextureBlend(struct i830_context *i830)
I830_ACTIVESTATE(i830, I830_UPLOAD_TEXBLEND_ALL, false);
if (ctx-Texture._MaxEnabledTexImageUnit != -1) {
- for (unit = 0; unit ctx-Texture._MaxEnabledTexImageUnit; unit++)
+ for (unit = 0; unit = ctx-Texture._MaxEnabledTexImageUnit; unit++)
if (ctx-Texture.Unit[unit]._Current)
emit_texblend(i830, unit, blendunit++,
unit == ctx-Texture._MaxEnabledTexImageUnit);
--
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 1/2] R600/SI: add Gather4 intrinsics (v2)
Why are there SDNodes for the other sample intrinsics then?
Marek
On Mon, Jun 16, 2014 at 5:45 PM, Tom Stellard t...@stellard.net wrote:
On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This adds a new type of intrinsic and SDNode: SampleRaw.
All fields of the MIMG opcodes are exposed and can be set by Mesa,
even DMASK. All GATHER4 variants are added and there are a lot of them.
v2: document DMASK behavior
---
lib/Target/R600/AMDGPUISelLowering.cpp | 24 +
lib/Target/R600/AMDGPUISelLowering.h | 31 +++
lib/Target/R600/SIISelLowering.cpp | 72 +
lib/Target/R600/SIISelLowering.h | 2 +
lib/Target/R600/SIInstrInfo.td | 91
lib/Target/R600/SIInstructions.td | 96
+-
lib/Target/R600/SIIntrinsics.td| 48 +
7 files changed, 340 insertions(+), 24 deletions(-)
diff --git a/lib/Target/R600/AMDGPUISelLowering.cpp
b/lib/Target/R600/AMDGPUISelLowering.cpp
index 849f169..359161c 100644
--- a/lib/Target/R600/AMDGPUISelLowering.cpp
+++ b/lib/Target/R600/AMDGPUISelLowering.cpp
@@ -1542,6 +1542,30 @@ const char*
AMDGPUTargetLowering::getTargetNodeName(unsigned Opcode) const {
NODE_NAME_CASE(SAMPLEB)
NODE_NAME_CASE(SAMPLED)
NODE_NAME_CASE(SAMPLEL)
+ NODE_NAME_CASE(GATHER4)
+ NODE_NAME_CASE(GATHER4_CL)
+ NODE_NAME_CASE(GATHER4_L)
+ NODE_NAME_CASE(GATHER4_B)
+ NODE_NAME_CASE(GATHER4_B_CL)
+ NODE_NAME_CASE(GATHER4_LZ)
+ NODE_NAME_CASE(GATHER4_C)
+ NODE_NAME_CASE(GATHER4_C_CL)
+ NODE_NAME_CASE(GATHER4_C_L)
+ NODE_NAME_CASE(GATHER4_C_B)
+ NODE_NAME_CASE(GATHER4_C_B_CL)
+ NODE_NAME_CASE(GATHER4_C_LZ)
+ NODE_NAME_CASE(GATHER4_O)
+ NODE_NAME_CASE(GATHER4_CL_O)
+ NODE_NAME_CASE(GATHER4_L_O)
+ NODE_NAME_CASE(GATHER4_B_O)
+ NODE_NAME_CASE(GATHER4_B_CL_O)
+ NODE_NAME_CASE(GATHER4_LZ_O)
+ NODE_NAME_CASE(GATHER4_C_O)
+ NODE_NAME_CASE(GATHER4_C_CL_O)
+ NODE_NAME_CASE(GATHER4_C_L_O)
+ NODE_NAME_CASE(GATHER4_C_B_O)
+ NODE_NAME_CASE(GATHER4_C_B_CL_O)
+ NODE_NAME_CASE(GATHER4_C_LZ_O)
You don't need to add new SDNodes for all these instructions, you can just use
the intrinsic directly in the pattern.
The only reason to add SDNodes, is if there are optimizations / special
lowering
we can do for these instructions.
NODE_NAME_CASE(STORE_MSKOR)
NODE_NAME_CASE(TBUFFER_STORE_FORMAT)
}
diff --git a/lib/Target/R600/AMDGPUISelLowering.h
b/lib/Target/R600/AMDGPUISelLowering.h
index d5d821d..a9af195 100644
--- a/lib/Target/R600/AMDGPUISelLowering.h
+++ b/lib/Target/R600/AMDGPUISelLowering.h
@@ -203,6 +203,37 @@ enum {
SAMPLEB,
SAMPLED,
SAMPLEL,
+
+ // Gather4 opcodes
+ GATHER4,
+ GATHER4_CL,
+ GATHER4_L,
+ GATHER4_B,
+ GATHER4_B_CL,
+ GATHER4_LZ,
+
+ GATHER4_C,
+ GATHER4_C_CL,
+ GATHER4_C_L,
+ GATHER4_C_B,
+ GATHER4_C_B_CL,
+ GATHER4_C_LZ,
+
+ GATHER4_O,
+ GATHER4_CL_O,
+ GATHER4_L_O,
+ GATHER4_B_O,
+ GATHER4_B_CL_O,
+ GATHER4_LZ_O,
+
+ GATHER4_C_O,
+ GATHER4_C_CL_O,
+ GATHER4_C_L_O,
+ GATHER4_C_B_O,
+ GATHER4_C_B_CL_O,
+ GATHER4_C_LZ_O,
+
+ // Nemory opcodes
FIRST_MEM_OPCODE_NUMBER = ISD::FIRST_TARGET_MEMORY_OPCODE,
STORE_MSKOR,
LOAD_CONSTANT,
diff --git a/lib/Target/R600/SIISelLowering.cpp
b/lib/Target/R600/SIISelLowering.cpp
index 1a861d4..909255d 100644
--- a/lib/Target/R600/SIISelLowering.cpp
+++ b/lib/Target/R600/SIISelLowering.cpp
@@ -688,6 +688,59 @@ SDValue SITargetLowering::LowerOperation(SDValue Op,
SelectionDAG DAG) const {
Op.getOperand(1),
Op.getOperand(2),
Op.getOperand(3));
+
+// Gather4 intrinsics
+case AMDGPUIntrinsic::SI_gather4:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_CL, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_l:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_L, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_b:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_B, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_b_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_B_CL, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_lz:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_LZ, Op, DAG);
+
+case AMDGPUIntrinsic::SI_gather4_c:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_cl:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_CL, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_l:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_L, Op, DAG);
+case AMDGPUIntrinsic::SI_gather4_c_b:
+ return LowerSampleRawIntrinsic(AMDGPUISD::GATHER4_C_B, Op, DAG);
+case
Re: [Mesa-dev] [PATCH] glsl: Expand matrix flip optimization pass to cover more cases.
On 04/21/2014 04:38 AM, Iago Toral Quiroga wrote:
Currently it only considers the cases of gl_ModelViewProjectionMatrix and
gl_TextureMatrix. The same optimization can be done also for
gl_ModelViewMatrix, gl_ProjectionMatrix and the corresponding inverses.
I've been looking at some thing similar recently. I've been looking at
flipping user-defined matrices.
I think rather than adding a bunch of individual handles to flippable
matrices, I think we should add a hash-table of possible names. For the
built-in uniforms, we would add any matrix uniform that doesn't have
Transpose in the name. Something like:
struct matrix_and_transpose {
ir_variable *matrix;
ir_variable *transpose_matrix;
};
I think all of the names have regular enough patterns that we should be
able to generate the non-transpose name from the transpose name. Vice
versa shouldn't be necessary. If the transpose name is encountered
first, add the structure with matrix set NULL and the name derived from
the transpose name.
One other comment below.
---
src/glsl/opt_flip_matrices.cpp | 118
+++--
1 file changed, 91 insertions(+), 27 deletions(-)
diff --git a/src/glsl/opt_flip_matrices.cpp b/src/glsl/opt_flip_matrices.cpp
index 9044fd6..bf09b78 100644
--- a/src/glsl/opt_flip_matrices.cpp
+++ b/src/glsl/opt_flip_matrices.cpp
@@ -29,8 +29,9 @@
* On some hardware, this is more efficient.
*
* This currently only does the conversion for built-in matrices which
- * already have transposed equivalents. Namely, gl_ModelViewProjectionMatrix
- * and gl_TextureMatrix.
+ * already have transposed equivalents. Namely, gl_ModelViewMatrix,
+ * gl_ProjectionMatrix, gl_ModelViewProjectionMatrix, gl_TextureMatrix and
+ * their inverses.
*/
#include ir.h
#include ir_optimization.h
@@ -42,18 +43,39 @@ public:
matrix_flipper(exec_list *instructions)
{
progress = false;
+ p_transpose = NULL;
+ p_inv_transpose = NULL;
+ mv_transpose = NULL;
+ mv_inv_transpose = NULL;
mvp_transpose = NULL;
+ mvp_inv_transpose = NULL;
texmat_transpose = NULL;
+ texmat_inv_transpose = NULL;
foreach_list(n, instructions) {
ir_instruction *ir = (ir_instruction *) n;
ir_variable *var = ir-as_variable();
if (!var)
continue;
- if (strcmp(var-name, gl_ModelViewProjectionMatrixTranspose) == 0)
+
+ if (strcmp(var-name, gl_ProjectionMatrixTranspose) == 0)
+p_transpose = var;
+ else if (strcmp(var-name, gl_ProjectionMatrixInverseTranspose)
== 0)
+p_inv_transpose = var;
+ else if (strcmp(var-name, gl_ModelViewMatrixTranspose) == 0)
+mv_transpose = var;
+ else if (strcmp(var-name, gl_ModelViewMatrixInverseTranspose) ==
0)
+mv_inv_transpose = var;
+ else if (strcmp(var-name,
+ gl_ModelViewProjectionMatrixTranspose) == 0)
mvp_transpose = var;
- if (strcmp(var-name, gl_TextureMatrixTranspose) == 0)
+ else if (strcmp(var-name,
+ gl_ModelViewProjectionMatrixInverseTranspose) ==
0)
+mvp_inv_transpose = var;
+ else if (strcmp(var-name, gl_TextureMatrixTranspose) == 0)
texmat_transpose = var;
+ else if (strcmp(var-name, gl_TextureMatrixInverseTranspose) == 0)
+texmat_inv_transpose = var;
}
}
@@ -62,11 +84,49 @@ public:
bool progress;
private:
+ ir_variable *p_transpose;
+ ir_variable *p_inv_transpose;
+ ir_variable *mv_transpose;
+ ir_variable *mv_inv_transpose;
ir_variable *mvp_transpose;
+ ir_variable *mvp_inv_transpose;
ir_variable *texmat_transpose;
+ ir_variable *texmat_inv_transpose;
};
}
+static void
+transform_operands(ir_expression *ir,
+ ir_variable *mat_var, ir_variable *mat_transpose)
+{
+#ifndef NDEBUG
+ ir_dereference_variable *deref =
ir-operands[0]-as_dereference_variable();
+ assert(deref deref-var == mat_var);
+#endif
+
+ void *mem_ctx = ralloc_parent(ir);
+ ir-operands[0] = ir-operands[1];
+ ir-operands[1] = new(mem_ctx) ir_dereference_variable(mat_transpose);
+}
+
+static void
+transform_operands_texmat(ir_expression *ir,
+ ir_variable *mat_var, ir_variable *mat_transpose)
I'd call this transform_operands_array_of_matrix or something. Once we
add support for user-defined matrices, this function will be used for
other arrays too.
+{
+ ir_dereference_array *array_ref = ir-operands[0]-as_dereference_array();
+ assert(array_ref != NULL);
+ ir_dereference_variable *var_ref =
array_ref-array-as_dereference_variable();
+ assert(var_ref var_ref-var == mat_var);
+
+ ir-operands[0] = ir-operands[1];
+ ir-operands[1] = array_ref;
+
+ var_ref-var =
Re: [Mesa-dev] [PATCH] i915: Fix gen2 texblend setup
Yeah, that looks right.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Did you notice if other drivers have the same off-by-one issue?
On 06/16/2014 11:22 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Fix an off by one in the texture unit walk during texblend
setup on gen2. This caused the last enabled texunit to be
skipped resulting in totally messed up texturing.
This is a regression introduced here:
commit 1ad443ecdd694dd9bf3c4a5050d749fb80db6fa2
Author: Eric Anholt e...@anholt.net
Date: Wed Apr 23 15:35:27 2014 -0700
i915: Redo texture unit walking on i830.
Cc: 10.2 mesa-sta...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
src/mesa/drivers/dri/i915/i830_texblend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i915/i830_texblend.c
b/src/mesa/drivers/dri/i915/i830_texblend.c
index 6e991c4..236be59 100644
--- a/src/mesa/drivers/dri/i915/i830_texblend.c
+++ b/src/mesa/drivers/dri/i915/i830_texblend.c
@@ -445,7 +445,7 @@ i830EmitTextureBlend(struct i830_context *i830)
I830_ACTIVESTATE(i830, I830_UPLOAD_TEXBLEND_ALL, false);
if (ctx-Texture._MaxEnabledTexImageUnit != -1) {
- for (unit = 0; unit ctx-Texture._MaxEnabledTexImageUnit; unit++)
+ for (unit = 0; unit = ctx-Texture._MaxEnabledTexImageUnit; unit++)
if (ctx-Texture.Unit[unit]._Current)
emit_texblend(i830, unit, blendunit++,
unit == ctx-Texture._MaxEnabledTexImageUnit);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80069] rendering problems: black areas in KDE desktop. [mesa 10.2.1 (not with 10.1.4)]
https://bugs.freedesktop.org/show_bug.cgi?id=80069 Andreas Boll andreas.boll@gmail.com changed: What|Removed |Added Version|unspecified |10.2 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker
https://bugs.freedesktop.org/show_bug.cgi?id=79706 Andreas Boll andreas.boll@gmail.com changed: What|Removed |Added Depends on||80069 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80069] rendering problems: black areas in KDE desktop. [mesa 10.2.1 (not with 10.1.4)]
https://bugs.freedesktop.org/show_bug.cgi?id=80069 Andreas Boll andreas.boll@gmail.com changed: What|Removed |Added Blocks||79706 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Program RASTER_CONFIG for harvested GPUs v2
I haven't read the hardware docs on this, so I can't say if it's correct.
Acked-by: Marek Olšák marek.ol...@amd.com
Marek
On Thu, May 1, 2014 at 4:55 AM, Tom Stellard thomas.stell...@amd.com wrote:
v2:
- Write RASTER_CONFIG for all SEs
https://bugs.freedesktop.org/show_bug.cgi?id=60879
---
src/gallium/drivers/radeonsi/si_state.c | 100
--
src/gallium/drivers/radeonsi/sid.h| 8 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 3 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
4 files changed, 106 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 921264e..509ba5b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3024,6 +3024,17 @@ void si_init_state_functions(struct si_context *sctx)
sctx-b.b.draw_vbo = si_draw_vbo;
}
+static unsigned pkr_mask_to_map(unsigned mask)
+{
+ switch(mask 0x3) {
+ case 0x0:
+ case 0x1: return 0x0;
+ case 0x2: return 0x3;
+ case 0x3: return 0x2;
+ }
+ return 0;
+}
+
void si_init_config(struct si_context *sctx)
{
struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
@@ -3101,24 +3112,103 @@ void si_init_config(struct si_context *sctx)
break;
}
} else {
+ unsigned raster_config = 0;
+ unsigned default_rb_mask = 0;
+ unsigned sh_per_se;
+ unsigned num_se;
+ unsigned rb_mask =
sctx-screen-b.info.si_backend_enabled_mask;
+ unsigned i;
switch (sctx-screen-b.family) {
case CHIP_TAHITI:
case CHIP_PITCAIRN:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x2a00126a);
+ raster_config = 0x2a00126a;
+ sh_per_se = 2;
+ num_se = 2;
break;
case CHIP_VERDE:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x124a);
+ raster_config = 0x124a;
+ sh_per_se = 2;
+ num_se = 1;
break;
case CHIP_OLAND:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x0082);
+ raster_config = 0x0082;
+ sh_per_se = 1;
+ num_se = 1;
break;
case CHIP_HAINAN:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
+ raster_config = 0x;
+ sh_per_se = 1;
+ num_se = 1;
break;
default:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
+ raster_config = 0x;
+ sh_per_se = 1;
+ num_se = 1;
break;
}
+
+ if (rb_mask) {
+ /* XXX: I can't figure out what the *_XSEL and *_YSEL
+* fields are for, so I'm leaving them as their
default
+* values. */
+ unsigned pkr_mask = (sh_per_se | 0x1);
+ unsigned se0_pkr0 = rb_mask pkr_mask;
+ unsigned se0_pkr1 = (rb_mask = sh_per_se)
pkr_mask;
+ unsigned se1_pkr0 = (rb_mask = sh_per_se)
pkr_mask;
+ unsigned se1_pkr1 = (rb_mask = sh_per_se)
pkr_mask;
+ unsigned se_map = 0;
+ unsigned se0_pkr_map = 0;
+ unsigned se1_pkr_map = 0;
+ unsigned se0_pkr0_rb_map = 0;
+ unsigned se0_pkr1_rb_map = 0;
+ unsigned se1_pkr0_rb_map = 0;
+ unsigned se1_pkr1_rb_map = 0;
+ if (!se0_pkr0 !se0_pkr1) {
+ /* se0 disabled */
+ se_map |= 0x1;
+ }
+ if (se1_pkr0 || se1_pkr1) {
+ /* se1 enabled */
+ se_map |= 0x2;
+ }
+ if (!se0_pkr0) {
+ /* se0 pkr0 disabled */
+ se0_pkr_map |= 0x1;
+ }
+ if (se0_pkr1) {
+ /* se0 pkr1 enabled */
+ se0_pkr_map |= 0x2;
+ }
+ if (!se1_pkr0) {
+
Re: [Mesa-dev] Mesa (master): r600g, radeonsi: don' t use hardware MSAA resolve if dst is fast-cleared
No, 0423513c will fail to compile on stable branches.
Marek
On Sat, Jun 7, 2014 at 3:10 AM, Ian Romanick i...@freedesktop.org wrote:
This patch didn't apply cleanly to 10.2. It appears that 0423513c also
hits some code in this area. I picked d2261918 over, but should
0423513c also get picked?
On 06/03/2014 04:33 AM, Marek Olšák wrote:
Module: Mesa
Branch: master
Commit: d2261918202697febed0de18f66416e273001088
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d2261918202697febed0de18f66416e273001088
Author: Marek Olšák marek.ol...@amd.com
Date: Mon Jun 2 13:51:29 2014 +0200
r600g,radeonsi: don't use hardware MSAA resolve if dst is fast-cleared
It doesn't work and our docs say so too.
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/r600/r600_blit.c |3 ++-
src/gallium/drivers/radeonsi/si_blit.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index a2e7fa3..3269c47 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -788,7 +788,8 @@ static bool do_hardware_msaa_resolve(struct pipe_context
*ctx,
info-src.box.width == dst_width
info-src.box.height == dst_height
info-src.box.depth == 1
- dst-surface.level[info-dst.level].mode = RADEON_SURF_MODE_1D) {
+ dst-surface.level[info-dst.level].mode = RADEON_SURF_MODE_1D
+ (!dst-cmask.size || !dst-dirty_level_mask) /* dst cannot be
fast-cleared */) {
r600_blitter_begin(ctx, R600_COLOR_RESOLVE |
(info-render_condition_enable ? 0 :
R600_DISABLE_RENDER_COND));
util_blitter_custom_resolve_color(rctx-blitter,
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index 0a4a660..e02615f 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -688,7 +688,8 @@ static bool do_hardware_msaa_resolve(struct pipe_context
*ctx,
info-src.box.height == dst_height
info-src.box.depth == 1
dst-surface.level[info-dst.level].mode = RADEON_SURF_MODE_1D
- !(dst-surface.flags RADEON_SURF_SCANOUT)) {
+ !(dst-surface.flags RADEON_SURF_SCANOUT)
+ (!dst-cmask.size || !dst-dirty_level_mask) /* dst cannot be
fast-cleared */) {
si_blitter_begin(ctx, SI_COLOR_RESOLVE |
(info-render_condition_enable ? 0 :
SI_DISABLE_RENDER_COND));
util_blitter_custom_resolve_color(sctx-blitter,
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] RFC: Gallium support for ARB_shader_atomic_counters
Hello, I've been toying with the idea of adding gallium support for the atomic counters extension in gallium. Nouveau already largely supports it, so it's mostly a question of plumbing. (One piece that's missing in nouveau is _actually_ binding resources, but that can't be too difficult... I hope.) It seems like the thing that makes the most sense is to make sure that the atomic buffer is allocated with PIPE_BIND_SHADER_RESOURCE, and use -set_shader_resources to bind them. Then the TGSI opcodes generated would refer to TGSI_FILE_RESOURCE objects linked to those atomic buffers. I would reuse the existing ATOM* opcodes + LOAD/STORE (didn't check if extra ones are needed, but I'd assume not). Am I missing some large piece of this? Is there an easier/better way of doing this? It'll obviously require a bunch of work in st_glsl_to_tgsi to add support for tracking resources/etc. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: fix the max vertex shader input limit
--- src/gallium/drivers/r600/r600_pipe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 2b65056..6f87c78 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -410,7 +410,7 @@ static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned shader, e case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH: return 32; case PIPE_SHADER_CAP_MAX_INPUTS: - return 32; + return shader == PIPE_SHADER_VERTEX ? 16 : 32; case PIPE_SHADER_CAP_MAX_TEMPS: return 256; /* Max native temporaries. */ case PIPE_SHADER_CAP_MAX_ADDRS: -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/13] glsl: Remove 'struct' from ir_variable declaration.
Series is Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 06/15/2014 10:15 AM, Matt Turner wrote: --- src/glsl/opt_dead_builtin_varyings.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/opt_dead_builtin_varyings.cpp b/src/glsl/opt_dead_builtin_varyings.cpp index 6612592..50c8aa7 100644 --- a/src/glsl/opt_dead_builtin_varyings.cpp +++ b/src/glsl/opt_dead_builtin_varyings.cpp @@ -334,7 +334,7 @@ public: } void prepare_array(exec_list *ir, - struct ir_variable **new_var, + ir_variable **new_var, int max_elements, unsigned start_location, const char *var_name, const char *mode_str, unsigned usage, unsigned external_usage) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix geometry shader max texture limit in state validation
--- src/mesa/state_tracker/st_atom_texture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_atom_texture.c b/src/mesa/state_tracker/st_atom_texture.c index e2d26ee..f34a598 100644 --- a/src/mesa/state_tracker/st_atom_texture.c +++ b/src/mesa/state_tracker/st_atom_texture.c @@ -434,7 +434,7 @@ update_geometry_textures(struct st_context *st) update_textures(st, PIPE_SHADER_GEOMETRY, ctx-GeometryProgram._Current-Base, - ctx-Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits, + ctx-Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits, st-state.sampler_views[PIPE_SHADER_GEOMETRY], st-state.num_sampler_views[PIPE_SHADER_GEOMETRY]); } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix geometry shader max texture limit in state validation
On 06/16/2014 04:45 PM, Marek Olšák wrote: --- src/mesa/state_tracker/st_atom_texture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_atom_texture.c b/src/mesa/state_tracker/st_atom_texture.c index e2d26ee..f34a598 100644 --- a/src/mesa/state_tracker/st_atom_texture.c +++ b/src/mesa/state_tracker/st_atom_texture.c @@ -434,7 +434,7 @@ update_geometry_textures(struct st_context *st) update_textures(st, PIPE_SHADER_GEOMETRY, ctx-GeometryProgram._Current-Base, - ctx-Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits, + ctx-Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits, st-state.sampler_views[PIPE_SHADER_GEOMETRY], st-state.num_sampler_views[PIPE_SHADER_GEOMETRY]); } 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 2/2] i965: Use 8x4 aligned rectangles for HiZ operations on Broadwell.
On Fri, Jun 13, 2014 at 5:26 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Like on Haswell, we need to use 8x4 aligned rectangle primitives for
hierarchical depth buffer resolves and depth clears. See the comments
in brw_blorp.cpp's brw_hiz_op_params() constructor. (The Broadwell
documentation confirms that this is still necessary.)
This patch makes the Broadwell code follow the same behavior as Chad and
Jordan's Gen7 BLORP code. Based on a patch by Topi Pohjolainen.
This fixes es3conform's framebuffer_blit_functionality_scissor_blit
test, with no Piglit regressions.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 8c70c62..f538d23 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -225,6 +225,13 @@ gen8_hiz_exec(struct brw_context *brw, struct
intel_mipmap_tree *mt,
assert(mt-first_level == 0);
assert(mt-logical_depth0 = 1);
+ /* If we're operating on LOD 0, align to 8x4 to meet the alignment
+* requirements for most HiZ operations. Otherwise, use the actual size
+* to allow the hardware to calculate the miplevel offsets correctly.
+*/
+ uint32_t surface_width = ALIGN(mt-logical_width0, level == 0 ? 8 : 1);
+ uint32_t surface_height = ALIGN(mt-logical_height0, level == 0 ? 4 : 1);
+
/* The basic algorithm is:
* - If needed, emit 3DSTATE_{DEPTH,HIER_DEPTH,STENCIL}_BUFFER and
* 3DSTATE_CLEAR_PARAMS packets to set up the relevant buffers.
@@ -239,14 +246,19 @@ gen8_hiz_exec(struct brw_context *brw, struct
intel_mipmap_tree *mt,
true, /* depth writes */
NULL, false, 0, /* no stencil for now */
true, /* hiz */
- mt-logical_width0,
- mt-logical_height0,
+ surface_width,
+ surface_height,
mt-logical_depth0,
level,
layer); /* min_array_element */
- unsigned rect_width = minify(mt-logical_width0, level);
- unsigned rect_height = minify(mt-logical_height0, level);
+ /* Depth buffer clears and HiZ resolves must use an 8x4 aligned rectangle.
+* Note that intel_miptree_level_enable_hiz disables HiZ for miplevels 0
+* which aren't 8x4 aligned, so expanding the size is safe - it'll just
+* draw into empty padding space.
+*/
How about ... size is safe. For LOD 0 we may expand the size (by
aligning), but it is safe because at LOD 0 it overdraws into empty
padding space.
Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+ unsigned rect_width = ALIGN(minify(mt-logical_width0, level), 8);
+ unsigned rect_height = ALIGN(minify(mt-logical_height0, level), 4);
BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_DRAWING_RECTANGLE 16 | (4 - 2));
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Gallium support for ARB_shader_atomic_counters
[Cc: Aditya] Aditya Avinash was interested in doing this as his first task in Mesa. But what you describe sounds good. If we use set_shader_resources for atomic counter buffer objects, we should also have a plan for how we will bind shader storage buffers objects and images. I suggest we use a disjoint range of binding points for each, e.g. atomic counters: 0..15 (if we need so many), storage buffers: 16..31, and images: 32..47 if a driver supports 48 writable shader resources. The state tracker will have to divide the binding points among all resource types. Marek On Tue, Jun 17, 2014 at 12:43 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I've been toying with the idea of adding gallium support for the atomic counters extension in gallium. Nouveau already largely supports it, so it's mostly a question of plumbing. (One piece that's missing in nouveau is _actually_ binding resources, but that can't be too difficult... I hope.) It seems like the thing that makes the most sense is to make sure that the atomic buffer is allocated with PIPE_BIND_SHADER_RESOURCE, and use -set_shader_resources to bind them. Then the TGSI opcodes generated would refer to TGSI_FILE_RESOURCE objects linked to those atomic buffers. I would reuse the existing ATOM* opcodes + LOAD/STORE (didn't check if extra ones are needed, but I'd assume not). Am I missing some large piece of this? Is there an easier/better way of doing this? It'll obviously require a bunch of work in st_glsl_to_tgsi to add support for tracking resources/etc. -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] RFC: Gallium support for ARB_shader_atomic_counters
On Mon, Jun 16, 2014 at 7:21 PM, Marek Olšák mar...@gmail.com wrote: [Cc: Aditya] Aditya Avinash was interested in doing this as his first task in Mesa. Oh awesome. Actually I think someone may have mentioned this fact to me but then I forgot :) I'll look at other stuff then. But what you describe sounds good. If we use set_shader_resources for atomic counter buffer objects, we should also have a plan for how we will bind shader storage buffers objects and images. I suggest we use a disjoint range of binding points for each, e.g. atomic counters: 0..15 (if we need so many), storage buffers: 16..31, and images: 32..47 if a driver supports 48 writable shader resources. The state tracker will have to divide the binding points among all resource types. Why does it matter whether something's an atomic counter or some other kind of resource? i.e. why the separate ranges? Marek On Tue, Jun 17, 2014 at 12:43 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I've been toying with the idea of adding gallium support for the atomic counters extension in gallium. Nouveau already largely supports it, so it's mostly a question of plumbing. (One piece that's missing in nouveau is _actually_ binding resources, but that can't be too difficult... I hope.) It seems like the thing that makes the most sense is to make sure that the atomic buffer is allocated with PIPE_BIND_SHADER_RESOURCE, and use -set_shader_resources to bind them. Then the TGSI opcodes generated would refer to TGSI_FILE_RESOURCE objects linked to those atomic buffers. I would reuse the existing ATOM* opcodes + LOAD/STORE (didn't check if extra ones are needed, but I'd assume not). Am I missing some large piece of this? Is there an easier/better way of doing this? It'll obviously require a bunch of work in st_glsl_to_tgsi to add support for tracking resources/etc. -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] RFC: Gallium support for ARB_shader_atomic_counters
It's only for the state tracker. Drivers don't have to be concerned about this and should just expose a fixed number of writable shader resources that can be used with all types. Marek On Tue, Jun 17, 2014 at 1:26 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 16, 2014 at 7:21 PM, Marek Olšák mar...@gmail.com wrote: [Cc: Aditya] Aditya Avinash was interested in doing this as his first task in Mesa. Oh awesome. Actually I think someone may have mentioned this fact to me but then I forgot :) I'll look at other stuff then. But what you describe sounds good. If we use set_shader_resources for atomic counter buffer objects, we should also have a plan for how we will bind shader storage buffers objects and images. I suggest we use a disjoint range of binding points for each, e.g. atomic counters: 0..15 (if we need so many), storage buffers: 16..31, and images: 32..47 if a driver supports 48 writable shader resources. The state tracker will have to divide the binding points among all resource types. Why does it matter whether something's an atomic counter or some other kind of resource? i.e. why the separate ranges? Marek On Tue, Jun 17, 2014 at 12:43 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I've been toying with the idea of adding gallium support for the atomic counters extension in gallium. Nouveau already largely supports it, so it's mostly a question of plumbing. (One piece that's missing in nouveau is _actually_ binding resources, but that can't be too difficult... I hope.) It seems like the thing that makes the most sense is to make sure that the atomic buffer is allocated with PIPE_BIND_SHADER_RESOURCE, and use -set_shader_resources to bind them. Then the TGSI opcodes generated would refer to TGSI_FILE_RESOURCE objects linked to those atomic buffers. I would reuse the existing ATOM* opcodes + LOAD/STORE (didn't check if extra ones are needed, but I'd assume not). Am I missing some large piece of this? Is there an easier/better way of doing this? It'll obviously require a bunch of work in st_glsl_to_tgsi to add support for tracking resources/etc. -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
[Mesa-dev] [Bug 80034] compile error eglGetSyncValuesCHROMIUM undeclared
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #5 from charlie bug0xa...@hushmail.com ---
Solved. Mesa compiled fine after I fixed the typo in CPPFLAGS but I removed
CPPFLAGS as suggested anyway.
I use a simple 10-liner script that sets the options that I need from mesa.
People, your time was not a total waste as I will incorporate all your tips and
suggestions I learned here maybe in a build script or .bash_profile so other
people can test mesa more easily in the future.
Thus setting it to /etc while the latter two are ${XBUILD} is not something
I've seen and/or encourage.
I probably did that so that I could use one /etc for 3 different installs of X
on my system.
Thanks guys.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80034] compile error eglGetSyncValuesCHROMIUM undeclared
https://bugs.freedesktop.org/show_bug.cgi?id=80034 charlie bug0xa...@hushmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] gallium: add PIPE_BIND_COMMAND_ARGS_BUFFER
Since LLVM 3.5 will be released in August and my radeon patches adding
ARB_draw_indirect depend on it, I will commit ARB_draw_indirect
support for Gallium with softpipe and llvmpipe support earlier. My
plan is for patches 3,4,5,6 to get committed in one week from now, or
sooner if somebody reviews them.
Marek
On Sat, Apr 26, 2014 at 3:27 PM, Marek Olšák mar...@gmail.com wrote:
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Intended for use with GL_ARB_draw_indirect's DRAW_INDIRECT_BUFFER
target or for D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS.
---
src/gallium/docs/source/screen.rst | 3 +++
src/gallium/include/pipe/p_defines.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 89cbdbf..65885b9 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -354,6 +354,9 @@ resources might be created and handled quite differently.
bound to the graphics pipeline as a shader resource.
* ``PIPE_BIND_COMPUTE_RESOURCE``: A buffer or texture that can be
bound to the compute program as a shader resource.
+* ``PIPE_BIND_COMMAND_ARGS_BUFFER``: A buffer that may be sourced by the
+ GPU command processor. It can contain, for example, the arguments to
+ indirect draw calls.
.. _pipe_usage:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index a3a1ae1..4d5d833 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -350,6 +350,7 @@ enum pipe_flush_flags {
#define PIPE_BIND_GLOBAL (1 18) /* set_global_binding */
#define PIPE_BIND_SHADER_RESOURCE (1 19) /* set_shader_resources */
#define PIPE_BIND_COMPUTE_RESOURCE (1 20) /* set_compute_resources */
+#define PIPE_BIND_COMMAND_ARGS_BUFFER (1 21) /* pipe_draw_info.indirect
*/
/* The first two flags above were previously part of the amorphous
* TEXTURE_USAGE, most of which are now descriptions of the ways a
--
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 v3 3/3] Add a new capabilities for drivers that can't share buffers
2014-06-16 14:47 GMT+02:00 Marek Olšák mar...@gmail.com:
Does the new CAP cover resource_from_handle or resource_get_handle or both?
It covers both.
Giovanni
Marek
On Sun, Jun 15, 2014 at 1:49 PM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
From: Giovanni Campagna gcampa...@src.gnome.org
The kms-dri swrast driver cannot share buffers using the GEM,
so it must tell the loader to disable extensions relying on
that, without disabling the image DRI extension altogheter
(which would prevent the loader from working at all).
This requires a new gallium capability (which is queried on
the pipe_screen and for swrast drivers it's forwared to the
winsys), and requires a new version of the DRI image extension.
---
include/GL/internal/dri_interface.h| 17 +-
src/egl/drivers/dri2/egl_dri2.c| 10 -
src/egl/drivers/dri2/platform_drm.c| 17 +++---
src/gallium/docs/source/screen.rst | 5 -
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen.c | 2 ++
src/gallium/drivers/llvmpipe/lp_screen.c | 7 ++
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++
src/gallium/drivers/r300/r300_screen.c | 1 +
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
src/gallium/drivers/softpipe/sp_screen.c | 7 ++
src/gallium/drivers/svga/svga_screen.c | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
src/gallium/include/state_tracker/sw_winsys.h | 5 +
src/gallium/state_trackers/dri/common/dri_screen.h | 1 +
src/gallium/state_trackers/dri/drm/dri2.c | 23 +++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 26
+++---
21 files changed, 121 insertions(+), 14 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 4d57d0b..fba1cac 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1005,7 +1005,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 8
+#define __DRI_IMAGE_VERSION 9
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -1133,6 +1133,13 @@ enum __DRIChromaSiting {
#define __DRI_IMAGE_ERROR_BAD_PARAMETER 3
/*@}*/
+/**
+ * \name Capabilities that might be returned by
__DRIimageExtensionRec::getCapabilities
+ */
+/*@{*/
+#define __DRI_IMAGE_CAP_GLOBAL_NAMES 1
+/*@}*/
+
typedef struct __DRIimageRec __DRIimage;
typedef struct __DRIimageExtensionRec __DRIimageExtension;
struct __DRIimageExtensionRec {
@@ -1239,6 +1246,14 @@ struct __DRIimageExtensionRec {
enum __DRIChromaSiting vert_siting,
unsigned *error,
void *loaderPrivate);
+
+ /**
+* Query for general capabilities of the driver that concern
+* buffer sharing and image importing.
+*
+* \since 9
+*/
+ int (*getCapabilities)(__DRIscreen *screen);
};
diff --git a/src/egl/drivers/dri2/egl_dri2.c
b/src/egl/drivers/dri2/egl_dri2.c
index eb6abfd..132ebff 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -520,7 +520,15 @@ dri2_setup_screen(_EGLDisplay *disp)
}
if (dri2_dpy-image) {
- disp-Extensions.MESA_drm_image = EGL_TRUE;
+ if (dri2_dpy-image-base.version = 9
+ dri2_dpy-image-getCapabilities != NULL) {
+ int capabilities;
+
+ capabilities =
dri2_dpy-image-getCapabilities(dri2_dpy-dri_screen);
+ disp-Extensions.MESA_drm_image = (capabilities
__DRI_IMAGE_CAP_GLOBAL_NAMES) != 0;
+ } else
+ disp-Extensions.MESA_drm_image = EGL_TRUE;
+
disp-Extensions.KHR_image_base = EGL_TRUE;
disp-Extensions.KHR_gl_renderbuffer_image = EGL_TRUE;
if (dri2_dpy-image-base.version = 5
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index 6a0dcd3..633b2ab 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -270,7 +270,10 @@ back_bo_to_dri_buffer(struct dri2_egl_surface
*dri2_surf, __DRIbuffer *buffer)
bo = (struct gbm_dri_bo *) dri2_surf-back-bo;
- dri2_dpy-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_NAME, name);
+ if (dri2_surf-base.Resource.Display-Extensions.MESA_drm_image)
+ dri2_dpy-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_NAME,
name);
+ else
+
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
2014-06-16 7:47 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Sun, 15 Jun 2014 13:49:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Hi, this sounds cool work to me, sorry I can't really review it. Does this work also help in getting llvmpipe working with the egl_dri2 loader? If you mean in wayland, unfortunately no. Each egl platform has to implement buffer uploading differently, so the code paths are different. This patchset only tackles the DRM platform, which means mutter, weston and other wayland compositors can run with llvmpipe, but their clients will not have working egl. AFAIU, currently on EGL-Wayland the only way to use llvmpipe is to use egl_gallium.so as the loader, and I don't really know what it would take to make egl_dri2 work there, apart from the Wayland-specific bits, so I was kind of hoping your work would make that easier to implement. In the end, the simple way is to implement swrastGetImage and swrastPutImage for the wayland platform, using an shm backed buffer. It would look similar to the platform_drm side (because the way drm and wayland do double buffering is quite similar, and because both are incapable of front-buffer rendering, single-buffer rendering or rendering to foreign windows), but no real code sharing. OTOH, in wayland buffer sharing exists, so it would be hugely inefficient to implement swrast support this way (it incures one extra copy, from the malloc backbuffer to the shm fake frontbuffer). It should be possible to design an swrast2 interface in terms of shm FDs, similar to prime/dma-buf FDs, and with similar semantics, just nobody is working on it right now. Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] R600/SI: add Gather4 intrinsics (v2)
On 06/16/2014 08:45 AM, Tom Stellard wrote: You don't need to add new SDNodes for all these instructions, you can just use the intrinsic directly in the pattern. The only reason to add SDNodes, is if there are optimizations / special lowering we can do for these instructions. I kind of like having everything consistently use an SDNode ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80115] New: MESA_META_DRAW_BUFFERS induced GL_INVALID_VALUE errors
https://bugs.freedesktop.org/show_bug.cgi?id=80115
Priority: medium
Bug ID: 80115
Assignee: mesa-dev@lists.freedesktop.org
Summary: MESA_META_DRAW_BUFFERS induced GL_INVALID_VALUE errors
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: jpsinthe...@verizon.net
Hardware: x86 (IA32)
Status: NEW
Version: 10.2
Component: Mesa core
Product: Mesa
Hi,
After upgrading to mesa-10.2.1, I began to see a lot of GL_INVALID_VALUE errors
under kde, eg,
kwin(982) KWin::checkGLError: GL error ( PostPaint ): GL_INVALID_VALUE
With mesa-10.1.5, no such errors occur. Modifying a MESA_DEBUG message in
mesa-10.2.1/src/mesa/main/buffers.c:_mesa_DrawBuffers():303 to print actual
values, gives
Mesa: User error: GL_INVALID_VALUE in glDrawBuffersARB(n: 8
Const.MaxDrawBuffers: 1)
kwin(908) KWin::checkGLError: GL error ( update texture ): GL_INVALID_VALUE
It turns out that the problem appears in the mesa-10.2.1-rc1 -
mesa-10.2.1-rc2, transition, with this set of commits:
2014-05-07 meta: Only clear the requested color buffers.
Kenneth Graunke 1 -2/+49
2014-05-07 meta: Add infrastructure for saving/restoring the DrawBuffers state.
Kenneth Graunke 2 -0/+42
2014-05-07 meta: Add a new MESA_META_DRAW_BUFFERS bit.
Kenneth Graunke 4 -4/+6
I have a bunch of laptops, mostly kinda old, and several have radeon graphics
controllers, eg, RV200/M7 [Mobility Radeon 7500]. It turns out that the
MESA_META_DRAW_BUFFERS commit (specifically, the Add infrastructure for
saving/restoring .. commit) uses MAX_DRAW_BUFFERS, and passes this value to
_mesa_DrawBuffers():
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 36150a5..7c84c33 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1176,6 +1211,10 @@ _mesa_meta_end(struct gl_context *ctx)
ctx-CurrentRenderbuffer-Name != save-RenderbufferName)
_mesa_BindRenderbuffer(GL_RENDERBUFFER, save-RenderbufferName);
+ if (state MESA_META_DRAW_BUFFERS) {
+ _mesa_DrawBuffers(MAX_DRAW_BUFFERS, save-ColorDrawBuffers);
+ }
+
ctx-Meta-SaveStackDepth--;
Then, in mesa-10.2.1/src/mesa/main/buffers.c:_mesa_DrawBuffers():303, we have
315 * From the OpenGL 3.0 specification, page 258:
316 * An INVALID_VALUE error is generated if n is greater than
317 * MAX_DRAW_BUFFERS.
318 */
319if (n 0 || n (GLsizei) ctx-Const.MaxDrawBuffers) {
320 _mesa_error(ctx, GL_INVALID_VALUE, glDrawBuffersARB(n));
321 return;
322}
For the radeon case, ctx-Const.MaxDrawBuffers = 1, while MAX_DRAW_BUFFERS = 8,
hence the error.
As a quick fix to have mesa-10.2.1 usable for radeon controllers, I use a
simple patch:
---
Attempting to draw MAX_DRAW_BUFFERS here results in many INVALID_VALUE errors
in _mesa_DrawBuffers(), at least for [AMD/ATI] RV200/M7 [Mobility Radeon 7500]
chips (Radeon driver) where ctx-Const.MaxDrawBuffers=1 is less than
MAX_DRAW_BUFFERS.
Do not try to draw more saved color buffers than we actually have saved.
diff -Npur mesa-10.2.1.old/src/mesa/drivers/common/meta.c
mesa-10.2.1.new/src/mesa/drivers/common/meta.c
--- mesa-10.2.1.old/src/mesa/drivers/common/meta.c 2014-05-30
18:09:47.0 -0400
+++ mesa-10.2.1.new/src/mesa/drivers/common/meta.c 2014-06-16
19:57:14.505961190 -0400
@@ -1213,7 +1213,10 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_BindRenderbuffer(GL_RENDERBUFFER, save-RenderbufferName);
if (state MESA_META_DRAW_BUFFERS) {
- _mesa_DrawBuffers(MAX_DRAW_BUFFERS, save-ColorDrawBuffers);
+ int c = 0;
+ while (save-ColorDrawBuffers[c] c sizeof(save-ColorDrawBuffers))
+ ++c;
+ _mesa_DrawBuffers(c, save-ColorDrawBuffers);
}
ctx-Meta-SaveStackDepth--;
---
As long as memset() is used
(mesa-10.2.1/src/mesa/drivers/common/meta.c:_mesa_meta_begin():796):
802 memset(save-ColorDrawBuffers, 0, sizeof(save-ColorDrawBuffers));
this appears to be safe, however, maybe it would be more efficient to save the
actual number of saved buffers (real_color_buffers in meta.c) in a new
parameter under ctx?
thanks much for your time, and the great software,
John
john@juluka: ~
$ cat 00-mesa-10.2.1-GL_INVALID_VALUE.br
Hi,
After upgrading to mesa-10.2.1, I began to see a lot of GL_INVALID_VALUE errors
under kde, eg,
kwin(982) KWin::checkGLError: GL error ( PostPaint ): GL_INVALID_VALUE
With mesa-10.1.5, no such errors occur. Modifying a MESA_DEBUG message in
mesa-10.2.1/src/mesa/main/buffers.c:_mesa_DrawBuffers():303 to print actual
values, gives
Mesa: User error: GL_INVALID_VALUE in glDrawBuffersARB(n: 8
Const.MaxDrawBuffers: 1)
kwin(908) KWin::checkGLError: GL error ( update texture ): GL_INVALID_VALUE
It turns out that the problem appears in the mesa-10.2.1-rc1 -
mesa-10.2.1-rc2, transition, with this set of
[Mesa-dev] [Bug 80115] MESA_META_DRAW_BUFFERS induced GL_INVALID_VALUE errors
https://bugs.freedesktop.org/show_bug.cgi?id=80115 --- Comment #1 from jpsinthe...@verizon.net --- oops, pasted in description twice; sorry about that.. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: pass ARB_conservative_depth parameters to the hardware
On 17.06.2014 00:08, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com Reviewed-by: Michel Dänzer michel.daen...@amd.com -- 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
[Mesa-dev] [PATCH 3/3] mesa: Don't allow GL_TEXTURE_{LUMINANCE, INTENSITY}_* queries outside compat profile
From: Ian Romanick ian.d.roman...@intel.com There are no queries for GL_TEXTURE_LUMINANCE_SIZE, GL_TEXTURE_INTENSITY_SIZE, GL_TEXTURE_LUMINANCE_TYPE, or GL_TEXTURE_INTENSITY_TYPE in any version of OpenGL ES or desktop OpenGL core profile. NOTE: Without changes to piglit, this regresses required-sized-texture-formats. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/mesa/main/texparam.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c index f67745b..38267e9 100644 --- a/src/mesa/main/texparam.c +++ b/src/mesa/main/texparam.c @@ -1070,8 +1070,11 @@ get_tex_level_parameter_image(struct gl_context *ctx, case GL_TEXTURE_GREEN_SIZE: case GL_TEXTURE_BLUE_SIZE: case GL_TEXTURE_ALPHA_SIZE: + break; case GL_TEXTURE_INTENSITY_SIZE: case GL_TEXTURE_LUMINANCE_SIZE: + if (ctx-API != API_OPENGL_COMPAT) + goto invalid_pname; break; case GL_TEXTURE_DEPTH_SIZE_ARB: if (!ctx-Extensions.ARB_depth_texture) @@ -1087,12 +1090,15 @@ get_tex_level_parameter_image(struct gl_context *ctx, case GL_TEXTURE_COMPRESSED_IMAGE_SIZE: case GL_TEXTURE_COMPRESSED: break; + case GL_TEXTURE_LUMINANCE_TYPE_ARB: + case GL_TEXTURE_INTENSITY_TYPE_ARB: + if (ctx-API != API_OPENGL_COMPAT) + goto invalid_pname; + /* FALLTHROUGH */ case GL_TEXTURE_RED_TYPE_ARB: case GL_TEXTURE_GREEN_TYPE_ARB: case GL_TEXTURE_BLUE_TYPE_ARB: case GL_TEXTURE_ALPHA_TYPE_ARB: - case GL_TEXTURE_LUMINANCE_TYPE_ARB: - case GL_TEXTURE_INTENSITY_TYPE_ARB: case GL_TEXTURE_DEPTH_TYPE_ARB: if (!ctx-Extensions.ARB_texture_float) goto invalid_pname; -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: Generate pname-based errors from glGetTexLevelParameter first
From: Ian Romanick ian.d.roman...@intel.com
Previously, calling
glGenTextures(1, t);
glBindTexture(GL_TEXTURE_2D, t);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, 0xDEADBEEF, value);
would not generate an error.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texparam.c | 63 +++-
1 file changed, 52 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index dc17ea5..565c1d6 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1053,6 +1053,58 @@ get_tex_level_parameter_image(struct gl_context *ctx,
const struct gl_texture_image *img = NULL;
mesa_format texFormat;
+ /* Generate pname errors now. OpenGL 4.0 requires special behavior if the
+* image is undefined, but that does not supersede pname-based errors.
+*/
+ switch (pname) {
+ case GL_TEXTURE_WIDTH:
+ case GL_TEXTURE_HEIGHT:
+ case GL_TEXTURE_DEPTH:
+ case GL_TEXTURE_INTERNAL_FORMAT:
+ case GL_TEXTURE_BORDER:
+ case GL_TEXTURE_RED_SIZE:
+ case GL_TEXTURE_GREEN_SIZE:
+ case GL_TEXTURE_BLUE_SIZE:
+ case GL_TEXTURE_ALPHA_SIZE:
+ case GL_TEXTURE_INTENSITY_SIZE:
+ case GL_TEXTURE_LUMINANCE_SIZE:
+ break;
+ case GL_TEXTURE_DEPTH_SIZE_ARB:
+ if (!ctx-Extensions.ARB_depth_texture)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_STENCIL_SIZE:
+ break;
+ case GL_TEXTURE_SHARED_SIZE:
+ if (ctx-Version 30
+ !ctx-Extensions.EXT_texture_shared_exponent)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_COMPRESSED_IMAGE_SIZE:
+ case GL_TEXTURE_COMPRESSED:
+ break;
+ case GL_TEXTURE_RED_TYPE_ARB:
+ case GL_TEXTURE_GREEN_TYPE_ARB:
+ case GL_TEXTURE_BLUE_TYPE_ARB:
+ case GL_TEXTURE_ALPHA_TYPE_ARB:
+ case GL_TEXTURE_LUMINANCE_TYPE_ARB:
+ case GL_TEXTURE_INTENSITY_TYPE_ARB:
+ case GL_TEXTURE_DEPTH_TYPE_ARB:
+ if (!ctx-Extensions.ARB_texture_float)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_SAMPLES:
+ if (!ctx-Extensions.ARB_texture_multisample)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_FIXED_SAMPLE_LOCATIONS:
+ if (!ctx-Extensions.ARB_texture_multisample)
+ goto invalid_pname;
+ break;
+ default:
+ goto invalid_pname;
+ }
+
img = _mesa_select_tex_image(ctx, texObj, target, level);
if (!img || img-TexFormat == MESA_FORMAT_NONE) {
/* In case of undefined texture image return the default values.
@@ -1135,17 +1187,12 @@ get_tex_level_parameter_image(struct gl_context *ctx,
}
break;
case GL_TEXTURE_DEPTH_SIZE_ARB:
- if (!ctx-Extensions.ARB_depth_texture)
-goto invalid_pname;
*params = _mesa_get_format_bits(texFormat, pname);
break;
case GL_TEXTURE_STENCIL_SIZE:
*params = _mesa_get_format_bits(texFormat, pname);
break;
case GL_TEXTURE_SHARED_SIZE:
- if (ctx-Version 30
- !ctx-Extensions.EXT_texture_shared_exponent)
-goto invalid_pname;
*params = texFormat == MESA_FORMAT_R9G9B9E5_FLOAT ? 5 : 0;
break;
@@ -1173,8 +1220,6 @@ get_tex_level_parameter_image(struct gl_context *ctx,
case GL_TEXTURE_LUMINANCE_TYPE_ARB:
case GL_TEXTURE_INTENSITY_TYPE_ARB:
case GL_TEXTURE_DEPTH_TYPE_ARB:
- if (!ctx-Extensions.ARB_texture_float)
-goto invalid_pname;
if (_mesa_base_format_has_channel(img-_BaseFormat, pname))
*params = _mesa_get_format_datatype(texFormat);
else
@@ -1183,14 +1228,10 @@ get_tex_level_parameter_image(struct gl_context *ctx,
/* GL_ARB_texture_multisample */
case GL_TEXTURE_SAMPLES:
- if (!ctx-Extensions.ARB_texture_multisample)
-goto invalid_pname;
*params = img-NumSamples;
break;
case GL_TEXTURE_FIXED_SAMPLE_LOCATIONS:
- if (!ctx-Extensions.ARB_texture_multisample)
-goto invalid_pname;
*params = img-FixedSampleLocations;
break;
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: Don't allow GL_TEXTURE_BORDER queries outside compat profile
From: Ian Romanick ian.d.roman...@intel.com There are no texture borders in any version of OpenGL ES or desktop OpenGL core profile. Fixes piglit's gl-3.2-texture-border-deprecated. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/mesa/main/texparam.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c index 565c1d6..f67745b 100644 --- a/src/mesa/main/texparam.c +++ b/src/mesa/main/texparam.c @@ -1061,7 +1061,11 @@ get_tex_level_parameter_image(struct gl_context *ctx, case GL_TEXTURE_HEIGHT: case GL_TEXTURE_DEPTH: case GL_TEXTURE_INTERNAL_FORMAT: + break; case GL_TEXTURE_BORDER: + if (ctx-API != API_OPENGL_COMPAT) + goto invalid_pname; + break; case GL_TEXTURE_RED_SIZE: case GL_TEXTURE_GREEN_SIZE: case GL_TEXTURE_BLUE_SIZE: -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] R600/SI: add Gather4 intrinsics (v2)
Is there any specific reason for using SDNodes for everything? Using intrinsics directly in patterns seems to result in a smaller amount of code, which is always good. Marek On Mon, Jun 16, 2014 at 8:12 PM, Matt Arsenault matthew.arsena...@amd.com wrote: On 06/16/2014 08:45 AM, Tom Stellard wrote: You don't need to add new SDNodes for all these instructions, you can just use the intrinsic directly in the pattern. The only reason to add SDNodes, is if there are optimizations / special lowering we can do for these instructions. I kind of like having everything consistently use an SDNode ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ Open source project]
Hi, I am new to mesa and interested in working on open source project. I have good knowledge about OpenGL and GLSL functionality. From the list, I want to work on Improved application of GLSL compiler optimization . What should I do to pick it? Can you help me with some documentation which can be useful for accomplishing the task ? Also, I am unclear about the second point in the description Find a static ordering, with possible repeats, of optimization passes that does not compromise the quality of the generated code. Measure the before and after speed of compiling a large set of real-world shaders It would be great if someone can explain it, what needs to be done. -- Thanks, Roshan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] nvc0: remove vport_int hack and instead use the usual state validation
Commit ad4dc772 fixed an issue with the viewport not being restored
correctly. However it's rather hackish and confusing. Instead just mark
the viewport dirty and let the viewport validation take care of it.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nvc0/nvc0_context.h| 1 -
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 5 -
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c| 8 +++-
3 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
index 41cee78..052f0ba 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
@@ -202,7 +202,6 @@ struct nvc0_context {
struct pipe_surface *surfaces[2][NVC0_MAX_SURFACE_SLOTS];
uint16_t surfaces_dirty[2];
uint16_t surfaces_valid[2];
- uint32_t vport_int[2];
struct util_dynarray global_residents;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
index 0cc7a52..25a3232 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
@@ -299,11 +299,6 @@ nvc0_validate_viewport(struct nvc0_context *nvc0)
PUSH_DATA (push, (w 16) | x);
PUSH_DATA (push, (h 16) | y);
- if (i == 0) {
- nvc0-vport_int[0] = (w 16) | x;
- nvc0-vport_int[1] = (h 16) | y;
- }
-
zmin = vp-translate[2] - fabsf(vp-scale[2]);
zmax = vp-translate[2] + fabsf(vp-scale[2]);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index f782eec..a29f0cc 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -1012,11 +1012,13 @@ nvc0_blitctx_post_blit(struct nvc0_blitctx *blit)
nvc0-dirty = blit-saved.dirty |
(NVC0_NEW_FRAMEBUFFER | NVC0_NEW_SCISSOR | NVC0_NEW_SAMPLE_MASK |
NVC0_NEW_RASTERIZER | NVC0_NEW_ZSA | NVC0_NEW_BLEND |
+ NVC0_NEW_VIEWPORT |
NVC0_NEW_TEXTURES | NVC0_NEW_SAMPLERS |
NVC0_NEW_VERTPROG | NVC0_NEW_FRAGPROG |
NVC0_NEW_TCTLPROG | NVC0_NEW_TEVLPROG | NVC0_NEW_GMTYPROG |
NVC0_NEW_TFB_TARGETS | NVC0_NEW_VERTEX | NVC0_NEW_ARRAYS);
nvc0-scissors_dirty |= 1;
+ nvc0-viewports_dirty |= 1;
nvc0-base.pipe.set_min_samples(nvc0-base.pipe, blit-saved.min_samples);
}
@@ -1188,11 +1190,7 @@ nvc0_blit_3d(struct nvc0_context *nvc0, const struct
pipe_blit_info *info)
nvc0_blitctx_post_blit(blit);
- /* restore viewport */
-
- BEGIN_NVC0(push, NVC0_3D(VIEWPORT_HORIZ(0)), 2);
- PUSH_DATA (push, nvc0-vport_int[0]);
- PUSH_DATA (push, nvc0-vport_int[1]);
+ /* restore viewport transform */
IMMED_NVC0(push, NVC0_3D(VIEWPORT_TRANSFORM_EN), 1);
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] nvc0: organize screen caps
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 112 +++--
1 file changed, 51 insertions(+), 61 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 3fdb6ae..52a067e 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -71,6 +71,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
const uint16_t class_3d = nouveau_screen(pscreen)-class_3d;
switch (param) {
+ /* non-boolean caps */
case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
return 15;
@@ -86,6 +87,38 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
return -32;
case PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET:
return 31;
+ case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
+ return 65536;
+ case PIPE_CAP_GLSL_FEATURE_LEVEL:
+ return 330;
+ case PIPE_CAP_MAX_RENDER_TARGETS:
+ return 8;
+ case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
+ return 1;
+ case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
+ return 4;
+ case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
+ case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
+ return 128;
+ case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+ case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+ return 1024;
+ case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
+ return 256;
+ case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
+ return 1; /* 256 for binding as RT, but that's not possible in GL */
+ case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
+ return NOUVEAU_MIN_BUFFER_MAP_ALIGN;
+ case PIPE_CAP_MAX_VIEWPORTS:
+ return NVC0_MAX_VIEWPORTS;
+ case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
+ return 4;
+ case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
+ return PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50;
+ case PIPE_CAP_ENDIANNESS:
+ return PIPE_ENDIAN_LITTLE;
+
+ /* supported caps */
case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
case PIPE_CAP_TEXTURE_SWIZZLE:
case PIPE_CAP_TEXTURE_SHADOW_MAP:
@@ -96,54 +129,24 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_CUBE_MAP_ARRAY:
case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
case PIPE_CAP_TEXTURE_MULTISAMPLE:
- return 1;
- case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
- return 65536;
- case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
- return (class_3d = NVE4_3D_CLASS) ? 1 : 0;
case PIPE_CAP_TWO_SIDED_STENCIL:
case PIPE_CAP_DEPTH_CLIP_DISABLE:
case PIPE_CAP_POINT_SPRITE:
case PIPE_CAP_TGSI_TEXCOORD:
- return 1;
case PIPE_CAP_SM3:
- return 1;
- case PIPE_CAP_GLSL_FEATURE_LEVEL:
- return 330;
- case PIPE_CAP_MAX_RENDER_TARGETS:
- return 8;
- case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
- return 1;
case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
case PIPE_CAP_VERTEX_COLOR_CLAMPED:
- return 1;
case PIPE_CAP_QUERY_TIMESTAMP:
case PIPE_CAP_QUERY_TIME_ELAPSED:
case PIPE_CAP_OCCLUSION_QUERY:
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
- return 1;
- case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
- return 4;
- case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
- case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
- return 128;
- case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
- case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
- return 1024;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
case PIPE_CAP_INDEP_BLEND_ENABLE:
case PIPE_CAP_INDEP_BLEND_FUNC:
- return 1;
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
- return 1;
- case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
- case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
- return 0;
- case PIPE_CAP_SHADER_STENCIL_EXPORT:
- return 0;
case PIPE_CAP_PRIMITIVE_RESTART:
case PIPE_CAP_TGSI_INSTANCEID:
case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR:
@@ -153,49 +156,36 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
case PIPE_CAP_START_INSTANCE:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
- return 1;
- case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
- return 0; /* state trackers will know better */
case PIPE_CAP_USER_CONSTANT_BUFFERS:
case PIPE_CAP_USER_INDEX_BUFFERS:
case PIPE_CAP_USER_VERTEX_BUFFERS:
+ case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
+ case PIPE_CAP_TEXTURE_QUERY_LOD:
+ case PIPE_CAP_SAMPLE_SHADING:
+ case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
+ case PIPE_CAP_TEXTURE_GATHER_SM5:
return 1;
- case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
- return 256;
- case
[Mesa-dev] [PATCH 3/3] nv50: organize screen caps
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 124 -
1 file changed, 57 insertions(+), 67 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 015f139..c09a8c6 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -85,6 +85,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
const uint16_t class_3d = nouveau_screen(pscreen)-class_3d;
switch (param) {
+ /* non-boolean caps */
case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
return 14;
case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
@@ -99,6 +100,38 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET:
case PIPE_CAP_MAX_TEXEL_OFFSET:
return 7;
+ case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
+ return 65536;
+ case PIPE_CAP_GLSL_FEATURE_LEVEL:
+ return 330;
+ case PIPE_CAP_MAX_RENDER_TARGETS:
+ return 8;
+ case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
+ return 1;
+ case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
+ return 4;
+ case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
+ case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
+ return 64;
+ case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+ case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+ return 1024;
+ case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
+ return 256;
+ case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
+ return 1; /* 256 for binding as RT, but that's not possible in GL */
+ case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
+ return NOUVEAU_MIN_BUFFER_MAP_ALIGN;
+ case PIPE_CAP_MAX_VIEWPORTS:
+ return NV50_MAX_VIEWPORTS;
+ case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
+ return PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50;
+ case PIPE_CAP_ENDIANNESS:
+ return PIPE_ENDIAN_LITTLE;
+ case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
+ return (class_3d = NVA3_3D_CLASS) ? 4 : 0;
+
+ /* supported caps */
case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
case PIPE_CAP_TEXTURE_SWIZZLE:
case PIPE_CAP_TEXTURE_SHADOW_MAP:
@@ -107,58 +140,20 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_ANISOTROPIC_FILTER:
case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
- return 1;
- case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
- return 65536;
- case PIPE_CAP_SEAMLESS_CUBE_MAP:
- return 1; /* nv50_screen(pscreen)-tesla-oclass = NVA0_3D_CLASS; */
- case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
- return 0;
- case PIPE_CAP_CUBE_MAP_ARRAY:
- return nv50_screen(pscreen)-tesla-oclass = NVA3_3D_CLASS;
case PIPE_CAP_TWO_SIDED_STENCIL:
case PIPE_CAP_DEPTH_CLIP_DISABLE:
case PIPE_CAP_POINT_SPRITE:
- return 1;
case PIPE_CAP_SM3:
- return 1;
- case PIPE_CAP_GLSL_FEATURE_LEVEL:
- return 330;
- case PIPE_CAP_MAX_RENDER_TARGETS:
- return 8;
- case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
- return 1;
case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
case PIPE_CAP_VERTEX_COLOR_CLAMPED:
- return 1;
case PIPE_CAP_QUERY_TIMESTAMP:
case PIPE_CAP_QUERY_TIME_ELAPSED:
case PIPE_CAP_OCCLUSION_QUERY:
- return 1;
- case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
- return 4;
- case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
- case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
- return 64;
- case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
- case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
- return 1024;
- case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
- return (class_3d = NVA0_3D_CLASS) ? 1 : 0;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
case PIPE_CAP_INDEP_BLEND_ENABLE:
- return 1;
- case PIPE_CAP_INDEP_BLEND_FUNC:
- return nv50_screen(pscreen)-tesla-oclass = NVA3_3D_CLASS;
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
- return 1;
- case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
- case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
- return 0;
- case PIPE_CAP_SHADER_STENCIL_EXPORT:
- return 0;
case PIPE_CAP_PRIMITIVE_RESTART:
case PIPE_CAP_TGSI_INSTANCEID:
case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR:
@@ -167,51 +162,46 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
case PIPE_CAP_START_INSTANCE:
- return 1;
- case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
- return 0; /* state trackers will know better */
case PIPE_CAP_USER_CONSTANT_BUFFERS:
case PIPE_CAP_USER_INDEX_BUFFERS:
case PIPE_CAP_USER_VERTEX_BUFFERS:
+ case PIPE_CAP_TEXTURE_MULTISAMPLE:
+ case
