[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 79373, which changed state. Bug 79373 Summary: Non-const initializers for matrix and vector constructors https://bugs.freedesktop.org/show_bug.cgi?id=79373 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2] glsl: remove unnecessary check
On Sat, 2014-07-19 at 14:20 +1000, Timothy Arceri wrote:
> On Sat, 2014-07-19 at 12:25 +1000, Timothy Arceri wrote:
> > This code does nothing useful as the next recursive call on the array
> > element
> > will override any null values if the element is a record anyway. The code is
> > also not doing what the comment says as its trying to set the record type
> > pointer for only the first element of the array not the first leaf field
> > of the record.
>
> It's been a while since I wrote this patch so I decided to double check
> it. For a second I thought I should have maybe left the null assignment
> in the array loop, so that if record_type was already passed it wouldn't
> be passed to each array element but that's what happens to each element
> anyway if record_type is null.
>
> For example:
>
> struct S1 {
>vec4 v;
>float f;
> };
>
> struct S {
>S1 s1[3];
>S1 s2;
> };
>
> uniform Ubo {
>S s;
> };
>
>
> Without my patch:
>
> s.s1[0].v == record_type: S
> s.s1[1].v == record_type: S1
> s.s1[2].v == record_type: S1
> s.s1[0].f == record_type: null
> s.s1[1].f == record_type: null
> s.s1[2].f == record_type: null
> s.s2.v == record_type: S1
> s.s2.f == record_type: null
>
> With my patch:
>
> s.s1[0].v == record_type: S
> s.s1[1].v == record_type: S
> s.s1[2].v == record_type: S
> s.s1[0].f == record_type: null
> s.s1[1].f == record_type: null
> s.s1[2].f == record_type: null
> s.s2.v == record_type: S1
> s.s2.v == record_type: null
>
Ok it looks like that code path is just plain broken either way.
I've opened a bug [1] and attached a piglit patch that triggers the
issue the test probably needs some work to make it a little more
thorough before submitting to the piglit list.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=81528
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On 18/07/14 17:27, Kenneth Graunke wrote:
> On Friday, July 18, 2014 07:41:57 AM Dylan Baker wrote:
>> Currently mesa searches for two different environment variables,
>> LIBGL_DRIVERS_PATH and GBM_DRIVERS_PATH. The first is used for search
>> for DRI drivers in every case except GBM, and the latter is used
>> exclusively for setting GBM drivers. This patch simplifies things by
>> having just one variable to set.
>>
>> Signed-off-by: Dylan Baker
>> ---
>> src/gbm/backends/dri/gbm_dri.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index 347bc99..9d9d1c4 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -212,8 +212,8 @@ dri_load_driver(struct gbm_dri_device *dri)
>>
>> search_paths = NULL;
>> if (geteuid() == getuid()) {
>> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
>> - search_paths = getenv("GBM_DRIVERS_PATH");
>> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
>> + search_paths = getenv("LIBGL_DRIVERS_PATH");
>> }
>> if (search_paths == NULL)
>>search_paths = DEFAULT_DRIVER_DIR;
>>
>
> I'm definitely a fan of moving to LIBGL_DRIVERS_PATH for everything -
> GBM_DRIVERS_PATH is just another environment variable to forget to set
> properly.
>
> As is, this is:
> Reviewed-by: Kenneth Graunke
>
> Are people okay with just moving to LIBGL_DRIVERS_PATH completely like this?
> Or do people want it to check GBM_DRIVERS_PATH then fall back to
> LIBGL_DRIVERS_PATH? Or use $GBM_DRIVERS_PATH:$LIBGL_DRIVERS_PATH?
>
A few thoughts of a blurry mind (sorry I'm out of coffee):
I can envision at least at couple of use-cases where either of the above will
cause more harm than good, yet I feel that affected people will come here
after spending hours of debugging/bisecting.
IMHO the "one variable to rule them all" while convenient (set only
LIBGL_DRIVERS_PATH in your debug scripts/session), is not at all useful. If
the only issue is "I always forget to set it", I believe that it's not a thing
that should be addressed in mesa.
This is more of a food for thought than anything else.
-Emil
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Make a llvmpipe context basically thread safe.
Hi Jose, Thanks for reviewing! On Thursday, July 17, 2014 16:01:50 Jose Fonseca wrote: > For patch 1 I'd prefer that instead of keeping a global list of > contexts, these are passed by the caller as argument to gallivm_create() > . It will be a more invasive change, but it will be cleaner. And in > particular it will garantee that when llvmpipe contexts are destroyed > there will be no lingering llvm contexts neither. Ok, the rationale to resort to the pool was for me that the EVT instances in this static map are in the end keyed beyond their type by their LLVMContext pointer value they were belonging to. That means there is a risc of having a LLVMContext that introduces such an EVT entry which is belonging to that LLVMContext and put into the global EVT map. Now assume the LLVMContext gets destroyed and a new one is created later at the same address than the previous one. Now the cached EVT is found but does not belong to the LLVMContext. Now I have no clue if this leads to real problems with these EVT entries nor do we have a huge probability that this really happens. Means that a next LLVMContext is malloced at the same address. But if this is a problem is probably very difficult to track. If you just want to have the LLVMContext instances cleaned up at module unloading so that valgrind runs or similar don't report leaks - we can dispose them at shared library unload. Ahh, I see we even should if we stick with a pool, the driver module might be loaded and unloaded several times which leaks these LLVMContexts with the current series. Also pooling them means that we are guaranteed to not accumulate these EVT instances in that LLVM internal cache as we get at most of them as we have gallivm_state instances around at a time. That means even an application which is repeatedly creating and destroying GL contexts can not go mad memory wise by introducing new EVT instances for LLVMContexts at different addresses. For my use case both above potential problems did never occur. So In the end I don't mind, but wanted to mention this. What do you think? Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78773] Doom3 BFG doesnt start
https://bugs.freedesktop.org/show_bug.cgi?id=78773 --- Comment #9 from Jonathan Gray --- The latest RBDOOM-3-BFG git at the time of writing (485edfebc146c6c60fe4e918d7bb7b18e1e87f1b) seems to work fine with Mesa 10.2.3 on OpenBSD/amd64 with ivybridge mobile/HD4000 without needing to set any additional environment variables. So it seems a recent change in Mesa has fixed this? OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL core profile version string: 3.2 (Core Profile) Mesa 10.2.3 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 3.0 Mesa 10.2.3 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.3 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0 -- 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] [PATCH 5/5] gallium: add tessellation shader properties
Signed-off-by: Ilia Mirkin
---
Please double-check my docs on what these things mean... I'm definitely weak
on all the details, I just know that value X must be stuffed into card method
Y and everything works :)
I had an initial version that also fed the patch size to each of TCS and TES,
but I think that's a mistake. The shader code shouldn't depend on
that... gl_PatchVerticesIn should just be provided via a uniform, and the
value would be passed in via a set_tess_state() or something.
src/gallium/auxiliary/tgsi/tgsi_strings.c | 7 ++-
src/gallium/docs/source/tgsi.rst | 33 ++
src/gallium/include/pipe/p_defines.h | 7 +++
src/gallium/include/pipe/p_shader_tokens.h | 7 ++-
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 37c050b..d220d58 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -128,7 +128,12 @@ const char *tgsi_property_names[TGSI_PROPERTY_COUNT] =
"FS_DEPTH_LAYOUT",
"VS_PROHIBIT_UCPS",
"GS_INVOCATIONS",
- "VS_POSITION_WINDOW_SPACE"
+ "VS_POSITION_WINDOW_SPACE",
+ "TCS_VERTICES_OUT",
+ "TES_PRIM_MODE",
+ "TES_SPACING",
+ "TES_VERTEX_ORDER_CW",
+ "TES_POINT_MODE",
};
const char *tgsi_type_names[5] =
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index d95e941..7349075 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2925,6 +2925,39 @@ Naturally, clipping is not performed on window
coordinates either.
The effect of this property is undefined if a geometry or tessellation shader
are in use.
+TCS_VERTICES_OUT
+
+
+The number of vertices written by the tessellation control shader. This
+effectively defines the patch input size of the tessellation evaluation shader
+as well.
+
+TES_PRIM_MODE
+"
+
+This sets the tessellation primitive mode, one of ``PIPE_PRIM_TRIANGLES``,
+``PIPE_PRIM_QUADS``, or ``PIPE_PRIM_LINES``. (Unlike in GL, there is no
+separate isolines settings, the regular lines is assumed to mean isolines.)
+
+TES_SPACING
+"""
+
+This sets the spacing mode of the tessellation generator, one of
+``PIPE_TESS_SPACING_*``.
+
+TES_VERTEX_ORDER_CW
+"""
+
+This sets the vertex order to be clockwise if the value is 1, or
+counter-clockwise if set to 0.
+
+TES_POINT_MODE
+""
+
+If set to a non-zero value, this turns on point mode for the tessellator,
+which means that points will be generated instead of primitives.
+
+
Texture Sampling and Texture Formats
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 1d257db..c04db09 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -426,6 +426,13 @@ enum pipe_flush_flags {
/**
+ * Tessellator spacing types
+ */
+#define PIPE_TESS_SPACING_FRACT_ODD 0
+#define PIPE_TESS_SPACING_FRACT_EVEN 1
+#define PIPE_TESS_SPACING_EQUAL 2
+
+/**
* Query object types
*/
#define PIPE_QUERY_OCCLUSION_COUNTER 0
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 5e98c60..94809ce 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -249,7 +249,12 @@ union tgsi_immediate_data
#define TGSI_PROPERTY_VS_PROHIBIT_UCPS 7
#define TGSI_PROPERTY_GS_INVOCATIONS 8
#define TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION 9
-#define TGSI_PROPERTY_COUNT 10
+#define TGSI_PROPERTY_TCS_VERTICES_OUT 10
+#define TGSI_PROPERTY_TES_PRIM_MODE 11
+#define TGSI_PROPERTY_TES_SPACING12
+#define TGSI_PROPERTY_TES_VERTEX_ORDER_CW13
+#define TGSI_PROPERTY_TES_POINT_MODE 14
+#define TGSI_PROPERTY_COUNT 15
struct tgsi_property {
unsigned Type : 4; /**< TGSI_TOKEN_TYPE_PROPERTY */
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/5] gallium: add tessellation basics
This just adds the names of things, extends lists, adds a few function entrypoints. It's unlikely that this is everything that will need to be done to the gallium, interface, but I can't imagine a tessellation implementation without these things. So I thought I'd send it out before starting to polish the rest of my patches which rely on these names/concepts/etc. The only big thing missing here that I'm aware of is passing the patch size and default tessouter/inner settings. I was thinking maybe just a set_tess_state() sort of thing. If you can think of other aspects of the interface that I've missed, please point them out. Ilia Mirkin (5): gallium: add tessellation shader types gallium: add new PATCHES primitive type gallium: add new semantics for tessellation gallium: add interfaces for controlling tess program state gallium: add tessellation shader properties src/gallium/auxiliary/tgsi/tgsi_info.c | 4 ++ src/gallium/auxiliary/tgsi/tgsi_strings.c | 18 +++-- src/gallium/auxiliary/tgsi/tgsi_strings.h | 2 +- src/gallium/docs/source/tgsi.rst | 64 ++ src/gallium/include/pipe/p_context.h | 10 + src/gallium/include/pipe/p_defines.h | 16 ++-- src/gallium/include/pipe/p_shader_tokens.h | 17 ++-- 7 files changed, 121 insertions(+), 10 deletions(-) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] gallium: add tessellation shader types
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 4
src/gallium/auxiliary/tgsi/tgsi_strings.c | 4 +++-
src/gallium/auxiliary/tgsi/tgsi_strings.h | 2 +-
src/gallium/include/pipe/p_defines.h | 6 --
src/gallium/include/pipe/p_shader_tokens.h | 4 +++-
5 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index e24348f..3018ded 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -275,6 +275,10 @@ tgsi_get_processor_name( uint processor )
return "fragment shader";
case TGSI_PROCESSOR_GEOMETRY:
return "geometry shader";
+ case TGSI_PROCESSOR_TESSCTRL:
+ return "tessellation control shader";
+ case TGSI_PROCESSOR_TESSEVAL:
+ return "tessellation evaluation shader";
default:
return "unknown shader type!";
}
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..be5534c 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -32,11 +32,13 @@
#include "tgsi_strings.h"
-const char *tgsi_processor_type_names[4] =
+const char *tgsi_processor_type_names[6] =
{
"FRAG",
"VERT",
"GEOM",
+ "TESSC",
+ "TESSE",
"COMP"
};
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h
b/src/gallium/auxiliary/tgsi/tgsi_strings.h
index 1c37c29..0ebed69 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
@@ -38,7 +38,7 @@ extern "C" {
#endif
-extern const char *tgsi_processor_type_names[4];
+extern const char *tgsi_processor_type_names[6];
extern const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT];
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index d9b6e5a..214640c 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -398,8 +398,10 @@ enum pipe_flush_flags {
#define PIPE_SHADER_VERTEX 0
#define PIPE_SHADER_FRAGMENT 1
#define PIPE_SHADER_GEOMETRY 2
-#define PIPE_SHADER_COMPUTE 3
-#define PIPE_SHADER_TYPES4
+#define PIPE_SHADER_TESSCTRL 3
+#define PIPE_SHADER_TESSEVAL 4
+#define PIPE_SHADER_COMPUTE 5
+#define PIPE_SHADER_TYPES6
/**
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 0d3ad6a..01a8128 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -43,7 +43,9 @@ struct tgsi_header
#define TGSI_PROCESSOR_FRAGMENT 0
#define TGSI_PROCESSOR_VERTEX1
#define TGSI_PROCESSOR_GEOMETRY 2
-#define TGSI_PROCESSOR_COMPUTE 3
+#define TGSI_PROCESSOR_TESSCTRL 3
+#define TGSI_PROCESSOR_TESSEVAL 4
+#define TGSI_PROCESSOR_COMPUTE 5
struct tgsi_processor
{
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] gallium: add new semantics for tessellation
Signed-off-by: Ilia Mirkin
---
An alternative to having TESSOUTER/INNER be separate is to create a single
TESSFACTOR semantic with index 0 being the outer, and index 1 being the
inner. I'm pretty ambivalent on the issue though.
src/gallium/auxiliary/tgsi/tgsi_strings.c | 4
src/gallium/docs/source/tgsi.rst | 31 ++
src/gallium/include/pipe/p_shader_tokens.h | 6 +-
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 000df42..37c050b 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -88,6 +88,10 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] =
"SAMPLEPOS",
"SAMPLEMASK",
"INVOCATIONID",
+ "PATCH",
+ "TESSCOORD",
+ "TESSOUTER",
+ "TESSINNER",
};
const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] =
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 093bf7d..d95e941 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2754,6 +2754,37 @@ For geometry shaders, this semantic label indicates that
a system value
contains the current invocation id (i.e. gl_InvocationID). Only the X value is
used.
+TGSI_SEMANTIC_PATCH
+"""
+
+For tessellation evaluation/control shaders, this semantic label indicates a
+generic per-patch attribute. Such semantics will not implicitly be per-vertex
+arrays.
+
+TGSI_SEMANTIC_TESSCOORD
+"""
+
+For tessellation evaluation shaders, this semantic label indicates the
+coordinates of the vertex being processed. This is available in XYZ; W is
+undefined.
+
+TGSI_SEMANTIC_TESSOUTER
+"""
+
+For tessellation evaluation/control shaders, this semantic label indicates the
+outer tessellation levels of the patch. Isoline tessellation will only have XY
+defined, triangle will have XYZ and quads will have XYZW defined. This
+corresponds to gl_TessLevelOuter.
+
+TGSI_SEMANTIC_TESSINNER
+"""
+
+For tessellation evaluation/control shaders, this semantic label indicates the
+inner tessellation levels of the patch. The X value is only defined for
+triangle tessellation, while quads will have XY defined. This is entirely
+undefined for isoline tessellation.
+
+
Declaration Interpolate
^^^
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 01a8128..5e98c60 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -178,7 +178,11 @@ struct tgsi_declaration_interp
#define TGSI_SEMANTIC_SAMPLEPOS 25
#define TGSI_SEMANTIC_SAMPLEMASK 26
#define TGSI_SEMANTIC_INVOCATIONID 27
-#define TGSI_SEMANTIC_COUNT 28 /**< number of semantic values */
+#define TGSI_SEMANTIC_PATCH 28 /**< generic per-patch semantic */
+#define TGSI_SEMANTIC_TESSCOORD 29 /**< coordinate being processed by tess */
+#define TGSI_SEMANTIC_TESSOUTER 30 /**< outer tessellation levels */
+#define TGSI_SEMANTIC_TESSINNER 31 /**< inner tessellation levels */
+#define TGSI_SEMANTIC_COUNT 32 /**< number of semantic values */
struct tgsi_declaration_semantic
{
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] gallium: add new PATCHES primitive type
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index be5534c..000df42 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -166,7 +166,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
"LINES_ADJACENCY",
"LINE_STRIP_ADJACENCY",
"TRIANGLES_ADJACENCY",
- "TRIANGLE_STRIP_ADJACENCY"
+ "TRIANGLE_STRIP_ADJACENCY",
+ "PATCHES",
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 214640c..1d257db 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -421,7 +421,8 @@ enum pipe_flush_flags {
#define PIPE_PRIM_LINE_STRIP_ADJACENCY11
#define PIPE_PRIM_TRIANGLES_ADJACENCY 12
#define PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY 13
-#define PIPE_PRIM_MAX 14
+#define PIPE_PRIM_PATCHES 14
+#define PIPE_PRIM_MAX 15
/**
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] gallium: add interfaces for controlling tess program state
Signed-off-by: Ilia Mirkin
---
There are no docs on any of these shader states. I didn't want to create them
as part of this change, since this is just a copy of whatever fs/vs/gs are
doing.
src/gallium/include/pipe/p_context.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index af5674f..40a0eef 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -170,6 +170,16 @@ struct pipe_context {
void (*bind_gs_state)(struct pipe_context *, void *);
void (*delete_gs_state)(struct pipe_context *, void *);
+ void * (*create_tcs_state)(struct pipe_context *,
+ const struct pipe_shader_state *);
+ void (*bind_tcs_state)(struct pipe_context *, void *);
+ void (*delete_tcs_state)(struct pipe_context *, void *);
+
+ void * (*create_tes_state)(struct pipe_context *,
+ const struct pipe_shader_state *);
+ void (*bind_tes_state)(struct pipe_context *, void *);
+ void (*delete_tes_state)(struct pipe_context *, void *);
+
void * (*create_vertex_elements_state)(struct pipe_context *,
unsigned num_elements,
const struct pipe_vertex_element *);
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] State of llvmpipe geometry shaders?
Brian Paul vmware.com> writes: > > On 07/11/2014 01:47 AM, Florian Link wrote: > > Hi everyone, > > > > I read a post from 2012 that MESA supports geometry shaders. I tried a > > current MESA 10.2.x release, but MESA GL_VERSION returns OpenGL version > > 3.0 (not 3.2) and the > > GL_ARB_geometry_shader4 extension is not reported in the MESA extensions. > > The function lookup for the functions of GL_ARB_geometry_shader4 works, > > though. > > When I run a shader program with a geometry shader, the MESA linker > > complains that the varying that is used in the fragment shader is not > > emitted from the vertex shader, which indicates that the geometry shader > > is not detected/used. > > > > Should geometry shaders work in the current MESA llvm pipe release, or > > do I need to enable/compile in some code? > > > > regards, > > Florian > > > > P.S. My geometry shader works on non-MESA native ATI/NVidia/Intel OpenGL > > drivers, so I don't think it is a problem of my shader code, especially > > the ATI drivers are quite strict. > > llvmpipe supports GS, but only in core profiles. With glxinfo, use the > -c option to see core profile version/extension info. > > -Brian > Hi. I was also wondering about geometry shaders and the core profile with llvmpipe. I have cross compiled Mesa for Windows following the steps at qt- project, then tested the DLL with OpenGL Extensions Viewer. All I get is OpenGL 3.0, and no core profiles. I have tested versions 10.2.2, 10.2.3 and 10.3.0-devel with no luck so far. This message is as close as I have gotten to an answer, but it only seems to indicate that in Linux it just works (if you ask for a core profile). Is it supported in Windows? If so, is there something that needs to be done to enable the core profile? Regards, Paul. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Saturday, July 19, 2014 01:50:39 PM Emil Velikov wrote:
> On 18/07/14 17:27, Kenneth Graunke wrote:
> > On Friday, July 18, 2014 07:41:57 AM Dylan Baker wrote:
> >> Currently mesa searches for two different environment variables,
> >> LIBGL_DRIVERS_PATH and GBM_DRIVERS_PATH. The first is used for search
> >> for DRI drivers in every case except GBM, and the latter is used
> >> exclusively for setting GBM drivers. This patch simplifies things by
> >> having just one variable to set.
> >>
> >> Signed-off-by: Dylan Baker
> >> ---
> >> src/gbm/backends/dri/gbm_dri.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/gbm/backends/dri/gbm_dri.c
> >> b/src/gbm/backends/dri/gbm_dri.c
> >> index 347bc99..9d9d1c4 100644
> >> --- a/src/gbm/backends/dri/gbm_dri.c
> >> +++ b/src/gbm/backends/dri/gbm_dri.c
> >> @@ -212,8 +212,8 @@ dri_load_driver(struct gbm_dri_device *dri)
> >>
> >> search_paths = NULL;
> >> if (geteuid() == getuid()) {
> >> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
> >> - search_paths = getenv("GBM_DRIVERS_PATH");
> >> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
> >> + search_paths = getenv("LIBGL_DRIVERS_PATH");
> >> }
> >> if (search_paths == NULL)
> >>search_paths = DEFAULT_DRIVER_DIR;
> >>
> >
> > I'm definitely a fan of moving to LIBGL_DRIVERS_PATH for everything -
> > GBM_DRIVERS_PATH is just another environment variable to forget to set
> > properly.
> >
> > As is, this is:
> > Reviewed-by: Kenneth Graunke
> >
> > Are people okay with just moving to LIBGL_DRIVERS_PATH completely like
> > this? Or do people want it to check GBM_DRIVERS_PATH then fall back to
> > LIBGL_DRIVERS_PATH? Or use $GBM_DRIVERS_PATH:$LIBGL_DRIVERS_PATH?
> >
> A few thoughts of a blurry mind (sorry I'm out of coffee):
>
> I can envision at least at couple of use-cases where either of the above will
> cause more harm than good, yet I feel that affected people will come here
> after spending hours of debugging/bisecting.
>
> IMHO the "one variable to rule them all" while convenient (set only
> LIBGL_DRIVERS_PATH in your debug scripts/session), is not at all useful. If
> the only issue is "I always forget to set it", I believe that it's not a thing
> that should be addressed in mesa.
>
> This is more of a food for thought than anything else.
> -Emil
But I don't understand the utility of having libGL and GBM use different driver
paths. When is that ever useful? People have asked me on many occasions why
there are two environment variables (usually after getting bitten by this), and
the only explanation I could think of was "because somebody wrote it that way",
i.e. a historical accident. Which isn't a good reason.
If there /is/ a compelling reason to keep both, then I'd like to hear about it.
In particular, if anyone here uses GBM, and actually sets GBM_DRIVERS_PATH and
LIBGL_DRIVERS_PATH separately, please, speak up...
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] r600g/compute: Defrag the pool at the same time as we grow it
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one copy per item) and, even in the
case where we don't need to defrag the pool, we reduce the data copied
to just the useful data that the items use.
Note: The fallback path is a bit ugly now, but hopefully we won't need
it much.
---
src/gallium/drivers/r600/compute_memory_pool.c | 40 --
src/gallium/drivers/r600/compute_memory_pool.h | 2 +-
2 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ca36240..32f5892 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -169,10 +169,12 @@ struct list_head *compute_memory_postalloc_chunk(
* Reallocates pool, conserves data.
* @returns -1 if it fails, 0 otherwise
*/
-int compute_memory_grow_pool(struct compute_memory_pool* pool,
- struct pipe_context * pipe, int new_size_in_dw)
+int compute_memory_grow_defrag_pool(struct compute_memory_pool *pool,
+ struct pipe_context *pipe, int new_size_in_dw)
{
- COMPUTE_DBG(pool->screen, "* compute_memory_grow_pool() "
+ new_size_in_dw = align(new_size_in_dw, ITEM_ALIGNMENT);
+
+ COMPUTE_DBG(pool->screen, "* compute_memory_grow_defrag_pool() "
"new_size_in_dw = %d (%d bytes)\n",
new_size_in_dw, new_size_in_dw * 4);
@@ -183,27 +185,17 @@ int compute_memory_grow_pool(struct compute_memory_pool*
pool,
} else {
struct r600_resource *temp = NULL;
- new_size_in_dw = align(new_size_in_dw, ITEM_ALIGNMENT);
-
- COMPUTE_DBG(pool->screen, " Aligned size = %d (%d bytes)\n",
- new_size_in_dw, new_size_in_dw * 4);
-
temp = (struct r600_resource *)r600_compute_buffer_alloc_vram(
pool->screen,
new_size_in_dw * 4);
if (temp != NULL) {
- struct r600_context *rctx = (struct r600_context *)pipe;
struct pipe_resource *src = (struct pipe_resource
*)pool->bo;
struct pipe_resource *dst = (struct pipe_resource
*)temp;
- struct pipe_box box;
- COMPUTE_DBG(pool->screen, " Growing the pool using a
temporary resource\n");
+ COMPUTE_DBG(pool->screen, " Growing and defragmenting
the pool "
+ "using a temporary resource\n");
- u_box_1d(0, pool->size_in_dw * 4, &box);
-
- rctx->b.b.resource_copy_region(pipe,
- dst, 0, 0, 0 ,0,
- src, 0, &box);
+ compute_memory_defrag(pool, src, dst, pipe);
pool->screen->b.b.resource_destroy(
(struct pipe_screen *)pool->screen,
@@ -229,6 +221,11 @@ int compute_memory_grow_pool(struct compute_memory_pool*
pool,
pool->screen,
pool->size_in_dw * 4);
compute_memory_shadow(pool, pipe, 0);
+
+ if (pool->status & POOL_FRAGMENTED) {
+ struct pipe_resource *src = (struct
pipe_resource *)pool->bo;
+ compute_memory_defrag(pool, src, src, pipe);
+ }
}
}
@@ -292,16 +289,15 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
return 0;
}
- if (pool->status & POOL_FRAGMENTED) {
- struct pipe_resource *src = (struct pipe_resource *)pool->bo;
- compute_memory_defrag(pool, src, src, pipe);
- }
-
if (pool->size_in_dw < allocated + unallocated) {
- err = compute_memory_grow_pool(pool, pipe, allocated +
unallocated);
+ err = compute_memory_grow_defrag_pool(pool, pipe, allocated +
unallocated);
if (err == -1)
return -1;
}
+ else if (pool->status & POOL_FRAGMENTED) {
+ struct pipe_resource *src = (struct pipe_resource *)pool->bo;
+ compute_memory_defrag(pool, src, src, pipe);
+ }
/* After defragmenting the pool, allocated is equal to the first
available
* position for new items in the pool */
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index 5f1d72b..c7eb237 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.h
+++ b/src/gallium/drivers/r600/compute_memory_pool.h
@@ -81,7 +81,7 @@ int64_t compute_memory_prealloc_chunk(struct
compute_memory_pool* pool, int64_t
struct list_head *compute_memory_po
[Mesa-dev] [PATCH 1/3] r600g/compute: Allow compute_memory_move_item to move items between resources
---
src/gallium/drivers/r600/compute_memory_pool.c | 43 ++
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 254c1d7..1ad77ad 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -331,6 +331,7 @@ void compute_memory_defrag(struct compute_memory_pool *pool,
struct pipe_context *pipe)
{
struct compute_memory_item *item;
+ struct pipe_resource *src = (struct pipe_resource *)pool->bo;
int64_t last_pos;
COMPUTE_DBG(pool->screen, "* compute_memory_defrag()\n");
@@ -340,7 +341,8 @@ void compute_memory_defrag(struct compute_memory_pool *pool,
if (item->start_in_dw != last_pos) {
assert(last_pos < item->start_in_dw);
- compute_memory_move_item(pool, item, last_pos, pipe);
+ compute_memory_move_item(pool, src, src,
+ item, last_pos, pipe);
}
last_pos += align(item->size_in_dw, ITEM_ALIGNMENT);
@@ -431,7 +433,8 @@ void compute_memory_demote_item(struct compute_memory_pool
*pool,
}
/**
- * Moves the item \a item forward in the pool to \a new_start_in_dw
+ * Moves the item \a item forward from the resource \a src to the
+ * resource \a dst at \a new_start_in_dw
*
* This function assumes two things:
* 1) The item is \b only moved forward
@@ -442,13 +445,14 @@ void compute_memory_demote_item(struct
compute_memory_pool *pool,
* \see compute_memory_defrag
*/
void compute_memory_move_item(struct compute_memory_pool *pool,
+ struct pipe_resource *src, struct pipe_resource *dst,
struct compute_memory_item *item, uint64_t new_start_in_dw,
struct pipe_context *pipe)
{
struct pipe_screen *screen = (struct pipe_screen *)pool->screen;
struct r600_context *rctx = (struct r600_context *)pipe;
- struct pipe_resource *src = (struct pipe_resource *)pool->bo;
- struct pipe_resource *dst;
+ struct pipe_resource *src_ = src;
+ struct pipe_resource *dst_;
struct pipe_box box;
struct compute_memory_item *prev;
@@ -465,34 +469,35 @@ void compute_memory_move_item(struct compute_memory_pool
*pool,
u_box_1d(item->start_in_dw * 4, item->size_in_dw * 4, &box);
- /* If the ranges don't overlap, we can just copy the item directly */
- if (new_start_in_dw + item->size_in_dw <= item->start_in_dw) {
- dst = (struct pipe_resource *)pool->bo;
+ /* If the ranges don't overlap, or we are copying from one resource
+* to another, we can just copy the item directly */
+ if (src != dst || new_start_in_dw + item->size_in_dw <=
item->start_in_dw) {
+ dst_ = dst;
rctx->b.b.resource_copy_region(pipe,
- dst, 0, new_start_in_dw * 4, 0, 0,
- src, 0, &box);
+ dst_, 0, new_start_in_dw * 4, 0, 0,
+ src_, 0, &box);
} else {
/* The ranges overlap, we will try first to use an intermediate
* resource to move the item */
- dst = (struct pipe_resource *)r600_compute_buffer_alloc_vram(
+ dst_ = (struct pipe_resource *)r600_compute_buffer_alloc_vram(
pool->screen, item->size_in_dw * 4);
- if (dst != NULL) {
+ if (dst_ != NULL) {
rctx->b.b.resource_copy_region(pipe,
- dst, 0, 0, 0, 0,
- src, 0, &box);
+ dst_, 0, 0, 0, 0,
+ src_, 0, &box);
- src = dst;
- dst = (struct pipe_resource *)pool->bo;
+ src_ = dst_;
+ dst_ = dst;
box.x = 0;
rctx->b.b.resource_copy_region(pipe,
- dst, 0, new_start_in_dw * 4, 0, 0,
- src, 0, &box);
+ dst_, 0, new_start_in_dw * 4, 0, 0,
+ src_, 0, &box);
- pool->screen->b.b.resource_destroy(screen, src);
+ pool->screen->b.b.resource_destroy(screen, src_);
} else {
/* The allocation of the temporary resource failed,
@@ -505,7 +510,7 @@ void compute_memory_move_item(struct compute_memory_pool
*pool,
u_box_1d(new_start_in_dw * 4, (offset +
item->size_in_dw) * 4, &box);
- map = pipe->transfer_map(pipe, src, 0,
PIPE_TRANSFER_READ_WRITE,
+ map = pipe-
[Mesa-dev] [PATCH 2/3] r600g/compute: Allow compute_memory_defrag to defragment between resources
This will be used in the following patch to avoid duplicated code
---
src/gallium/drivers/r600/compute_memory_pool.c | 11 ++-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1ad77ad..ca36240 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -293,7 +293,8 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
}
if (pool->status & POOL_FRAGMENTED) {
- compute_memory_defrag(pool, pipe);
+ struct pipe_resource *src = (struct pipe_resource *)pool->bo;
+ compute_memory_defrag(pool, src, src, pipe);
}
if (pool->size_in_dw < allocated + unallocated) {
@@ -328,20 +329,20 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
* \param pool The pool to be defragmented
*/
void compute_memory_defrag(struct compute_memory_pool *pool,
+ struct pipe_resource *src, struct pipe_resource *dst,
struct pipe_context *pipe)
{
struct compute_memory_item *item;
- struct pipe_resource *src = (struct pipe_resource *)pool->bo;
int64_t last_pos;
COMPUTE_DBG(pool->screen, "* compute_memory_defrag()\n");
last_pos = 0;
LIST_FOR_EACH_ENTRY(item, pool->item_list, link) {
- if (item->start_in_dw != last_pos) {
- assert(last_pos < item->start_in_dw);
+ if (src != dst || item->start_in_dw != last_pos) {
+ assert(last_pos <= item->start_in_dw);
- compute_memory_move_item(pool, src, src,
+ compute_memory_move_item(pool, src, dst,
item, last_pos, pipe);
}
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index 822bfbe..5f1d72b 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.h
+++ b/src/gallium/drivers/r600/compute_memory_pool.h
@@ -91,6 +91,7 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
struct pipe_context * pipe);
void compute_memory_defrag(struct compute_memory_pool *pool,
+ struct pipe_resource *src, struct pipe_resource *dst,
struct pipe_context *pipe);
int compute_memory_promote_item(struct compute_memory_pool *pool,
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] r600g/compute: Implement grow+defrag for compute_memory_pool
Hi, This series is a follow up for the 'Adding support for defragmenting compute_memory_pool' series. It also sits on top of the patch I sent here: http://lists.freedesktop.org/archives/mesa-dev/2014-July/062923.html It modifies the function 'compute_memory_grow_pool' so it can defrag the pool at the same time as it grows it, thus reducing the total amount of copies to one per item in the case grow+defrag. In the case where the pool needs to grow, but it's not fragmented, then we copy only the 'real' data that the items have, instead of copying the whole resource, data and garbage at the same time. The fallback path for grow+defrag isn't very good, but hopefully it won't be used much. As usual, if you have any doubt about any of the patches, just ask. Thanks in advance! Bruno Bruno Jiménez (3): r600g/compute: Allow compute_memory_move_item to move items between resources r600g/compute: Allow compute_memory_defrag to defragment between resources r600g/compute: Defrag the pool at the same time as we grow it src/gallium/drivers/r600/compute_memory_pool.c | 86 +- src/gallium/drivers/r600/compute_memory_pool.h | 4 +- 2 files changed, 47 insertions(+), 43 deletions(-) -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79949] [DRI3] GTK+ Programs Not Updating Correctly
https://bugs.freedesktop.org/show_bug.cgi?id=79949 ava1ar changed: What|Removed |Added CC||m...@ava1ar.info -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] i965: Silence many unused parameter warnings
On 07/15/2014 11:18 AM, Matt Turner wrote:
> On Tue, Jul 15, 2014 at 10:56 AM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> brw_inst.h: In function 'brw_inst_set_src1_vstride':
>> brw_inst.h:118:76: warning: unused parameter 'brw' [-Wunused-parameter]
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/mesa/drivers/dri/i965/brw_inst.h | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_inst.h
>> b/src/mesa/drivers/dri/i965/brw_inst.h
>> index e880c9f..719ac8e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_inst.h
>> +++ b/src/mesa/drivers/dri/i965/brw_inst.h
>> @@ -56,6 +56,7 @@ brw_inst_set_##name(const struct brw_context *brw,
>>\
>> brw_inst *inst, uint64_t v) \
>> { \
>> assert(assertions);\
>> + (void) brw;\
>> brw_inst_set_bits(inst, high, low, v); \
>> } \
>> static inline uint64_t\
>> @@ -63,6 +64,7 @@ brw_inst_##name(const struct brw_context *brw,
>>\
>> brw_inst *inst) \
>> { \
>> assert(assertions);\
>> + (void) brw;\
>> return brw_inst_bits(inst, high, low); \
>> }
>>
>> @@ -306,12 +308,14 @@ brw_inst_set_##name(const struct brw_context *brw,
>> brw_inst *inst, int16_t v) \
>> assert(assertions);
>> \
>> assert(v <= (1 << 16) - 1);
>> \
>> assert(v > -(1 << 16));
>> \
>> + (void) brw;
>> \
>> brw_inst_set_bits(inst, high, low, (uint16_t) v);
>> \
>> }
>> \
>> static inline int16_t
>> \
>> brw_inst_##name(const struct brw_context *brw, brw_inst *inst)
>> \
>> {
>> \
>> assert(assertions);
>> \
>> + (void) brw;
>> \
>> return brw_inst_bits(inst, high, low);
>> \
>> }
>>
>> @@ -544,12 +548,14 @@ F(pi_message_data, MD(7), MD(0))
>> static inline int
>> brw_inst_imm_d(const struct brw_context *brw, brw_inst *insn)
>> {
>> + (void) brw;
>> return brw_inst_bits(insn, 127, 96);
>> }
>>
>> static inline unsigned
>> brw_inst_imm_ud(const struct brw_context *brw, brw_inst *insn)
>> {
>> + (void) brw;
>> return brw_inst_bits(insn, 127, 96);
>> }
>>
>> @@ -557,6 +563,7 @@ static inline float
>> brw_inst_imm_f(const struct brw_context *brw, brw_inst *insn)
>> {
>> fi_type ft;
>> + (void) brw;
>> ft.u = brw_inst_bits(insn, 127, 96);
>> return ft.f;
>> }
>> @@ -565,6 +572,7 @@ static inline void
>> brw_inst_set_imm_d(const struct brw_context *brw,
>> brw_inst *insn, int value)
>> {
>> + (void) brw;
>> return brw_inst_set_bits(insn, 127, 96, value);
>> }
>>
>> @@ -572,6 +580,7 @@ static inline void
>> brw_inst_set_imm_ud(const struct brw_context *brw,
>> brw_inst *insn, unsigned value)
>> {
>> + (void) brw;
>> return brw_inst_set_bits(insn, 127, 96, value);
>> }
>>
>> @@ -580,6 +589,7 @@ brw_inst_set_imm_f(const struct brw_context *brw,
>> brw_inst *insn, float value)
>> {
>> fi_type ft;
>> + (void) brw;
>> ft.f = value;
>> brw_inst_set_bits(insn, 127, 96, ft.u);
>> }
>> --
>
> Series is
>
> Reviewed-by: Matt Turner
>
> You could just drop the brw from the function declaration, and avoid
> the (void)brw. That might be nicer.
Unfortunately, that .h file is included from C files, and you can only
do that in C++. :(
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] i965: Silence many unused parameter warnings
On Sat, Jul 19, 2014 at 3:03 PM, Ian Romanick wrote: > On 07/15/2014 11:18 AM, Matt Turner wrote: >> You could just drop the brw from the function declaration, and avoid >> the (void)brw. That might be nicer. > > Unfortunately, that .h file is included from C files, and you can only > do that in C++. :( Oh, right. I just learned that this week, in fact. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/14] i965/gen7: Don't allocate hiz miptree structure
On Fri, Jul 18, 2014 at 1:58 AM, Pohjolainen, Topi
wrote:
> On Tue, Jul 15, 2014 at 06:32:12PM -0700, Jordan Justen wrote:
>> We now skip allocating a hiz miptree for gen7. Instead, we calculate
>> the required hiz buffer parameters and allocate a bo directly.
>>
>> Signed-off-by: Jordan Justen
>> ---
>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95
>> ++-
>> 1 file changed, 93 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> index 8719c29..7e8bec8 100644
>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> @@ -823,7 +823,10 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
>>drm_intel_bo_unreference((*mt)->bo);
>>intel_miptree_release(&(*mt)->stencil_mt);
>>if ((*mt)->hiz_buf) {
>> - intel_miptree_release(&(*mt)->hiz_buf->mt);
>> + if ((*mt)->hiz_buf->mt)
>> +intel_miptree_release(&(*mt)->hiz_buf->mt);
>> + else
>> +drm_intel_bo_unreference((*mt)->hiz_buf->bo);
>> free((*mt)->hiz_buf);
>>}
>>intel_miptree_release(&(*mt)->mcs_mt);
>> @@ -1374,6 +1377,89 @@ intel_miptree_level_enable_hiz(struct brw_context
>> *brw,
>> }
>>
>>
>> +/**
>> + * Helper for intel_miptree_alloc_hiz() that determines the required hiz
>> + * buffer dimensions and allocates a bo for the hiz buffer.
>> + */
>> +static struct intel_miptree_aux_buffer *
>> +intel_gen7_hiz_buf_create(struct brw_context *brw,
>> + struct intel_mipmap_tree *mt)
>> +{
>> + unsigned z_width = mt->logical_width0;
>> + unsigned z_height = mt->logical_height0;
>> + const unsigned z_depth = mt->logical_depth0;
>> + unsigned hz_width, hz_height, qpitch;
>
> Minor nit, qpitch could be called hz_qpitch for clarity as it is a result of
> hiz-specific rules just as hz_width and hz_height. Simple matter of taste and
> you choose the way that you feel the best.
>
>> + struct intel_miptree_aux_buffer *buf = calloc(sizeof(*buf), 1);
>> +
>> + if (!buf)
>> + return NULL;
>> +
>> + /* Gen7 PRM Volume 2, Part 1, 11.5.3 "Hierarchical Depth Buffer"
>> documents
>> +* adjustments required for Z_Height and Z_Width based on multisampling.
>> +*/
>> + switch(mt->num_samples) {
>> + case 0:
>> + case 1:
>> + break;
>> + case 2:
>> + case 4:
>> + z_width *= 2;
>> + z_height *= 2;
>> + break;
>> + case 8:
>> + z_width *= 4;
>> + z_height *= 2;
>> + break;
>> + default:
>> + assert(!"Unsupported sample count!");
>> + }
>> +
>> + const unsigned vertical_align = 8; /* 'j' in the docs */
>> + const unsigned H0 = z_height;
>> + const unsigned h0 = ALIGN(H0, vertical_align);
>> + const unsigned h1 = ALIGN(minify(H0, 1), vertical_align);
>> + const unsigned Z0 = z_depth;
>> +
>> + /* HZ_Width (bytes) = ceiling(Z_Width / 16) * 16 */
>> + hz_width = ALIGN(z_width, 16);
>> +
>> + if (mt->target == GL_TEXTURE_3D) {
>> + unsigned H_i = H0;
>> + unsigned Z_i = Z0;
>> + hz_height = 0;
>> + for (int level = mt->first_level; level <= mt->last_level; ++level) {
>> + unsigned h_i = ALIGN(H_i, vertical_align);
>> + /* sum(i=0 to m; h_i * max(1, floor(Z_Depth/2**i))) */
>
> I had to think for a second if you had typo here (2**i) but then realized
> you used it to mean power-of-two. I've also seen people using 2^i, would that
> make sense to you?
>
>> + hz_height += h_i * Z_i;
>> + H_i = minify(H_i, 1);
>> + Z_i = minify(Z_i, 1);
>> + }
>> + /* HZ_Height =
>> + *(1/2) * sum(i=0 to m; h_i * max(1, floor(Z_Depth/2**i)))
>> + */
>> + hz_height = CEILING(hz_height, 2);
>> + } else {
>> + qpitch = h0 + h1 + (12 * vertical_align);
>> + /* HZ_Height (rows) = Ceiling ( ( Q_pitch * Z_depth/2) /8 ) * 8 */
>> + hz_height = (ALIGN(qpitch, 8) / 2) * Z0;
>
> Here the ALIGN is no-op - qpitch is a sum of three already aligned numbers,
> and hence it is aligned itself. The final result in turn is not always aligned
> (althought is should be). For example, say
>
> qpitch = ALIGN(16, 8) + ALIGN(minify(16, 1), 8) + 12 * 8 = 15 * 8
> ZO = z_depth = 1
>
> => hz_height = (15 * 8 / 2) * 1 = 60
>
> This particular case would probably fine as there is only one layer and still
> a lot of extra. But that may not be the case with higher odd layer numbers
> anymore.
>
> I would change this into:
>
> hz_height = ALIGN(qpitch * Z0 / 2, vertical_align);
The comment above the assignment is from the docs, and it uses the
constant 8, rather than 'j', so I thought it would be better just to
use 8. Although, you are right that it is probably 8 because they set
'j' as 8 for the purposes of hiz calculations.
I also wanted to do the ALIGN before the integer / 2.
How do you feel about:
hz_height = ALIGN
Re: [Mesa-dev] [PATCH V2] glsl: remove unnecessary check
On 07/19/2014 03:24 AM, Timothy Arceri wrote:
> On Sat, 2014-07-19 at 14:20 +1000, Timothy Arceri wrote:
>> On Sat, 2014-07-19 at 12:25 +1000, Timothy Arceri wrote:
>>> This code does nothing useful as the next recursive call on the array
>>> element
>>> will override any null values if the element is a record anyway. The code is
>>> also not doing what the comment says as its trying to set the record type
>>> pointer for only the first element of the array not the first leaf field
>>> of the record.
>>
>> It's been a while since I wrote this patch so I decided to double check
>> it. For a second I thought I should have maybe left the null assignment
>> in the array loop, so that if record_type was already passed it wouldn't
>> be passed to each array element but that's what happens to each element
>> anyway if record_type is null.
>>
>> For example:
>>
>> struct S1 {
>>vec4 v;
>>float f;
>> };
>>
>> struct S {
>>S1 s1[3];
>>S1 s2;
>> };
>>
>> uniform Ubo {
>>S s;
>> };
>>
>>
>> Without my patch:
>>
>> s.s1[0].v == record_type: S
>> s.s1[1].v == record_type: S1
>> s.s1[2].v == record_type: S1
>> s.s1[0].f == record_type: null
>> s.s1[1].f == record_type: null
>> s.s1[2].f == record_type: null
>> s.s2.v == record_type: S1
>> s.s2.f == record_type: null
>>
>> With my patch:
>>
>> s.s1[0].v == record_type: S
>> s.s1[1].v == record_type: S
>> s.s1[2].v == record_type: S
>> s.s1[0].f == record_type: null
>> s.s1[1].f == record_type: null
>> s.s1[2].f == record_type: null
>> s.s2.v == record_type: S1
>> s.s2.v == record_type: null
>>
>
> Ok it looks like that code path is just plain broken either way.
>
> I've opened a bug [1] and attached a piglit patch that triggers the
> issue the test probably needs some work to make it a little more
> thorough before submitting to the piglit list.
I've been digging around in this area... and I have a pretty sizable
patch series coming in the next day or two. I'll compare what you have
with what I have. There are a *LOT* of bugs in the UBO code.
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=81528
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/st: add support for dynamic ubo selection
Signed-off-by: Ilia Mirkin
---
Brian reviewed the first bits of this, but it turns out I had to change
src_register as well. Also I realized that instead of doing the UADD I could
just index2D to 1 in order to generate something like
6: MOV TEMP[0], CONST[ADDR[1].x+1][ADDR[0].x]
So... that's what I did. Anyways, with this (and a small nvc0 adjustment),
nvc0 passes all the new ARB_gs5 ubo tests.
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 62 --
1 file changed, 34 insertions(+), 28 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 5ea1465..27e4615 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1947,16 +1947,16 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
break;
case ir_binop_ubo_load: {
- ir_constant *uniform_block = ir->operands[0]->as_constant();
+ ir_constant *const_uniform_block = ir->operands[0]->as_constant();
ir_constant *const_offset_ir = ir->operands[1]->as_constant();
unsigned const_offset = const_offset_ir ? const_offset_ir->value.u[0] :
0;
+ unsigned const_block = const_uniform_block ?
const_uniform_block->value.u[0] + 1 : 0;
st_src_reg index_reg = get_temp(glsl_type::uint_type);
st_src_reg cbuf;
cbuf.type = glsl_type::vec4_type->base_type;
cbuf.file = PROGRAM_CONSTANT;
cbuf.index = 0;
- cbuf.index2D = uniform_block->value.u[0] + 1;
cbuf.reladdr = NULL;
cbuf.negate = 0;
@@ -1966,7 +1966,6 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
/* Constant index into constant buffer */
cbuf.reladdr = NULL;
cbuf.index = const_offset / 16;
- cbuf.has_index2 = true;
}
else {
/* Relative/variable index into constant buffer */
@@ -1976,6 +1975,20 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
memcpy(cbuf.reladdr, &index_reg, sizeof(index_reg));
}
+ if (const_uniform_block) {
+ /* Constant constant buffer */
+ cbuf.reladdr2 = NULL;
+ cbuf.index2D = const_block;
+ cbuf.has_index2 = true;
+ }
+ else {
+ /* Relative/variable constant buffer */
+ cbuf.reladdr2 = ralloc(mem_ctx, st_src_reg);
+ cbuf.index2D = 1;
+ memcpy(cbuf.reladdr2, &op[0], sizeof(st_src_reg));
+ cbuf.has_index2 = true;
+ }
+
cbuf.swizzle = swizzle_for_size(ir->type->vector_elements);
cbuf.swizzle += MAKE_SWIZZLE4(const_offset % 16 / 4,
const_offset % 16 / 4,
@@ -4367,51 +4380,45 @@ dst_register(struct st_translate *t,
* Map a glsl_to_tgsi src register to a TGSI ureg_src register.
*/
static struct ureg_src
-src_register(struct st_translate *t,
- gl_register_file file,
- GLint index, GLint index2D)
+src_register(struct st_translate *t, const struct st_src_reg *reg)
{
- switch(file) {
+ switch(reg->file) {
case PROGRAM_UNDEFINED:
return ureg_src_undef();
case PROGRAM_TEMPORARY:
case PROGRAM_ARRAY:
- return ureg_src(dst_register(t, file, index));
+ return ureg_src(dst_register(t, reg->file, reg->index));
case PROGRAM_UNIFORM:
- assert(index >= 0);
- return t->constants[index];
+ assert(reg->index >= 0);
+ return t->constants[reg->index];
case PROGRAM_STATE_VAR:
case PROGRAM_CONSTANT: /* ie, immediate */
- if (index2D) {
- struct ureg_src src;
- src = ureg_src_register(TGSI_FILE_CONSTANT, index);
- src.Dimension = 1;
- src.DimensionIndex = index2D;
- return src;
- } else if (index < 0)
+ if (reg->has_index2)
+ return ureg_src_register(TGSI_FILE_CONSTANT, reg->index);
+ else if (reg->index < 0)
return ureg_DECL_constant(t->ureg, 0);
else
- return t->constants[index];
+ return t->constants[reg->index];
case PROGRAM_IMMEDIATE:
- return t->immediates[index];
+ return t->immediates[reg->index];
case PROGRAM_INPUT:
- assert(t->inputMapping[index] < Elements(t->inputs));
- return t->inputs[t->inputMapping[index]];
+ assert(t->inputMapping[reg->index] < Elements(t->inputs));
+ return t->inputs[t->inputMapping[reg->index]];
case PROGRAM_OUTPUT:
- assert(t->outputMapping[index] < Elements(t->outputs));
- return ureg_src(t->outputs[t->outputMapping[index]]); /* not needed? */
+ assert(t->outputMapping[reg->index] < Elements(t->outputs));
+ return ureg_src(t->outputs[t->outputMapping[reg->index]]); /* not
needed? */
case PROGRAM_ADDRESS:
- return ureg_src(t->address[index]);
+ return ureg_src(t->address[reg->index]);
case PROGRAM_SYSTEM_VALUE:
- assert(index < (int) Elements(t->systemValues));
- return t->systemValues[index];
+ assert(reg->index < (int)
