Re: [Mesa-dev] [PATCH v2 20/82] mesa: Implement _mesa_BindBufferRange for target GL_SHADER_STORAGE_BUFFER
19-20 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On 2015-06-03 00:01:10, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index fb5331e..4277880 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3157,6 +3157,40 @@ bind_buffer_range_uniform_buffer(struct gl_context
*ctx,
bind_uniform_buffer(ctx, index, bufObj, offset, size, GL_FALSE);
}
+/**
+ * Bind a region of a buffer object to a shader storage block binding point.
+ * \param index the shader storage buffer binding point index
+ * \param bufObj the buffer object
+ * \param offset offset to the start of buffer object region
+ * \param size size of the buffer object region
+ */
+static void
+bind_buffer_range_shader_storage_buffer(struct gl_context *ctx,
+GLuint index,
+struct gl_buffer_object *bufObj,
+GLintptr offset,
+GLsizeiptr size)
+{
+ if (index = ctx-Const.MaxShaderStorageBufferBindings) {
+ _mesa_error(ctx, GL_INVALID_VALUE, glBindBufferRange(index=%d),
index);
+ return;
+ }
+
+ if (offset (ctx-Const.ShaderStorageBufferOffsetAlignment - 1)) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glBindBufferRange(offset misaligned %d/%d), (int) offset,
+ ctx-Const.ShaderStorageBufferOffsetAlignment);
+ return;
+ }
+
+ if (bufObj == ctx-Shared-NullBufferObj) {
+ offset = -1;
+ size = -1;
+ }
+
+ _mesa_reference_buffer_object(ctx, ctx-ShaderStorageBuffer, bufObj);
+ bind_shader_storage_buffer(ctx, index, bufObj, offset, size, GL_FALSE);
+}
/**
* Bind a buffer object to a uniform block binding point.
@@ -4227,6 +4261,9 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
case GL_UNIFORM_BUFFER:
bind_buffer_range_uniform_buffer(ctx, index, bufObj, offset, size);
return;
+ case GL_SHADER_STORAGE_BUFFER:
+ bind_buffer_range_shader_storage_buffer(ctx, index, bufObj, offset,
size);
+ return;
case GL_ATOMIC_COUNTER_BUFFER:
bind_atomic_buffer(ctx, index, bufObj, offset, size,
glBindBufferRange);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl: handle conversions to double when comparing param matches
This allows mod(int, int) to become selected as float mod when doubles
are supported.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.6 mesa-sta...@lists.freedesktop.org
---
src/glsl/ir_function.cpp | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index 2b2643c..1319443 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -148,9 +148,11 @@ get_parameter_match_type(const ir_variable *param,
if (from_type == to_type)
return PARAMETER_EXACT_MATCH;
- /* XXX: When ARB_gpu_shader_fp64 support is added, check for float-double,
-* and int/uint-double conversions
-*/
+ if (to_type-base_type == GLSL_TYPE_DOUBLE) {
+ if (from_type-base_type == GLSL_TYPE_FLOAT)
+ return PARAMETER_FLOAT_TO_DOUBLE;
+ return PARAMETER_INT_TO_DOUBLE;
+ }
if (to_type-base_type == GLSL_TYPE_FLOAT)
return PARAMETER_INT_TO_FLOAT;
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 22/82] glsl: Do not kill dead assignments to buffer variables or SSBO declarations.
On 2015-06-03 00:01:12, Iago Toral Quiroga wrote:
If we kill dead assignments we lose the buffer writes.
Also, we never kill UBO declarations even if they are never referenced
by the shader, they are always considered active. Although the spec
does not seem say this specifically for SSBOs, it is probably implied
since SSBOs are pretty much the same as UBOs, only that you can write
to them.
---
src/glsl/opt_dead_code.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index f45bf5d..1bb5f32 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -77,11 +77,13 @@ do_dead_code(exec_list *instructions, bool
uniform_locations_assigned)
if (entry-assign) {
/* Remove a single dead assignment to the variable we found.
- * Don't do so if it's a shader or function output, though.
+ * Don't do so if it's a shader or function output or a buffer
+ * variable though.
buffer = shader storage
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
*/
if (entry-var-data.mode != ir_var_function_out
entry-var-data.mode != ir_var_function_inout
- entry-var-data.mode != ir_var_shader_out) {
+ entry-var-data.mode != ir_var_shader_out
+ entry-var-data.mode != ir_var_shader_storage) {
entry-assign-remove();
progress = true;
@@ -99,7 +101,8 @@ do_dead_code(exec_list *instructions, bool
uniform_locations_assigned)
* stage. Also, once uniform locations have been assigned, the
* declaration cannot be deleted.
*/
- if (entry-var-data.mode == ir_var_uniform) {
+ if (entry-var-data.mode == ir_var_uniform ||
+ entry-var-data.mode == ir_var_shader_storage) {
if (uniform_locations_assigned || entry-var-constant_value)
continue;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
So, as is, this patch isn't quite correct. When I originally wrote
NIR, the idea was that the size of each instruction would be explicit
-- that is, each instruction has it's own size, and the size of
registers/SSA values was merely a hint to say by the way, you
actually need this many components based on all the things that use
this value/register. In other words, you could smash num_components
to 4 for everything, and it would still work. Then, we could just
shrink num_components on demand as we got rid of uses of things.
That's why we have functions like nir_tex_instr_src_size(),
nir_tex_instr_dest_size(), and nir_ssa_alu_instr_src_components() that
seem like they're doing the same thing that these functions -- in most
cases, you actually want those functions instead of these. Maybe we
were figuring out the register/value # of components a few times, and
perhaps some of times it was broken, but it seems like adding these
functions would only add to the confusion.
Now, in hindsight, it seems like that might not be the best idea. In
other words, I can see how it would make sense to turn
nir_tex_instr_src_size() etc. into assertions in the validator that
check that nir_(src|dest)_num_components() equals what you would
expect, and it's probably a good idea. But I don't want people to use
these functions without knowing what they're doing until we do that
cleanup.
On Mon, Jun 8, 2015 at 12:45 PM, Rob Clark robdcl...@gmail.com wrote:
From: Rob Clark robcl...@freedesktop.org
I need something like this in a couple places. And didn't see anything
like it anywhere.
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
v2: Added similar helper for nir_src, and cleaned up a few places that
open coded this. There are a couple left (such as validate_alu_src())
but that handle is_packed differently so I thought it best to leave
them as-is.
src/glsl/nir/nir.h | 18 ++
src/glsl/nir/nir_from_ssa.c | 10 ++
src/glsl/nir/nir_validate.c | 4 +---
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 697d37e..06bbb0c 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -541,6 +541,24 @@ typedef struct {
#define nir_foreach_def_safe(reg, dest) \
list_for_each_entry_safe(nir_dest, dest, (reg)-defs, reg.def_link)
+static inline unsigned
+nir_dest_num_components(nir_dest *dest)
+{
+ if (dest-is_ssa)
+ return dest-ssa.num_components;
+ else
+ return dest-reg.reg-num_components;
+}
+
+static inline unsigned
+nir_src_num_components(nir_src *src)
+{
+ if (src-is_ssa)
+ return src-ssa-num_components;
+ else
+ return src-reg.reg-num_components;
+}
+
static inline nir_src
nir_src_for_ssa(nir_ssa_def *def)
{
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 67733e6..23c798d 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -553,10 +553,7 @@ emit_copy(nir_parallel_copy_instr *pcopy, nir_src src,
nir_src dest_src,
dest_src.reg.indirect == NULL
dest_src.reg.base_offset == 0);
- if (src.is_ssa)
- assert(src.ssa-num_components = dest_src.reg.reg-num_components);
- else
- assert(src.reg.reg-num_components =
dest_src.reg.reg-num_components);
+ assert(nir_src_num_components(src) == nir_src_num_components(dest_src));
nir_alu_instr *mov = nir_alu_instr_create(mem_ctx, nir_op_imov);
nir_src_copy(mov-src[0].src, src, mem_ctx);
@@ -712,10 +709,7 @@ resolve_parallel_copy(nir_parallel_copy_instr *pcopy,
nir_register *reg = nir_local_reg_create(state-impl);
reg-name = copy_temp;
reg-num_array_elems = 0;
- if (values[b].is_ssa)
- reg-num_components = values[b].ssa-num_components;
- else
- reg-num_components = values[b].reg.reg-num_components;
+ reg-num_components = nir_src_num_components(values[b]);
values[num_vals].is_ssa = false;
values[num_vals].reg.reg = reg;
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index da92ed9..c781912 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -262,9 +262,7 @@ validate_dest(nir_dest *dest, validate_state *state)
static void
validate_alu_dest(nir_alu_dest *dest, validate_state *state)
{
- unsigned dest_size =
- dest-dest.is_ssa ? dest-dest.ssa.num_components
-: dest-dest.reg.reg-num_components;
+ unsigned dest_size = nir_dest_num_components(dest-dest);
bool is_packed = !dest-dest.is_ssa dest-dest.reg.reg-is_packed;
/*
* validate that the instruction doesn't write to components not in the
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 17/82] mesa: Implement _mesa_BindBuffersBase for target GL_SHADER_STORAGE_BUFFER
On 2015-06-03 00:01:07, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 142
++
src/mesa/main/mtypes.h| 7 +++
2 files changed, 149 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 0e762df..c8b29a7 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3034,6 +3034,33 @@ set_ubo_binding(struct gl_context *ctx,
}
/**
+ * Binds a buffer object to a shader storage buffer binding point.
+ *
+ * The caller is responsible for flushing vertices and updating
+ * NewDriverState.
+ */
+static void
+set_ssbo_binding(struct gl_context *ctx,
+ struct gl_shader_storage_buffer_binding *binding,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset,
+ GLsizeiptr size,
+ GLboolean autoSize)
+{
+ _mesa_reference_buffer_object(ctx, binding-BufferObject, bufObj);
+
+ binding-Offset = offset;
+ binding-Size = size;
+ binding-AutomaticSize = autoSize;
+
+ /* If this is a real buffer object, mark it has having been used
+* at some point as a SSBO.
+*/
+ if (size = 0)
+ bufObj-UsageHistory |= USAGE_SHADER_STORAGE_BUFFER;
+}
+
+/**
* Binds a buffer object to a uniform buffer binding point.
*
* Unlike set_ubo_binding(), this function also flushes vertices
@@ -3254,6 +3281,35 @@ error_check_bind_uniform_buffers(struct gl_context
*ctx,
return true;
}
+static bool
+error_check_bind_shader_storage_buffers(struct gl_context *ctx,
+GLuint first, GLsizei count,
+const char *caller)
+{
+ if (!ctx-Extensions.ARB_shader_storage_buffer_object) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ %s(target=GL_SHADER_STORAGE_BUFFER), caller);
+ return false;
+ }
+
+ /* The ARB_multi_bind_spec says:
+*
+* An INVALID_OPERATION error is generated if first + count is
+* greater than the number of target-specific indexed binding points,
+* as described in section 6.7.1.
+*/
+ if (first + count ctx-Const.MaxShaderStorageBufferBindings) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(first=%u + count=%d the value of
+ GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS=%u),
+ caller, first, count,
+ ctx-Const.MaxShaderStorageBufferBindings);
+ return false;
+ }
+
+ return true;
+}
+
/**
* Unbind all uniform buffers in the range
* first through first+count-1
@@ -3269,6 +3325,22 @@ unbind_uniform_buffers(struct gl_context *ctx, GLuint
first, GLsizei count)
bufObj, -1, -1, GL_TRUE);
}
+/**
+ * Unbind all shader storage buffers in the range
+ * first through first+count-1
+ */
+static void
+unbind_shader_storage_buffers(struct gl_context *ctx, GLuint first,
+ GLsizei count)
+{
+ struct gl_buffer_object *bufObj = ctx-Shared-NullBufferObj;
+ GLint i;
+
+ for (i = 0; i count; i++)
+ set_ssbo_binding(ctx, ctx-ShaderStorageBufferBindings[first + i],
+ bufObj, -1, -1, GL_TRUE);
+}
+
static void
bind_uniform_buffers_base(struct gl_context *ctx, GLuint first, GLsizei
count,
const GLuint *buffers)
@@ -3336,6 +3408,73 @@ bind_uniform_buffers_base(struct gl_context *ctx,
GLuint first, GLsizei count,
}
static void
+bind_shader_storage_buffers_base(struct gl_context *ctx, GLuint first,
+ GLsizei count,const GLuint *buffers)
space before const
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+{
+ GLint i;
+
+ if (!error_check_bind_shader_storage_buffers(ctx, first, count,
+glBindBuffersBase))
+ return;
+
+ /* Assume that at least one binding will be changed */
+ FLUSH_VERTICES(ctx, 0);
+ ctx-NewDriverState |= ctx-DriverFlags.NewShaderStorageBuffer;
+
+ if (!buffers) {
+ /* The ARB_multi_bind spec says:
+ *
+ * If buffers is NULL, all bindings from first through
+ *first+count-1 are reset to their unbound (zero) state.
+ */
+ unbind_shader_storage_buffers(ctx, first, count);
+ return;
+ }
+
+ /* Note that the error semantics for multi-bind commands differ from
+* those of other GL commands.
+*
+* The Issues section in the ARB_multi_bind spec says:
+*
+*(11) Typically, OpenGL specifies that if an error is generated by a
+* command, that command has no effect. This is somewhat
+* unfortunate for multi-bind commands, because it would require
a
+* first pass to scan the entire list of bound objects for errors
+* and then a second pass
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Wed, Jun 17, 2015 at 2:27 PM, Connor Abbott cwabbo...@gmail.com wrote:
So, as is, this patch isn't quite correct. When I originally wrote
NIR, the idea was that the size of each instruction would be explicit
-- that is, each instruction has it's own size, and the size of
registers/SSA values was merely a hint to say by the way, you
actually need this many components based on all the things that use
this value/register. In other words, you could smash num_components
to 4 for everything, and it would still work. Then, we could just
shrink num_components on demand as we got rid of uses of things.
That's why we have functions like nir_tex_instr_src_size(),
nir_tex_instr_dest_size(), and nir_ssa_alu_instr_src_components() that
seem like they're doing the same thing that these functions -- in most
cases, you actually want those functions instead of these. Maybe we
were figuring out the register/value # of components a few times, and
perhaps some of times it was broken, but it seems like adding these
functions would only add to the confusion.
Now, in hindsight, it seems like that might not be the best idea. In
other words, I can see how it would make sense to turn
nir_tex_instr_src_size() etc. into assertions in the validator that
check that nir_(src|dest)_num_components() equals what you would
expect, and it's probably a good idea. But I don't want people to use
these functions without knowing what they're doing until we do that
cleanup.
hmm, fortunately I hadn't pushed my loops branch yet, since still need
to work out how to make variables/arrays work w/ 1 block (since in
nir-land variables are not ssa)..
(really I want phi's for variables too.. the way I turn arrays into
fanin/collect fanout/split works on the backend for dealing with
arrays in ssa form (other than making instruction graph large) but the
way I go from nir to ir3 currently assumes I get nir phi's everywhere
I need an ir3 phi)
Anyways, maybe I'll just move the helpers into ir3 for now until the
is_packed stuff is purged..
BR,
-R
On Mon, Jun 8, 2015 at 12:45 PM, Rob Clark robdcl...@gmail.com wrote:
From: Rob Clark robcl...@freedesktop.org
I need something like this in a couple places. And didn't see anything
like it anywhere.
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
v2: Added similar helper for nir_src, and cleaned up a few places that
open coded this. There are a couple left (such as validate_alu_src())
but that handle is_packed differently so I thought it best to leave
them as-is.
src/glsl/nir/nir.h | 18 ++
src/glsl/nir/nir_from_ssa.c | 10 ++
src/glsl/nir/nir_validate.c | 4 +---
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 697d37e..06bbb0c 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -541,6 +541,24 @@ typedef struct {
#define nir_foreach_def_safe(reg, dest) \
list_for_each_entry_safe(nir_dest, dest, (reg)-defs, reg.def_link)
+static inline unsigned
+nir_dest_num_components(nir_dest *dest)
+{
+ if (dest-is_ssa)
+ return dest-ssa.num_components;
+ else
+ return dest-reg.reg-num_components;
+}
+
+static inline unsigned
+nir_src_num_components(nir_src *src)
+{
+ if (src-is_ssa)
+ return src-ssa-num_components;
+ else
+ return src-reg.reg-num_components;
+}
+
static inline nir_src
nir_src_for_ssa(nir_ssa_def *def)
{
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 67733e6..23c798d 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -553,10 +553,7 @@ emit_copy(nir_parallel_copy_instr *pcopy, nir_src src,
nir_src dest_src,
dest_src.reg.indirect == NULL
dest_src.reg.base_offset == 0);
- if (src.is_ssa)
- assert(src.ssa-num_components = dest_src.reg.reg-num_components);
- else
- assert(src.reg.reg-num_components =
dest_src.reg.reg-num_components);
+ assert(nir_src_num_components(src) ==
nir_src_num_components(dest_src));
nir_alu_instr *mov = nir_alu_instr_create(mem_ctx, nir_op_imov);
nir_src_copy(mov-src[0].src, src, mem_ctx);
@@ -712,10 +709,7 @@ resolve_parallel_copy(nir_parallel_copy_instr *pcopy,
nir_register *reg = nir_local_reg_create(state-impl);
reg-name = copy_temp;
reg-num_array_elems = 0;
- if (values[b].is_ssa)
- reg-num_components = values[b].ssa-num_components;
- else
- reg-num_components = values[b].reg.reg-num_components;
+ reg-num_components = nir_src_num_components(values[b]);
values[num_vals].is_ssa = false;
values[num_vals].reg.reg = reg;
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index da92ed9..c781912 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -262,9 +262,7 @@ validate_dest(nir_dest *dest, validate_state *state)
static
Re: [Mesa-dev] [PATCH v2 18/82] mesa: Implement _mesa_BindBuffersRange for target GL_SHADER_STORAGE_BUFFER
On 2015-06-03 00:01:08, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 110
++
1 file changed, 110 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index c8b29a7..70ac638 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3579,6 +3579,112 @@ bind_uniform_buffers_range(struct gl_context *ctx,
GLuint first, GLsizei count,
_mesa_end_bufferobj_lookups(ctx);
}
+static void
+bind_shader_storage_buffers_range(struct gl_context *ctx, GLuint first,
+ GLsizei count, const GLuint *buffers,
+ const GLintptr *offsets,
+ const GLsizeiptr *sizes)
+{
+ GLint i;
+
+ if (!error_check_bind_shader_storage_buffers(ctx, first, count,
+glBindBuffersRange))
+ return;
+
+ /* Assume that at least one binding will be changed */
+ FLUSH_VERTICES(ctx, 0);
+ ctx-NewDriverState |= ctx-DriverFlags.NewShaderStorageBuffer;
+
+ if (!buffers) {
+ /* The ARB_multi_bind spec says:
+ *
+ *If buffers is NULL, all bindings from first through
+ * first+count-1 are reset to their unbound (zero) state.
+ * In this case, the offsets and sizes associated with the
+ * binding points are set to default values, ignoring
+ * offsets and sizes.
+ */
+ unbind_shader_storage_buffers(ctx, first, count);
+ return;
+ }
+
+ /* Note that the error semantics for multi-bind commands differ from
+* those of other GL commands.
+*
+* The Issues section in the ARB_multi_bind spec says:
+*
+*(11) Typically, OpenGL specifies that if an error is generated by a
+* command, that command has no effect. This is somewhat
+* unfortunate for multi-bind commands, because it would require
a
+* first pass to scan the entire list of bound objects for errors
+* and then a second pass to actually perform the bindings.
+* Should we have different error semantics?
+*
+* RESOLVED: Yes. In this specification, when the parameters for
+* one of the count binding points are invalid, that binding point
+* is not updated and an error will be generated. However, other
+* binding points in the same command will be updated if their
+* parameters are valid and no other error occurs.
+*/
+
+ _mesa_begin_bufferobj_lookups(ctx);
+
+ for (i = 0; i count; i++) {
+ struct gl_shader_storage_buffer_binding *binding =
+ ctx-ShaderStorageBufferBindings[first + i];
+ struct gl_buffer_object *bufObj;
+
+ if (!bind_buffers_check_offset_and_size(ctx, i, offsets, sizes))
+ continue;
+
+ /* The ARB_multi_bind spec says:
+ *
+ * An INVALID_VALUE error is generated by BindBuffersRange if any
+ * pair of values in offsets and sizes does not respectively
+ * satisfy the constraints described for those parameters for the
+ * specified target, as described in section 6.7.1 (per binding).
+ *
+ * Section 6.7.1 refers to table 6.5, which says:
+ *
+ *
┌───┐
+ * │ Shader storage buffer array bindings (see sec. 7.8)
│
+ *
├─┬─┤
+ * │ ...│ ...
│
+ * │ offset restriction │ multiple of value of SHADER_STORAGE_-
│
+ * │ │ BUFFER_OFFSET_ALIGNMENT
│
+ * │ ...│ ...
│
+ * │ size restriction │ none
│
+ *
└─┴─┘
+ */
+ if (offsets[i] (ctx-Const.ShaderStorageBufferOffsetAlignment - 1)) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glBindBuffersRange(offsets[%u]=% PRId64
+ is misaligned; it must be a multiple of the value of
+ GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT=%u when
+ target=GL_UNIFORM_BUFFER),
target=GL_SHADER_STORAGE_BUFFER
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+ i, (int64_t) offsets[i],
+ ctx-Const.ShaderStorageBufferOffsetAlignment);
+ continue;
+ }
+
+ if (binding-BufferObject binding-BufferObject-Name == buffers[i])
+ bufObj = binding-BufferObject;
+ else
+ bufObj = _mesa_multi_bind_lookup_bufferobj(ctx, buffers, i,
+
Re: [Mesa-dev] [PATCH v2 21/82] glsl: Don't do tree grafting on buffer variables
On 2015-06-03 00:01:11, Iago Toral Quiroga wrote: Otherwise we can lose writes into the buffers backing the variables. --- src/glsl/opt_tree_grafting.cpp | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/glsl/opt_tree_grafting.cpp b/src/glsl/opt_tree_grafting.cpp index d47613c..7f2ee6c 100644 --- a/src/glsl/opt_tree_grafting.cpp +++ b/src/glsl/opt_tree_grafting.cpp @@ -359,10 +359,11 @@ tree_grafting_basic_block(ir_instruction *bb_first, if (!lhs_var) continue; - if (lhs_var-data.mode == ir_var_function_out || - lhs_var-data.mode == ir_var_function_inout || - lhs_var-data.mode == ir_var_shader_out) -continue; + if (lhs_var-data.mode == ir_var_function_out || + lhs_var-data.mode == ir_var_function_inout || + lhs_var-data.mode == ir_var_shader_out || + lhs_var-data.mode == ir_var_shader_storage) + continue; This indentation looks wrong. If fixed, Reviewed-by: Jordan Justen jordan.l.jus...@intel.com ir_variable_refcount_entry *entry = info-refs-get_variable_entry(lhs_var); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: add version checks to conditionals for builtin variable enablement
A number of builtin variables have checks based on the extension being
enabled, but were missing enablement via a higher GLSL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
src/glsl/builtin_variables.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 6806aa1..c52b252 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -876,9 +876,9 @@ void
builtin_variable_generator::generate_gs_special_vars()
{
add_output(VARYING_SLOT_LAYER, int_t, gl_Layer);
- if (state-ARB_viewport_array_enable)
+ if (state-is_version(410, 0) || state-ARB_viewport_array_enable)
add_output(VARYING_SLOT_VIEWPORT, int_t, gl_ViewportIndex);
- if (state-ARB_gpu_shader5_enable)
+ if (state-is_version(400, 0) || state-ARB_gpu_shader5_enable)
add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, gl_InvocationID);
/* Although gl_PrimitiveID appears in tessellation control and tessellation
@@ -946,7 +946,7 @@ builtin_variable_generator::generate_fs_special_vars()
var-enable_extension_warning(GL_AMD_shader_stencil_export);
}
- if (state-ARB_sample_shading_enable) {
+ if (state-is_version(400, 0) || state-ARB_sample_shading_enable) {
add_system_value(SYSTEM_VALUE_SAMPLE_ID, int_t, gl_SampleID);
add_system_value(SYSTEM_VALUE_SAMPLE_POS, vec2_t, gl_SamplePosition);
/* From the ARB_sample_shading specification:
@@ -959,11 +959,11 @@ builtin_variable_generator::generate_fs_special_vars()
add_output(FRAG_RESULT_SAMPLE_MASK, array(int_t, 1), gl_SampleMask);
}
- if (state-ARB_gpu_shader5_enable) {
+ if (state-is_version(400, 0) || state-ARB_gpu_shader5_enable) {
add_system_value(SYSTEM_VALUE_SAMPLE_MASK_IN, array(int_t, 1),
gl_SampleMaskIn);
}
- if (state-ARB_fragment_layer_viewport_enable) {
+ if (state-is_version(430, 0) || state-ARB_fragment_layer_viewport_enable)
{
add_input(VARYING_SLOT_LAYER, int_t, gl_Layer);
add_input(VARYING_SLOT_VIEWPORT, int_t, gl_ViewportIndex);
}
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 16/82] mesa: Implement _mesa_DeleteBuffers for target GL_SHADER_STORAGE_BUFFER
On 2015-06-03 00:01:06, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index a528787..0e762df 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1264,6 +1264,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
_mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
}
+ /* unbind SSBO binding points */
+ for (j = 0; j ctx-Const.MaxShaderStorageBufferBindings; j++) {
+if (ctx-ShaderStorageBufferBindings[j].BufferObject == bufObj) {
+ _mesa_BindBufferBase( GL_SHADER_STORAGE_BUFFER, j, 0 );
+}
+ }
+
+ if (ctx-ShaderStorageBuffer == bufObj) {
+_mesa_BindBuffer( GL_SHADER_STORAGE_BUFFER, 0 );
+ }
Can you remove the extra spaces after '(' and before ')'?
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+
/* unbind Atomci Buffer binding points */
for (j = 0; j ctx-Const.MaxAtomicBufferBindings; j++) {
if (ctx-AtomicBufferBindings[j].BufferObject == bufObj) {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api
https://bugs.freedesktop.org/show_bug.cgi?id=91015 Bug ID: 91015 Summary: Piglit regression: spec/ARB_occlusion_query2/api Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: brian.wil...@intel.com QA Contact: mesa-dev@lists.freedesktop.org Piglit test: spec/ARB_occlusion_query2/api We are seeing this Piglit regression on pineview (chromebook, the only chrome platform in our stable still using X and tested with Piglit) The version of Mesa that ChromeOS is currently using passes this test in piglit. It is based on the following commit plus an additional 34 patches: 1291788 glsl: Generate unique names for each const array lowered to uniforms [Nov 2014-ish] It fails in the following Mesa commit: c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend [May 2015-ish] It also fails in this recent Mesa commit: 1a6e4f46ed117b393e26aff326e5b05d4aea7fb0 (gallium: remove explicit values from PIPE_CAP_ enums) [~June 10, 2015] -- You are receiving this mail because: You are the QA Contact for the bug. 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] [PATCHES] Tessellation is here
On Wed, Jun 17, 2015 at 4:48 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 17.06.2015 14:34, schrieb Marek Olšák: Only the RadeonSI driver supports it right now. Marek Marek, will we ever see something on r600 or do we need 'new' boards (Turks, here)? I would like to see on R600, but I don't know if and how much I will be able to help with that. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats
https://bugs.freedesktop.org/show_bug.cgi?id=91014 Bug ID: 91014 Summary: Piglit regression: spec/!OpenGL 1.2/texture-packed-formats Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: brian.wil...@intel.com QA Contact: mesa-dev@lists.freedesktop.org Piglit test: spec/!OpenGL 1.2/texture-packed-formats We are seeing this Piglit regression on pineview (chromebook, the only chrome platform in our stable still using X and tested with Piglit) The version of Mesa that ChromeOS is currently using passes this test in piglit. It is based on the following commit plus an additional 34 patches: 1291788 glsl: Generate unique names for each const array lowered to uniforms [Nov 2014-ish] It fails in the following Mesa commit: c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend [May 2015-ish] It also fails in this recent Mesa commit: 1a6e4f46ed117b393e26aff326e5b05d4aea7fb0 (gallium: remove explicit values from PIPE_CAP_ enums) [~June 10, 2015] -- You are receiving this mail because: You are the QA Contact for the bug. 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 23/82] glsl: Do not do CSE for expressions involving SSBO loads
I wanted to question whether this was required, based on this text
from the extension spec:
The ability to write to buffer objects creates the potential for
multiple independent shader invocations to read and write the same
underlying memory. The same issue exists with the
ARB_shader_image_load_store extension provided in OpenGL 4.2, which
can write to texture objects and buffers. In both cases, the
specification makes few guarantees related to the relative order of
memory reads and writes performed by the shader invocations.
But I'm not sure if we can reconcile CSE with 'memoryBarrier' and
'barrier'. curro, any thoughts from image load/store?
-Jordan
On 2015-06-03 00:01:13, Iago Toral Quiroga wrote:
SSBOs are read/write and this CSE pass only handles read-only variables.
---
src/glsl/opt_cse.cpp | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/src/glsl/opt_cse.cpp b/src/glsl/opt_cse.cpp
index 4b8e9a0..a05ab46 100644
--- a/src/glsl/opt_cse.cpp
+++ b/src/glsl/opt_cse.cpp
@@ -245,6 +245,28 @@ contains_rvalue(ir_rvalue *haystack, ir_rvalue *needle)
}
static bool
+expression_contains_ssbo_load(ir_expression *expr)
+{
+ if (expr-operation == ir_binop_ssbo_load)
+ return true;
+
+ for (unsigned i = 0; i expr-get_num_operands(); i++) {
+ ir_rvalue *op = expr-operands[i];
+ if (op-ir_type == ir_type_expression
+ expression_contains_ssbo_load(op-as_expression())) {
+ return true;
+ } else if (op-ir_type == ir_type_swizzle) {
+ ir_swizzle *swizzle = op-as_swizzle();
+ ir_expression *val = swizzle-val-as_expression();
+ if (val expression_contains_ssbo_load(val))
+return true;
+ }
+ }
+
+ return false;
+}
+
+static bool
is_cse_candidate(ir_rvalue *ir)
{
/* Our temporary variable assignment generation isn't ready to handle
@@ -260,7 +282,16 @@ is_cse_candidate(ir_rvalue *ir)
* to variable-index array dereferences at some point.
*/
switch (ir-ir_type) {
- case ir_type_expression:
+ case ir_type_expression: {
+ /* Skip expressions involving SSBO loads, since these operate on
+ * read-write variables, meaning that the same ssbo_load expression
+ * may return a different value if the underlying buffer storage
+ * is written in between.
+ */
+ if (expression_contains_ssbo_load(ir-as_expression()))
+return false;
+ }
+ break;
case ir_type_texture:
break;
default:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC v2 10/15] i965: enable ASTC support for Skylake
I agree. This will be fixed in the next revision.
On Tue, Jun 9, 2015 at 12:03 PM, Ian Romanick i...@freedesktop.org wrote:
Should this patch be last? It looks like later patches fix bugs.
On 06/01/2015 10:13 AM, Nanley Chery wrote:
From: Nanley Chery nanley.g.ch...@intel.com
v2: remove OES ASTC extension reference.
Signed-off-by: Nanley Chery nanley.g.ch...@intel.com
---
src/mesa/drivers/dri/i965/intel_extensions.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 18b69a0..3c07c8e 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -354,6 +354,11 @@ intelInitExtensions(struct gl_context *ctx)
ctx-Extensions.ARB_stencil_texturing = true;
}
+ if (brw-gen = 9) {
+ ctx-Extensions.KHR_texture_compression_astc_ldr = true;
+ ctx-Extensions.KHR_texture_compression_astc_hdr = true;
+ }
+
if (ctx-API == API_OPENGL_CORE)
ctx-Extensions.ARB_base_instance = true;
if (ctx-API != API_OPENGL_CORE)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: add version checks to conditionals for builtin variable enablement
Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au
On Wed, 2015-06-17 at 15:15 -0400, Ilia Mirkin wrote:
A number of builtin variables have checks based on the extension being
enabled, but were missing enablement via a higher GLSL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
src/glsl/builtin_variables.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 6806aa1..c52b252 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -876,9 +876,9 @@ void
builtin_variable_generator::generate_gs_special_vars()
{
add_output(VARYING_SLOT_LAYER, int_t, gl_Layer);
- if (state-ARB_viewport_array_enable)
+ if (state-is_version(410, 0) || state-ARB_viewport_array_enable)
add_output(VARYING_SLOT_VIEWPORT, int_t, gl_ViewportIndex);
- if (state-ARB_gpu_shader5_enable)
+ if (state-is_version(400, 0) || state-ARB_gpu_shader5_enable)
add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, gl_InvocationID);
/* Although gl_PrimitiveID appears in tessellation control and
tessellation
@@ -946,7 +946,7 @@ builtin_variable_generator::generate_fs_special_vars()
var-enable_extension_warning(GL_AMD_shader_stencil_export);
}
- if (state-ARB_sample_shading_enable) {
+ if (state-is_version(400, 0) || state-ARB_sample_shading_enable) {
add_system_value(SYSTEM_VALUE_SAMPLE_ID, int_t, gl_SampleID);
add_system_value(SYSTEM_VALUE_SAMPLE_POS, vec2_t, gl_SamplePosition);
/* From the ARB_sample_shading specification:
@@ -959,11 +959,11 @@ builtin_variable_generator::generate_fs_special_vars()
add_output(FRAG_RESULT_SAMPLE_MASK, array(int_t, 1), gl_SampleMask);
}
- if (state-ARB_gpu_shader5_enable) {
+ if (state-is_version(400, 0) || state-ARB_gpu_shader5_enable) {
add_system_value(SYSTEM_VALUE_SAMPLE_MASK_IN, array(int_t, 1),
gl_SampleMaskIn);
}
- if (state-ARB_fragment_layer_viewport_enable) {
+ if (state-is_version(430, 0) ||
state-ARB_fragment_layer_viewport_enable) {
add_input(VARYING_SLOT_LAYER, int_t, gl_Layer);
add_input(VARYING_SLOT_VIEWPORT, int_t, gl_ViewportIndex);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965/gen9: Don't use encrypted MOCS
On gen9+ MOCS is an index into a table. It is 7 bits, and AFAICT, bit 0 is for
doing encrypted reads.
I don't recall how I decided to do this for BXT. I don't know this patch was
ever needed, since it seems nothing is broken today on SKL. Furthermore, this
patch may no longer be needed because of the ongoing changes with MOCS setup. It
is what is being used/tested, so it's included in the series.
The chosen values are the old values left shifted. That was also an arbitrary
choice.
Cc: Francisco Jerez curroje...@riseup.net
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index bfcc442..5358edc 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2495,8 +2495,8 @@ enum brw_wm_barycentric_interp_mode {
* cache settings. We still use only either write-back or write-through; and
* rely on the documented default values.
*/
-#define SKL_MOCS_WB 9
-#define SKL_MOCS_WT 5
+#define SKL_MOCS_WB 0x12
+#define SKL_MOCS_WT 0xa
#define MEDIA_VFE_STATE 0x7000
/* GEN7 DW2, GEN8+ DW3 */
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] i965/bxt: Add known PCI IDs
These match the ones defined in the kernel. The only one tested by us is 0x0a84. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- include/pci_ids/i965_pci_ids.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h index 8d757aa..4d8b419 100644 --- a/include/pci_ids/i965_pci_ids.h +++ b/include/pci_ids/i965_pci_ids.h @@ -128,3 +128,6 @@ CHIPSET(0x22B0, chv, Intel(R) HD Graphics (Cherryview)) CHIPSET(0x22B1, chv, Intel(R) HD Graphics (Cherryview)) CHIPSET(0x22B2, chv, Intel(R) HD Graphics (Cherryview)) CHIPSET(0x22B3, chv, Intel(R) HD Graphics (Cherryview)) +CHIPSET(0x0a84, bxt, Intel(R) Broxton) +CHIPSET(0x1a84, bxt, Intel(R) Broxton) +CHIPSET(0x5a84, bxt, Intel(R) Broxton) -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] i965/bxt: Add basic Broxton infrastructure
The thread counts and URB information are all speculative numbers that were
based on some CHV numbers at the time.
v2:
Originally this patch had PCI IDs. I've moved that to a new patch at the end of
the series.
Remove is_cherryview hack.
Cc: Neil Roberts n...@linux.intel.com
Cc: Lecluse, Philippe philippe.lecl...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_device_info.c | 16
src/mesa/drivers/dri/i965/brw_device_info.h | 1 +
4 files changed, 19 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index c629f39..0286577 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -752,6 +752,7 @@ brwCreateContext(gl_api api,
brw-is_baytrail = devinfo-is_baytrail;
brw-is_haswell = devinfo-is_haswell;
brw-is_cherryview = devinfo-is_cherryview;
+ brw-is_broxton = devinfo-is_broxton;
brw-has_llc = devinfo-has_llc;
brw-has_hiz = devinfo-has_hiz_and_separate_stencil;
brw-has_separate_stencil = devinfo-has_hiz_and_separate_stencil;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 58119ee..c60053b 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1125,6 +1125,7 @@ struct brw_context
bool is_baytrail;
bool is_haswell;
bool is_cherryview;
+ bool is_broxton;
bool has_hiz;
bool has_separate_stencil;
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c
b/src/mesa/drivers/dri/i965/brw_device_info.c
index 97243a4..342e566 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -334,6 +334,22 @@ static const struct brw_device_info
brw_device_info_skl_gt3 = {
.supports_simd16_3src = true,
};
+static const struct brw_device_info brw_device_info_bxt = {
+ GEN9_FEATURES,
+ .is_broxton = 1,
+ .gt = 1,
+ .has_llc = false,
+ .max_vs_threads = 112,
+ .max_gs_threads = 112,
+ .max_wm_threads = 32,
+ .urb = {
+ .size = 64,
+ .min_vs_entries = 34,
+ .max_vs_entries = 640,
+ .max_gs_entries = 256,
+ }
+};
+
const struct brw_device_info *
brw_get_device_info(int devid, int revision)
{
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.h
b/src/mesa/drivers/dri/i965/brw_device_info.h
index 65c024c..7b7a1fc 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.h
+++ b/src/mesa/drivers/dri/i965/brw_device_info.h
@@ -35,6 +35,7 @@ struct brw_device_info
bool is_baytrail;
bool is_haswell;
bool is_cherryview;
+ bool is_broxton;
bool has_hiz_and_separate_stencil;
bool must_use_separate_stencil;
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] i965/bxt: Don't allow 16B pitch for blits
NOTE: I can no longer find where this workaround is documented. In my notes it is required for BXT A*, and B*. I'm happy to drop the patch, but I figured I'd put it here for completeness. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- src/mesa/drivers/dri/i965/intel_blit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/intel_blit.c b/src/mesa/drivers/dri/i965/intel_blit.c index d3ab769..bd1a03a 100644 --- a/src/mesa/drivers/dri/i965/intel_blit.c +++ b/src/mesa/drivers/dri/i965/intel_blit.c @@ -380,6 +380,9 @@ intelEmitCopyBlit(struct brw_context *brw, dst_pitch % 4 != 0 || dst_offset % cpp != 0) return false; + if (brw-is_broxton (src_pitch % 16 != 0 || dst_pitch % 16 != 0)) + return false; + /* For big formats (such as floating point), do the copy using 16 or 32bpp * and multiply the coordinates. */ -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91016] Piglit regression: shaders/glsl-floating-constant-120
https://bugs.freedesktop.org/show_bug.cgi?id=91016 Bug ID: 91016 Summary: Piglit regression: shaders/glsl-floating-constant-120 Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: brian.wil...@intel.com QA Contact: mesa-dev@lists.freedesktop.org Piglit test: shaders/glsl-floating-constant-120 We are seeing this Piglit regression on pineview (chromebook, the only chrome platform in our stable still using X and tested with Piglit) The version of Mesa that ChromeOS is currently using passes this test in piglit. It is based on the following commit plus an additional 34 patches: 1291788 glsl: Generate unique names for each const array lowered to uniforms [Nov 2014-ish] It fails in the following Mesa commit: c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend [May 2015-ish] It also fails in this recent Mesa commit: 1a6e4f46ed117b393e26aff326e5b05d4aea7fb0 (gallium: remove explicit values from PIPE_CAP_ enums) [~June 10, 2015] -- You are receiving this mail because: You are the QA Contact for the bug. 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] mesa: store full array type in gl_uniform_storage
I've sent a smaller fix for this bug, will save this change for an
upcoming AoA patch series.
On Wed, 2015-06-17 at 22:24 +1000, Timothy Arceri wrote:
I've created a new piglit test to confirm this fixes a bug in
_mesa_sampler_uniforms_pipeline_are_valid()
http://lists.freedesktop.org/archives/piglit/2015-June/016270.html
I'll update the commit message to:
Previously only the type of a single array element was stored.
_mesa_sampler_uniforms_pipeline_are_valid() was expecting to get the
array type so this fixes a bug with validating arrays of samplers in
SSO.
This change will also useful for implementing arrays of arrays support
in glGetUniformLocation().
I guess this could also be a stable candidate.
On Mon, 2015-06-08 at 18:58 +1000, Timothy Arceri wrote:
Previously only the type of a single array element
was stored.
_mesa_sampler_uniforms_pipeline_are_valid() was expecting to get the array
type so this probably fixes a bug there.
However the main reason for doing this is to use the array type for
implementing arrays of arrays in glGetUniformLocation() in an upcoming
patch series.
---
src/glsl/ir_uniform.h | 5 +-
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 3 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 5 +-
src/mesa/main/shader_query.cpp | 2 +-
src/mesa/main/uniform_query.cpp| 64
++
src/mesa/program/ir_to_mesa.cpp| 7 +--
6 files changed, 46 insertions(+), 40 deletions(-)
diff --git a/src/glsl/ir_uniform.h b/src/glsl/ir_uniform.h
index e1b8014..07dd3c3 100644
--- a/src/glsl/ir_uniform.h
+++ b/src/glsl/ir_uniform.h
@@ -91,9 +91,8 @@ struct gl_opaque_uniform_index {
struct gl_uniform_storage {
char *name;
- /** Type of this uniform data stored.
-*
-* In the case of an array, it's the type of a single array element.
+ /**
+* Type of this uniform
*/
const struct glsl_type *type;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 5d3501c..6b669c2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -220,6 +220,7 @@ fs_visitor::nir_setup_uniform(nir_variable *var)
unsigned index = var-data.driver_location;
for (unsigned u = 0; u shader_prog-NumUniformStorage; u++) {
struct gl_uniform_storage *storage = shader_prog-UniformStorage[u];
+ const glsl_type *type = storage-type-without_array();
if (storage-builtin)
continue;
@@ -231,7 +232,7 @@ fs_visitor::nir_setup_uniform(nir_variable *var)
continue;
}
- unsigned slots = storage-type-component_slots();
+ unsigned slots = type-component_slots();
if (storage-array_elements)
slots *= storage-array_elements;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 242d007..e5874ca 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -685,6 +685,7 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
*/
for (unsigned u = 0; u shader_prog-NumUniformStorage; u++) {
struct gl_uniform_storage *storage = shader_prog-UniformStorage[u];
+ const glsl_type *type = storage-type-without_array();
if (storage-builtin)
continue;
@@ -698,11 +699,11 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
gl_constant_value *components = storage-storage;
unsigned vector_count = (MAX2(storage-array_elements, 1) *
- storage-type-matrix_columns);
+ type-matrix_columns);
for (unsigned s = 0; s vector_count; s++) {
assert(uniforms uniform_array_size);
- uniform_vector_size[uniforms] = storage-type-vector_elements;
+ uniform_vector_size[uniforms] = type-vector_elements;
int i;
for (i = 0; i uniform_vector_size[uniforms]; i++) {
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index a6246a3..807a95c 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -953,7 +953,7 @@ _mesa_program_resource_prop(struct gl_shader_program
*shProg,
case GL_TYPE:
switch (res-Type) {
case GL_UNIFORM:
- *val = RESOURCE_UNI(res)-type-gl_type;
+ *val = RESOURCE_UNI(res)-type-without_array()-gl_type;
return 1;
case GL_PROGRAM_INPUT:
case GL_PROGRAM_OUTPUT:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index cab5083..c8b0b58 100644
--- a/src/mesa/main/uniform_query.cpp
+++
[Mesa-dev] [PATCH] mesa: fix active sampler conflict validation for arrays
The type stored in gl_uniform_storage is the type of a single array
element not the array type so size was always 1
---
src/mesa/main/uniform_query.cpp | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Fixes new piglit test:
http://lists.freedesktop.org/archives/piglit/2015-June/016270.html
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index cab5083..cd558ba 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -1101,15 +1101,14 @@ _mesa_sampler_uniforms_pipeline_are_valid(struct
gl_pipeline_object *pipeline)
for (unsigned i = 0; i shProg[idx]-NumUniformStorage; i++) {
const struct gl_uniform_storage *const storage =
shProg[idx]-UniformStorage[i];
- const glsl_type *const t = (storage-type-is_array())
-? storage-type-fields.array : storage-type;
+ const glsl_type *const t = storage-type;
if (!t-is_sampler())
continue;
active_samplers++;
- const unsigned count = MAX2(1, storage-type-array_size());
+ const unsigned count = MAX2(1, storage-array_elements);
for (unsigned j = 0; j count; j++) {
const unsigned unit = storage-storage[j].i;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 18/82] mesa: Implement _mesa_BindBuffersRange for target GL_SHADER_STORAGE_BUFFER
On 17/06/15 20:56, Jordan Justen wrote:
On 2015-06-03 00:01:08, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 110
++
1 file changed, 110 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index c8b29a7..70ac638 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3579,6 +3579,112 @@ bind_uniform_buffers_range(struct gl_context *ctx,
GLuint first, GLsizei count,
_mesa_end_bufferobj_lookups(ctx);
}
+static void
+bind_shader_storage_buffers_range(struct gl_context *ctx, GLuint first,
+ GLsizei count, const GLuint *buffers,
+ const GLintptr *offsets,
+ const GLsizeiptr *sizes)
+{
+ GLint i;
+
+ if (!error_check_bind_shader_storage_buffers(ctx, first, count,
+glBindBuffersRange))
+ return;
+
+ /* Assume that at least one binding will be changed */
+ FLUSH_VERTICES(ctx, 0);
+ ctx-NewDriverState |= ctx-DriverFlags.NewShaderStorageBuffer;
+
+ if (!buffers) {
+ /* The ARB_multi_bind spec says:
+ *
+ *If buffers is NULL, all bindings from first through
+ * first+count-1 are reset to their unbound (zero) state.
+ * In this case, the offsets and sizes associated with the
+ * binding points are set to default values, ignoring
+ * offsets and sizes.
+ */
+ unbind_shader_storage_buffers(ctx, first, count);
+ return;
+ }
+
+ /* Note that the error semantics for multi-bind commands differ from
+* those of other GL commands.
+*
+* The Issues section in the ARB_multi_bind spec says:
+*
+*(11) Typically, OpenGL specifies that if an error is generated by
a
+* command, that command has no effect. This is somewhat
+* unfortunate for multi-bind commands, because it would
require a
+* first pass to scan the entire list of bound objects for
errors
+* and then a second pass to actually perform the bindings.
+* Should we have different error semantics?
+*
+* RESOLVED: Yes. In this specification, when the parameters for
+* one of the count binding points are invalid, that binding
point
+* is not updated and an error will be generated. However, other
+* binding points in the same command will be updated if their
+* parameters are valid and no other error occurs.
+*/
+
+ _mesa_begin_bufferobj_lookups(ctx);
+
+ for (i = 0; i count; i++) {
+ struct gl_shader_storage_buffer_binding *binding =
+ ctx-ShaderStorageBufferBindings[first + i];
+ struct gl_buffer_object *bufObj;
+
+ if (!bind_buffers_check_offset_and_size(ctx, i, offsets, sizes))
+ continue;
+
+ /* The ARB_multi_bind spec says:
+ *
+ * An INVALID_VALUE error is generated by BindBuffersRange if any
+ * pair of values in offsets and sizes does not respectively
+ * satisfy the constraints described for those parameters for the
+ * specified target, as described in section 6.7.1 (per
binding).
+ *
+ * Section 6.7.1 refers to table 6.5, which says:
+ *
+ *
┌───┐
+ * │ Shader storage buffer array bindings (see sec. 7.8)
│
+ *
├─┬─┤
+ * │ ...│ ...
│
+ * │ offset restriction │ multiple of value of
SHADER_STORAGE_- │
+ * │ │ BUFFER_OFFSET_ALIGNMENT
│
+ * │ ...│ ...
│
+ * │ size restriction │ none
│
+ *
└─┴─┘
+ */
+ if (offsets[i] (ctx-Const.ShaderStorageBufferOffsetAlignment - 1))
{
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glBindBuffersRange(offsets[%u]=% PRId64
+ is misaligned; it must be a multiple of the value of
+ GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT=%u when
+ target=GL_UNIFORM_BUFFER),
target=GL_SHADER_STORAGE_BUFFER
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
OK, thanks.
Sam
+ i, (int64_t) offsets[i],
+ ctx-Const.ShaderStorageBufferOffsetAlignment);
+ continue;
+ }
+
+ if (binding-BufferObject binding-BufferObject-Name ==
buffers[i])
+ bufObj = binding-BufferObject;
+ else
+
Re: [Mesa-dev] [PATCH v2 16/82] mesa: Implement _mesa_DeleteBuffers for target GL_SHADER_STORAGE_BUFFER
On 17/06/15 20:44, Jordan Justen wrote:
On 2015-06-03 00:01:06, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index a528787..0e762df 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1264,6 +1264,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
_mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
}
+ /* unbind SSBO binding points */
+ for (j = 0; j ctx-Const.MaxShaderStorageBufferBindings; j++) {
+if (ctx-ShaderStorageBufferBindings[j].BufferObject == bufObj)
{
+ _mesa_BindBufferBase( GL_SHADER_STORAGE_BUFFER, j, 0 );
+}
+ }
+
+ if (ctx-ShaderStorageBuffer == bufObj) {
+_mesa_BindBuffer( GL_SHADER_STORAGE_BUFFER, 0 );
+ }
Can you remove the extra spaces after '(' and before ')'?
Sure, I will remove them. They were added as it was the convention for
similar code in this file.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Thanks,
Sam
+
/* unbind Atomci Buffer binding points */
for (j = 0; j ctx-Const.MaxAtomicBufferBindings; j++) {
if (ctx-AtomicBufferBindings[j].BufferObject == bufObj) {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 17/82] mesa: Implement _mesa_BindBuffersBase for target GL_SHADER_STORAGE_BUFFER
On 17/06/15 20:47, Jordan Justen wrote:
On 2015-06-03 00:01:07, Iago Toral Quiroga wrote:
---
src/mesa/main/bufferobj.c | 142
++
src/mesa/main/mtypes.h| 7 +++
2 files changed, 149 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 0e762df..c8b29a7 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3034,6 +3034,33 @@ set_ubo_binding(struct gl_context *ctx,
}
/**
+ * Binds a buffer object to a shader storage buffer binding point.
+ *
+ * The caller is responsible for flushing vertices and updating
+ * NewDriverState.
+ */
+static void
+set_ssbo_binding(struct gl_context *ctx,
+ struct gl_shader_storage_buffer_binding *binding,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset,
+ GLsizeiptr size,
+ GLboolean autoSize)
+{
+ _mesa_reference_buffer_object(ctx, binding-BufferObject, bufObj);
+
+ binding-Offset = offset;
+ binding-Size = size;
+ binding-AutomaticSize = autoSize;
+
+ /* If this is a real buffer object, mark it has having been used
+* at some point as a SSBO.
+*/
+ if (size = 0)
+ bufObj-UsageHistory |= USAGE_SHADER_STORAGE_BUFFER;
+}
+
+/**
* Binds a buffer object to a uniform buffer binding point.
*
* Unlike set_ubo_binding(), this function also flushes vertices
@@ -3254,6 +3281,35 @@ error_check_bind_uniform_buffers(struct gl_context
*ctx,
return true;
}
+static bool
+error_check_bind_shader_storage_buffers(struct gl_context *ctx,
+GLuint first, GLsizei count,
+const char *caller)
+{
+ if (!ctx-Extensions.ARB_shader_storage_buffer_object) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ %s(target=GL_SHADER_STORAGE_BUFFER), caller);
+ return false;
+ }
+
+ /* The ARB_multi_bind_spec says:
+*
+* An INVALID_OPERATION error is generated if first + count is
+* greater than the number of target-specific indexed binding
points,
+* as described in section 6.7.1.
+*/
+ if (first + count ctx-Const.MaxShaderStorageBufferBindings) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(first=%u + count=%d the value of
+ GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS=%u),
+ caller, first, count,
+ ctx-Const.MaxShaderStorageBufferBindings);
+ return false;
+ }
+
+ return true;
+}
+
/**
* Unbind all uniform buffers in the range
* first through first+count-1
@@ -3269,6 +3325,22 @@ unbind_uniform_buffers(struct gl_context *ctx, GLuint
first, GLsizei count)
bufObj, -1, -1, GL_TRUE);
}
+/**
+ * Unbind all shader storage buffers in the range
+ * first through first+count-1
+ */
+static void
+unbind_shader_storage_buffers(struct gl_context *ctx, GLuint first,
+ GLsizei count)
+{
+ struct gl_buffer_object *bufObj = ctx-Shared-NullBufferObj;
+ GLint i;
+
+ for (i = 0; i count; i++)
+ set_ssbo_binding(ctx, ctx-ShaderStorageBufferBindings[first + i],
+ bufObj, -1, -1, GL_TRUE);
+}
+
static void
bind_uniform_buffers_base(struct gl_context *ctx, GLuint first, GLsizei
count,
const GLuint *buffers)
@@ -3336,6 +3408,73 @@ bind_uniform_buffers_base(struct gl_context *ctx,
GLuint first, GLsizei count,
}
static void
+bind_shader_storage_buffers_base(struct gl_context *ctx, GLuint first,
+ GLsizei count,const GLuint *buffers)
space before const
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
OK, thanks.
Sam
+{
+ GLint i;
+
+ if (!error_check_bind_shader_storage_buffers(ctx, first, count,
+glBindBuffersBase))
+ return;
+
+ /* Assume that at least one binding will be changed */
+ FLUSH_VERTICES(ctx, 0);
+ ctx-NewDriverState |= ctx-DriverFlags.NewShaderStorageBuffer;
+
+ if (!buffers) {
+ /* The ARB_multi_bind spec says:
+ *
+ * If buffers is NULL, all bindings from first through
+ *first+count-1 are reset to their unbound (zero) state.
+ */
+ unbind_shader_storage_buffers(ctx, first, count);
+ return;
+ }
+
+ /* Note that the error semantics for multi-bind commands differ from
+* those of other GL commands.
+*
+* The Issues section in the ARB_multi_bind spec says:
+*
+*(11) Typically, OpenGL specifies that if an error is generated by
a
+* command, that command has no effect. This is somewhat
+* unfortunate for multi-bind commands, because it would
require a
+* first pass to scan the entire
Re: [Mesa-dev] [PATCH v2 21/82] glsl: Don't do tree grafting on buffer variables
On 17/06/15 21:19, Jordan Justen wrote: On 2015-06-03 00:01:11, Iago Toral Quiroga wrote: Otherwise we can lose writes into the buffers backing the variables. --- src/glsl/opt_tree_grafting.cpp | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/glsl/opt_tree_grafting.cpp b/src/glsl/opt_tree_grafting.cpp index d47613c..7f2ee6c 100644 --- a/src/glsl/opt_tree_grafting.cpp +++ b/src/glsl/opt_tree_grafting.cpp @@ -359,10 +359,11 @@ tree_grafting_basic_block(ir_instruction *bb_first, if (!lhs_var) continue; - if (lhs_var-data.mode == ir_var_function_out || - lhs_var-data.mode == ir_var_function_inout || - lhs_var-data.mode == ir_var_shader_out) -continue; + if (lhs_var-data.mode == ir_var_function_out || + lhs_var-data.mode == ir_var_function_inout || + lhs_var-data.mode == ir_var_shader_out || + lhs_var-data.mode == ir_var_shader_storage) + continue; This indentation looks wrong. If fixed, Reviewed-by: Jordan Justen jordan.l.jus...@intel.com Actually the indentation is fine: it uses 3-spaces. The old code was mixing tabs and spaces. Thanks, Sam ir_variable_refcount_entry *entry = info-refs-get_variable_entry(lhs_var); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 22/82] glsl: Do not kill dead assignments to buffer variables or SSBO declarations.
On 17/06/15 21:24, Jordan Justen wrote:
On 2015-06-03 00:01:12, Iago Toral Quiroga wrote:
If we kill dead assignments we lose the buffer writes.
Also, we never kill UBO declarations even if they are never referenced
by the shader, they are always considered active. Although the spec
does not seem say this specifically for SSBOs, it is probably implied
since SSBOs are pretty much the same as UBOs, only that you can write
to them.
---
src/glsl/opt_dead_code.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index f45bf5d..1bb5f32 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -77,11 +77,13 @@ do_dead_code(exec_list *instructions, bool
uniform_locations_assigned)
if (entry-assign) {
/* Remove a single dead assignment to the variable we found.
- * Don't do so if it's a shader or function output, though.
+ * Don't do so if it's a shader or function output or a buffer
+ * variable though.
buffer = shader storage
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
OK, thanks.
Sam
*/
if (entry-var-data.mode != ir_var_function_out
entry-var-data.mode != ir_var_function_inout
- entry-var-data.mode != ir_var_shader_out) {
+ entry-var-data.mode != ir_var_shader_out
+ entry-var-data.mode != ir_var_shader_storage) {
entry-assign-remove();
progress = true;
@@ -99,7 +101,8 @@ do_dead_code(exec_list *instructions, bool
uniform_locations_assigned)
* stage. Also, once uniform locations have been assigned, the
* declaration cannot be deleted.
*/
- if (entry-var-data.mode == ir_var_uniform) {
+ if (entry-var-data.mode == ir_var_uniform ||
+ entry-var-data.mode == ir_var_shader_storage) {
if (uniform_locations_assigned || entry-var-constant_value)
continue;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Wed, Jun 17, 2015 at 12:02 PM, Rob Clark robdcl...@gmail.com wrote:
On Wed, Jun 17, 2015 at 2:27 PM, Connor Abbott cwabbo...@gmail.com wrote:
So, as is, this patch isn't quite correct. When I originally wrote
NIR, the idea was that the size of each instruction would be explicit
-- that is, each instruction has it's own size, and the size of
registers/SSA values was merely a hint to say by the way, you
actually need this many components based on all the things that use
this value/register. In other words, you could smash num_components
to 4 for everything, and it would still work. Then, we could just
shrink num_components on demand as we got rid of uses of things.
That's why we have functions like nir_tex_instr_src_size(),
nir_tex_instr_dest_size(), and nir_ssa_alu_instr_src_components() that
seem like they're doing the same thing that these functions -- in most
cases, you actually want those functions instead of these. Maybe we
were figuring out the register/value # of components a few times, and
perhaps some of times it was broken, but it seems like adding these
functions would only add to the confusion.
Now, in hindsight, it seems like that might not be the best idea. In
other words, I can see how it would make sense to turn
nir_tex_instr_src_size() etc. into assertions in the validator that
check that nir_(src|dest)_num_components() equals what you would
expect, and it's probably a good idea. But I don't want people to use
these functions without knowing what they're doing until we do that
cleanup.
hmm, fortunately I hadn't pushed my loops branch yet, since still need
to work out how to make variables/arrays work w/ 1 block (since in
nir-land variables are not ssa)..
(really I want phi's for variables too.. the way I turn arrays into
fanin/collect fanout/split works on the backend for dealing with
arrays in ssa form (other than making instruction graph large) but the
way I go from nir to ir3 currently assumes I get nir phi's everywhere
I need an ir3 phi)
Right... we explicitly decided not to support SSA form for arrays in
NIR, since it seemed like a pretty bad idea. SSA form assumes that
inserting copies for the things you're SSA-ifying is relatively
inexpensive, and both SSA-based register allocation and algorithms for
converting out of SSA make no guarantees about not inserting
potentially unnecessary copies. This is a good compromise for smaller
things, but not for your array of (say) 64 things where inserting an
extra copy is rather disastrous. You can do it if you want and shoot
yourself in the foot, but NIR isn't going to help you there -- we
won't write a to-SSA pass for something which doesn't make much sense
in the first place.
Anyways, maybe I'll just move the helpers into ir3 for now until the
is_packed stuff is purged..
is_packed? what does that have to do with it? I suspect that there
might be some places where you're using this function instead of the
others I mentioned, and you actually want to use the latter, although
I haven't seen the code so I can't be sure. But of course, there's
always the option of actually going and fixing it :)
BR,
-R
On Mon, Jun 8, 2015 at 12:45 PM, Rob Clark robdcl...@gmail.com wrote:
From: Rob Clark robcl...@freedesktop.org
I need something like this in a couple places. And didn't see anything
like it anywhere.
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
v2: Added similar helper for nir_src, and cleaned up a few places that
open coded this. There are a couple left (such as validate_alu_src())
but that handle is_packed differently so I thought it best to leave
them as-is.
src/glsl/nir/nir.h | 18 ++
src/glsl/nir/nir_from_ssa.c | 10 ++
src/glsl/nir/nir_validate.c | 4 +---
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 697d37e..06bbb0c 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -541,6 +541,24 @@ typedef struct {
#define nir_foreach_def_safe(reg, dest) \
list_for_each_entry_safe(nir_dest, dest, (reg)-defs, reg.def_link)
+static inline unsigned
+nir_dest_num_components(nir_dest *dest)
+{
+ if (dest-is_ssa)
+ return dest-ssa.num_components;
+ else
+ return dest-reg.reg-num_components;
+}
+
+static inline unsigned
+nir_src_num_components(nir_src *src)
+{
+ if (src-is_ssa)
+ return src-ssa-num_components;
+ else
+ return src-reg.reg-num_components;
+}
+
static inline nir_src
nir_src_for_ssa(nir_ssa_def *def)
{
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 67733e6..23c798d 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -553,10 +553,7 @@ emit_copy(nir_parallel_copy_instr *pcopy, nir_src src,
nir_src dest_src,
dest_src.reg.indirect == NULL
dest_src.reg.base_offset == 0);
- if (src.is_ssa)
-
[Mesa-dev] [PATCH 2/2] i965: Add and fix comments in brw_vue_map.c.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vue_map.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vue_map.c
b/src/mesa/drivers/dri/i965/brw_vue_map.c
index ff92bd2..7687578 100644
--- a/src/mesa/drivers/dri/i965/brw_vue_map.c
+++ b/src/mesa/drivers/dri/i965/brw_vue_map.c
@@ -24,6 +24,15 @@
/**
* @file brw_vue_map.c
*
+ * This file computes the VUE map for a (non-fragment) shader stage, which
+ * describes the layout of its output varyings. The VUE map is used to match
+ * outputs from one stage with the inputs of the next.
+ *
+ * Largely, varyings can be placed however we like - producers/consumers simply
+ * have to agree on the layout. However, there is also a VUE Header that
+ * prescribes a fixed-layout for items that interact with fixed function
+ * hardware, such as the clipper and rasterizer.
+ *
* Authors:
* Paul Berry stereotype...@gmail.com
* Chris Forbes chr...@ijw.co.nz
@@ -45,7 +54,7 @@ assign_vue_slot(struct brw_vue_map *vue_map, int varying)
}
/**
- * Compute the VUE map for vertex shader program.
+ * Compute the VUE map for a shader stage.
*/
void
brw_compute_vue_map(const struct brw_device_info *devinfo,
@@ -76,6 +85,9 @@ brw_compute_vue_map(const struct brw_device_info *devinfo,
/* VUE header: format depends on chip generation and whether clipping is
* enabled.
+*
+* See the Sandybridge PRM, Volume 2 Part 1, section 1.5.1 (page 30),
+* Vertex URB Entry (VUE) Formats which describes the VUE header layout.
*/
if (devinfo-gen 6) {
/* There are 8 dwords in VUE header pre-Ironlake:
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Split VUE map handling out of brw_vs.c into brw_vue_map.c.
This was originally only used by the vertex shader, but it's now used by
the geometry shader as well, and will also eventually be used for
tessellation control and evaluation shaders.
I suspect it will be easier to find in a file named after the concept.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_vs.c | 102 --
src/mesa/drivers/dri/i965/brw_vue_map.c| 136 +
3 files changed, 137 insertions(+), 102 deletions(-)
create mode 100644 src/mesa/drivers/dri/i965/brw_vue_map.c
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index 93f336e..981fe79 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -130,6 +130,7 @@ i965_FILES = \
brw_vs.h \
brw_vs_state.c \
brw_vs_surface_state.c \
+ brw_vue_map.c \
brw_wm.c \
brw_wm.h \
brw_wm_iz.cpp \
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index d03567e..6e9848f 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -40,108 +40,6 @@
#include util/ralloc.h
-static inline void assign_vue_slot(struct brw_vue_map *vue_map,
- int varying)
-{
- /* Make sure this varying hasn't been assigned a slot already */
- assert (vue_map-varying_to_slot[varying] == -1);
-
- vue_map-varying_to_slot[varying] = vue_map-num_slots;
- vue_map-slot_to_varying[vue_map-num_slots++] = varying;
-}
-
-/**
- * Compute the VUE map for vertex shader program.
- */
-void
-brw_compute_vue_map(const struct brw_device_info *devinfo,
-struct brw_vue_map *vue_map,
-GLbitfield64 slots_valid)
-{
- vue_map-slots_valid = slots_valid;
- int i;
-
- /* gl_Layer and gl_ViewportIndex don't get their own varying slots -- they
-* are stored in the first VUE slot (VARYING_SLOT_PSIZ).
-*/
- slots_valid = ~(VARYING_BIT_LAYER | VARYING_BIT_VIEWPORT);
-
- /* Make sure that the values we store in vue_map-varying_to_slot and
-* vue_map-slot_to_varying won't overflow the signed chars that are used
-* to store them. Note that since vue_map-slot_to_varying sometimes holds
-* values equal to BRW_VARYING_SLOT_COUNT, we need to ensure that
-* BRW_VARYING_SLOT_COUNT is = 127, not 128.
-*/
- STATIC_ASSERT(BRW_VARYING_SLOT_COUNT = 127);
-
- vue_map-num_slots = 0;
- for (i = 0; i BRW_VARYING_SLOT_COUNT; ++i) {
- vue_map-varying_to_slot[i] = -1;
- vue_map-slot_to_varying[i] = BRW_VARYING_SLOT_COUNT;
- }
-
- /* VUE header: format depends on chip generation and whether clipping is
-* enabled.
-*/
- if (devinfo-gen 6) {
- /* There are 8 dwords in VUE header pre-Ironlake:
- * dword 0-3 is indices, point width, clip flags.
- * dword 4-7 is ndc position
- * dword 8-11 is the first vertex data.
- *
- * On Ironlake the VUE header is nominally 20 dwords, but the hardware
- * will accept the same header layout as Gen4 [and should be a bit
faster]
- */
- assign_vue_slot(vue_map, VARYING_SLOT_PSIZ);
- assign_vue_slot(vue_map, BRW_VARYING_SLOT_NDC);
- assign_vue_slot(vue_map, VARYING_SLOT_POS);
- } else {
- /* There are 8 or 16 DWs (D0-D15) in VUE header on Sandybridge:
- * dword 0-3 of the header is indices, point width, clip flags.
- * dword 4-7 is the 4D space position
- * dword 8-15 of the vertex header is the user clip distance if
- * enabled.
- * dword 8-11 or 16-19 is the first vertex element data we fill.
- */
- assign_vue_slot(vue_map, VARYING_SLOT_PSIZ);
- assign_vue_slot(vue_map, VARYING_SLOT_POS);
- if (slots_valid BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST0))
- assign_vue_slot(vue_map, VARYING_SLOT_CLIP_DIST0);
- if (slots_valid BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST1))
- assign_vue_slot(vue_map, VARYING_SLOT_CLIP_DIST1);
-
- /* front and back colors need to be consecutive so that we can use
- * ATTRIBUTE_SWIZZLE_INPUTATTR_FACING to swizzle them when doing
- * two-sided color.
- */
- if (slots_valid BITFIELD64_BIT(VARYING_SLOT_COL0))
- assign_vue_slot(vue_map, VARYING_SLOT_COL0);
- if (slots_valid BITFIELD64_BIT(VARYING_SLOT_BFC0))
- assign_vue_slot(vue_map, VARYING_SLOT_BFC0);
- if (slots_valid BITFIELD64_BIT(VARYING_SLOT_COL1))
- assign_vue_slot(vue_map, VARYING_SLOT_COL1);
- if (slots_valid BITFIELD64_BIT(VARYING_SLOT_BFC1))
- assign_vue_slot(vue_map, VARYING_SLOT_BFC1);
- }
-
- /* The hardware doesn't care about the rest of the vertex outputs, so just
-* assign them contiguously. Don't reassign outputs that already have a
-* slot.
-*
-* We generally
[Mesa-dev] [PATCH 3/5] egl/dri2: load libglapi.0.dylib on osx
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90903 Signed-off-by: Julien Isorce j.iso...@samsung.com --- src/egl/drivers/dri2/egl_dri2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index a1cbd43..90b9648 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -2354,6 +2354,8 @@ dri2_load(_EGLDriver *drv) #ifdef HAVE_SHARED_GLAPI #ifdef HAVE_ANDROID_PLATFORM const char *libname = libglapi.so; +#elif defined(__APPLE__) + const char *libname = libglapi.0.dylib; #else const char *libname = libglapi.so.0; #endif -- 1.9.5 (Apple Git-50.3) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] applegl: Provide requirements of _SET_DrawBuffers
From: Jon TURNEY jon.tur...@dronecode.org.uk
_SET_DrawBuffers requires driDispatchRemapTable,
so we need to link with libmesa for remap.c.
libmesa requires the C++ linker.
Also need to arrange to call _mesa_init_remap_table()
to initialize the remap table.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90311
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
src/glx/Makefile.am | 5 -
src/glx/apple/apple_glapi.c | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 6e50e09..de24496 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -139,7 +139,10 @@ libglx_la_SOURCES += \
applegl_glx.c
SUBDIRS += apple
-libglx_la_LIBADD += $(builddir)/apple/libappleglx.la
+libglx_la_LIBADD += \
+ $(builddir)/apple/libappleglx.la \
+ $(top_builddir)/src/mesa/libmesa.la
+nodist_EXTRA_lib@GL_LIB@_la_SOURCES = dummy.cpp
endif
GL_LIBS = \
diff --git a/src/glx/apple/apple_glapi.c b/src/glx/apple/apple_glapi.c
index 4d19f7f..849044b 100644
--- a/src/glx/apple/apple_glapi.c
+++ b/src/glx/apple/apple_glapi.c
@@ -39,6 +39,7 @@
#include GL/gl.h
#include main/glheader.h
+#include main/remap.h
#include glapi.h
#include glapitable.h
#include main/dispatch.h
@@ -54,6 +55,8 @@ static void _apple_glapi_create_table(void) {
if (__applegl_api)
return;
+_mesa_init_remap_table();
+
__ogl_framework_api =
_glapi_create_table_from_handle(apple_cgl_get_dl_handle(), gl);
assert(__ogl_framework_api);
--
1.9.5 (Apple Git-50.3)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] osx: fix asm support on darwin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90908 Signed-off-by: Julien Isorce j.iso...@samsung.com --- configure.ac | 2 +- src/mesa/x86-64/xform4.S | 53 +--- src/mesa/x86/assyntax.h | 2 +- 3 files changed, 30 insertions(+), 27 deletions(-) diff --git a/configure.ac b/configure.ac index ae6d83d..6d699d5 100644 --- a/configure.ac +++ b/configure.ac @@ -615,7 +615,7 @@ if test x$enable_asm = xyes; then ;; x86_64|amd64) case $host_os in -linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | darwin*) asm_arch=x86_64 ;; esac diff --git a/src/mesa/x86-64/xform4.S b/src/mesa/x86-64/xform4.S index c185f62..17eb7fa 100644 --- a/src/mesa/x86-64/xform4.S +++ b/src/mesa/x86-64/xform4.S @@ -24,14 +24,15 @@ #ifdef USE_X86_64_ASM +#include x86/assyntax.h #include matypes.h .text .align 16 -.globl _mesa_x86_64_cpuid -.hidden _mesa_x86_64_cpuid -_mesa_x86_64_cpuid: +GLOBL GLNAME(_mesa_x86_64_cpuid) +HIDDEN(_mesa_x86_64_cpuid) +GLNAME(_mesa_x86_64_cpuid): pushq %rbx movl(%rdi), %eax movl8(%rdi), %ecx @@ -46,9 +47,9 @@ _mesa_x86_64_cpuid: ret .align 16 -.globl _mesa_x86_64_transform_points4_general -.hidden _mesa_x86_64_transform_points4_general -_mesa_x86_64_transform_points4_general: +GLOBL GLNAME(_mesa_x86_64_transform_points4_general) +HIDDEN(_mesa_x86_64_transform_points4_general) +GLNAME(_mesa_x86_64_transform_points4_general): /* * rdi = dest * rsi = matrix @@ -105,8 +106,10 @@ p4_general_loop: p4_general_done: .byte 0xf3 ret - + +#if defined (__ELF__) defined (__linux__) .section .rodata +#endif .align 16 p4_constants: @@ -122,13 +125,13 @@ p4_constants: .text .align 16 -.globl _mesa_x86_64_transform_points4_3d -.hidden _mesa_x86_64_transform_points4_3d +GLOBL GLNAME(_mesa_x86_64_transform_points4_3d) +HIDDEN(_mesa_x86_64_transform_points4_3d) /* * this is slower than _mesa_x86_64_transform_points4_general * because it ensures that the last matrix row (or is it column?) is 0,0,0,1 */ -_mesa_x86_64_transform_points4_3d: +GLNAME(_mesa_x86_64_transform_points4_3d): leaq p4_constants(%rip), %rax @@ -194,9 +197,9 @@ p4_3d_done: .align 16 -.globl _mesa_x86_64_transform_points4_identity -.hidden _mesa_x86_64_transform_points4_identity -_mesa_x86_64_transform_points4_identity: +GLOBL GLNAME(_mesa_x86_64_transform_points4_identity) +HIDDEN(_mesa_x86_64_transform_points4_identitiy) +GLNAME(_mesa_x86_64_transform_points4_identity): movl V4F_COUNT(%rdx), %ecx /* count */ movzbl V4F_STRIDE(%rdx), %eax /* stride */ @@ -223,9 +226,9 @@ p4_identity_done: .align 16 -.globl _mesa_3dnow_transform_points4_3d_no_rot -.hidden _mesa_3dnow_transform_points4_3d_no_rot -_mesa_3dnow_transform_points4_3d_no_rot: +GLOBL GLNAME(_mesa_3dnow_transform_points4_3d_no_rot) +HIDDEN(_mesa_3dnow_transform_points4_3d_no_rot) +GLNAME(_mesa_3dnow_transform_points4_3d_no_rot): movl V4F_COUNT(%rdx), %ecx /* count */ movzbl V4F_STRIDE(%rdx), %eax /* stride */ @@ -288,9 +291,9 @@ p4_3d_no_rot_done: .align 16 -.globl _mesa_3dnow_transform_points4_perspective -.hidden _mesa_3dnow_transform_points4_perspective -_mesa_3dnow_transform_points4_perspective: +GLOBL GLNAME(_mesa_3dnow_transform_points4_perspective) +HIDDEN(_mesa_3dnow_transform_points4_perspective) +GLNAME(_mesa_3dnow_transform_points4_perspective): movl V4F_COUNT(%rdx), %ecx /* count */ movzbl V4F_STRIDE(%rdx), %eax /* stride */ @@ -355,9 +358,9 @@ p4_perspective_done: ret .align 16 -.globl _mesa_3dnow_transform_points4_2d_no_rot -.hidden _mesa_3dnow_transform_points4_2d_no_rot -_mesa_3dnow_transform_points4_2d_no_rot: +GLOBL GLNAME(_mesa_3dnow_transform_points4_2d_no_rot) +HIDDEN(_mesa_3dnow_transform_points4_2d_no_rot) +GLNAME(_mesa_3dnow_transform_points4_2d_no_rot): movl V4F_COUNT(%rdx), %ecx /* count */ movzbl V4F_STRIDE(%rdx), %eax /* stride */ @@ -411,9 +414,9 @@ p4_2d_no_rot_done: .align 16 -.globl _mesa_3dnow_transform_points4_2d -.hidden _mesa_3dnow_transform_points4_2d -_mesa_3dnow_transform_points4_2d: +GLOBL GLNAME(_mesa_3dnow_transform_points4_2d) +HIDDEN(_mesa_3dnow_transform_points4_2d) +GLNAME(_mesa_3dnow_transform_points4_2d): movl V4F_COUNT(%rdx), %ecx /* count */ movzbl V4F_STRIDE(%rdx), %eax /* stride */ diff --git a/src/mesa/x86/assyntax.h b/src/mesa/x86/assyntax.h index 67867bd..8ba7e50 100644 --- a/src/mesa/x86/assyntax.h +++ b/src/mesa/x86/assyntax.h @@ -255,7 +255,7 @@ #endif /* ACK_ASSEMBLER */ -#if defined(__QNX__) || defined(Lynx) || (defined(SYSV) || defined(SVR4)) !defined(ACK_ASSEMBLER) || defined(__ELF__) || defined(__GNU__) || defined(__GNUC__)
[Mesa-dev] [PATCH 1/5] darwin: Suppress type conversion warnings for GLhandleARB
From: Jon TURNEY jon.tur...@dronecode.org.uk
On darwin, GLhandleARB is defined as a void *, not the unsigned int it is on
linux.
For the moment, apply a cast to supress the warning
Possibly this is safe, as for the mesa software renderer the shader program
handle is not a real pointer, but a integer handle
Probably this is not the right thing to do, and we should pay closer attention
to how the GLhandlerARB type is used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66346
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
src/mesa/main/shader_query.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index a6246a3..e3a1213 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -69,7 +69,7 @@ _mesa_BindAttribLocation(GLhandleARB program, GLuint index,
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *const shProg =
- _mesa_lookup_shader_program_err(ctx, program, glBindAttribLocation);
+ _mesa_lookup_shader_program_err(ctx, (uintptr_t)program,
glBindAttribLocation);
if (!shProg)
return;
@@ -137,7 +137,7 @@ _mesa_GetActiveAttrib(GLhandleARB program, GLuint
desired_index,
return;
}
- shProg = _mesa_lookup_shader_program_err(ctx, program, glGetActiveAttrib);
+ shProg = _mesa_lookup_shader_program_err(ctx, (uintptr_t)program,
glGetActiveAttrib);
if (!shProg)
return;
@@ -251,7 +251,7 @@ _mesa_GetAttribLocation(GLhandleARB program, const
GLcharARB * name)
{
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *const shProg =
- _mesa_lookup_shader_program_err(ctx, program, glGetAttribLocation);
+ _mesa_lookup_shader_program_err(ctx, (uintptr_t)program,
glGetAttribLocation);
if (!shProg) {
return -1;
--
1.9.5 (Apple Git-50.3)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] egl: use unix defines on osx with clang
CC egl_dri2.lo include/EGL/eglplatform.h:135:2: error: Platform not recognized include/EGL/eglplatform.h:140:9: error: unknown type name 'EGLNativeDisplayType' typedef EGLNativeDisplayType NativeDisplayType; Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90249 Signed-off-by: Julien Isorce j.iso...@samsung.com --- include/EGL/eglplatform.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h index 7802542..b376e64 100644 --- a/include/EGL/eglplatform.h +++ b/include/EGL/eglplatform.h @@ -77,7 +77,7 @@ typedef HDC EGLNativeDisplayType; typedef HBITMAP EGLNativePixmapType; typedef HWNDEGLNativeWindowType; -#elif defined(__APPLE__) || defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian */ +#elif defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian */ typedef int EGLNativeDisplayType; typedef void *EGLNativeWindowType; @@ -105,7 +105,7 @@ typedef struct ANativeWindow* EGLNativeWindowType; typedef struct egl_native_pixmap_t* EGLNativePixmapType; typedef void* EGLNativeDisplayType; -#elif defined(__unix__) +#elif defined(__unix__) || defined(__APPLE__) #if defined(MESA_EGL_NO_X11_HEADERS) -- 1.9.5 (Apple Git-50.3) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 23/82] glsl: Do not do CSE for expressions involving SSBO loads
On Wed, Jun 17, 2015 at 5:20 PM, Jordan Justen jordan.l.jus...@intel.com wrote: I wanted to question whether this was required, based on this text from the extension spec: The ability to write to buffer objects creates the potential for multiple independent shader invocations to read and write the same underlying memory. The same issue exists with the ARB_shader_image_load_store extension provided in OpenGL 4.2, which can write to texture objects and buffers. In both cases, the specification makes few guarantees related to the relative order of memory reads and writes performed by the shader invocations. But I'm not sure if we can reconcile CSE with 'memoryBarrier' and 'barrier'. curro, any thoughts from image load/store? I think the point is that if you have two reads of the same location, you can't combine them into a single load since in the intervening time another shader invocation might have written to that location...? The question about the semantics of memory-barriers is a good one though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add GL_PROGRAM_PIPELINE support in KHR_debug calls
This was apparently missed when KHR_debug or ARB_sso support was added.
Add label support to pipeline objects just like all the other
debug-related objects.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/mtypes.h | 2 ++
src/mesa/main/objectlabel.c | 10 --
src/mesa/main/pipelineobj.c | 21 +++--
src/mesa/main/pipelineobj.h | 3 +++
4 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ffa7f0c..983b9dc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2815,6 +2815,8 @@ struct gl_pipeline_object
mtx_t Mutex;
+ GLchar *Label; /** GL_KHR_debug */
+
/**
* Programs used for rendering
*
diff --git a/src/mesa/main/objectlabel.c b/src/mesa/main/objectlabel.c
index aecb5b1..5626054 100644
--- a/src/mesa/main/objectlabel.c
+++ b/src/mesa/main/objectlabel.c
@@ -30,6 +30,7 @@
#include enums.h
#include fbobject.h
#include objectlabel.h
+#include pipelineobj.h
#include queryobj.h
#include samplerobj.h
#include shaderobj.h
@@ -214,8 +215,13 @@ get_label_pointer(struct gl_context *ctx, GLenum
identifier, GLuint name,
}
break;
case GL_PROGRAM_PIPELINE:
- /* requires GL 4.2 */
- goto invalid_enum;
+ {
+ struct gl_pipeline_object *pipe =
+_mesa_lookup_pipeline_object(ctx, name);
+ if (pipe)
+labelPtr = pipe-Label;
+ }
+ break;
default:
goto invalid_enum;
}
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index b4795ff..279ae20 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -65,6 +65,7 @@ _mesa_delete_pipeline_object(struct gl_context *ctx,
_mesa_reference_shader_program(ctx, obj-ActiveProgram, NULL);
mtx_destroy(obj-Mutex);
+ free(obj-Label);
ralloc_free(obj);
}
@@ -136,8 +137,8 @@ _mesa_free_pipeline_data(struct gl_context *ctx)
* a non-existent ID. The spec defines ID 0 as being technically
* non-existent.
*/
-static inline struct gl_pipeline_object *
-lookup_pipeline_object(struct gl_context *ctx, GLuint id)
+struct gl_pipeline_object *
+_mesa_lookup_pipeline_object(struct gl_context *ctx, GLuint id)
{
if (id == 0)
return NULL;
@@ -225,7 +226,7 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield stages,
GLuint program)
{
GET_CURRENT_CONTEXT(ctx);
- struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+ struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx,
pipeline);
struct gl_shader_program *shProg = NULL;
GLbitfield any_valid_stages;
@@ -337,7 +338,7 @@ _mesa_ActiveShaderProgram(GLuint pipeline, GLuint program)
{
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *shProg = NULL;
- struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+ struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx,
pipeline);
if (program != 0) {
shProg = _mesa_lookup_shader_program_err(ctx, program,
@@ -399,7 +400,7 @@ _mesa_BindProgramPipeline(GLuint pipeline)
*/
if (pipeline) {
/* non-default pipeline object */
- newObj = lookup_pipeline_object(ctx, pipeline);
+ newObj = _mesa_lookup_pipeline_object(ctx, pipeline);
if (!newObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindProgramPipeline(non-gen name));
@@ -468,7 +469,7 @@ _mesa_DeleteProgramPipelines(GLsizei n, const GLuint
*pipelines)
for (i = 0; i n; i++) {
struct gl_pipeline_object *obj =
- lookup_pipeline_object(ctx, pipelines[i]);
+ _mesa_lookup_pipeline_object(ctx, pipelines[i]);
if (obj) {
assert(obj-Name == pipelines[i]);
@@ -568,7 +569,7 @@ _mesa_IsProgramPipeline(GLuint pipeline)
{
GET_CURRENT_CONTEXT(ctx);
- struct gl_pipeline_object *obj = lookup_pipeline_object(ctx, pipeline);
+ struct gl_pipeline_object *obj = _mesa_lookup_pipeline_object(ctx,
pipeline);
if (obj == NULL)
return GL_FALSE;
@@ -582,7 +583,7 @@ void GLAPIENTRY
_mesa_GetProgramPipelineiv(GLuint pipeline, GLenum pname, GLint *params)
{
GET_CURRENT_CONTEXT(ctx);
- struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+ struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx,
pipeline);
/* Are geometry shaders available in this context?
*/
@@ -841,7 +842,7 @@ _mesa_ValidateProgramPipeline(GLuint pipeline)
{
GET_CURRENT_CONTEXT(ctx);
- struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+ struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx,
pipeline);
if (!pipe) {
_mesa_error(ctx, GL_INVALID_OPERATION,
@@ -859,7 +860,7 @@ _mesa_GetProgramPipelineInfoLog(GLuint pipeline, GLsizei
bufSize,
{
GET_CURRENT_CONTEXT(ctx);
- struct gl_pipeline_object *pipe
Re: [Mesa-dev] [PATCH 03/14] mesa: Fix conditions to test signed, unsigned integer format
On Tue, Jun 16, 2015 at 9:16 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
Please note in the commit message exactly what is broken.
I didn't notice any piglit failure without this change. As requested I'll add
this in the commit message:
Just checking the type in glReadPixels() is not sufficient to decide if the
format is one of the integer formats. GL_INT, GL_SHORT or GL_BYTE types can
be used with both normalized fixed point formats and integer formats. So, add a
check to ensure the integer format.
On Jun 16, 2015 11:15, Anuj Phogat anuj.pho...@gmail.com wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/main/readpix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index caa2648..a9416ef 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -160,10 +160,12 @@ _mesa_readpixels_needs_slow_path(const struct
gl_context *ctx, GLenum format,
srcType = _mesa_get_format_datatype(rb-Format);
if ((srcType == GL_INT
+ _mesa_is_enum_format_integer(format)
(type == GL_UNSIGNED_INT ||
type == GL_UNSIGNED_SHORT ||
type == GL_UNSIGNED_BYTE)) ||
(srcType == GL_UNSIGNED_INT
+ _mesa_is_enum_format_integer(format)
(type == GL_INT ||
type == GL_SHORT ||
type == GL_BYTE))) {
--
1.9.3
___
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/4] CLOEXEC fix-ups
On Wed, Jun 17, 2015 at 9:28 AM, Derek Foreman der...@osg.samsung.com wrote: This series catches a couple of places where we forget to set CLOEXEC on file descriptors, and makes a helper function for the necessarily ugly way we have to open fds to make sure CLOEXEC is set. Derek Foreman (4): egl/drm: Duplicate fd with F_DUPFD_CLOEXEC to prevent leak loader: Rename drm_open_device() to loader_open_device() and share it glx: Use loader_open_device() helper egl: Use the loader_open_device() helper to do open with CLOEXEC Reviewed-by: Kristian Høgsberg k...@bitplanet.net src/egl/drivers/dri2/platform_drm.c | 6 +++--- src/egl/drivers/dri2/platform_surfaceless.c | 11 +-- src/egl/drivers/dri2/platform_wayland.c | 11 +-- src/egl/drivers/dri2/platform_x11.c | 12 ++-- src/glx/dri2_glx.c | 10 +- src/loader/loader.c | 6 +++--- src/loader/loader.h | 3 +++ 7 files changed, 14 insertions(+), 45 deletions(-) -- 2.1.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] [PATCH v2 23/82] glsl: Do not do CSE for expressions involving SSBO loads
On 2015-06-17 19:33:23, Matt Turner wrote: On Wed, Jun 17, 2015 at 5:20 PM, Jordan Justen jordan.l.jus...@intel.com wrote: I wanted to question whether this was required, based on this text from the extension spec: The ability to write to buffer objects creates the potential for multiple independent shader invocations to read and write the same underlying memory. The same issue exists with the ARB_shader_image_load_store extension provided in OpenGL 4.2, which can write to texture objects and buffers. In both cases, the specification makes few guarantees related to the relative order of memory reads and writes performed by the shader invocations. But I'm not sure if we can reconcile CSE with 'memoryBarrier' and 'barrier'. curro, any thoughts from image load/store? I think the point is that if you have two reads of the same location, you can't combine them into a single load since in the intervening time another shader invocation might have written to that location...? I don't think the spec requires you to have gotten the newly written value in that case. So, it might be okay to just read it once. In both cases, the specification makes few guarantees related to the relative order of memory reads and writes performed by the shader invocations. The question about the semantics of memory-barriers is a good one though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 23/82] glsl: Do not do CSE for expressions involving SSBO loads
On Wed, 2015-06-17 at 17:20 -0700, Jordan Justen wrote:
I wanted to question whether this was required, based on this text
from the extension spec:
The ability to write to buffer objects creates the potential for
multiple independent shader invocations to read and write the same
underlying memory. The same issue exists with the
ARB_shader_image_load_store extension provided in OpenGL 4.2, which
can write to texture objects and buffers. In both cases, the
specification makes few guarantees related to the relative order of
memory reads and writes performed by the shader invocations.
But I'm not sure if we can reconcile CSE with 'memoryBarrier' and
'barrier'. curro, any thoughts from image load/store?
I think the problem is within the same thread, that text above talks
about multiple invocations reading from and writing to the same
location, but within the same invocation, the order of reads and writes
must be preserved:
Buffer variable memory reads and writes within a single shader
invocation are processed in order. However, the order of reads and
writes performed in one invocation relative to those performed by
another invocation is largely undefined.
For example, if X is a shader storage buffer variable and we have code
like this with just one invocation:
ssbo_store(X, 1);
a = ssbo_load(X) + 1 // a = 2
ssbo_store(X, 2);
b = ssbo_load(X) + 1; // b = 3
CSE could mess it up like this:
ssbo_store(X, 1);
tmp = ssbo_load(X) + 1 // tmp = 2
a = tmp;
ssbo_store(X, 2);
b = tmp;
which would be incorrect. I think I wrote this patch after seeing
something like this happening. The CSE pass clearly states that it does
not support write variables after all.
Also, notice the same would apply if there are multiple invocations but
the shader code used something like gl_VertexID or gl_FragCoord to make
each invocation read from/write to a different address within the SSBO
buffer (I imagine this is the usual way to operate with SSBOs). In these
cases, even if we have multiple invocations, keeping the relative order
of reads and writes within each one is necessary.
Iago
-Jordan
On 2015-06-03 00:01:13, Iago Toral Quiroga wrote:
SSBOs are read/write and this CSE pass only handles read-only variables.
---
src/glsl/opt_cse.cpp | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/src/glsl/opt_cse.cpp b/src/glsl/opt_cse.cpp
index 4b8e9a0..a05ab46 100644
--- a/src/glsl/opt_cse.cpp
+++ b/src/glsl/opt_cse.cpp
@@ -245,6 +245,28 @@ contains_rvalue(ir_rvalue *haystack, ir_rvalue *needle)
}
static bool
+expression_contains_ssbo_load(ir_expression *expr)
+{
+ if (expr-operation == ir_binop_ssbo_load)
+ return true;
+
+ for (unsigned i = 0; i expr-get_num_operands(); i++) {
+ ir_rvalue *op = expr-operands[i];
+ if (op-ir_type == ir_type_expression
+ expression_contains_ssbo_load(op-as_expression())) {
+ return true;
+ } else if (op-ir_type == ir_type_swizzle) {
+ ir_swizzle *swizzle = op-as_swizzle();
+ ir_expression *val = swizzle-val-as_expression();
+ if (val expression_contains_ssbo_load(val))
+return true;
+ }
+ }
+
+ return false;
+}
+
+static bool
is_cse_candidate(ir_rvalue *ir)
{
/* Our temporary variable assignment generation isn't ready to handle
@@ -260,7 +282,16 @@ is_cse_candidate(ir_rvalue *ir)
* to variable-index array dereferences at some point.
*/
switch (ir-ir_type) {
- case ir_type_expression:
+ case ir_type_expression: {
+ /* Skip expressions involving SSBO loads, since these operate on
+ * read-write variables, meaning that the same ssbo_load
expression
+ * may return a different value if the underlying buffer storage
+ * is written in between.
+ */
+ if (expression_contains_ssbo_load(ir-as_expression()))
+return false;
+ }
+ break;
case ir_type_texture:
break;
default:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHES] Tessellation is here
Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2 + src/glsl/ir.h | 1 + src/glsl/ir_optimization.h| 8 +- src/glsl/ir_print_visitor.cpp | 5 +-
Re: [Mesa-dev] [PATCHES] Tessellation is here
Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2 + src/glsl/ir.h | 1 + src/glsl/ir_optimization.h| 8 +- src/glsl/ir_print_visitor.cpp | 5 +- src/glsl/ir_reader.cpp| 2 + src/glsl/ir_set_program_inouts.cpp| 96 ++- src/glsl/link_interface_blocks.cpp|
Re: [Mesa-dev] [PATCHES] Tessellation is here
I only guess, that TESS is too much for the software rasterization, so they may very well fake it. On Wed, Jun 17, 2015 at 3:21 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2 + src/glsl/ir.h
Re: [Mesa-dev] [PATCHES] Tessellation is here
Only the RadeonSI driver supports it right now. Marek On Wed, Jun 17, 2015 at 2:21 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2 + src/glsl/ir.h | 1 +
Re: [Mesa-dev] [PATCH] mesa: store full array type in gl_uniform_storage
I've created a new piglit test to confirm this fixes a bug in
_mesa_sampler_uniforms_pipeline_are_valid()
http://lists.freedesktop.org/archives/piglit/2015-June/016270.html
I'll update the commit message to:
Previously only the type of a single array element was stored.
_mesa_sampler_uniforms_pipeline_are_valid() was expecting to get the
array type so this fixes a bug with validating arrays of samplers in
SSO.
This change will also useful for implementing arrays of arrays support
in glGetUniformLocation().
I guess this could also be a stable candidate.
On Mon, 2015-06-08 at 18:58 +1000, Timothy Arceri wrote:
Previously only the type of a single array element
was stored.
_mesa_sampler_uniforms_pipeline_are_valid() was expecting to get the array
type so this probably fixes a bug there.
However the main reason for doing this is to use the array type for
implementing arrays of arrays in glGetUniformLocation() in an upcoming
patch series.
---
src/glsl/ir_uniform.h | 5 +-
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 3 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 5 +-
src/mesa/main/shader_query.cpp | 2 +-
src/mesa/main/uniform_query.cpp| 64
++
src/mesa/program/ir_to_mesa.cpp| 7 +--
6 files changed, 46 insertions(+), 40 deletions(-)
diff --git a/src/glsl/ir_uniform.h b/src/glsl/ir_uniform.h
index e1b8014..07dd3c3 100644
--- a/src/glsl/ir_uniform.h
+++ b/src/glsl/ir_uniform.h
@@ -91,9 +91,8 @@ struct gl_opaque_uniform_index {
struct gl_uniform_storage {
char *name;
- /** Type of this uniform data stored.
-*
-* In the case of an array, it's the type of a single array element.
+ /**
+* Type of this uniform
*/
const struct glsl_type *type;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 5d3501c..6b669c2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -220,6 +220,7 @@ fs_visitor::nir_setup_uniform(nir_variable *var)
unsigned index = var-data.driver_location;
for (unsigned u = 0; u shader_prog-NumUniformStorage; u++) {
struct gl_uniform_storage *storage = shader_prog-UniformStorage[u];
+ const glsl_type *type = storage-type-without_array();
if (storage-builtin)
continue;
@@ -231,7 +232,7 @@ fs_visitor::nir_setup_uniform(nir_variable *var)
continue;
}
- unsigned slots = storage-type-component_slots();
+ unsigned slots = type-component_slots();
if (storage-array_elements)
slots *= storage-array_elements;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 242d007..e5874ca 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -685,6 +685,7 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
*/
for (unsigned u = 0; u shader_prog-NumUniformStorage; u++) {
struct gl_uniform_storage *storage = shader_prog-UniformStorage[u];
+ const glsl_type *type = storage-type-without_array();
if (storage-builtin)
continue;
@@ -698,11 +699,11 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
gl_constant_value *components = storage-storage;
unsigned vector_count = (MAX2(storage-array_elements, 1) *
- storage-type-matrix_columns);
+ type-matrix_columns);
for (unsigned s = 0; s vector_count; s++) {
assert(uniforms uniform_array_size);
- uniform_vector_size[uniforms] = storage-type-vector_elements;
+ uniform_vector_size[uniforms] = type-vector_elements;
int i;
for (i = 0; i uniform_vector_size[uniforms]; i++) {
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index a6246a3..807a95c 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -953,7 +953,7 @@ _mesa_program_resource_prop(struct gl_shader_program
*shProg,
case GL_TYPE:
switch (res-Type) {
case GL_UNIFORM:
- *val = RESOURCE_UNI(res)-type-gl_type;
+ *val = RESOURCE_UNI(res)-type-without_array()-gl_type;
return 1;
case GL_PROGRAM_INPUT:
case GL_PROGRAM_OUTPUT:
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index cab5083..c8b0b58 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -320,9 +320,10 @@ _mesa_get_uniform(struct gl_context *ctx, GLuint
program, GLint location,
return;
}
+ const glsl_type *uni_type = uni-type-without_array();
{
- unsigned elements = (uni-type-is_sampler())
- ? 1 :
Re: [Mesa-dev] [PATCH 2/9] i965: Fix textureGrad with cube samplers
On Tue, Feb 24, 2015 at 07:02:50PM +0100, Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
We can't use sampler messages with gradient information (like
sample_g or sample_d) to deal with this scenario because according
to the PRM:
The r coordinate and its gradients are required only for surface
types that use the third coordinate. Usage of this message type on
cube surfaces assumes that the u, v, and gradients have already been
transformed onto the appropriate face, but still in [-1,+1] range.
The r coordinate contains the faceid, and the r gradients are ignored
by hardware.
Instead, we should lower this to compute the LOD manually based on the
gradients and use a different sample message that takes the computed
LOD instead of the gradients. This is already being done in
brw_lower_texture_gradients.cpp, but it is restricted to shadow
samplers only, although there is a comment stating that we should
probably do this also for samplerCube and samplerCubeArray.
Because of this, both dEQP and Piglit test cases for textureGrad with
cube maps currently fail.
This patch does two things:
1) Activates the texturegrad lowering pass for all cube samplers.
2) Corrects the computation of the LOD value for cube samplers.
I had to do 2) because for cube maps the calculations implemented
in the lowering pass always compute a value of rho that is twice
the value we want (so we get a LOD value one unit larger than we
want). This only happens for cube map samplers (all kinds). I am
not sure about why we need to do this, but I suspect that it is
related to the fact that cube map coordinates, when transported
to a specific face in the cube, are in the range [-1, 1] instead of
[0, 1] so we probably need to divide the derivatives by 2 when
we compute the LOD. Doing that would produce the same result as
dividing the final rho computation by 2 (or removing a unit
from the computed LOD, which is what we are doing here).
Fixes the following piglit tests:
bin/tex-miplevel-selection textureGrad Cube -auto -fbo
bin/tex-miplevel-selection textureGrad CubeArray -auto -fbo
bin/tex-miplevel-selection textureGrad CubeShadow -auto -fbo
Fixes 10 dEQP tests in the following category:
dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*cube*
What$ happened to this patch? It seems like we still need/want it, and it seemed
like people had been looking at it. Was it just missing a formal review?
---
.../dri/i965/brw_lower_texture_gradients.cpp | 26
+++---
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
b/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
index 9679d28..878a54e 100644
--- a/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
+++ b/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
@@ -89,19 +89,18 @@ txs_type(const glsl_type *type)
ir_visitor_status
lower_texture_grad_visitor::visit_leave(ir_texture *ir)
{
- /* Only lower textureGrad with shadow samplers */
- if (ir-op != ir_txd || !ir-shadow_comparitor)
+ /* Only lower textureGrad with cube maps or shadow samplers */
+ if (ir-op != ir_txd ||
+ (ir-sampler-type-sampler_dimensionality != GLSL_SAMPLER_DIM_CUBE
+ !ir-shadow_comparitor))
return visit_continue;
Do you need this for GLSL_SAMPLER_DIM_3D? It seems to fit with the PRM blurb
about use the third coordinate
- /* Lower textureGrad() with samplerCubeShadow even if we have the
sample_d_c
+ /* Lower textureGrad() with samplerCube* even if we have the sample_d_c
* message. GLSL provides gradients for the 'r' coordinate.
Unfortunately:
*
* From the Ivybridge PRM, Volume 4, Part 1, sample_d message description:
* The r coordinate contains the faceid, and the r gradients are ignored
* by hardware.
-*
-* We likely need to do a similar treatment for samplerCube and
-* samplerCubeArray, but we have insufficient testing for that at the
moment.
*/
bool need_lowering = !has_sample_d_c ||
ir-sampler-type-sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE;
@@ -153,9 +152,20 @@ lower_texture_grad_visitor::visit_leave(ir_texture *ir)
expr(ir_unop_sqrt, dot(dPdy, dPdy)));
}
- /* lambda_base = log2(rho). We're ignoring GL state biases for now. */
+ /* lambda_base = log2(rho). We're ignoring GL state biases for now.
+*
+* For cube maps the result of these formulas is giving us a value of rho
+* that is twice the value we should use, so divide it by 2 or,
+* alternatively, remove one unit from the result of the log2 computation.
+*/
ir-op = ir_txl;
- ir-lod_info.lod = expr(ir_unop_log2, rho);
+ if (ir-sampler-type-sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE) {
+ ir-lod_info.lod = expr(ir_binop_add,
+
Re: [Mesa-dev] [PATCH] i965/skl: Fix aligning mt-total_width to the block size
On Tue, Jun 16, 2015 at 01:53:40PM +0100, Neil Roberts wrote:
brw_miptree_layout_2d tries to ensure that mt-total_width is a
multiple of the compressed block size, presumably because it wouldn't
be possible to make an image that has a fraction of a block. However
it was doing this by aligning mt-total_width to align_w. Previously
align_w has been used as a shortcut for getting the block width
because before Gen9 the block width was always equal to the alignment.
Commit 4ab8d59a2 tried to fix these cases to use the block width
instead of the alignment but it missed this case.
I think in practice this probably won't make any difference because
the buffer for the texture will be allocated to be large enough to
contain the entire pitch and libdrm aligns the pitch to the tile width
anyway. However I think the patch is worth having to make the
intention clearer.
I think this is beginning to infringe upon the definition of align_w. The total
width is a function of it's miptree properties and not the compressed block
properties, right?
In other words, if there is a case where align_w != bw, I think total_width
should be aligned to align_w, NOT bw.
(I'm not opposed to the patch, just making sure I understand.)
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 1e7d8a1..dbb6cef 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -366,9 +366,8 @@ brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
mt-total_width = mt-physical_width0;
- if (mt-compressed) {
- mt-total_width = ALIGN(mt-physical_width0, mt-align_w);
- }
+ if (mt-compressed)
+ mt-total_width = ALIGN(mt-total_width, bw);
/* May need to adjust width to accommodate the placement of
* the 2nd mipmap. This occurs when the alignment
--
1.9.3
___
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 2/9] i965: Fix textureGrad with cube samplers
On Tue, 2015-06-16 at 23:52 -0700, Ben Widawsky wrote:
On Tue, Feb 24, 2015 at 07:02:50PM +0100, Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
We can't use sampler messages with gradient information (like
sample_g or sample_d) to deal with this scenario because according
to the PRM:
The r coordinate and its gradients are required only for surface
types that use the third coordinate. Usage of this message type on
cube surfaces assumes that the u, v, and gradients have already been
transformed onto the appropriate face, but still in [-1,+1] range.
The r coordinate contains the faceid, and the r gradients are ignored
by hardware.
Instead, we should lower this to compute the LOD manually based on the
gradients and use a different sample message that takes the computed
LOD instead of the gradients. This is already being done in
brw_lower_texture_gradients.cpp, but it is restricted to shadow
samplers only, although there is a comment stating that we should
probably do this also for samplerCube and samplerCubeArray.
Because of this, both dEQP and Piglit test cases for textureGrad with
cube maps currently fail.
This patch does two things:
1) Activates the texturegrad lowering pass for all cube samplers.
2) Corrects the computation of the LOD value for cube samplers.
I had to do 2) because for cube maps the calculations implemented
in the lowering pass always compute a value of rho that is twice
the value we want (so we get a LOD value one unit larger than we
want). This only happens for cube map samplers (all kinds). I am
not sure about why we need to do this, but I suspect that it is
related to the fact that cube map coordinates, when transported
to a specific face in the cube, are in the range [-1, 1] instead of
[0, 1] so we probably need to divide the derivatives by 2 when
we compute the LOD. Doing that would produce the same result as
dividing the final rho computation by 2 (or removing a unit
from the computed LOD, which is what we are doing here).
Fixes the following piglit tests:
bin/tex-miplevel-selection textureGrad Cube -auto -fbo
bin/tex-miplevel-selection textureGrad CubeArray -auto -fbo
bin/tex-miplevel-selection textureGrad CubeShadow -auto -fbo
Fixes 10 dEQP tests in the following category:
dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*cube*
What$ happened to this patch? It seems like we still need/want it, and it
seemed
like people had been looking at it. Was it just missing a formal review?
---
.../dri/i965/brw_lower_texture_gradients.cpp | 26
+++---
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
b/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
index 9679d28..878a54e 100644
--- a/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
+++ b/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
@@ -89,19 +89,18 @@ txs_type(const glsl_type *type)
ir_visitor_status
lower_texture_grad_visitor::visit_leave(ir_texture *ir)
{
- /* Only lower textureGrad with shadow samplers */
- if (ir-op != ir_txd || !ir-shadow_comparitor)
+ /* Only lower textureGrad with cube maps or shadow samplers */
+ if (ir-op != ir_txd ||
+ (ir-sampler-type-sampler_dimensionality != GLSL_SAMPLER_DIM_CUBE
+ !ir-shadow_comparitor))
return visit_continue;
Do you need this for GLSL_SAMPLER_DIM_3D? It seems to fit with the PRM blurb
about use the third coordinate
I did not identify the need to do this for that kind, at least I did not
find any tests that failed in either deqp or piglit.
- /* Lower textureGrad() with samplerCubeShadow even if we have the
sample_d_c
+ /* Lower textureGrad() with samplerCube* even if we have the sample_d_c
* message. GLSL provides gradients for the 'r' coordinate.
Unfortunately:
*
* From the Ivybridge PRM, Volume 4, Part 1, sample_d message
description:
* The r coordinate contains the faceid, and the r gradients are
ignored
* by hardware.
-*
-* We likely need to do a similar treatment for samplerCube and
-* samplerCubeArray, but we have insufficient testing for that at the
moment.
*/
bool need_lowering = !has_sample_d_c ||
ir-sampler-type-sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE;
@@ -153,9 +152,20 @@ lower_texture_grad_visitor::visit_leave(ir_texture *ir)
expr(ir_unop_sqrt, dot(dPdy, dPdy)));
}
- /* lambda_base = log2(rho). We're ignoring GL state biases for now. */
+ /* lambda_base = log2(rho). We're ignoring GL state biases for now.
+*
+* For cube maps the result of these formulas is giving us a value of
rho
+* that is twice the value we should use, so divide it by 2 or,
+*
[Mesa-dev] [Bug 89818] WebGL Conformance conformance/textures/texture-size-limit.html - OUT_OF_MEMORY
https://bugs.freedesktop.org/show_bug.cgi?id=89818 Luke lukebe...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from Luke lukebe...@hotmail.com --- Roland, Yes, chromium's sandbox can be a hassle if it gets misconfigured. When I was running daily builds, I configured it (also can be disabled) with this: https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment I'm currently using Chrome, which installs with a working/preconfigured sandbox. It still gives the InitializeSandbox() called with multiple threads in process gpu-process warning but still works. llvmpipe is working with both webgl demos and the webgl conformance tests. Thanks for investigating this issue. I'll close it as NOTABUG. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/27] gallium/radeon: expose LLVM functions implementing emit_store
This series is Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Actually enable L3 caching for everything on CHV
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like CHV MOCS behaves a bit differently than BDW MOCS. On BDW the
target cache bits can be used to enable L3 caching regardless if how the
other bits are set up to select the UC/WT/WB caching mode for LLC/eLLC.
On CHV however it appears that the other bits control the caching mode
for the specified target cache, which is obviously just L3. So, to
actually enable L3 caching we need to specify L3+WB instead of L3+UC
in the MOCS.
Also note that there is no CPU cache snoop control in MOCS on CHV
like there was on VLV.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_defines.h | 6 ++
src/mesa/drivers/dri/i965/brw_device_info.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 3cf778b..2ec7f39 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2493,6 +2493,12 @@ enum brw_wm_barycentric_interp_mode {
#define BDW_MOCS_WT 0x58
#define BDW_MOCS_PTE 0x18
+/* Cherryview: always use L3 caching. Apparently we have to
+ * say L3+WB instead of L3+UC to actually get L3 caching.
+ * CPU cache snooping is specifid in the PTE only.
+ */
+#define CHV_MOCS_L30x78
+
/* Skylake: MOCS is now an index into an array of 64 different configurable
* cache settings. We still use only either write-back or write-through; and
* rely on the documented default values.
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c
b/src/mesa/drivers/dri/i965/brw_device_info.c
index edcfbd4..4e10c2c 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -292,6 +292,8 @@ static const struct brw_device_info brw_device_info_chv = {
.max_gs_threads = 80,
.max_wm_threads = 128,
.max_cs_threads = 28,
+ .mocs_pte = CHV_MOCS_L3,
+ .mocs_wb = CHV_MOCS_L3,
.urb = {
.size = 192,
.min_vs_entries = 34,
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/46] mesa: require VS if TCS or TES is present in pipeline
Sure. Marek On Wed, Jun 17, 2015 at 2:54 AM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-06-16 17:02:57, Marek Olšák wrote: On Wed, Jun 17, 2015 at 1:46 AM, Jordan Justen jordan.l.jus...@intel.com wrote: This patch was in a range of 11 patches that I added my r-b for: http://lists.freedesktop.org/archives/mesa-dev/2014-September/068742.html It seems Chris didn't get a chance to add my r-b to these patches, including the recently already committed 358b6bb. Sorry for not including your Rb. I did read all the comments on this mailing list and also github (I think it was tess-i965-4) and incorporated them into the series, but when you have a ton of comments and possibly incomplete 130 patches in your branch, the last thing you think of is adding Rb's. It is understandable to miss feedback from last September. Especially if it was directed to someone else... Anyway, can I get my r-b on the remaining 10 patches, assuming they are still alive? Thanks, -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: Unmap GPU VM address range when destroying BO
On 17.06.2015 04:54, Michel Dänzer wrote: On 16.06.2015 20:39, Christian König wrote: On 16.06.2015 10:56, Michel Dänzer wrote: On 16.06.2015 17:34, Christian König wrote: What we would need to really clean that up is to make the VM mappings per GEM handle like you suggested or allow multiple mappings per BO like we did it for Amdgpu. What kind of time-frame / effort do you think it would take to get that? Doing it like Amdgpu is actually trivial to implement, we would just need to port the implementation back from Amdgpu. But the problem is that it would break the userspace ABI and some older mesa version wouldn't work any more because of this cause they couldn't detect any more that it's the same BO. Doing the mapping per GEM handle might be an idea worth looking into, but I'm not sure how to approach that. Allowing multiple mappings per BO but not tracking them per GEM handle wouldn't solve the problem without this Mesa patch anyway, because the kernel would remember all mappings until the BO is destroyed, right? I think that might also indeed break older Mesa. However, I think it should be safe to allow multiple mappings if they are tracked per GEM handle. That should avoid this kind of problem even with old Mesa without this patch. Not sure that's worth the effort though. Another alternative is to teach radeon_bomgr_free_va that a certain address range could be allocated to more than one handle. What exactly do you have in mind for that? I don't think the winsys has several representations of the same BO in the cases fixed by this patch, and I'm not sure how it could account for external references. Ah, right the BO could still be open by somebody else outside of mesa. Since the code now looks up the BOs by VA we indeed shouldn't have any problems any more and your proposed solution should work fine. Does that mean I get your Reviewed-by: or at least Acked-by: tag? :) Yes, patches are Reviewed-by: Christian König christian.koe...@amd.com A better solution for detecting if it's save to unmap the BO would be nice, but I don't see one of hand either. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: House MOCS settings in brw_context/brw_device_info
From: Ville Syrjälä ville.syrj...@linux.intel.com
The layout of the MOCS bits has kept changing for each new
platform. Instead of adding platform checks all over the
place just store the MOCS settings in the device info
and context.
Currently MOCS is only ever set up in two ways: either
let the PTE choose the LLC/eLLC caching mode, or override
it to WB. L3 caching is enabled in both cases. That means
at most two different MOCS settings are required per
platform: PTE and WB.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_defines.h | 2 ++
src/mesa/drivers/dri/i965/brw_device_info.c | 12 ++--
src/mesa/drivers/dri/i965/brw_device_info.h | 3 +++
src/mesa/drivers/dri/i965/brw_draw_upload.c | 2 +-
src/mesa/drivers/dri/i965/brw_misc_state.c| 6 ++
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 8 +++-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 6 +++---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 +++
src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 7 +++
src/mesa/drivers/dri/i965/gen8_depth_state.c | 8 +++-
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 8 +++-
src/mesa/drivers/dri/i965/gen8_misc_state.c | 13 ++---
src/mesa/drivers/dri/i965/gen8_sol_state.c| 3 +--
src/mesa/drivers/dri/i965/gen8_surface_state.c| 10 +++---
17 files changed, 52 insertions(+), 50 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index f39b350..144142e 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -756,6 +756,9 @@ brwCreateContext(gl_api api,
brw-needs_unlit_centroid_workaround =
devinfo-needs_unlit_centroid_workaround;
+ brw-mocs_pte = devinfo-mocs_pte;
+ brw-mocs_wb = devinfo-mocs_wb;
+
brw-must_use_separate_stencil = screen-hw_must_use_separate_stencil;
brw-has_swizzling = screen-hw_has_swizzling;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 58119ee..b3d9bf9 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1148,6 +1148,8 @@ struct brw_context
*/
bool needs_unlit_centroid_workaround;
+ uint8_t mocs_pte, mocs_wb;
+
GLuint NewGLState;
struct {
struct brw_state_flags pipelines[BRW_NUM_PIPELINES];
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index bfcc442..3cf778b 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -29,6 +29,8 @@
* Keith Whitwell kei...@vmware.com
*/
+#include util/macros.h
+
#define INTEL_MASK(high, low) (((1((high)-(low)+1))-1)(low))
/* Using the GNU statement expression extension */
#define SET_FIELD(value, field) \
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c
b/src/mesa/drivers/dri/i965/brw_device_info.c
index 97243a4..edcfbd4 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -23,6 +23,7 @@
#include stdio.h
#include stdlib.h
+#include brw_defines.h
#include brw_device_info.h
static const struct brw_device_info brw_device_info_i965 = {
@@ -107,7 +108,9 @@ static const struct brw_device_info brw_device_info_snb_gt2
= {
.must_use_separate_stencil = true, \
.has_llc = true, \
.has_pln = true, \
- .has_surface_tile_offset = true
+ .has_surface_tile_offset = true, \
+ .mocs_pte = GEN7_MOCS_L3,\
+ .mocs_wb = GEN7_MOCS_L3
static const struct brw_device_info brw_device_info_ivb_gt1 = {
GEN7_FEATURES, .is_ivybridge = true, .gt = 1,
@@ -237,7 +240,9 @@ static const struct brw_device_info brw_device_info_hsw_gt3
= {
.max_hs_threads = 504, \
.max_ds_threads = 504, \
.max_gs_threads = 504, \
- .max_wm_threads = 384
+ .max_wm_threads = 384, \
+ .mocs_pte = BDW_MOCS_PTE,\
+ .mocs_wb = BDW_MOCS_WB
static const struct brw_device_info brw_device_info_bdw_gt1 = {
GEN8_FEATURES, .gt = 1,
@@ -298,6 +303,7 @@ static const struct brw_device_info brw_device_info_chv = {
};
/* Thread counts and URB limits are placeholders, and may not be accurate. */
+/* FINISHME: Use PTE MOCS on Skylake. */
#define GEN9_FEATURES \
.gen = 9,\
.has_hiz_and_separate_stencil = true,\
@@
Re: [Mesa-dev] [PATCHES] Tessellation is here
No. And as far as I know noone is working on it for llvmpipe. If I'd write a to do list for llvmpipe, that would probably be on page 50 or so :-). But patches always welcome... Roland Am 17.06.2015 um 14:21 schrieb Ilyes Gouta: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com mailto:drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 +
Re: [Mesa-dev] [PATCHES] Tessellation is here
Hi, On Wed, Jun 17, 2015 at 1:51 PM, Roland Scheidegger srol...@vmware.com wrote: No. And as far as I know noone is working on it for llvmpipe. If I'd write a to do list for llvmpipe, that would probably be on page 50 or so :-). But patches always welcome... Well, is such a to-do list for LLVMpipe online? I'm quite interested :) Ilyes Roland Am 17.06.2015 um 14:21 schrieb Ilyes Gouta: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com mailto:drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 +
Re: [Mesa-dev] [PATCHES] Tessellation is here
No, there is no such list. On that list would be: - implement multisampling (basic GL 3.0 feature, we cheat our way out of it...) - related to multisampling, rewrite attribute interpolation. This has problems nowadays even without msaa (particularly precision loss if a tri is far away from screen origin, since interpolation is always done wrt to screen origin), nowadays all real gpus do barycentric interpolation, there's also problems with a tri A,B,C not getting the exact same interpolated values compared to a tri B,C,A with the same vertices) - control flow. Right now we don't support any real control flow, just mask off the non-active values when writing the register values back. All branches in a shader are always evaluated, regardless if any elements in the execution mask are active. This means even for uniform control flow we always execute the dead branches. - avx2 support (use gather for texturing etc., extend intrinsics to avx2). This is definitely an easier task than the others... Things like tesselation would go in a bucket together with other GL4 stuff, a key problem with GL4 would be the dynamic indexing of samplers (the sample code bakes in the texture format, and with dynamic indexing this isn't known at compile time as it can differ for each texture bound), but everything GL4 is not even really on a to do list... Feel free to work on it though... Roland Am 17.06.2015 um 15:00 schrieb Ilyes Gouta: Hi, On Wed, Jun 17, 2015 at 1:51 PM, Roland Scheidegger srol...@vmware.com mailto:srol...@vmware.com wrote: No. And as far as I know noone is working on it for llvmpipe. If I'd write a to do list for llvmpipe, that would probably be on page 50 or so :-). But patches always welcome... Well, is such a to-do list for LLVMpipe online? I'm quite interested :) Ilyes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Mon, 2015-06-08 at 15:45 -0400, Rob Clark wrote:
From: Rob Clark robcl...@freedesktop.org
I need something like this in a couple places. And didn't see anything
like it anywhere.
We ended up doing something similar in our work-in-progress nir/vec4
pass, it makes the code a bit easier to read, so if nobody else has
objections this is:
Reviewed-by: Iago Toral Quiroga ito...@igalia.com
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
v2: Added similar helper for nir_src, and cleaned up a few places that
open coded this. There are a couple left (such as validate_alu_src())
but that handle is_packed differently so I thought it best to leave
them as-is.
A quick grep suggests that nobody is ever setting is_packed to true...
the only code that reads is_packed is in nir_validate and it is there
only to avoid doing validations on the number of components when
is_packed is set to true, so I guess it is okay to keep that code as it
is.
Iago
src/glsl/nir/nir.h | 18 ++
src/glsl/nir/nir_from_ssa.c | 10 ++
src/glsl/nir/nir_validate.c | 4 +---
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 697d37e..06bbb0c 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -541,6 +541,24 @@ typedef struct {
#define nir_foreach_def_safe(reg, dest) \
list_for_each_entry_safe(nir_dest, dest, (reg)-defs, reg.def_link)
+static inline unsigned
+nir_dest_num_components(nir_dest *dest)
+{
+ if (dest-is_ssa)
+ return dest-ssa.num_components;
+ else
+ return dest-reg.reg-num_components;
+}
+
+static inline unsigned
+nir_src_num_components(nir_src *src)
+{
+ if (src-is_ssa)
+ return src-ssa-num_components;
+ else
+ return src-reg.reg-num_components;
+}
+
static inline nir_src
nir_src_for_ssa(nir_ssa_def *def)
{
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 67733e6..23c798d 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -553,10 +553,7 @@ emit_copy(nir_parallel_copy_instr *pcopy, nir_src src,
nir_src dest_src,
dest_src.reg.indirect == NULL
dest_src.reg.base_offset == 0);
- if (src.is_ssa)
- assert(src.ssa-num_components = dest_src.reg.reg-num_components);
- else
- assert(src.reg.reg-num_components =
dest_src.reg.reg-num_components);
+ assert(nir_src_num_components(src) == nir_src_num_components(dest_src));
nir_alu_instr *mov = nir_alu_instr_create(mem_ctx, nir_op_imov);
nir_src_copy(mov-src[0].src, src, mem_ctx);
@@ -712,10 +709,7 @@ resolve_parallel_copy(nir_parallel_copy_instr *pcopy,
nir_register *reg = nir_local_reg_create(state-impl);
reg-name = copy_temp;
reg-num_array_elems = 0;
- if (values[b].is_ssa)
- reg-num_components = values[b].ssa-num_components;
- else
- reg-num_components = values[b].reg.reg-num_components;
+ reg-num_components = nir_src_num_components(values[b]);
values[num_vals].is_ssa = false;
values[num_vals].reg.reg = reg;
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index da92ed9..c781912 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -262,9 +262,7 @@ validate_dest(nir_dest *dest, validate_state *state)
static void
validate_alu_dest(nir_alu_dest *dest, validate_state *state)
{
- unsigned dest_size =
- dest-dest.is_ssa ? dest-dest.ssa.num_components
-: dest-dest.reg.reg-num_components;
+ unsigned dest_size = nir_dest_num_components(dest-dest);
bool is_packed = !dest-dest.is_ssa dest-dest.reg.reg-is_packed;
/*
* validate that the instruction doesn't write to components not in the
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: correct alignment units for 2D compressed textures on Skylake
Thanks for the diagram and explanation. The Bspec's Calculating Texel
Location for 2D Surfaces section says that each LOD's width and height is
determined by a formula using an alignment term. One reason is to calculate
the LOD positions. I'm assuming another is to prevent the sampler engine
from fetching texels outside of pages defined by the GTT by padding images
for cache alignment. Is this true? If we don't align LOD-{0,2} by the
alignment term and use a block dimension instead, don't we risk getting
this error? Even if this is not the case, the spec doesn't exempt LOD-0
from being aligned by the alignment term, right?
Thanks,
Nanley
On Mon, Jun 15, 2015 at 10:45 AM, Neil Roberts n...@linux.intel.com wrote:
Nanley Chery nanleych...@gmail.com writes:
Although most of the patch is incorrect, the following change is still
necessary isn't it?
if (mt-compressed) {
mip1_width = ALIGN(minify(mt-physical_width0, 1), mt-align_w) +
- ALIGN(minify(mt-physical_width0, 2), bw);
+ ALIGN(minify(mt-physical_width0, 2), mt-align_w);
Each LOD is aligned by the alignment term. I don't see why we're
switching to block width here.
I'm pretty sure the original version is correct and we do want to align
to the block width here. This bit of code is not being used to work out
the position of an image so it doesn't need to take into account the
image alignment. It is only being used to calculate the mt-total_width
value. That value is not aligned to the image alignment. You can see
this because it will usually just be directly taken from
mt-physical_width0 and that is not aligned. In the non-compressed case
just below you can see that the second half of the addition is not
aligned to anything at all. The total_width does however need to be at
least a multiple of the block size because it isn't possible to allocate
space for half of a block.
If I understand correctly this code is just trying to cope with cases
where the third image in the mipmap is positioned so that it extends
past the width of the first image. If that happens then the width of the
image containing all of the mipmap images needs to be extended slightly
or it would crop the third mipmap image.
Please see the attached SVG.
Looking at it a bit more I think this bit above is wrong:
if (mt-compressed) {
mt-total_width = ALIGN(mt-physical_width0, mt-align_w);
}
That should also be using bw instead of mt-align_w for the same reason.
I think it could only end up making the total_width a bit larger than
necessary so it probably isn't causing any actual problems.
I'll make a patch and test it.
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/9] i965: Fix textureGrad with cube samplers
On Tue, 2015-06-16 at 23:52 -0700, Ben Widawsky wrote:
On Tue, Feb 24, 2015 at 07:02:50PM +0100, Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
We can't use sampler messages with gradient information (like
sample_g or sample_d) to deal with this scenario because according
to the PRM:
The r coordinate and its gradients are required only for surface
types that use the third coordinate. Usage of this message type on
cube surfaces assumes that the u, v, and gradients have already been
transformed onto the appropriate face, but still in [-1,+1] range.
The r coordinate contains the faceid, and the r gradients are ignored
by hardware.
Instead, we should lower this to compute the LOD manually based on the
gradients and use a different sample message that takes the computed
LOD instead of the gradients. This is already being done in
brw_lower_texture_gradients.cpp, but it is restricted to shadow
samplers only, although there is a comment stating that we should
probably do this also for samplerCube and samplerCubeArray.
Because of this, both dEQP and Piglit test cases for textureGrad with
cube maps currently fail.
This patch does two things:
1) Activates the texturegrad lowering pass for all cube samplers.
2) Corrects the computation of the LOD value for cube samplers.
I had to do 2) because for cube maps the calculations implemented
in the lowering pass always compute a value of rho that is twice
the value we want (so we get a LOD value one unit larger than we
want). This only happens for cube map samplers (all kinds). I am
not sure about why we need to do this, but I suspect that it is
related to the fact that cube map coordinates, when transported
to a specific face in the cube, are in the range [-1, 1] instead of
[0, 1] so we probably need to divide the derivatives by 2 when
we compute the LOD. Doing that would produce the same result as
dividing the final rho computation by 2 (or removing a unit
from the computed LOD, which is what we are doing here).
Fixes the following piglit tests:
bin/tex-miplevel-selection textureGrad Cube -auto -fbo
bin/tex-miplevel-selection textureGrad CubeArray -auto -fbo
bin/tex-miplevel-selection textureGrad CubeShadow -auto -fbo
Fixes 10 dEQP tests in the following category:
dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*cube*
What$ happened to this patch? It seems like we still need/want it, and it
seemed
like people had been looking at it. Was it just missing a formal review?
Yes, I think nobody gave it a formal reviewed-by yet.
Iago
---
.../dri/i965/brw_lower_texture_gradients.cpp | 26
+++---
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
b/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
index 9679d28..878a54e 100644
--- a/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
+++ b/src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp
@@ -89,19 +89,18 @@ txs_type(const glsl_type *type)
ir_visitor_status
lower_texture_grad_visitor::visit_leave(ir_texture *ir)
{
- /* Only lower textureGrad with shadow samplers */
- if (ir-op != ir_txd || !ir-shadow_comparitor)
+ /* Only lower textureGrad with cube maps or shadow samplers */
+ if (ir-op != ir_txd ||
+ (ir-sampler-type-sampler_dimensionality != GLSL_SAMPLER_DIM_CUBE
+ !ir-shadow_comparitor))
return visit_continue;
Do you need this for GLSL_SAMPLER_DIM_3D? It seems to fit with the PRM blurb
about use the third coordinate
- /* Lower textureGrad() with samplerCubeShadow even if we have the
sample_d_c
+ /* Lower textureGrad() with samplerCube* even if we have the sample_d_c
* message. GLSL provides gradients for the 'r' coordinate.
Unfortunately:
*
* From the Ivybridge PRM, Volume 4, Part 1, sample_d message
description:
* The r coordinate contains the faceid, and the r gradients are
ignored
* by hardware.
-*
-* We likely need to do a similar treatment for samplerCube and
-* samplerCubeArray, but we have insufficient testing for that at the
moment.
*/
bool need_lowering = !has_sample_d_c ||
ir-sampler-type-sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE;
@@ -153,9 +152,20 @@ lower_texture_grad_visitor::visit_leave(ir_texture *ir)
expr(ir_unop_sqrt, dot(dPdy, dPdy)));
}
- /* lambda_base = log2(rho). We're ignoring GL state biases for now. */
+ /* lambda_base = log2(rho). We're ignoring GL state biases for now.
+*
+* For cube maps the result of these formulas is giving us a value of
rho
+* that is twice the value we should use, so divide it by 2 or,
+* alternatively, remove one unit from the result of the log2
Re: [Mesa-dev] [PATCHES] Tessellation is here
Am 17.06.2015 14:34, schrieb Marek Olšák: Only the RadeonSI driver supports it right now. Marek Marek, will we ever see something on r600 or do we need 'new' boards (Turks, here)? GREAT stuff. -Dieter On Wed, Jun 17, 2015 at 2:21 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2
[Mesa-dev] [PATCH 4/4] egl: Use the loader_open_device() helper to do open with CLOEXEC
We've moved the open with CLOEXEC idiom into a helper function, so
call it instead of duplicating the code.
This also replaces a couple of opens that didn't properly do CLOEXEC.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
src/egl/drivers/dri2/platform_drm.c | 4 ++--
src/egl/drivers/dri2/platform_surfaceless.c | 11 +--
src/egl/drivers/dri2/platform_wayland.c | 11 +--
src/egl/drivers/dri2/platform_x11.c | 12 ++--
4 files changed, 6 insertions(+), 32 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index c97c54f..a62da41 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -611,9 +611,9 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
char buf[64];
int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
if (n != -1 n sizeof(buf))
- fd = open(buf, O_RDWR);
+ fd = loader_open_device(buf);
if (fd 0)
- fd = open(/dev/dri/card0, O_RDWR);
+ fd = loader_open_device(/dev/dri/card0);
dri2_dpy-own_device = 1;
gbm = gbm_create_device(fd);
if (gbm == NULL)
diff --git a/src/egl/drivers/dri2/platform_surfaceless.c
b/src/egl/drivers/dri2/platform_surfaceless.c
index 30cea36..48f15df 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -97,16 +97,7 @@ dri2_initialize_surfaceless(_EGLDriver *drv, _EGLDisplay
*disp)
if (asprintf(card_path, DRM_RENDER_DEV_NAME, DRM_DIR_NAME, base + i)
0)
continue;
-#ifdef O_CLOEXEC
- dri2_dpy-fd = open(card_path, O_RDWR | O_CLOEXEC);
- if (dri2_dpy-fd 0 errno == EINVAL)
-#endif
- {
- dri2_dpy-fd = open(card_path, O_RDWR);
- if (dri2_dpy-fd = 0)
-fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
- FD_CLOEXEC);
- }
+ dri2_dpy-fd = loader_open_device(card_path);
free(card_path);
if (dri2_dpy-fd 0)
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index ea2f9f2..1c98552 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -891,16 +891,7 @@ drm_handle_device(void *data, struct wl_drm *drm, const
char *device)
if (!dri2_dpy-device_name)
return;
-#ifdef O_CLOEXEC
- dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
- if (dri2_dpy-fd == -1 errno == EINVAL)
-#endif
- {
- dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
- if (dri2_dpy-fd != -1)
- fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
-FD_CLOEXEC);
- }
+ dri2_dpy-fd = loader_open_device(dri2_dpy-device_name);
if (dri2_dpy-fd == -1) {
_eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
dri2_dpy-device_name, strerror(errno));
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index e0d0fdc..e010800 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -43,6 +43,7 @@
#include egl_dri2.h
#include egl_dri2_fallbacks.h
+#include loader.h
static EGLBoolean
dri2_x11_swap_interval(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf,
@@ -1230,16 +1231,7 @@ dri2_initialize_x11_dri2(_EGLDriver *drv, _EGLDisplay
*disp)
if (!dri2_load_driver(disp))
goto cleanup_conn;
-#ifdef O_CLOEXEC
- dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
- if (dri2_dpy-fd == -1 errno == EINVAL)
-#endif
- {
- dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
- if (dri2_dpy-fd != -1)
- fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
-FD_CLOEXEC);
- }
+ dri2_dpy-fd = loader_open_device(dri2_dpy-device_name);
if (dri2_dpy-fd == -1) {
_eglLog(_EGL_WARNING,
DRI2: could not open %s (%s), dri2_dpy-device_name,
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] egl/drm: Duplicate fd with F_DUPFD_CLOEXEC to prevent leak
Replacing dup() with fcntl F_DUPFD_CLOEXEC creates the duplicate
file descriptor with CLOEXEC so it won't be leaked to child
processes if the process fork()s later.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
src/egl/drivers/dri2/platform_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index 3391afc..c97c54f 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -632,7 +632,7 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
}
if (fd 0) {
- fd = dup(gbm_device_get_fd(gbm));
+ fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
if (fd 0) {
free(dri2_dpy);
return EGL_FALSE;
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] CLOEXEC fix-ups
This series catches a couple of places where we forget to set CLOEXEC on file descriptors, and makes a helper function for the necessarily ugly way we have to open fds to make sure CLOEXEC is set. Derek Foreman (4): egl/drm: Duplicate fd with F_DUPFD_CLOEXEC to prevent leak loader: Rename drm_open_device() to loader_open_device() and share it glx: Use loader_open_device() helper egl: Use the loader_open_device() helper to do open with CLOEXEC src/egl/drivers/dri2/platform_drm.c | 6 +++--- src/egl/drivers/dri2/platform_surfaceless.c | 11 +-- src/egl/drivers/dri2/platform_wayland.c | 11 +-- src/egl/drivers/dri2/platform_x11.c | 12 ++-- src/glx/dri2_glx.c | 10 +- src/loader/loader.c | 6 +++--- src/loader/loader.h | 3 +++ 7 files changed, 14 insertions(+), 45 deletions(-) -- 2.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] glx: Use loader_open_device() helper
We've moved the open with CLOEXEC idiom into a helper function, so
call it instead of duplicating the code here.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
src/glx/dri2_glx.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 538cf1a..27ea952 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1183,15 +1183,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
return NULL;
}
-#ifdef O_CLOEXEC
- psc-fd = open(deviceName, O_RDWR | O_CLOEXEC);
- if (psc-fd == -1 errno == EINVAL)
-#endif
- {
- psc-fd = open(deviceName, O_RDWR);
- if (psc-fd != -1)
- fcntl(psc-fd, F_SETFD, fcntl(psc-fd, F_GETFD) | FD_CLOEXEC);
- }
+ psc-fd = loader_open_device(deviceName);
if (psc-fd 0) {
ErrorMessageF(failed to open drm device: %s\n, strerror(errno));
goto handle_error;
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] loader: Rename drm_open_device() to loader_open_device() and share it
This is already our common idiom for opening files with CLOEXEC and
it's a little ugly, so let's share this one implementation.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
src/loader/loader.c | 6 +++---
src/loader/loader.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 17bf133..fc46815 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -314,8 +314,8 @@ get_id_path_tag_from_fd(struct udev *udev, int fd)
return id_path_tag;
}
-static int
-drm_open_device(const char *device_name)
+int
+loader_open_device(const char *device_name)
{
int fd;
#ifdef O_CLOEXEC
@@ -404,7 +404,7 @@ int loader_get_user_preferred_fd(int default_fd, int
*different_device)
goto default_device_clean;
}
- fd = drm_open_device(device_name);
+ fd = loader_open_device(device_name);
if (fd = 0) {
close(default_fd);
} else {
diff --git a/src/loader/loader.h b/src/loader/loader.h
index 60c58f2..055dc78 100644
--- a/src/loader/loader.h
+++ b/src/loader/loader.h
@@ -37,6 +37,9 @@ extern C {
#define _LOADER_GALLIUM (1 1)
int
+loader_open_device(const char *);
+
+int
loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id);
char *
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/14] gallium: add PIPE_CAP_MAX_SHADER_PATCH_VARYINGS
There appears to be a tabs/spaces screwup in vc4_screen.c, otherwise this patch is Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Could I trouble you to land this sooner rather than later? The gallium-side driver impl depends on this too. I guess I could just carry it in my nvc0-tess tree as well. On Tue, Jun 16, 2015 at 7:04 PM, Marek Olšák mar...@gmail.com wrote: From: Marek Olšák marek.ol...@amd.com --- src/gallium/docs/source/screen.rst | 4 src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + 15 files changed, 18 insertions(+) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 8f64817..e88af38 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -254,6 +254,10 @@ The integer capabilities: and size must be page-aligned. * ``PIPE_CAP_DEVICE_RESET_STATUS_QUERY``: Whether pipe_context::get_device_reset_status is implemented. +* ``PIPE_CAP_MAX_SHADER_PATCH_VARYINGS``: + How many per-patch outputs and inputs are supported between tessellation + control and tessellation evaluation shaders, not counting in TESSINNER and + TESSOUTER. The minimum allowed value for OpenGL is 30. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 6a5748c..e6ccfe5 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -221,6 +221,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: + case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: return 0; case PIPE_CAP_MAX_VIEWPORTS: diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 0590da0..de0798a 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -243,6 +243,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: + case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: return 0; case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index b75a259..9efa581 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -457,6 +457,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: + case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 47f1897..37f6cbe 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -292,6 +292,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: + case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: return 0; } /* should only get here on unhandled cases */ diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 2e38a19..039f703 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c @@ -162,6 +162,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: + case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 6583a35..c32ad01 100644 ---
