[Mesa-dev] [PATCH] glsl: Fix uninitialized member in ir_array_splitting_visitor.
Fix uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/opt_array_splitting.cpp |1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/opt_array_splitting.cpp b/src/glsl/opt_array_splitting.cpp
index f11b516..99b6a22 100644
--- a/src/glsl/opt_array_splitting.cpp
+++ b/src/glsl/opt_array_splitting.cpp
@@ -223,6 +223,7 @@ public:
ir_array_splitting_visitor(exec_list *vars)
{
this-variable_list = vars;
+ this-mem_ctx = NULL;
}
virtual ~ir_array_splitting_visitor()
--
1.7.9.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #18 from Michel Dänzer mic...@daenzer.net 2012-04-18 00:00:09 PDT --- (In reply to comment #15) I've published information, requested by Michel. I think you mean Dave, but in the future please include this kind of information in bug reports right away. (In reply to comment #16) This is a real bug in Mesa's configure script. Yeah, sorry I jumped the gun here. [...] there's no way to actually set default_driver in configure.ac, which means architectures that aren't officially blessed for DRI end up with the xlib version of libGL. I wonder if it wouldn't be better to blacklist architectures where DRI really can't work instead, if there are any. Anyway, Dave pushed a fix for this particular problem, so resolving as fixed. (In reply to comment #17) [...] for some reason LIBGL_DEBUG env var is respected and works as intended. So, probably it works only with DRI built libGL. Yeah, I said so in comment #8. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] llvmPipe on ARM (CortexA-9)
Hello, Can we use llvmpipe for arm architecture.(Specifically ARM cortexA-9) ?? I tried found below error. Unhandled instruction encoding format! UNREACHABLE executed at ARMCodeEmitter.cpp:534! Aborted Version used : llvmpipe3.0,Mesa-8.0 Any hint or info will be helpfull. Thanks.. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] llvmPipe on ARM (CortexA-9)
- Original Message -
Hello,
Can we use llvmpipe for arm architecture.(Specifically ARM cortexA-9)
??
It has never been tried before, so have no idea how close it is of working.
I tried found below error.
Unhandled instruction encoding format!
UNREACHABLE executed at ARMCodeEmitter.cpp:534!
Aborted
Version used : llvmpipe3.0,Mesa-8.0
Any hint or info will be helpfull.
You should run inside a debugger and see the stack trace when LLVM aborts.
You can also see the LLVM IR by setting the following env var:
GALLIVM_DEBUG=ir
Or dump it to a file by applying this change:
diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c
b/src/gallium/drivers/llvmpipe/lp_state_fs.c
index ff78b9d..ab37950 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_fs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c
@@ -812,7 +812,7 @@ generate_fragment(struct llvmpipe_context *lp,
}
/* Dump byte code to a file */
- if (0) {
+ if (1) {
LLVMWriteBitcodeToFile(gallivm-module, llvmpipe.bc);
}
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] How to memory map the framebuffer
Hi everybody,
first of all I apologize if this is not the right place for this
question but I couldn't find
any answer in other places and I think this is a good question about
DRI. I also apologize
for the length of the question!
For a security application I'm developing I need direct access to the
framebuffer on the
graphic device under X on both linux and freebsd.
My goal is to memory map the portion of the graphic device memory
where pixel values
are stored just before they are read by the monitor. I need to achieve
this for a couple of
well known architectures that will not change in time (say an ati and
an nvidia specific card).
This would be the best scenario even if it is not really clear to me
if it is really possible at all.
I've spent days trying to figure out how to do that and I've seen that
DRI2 / DRM is probably
what I should use.
By now I've found 3 possible solutions (sorry if two of these
solutions are not DRI related, but maybe
some of you have an answer!). If you are not interested in anything
but DRI you should jump to point 3.
1. Use of the kernel fbdev (/dev/fb0).
Issues:
- 1.a What am I really accessing when reading from /dev/fb0? Is
that really the videocard memory
or some system memory the kernel allocates and keep updated?
- 1.b Capturing /dev/fb0 is not working under X unless fbdev is
specified as videodriver for X. And that is
really really slow!
2. Use of X API and shm extension. This is what screenshot grabber are
usually doing. Basically ask X to get
the pixmap of the screen root drawable and retrieve it by using a
shared memory.
Issues:
- This is working fine actually but it is using X. I would like
something of more low level (that is more reliable
for the security applications). Also I'm not sure of the
pipeline involved in this process.
I guess it is something like: X gets the backbuffer reading
directly from the graphic device and copies it to the
shared memory. Or is it possible that X is accessing some buffer
in system memory that it keeps updated?
(Note that I'm supposing DRI2 and hardware acceleration are
active and runinng).
3. Use of DRI2 infrastructure and DRM. This would be my favourite
solution since I would have the biggest control
over what is happening.
I've made some test and I failed but I feel I'm close to the
solution...but sadly it is not working!
I would really appreciate if you validated this procedure and/or
if you suggested any possible mistake I've made.
So first, DRM seems to be the key...and more precisely, drmMap
function seems to be exactly what I need!
int drmMap(int fd, drmHandle handle, drmSize size, drmAddressPtr address)
I have fd here (I got it by open(/dev/dri/card0)), I need the
handle and the size. After a long search and try
this is what I've found that should work for getting this information:
- I setup a DRI connection using xcb_dri2_connect() and
xcb_dri2_authenticate(). This is working.
- I call xcb_dri2_get_buffers(...) passing as input drawable the
root window of the screen and XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT
as the attachment.This is half working. I receive an answer, width
and height are correct but, the count attribute is 0!
If I call xcb_dri2_create_drawable() with the same drawable,
then the xcb_dri2_get_buffers call returns a good answer, where
count is 5! I can't really understand this..why 5?..but then I go
on with buffer[0] and
- I need to convert the buffer name to an handle to be used for the
drmMap call. So I execute this code I've found googling and
that makes sense to me:
struct drm_gem_open open;
int ret;
open.name = buffer[0].name;
open.handle = 0;
open.size = 0;
do {
ret = ioctl (drmFD, DRM_IOCTL_GEM_OPEN, open);
} while (ret == -1 errno == EINTR);
This code is working with no error and at the end I get open.handle
with a (seems) good value.
- At the end of this I call drmMap(fd, open.handle, open.size,
pointer); but this is returning a negative value :-(
So, Is this a correct way of doing things? The key could really be
that xcb_dri2_get_buffers() is returning count == 0 when
called and I need to call xcb_dri2_create_drawable()...but I think
that this is wrong since X should have created that at the beginning
of the times! Isn't there any other way of retrieving the name of
the root drawable of X?
Last question: even If I'll manage to read the buffer memory mapping
it...will that memory be the final step before
monitor, or there will be some other piece of software moving it
around to some other buffer?
Sorry for the very long post, but I really thing this could be an
instructive thread for a lot of people!
Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
On Tue, 2012-04-17 at 23:53 +1000, jupiter@gmail.com wrote: On 2012-04-17 09:34-0400, Adam Jackson wrote: Note that neither one of the above libraries is mentioned in your ldd output, which means libGL was linked incorrectly. What method did you use to build Mesa? The default of the configuration was used. How should I change the default configure to link libX11-xcb and libxcb-glx properly? That's not the answer I was looking for. When I ask what method did you use I expect a reply more like: I ran ./configure and then make or: I ran 'make linux-dri-x86' - ajax 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
[Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
---
src/mesa/state_tracker/st_context.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.h
b/src/mesa/state_tracker/st_context.h
index da03719..3d41ab5 100644
--- a/src/mesa/state_tracker/st_context.h
+++ b/src/mesa/state_tracker/st_context.h
@@ -42,12 +42,12 @@ struct st_context;
struct st_fragment_program;
-#define ST_NEW_MESA0x1 /* Mesa state has changed */
-#define ST_NEW_FRAGMENT_PROGRAM0x2
-#define ST_NEW_VERTEX_PROGRAM 0x4
-#define ST_NEW_FRAMEBUFFER 0x8
-#define ST_NEW_EDGEFLAGS_DATA 0x10
-#define ST_NEW_GEOMETRY_PROGRAM0x20
+#define ST_NEW_MESA(1 0) /* Mesa state has changed */
+#define ST_NEW_FRAGMENT_PROGRAM(1 1)
+#define ST_NEW_VERTEX_PROGRAM (1 2)
+#define ST_NEW_FRAMEBUFFER (1 3)
+#define ST_NEW_EDGEFLAGS_DATA (1 4)
+#define ST_NEW_GEOMETRY_PROGRAM(1 5)
struct st_state_flags {
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] mesa: only update _MaxElement when we actually need it
---
src/mesa/main/state.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index b019266..2e9f021 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -561,8 +561,10 @@ _mesa_update_state_locked( struct gl_context *ctx )
new_prog_state |= update_program( ctx );
}
- if (new_state (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT))
+ if (ctx-Const.CheckArrayBounds
+ (new_state (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT))) {
_mesa_update_array_object_max_element(ctx, ctx-Array.ArrayObj);
+ }
out:
new_prog_state |= update_program_constants(ctx);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] mesa, vbo: properly detect when vertex arrays need to be recalculated
This moves the RebindArrays flag into the vbo module, consolidates the code,
and adds missing vbo_draw_method calls.
Also with this change, the vertex arrays are not needlessly recalculated twice.
The issue with the old code was:
- If recalculate_input_bindings updates vp_varying_inputs, _NEW_ARRAY is set.
- _mesa_update_state is called and the vp_varying_inputs change causes
regeneration of the fixed-function shaders, which also sets _NEW_PROGRAM.
- The occurence of either _NEW_ARRAY or _NEW_PROGRAM sets
the recalculate_inputs flag to TRUE again.
- The new code sets the flag to FALSE after the second _mesa_update_state,
because there can't possibly be any change which would require recalculating
the arrays.
---
src/mesa/main/attrib.c|3 --
src/mesa/main/mtypes.h|1 -
src/mesa/main/state.c |2 -
src/mesa/vbo/vbo_exec.c |4 +++
src/mesa/vbo/vbo_exec.h |1 +
src/mesa/vbo/vbo_exec_array.c | 59 ++---
6 files changed, 25 insertions(+), 45 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 7042312..9b90b05 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1448,9 +1448,6 @@ restore_array_attrib(struct gl_context *ctx,
_mesa_BindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB,
src-ArrayObj-ElementArrayBufferObj-Name);
- /* Better safe than sorry?! */
- dest-RebindArrays = GL_TRUE;
-
/* FIXME: Should some bits in ctx-Array-NewState also be set
* FIXME: here? It seems like it should be set to inclusive-or
* FIXME: of the old ArrayObj-_Enabled and the new _Enabled.
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index bfa320a..e1afdbc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1632,7 +1632,6 @@ struct gl_array_attrib
GLuint RestartIndex;
GLbitfield64 NewState; /** mask of VERT_BIT_* values */
- GLboolean RebindArrays; /** whether the VBO module should rebind arrays */
/* GL_ARB_vertex_buffer_object */
struct gl_buffer_object *ArrayBufferObj;
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 2e9f021..c953efc 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -582,8 +582,6 @@ _mesa_update_state_locked( struct gl_context *ctx )
ctx-NewState = 0;
ctx-Driver.UpdateState(ctx, new_state);
ctx-Array.NewState = 0;
- if (!ctx-Array.RebindArrays)
- ctx-Array.RebindArrays = (new_state (_NEW_ARRAY | _NEW_PROGRAM)) != 0;
}
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index 05c3ec1..fd5e0f8 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -85,6 +85,10 @@ void vbo_exec_invalidate_state( struct gl_context *ctx,
GLuint new_state )
{
struct vbo_exec_context *exec = vbo_context(ctx)-exec;
+ if (new_state (_NEW_PROGRAM|_NEW_ARRAY)) {
+ exec-array.recalculate_inputs = GL_TRUE;
+ }
+
if (new_state (_NEW_PROGRAM|_NEW_EVAL))
exec-eval.recalculate_maps = 1;
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index f6ede99..5cdf5ce 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -141,6 +141,7 @@ struct vbo_exec_context
* programs:
*/
const struct gl_client_array *inputs[VERT_ATTRIB_MAX];
+ GLboolean recalculate_inputs;
} array;
/* Which flags to set in vbo_exec_BeginVertices() */
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index b0a4261..d9003c2 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -529,12 +529,25 @@ recalculate_input_bindings(struct gl_context *ctx)
void
vbo_bind_arrays(struct gl_context *ctx)
{
- if (!ctx-Array.RebindArrays) {
- return;
- }
+ struct vbo_context *vbo = vbo_context(ctx);
+ struct vbo_exec_context *exec = vbo-exec;
+
+ vbo_draw_method(exec, DRAW_ARRAYS);
- recalculate_input_bindings(ctx);
- ctx-Array.RebindArrays = GL_FALSE;
+ if (exec-array.recalculate_inputs) {
+ recalculate_input_bindings(ctx);
+
+ /* Again... because we may have changed the bitmask of per-vertex varying
+ * attributes. If we regenerate the fixed-function vertex program now
+ * we may be able to prune down the number of vertex attributes which we
+ * need in the shader.
+ */
+ if (ctx-NewState) {
+ _mesa_update_state(ctx);
+ }
+
+ exec-array.recalculate_inputs = GL_FALSE;
+ }
}
@@ -554,16 +567,6 @@ vbo_draw_arrays(struct gl_context *ctx, GLenum mode, GLint
start,
vbo_bind_arrays(ctx);
- vbo_draw_method(exec, DRAW_ARRAYS);
-
- /* Again... because we may have changed the bitmask of per-vertex varying
-* attributes. If we regenerate the fixed-function vertex program now
-* we may be able to prune down the number of vertex attributes which we
-* need in the shader.
-*/
- if (ctx-NewState)
-
[Mesa-dev] [PATCH 04/10] mesa: add _NEW_VARYING_VP_INPUTS for gl_context::varying_vp_inputs
This is a frequently-updated state and _NEW_ARRAY already causes revalidation
of the vbo module. It's kinda counter-productive to recompute arrays
in the vbo module if _NEW_ARRAY is set and then set _NEW_ARRAY again.
---
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/mtypes.h |1 +
src/mesa/main/state.c| 11 ++-
src/mesa/vbo/vbo_exec_array.c|4 ++--
src/mesa/vbo/vbo_exec_draw.c |2 +-
5 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 3c91b1a..8a42281 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -337,7 +337,7 @@ static GLbitfield get_fp_input_mask( struct gl_context *ctx
)
}
else if (!(vertexProgram || vertexShader)) {
/* Fixed function vertex logic */
- /* _NEW_ARRAY */
+ /* _NEW_VARYING_VP_INPUTS */
GLbitfield64 varying_inputs = ctx-varying_vp_inputs;
/* These get generated in the setup routine regardless of the
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index e1afdbc..f277307 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3062,6 +3062,7 @@ struct gl_matrix_stack
#define _NEW_BUFFER_OBJECT (1 28)
#define _NEW_FRAG_CLAMP(1 29)
#define _NEW_TRANSFORM_FEEDBACK (1 30) /** gl_context::TransformFeedback */
+#define _NEW_VARYING_VP_INPUTS (1 31) /** gl_context::varying_vp_inputs */
#define _NEW_ALL ~0
/**
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index c953efc..627bf83 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -473,12 +473,13 @@ _mesa_update_state_locked( struct gl_context *ctx )
/* Determine which state flags effect vertex/fragment program state */
if (ctx-FragmentProgram._MaintainTexEnvProgram) {
prog_flags |= (_NEW_BUFFERS | _NEW_TEXTURE | _NEW_FOG |
-_NEW_ARRAY | _NEW_LIGHT | _NEW_POINT | _NEW_RENDERMODE |
-_NEW_PROGRAM | _NEW_FRAG_CLAMP | _NEW_COLOR);
+_NEW_VARYING_VP_INPUTS | _NEW_LIGHT | _NEW_POINT |
+_NEW_RENDERMODE | _NEW_PROGRAM | _NEW_FRAG_CLAMP |
+_NEW_COLOR);
}
if (ctx-VertexProgram._MaintainTnlProgram) {
- prog_flags |= (_NEW_ARRAY | _NEW_TEXTURE | _NEW_TEXTURE_MATRIX |
- _NEW_TRANSFORM | _NEW_POINT |
+ prog_flags |= (_NEW_VARYING_VP_INPUTS | _NEW_TEXTURE |
+ _NEW_TEXTURE_MATRIX | _NEW_TRANSFORM | _NEW_POINT |
_NEW_FOG | _NEW_LIGHT |
_MESA_NEW_NEED_EYE_COORDS);
}
@@ -626,7 +627,7 @@ _mesa_set_varying_vp_inputs( struct gl_context *ctx,
{
if (ctx-varying_vp_inputs != varying_inputs) {
ctx-varying_vp_inputs = varying_inputs;
- ctx-NewState |= _NEW_ARRAY;
+ ctx-NewState |= _NEW_VARYING_VP_INPUTS;
/*printf(%s %x\n, __FUNCTION__, varying_inputs);*/
}
}
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index d9003c2..2e324a2 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -523,8 +523,8 @@ recalculate_input_bindings(struct gl_context *ctx)
* Examine the enabled vertex arrays to set the exec-array.inputs[] values.
* These will point to the arrays to actually use for drawing. Some will
* be user-provided arrays, other will be zero-stride const-valued arrays.
- * Note that this might set the _NEW_ARRAY dirty flag so state validation
- * must be done after this call.
+ * Note that this might set the _NEW_VARYING_VP_INPUTS dirty flag so state
+ * validation must be done after this call.
*/
void
vbo_bind_arrays(struct gl_context *ctx)
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index dd5363b..a1d329f 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -388,7 +388,7 @@ vbo_exec_vtx_flush(struct vbo_exec_context *exec, GLboolean
keepUnmapped)
if (exec-vtx.copied.nr != exec-vtx.vert_count) {
struct gl_context *ctx = exec-ctx;
-/* Before the update_state() as this may raise _NEW_ARRAY
+/* Before the update_state() as this may raise _NEW_VARYING_VP_INPUTS
* from _mesa_set_varying_vp_inputs().
*/
vbo_exec_bind_arrays( ctx );
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] mesa: set _NEW_VARYING_VP_INPUTS flag only if fixed-func VP is enabled valid
---
src/mesa/main/state.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 627bf83..6efc45a 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -627,7 +627,16 @@ _mesa_set_varying_vp_inputs( struct gl_context *ctx,
{
if (ctx-varying_vp_inputs != varying_inputs) {
ctx-varying_vp_inputs = varying_inputs;
- ctx-NewState |= _NEW_VARYING_VP_INPUTS;
+
+ /* Only the fixed-func generated programs need to use the flag
+ * and the fixed-func fragment program uses it only if there is also
+ * a fixed-func vertex program, so this only depends on the latter.
+ *
+ * It's okay to check the VP pointer here, because this is called after
+ * _mesa_update_state in the vbo module. */
+ if (ctx-VertexProgram._TnlProgram) {
+ ctx-NewState |= _NEW_VARYING_VP_INPUTS;
+ }
/*printf(%s %x\n, __FUNCTION__, varying_inputs);*/
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] vbo: don't check twice whether it's valid to render
It's already done in _mesa_validate_Draw* and it's not needed to do it again
unless I am missing something.
---
src/mesa/vbo/vbo_exec_array.c | 20
1 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 2e324a2..30a954a 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -644,10 +644,6 @@ vbo_exec_DrawArrays(GLenum mode, GLint start, GLsizei
count)
FLUSH_CURRENT( ctx, 0 );
- if (!_mesa_valid_to_render(ctx, glDrawArrays)) {
- return;
- }
-
if (0)
check_draw_arrays_data(ctx, start, count);
@@ -677,10 +673,6 @@ vbo_exec_DrawArraysInstanced(GLenum mode, GLint start,
GLsizei count,
FLUSH_CURRENT( ctx, 0 );
- if (!_mesa_valid_to_render(ctx, glDrawArraysInstanced)) {
- return;
- }
-
if (0)
check_draw_arrays_data(ctx, start, count);
@@ -770,10 +762,6 @@ vbo_validated_drawrangeelements(struct gl_context *ctx,
GLenum mode,
FLUSH_CURRENT( ctx, 0 );
- if (!_mesa_valid_to_render(ctx, glDraw[Range]Elements)) {
- return;
- }
-
vbo_bind_arrays(ctx);
ib.count = count;
@@ -1050,10 +1038,6 @@ vbo_validated_multidrawelements(struct gl_context *ctx,
GLenum mode,
FLUSH_CURRENT( ctx, 0 );
- if (!_mesa_valid_to_render(ctx, glMultiDrawElements)) {
- return;
- }
-
prim = calloc(1, primcount * sizeof(*prim));
if (prim == NULL) {
_mesa_error(ctx, GL_OUT_OF_MEMORY, glMultiDrawElements);
@@ -1247,10 +1231,6 @@ vbo_exec_DrawTransformFeedback(GLenum mode, GLuint name)
FLUSH_CURRENT(ctx, 0);
- if (!_mesa_valid_to_render(ctx, glDrawTransformFeedback)) {
- return;
- }
-
vbo_draw_transform_feedback(ctx, mode, obj, 1);
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] vbo: remove unused variables in vbo_context
---
src/mesa/vbo/vbo_context.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index 1a1cc92..cae2407 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -71,10 +71,6 @@ struct vbo_context {
GLuint map_vp_none[VERT_ATTRIB_MAX];
GLuint map_vp_arb[VERT_ATTRIB_MAX];
- GLfloat *current[VBO_ATTRIB_MAX]; /* points into ctx-Current,
ctx-Light.Material */
- GLfloat CurrentFloatEdgeFlag;
-
-
struct vbo_exec_context exec;
#if FEATURE_dlist
struct vbo_save_context save;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] vbo: remove vbo_context::legacy_currval
It's not nice when you have several variables pointing to the same array
and you wanna ask your editor where is this used and you only get an answer
for one of the four currval, legacy_currval, generic_currval, mat_currval,
which is quite useless, because you never see the whole picture.
Let's get rid of the additional pointers.
---
src/mesa/vbo/vbo_context.c|3 +--
src/mesa/vbo/vbo_context.h|3 +--
src/mesa/vbo/vbo_exec_api.c |4 ++--
src/mesa/vbo/vbo_exec_array.c |8
src/mesa/vbo/vbo_exec_draw.c |4 ++--
src/mesa/vbo/vbo_save.c |4 ++--
src/mesa/vbo/vbo_save_draw.c |4 ++--
7 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index d83f2fd..2b31b62 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -47,7 +47,7 @@ static GLuint check_size( const GLfloat *attr )
static void init_legacy_currval(struct gl_context *ctx)
{
struct vbo_context *vbo = vbo_context(ctx);
- struct gl_client_array *arrays = vbo-legacy_currval;
+ struct gl_client_array *arrays = vbo-currval[VBO_ATTRIB_POS];
GLuint i;
memset(arrays, 0, sizeof(*arrays) * VERT_ATTRIB_FF_MAX);
@@ -162,7 +162,6 @@ GLboolean _vbo_CreateContext( struct gl_context *ctx )
/* TODO: remove these pointers.
*/
- vbo-legacy_currval = vbo-currval[VBO_ATTRIB_POS];
vbo-generic_currval = vbo-currval[VBO_ATTRIB_GENERIC0];
vbo-mat_currval = vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT];
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index cae2407..77010b8 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -61,9 +61,8 @@
struct vbo_context {
struct gl_client_array currval[VBO_ATTRIB_MAX];
- /* These point into the above. TODO: remove.
+ /* These point into the above. TODO: remove.
*/
- struct gl_client_array *legacy_currval;
struct gl_client_array *generic_currval;
struct gl_client_array *mat_currval;
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 3061990..8a16804 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -1089,14 +1089,14 @@ void vbo_exec_vtx_init( struct vbo_exec_context *exec )
struct gl_client_array *arrays = exec-vtx.arrays;
unsigned i;
- memcpy(arrays, vbo-legacy_currval,
+ memcpy(arrays, vbo-currval[VBO_ATTRIB_POS],
VERT_ATTRIB_FF_MAX * sizeof(arrays[0]));
for (i = 0; i VERT_ATTRIB_FF_MAX; ++i) {
struct gl_client_array *array;
array = arrays[VERT_ATTRIB_FF(i)];
array-BufferObj = NULL;
_mesa_reference_buffer_object(ctx, arrays-BufferObj,
- vbo-legacy_currval[i].BufferObj);
+ vbo-currval[VBO_ATTRIB_POS+i].BufferObj);
}
memcpy(arrays + VERT_ATTRIB_GENERIC(0), vbo-generic_currval,
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 30a954a..7278c39 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -420,7 +420,7 @@ recalculate_input_bindings(struct gl_context *ctx)
if (vertexAttrib[VERT_ATTRIB_FF(i)].Enabled)
inputs[i] = vertexAttrib[VERT_ATTRIB_FF(i)];
else {
- inputs[i] = vbo-legacy_currval[i];
+ inputs[i] = vbo-currval[VBO_ATTRIB_POS+i];
const_inputs |= VERT_BIT(i);
}
}
@@ -459,7 +459,7 @@ recalculate_input_bindings(struct gl_context *ctx)
else if (vertexAttrib[VERT_ATTRIB_FF(i)].Enabled)
inputs[i] = vertexAttrib[VERT_ATTRIB_FF(i)];
else {
- inputs[i] = vbo-legacy_currval[i];
+ inputs[i] = vbo-currval[VBO_ATTRIB_POS+i];
const_inputs |= VERT_BIT_FF(i);
}
}
@@ -488,7 +488,7 @@ recalculate_input_bindings(struct gl_context *ctx)
else if (vertexAttrib[VERT_ATTRIB_POS].Enabled)
inputs[0] = vertexAttrib[VERT_ATTRIB_POS];
else {
-inputs[0] = vbo-legacy_currval[0];
+inputs[0] = vbo-currval[VBO_ATTRIB_POS];
const_inputs |= VERT_BIT_POS;
}
@@ -496,7 +496,7 @@ recalculate_input_bindings(struct gl_context *ctx)
if (vertexAttrib[VERT_ATTRIB_FF(i)].Enabled)
inputs[i] = vertexAttrib[VERT_ATTRIB_FF(i)];
else {
- inputs[i] = vbo-legacy_currval[i];
+ inputs[i] = vbo-currval[VBO_ATTRIB_POS+i];
const_inputs |= VERT_BIT_FF(i);
}
}
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index a1d329f..96ff224 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -174,7 +174,7 @@ vbo_exec_bind_arrays( struct gl_context *ctx )
switch (get_program_mode(exec-ctx)) {
case VP_NONE:
for (attr = 0; attr VERT_ATTRIB_FF_MAX; attr++) {
- exec-vtx.inputs[attr] =
[Mesa-dev] [PATCH 09/10] vbo: remove vbo_context::generic_currval
---
src/mesa/vbo/vbo_context.c|3 +--
src/mesa/vbo/vbo_context.h|1 -
src/mesa/vbo/vbo_exec_api.c |6 --
src/mesa/vbo/vbo_exec_array.c |6 +++---
src/mesa/vbo/vbo_exec_draw.c |3 ++-
src/mesa/vbo/vbo_save.c |6 --
src/mesa/vbo/vbo_save_draw.c |3 ++-
7 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 2b31b62..33bd4f3 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -77,7 +77,7 @@ static void init_legacy_currval(struct gl_context *ctx)
static void init_generic_currval(struct gl_context *ctx)
{
struct vbo_context *vbo = vbo_context(ctx);
- struct gl_client_array *arrays = vbo-generic_currval;
+ struct gl_client_array *arrays = vbo-currval[VBO_ATTRIB_GENERIC0];
GLuint i;
memset(arrays, 0, sizeof(*arrays) * VERT_ATTRIB_GENERIC_MAX);
@@ -162,7 +162,6 @@ GLboolean _vbo_CreateContext( struct gl_context *ctx )
/* TODO: remove these pointers.
*/
- vbo-generic_currval = vbo-currval[VBO_ATTRIB_GENERIC0];
vbo-mat_currval = vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT];
init_legacy_currval( ctx );
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index 77010b8..b9d0086 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -63,7 +63,6 @@ struct vbo_context {
/* These point into the above. TODO: remove.
*/
- struct gl_client_array *generic_currval;
struct gl_client_array *mat_currval;
/** Map VERT_ATTRIB_x to VBO_ATTRIB_y */
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 8a16804..3f95410 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -1099,14 +1099,16 @@ void vbo_exec_vtx_init( struct vbo_exec_context *exec )
vbo-currval[VBO_ATTRIB_POS+i].BufferObj);
}
- memcpy(arrays + VERT_ATTRIB_GENERIC(0), vbo-generic_currval,
+ memcpy(arrays + VERT_ATTRIB_GENERIC(0),
+ vbo-currval[VBO_ATTRIB_GENERIC0],
VERT_ATTRIB_GENERIC_MAX * sizeof(arrays[0]));
+
for (i = 0; i VERT_ATTRIB_GENERIC_MAX; ++i) {
struct gl_client_array *array;
array = arrays[VERT_ATTRIB_GENERIC(i)];
array-BufferObj = NULL;
_mesa_reference_buffer_object(ctx, array-BufferObj,
- vbo-generic_currval[i].BufferObj);
+ vbo-currval[VBO_ATTRIB_GENERIC0+i].BufferObj);
}
}
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 7278c39..60e18db 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -434,7 +434,7 @@ recalculate_input_bindings(struct gl_context *ctx)
* slots:
*/
for (i = MAT_ATTRIB_MAX; i VERT_ATTRIB_GENERIC_MAX; i++) {
-inputs[VERT_ATTRIB_GENERIC(i)] = vbo-generic_currval[i];
+inputs[VERT_ATTRIB_GENERIC(i)] = vbo-currval[VBO_ATTRIB_GENERIC0+i];
const_inputs |= VERT_BIT_GENERIC(i);
}
@@ -468,7 +468,7 @@ recalculate_input_bindings(struct gl_context *ctx)
* slots:
*/
for (i = 0; i VERT_ATTRIB_GENERIC_MAX; i++) {
-inputs[VERT_ATTRIB_GENERIC(i)] = vbo-generic_currval[i];
+inputs[VERT_ATTRIB_GENERIC(i)] = vbo-currval[VBO_ATTRIB_GENERIC0+i];
const_inputs |= VERT_BIT_GENERIC(i);
}
@@ -505,7 +505,7 @@ recalculate_input_bindings(struct gl_context *ctx)
if (vertexAttrib[VERT_ATTRIB_GENERIC(i)].Enabled)
inputs[VERT_ATTRIB_GENERIC(i)] =
vertexAttrib[VERT_ATTRIB_GENERIC(i)];
else {
- inputs[VERT_ATTRIB_GENERIC(i)] = vbo-generic_currval[i];
+ inputs[VERT_ATTRIB_GENERIC(i)] =
vbo-currval[VBO_ATTRIB_GENERIC0+i];
const_inputs |= VERT_BIT_GENERIC(i);
}
}
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index 96ff224..570323a 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -193,7 +193,8 @@ vbo_exec_bind_arrays( struct gl_context *ctx )
}
for (attr = 0; attr VERT_ATTRIB_GENERIC_MAX; attr++) {
ASSERT(VERT_ATTRIB_GENERIC(attr) Elements(exec-vtx.inputs));
- exec-vtx.inputs[VERT_ATTRIB_GENERIC(attr)] =
vbo-generic_currval[attr];
+ exec-vtx.inputs[VERT_ATTRIB_GENERIC(attr)] =
+vbo-currval[VBO_ATTRIB_GENERIC0+attr];
}
map = vbo-map_vp_arb;
diff --git a/src/mesa/vbo/vbo_save.c b/src/mesa/vbo/vbo_save.c
index dbe99ed..040c9b7 100644
--- a/src/mesa/vbo/vbo_save.c
+++ b/src/mesa/vbo/vbo_save.c
@@ -73,14 +73,16 @@ void vbo_save_init( struct gl_context *ctx )
vbo-currval[VBO_ATTRIB_POS+i].BufferObj);
}
- memcpy(arrays + VERT_ATTRIB_GENERIC(0), vbo-generic_currval,
+ memcpy(arrays + VERT_ATTRIB_GENERIC(0),
+
[Mesa-dev] [PATCH 10/10] vbo: remove vbo_context::mat_currval
---
src/mesa/vbo/vbo_context.c|7 ++-
src/mesa/vbo/vbo_context.h|4
src/mesa/vbo/vbo_exec_array.c |3 ++-
src/mesa/vbo/vbo_exec_draw.c |3 ++-
src/mesa/vbo/vbo_save_draw.c |3 ++-
5 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 33bd4f3..5f1c72b 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -104,7 +104,8 @@ static void init_generic_currval(struct gl_context *ctx)
static void init_mat_currval(struct gl_context *ctx)
{
struct vbo_context *vbo = vbo_context(ctx);
- struct gl_client_array *arrays = vbo-mat_currval;
+ struct gl_client_array *arrays =
+ vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT];
GLuint i;
ASSERT(NR_MAT_ATTRIBS == MAT_ATTRIB_MAX);
@@ -160,10 +161,6 @@ GLboolean _vbo_CreateContext( struct gl_context *ctx )
return GL_FALSE;
}
- /* TODO: remove these pointers.
-*/
- vbo-mat_currval = vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT];
-
init_legacy_currval( ctx );
init_generic_currval( ctx );
init_mat_currval( ctx );
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index b9d0086..b9a8aff 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -61,10 +61,6 @@
struct vbo_context {
struct gl_client_array currval[VBO_ATTRIB_MAX];
- /* These point into the above. TODO: remove.
-*/
- struct gl_client_array *mat_currval;
-
/** Map VERT_ATTRIB_x to VBO_ATTRIB_y */
GLuint map_vp_none[VERT_ATTRIB_MAX];
GLuint map_vp_arb[VERT_ATTRIB_MAX];
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 60e18db..f95e062 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -426,7 +426,8 @@ recalculate_input_bindings(struct gl_context *ctx)
}
for (i = 0; i MAT_ATTRIB_MAX; i++) {
-inputs[VERT_ATTRIB_GENERIC(i)] = vbo-mat_currval[i];
+inputs[VERT_ATTRIB_GENERIC(i)] =
+ vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT+i];
const_inputs |= VERT_BIT_GENERIC(i);
}
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index 570323a..5cc6586 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -178,7 +178,8 @@ vbo_exec_bind_arrays( struct gl_context *ctx )
}
for (attr = 0; attr MAT_ATTRIB_MAX; attr++) {
ASSERT(VERT_ATTRIB_GENERIC(attr) Elements(exec-vtx.inputs));
- exec-vtx.inputs[VERT_ATTRIB_GENERIC(attr)] = vbo-mat_currval[attr];
+ exec-vtx.inputs[VERT_ATTRIB_GENERIC(attr)] =
+vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT+attr];
}
map = vbo-map_vp_none;
break;
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 4eac65a..57186de 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -150,7 +150,8 @@ static void vbo_bind_vertex_list(struct gl_context *ctx,
save-inputs[attr] = vbo-currval[VBO_ATTRIB_POS+attr];
}
for (attr = 0; attr MAT_ATTRIB_MAX; attr++) {
- save-inputs[VERT_ATTRIB_GENERIC(attr)] = vbo-mat_currval[attr];
+ save-inputs[VERT_ATTRIB_GENERIC(attr)] =
+vbo-currval[VBO_ATTRIB_MAT_FRONT_AMBIENT+attr];
}
map = vbo-map_vp_none;
break;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
Jose Fonseca jfons...@vmware.com writes:
Francisco,
Sorry for the delay reviewing this, but I haven't been able to dedicate
some time until now.
Overall, it's a great piece of work! Just a few relatively minor
comments/requests.
Hi Jose, thanks for the comments.
[...]
gallium/tgsi: Add support for raw resources.
What's the difference between raw resources and buffers? Shouldn't all
buffers be raw, and non-buffers resources non-row?
The difference is that raw resources have no associated data type, so
there's no type conversion between what the shader sees and what ends up
stored in memory. This is somewhat orthogonal to the number of
addressing dimensions of the resource, so you can get raw 2D textures,
3D textures, etc.
You're right that CL only uses raw buffers right now, but D3D11 makes a
similar distinction and both raw and non-raw buffers are likely to be
useful if someone tries to implement ByteAddressBuffers and Buffers,
respectively.
[...]
gallium/compute: Drop TGSI dependency.
This fine in principle, but I don't understand what
PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a string?),
Yes, it's supposed to be a null-terminated string containing a target
triple specification in the standard form many compilers understand,
as documented in screen.rst.
and how would this scheme work, e.g., if a driver wanted to consume
GLSL IR in the future.
Hm, I'm not convinced that letting a driver consume GLSL IR would be a
good idea in itself. It opens the door to a situation where each driver
has to provide a compiler front-end for each individual API it aims to
support, and it would break with the principle of having API-agnostic
drivers running under a hardware-agnostic state tracker.
The target triple and the IR type are two separate issues. The
target triple really doesn't say anything about the IR type the driver
expects. Really, the only purpose of the target triple is to describe the
target
to help the compiler frontend generate correct code.
I think we should also add a query function like this in order to communicate to
the state tracker the kind of IR it should pass to the driver:
unsigned get_prefered_ir(unsigned shader_type) {
switch(shader_type) {
default:
return GALLIUM_IR_TGSI;
}
}
IMHO, in an ideal world we'd have one common transport IR all drivers
would be comfortable with, otherwise you get a matrix of code paths that
is likely to get more and more painful to debug and maintain as the
number of drivers and state trackers grows.
As AMD didn't seem to be willing to use TGSI directly in their compute
stack, the purpose of this change was to simplify the driver code in
cases where the front-end compiler already happens to support the native
binary format required by the pipe driver, so, right now
PIPE_COMPUTE_CAP_IR_TARGET can be either tgsi or the hardware's native
binary format.
I think that an enum would be preferrable.
I'm OK with changing it to an enum if you think it would be preferable.
What made me decide for a string was that if it were to be an enum, we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state trackers would
need driver-specific code to make a proper interpretation of it. If
it's a string in some standard form the state tracker can just pass it
on to the compiler without looking inside.
I think this makes more sense as a string. The target triple is a pretty
standard format and as Francisco points out an enum would require the
state tracker to have driver specific code to determine which triple
to use.
-Tom
Jose
___
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][PATCH 00/11] gallium: Basic compute infrastructure.
- Original Message -
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
Jose Fonseca jfons...@vmware.com writes:
Francisco,
Sorry for the delay reviewing this, but I haven't been able to
dedicate some time until now.
Overall, it's a great piece of work! Just a few relatively minor
comments/requests.
Hi Jose, thanks for the comments.
[...]
gallium/tgsi: Add support for raw resources.
What's the difference between raw resources and buffers?
Shouldn't all
buffers be raw, and non-buffers resources non-row?
The difference is that raw resources have no associated data type,
so
there's no type conversion between what the shader sees and what
ends up
stored in memory. This is somewhat orthogonal to the number of
addressing dimensions of the resource, so you can get raw 2D
textures,
3D textures, etc.
You're right that CL only uses raw buffers right now, but D3D11
makes a
similar distinction and both raw and non-raw buffers are likely to
be
useful if someone tries to implement ByteAddressBuffers and
Buffers,
respectively.
[...]
gallium/compute: Drop TGSI dependency.
This fine in principle, but I don't understand what
PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a
string?),
Yes, it's supposed to be a null-terminated string containing a
target
triple specification in the standard form many compilers
understand,
as documented in screen.rst.
and how would this scheme work, e.g., if a driver wanted to
consume
GLSL IR in the future.
Hm, I'm not convinced that letting a driver consume GLSL IR would
be a
good idea in itself. It opens the door to a situation where each
driver
has to provide a compiler front-end for each individual API it aims
to
support, and it would break with the principle of having
API-agnostic
drivers running under a hardware-agnostic state tracker.
The target triple and the IR type are two separate issues. The
target triple really doesn't say anything about the IR type the
driver
expects. Really, the only purpose of the target triple is to
describe the target
to help the compiler frontend generate correct code.
I think we should also add a query function like this in order to
communicate to
the state tracker the kind of IR it should pass to the driver:
unsigned get_prefered_ir(unsigned shader_type) {
switch(shader_type) {
default:
return GALLIUM_IR_TGSI;
}
}
IMHO, in an ideal world we'd have one common transport IR all
drivers
would be comfortable with, otherwise you get a matrix of code paths
that
is likely to get more and more painful to debug and maintain as the
number of drivers and state trackers grows.
As AMD didn't seem to be willing to use TGSI directly in their
compute
stack, the purpose of this change was to simplify the driver code
in
cases where the front-end compiler already happens to support the
native
binary format required by the pipe driver, so, right now
PIPE_COMPUTE_CAP_IR_TARGET can be either tgsi or the hardware's
native
binary format.
I think that an enum would be preferrable.
I'm OK with changing it to an enum if you think it would be
preferable.
What made me decide for a string was that if it were to be an enum,
we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state trackers
would
need driver-specific code to make a proper interpretation of it.
If
it's a string in some standard form the state tracker can just pass
it
on to the compiler without looking inside.
I think this makes more sense as a string. The target triple is a
pretty
standard format and as Francisco points out an enum would require the
state tracker to have driver specific code to determine which triple
to use.
I'm ok with punching LLVM IR through gallium, but I really would prefer adding
LLVM specific interfaces.
Also, while you say target triple is a pretty standard format, I don't see it
standardized anywhere. It looks like even LLVM changes every now and then.
So both things make thing this is a bad interface.
So, let's use an enum for now, like
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R700, /* or maybe PIPE_IR_AMD_IL_R700, as I'm not entirely
sure what's exactly being punched through */
};
enum pipe_preferred_ir ir = screen-get_shader_param(screen, shader,
PIPE_SHADER_CAP_PREFERRED_IR);
switch( ir) {
default:
case PIPE_IR_TGSI:
/* fallback to TGSI
return FALSE;
case PIPE_IR_LLVM:
target = ???;
break;
case PIPE_IR_LLVM_R700:
target = ???-amd-r700;
break;
}
...
The switch table can be in an inline helper function.
And lets move on. I'm happy to revisit this issue later when there are more
drivers using LLVM IR.
Re: [Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
On 04/18/2012 08:16 AM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_context.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.h
b/src/mesa/state_tracker/st_context.h
index da03719..3d41ab5 100644
--- a/src/mesa/state_tracker/st_context.h
+++ b/src/mesa/state_tracker/st_context.h
@@ -42,12 +42,12 @@ struct st_context;
struct st_fragment_program;
-#define ST_NEW_MESA0x1 /* Mesa state has changed */
-#define ST_NEW_FRAGMENT_PROGRAM0x2
-#define ST_NEW_VERTEX_PROGRAM 0x4
-#define ST_NEW_FRAMEBUFFER 0x8
-#define ST_NEW_EDGEFLAGS_DATA 0x10
-#define ST_NEW_GEOMETRY_PROGRAM0x20
+#define ST_NEW_MESA(1 0) /* Mesa state has changed */
+#define ST_NEW_FRAGMENT_PROGRAM(1 1)
+#define ST_NEW_VERTEX_PROGRAM (1 2)
+#define ST_NEW_FRAMEBUFFER (1 3)
+#define ST_NEW_EDGEFLAGS_DATA (1 4)
+#define ST_NEW_GEOMETRY_PROGRAM(1 5)
struct st_state_flags {
Marek, these look like good clean-ups. Thanks.
BTW, the gl_array_attrib::NewState field is assigned to but never used
anywhere. Want to remove it too?
Assuming you've run a good amount of piglit/etc regression testing,
Reviewed-by: Brian Paul bri...@vmware.com
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/21] u_vbuf: override set_index_buffer
On Thu, Apr 12, 2012 at 4:13 AM, Brian Paul brian.e.p...@gmail.com wrote: On Wed, Apr 11, 2012 at 9:38 AM, Marek Olšák mar...@gmail.com wrote: This makes u_vbuf_mgr call the driver instead of the other way around. --- src/gallium/auxiliary/util/u_vbuf.c | 35 ++--- src/gallium/auxiliary/util/u_vbuf.h | 6 src/gallium/drivers/r300/r300_context.h | 2 +- src/gallium/drivers/r300/r300_render.c | 22 src/gallium/drivers/r300/r300_state.c | 15 +-- src/gallium/drivers/r600/r600_pipe.h | 1 + src/gallium/drivers/r600/r600_state_common.c | 16 +++ 7 files changed, 60 insertions(+), 37 deletions(-) I looked at patches 5-16 and they seem OK to me but someone more familiar with r300 might want to double-check. In the patch where you add the new gallium PIPE_CAP_ tokens, you're using DWORD. I think that's the first occurrence of that term in the gallium interface. Coming from a workstation-centric background I've never been a big fan of dword since I always thought of a word as being 32-bits. Would something like 4BYTE be acceptable in this case? I guess it's not a big deal though. No problem, I'll change DWORD to 4BYTE. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] gallium/u_blit: don't release vertex buffer at end of frame / in glFlush
Marek,
Sorry for not noticing earlier ( I haven't been able to keep up with mesa
traffic lately), but I'm afraid this and the 10/10 are not ok, as on several
operating systems, namely, Windows WDDM, it is illegal to flush a command
buffer with a buffer mapped.
Jose
- Original Message -
There's no reason to do that. The buffer being used for rendering is
always
mapped as unsynchronized.
---
src/gallium/auxiliary/util/u_blit.c | 17 -
src/gallium/auxiliary/util/u_blit.h |5 -
src/mesa/state_tracker/st_cb_flush.c |1 -
3 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util/u_blit.c
index 1279733..e5b97f7 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -232,8 +232,10 @@ get_next_slot( struct blit_state *ctx )
{
const unsigned max_slots = 4096 / sizeof ctx-vertices;
- if (ctx-vbuf_slot = max_slots)
- util_blit_flush( ctx );
+ if (ctx-vbuf_slot = max_slots) {
+ pipe_resource_reference(ctx-vbuf, NULL);
+ ctx-vbuf_slot = 0;
+ }
if (!ctx-vbuf) {
ctx-vbuf = pipe_buffer_create(ctx-pipe-screen,
@@ -674,17 +676,6 @@ util_blit_pixels(struct blit_state *ctx,
}
-/* Release vertex buffer at end of frame to avoid synchronous
- * rendering.
- */
-void util_blit_flush( struct blit_state *ctx )
-{
- pipe_resource_reference(ctx-vbuf, NULL);
- ctx-vbuf_slot = 0;
-}
-
-
-
/**
* Copy pixel block from src texture to dst surface.
* The sampler view's first_level field indicates the source
diff --git a/src/gallium/auxiliary/util/u_blit.h
b/src/gallium/auxiliary/util/u_blit.h
index 3009e25..810d01b 100644
--- a/src/gallium/auxiliary/util/u_blit.h
+++ b/src/gallium/auxiliary/util/u_blit.h
@@ -86,11 +86,6 @@ util_blit_pixels_tex(struct blit_state *ctx,
int dstX1, int dstY1,
float z, uint filter);
-/* Call at end of frame to avoid synchronous rendering.
- */
-extern void
-util_blit_flush( struct blit_state *ctx );
-
#ifdef __cplusplus
}
#endif
diff --git a/src/mesa/state_tracker/st_cb_flush.c
b/src/mesa/state_tracker/st_cb_flush.c
index 724bc19..4cde84a 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -85,7 +85,6 @@ void st_flush( struct st_context *st,
* successive frames:
*/
st_flush_bitmap(st);
- util_blit_flush(st-blit);
util_gen_mipmap_flush(st-gen_mipmap);
st-pipe-flush( st-pipe, fence );
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
- Original Message -
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
Jose Fonseca jfons...@vmware.com writes:
Francisco,
Sorry for the delay reviewing this, but I haven't been able to
dedicate some time until now.
Overall, it's a great piece of work! Just a few relatively minor
comments/requests.
Hi Jose, thanks for the comments.
[...]
gallium/tgsi: Add support for raw resources.
What's the difference between raw resources and buffers?
Shouldn't all
buffers be raw, and non-buffers resources non-row?
The difference is that raw resources have no associated data type,
so
there's no type conversion between what the shader sees and what
ends up
stored in memory. This is somewhat orthogonal to the number of
addressing dimensions of the resource, so you can get raw 2D
textures,
3D textures, etc.
You're right that CL only uses raw buffers right now, but D3D11
makes a
similar distinction and both raw and non-raw buffers are likely to
be
useful if someone tries to implement ByteAddressBuffers and
Buffers,
respectively.
[...]
gallium/compute: Drop TGSI dependency.
This fine in principle, but I don't understand what
PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a
string?),
Yes, it's supposed to be a null-terminated string containing a
target
triple specification in the standard form many compilers
understand,
as documented in screen.rst.
and how would this scheme work, e.g., if a driver wanted to
consume
GLSL IR in the future.
Hm, I'm not convinced that letting a driver consume GLSL IR would
be a
good idea in itself. It opens the door to a situation where each
driver
has to provide a compiler front-end for each individual API it aims
to
support, and it would break with the principle of having
API-agnostic
drivers running under a hardware-agnostic state tracker.
The target triple and the IR type are two separate issues. The
target triple really doesn't say anything about the IR type the
driver
expects. Really, the only purpose of the target triple is to
describe the target
to help the compiler frontend generate correct code.
I think we should also add a query function like this in order to
communicate to
the state tracker the kind of IR it should pass to the driver:
unsigned get_prefered_ir(unsigned shader_type) {
switch(shader_type) {
default:
return GALLIUM_IR_TGSI;
}
}
IMHO, in an ideal world we'd have one common transport IR all
drivers
would be comfortable with, otherwise you get a matrix of code paths
that
is likely to get more and more painful to debug and maintain as the
number of drivers and state trackers grows.
As AMD didn't seem to be willing to use TGSI directly in their
compute
stack, the purpose of this change was to simplify the driver code
in
cases where the front-end compiler already happens to support the
native
binary format required by the pipe driver, so, right now
PIPE_COMPUTE_CAP_IR_TARGET can be either tgsi or the hardware's
native
binary format.
I think that an enum would be preferrable.
I'm OK with changing it to an enum if you think it would be
preferable.
What made me decide for a string was that if it were to be an enum,
we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state trackers
would
need driver-specific code to make a proper interpretation of it.
If
it's a string in some standard form the state tracker can just pass
it
on to the compiler without looking inside.
I think this makes more sense as a string. The target triple is a
pretty
standard format and as Francisco points out an enum would require the
state tracker to have driver specific code to determine which triple
to use.
I'm ok with punching LLVM IR through gallium, but I really would prefer
adding LLVM specific interfaces.
Also, while you say target triple is a pretty standard format, I don't see it
standardized anywhere. It looks like even LLVM changes every now and then.
So both things make thing this is a bad interface.
So, let's use an enum for now, like
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R700, /* or maybe PIPE_IR_AMD_IL_R700, as I'm not entirely
sure what's exactly being punched through */
};
It's LLVM IR that is being passed. The enum should look like this:
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R600,
PIPE_IR_LLVM_SI
};
enum pipe_preferred_ir ir = screen-get_shader_param(screen, shader,
PIPE_SHADER_CAP_PREFERRED_IR);
switch( ir) {
Re: [Mesa-dev] llvmPipe on ARM (CortexA-9)
Am 18.04.2012 14:02, schrieb Vijay: Hello, Can we use llvmpipe for arm architecture.(Specifically ARM cortexA-9) ?? I tried found below error. Unhandled instruction encoding format! UNREACHABLE executed at ARMCodeEmitter.cpp:534! Aborted Version used : llvmpipe3.0,Mesa-8.0 Any hint or info will be helpfull. As José said, noone tried so far. I don't know how good the llvm arm backend is, specifically for handling vector instructions it might not be quite up to the task, or the JIT might not work too well. I found some references saying old arm jit is 100% broken for VFP/NEON, which means mc-jit is needed, so it's probably not going to work right now. Oh and is this a Cortex-A9 with NEON? Some of the Cortex-A9 (ok I only know of one) don't have NEON, in which case with some luck the backend might still generate code which works but it's probably not too useful. I (very) quickly glanced over the neon instruction set, looks like it has pretty much everything needed for reasonable code generation. But in any case, that's certainly secondary issues if the jit doesn't work at all... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
On Wed, Apr 18, 2012 at 5:02 PM, Brian Paul bri...@vmware.com wrote:
On 04/18/2012 08:16 AM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_context.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.h
b/src/mesa/state_tracker/st_context.h
index da03719..3d41ab5 100644
--- a/src/mesa/state_tracker/st_context.h
+++ b/src/mesa/state_tracker/st_context.h
@@ -42,12 +42,12 @@ struct st_context;
struct st_fragment_program;
-#define ST_NEW_MESA 0x1 /* Mesa state has changed */
-#define ST_NEW_FRAGMENT_PROGRAM 0x2
-#define ST_NEW_VERTEX_PROGRAM 0x4
-#define ST_NEW_FRAMEBUFFER 0x8
-#define ST_NEW_EDGEFLAGS_DATA 0x10
-#define ST_NEW_GEOMETRY_PROGRAM 0x20
+#define ST_NEW_MESA (1 0) /* Mesa state has changed
*/
+#define ST_NEW_FRAGMENT_PROGRAM (1 1)
+#define ST_NEW_VERTEX_PROGRAM (1 2)
+#define ST_NEW_FRAMEBUFFER (1 3)
+#define ST_NEW_EDGEFLAGS_DATA (1 4)
+#define ST_NEW_GEOMETRY_PROGRAM (1 5)
struct st_state_flags {
Marek, these look like good clean-ups. Thanks.
BTW, the gl_array_attrib::NewState field is assigned to but never used
anywhere. Want to remove it too?
Hi Brian,
I didn't remove it because I thought it would be useful in the future.
I wouldn't oppose somebody else removing it though.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
Hi, That's actually a nice cleanup. There's a plenty potential for speeding up this area, but I did not find time to complete what I had/have in mind! For the series: Reviewed-by: Mathias Fröhlich mathias.froehl...@web.de Thanks! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
Hi, On Wednesday, April 18, 2012 18:22:48 Marek Olšák wrote: BTW, the gl_array_attrib::NewState field is assigned to but never used anywhere. Want to remove it too? Hi Brian, I didn't remove it because I thought it would be useful in the future. I wouldn't oppose somebody else removing it though. I was thinking about this too. But I agree with Marek. IMO It might be helpful to move this in the long term into gl_array_object and track this there, but that kind of information can safe us a lot of work in the end while updating array state. Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] gallium/u_blit: don't release vertex buffer at end of frame / in glFlush
On Wed, Apr 18, 2012 at 5:06 PM, Jose Fonseca jfons...@vmware.com wrote: Marek, Sorry for not noticing earlier ( I haven't been able to keep up with mesa traffic lately), but I'm afraid this and the 10/10 are not ok, as on several operating systems, namely, Windows WDDM, it is illegal to flush a command buffer with a buffer mapped. The buffer is not mapped when the flush happens. u_blit uses pipe_buffer_write_nooverlap, which uses transfer_inline_write, which goes into u_default_transfer_inline_write on most (if not all) drivers, which unmaps the resource before the function returns. The buffer may be mapped with the 'unsynchronized' flag again later though, so drivers should implement that flag to avoid stalls. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
On 04/18/2012 10:28 AM, Mathias Fröhlich wrote: Hi, On Wednesday, April 18, 2012 18:22:48 Marek Olšák wrote: BTW, the gl_array_attrib::NewState field is assigned to but never used anywhere. Want to remove it too? Hi Brian, I didn't remove it because I thought it would be useful in the future. I wouldn't oppose somebody else removing it though. I was thinking about this too. But I agree with Marek. IMO It might be helpful to move this in the long term into gl_array_object and track this there, but that kind of information can safe us a lot of work in the end while updating array state. Yes. I actually started some work on that a while back but never got back to it. I don't think there'd be any harm in moving the field so I'll go dig up that patch. My goal was to explore having an st_array_object subclass of gl_array_object that would contain pipe_vertex_buffer and pipe_vertex_element state. It would only have to be updated when that array object's state changed. While not many apps use array objects yet, those that did could avoid some (most?) of the draw/array-releted state validation when they did: create_array_objects(); ... glBindVertexArray(1); glDrawArrays(); glBindVertexArray(2); glDrawArrays(); etc.. I started plumbing a gl_array_object pointer through the VBO code but never finished. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: move gl_array_attrib::NewState to gl_array_object::NewArrays
From: Brian Paul bri...@vmware.com
The field wasn't actually used before and it's not used now either.
But this is a more logical place for it and will hopefully allow
doing smarter draw/array validation (per array object) in the future.
---
src/mesa/main/arrayobj.c |1 -
src/mesa/main/attrib.c |3 ++-
src/mesa/main/enable.c |3 ++-
src/mesa/main/mtypes.h |4 +++-
src/mesa/main/state.c|2 +-
src/mesa/main/varray.c | 10 --
6 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index c7584d9..4c50066 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -389,7 +389,6 @@ bind_vertex_array(struct gl_context *ctx, GLuint id,
GLboolean genRequired)
}
ctx-NewState |= _NEW_ARRAY;
- ctx-Array.NewState |= VERT_BIT_ALL;
_mesa_reference_array_object(ctx, ctx-Array.ArrayObj, newObj);
/* Pass BindVertexArray call to device driver */
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 7042312..66ded11 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1456,7 +1456,8 @@ restore_array_attrib(struct gl_context *ctx,
* FIXME: of the old ArrayObj-_Enabled and the new _Enabled.
* ... just do it.
*/
- dest-NewState |= src-ArrayObj-_Enabled | dest-ArrayObj-_Enabled;
+ dest-ArrayObj-NewArrays |=
+ src-ArrayObj-_Enabled | dest-ArrayObj-_Enabled;
}
/**
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index f6d37fe..d0b4625 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -142,7 +142,6 @@ client_state(struct gl_context *ctx, GLenum cap, GLboolean
state)
return;
FLUSH_VERTICES(ctx, _NEW_ARRAY);
- ctx-Array.NewState |= flag;
_ae_invalidate_state(ctx, _NEW_ARRAY);
@@ -153,6 +152,8 @@ client_state(struct gl_context *ctx, GLenum cap, GLboolean
state)
else
arrayObj-_Enabled = ~flag;
+ arrayObj-NewArrays |= flag;
+
if (ctx-Driver.Enable) {
ctx-Driver.Enable( ctx, cap, state );
}
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 8e441c2..f952b36 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1599,6 +1599,9 @@ struct gl_array_object
/** Mask of VERT_BIT_* values indicating which arrays are enabled */
GLbitfield64 _Enabled;
+ /** Mask of VERT_BIT_* values indicating changed/dirty arrays */
+ GLbitfield64 NewArrays;
+
/**
* Min of all enabled arrays' _MaxElement. When arrays reside inside VBOs
* we can determine the max legal (in bounds) glDrawElements array index.
@@ -1631,7 +1634,6 @@ struct gl_array_attrib
GLboolean PrimitiveRestart;
GLuint RestartIndex;
- GLbitfield64 NewState; /** mask of VERT_BIT_* values */
GLboolean RebindArrays; /** whether the VBO module should rebind arrays */
/* GL_ARB_vertex_buffer_object */
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index b019266..39c63f4 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -579,7 +579,7 @@ _mesa_update_state_locked( struct gl_context *ctx )
new_state = ctx-NewState | new_prog_state;
ctx-NewState = 0;
ctx-Driver.UpdateState(ctx, new_state);
- ctx-Array.NewState = 0;
+ ctx-Array.ArrayObj-NewArrays = 0x0;
if (!ctx-Array.RebindArrays)
ctx-Array.RebindArrays = (new_state (_NEW_ARRAY | _NEW_PROGRAM)) != 0;
}
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index a402c7b..184e75e 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -221,7 +221,7 @@ update_array(struct gl_context *ctx,
ctx-Array.ArrayBufferObj);
ctx-NewState |= _NEW_ARRAY;
- ctx-Array.NewState |= VERT_BIT(attrib);
+ ctx-Array.ArrayObj-NewArrays |= VERT_BIT(attrib);
}
@@ -502,7 +502,7 @@ _mesa_EnableVertexAttribArrayARB(GLuint index)
FLUSH_VERTICES(ctx, _NEW_ARRAY);
arrayObj-VertexAttrib[VERT_ATTRIB_GENERIC(index)].Enabled = GL_TRUE;
arrayObj-_Enabled |= VERT_BIT_GENERIC(index);
- ctx-Array.NewState |= VERT_BIT_GENERIC(index);
+ arrayObj-NewArrays |= VERT_BIT_GENERIC(index);
}
}
@@ -529,7 +529,7 @@ _mesa_DisableVertexAttribArrayARB(GLuint index)
FLUSH_VERTICES(ctx, _NEW_ARRAY);
arrayObj-VertexAttrib[VERT_ATTRIB_GENERIC(index)].Enabled = GL_FALSE;
arrayObj-_Enabled = ~VERT_BIT_GENERIC(index);
- ctx-Array.NewState |= VERT_BIT_GENERIC(index);
+ arrayObj-NewArrays |= VERT_BIT_GENERIC(index);
}
}
@@ -1001,7 +1001,6 @@ _mesa_LockArraysEXT(GLint first, GLsizei count)
ctx-Array.LockCount = count;
ctx-NewState |= _NEW_ARRAY;
- ctx-Array.NewState |= VERT_BIT_ALL;
}
@@ -1022,7 +1021,6 @@ _mesa_UnlockArraysEXT( void )
ctx-Array.LockFirst = 0;
ctx-Array.LockCount = 0;
ctx-NewState |= _NEW_ARRAY;
- ctx-Array.NewState |= VERT_BIT_ALL;
}
@@ -1138,7 +1136,7 @@ _mesa_VertexAttribDivisor(GLuint index,
Re: [Mesa-dev] [PATCH 09/10] gallium/u_blit: don't release vertex buffer at end of frame / in glFlush
- Original Message - On Wed, Apr 18, 2012 at 5:06 PM, Jose Fonseca jfons...@vmware.com wrote: Marek, Sorry for not noticing earlier ( I haven't been able to keep up with mesa traffic lately), but I'm afraid this and the 10/10 are not ok, as on several operating systems, namely, Windows WDDM, it is illegal to flush a command buffer with a buffer mapped. The buffer is not mapped when the flush happens. u_blit uses pipe_buffer_write_nooverlap, which uses transfer_inline_write, which goes into u_default_transfer_inline_write on most (if not all) drivers, which unmaps the resource before the function returns. Ah. OK. Looks good then. Sorry for jumping on the gun here. The buffer may be mapped with the 'unsynchronized' flag again later though, so drivers should implement that flag to avoid stalls. Our WDDM winsys has some issues implementing unsynchronized semantics, so this may cause some stalls whenever we flush the command buffer, but that is an orthogonal problem we'll need to address independently of this, as this is perfectly valid/common behavior. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
- Original Message - Jose Fonseca jfons...@vmware.com writes: Francisco, Sorry for the delay reviewing this, but I haven't been able to dedicate some time until now. Overall, it's a great piece of work! Just a few relatively minor comments/requests. Hi Jose, thanks for the comments. [...] gallium/tgsi: Add support for raw resources. What's the difference between raw resources and buffers? Shouldn't all buffers be raw, and non-buffers resources non-row? The difference is that raw resources have no associated data type, so there's no type conversion between what the shader sees and what ends up stored in memory. This is somewhat orthogonal to the number of addressing dimensions of the resource, so you can get raw 2D textures, 3D textures, etc. You're right that CL only uses raw buffers right now, but D3D11 makes a similar distinction and both raw and non-raw buffers are likely to be useful if someone tries to implement ByteAddressBuffers and Buffers, respectively. Ok. Sounds good. [...] gallium/compute: Drop TGSI dependency. This fine in principle, but I don't understand what PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a string?), Yes, it's supposed to be a null-terminated string containing a target triple specification in the standard form many compilers understand, as documented in screen.rst. and how would this scheme work, e.g., if a driver wanted to consume GLSL IR in the future. Hm, I'm not convinced that letting a driver consume GLSL IR would be a good idea in itself. It opens the door to a situation where each driver has to provide a compiler front-end for each individual API it aims to support, and it would break with the principle of having API-agnostic drivers running under a hardware-agnostic state tracker. IMHO, in an ideal world we'd have one common transport IR all drivers would be comfortable with, otherwise you get a matrix of code paths that is likely to get more and more painful to debug and maintain as the number of drivers and state trackers grows. I agree entirely. This idea of passing GLSL IR assumes that GLSL IR would grow to be generic enough to represent any shader, and not just GLSL derived ones. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
- Original Message -
On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
- Original Message -
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
Jose Fonseca jfons...@vmware.com writes:
Francisco,
Sorry for the delay reviewing this, but I haven't been able
to
dedicate some time until now.
Overall, it's a great piece of work! Just a few relatively
minor
comments/requests.
Hi Jose, thanks for the comments.
[...]
gallium/tgsi: Add support for raw resources.
What's the difference between raw resources and buffers?
Shouldn't all
buffers be raw, and non-buffers resources non-row?
The difference is that raw resources have no associated data
type,
so
there's no type conversion between what the shader sees and
what
ends up
stored in memory. This is somewhat orthogonal to the number of
addressing dimensions of the resource, so you can get raw 2D
textures,
3D textures, etc.
You're right that CL only uses raw buffers right now, but D3D11
makes a
similar distinction and both raw and non-raw buffers are likely
to
be
useful if someone tries to implement ByteAddressBuffers and
Buffers,
respectively.
[...]
gallium/compute: Drop TGSI dependency.
This fine in principle, but I don't understand what
PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a
string?),
Yes, it's supposed to be a null-terminated string containing a
target
triple specification in the standard form many compilers
understand,
as documented in screen.rst.
and how would this scheme work, e.g., if a driver wanted to
consume
GLSL IR in the future.
Hm, I'm not convinced that letting a driver consume GLSL IR
would
be a
good idea in itself. It opens the door to a situation where
each
driver
has to provide a compiler front-end for each individual API it
aims
to
support, and it would break with the principle of having
API-agnostic
drivers running under a hardware-agnostic state tracker.
The target triple and the IR type are two separate issues. The
target triple really doesn't say anything about the IR type the
driver
expects. Really, the only purpose of the target triple is to
describe the target
to help the compiler frontend generate correct code.
I think we should also add a query function like this in order to
communicate to
the state tracker the kind of IR it should pass to the driver:
unsigned get_prefered_ir(unsigned shader_type) {
switch(shader_type) {
default:
return GALLIUM_IR_TGSI;
}
}
IMHO, in an ideal world we'd have one common transport IR all
drivers
would be comfortable with, otherwise you get a matrix of code
paths
that
is likely to get more and more painful to debug and maintain as
the
number of drivers and state trackers grows.
As AMD didn't seem to be willing to use TGSI directly in their
compute
stack, the purpose of this change was to simplify the driver
code
in
cases where the front-end compiler already happens to support
the
native
binary format required by the pipe driver, so, right now
PIPE_COMPUTE_CAP_IR_TARGET can be either tgsi or the
hardware's
native
binary format.
I think that an enum would be preferrable.
I'm OK with changing it to an enum if you think it would be
preferable.
What made me decide for a string was that if it were to be an
enum,
we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state
trackers
would
need driver-specific code to make a proper interpretation of
it.
If
it's a string in some standard form the state tracker can just
pass
it
on to the compiler without looking inside.
I think this makes more sense as a string. The target triple is
a
pretty
standard format and as Francisco points out an enum would require
the
state tracker to have driver specific code to determine which
triple
to use.
I'm ok with punching LLVM IR through gallium, but I really would
prefer adding LLVM specific interfaces.
... prefer _not_ adding LLVM specific interfaces.
Also, while you say target triple is a pretty standard format, I
don't see it standardized anywhere. It looks like even LLVM
changes every now and then.
So both things make thing this is a bad interface.
So, let's use an enum for now, like
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R700, /* or maybe PIPE_IR_AMD_IL_R700, as I'm not
entirely sure what's exactly being punched
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
On Wed, Apr 18, 2012 at 10:05:58AM -0700, Jose Fonseca wrote: This idea of passing GLSL IR assumes that GLSL IR would grow to be generic enough to represent any shader, and not just GLSL derived ones. What would be missing from a IR covering GLSL 4.2? Some types maybe? OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] st/mesa: use bitshifting to define state flags
Hi, On Wednesday, April 18, 2012 10:41:56 Brian Paul wrote: Yes. I actually started some work on that a while back but never got back to it. I don't think there'd be any harm in moving the field so I'll go dig up that patch. My goal was to explore having an st_array_object subclass of gl_array_object that would contain pipe_vertex_buffer and pipe_vertex_element state. It would only have to be updated when that array object's state changed. That's about what is lingering around here :) While not many apps use array objects yet, those that did could avoid some (most?) of the draw/array-releted state validation when they did: create_array_objects(); ... glBindVertexArray(1); glDrawArrays(); glBindVertexArray(2); glDrawArrays(); etc.. I started plumbing a gl_array_object pointer through the VBO code but never finished. Wait, I have one small change that safes you from the first crash doing this kind of changes :) Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: use array object constructor
Hi,
The attached change uses the array object factory for gl_array_objects. This
prevents crashes when deriving from gl_array_object.
The change should be orthogonal to Mareks posted changes.
Please Review.
Thanks
MathiasFrom 2f8f27281f44142edd258a62eff6be1fe7f413d8 Mon Sep 17 00:00:00 2001
Message-Id: 2f8f27281f44142edd258a62eff6be1fe7f413d8.1334769748.git.mathias.froehl...@gmx.net
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@web.de
Date: Wed, 2 Nov 2011 19:54:26 +0100
Subject: [PATCH] mesa: use array object constructor
---
src/mesa/main/context.c |3 ++-
src/mesa/main/varray.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 51b0241..a506981 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1118,7 +1118,8 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_free_varray_data(ctx);
_mesa_free_transform_feedback(ctx);
- _mesa_delete_array_object(ctx, ctx-Array.DefaultArrayObj);
+ _mesa_reference_array_object(ctx, ctx-Array.ArrayObj, NULL);
+ _mesa_reference_array_object(ctx, ctx-Array.DefaultArrayObj, NULL);
#if FEATURE_ARB_pixel_buffer_object
_mesa_reference_buffer_object(ctx, ctx-Pack.BufferObj, NULL);
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index a402c7b..0237cdd 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -1221,7 +1221,7 @@ _mesa_print_arrays(struct gl_context *ctx)
void
_mesa_init_varray(struct gl_context *ctx)
{
- ctx-Array.DefaultArrayObj = _mesa_new_array_object(ctx, 0);
+ ctx-Array.DefaultArrayObj = (*ctx-Driver.NewArrayObject)(ctx, 0);
_mesa_reference_array_object(ctx, ctx-Array.ArrayObj,
ctx-Array.DefaultArrayObj);
ctx-Array.ActiveTexture = 0; /* GL_ARB_multitexture */
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
- Original Message - On Wed, Apr 18, 2012 at 10:05:58AM -0700, Jose Fonseca wrote: This idea of passing GLSL IR assumes that GLSL IR would grow to be generic enough to represent any shader, and not just GLSL derived ones. What would be missing from a IR covering GLSL 4.2? Some types maybe? Don't know really. I'm not pushing for this or any direction. Just trying to have a gallium interface that doesn't preclude that scenario, as this has been mentioned before. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: move gl_array_attrib::NewState to gl_array_object::NewArrays
Hi, On Wednesday, April 18, 2012 10:49:41 Brian Paul wrote: From: Brian Paul bri...@vmware.com The field wasn't actually used before and it's not used now either. But this is a more logical place for it and will hopefully allow doing smarter draw/array validation (per array object) in the future. Reviewed-by: Mathias Fröhlich mathias.froehl...@web.de Mathias___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: use array object constructor
On 04/18/2012 11:28 AM, Mathias Fröhlich wrote:
Hi,
The attached change uses the array object factory for gl_array_objects. This
prevents crashes when deriving from gl_array_object.
The change should be orthogonal to Mareks posted changes.
Please Review.
From 2f8f27281f44142edd258a62eff6be1fe7f413d8 Mon Sep 17 00:00:00 2001
Message-Id:
2f8f27281f44142edd258a62eff6be1fe7f413d8.1334769748.git.mathias.froehl...@gmx.net
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@web.de
Date: Wed, 2 Nov 2011 19:54:26 +0100
Subject: [PATCH] mesa: use array object constructor
---
src/mesa/main/context.c |3 ++-
src/mesa/main/varray.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 51b0241..a506981 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1118,7 +1118,8 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_free_varray_data(ctx);
_mesa_free_transform_feedback(ctx);
- _mesa_delete_array_object(ctx, ctx-Array.DefaultArrayObj);
+ _mesa_reference_array_object(ctx, ctx-Array.ArrayObj, NULL);
+ _mesa_reference_array_object(ctx, ctx-Array.DefaultArrayObj, NULL);
#if FEATURE_ARB_pixel_buffer_object
_mesa_reference_buffer_object(ctx, ctx-Pack.BufferObj, NULL);
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index a402c7b..0237cdd 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -1221,7 +1221,7 @@ _mesa_print_arrays(struct gl_context *ctx)
void
_mesa_init_varray(struct gl_context *ctx)
{
- ctx-Array.DefaultArrayObj = _mesa_new_array_object(ctx, 0);
+ ctx-Array.DefaultArrayObj = (*ctx-Driver.NewArrayObject)(ctx, 0);
You can just use ctx-Driver.NewArrayObject(ctx, 0);
_mesa_reference_array_object(ctx, ctx-Array.ArrayObj,
ctx-Array.DefaultArrayObj);
ctx-Array.ActiveTexture = 0; /* GL_ARB_multitexture */
--
1.7.7.6
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] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Wed, 18 Apr 2012 03:32:46 -0700 (PDT), Jeff Gilbert jgilb...@mozilla.com wrote: It depends how much of the spec its in violation of. Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or 1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is guaranteed to be = the 'samples' value used at allocation, but at least 0 or 1 would reflect reality. However, since the spec requires that it gives at least what was requested, there's no reason the user should check the value afterwards, if all they care about is the minimum. I think the most spec-safe way to signal it would be to trigger GL_OUT_OF_MEMORY in response to requests for renderbuffers with samples1 of any size. This is at least theoretically plausible, since no amount of memory will give what was requested. This doesn't give a great indication of what happened, since the assumption will be that it's actually OOM, but seems technically compliant. At least this would give some indication something exceptional or unexpected is happening. It seems (at least for 3.3) that specification of what multisampled sampling requires is pretty minimally-defined, result-wise. If it's as 'up to the implementation' as it seems, it could technically 'multisample' by 'checking' the pixel in the same place N times, so long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives back the same center-of-pixel (0.5,0.5) location for each. This seems to be technically correct in the worst sort of way, but is checkable by the user, and doesn't appear to be otherwise-guaranteed. The spec is long though, so I am quite possibly missing something. Also, is there a bug open against Mesa for this? The lying about MSAA came about from a last-minute oh crap, GL 3.0 guarantees GL_MAX_SAMPLES of 4, but we don't do MSAA. What do we do? We resolved to lie about GL_MAX_SAMPLES so that GL 3.0 applications would at least run even though they would render single-sampled, and add MSAA as soon as possible. Paul's been working on it, and he's got a prototype up and running. Mostly we're limited by how hard it is to write all the tests we need for msaa functionality. pgp7VyO1OA364.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Wed, 18 Apr 2012 15:43:07 -0700 (PDT), Jeff Gilbert jgilb...@mozilla.com wrote: Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or 0/1? It returns the lie. pgpCRp8B2gGnI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] llvmpipe enabled mesa on ARM
Hello, Is it possible to use llvmpipe enabled mesa for ARM cortex-9. ?? If yes,then please give me info. If no,then when it will be possible. Thanks ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
It depends how much of the spec its in violation of. Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or 1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is guaranteed to be = the 'samples' value used at allocation, but at least 0 or 1 would reflect reality. However, since the spec requires that it gives at least what was requested, there's no reason the user should check the value afterwards, if all they care about is the minimum. I think the most spec-safe way to signal it would be to trigger GL_OUT_OF_MEMORY in response to requests for renderbuffers with samples1 of any size. This is at least theoretically plausible, since no amount of memory will give what was requested. This doesn't give a great indication of what happened, since the assumption will be that it's actually OOM, but seems technically compliant. At least this would give some indication something exceptional or unexpected is happening. It seems (at least for 3.3) that specification of what multisampled sampling requires is pretty minimally-defined, result-wise. If it's as 'up to the implementation' as it seems, it could technically 'multisample' by 'checking' the pixel in the same place N times, so long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives back the same center-of-pixel (0.5,0.5) location for each. This seems to be technically correct in the worst sort of way, but is checkable by the user, and doesn't appear to be otherwise-guaranteed. The spec is long though, so I am quite possibly missing something. Also, is there a bug open against Mesa for this? -Jeff - Original Message - From: Benoit Jacob bja...@mozilla.com To: Eric Anholt e...@anholt.net, Jeff Gilbert jgilb...@mozilla.com Cc: mesa-dev@lists.freedesktop.org Sent: Tuesday, April 17, 2012 7:41:33 PM Subject: Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers GL_MAX_SAMPLES tells you how many samples you can ask for from a multisample renderbuffer (GL 3.0 spec page 285), while to ask about the number of samples in a particular GLX visuals you have to check the GLX_SAMPLE_BUFFERS_ARB of the visual (GL_ARB_multisample spec). We currently expose GL_MAX_SAMPLES of 4 (GL 3.0 spec page 391), but that's a lie and if you ask for a 4-sample renderbuffer we don't actually multisample it. We don't expose any GLX visuals with nonzero GLX_SAMPLE_BUFFERS_ARB, which is conformant but disappointing. Thanks for that information. WebGL antialiasing relies in multisample renderbuffers (ARB_framebuffer_multisample), not on multisample GLX visuals. So GL_MAX_SAMPLES is really what we care about. If the value returned by Mesa for getIntegerv(GL_MAX_SAMPLES) can't be used to tell whether multisample renderbuffers are actually supported, then how can we determine that? Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] llvmPipe on ARM (CortexA-9)
I was just looking at this. The release notes say the ARM backend
has basic support for integer code, but even that appears to be
broken, at least for vector types. For the first case of
lp_test_conv, with this IR:
define void @test(8 x i16*, 4 x i32*) {
entry:
%2 = getelementptr 8 x i16* %0, i32 0
%3 = load 8 x i16* %2
%4 = shufflevector 8 x i16 %3, 8 x i16 zeroinitializer, 8 x i32
%5 = shufflevector 8 x i16 %3, 8 x i16 zeroinitializer, 8 x i32
%6 = bitcast 8 x i16 %4 to 4 x i32
%7 = bitcast 8 x i16 %5 to 4 x i32
%8 = getelementptr 4 x i32* %1, i32 0
store 4 x i32 %6, 4 x i32* %8
%9 = getelementptr 4 x i32* %1, i32 1
store 4 x i32 %7, 4 x i32* %9
ret void
}
the x86 backend generates reasonable (SSE) code whereas the ARM
backend generates nonsense:
add r2, r1, r2
andeq r8, r0, r0
add r0, r1, #16
andeq r9, r0, r8
add r2, r1, r2
add r0, r1, r2
bx lr
The other tests fail in various ways, including the error you report,
illegal instructions and hangs.
Comments on llvmdev say the Arm JIT is unmaintained, known to be
dead and broken in many ways. See
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045694.html
and http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047654.html.
Until the MC version of the JIT appears it doesn't look as if llvmpipe
will work on Arm.
Stuart
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or 0/1? -Jeff - Original Message - From: Eric Anholt e...@anholt.net To: Jeff Gilbert jgilb...@mozilla.com, Benoit Jacob bja...@mozilla.com Cc: mesa-dev@lists.freedesktop.org Sent: Wednesday, April 18, 2012 3:07:17 PM Subject: Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers On Wed, 18 Apr 2012 03:32:46 -0700 (PDT), Jeff Gilbert jgilb...@mozilla.com wrote: It depends how much of the spec its in violation of. Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or 1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is guaranteed to be = the 'samples' value used at allocation, but at least 0 or 1 would reflect reality. However, since the spec requires that it gives at least what was requested, there's no reason the user should check the value afterwards, if all they care about is the minimum. I think the most spec-safe way to signal it would be to trigger GL_OUT_OF_MEMORY in response to requests for renderbuffers with samples1 of any size. This is at least theoretically plausible, since no amount of memory will give what was requested. This doesn't give a great indication of what happened, since the assumption will be that it's actually OOM, but seems technically compliant. At least this would give some indication something exceptional or unexpected is happening. It seems (at least for 3.3) that specification of what multisampled sampling requires is pretty minimally-defined, result-wise. If it's as 'up to the implementation' as it seems, it could technically 'multisample' by 'checking' the pixel in the same place N times, so long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives back the same center-of-pixel (0.5,0.5) location for each. This seems to be technically correct in the worst sort of way, but is checkable by the user, and doesn't appear to be otherwise-guaranteed. The spec is long though, so I am quite possibly missing something. Also, is there a bug open against Mesa for this? The lying about MSAA came about from a last-minute oh crap, GL 3.0 guarantees GL_MAX_SAMPLES of 4, but we don't do MSAA. What do we do? We resolved to lie about GL_MAX_SAMPLES so that GL 3.0 applications would at least run even though they would render single-sampled, and add MSAA as soon as possible. Paul's been working on it, and he's got a prototype up and running. Mostly we're limited by how hard it is to write all the tests we need for msaa functionality. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
Jose Fonseca jfons...@vmware.com writes:
- Original Message -
On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
- Original Message -
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
Jose Fonseca jfons...@vmware.com writes:
[...]
I think that an enum would be preferrable.
I'm OK with changing it to an enum if you think it would be
preferable.
What made me decide for a string was that if it were to be an
enum,
we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state
trackers
would
need driver-specific code to make a proper interpretation of
it.
If
it's a string in some standard form the state tracker can just
pass
it
on to the compiler without looking inside.
I think this makes more sense as a string. The target triple is
a
pretty
standard format and as Francisco points out an enum would require
the
state tracker to have driver specific code to determine which
triple
to use.
I'm ok with punching LLVM IR through gallium, but I really would
prefer adding LLVM specific interfaces.
... prefer _not_ adding LLVM specific interfaces.
Also, while you say target triple is a pretty standard format, I
don't see it standardized anywhere. It looks like even LLVM
changes every now and then.
You're right that it's not a real standard, but, that isn't necessarily
a problem, as long as we make explicit in our API the exact format we
expect from the pipe driver, i.e. we don't depend on LLVM to give a
definition of the target triple syntax. If LLVM ever decides to change
their format, I don't see why the state tracker couldn't convert from
one format to another, if the change is deterministic.
I'm thinking that another option would be to replace the IR_TARGET cap
with three different string caps. On the one hand it would have the
advantage of making the internal structure of the target specification
more obvious and easier to process (say the format used by LLVM ever
changes in a non-backwards-compatible way), and on the other hand it
would be easier to maintain than an enum with driver-specific values.
So both things make thing this is a bad interface.
So, let's use an enum for now, like
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R700, /* or maybe PIPE_IR_AMD_IL_R700, as I'm not
entirely sure what's exactly being punched through */
};
It's LLVM IR that is being passed. The enum should look like this:
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R600,
PIPE_IR_LLVM_SI
};
enum pipe_preferred_ir ir = screen-get_shader_param(screen,
shader, PIPE_SHADER_CAP_PREFERRED_IR);
switch( ir) {
default:
case PIPE_IR_TGSI:
/* fallback to TGSI
return FALSE;
case PIPE_IR_LLVM:
target = ???;
break;
case PIPE_IR_LLVM_R700:
target = ???-amd-r700;
break;
}
...
The switch table can be in an inline helper function.
And lets move on. I'm happy to revisit this issue later when there
are more drivers using LLVM IR.
Sounds good.
BTW, why does the frontend need to know the target triplet? That
is, why isn't the frontend passing machine independent LLVM IR,
and let the target specific information be added/processed inside
the target driver?
That's also possible in principle. I'd be OK with dropping this patch
completely if we all agree on a transport IR for compute programs, be it
LLVM, TGSI, or whatever.
I think it needs to know the triplet to determine things like pointer
size and the width of data types like size_t.
Ah yes. I recall this being discussed on LLVM mailing lists -- it looks like
there isn't really a way to make truly target independent IR.
IMHO it would make more sense to add shader params for these kind of
things. Otherwise, I don't think the API would be completely
self-contained, the state tracker (or whatever the user of the compute
API is) would always depend on something external to know how certain
data structures have to be laid out in memory.
Jose
pgpMa4BFtE6qy.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 48899] New: llvmpipe doesn't work with wine 1.5.2 and 3Dmark2001se
https://bugs.freedesktop.org/show_bug.cgi?id=48899 Bug #: 48899 Summary: llvmpipe doesn't work with wine 1.5.2 and 3Dmark2001se Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: rand...@mail.ru Hello. I was trying to debug some nouveau bugs with wine, and ran into few more bugs :/ First, using llvmpipe from mesa master tree up to commit 86f53e6d6bd07e2bc3ffcadeb9a4418fbae06e0b (mesa: Use array object constructor.) and wine 1.5.2 self-compiled on Slackware-13.37 box i run into crash-on-startup. Not sure if it wine or llvmpipe bug, but backtrace point at functions inside swrast driver: -- guest@slax:~/.wine/drive_c/Program Files/MadOnion.com/3DMark2001 SE$ LIBGL_ALWAYS_SOFTWARE=1 LD_PRELOAD=~/botva/src/src/apitrace/wrappers/glxtrace.so wine 3DMark2001SE.exe err:winedevice:load_driver cannot open key L\\Registry\\Machine\\System\\CurrentControlSet\\Services\\PciBus, err=0 err:winedevice:ServiceMain driver LPciBus failed to load fixme:wbemprox:wbem_locator_ConnectServer 0x153970, L.\\root\\cimv2, (null), (null), (null), 0x, (null), (nil), 0x33f3cc) apitrace: redirecting dlopen(libGL.so.1, 0x102) apitrace: tracing to /home/guest/.wine/drive_c/Program Files/MadOnion.com/3DMark2001 SE/wine-preloader.trace apitrace: redirecting dlopen(libGL.so.1, 0x102) fixme:d3d_caps:wined3d_guess_card No card selector available for GL vendor 0x4 and card vendor (using GL_RENDERER Gallium 0.4 on llvmpipe (LLVM 0x209)). wine: Unhandled page fault on read access to 0x at address 0x7d9ca6a7 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x7d9ca6a7). fixme:dbghelp_dwarf:compute_location Only supporting one reg (eax/17 - -2) fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant (parameter) flags in function fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7d9ca6a7 ESP:0033e648 EBP:0033e884 EFLAGS:00210202( R- -- I - - - ) EAX:7c19f8dc EBX:0038 ECX:7c286e54 EDX:7c2b3050 ESI:0033e64c EDI:0033e648 Stack dump: 0x0033e648: 0033e6e8 7c286e50 74726576 0x0033e658: 0004 65646165 3372 0x0033e668: 7d943674 7c2b4968 7c2b4968 0x0033e678: 7c2b56e0 7ca77eea 019ca288 7900 0x0033e688: 7d552a10 7c2b4258 7c27b914 7c28aa20 0x0033e698: 7cb2aff0 7c286e50 0003 0033e6e8 Backtrace: =0 0x7d9ca6a7 (0x0033e884) 1 0x7cb2aa88 llvm_pipeline_generic+0x167(middle=0x33e64c, fetch_info=is not available, prim_info=0x33e93c) [/home/guest/botva/src/src/mesa/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:240] in swrast_dri.so (0x7c2862d8) 2 0x7cb2acac llvm_middle_end_linear_run+0x6b(middle=0x7c28aa20, start=0, count=0x4, prim_flags=0) [/home/guest/botva/src/src/mesa/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:358] in swrast_dri.so (0x0005) 3 0x7ca798ba vsplit_segment_simple_linear.isra+0x69() in swrast_dri.so (0x0005) 4 0x7ca79cce vsplit_run_linear+0x1fd(frontend=0x7c27b8f8, start=0, count=0x4) [/home/guest/botva/src/src/mesa/src/gallium/auxiliary/draw/draw_split_tmp.h:61] in swrast_dri.so (0x0005) 5 0x7ca747b1 draw_pt_arrays+0x150(draw=0x7c2862d8, prim=0x5, start=0, count=0x4) [/home/guest/botva/src/src/mesa/src/gallium/auxiliary/draw/draw_pt.c:142] in swrast_dri.so (0x0004) 6 0x7ca74bb5 draw_vbo+0x184(draw=0x7c2862d8, info=0x33eb58) [/home/guest/botva/src/src/mesa/src/gallium/auxiliary/draw/draw_pt.c:534] in swrast_dri.so (0x7c285990) 7 0x7c88157b llvmpipe_draw_vbo+0xca(pipe=0x7c285990, info=0x33eb58)
[Mesa-dev] [Bug 48899] llvmpipe doesn't work with wine 1.5.2 and 3Dmark2001se
https://bugs.freedesktop.org/show_bug.cgi?id=48899 --- Comment #1 from Andrew Randrianasulu rand...@mail.ru 2012-04-18 17:18:08 PDT --- Created attachment 60288 -- https://bugs.freedesktop.org/attachment.cgi?id=60288 glxinfo log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 48899] llvmpipe doesn't work with wine 1.5.2 and 3Dmark2001se
https://bugs.freedesktop.org/show_bug.cgi?id=48899 --- Comment #2 from Andrew Randrianasulu rand...@mail.ru 2012-04-18 17:19:42 UTC --- Mesa's compilation line was: make distclean ./autogen.sh --prefix=/usr/X11R7 --disable-egl --enable-gallium-llvm --with-gallium-drivers=i915 nouveau r600 r300 swrast --enable-texture-float --with-dri-drivers=i965 r200 radeon nouveau --enable-shared-glapi --enable-gallium-g3dvl --enable-vdpau --enable-debug -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
Tom Stellard thomas.stell...@amd.com writes:
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
Jose Fonseca jfons...@vmware.com writes:
[...]
and how would this scheme work, e.g., if a driver wanted to consume
GLSL IR in the future.
Hm, I'm not convinced that letting a driver consume GLSL IR would be a
good idea in itself. It opens the door to a situation where each driver
has to provide a compiler front-end for each individual API it aims to
support, and it would break with the principle of having API-agnostic
drivers running under a hardware-agnostic state tracker.
The target triple and the IR type are two separate issues. The
target triple really doesn't say anything about the IR type the driver
expects. Really, the only purpose of the target triple is to describe the
target
to help the compiler frontend generate correct code.
Hmm, sorry, I'm not following your argument. Doesn't an exact
specification of the target determine a certain instruction set, and a
certain binary representation of it? The driver just has to be able to
deal with the format it's asking for.
I think we should also add a query function like this in order to communicate
to
the state tracker the kind of IR it should pass to the driver:
unsigned get_prefered_ir(unsigned shader_type) {
switch(shader_type) {
default:
return GALLIUM_IR_TGSI;
}
}
[...]
pgpqJYrEY8P7w.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
On 2012-04-18 09:48-0400, Adam Jackson wrote: On Tue, 2012-04-17 at 23:53 +1000, jupiter@gmail.com wrote: On 2012-04-17 09:34-0400, Adam Jackson wrote: Note that neither one of the above libraries is mentioned in your ldd output, which means libGL was linked incorrectly. What method did you use to build Mesa? The default of the configuration was used. How should I change the default configure to link libX11-xcb and libxcb-glx properly? That's not the answer I was looking for. When I ask what method did you use I expect a reply more like: I ran ./configure and then make or: I ran 'make linux-dri-x86' I ran make linux-dri-x86 and make install, sorry, I thought I put the commands in response. As I said, I followed online document of Compiling and Installing. Unless I was missing something from the document, I guess there is no need to manually run configure to link libX11-xcb and libxcb-glx, correct? Thank you. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] glsl: Add doxygen explaining what main.cpp is for.
I keep getting lost in the Makefile trying to figure out what to edit to work on builtin_compiler or glsl_compiler. --- src/glsl/main.cpp |9 + 1 file changed, 9 insertions(+) diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp index 3231b1b..64c2496 100644 --- a/src/glsl/main.cpp +++ b/src/glsl/main.cpp @@ -22,6 +22,15 @@ */ #include getopt.h +/** @file main.cpp + * + * This file is the main() routine and scaffolding for producing + * builtin_compiler (which doesn't include builtins itself and is used + * to generate the profile information for builtin_function.cpp), and + * for glsl_compiler (which does include builtins and can be used to + * offline compile GLSL code and examine the resulting GLSL IR. + */ + #include ast.h #include glsl_parser_extras.h #include ir_optimization.h -- 1.7.10 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] glsl: Add implementation of inverse() for mat2/3/4.
This is taken from the ogl-math project, with Inverse renamed to adj
(since it's not actually the inverse), transposed, and our types
plugged in.
Fixes piglit inverse tests.
---
src/glsl/Makefile |2 +-
src/glsl/builtins/glsl/inverse.glsl | 105 +++
src/glsl/builtins/profiles/140.glsl |4 ++
3 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644 src/glsl/builtins/glsl/inverse.glsl
diff --git a/src/glsl/Makefile b/src/glsl/Makefile
index f6c7229..7c80c95 100644
--- a/src/glsl/Makefile
+++ b/src/glsl/Makefile
@@ -165,7 +165,7 @@ glcpp/glcpp-parse.c: glcpp/glcpp-parse.y
builtin_compiler: $(GLSL2_OBJECTS) $(OBJECTS) builtin_stubs.o
$(APP_CXX) $(INCLUDES) $(CXXFLAGS) $(LDFLAGS) $(OBJECTS)
$(GLSL2_OBJECTS) builtin_stubs.o -o $@
-builtin_function.cpp: builtins/profiles/* builtins/ir/*
builtins/tools/generate_builtins.py builtins/tools/texture_builtins.py
builtin_compiler
+builtin_function.cpp: builtins/profiles/* builtins/ir/* builtins/glsl/*
builtins/tools/generate_builtins.py builtins/tools/texture_builtins.py
builtin_compiler
@echo Regenerating builtin_function.cpp...
$(PYTHON2) $(PYTHON_FLAGS) builtins/tools/generate_builtins.py
./builtin_compiler builtin_function.cpp || rm -f builtin_function.cpp
diff --git a/src/glsl/builtins/glsl/inverse.glsl
b/src/glsl/builtins/glsl/inverse.glsl
new file mode 100644
index 000..bf558ca
--- /dev/null
+++ b/src/glsl/builtins/glsl/inverse.glsl
@@ -0,0 +1,105 @@
+/* Copyright (c) 2005 - 2012 G-Truc Creation (www.g-truc.net)
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#version 120
+mat2 inverse(mat2 m)
+{
+ mat2 adj;
+ adj[0][0] = m[1][1];
+ adj[0][1] = -m[0][1];
+ adj[1][0] = -m[1][0];
+ adj[1][1] = m[0][0];
+ float det = m[0][0] * m[1][1] - m[1][0] * m[0][1];
+ return adj / det;
+}
+
+mat3 inverse(mat3 m)
+{
+ mat3 adj;
+ adj[0][0] = + (m[1][1] * m[2][2] - m[2][1] * m[1][2]);
+ adj[1][0] = - (m[1][0] * m[2][2] - m[2][0] * m[1][2]);
+ adj[2][0] = + (m[1][0] * m[2][1] - m[2][0] * m[1][1]);
+ adj[0][1] = - (m[0][1] * m[2][2] - m[2][1] * m[0][2]);
+ adj[1][1] = + (m[0][0] * m[2][2] - m[2][0] * m[0][2]);
+ adj[2][1] = - (m[0][0] * m[2][1] - m[2][0] * m[0][1]);
+ adj[0][2] = + (m[0][1] * m[1][2] - m[1][1] * m[0][2]);
+ adj[1][2] = - (m[0][0] * m[1][2] - m[1][0] * m[0][2]);
+ adj[2][2] = + (m[0][0] * m[1][1] - m[1][0] * m[0][1]);
+
+ float det = (+ m[0][0] * (m[1][1] * m[2][2] - m[1][2] * m[2][1])
+ - m[0][1] * (m[1][0] * m[2][2] - m[1][2] * m[2][0])
+ + m[0][2] * (m[1][0] * m[2][1] - m[1][1] * m[2][0]));
+
+ return adj / det;
+}
+
+mat4 inverse(mat4 m)
+{
+ float SubFactor00 = m[2][2] * m[3][3] - m[3][2] * m[2][3];
+ float SubFactor01 = m[2][1] * m[3][3] - m[3][1] * m[2][3];
+ float SubFactor02 = m[2][1] * m[3][2] - m[3][1] * m[2][2];
+ float SubFactor03 = m[2][0] * m[3][3] - m[3][0] * m[2][3];
+ float SubFactor04 = m[2][0] * m[3][2] - m[3][0] * m[2][2];
+ float SubFactor05 = m[2][0] * m[3][1] - m[3][0] * m[2][1];
+ float SubFactor06 = m[1][2] * m[3][3] - m[3][2] * m[1][3];
+ float SubFactor07 = m[1][1] * m[3][3] - m[3][1] * m[1][3];
+ float SubFactor08 = m[1][1] * m[3][2] - m[3][1] * m[1][2];
+ float SubFactor09 = m[1][0] * m[3][3] - m[3][0] * m[1][3];
+ float SubFactor10 = m[1][0] * m[3][2] - m[3][0] * m[1][2];
+ float SubFactor11 = m[1][1] * m[3][3] - m[3][1] * m[1][3];
+ float SubFactor12 = m[1][0] * m[3][1] - m[3][0] * m[1][1];
+ float SubFactor13 = m[1][2] * m[2][3] - m[2][2] * m[1][3];
+ float SubFactor14 = m[1][1] * m[2][3] - m[2][1] * m[1][3];
+ float SubFactor15 = m[1][1] * m[2][2] - m[2][1] * m[1][2];
+ float SubFactor16 = m[1][0] * m[2][3] - m[2][0] * m[1][3];
+ float SubFactor17 = m[1][0] * m[2][2] - m[2][0] * m[1][2];
+ float SubFactor18 = m[1][0] * m[2][1] - m[2][0] * m[1][1];
+
+ mat4 adj;
+
+ adj[0][0] = +
[Mesa-dev] [PATCH 2/4] glsl: Make ir_reader parse the temporary variable qualifier.
This lets ir_reader eat the output of builtin_compiler on actual
function definitions.
---
src/glsl/ir_reader.cpp |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/ir_reader.cpp b/src/glsl/ir_reader.cpp
index 7ce683e..03dbb67 100644
--- a/src/glsl/ir_reader.cpp
+++ b/src/glsl/ir_reader.cpp
@@ -407,6 +407,8 @@ ir_reader::read_declaration(s_expression *expr)
var-mode = ir_var_out;
} else if (strcmp(qualifier-value(), inout) == 0) {
var-mode = ir_var_inout;
+ } else if (strcmp(qualifier-value(), temporary) == 0) {
+var-mode = ir_var_temporary;
} else if (strcmp(qualifier-value(), smooth) == 0) {
var-interpolation = INTERP_QUALIFIER_SMOOTH;
} else if (strcmp(qualifier-value(), flat) == 0) {
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] glsl: Add support for generating builtin code from GLSL instead of IR.
This takes advantage of the builtin compiler to generate IR into a
string, the same way we read GLSL for function prototypes for our
profiles.
---
src/glsl/builtins/tools/generate_builtins.py | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/glsl/builtins/tools/generate_builtins.py
b/src/glsl/builtins/tools/generate_builtins.py
index fb9052b..eada4a6 100755
--- a/src/glsl/builtins/tools/generate_builtins.py
+++ b/src/glsl/builtins/tools/generate_builtins.py
@@ -29,11 +29,23 @@ def read_ir_files(fs):
with open(filename) as f:
fs[function_name] = f.read()
+def read_glsl_files(fs):
+for filename in glob(path.join(path.join(builtins_dir, 'glsl'), '*.glsl')):
+function_name = path.basename(filename).split('.')[0]
+(output, returncode) = run_compiler([filename])
+if (returncode):
+sys.stderr.write(Failed to compile builtin: + filename + \n)
+sys.stderr.write(Result:\n)
+sys.stderr.write(output)
+else:
+fs[function_name] = output;
+
# Return a dictionary containing all builtin definitions (even generated)
def get_builtin_definitions():
fs = {}
generate_texture_functions(fs)
read_ir_files(fs)
+read_glsl_files(fs)
return fs
def stringify(s):
@@ -78,6 +90,10 @@ def run_compiler(args):
# Also toss any duplicate newlines
output = output.replace('\n\n', '\n')
+# Kill any global variable declarations. We don't want them.
+kill_globals = re.compile(r'^\(declare.*\n', re.MULTILINE)
+output = kill_globals.sub('', output)
+
return (output, p.returncode)
def write_profile(filename, profile):
@@ -87,10 +103,6 @@ def write_profile(filename, profile):
print '#error builtins profile', profile, 'failed to compile'
return
-# Kill any global variable declarations. We don't want them.
-kill_globals = re.compile(r'^\(declare.*\n', re.MULTILINE)
-proto_ir = kill_globals.sub('', proto_ir)
-
print 'static const char prototypes_for_' + profile + '[] ='
print stringify(proto_ir), ';'
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] glsl: Add support for generating builtin code from GLSL instead of IR.
On 04/18/2012 06:40 PM, Eric Anholt wrote:
This takes advantage of the builtin compiler to generate IR into a
string, the same way we read GLSL for function prototypes for our
profiles.
---
src/glsl/builtins/tools/generate_builtins.py | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/glsl/builtins/tools/generate_builtins.py
b/src/glsl/builtins/tools/generate_builtins.py
index fb9052b..eada4a6 100755
--- a/src/glsl/builtins/tools/generate_builtins.py
+++ b/src/glsl/builtins/tools/generate_builtins.py
@@ -29,11 +29,23 @@ def read_ir_files(fs):
with open(filename) as f:
fs[function_name] = f.read()
+def read_glsl_files(fs):
+for filename in glob(path.join(path.join(builtins_dir, 'glsl'), '*.glsl')):
This looks good to me. My original patch to do this was similar, though
it detected IR vs. GLSL by looking for a '(' character. That was before
Paul made us use file extensions. This is much simpler.
For patches 1-3:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
For patch 4:
Acked-by: Kenneth Graunke kenn...@whitecape.org
I'm not planning on reviewing the math unless you ask.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix uninitialized member in ir_array_splitting_visitor.
On 04/17/2012 11:49 PM, Vinson Lee wrote:
Fix uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Leev...@freedesktop.org
---
src/glsl/opt_array_splitting.cpp |1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/opt_array_splitting.cpp b/src/glsl/opt_array_splitting.cpp
index f11b516..99b6a22 100644
--- a/src/glsl/opt_array_splitting.cpp
+++ b/src/glsl/opt_array_splitting.cpp
@@ -223,6 +223,7 @@ public:
ir_array_splitting_visitor(exec_list *vars)
{
this-variable_list = vars;
+ this-mem_ctx = NULL;
}
virtual ~ir_array_splitting_visitor()
Initializing it to NULL would mean that we allocate a bunch of memory
that never gets freed. (Admittedly, using it as is, we'd crash horribly.)
But we never actually use it, so I just pushed a patch that deletes the
field entirely. Thanks for pointing this out.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] r600g/automake: add $CFLAGS and $OPT_FLAGS
I didn't check any other drivers besides r300g. I hope CFLAGS is not the only variable containing the -O2 flag... --- src/gallium/drivers/r600/Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r600/Makefile.am b/src/gallium/drivers/r600/Makefile.am index 8acd36a..431dea0 100644 --- a/src/gallium/drivers/r600/Makefile.am +++ b/src/gallium/drivers/r600/Makefile.am @@ -7,9 +7,11 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/gallium/auxiliary \ -I$(top_srcdir)/src/gallium/drivers \ -I$(top_srcdir)/include \ + $(CFLAGS) \ $(RADEON_CFLAGS) \ $(DEFINES) \ $(ASM_FLAGS) \ + $(OPT_FLAGS) \ $(PIC_FLAGS) \ $(VISIBILITY_CFLAGS) -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] r300g/automake: add $CFLAGS and $OPT_FLAGS
--- src/gallium/drivers/r300/Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r300/Makefile.am b/src/gallium/drivers/r300/Makefile.am index af352aa..c4ee08c 100644 --- a/src/gallium/drivers/r300/Makefile.am +++ b/src/gallium/drivers/r300/Makefile.am @@ -13,10 +13,12 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/mesa \ -I$(top_srcdir)/src/glsl \ -I$(top_srcdir)/src/mapi \ + $(CFLAGS) \ $(LLVM_CFLAGS) \ $(RADEON_CFLAGS) \ $(DEFINES) \ $(ASM_FLAGS) \ + $(OPT_FLAGS) \ $(PIC_FLAGS) libr300_a_SOURCES = \ -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] glsl: Add implementation of inverse() for mat2/3/4.
On Wed, Apr 18, 2012 at 06:40:32PM -0700, Eric Anholt wrote:
+mat3 inverse(mat3 m)
+{
+ mat3 adj;
+ adj[0][0] = + (m[1][1] * m[2][2] - m[2][1] * m[1][2]);
+ adj[1][0] = - (m[1][0] * m[2][2] - m[2][0] * m[1][2]);
+ adj[2][0] = + (m[1][0] * m[2][1] - m[2][0] * m[1][1]);
+ adj[0][1] = - (m[0][1] * m[2][2] - m[2][1] * m[0][2]);
+ adj[1][1] = + (m[0][0] * m[2][2] - m[2][0] * m[0][2]);
+ adj[2][1] = - (m[0][0] * m[2][1] - m[2][0] * m[0][1]);
+ adj[0][2] = + (m[0][1] * m[1][2] - m[1][1] * m[0][2]);
+ adj[1][2] = - (m[0][0] * m[1][2] - m[1][0] * m[0][2]);
+ adj[2][2] = + (m[0][0] * m[1][1] - m[1][0] * m[0][1]);
+
+ float det = (+ m[0][0] * (m[1][1] * m[2][2] - m[1][2] * m[2][1])
+ - m[0][1] * (m[1][0] * m[2][2] - m[1][2] * m[2][0])
+ + m[0][2] * (m[1][0] * m[2][1] - m[1][1] * m[2][0]));
Do you think the compiler will notice these are adj[0][0], adj[1][0]
and adj[2][0]?
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
- Original Message -
Jose Fonseca jfons...@vmware.com writes:
- Original Message -
On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
- Original Message -
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez
wrote:
Jose Fonseca jfons...@vmware.com writes:
[...]
I think that an enum would be preferrable.
I'm OK with changing it to an enum if you think it would be
preferable.
What made me decide for a string was that if it were to be
an
enum,
we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state
trackers
would
need driver-specific code to make a proper interpretation of
it.
If
it's a string in some standard form the state tracker can
just
pass
it
on to the compiler without looking inside.
I think this makes more sense as a string. The target triple
is
a
pretty
standard format and as Francisco points out an enum would
require
the
state tracker to have driver specific code to determine which
triple
to use.
I'm ok with punching LLVM IR through gallium, but I really would
prefer adding LLVM specific interfaces.
... prefer _not_ adding LLVM specific interfaces.
Also, while you say target triple is a pretty standard format, I
don't see it standardized anywhere. It looks like even LLVM
changes every now and then.
You're right that it's not a real standard, but, that isn't
necessarily
a problem, as long as we make explicit in our API the exact format we
expect from the pipe driver, i.e. we don't depend on LLVM to give a
definition of the target triple syntax. If LLVM ever decides to
change
their format, I don't see why the state tracker couldn't convert from
one format to another, if the change is deterministic.
I'm thinking that another option would be to replace the IR_TARGET
cap
with three different string caps. On the one hand it would have the
advantage of making the internal structure of the target
specification
more obvious and easier to process (say the format used by LLVM ever
changes in a non-backwards-compatible way), and on the other hand it
would be easier to maintain than an enum with driver-specific values.
So both things make thing this is a bad interface.
So, let's use an enum for now, like
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R700, /* or maybe PIPE_IR_AMD_IL_R700, as I'm
not
entirely sure what's exactly being punched through */
};
It's LLVM IR that is being passed. The enum should look like
this:
enum pipe_ir {
PIPE_IR_TGSI = 0,
PIPE_IR_LLVM,
PIPE_IR_LLVM_R600,
PIPE_IR_LLVM_SI
};
enum pipe_preferred_ir ir = screen-get_shader_param(screen,
shader, PIPE_SHADER_CAP_PREFERRED_IR);
switch( ir) {
default:
case PIPE_IR_TGSI:
/* fallback to TGSI
return FALSE;
case PIPE_IR_LLVM:
target = ???;
break;
case PIPE_IR_LLVM_R700:
target = ???-amd-r700;
break;
}
...
The switch table can be in an inline helper function.
And lets move on. I'm happy to revisit this issue later when
there
are more drivers using LLVM IR.
Sounds good.
BTW, why does the frontend need to know the target triplet? That
is, why isn't the frontend passing machine independent LLVM IR,
and let the target specific information be added/processed
inside
the target driver?
That's also possible in principle. I'd be OK with dropping this
patch
completely if we all agree on a transport IR for compute programs, be
it
LLVM, TGSI, or whatever.
I was not suggesting standarding on LLVM IR vs TGSI, but rather saying that
when LLVM IR is passed, it would be better that it was target agnostic.
I think it needs to know the triplet to determine things like
pointer
size and the width of data types like size_t.
Ah yes. I recall this being discussed on LLVM mailing lists -- it
looks like there isn't really a way to make truly target
independent IR.
IMHO it would make more sense to add shader params for these kind of
things. Otherwise, I don't think the API would be completely
self-contained, the state tracker (or whatever the user of the
compute
API is) would always depend on something external to know how certain
data structures have to be laid out in memory.
That's a good point. If you can replace the triplet by explicit get_shader_cap
queries for size_t / alignment etc then I think that would be the best.
If not, I'd really prefer a pipe_ir/pipe_shader_ir enum as above, as I really I
don't want gallium interface to depend on strings of dubious meaning.
Jose
