Re: [Mesa-dev] [PATCH 04/20] i965/vec4: Preserve CFG in spill_reg().
On Fri, Sep 19, 2014 at 07:57:00PM -0700, Matt Turner wrote: --- This also means I'll drop 05/20. v2: Just pass block to emit_before(), rather than trying to get rid of emit_before(). Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
On 24.09.2014 14:01, Ilia Mirkin wrote: For 3d textures, NumLayers is set to 1, which is not what we want. This fixes the newly added gl-layer-render-storage test (which constructs immutable 3d textures). Fixes regression introduced in d82bd7eb060. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Tested-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] [Bug 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 --- Comment #14 from smoki smoki00...@gmail.com --- Tried both patches, neither does not fix the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 --- Comment #15 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to comment #14) Tried both patches, neither does not fix the bug. Which patches are both patches? Can you confirm whether http://patchwork.freedesktop.org/patch/34010/ has any effect on your issue? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 Benjamin Bellec b.bel...@gmail.com changed: What|Removed |Added CC||b.bel...@gmail.com --- Comment #16 from Benjamin Bellec b.bel...@gmail.com --- How do you run these UE4 demo ? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 --- Comment #17 from smoki smoki00...@gmail.com --- Created attachment 106762 -- https://bugs.freedesktop.org/attachment.cgi?id=106762action=edit borked.jpg (In reply to comment #15) (In reply to comment #14) Tried both patches, neither does not fix the bug. Which patches are both patches? Comment 10 and Comment 13... separete of course. Can you confirm whether http://patchwork.freedesktop.org/patch/34010/ has any effect on your issue? That one also does not work, only colors is different now - see attachment. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/14] i965/compaction: Add support for Gen5.
On Tuesday, September 23, 2014 01:25:55 PM Matt Turner wrote:
On Tue, Sep 23, 2014 at 1:10 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner matts...@gmail.com wrote:
+int jump = brw_inst_imm_d(brw, insn);
+int jump_compacted = jump / sizeof(brw_compact_inst);
+int jump_uncompacted = jump / sizeof(brw_inst);
+
+target_old_ip = this_old_ip + jump_uncompacted;
+target_compacted_count = compacted_counts[target_old_ip];
+jump_compacted -= (target_compacted_count -
this_compacted_count);
+brw_inst_set_imm_ud(brw, insn, jump_compacted *
+ sizeof(brw_compact_inst));
Any reason why you're reading it as a signed value and then writing it back
in unsigned?
IIRC brw_inst_set_imm_d() is broken. It's been long enough that I've
forgotten the exact details, but _ud sets the exact bits you pass it,
while _d does something wrong.
static inline void
brw_inst_set_imm_d(const struct brw_context *brw,
brw_inst *insn, int value)
{
(void) brw;
return brw_inst_set_bits(insn, 127, 96, value);
}
The final parameter of brw_inst_set_bits is a uint64_t, so it looks like the
int value will get sign-extended to a 64-bit value, then treated as unsigned,
which is now too wide to fit in bits 127:96. IOW, it will never work for
negative values...while, ironically, brw_inst_set_imm_ud() will. (The int
would be converted to unsigned...still 32-bit...then promoted from unsigned to
uint64_t, which doesn't sign extend.)
That said, fixing it would be trivial:
return brw_inst_set_bits(insn, 127, 96, (unsigned) value);
We should either fix it or delete it. Either is fine by me.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/14] i965: Instruction compaction improvements
On Friday, September 19, 2014 05:47:58 PM Matt Turner wrote: On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner matts...@gmail.com wrote: This series adds instruction compaction support for G45 and Gen5 and enables compaction of control flow instructions. Ken reviewed the first four patches I think. Can I get someone to review the rest? I actually reviewed more, but forgot to send the email... Patches 1-7, 10, 13-14 are: Reviewed-by: Kenneth Graunke kenn...@whitecape.org Patches 8-9, 11-12 are: Acked-by: Kenneth Graunke kenn...@whitecape.org (they look fine but I never got around to looking at the details, and it looks like Jason's done that anyway, so I won't bother at this point) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context *st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
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 84186] X 1.16.1 RC 1 segfaults and reports XXX fail to create fbo with Radeon HD 7970.
https://bugs.freedesktop.org/show_bug.cgi?id=84186 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |mesa-dev@lists.freedesktop. ||org QA Contact|xorg-t...@lists.x.org | Product|xorg|Mesa Component|Driver/Radeon |Mesa core --- Comment #3 from Michel Dänzer mic...@daenzer.net --- The question is why the FBO creation fails. Reassigning to Mesa core for now. Can you attach the stderr output from running Xorg with the environment variable EGL_LOG_LEVEL=debug? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/17] auxiliary/vl: split out into a separate static library
On 22/09/14 00:44, Emil Velikov wrote: Avoid building the relatively large object every time and forcing on the non-vl targets. This gives us the following size improvement textdata bss dec hex filename 5898697 189212 1977864 8065773 7b12ed before/nouveau_dri.so 5771203 189228 391176 6351607 60eaf7 after/nouveau_dri.so Other targets (gbm, xa) are likely to exhibit similar savings. v2: Fix the 'pipe-loader' targets. This patch needs more work, thus I've dropped it for now and went ahead with the rest of the series. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: remove unused link_assign_uniform_block_offsets
ubo offsets are assigned by link_uniform_blocks since 514f8c7e
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/link_uniforms.cpp | 34 --
src/glsl/linker.h | 3 ---
2 files changed, 37 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index dcce183..5772771 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -777,40 +777,6 @@ link_update_uniform_buffer_variables(struct gl_shader
*shader)
}
}
-void
-link_assign_uniform_block_offsets(struct gl_shader *shader)
-{
- for (unsigned b = 0; b shader-NumUniformBlocks; b++) {
- struct gl_uniform_block *block = shader-UniformBlocks[b];
-
- unsigned offset = 0;
- for (unsigned int i = 0; i block-NumUniforms; i++) {
-struct gl_uniform_buffer_variable *ubo_var = block-Uniforms[i];
-const struct glsl_type *type = ubo_var-Type;
-
-unsigned alignment = type-std140_base_alignment(ubo_var-RowMajor);
-unsigned size = type-std140_size(ubo_var-RowMajor);
-
-offset = glsl_align(offset, alignment);
-ubo_var-Offset = offset;
-offset += size;
- }
-
- /* From the GL_ARB_uniform_buffer_object spec:
- *
- * For uniform blocks laid out according to [std140] rules,
- * the minimum buffer object size returned by the
- * UNIFORM_BLOCK_DATA_SIZE query is derived by taking the
- * offset of the last basic machine unit consumed by the
- * last uniform of the uniform block (including any
- * end-of-array or end-of-structure padding), adding one,
- * and rounding up to the next multiple of the base
- * alignment required for a vec4.
- */
- block-UniformBufferSize = glsl_align(offset, 16);
- }
-}
-
/**
* Scan the program for image uniforms and store image unit access
* information into the gl_shader data structure.
diff --git a/src/glsl/linker.h b/src/glsl/linker.h
index beb9bb2..7a6908c 100644
--- a/src/glsl/linker.h
+++ b/src/glsl/linker.h
@@ -47,9 +47,6 @@ link_cross_validate_uniform_block(void *mem_ctx,
unsigned int *num_linked_blocks,
struct gl_uniform_block *new_block);
-void
-link_assign_uniform_block_offsets(struct gl_shader *shader);
-
extern bool
link_uniform_blocks_are_compatible(const gl_uniform_block *a,
const gl_uniform_block *b);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: improve accuracy of atan()
On Wed, Sep 24, 2014 at 4:10 AM, Ian Romanick i...@freedesktop.org wrote:
On 09/23/2014 03:39 PM, Erik Faye-Lund wrote:
Our current atan()-approximation is pretty inaccurate at 1.0, so
let's try to improve the situation by doing a direct approximation
without going through atan.
This new implementation uses an 11th degree polynomial to approximate
atan in the [-1..1] range, and the following identitiy to reduce the
entire range to [-1..1]:
atan(x) = 0.5 * pi * sign(x) - atan(1.0 / x)
This range-reduction idea is taken from the paper Fast computation
of Arctangent Functions for Embedded Applications: A Comparative
Analysis (Ukil et al. 2011).
The polynomial that approximates atan(x) is:
x * 0.793128310355 - x^3 * 0.3326756418091246 +
x^5 * 0.1938924977115610 - x^7 * 0.1173503194786851 +
x^9 * 0.0536813784310406 - x^11 * 0.0121323213173444
This polynomial was found with the following GNU Octave script:
x = linspace(0, 1);
y = atan(x);
n = [1, 3, 5, 7, 9, 11];
format long;
polyfitc(x, y, n)
The polyfitc function is not built-in, but too long to include here.
It can be downloaded from the following URL:
http://www.mathworks.com/matlabcentral/fileexchange/47851-constraint-polynomial-fit/content/polyfitc.m
This fixes the following piglit test:
shaders/glsl-const-folding-01
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49713
Ah! Thanks a lot for that link, very useful.
We could also go down that path, by introducing an ir_unop_atan that
gets lowered to a polynomial before code-generation. That would benefit
drivers for hardware with atan-support (at least Mali supports this,
according to http://limadriver.org/Lima+ISA/), but it worries me a bit to
do constant folding with different precision than execution. But perhaps
we already have that problem, only a bit more subtle?
We used to implement constant folding for many built-in functions this
way. Built-in functions like atan were detected in the constant folding
process, and C library functions were used. Commit 363c14ae0 changed
this to simplify the constant folding code. This test case began
failing at that time, and Vinson submitted bug #49713.
Aha, thanks for clearing that up. However, just to be clear, my
alternative suggestion isn't to go back in that direction. It's to
make atan a middle-class citizen, like ir_unop_[exp|log]. These always
gets lowered to ir_unop_[exp|log]2, but in this case the lowering
would go to arithmetic.
Something like this (also no piglit regressions):
--8--
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 9be7f6d..cc6c8b3 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -442,6 +442,7 @@ private:
ir_swizzle *matrix_elt(ir_variable *var, int col, int row);
ir_expression *asin_expr(ir_variable *x);
+ void do_atan(ir_factory body, const glsl_type *type, ir_variable
*res, operand y_over_x);
/**
* Call function \param f with parameters specified as the linked
@@ -2596,6 +2597,7 @@ builtin_builder::_degrees(const glsl_type *type)
UNOP(sin, ir_unop_sin, always_available)
UNOP(cos, ir_unop_cos, always_available)
+UNOP(atan, ir_unop_atan, always_available)
ir_function_signature *
builtin_builder::_tan(const glsl_type *type)
@@ -2684,11 +2686,7 @@ builtin_builder::_atan2(const glsl_type *type)
ir_factory outer_then(outer_if-then_instructions, mem_ctx);
/* Then...call atan(y/x) */
- ir_variable *y_over_x =
outer_then.make_temp(glsl_type::float_type, y_over_x);
- outer_then.emit(assign(y_over_x, div(y, x)));
- outer_then.emit(assign(r, mul(y_over_x, rsq(add(mul(y_over_x, y_over_x),
- imm(1.0f));
- outer_then.emit(assign(r, asin_expr(r)));
+ body.emit(assign(r, expr(ir_unop_atan, div(y, x;
/* ...and fix it up: */
ir_if *inner_if = new(mem_ctx) ir_if(less(x, imm(0.0f)));
@@ -2712,21 +2710,6 @@ builtin_builder::_atan2(const glsl_type *type)
}
ir_function_signature *
-builtin_builder::_atan(const glsl_type *type)
-{
- ir_variable *y_over_x = in_var(type, y_over_x);
- MAKE_SIG(type, always_available, 1, y_over_x);
-
- ir_variable *t = body.make_temp(type, t);
- body.emit(assign(t, mul(y_over_x, rsq(add(mul(y_over_x, y_over_x),
- imm(1.0f));
-
- body.emit(ret(asin_expr(t)));
-
- return sig;
-}
-
-ir_function_signature *
builtin_builder::_sinh(const glsl_type *type)
{
ir_variable *x = in_var(type, x);
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 739a9f4..1ec7789 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -247,6 +247,7 @@ ir_expression::ir_expression(int op, ir_rvalue *op0)
case ir_unop_cos:
case ir_unop_sin_reduced:
case ir_unop_cos_reduced:
+ case ir_unop_atan:
case ir_unop_dFdx:
case
Re: [Mesa-dev] [PATCH] gallivm: Disable gallivm to fix build with LLVM 3.6
On 23/09/14 21:23, Tom Stellard wrote:
LLVM commit r218316 removes the JITMemoryManager class, which is
the parent for a seemingly important class in gallivm. In order to
fix the build, I've wrapped most of lp_bld_misc.cpp in
if HAVE_LLVM 0x0306 and modifyed the
lp_build_create_jit_compiler_for_module() function to return false
for 3.6 and newer which effectively disables the gallivm functionality.
I realize this is overkill, but I could not come up with a simple
solution to fix the build.
I don't oppose this until we have a better fix.
Also, since 3.6 will be the first release
without the old JIT, it would be really great if we could
move gallivm to use the C API only for accessing MCJIT. There
is still time before the 3.6 release to extend the C API in
case it is missing some functionality that is required by gallivm.
Yes, ideally the C API would suffice.
We're not the only one with similar needs. Webkit has similar needs.
Though they opted by using LLVMCreateSimpleMCJITMemoryManager
https://trac.webkit.org/browser/trunk/Tools/ReducedFTL/ReducedFTL.c#L321
and implemeting the memory manager themselves.
We could do the same. We even have the code for it in
src/gallium/auxiliary/rtasm/rtasm_execmem.*( And if we add a mutex
we could make this thread safe too, without needing multiple jit
managers around)
The other alternative would be to have another function besides
LLVMCreateSimpleMCJITMemoryManager that would create a standard
LLVMMCJITMemoryManagerRef.
That said, the way we use these things are still a bit in flux. Mathias
has some pending patches. BTW, Mathis, should I submit your patches
for making llvmpipe thread safe? Also, what are your thoughts on this
issue?
Jose
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 2fd85a8..1c42e8f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -143,6 +143,7 @@ lp_set_store_alignment(LLVMValueRef Inst,
llvm::unwrapllvm::StoreInst(Inst)-setAlignment(Align);
}
+#if HAVE_LLVM 0x0306
/*
* Delegating is tedious but the default manager class is hidden in an
@@ -398,6 +399,7 @@ class ShaderMemoryManager : public
DelegatingJITMemoryManager {
llvm::JITMemoryManager *ShaderMemoryManager::TheMM = 0;
unsigned ShaderMemoryManager::NumUsers = 0;
+#endif
/**
* Same as LLVMCreateJITCompilerForModule, but:
@@ -420,6 +422,11 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
{
using namespace llvm;
+#if HAVE_LLVM = 0x0306
+ *OutError = strdup(MCJIT not supported);
+ return 1;
+#else
+
std::string Error;
#if HAVE_LLVM = 0x0306
EngineBuilder builder(std::unique_ptrModule(unwrap(M)));
@@ -528,6 +535,7 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
delete MM;
*OutError = strdup(Error.c_str());
return 1;
+#endif
}
@@ -535,5 +543,7 @@ extern C
void
lp_free_generated_code(struct lp_generated_code *code)
{
+#if HAVE_LLVM 0x0306
ShaderMemoryManager::freeGeneratedCode(code);
+#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix uniform location count used for glsl types
Tapani Pälli tapani.pa...@intel.com writes:
Patch fixes the slot count used by vector types and adds 1 slot
to be used by image and sampler types.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
https://bugs.freedesktop.org/show_bug.cgi?id=82921
---
src/glsl/glsl_types.cpp | 18 +-
src/glsl/glsl_types.h | 3 +++
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 66e9b13..3c13fce 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -678,12 +678,17 @@ glsl_type::component_slots() const
unsigned
glsl_type::uniform_locations() const
{
- if (this-is_matrix())
- return 1;
-
unsigned size = 0;
switch (this-base_type) {
+ case GLSL_TYPE_UINT:
+ case GLSL_TYPE_INT:
+ case GLSL_TYPE_FLOAT:
+ case GLSL_TYPE_BOOL:
+ case GLSL_TYPE_SAMPLER:
+ case GLSL_TYPE_IMAGE:
+ return 1;
+
case GLSL_TYPE_STRUCT:
case GLSL_TYPE_INTERFACE:
for (unsigned i = 0; i this-length; i++)
@@ -692,13 +697,8 @@ glsl_type::uniform_locations() const
case GLSL_TYPE_ARRAY:
return this-length * this-fields.array-uniform_locations();
default:
- break;
+ return 0;
}
-
- /* The location count for many types match with component_slots() result,
-* all expections should be handled above.
-*/
- return component_slots();
}
bool
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index d545533..5a307bb 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -279,6 +279,9 @@ struct glsl_type {
/**
* Calculate the number of unique values from glGetUniformLocation for the
* elements of the type.
+*
+* This is used to allocate slots in the UniformRemapTable, the amount of
+* locations may not match with actual used storage space by the driver.
*/
unsigned uniform_locations() const;
Looks OK to me,
Reviewed-by: Francisco Jerez curroje...@riseup.net
pgpMFMs4eyVy5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] replace file specific compiler optimization withinline attibute
Hi Matt, Am Montag, 22. September 2014, 11:48:29 schrieb Matt Turner: On Fri, Sep 12, 2014 at 4:56 AM, Marc Dietrich marvi...@gmx.de wrote: File specific optimization as used for src/mesa/main/streaming-load-memcpy.c currently will cause problems with LTO in the future (see: https://bugs.freedesktop.org/show_bug.cgi?id=83669). Replace it with in-file target specification. This only works for gcc for now. The intel compiler has __attribute__((cpu_specific(cpuid))) with cpuid core_2_duo_sse4_1, but I'm not sure if mesa compiles with it and how it behaves on different platforms. V2: limit support for this optimization to gcc = 4.4 only Signed-off-by: Marc Dietrich marvi...@gmx.de --- This is the simplest solution I see for now. Drawback is that gcc 4.4 cannot make use of this single improvement anymore. Otherwise we would have to maintain a nightmare of version checks for different compilers and different pragmas. configure.ac | 10 ++ src/mesa/Makefile.am | 1 - src/mesa/main/streaming-load-memcpy.c | 4 ++-- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 29cf32e..52ff00a 100644 --- a/configure.ac +++ b/configure.ac @@ -240,11 +240,13 @@ AC_SUBST([VISIBILITY_CXXFLAGS]) dnl dnl Optional flags, check for compiler support dnl -AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0]) This is the only use of AX_CHECK_COMPILE_FLAG, so we can remove m4/ax_check_compile_flag.m4. well, I guess this test could be used more often in the future when more special acceleration paths are added. On the other hand, the test for the gcc version is enough in this case. -if test x$SSE41_SUPPORTED = x1; then -DEFINES=$DEFINES -DUSE_SSE41 +if test 0$GCC_VERSION_MAJOR$GCC_VERSION_MINOR -ge 44; then +AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0]) +if test x$SSE41_SUPPORTED = x1; then +DEFINES=$DEFINES -DUSE_SSE41 +fi +AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1]) fi -AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1]) dnl Can't have static and shared libraries, default to static if user dnl explicitly requested. If both disabled, set to static since shared diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am index e71bccb..bbdb36f 100644 --- a/src/mesa/Makefile.am +++ b/src/mesa/Makefile.am @@ -152,7 +152,6 @@ libmesagallium_la_LIBADD = \ libmesa_sse41_la_SOURCES = \ main/streaming-load-memcpy.c -libmesa_sse41_la_CFLAGS = $(AM_CFLAGS) -msse4.1 We don't need libmesa_sse41.la anymore, so just remove this by adding main/streaming-load-memcpy.c to libmesa.la's sources (pending figuring out how to handle clang support, see below). ok. pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = gl.pc diff --git a/src/mesa/main/streaming-load-memcpy.c b/src/mesa/main/streaming-load-memcpy.c index 8427149..94b0e0a 100644 --- a/src/mesa/main/streaming-load-memcpy.c +++ b/src/mesa/main/streaming-load-memcpy.c @@ -26,7 +26,7 @@ * */ -#ifdef __SSE4_1__ +#ifdef USE_SSE41 #include main/macros.h #include main/streaming-load-memcpy.h #include smmintrin.h This header can only be included when __SSE4_1__ is defined (which is enabled today when gcc is using an appropriate -march= setting or -msse4.1. How do you propose we work around that? I suppose #defining __SSE4_1__ before the inclusion is probably okay? looking at the header file, I think it can be included, but I'm not sure what the outcome will be. An alternative is to use the gcc pragma as shown in the header: #ifdef USE_SSE41 #pragma GCC push_options #pragma GCC target(sse4.1) #include stuff void my_nice_see_func() #pragma GCC pop_options @@ -34,7 +34,7 @@ /* Copies memory from src to dst, using SSE 4.1's MOVNTDQA to get streaming * read performance from uncached memory. */ -void +void __attribute__ ((target(sse4.1))) We need a configure check for support for __attribute__((target)). I'm going to send a series that adds support for this (and does the check for existing attribute uses, so once that goes in you can rebase this patch on that). nice, but won't work with the workaround above. Pragma and attribute does the same so, we could check for the attribute and use the pragma instead. It doesn't look like clang supports this though, which would be nice to support... don't know what to do. clang does support the existing -msse4.1 flag, so this would be a regression there. Any ideas for handling that? clang reports gcc 4.2 compatibilty, so USE_SSE4.1 would not be set (tests for gcc = 4.4). Marc signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list
Re: [Mesa-dev] Interest in participating in the OPW with X.org
Hello, Thanks for the reply. I'll download and build piglit, take a look at the various tests written in it and either come up with a project to work on, or wait for some ideas from mentors to take on as a project. I will like to know whether any documentation work could be a viable project? Thanks, Juliet On Wed, Sep 24, 2014 at 6:06 AM, Peter Hutterer peter.hutte...@who-t.net wrote: Hi Juliet, sorry about the delay, thanks for the email. I don't personally work on mesa so I'll wait if anyone on the list has a project to propose here. On Sat, Sep 20, 2014 at 07:52:38PM +0100, Juliet Fru wrote: I am Juliet Fru, a second year student of Computer Engineering at the University of Buea. I am interested in participating in the OPW this year. I've never worked on an open source project before; and I'll like to have this first experience with Xorg. I am proficient in C and i'm interested in writing tests for piglit. I'll like to know based on my discussions on IRC whether there is any programmer who is working on some functionality he/she would need me to write unit tests for? I would like to work on writing tests as my OPW project. One of the best ways to start is to build and run piglit and see if anything needs fixing. That way you get familiar with the code-base and the developers get to know you as well. Having a bit of a reputation from sending patches is a good thing to have. Cheers, Peter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Corruption and freezing issues with my Radeon 6670
Hey guys, I don't think this is a Mesa issue but I didn't know where else to start. I tried using the #radeon channel but it wont let me post anything. I'm having some corruption and freezing issues with my 6670 that I would like to help find the cause of. For more details and a screenshot see: https://lists.fedoraproject.org/pipermail/test/2014-September/122946.html The card works fine with Catalyst so I don't think its a hardware defect. Any help with this is appreciated. Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Corruption and freezing issues with my Radeon 6670
On Wed, Sep 24, 2014 at 9:31 AM, Timothy Arceri t_arc...@yahoo.com.au wrote: Hey guys, I don't think this is a Mesa issue but I didn't know where else to start. I tried using the #radeon channel but it wont let me post anything. I'm having some corruption and freezing issues with my 6670 that I would like to help find the cause of. For more details and a screenshot see: https://lists.fedoraproject.org/pipermail/test/2014-September/122946.html The card works fine with Catalyst so I don't think its a hardware defect. Any help with this is appreciated. Please file a bug (https://bugs.freedesktop.org) and attach your xorg log and dmesg output. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Corruption and freezing issues with my Radeon 6670
On Wed, Sep 24, 2014 at 8:31 AM, Timothy Arceri t_arc...@yahoo.com.au wrote: Hey guys, I don't think this is a Mesa issue but I didn't know where else to start. I tried using the #radeon channel but it wont let me post anything. You have to be a registered user with nickserv on freenode to post in #radeon, I think. Email me for more info if necesasry. I ran into that myself a while back and it took a bit to realize what was going on. --Aaron I'm having some corruption and freezing issues with my 6670 that I would like to help find the cause of. For more details and a screenshot see: https://lists.fedoraproject.org/pipermail/test/2014-September/122946.html The card works fine with Catalyst so I don't think its a hardware defect. Any help with this is appreciated. Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove EXT suffix from FBO error messages
And use pass caller= for _mesa_FramebufferTexture().
---
src/mesa/main/fbobject.c | 60 +++---
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index ae3a418..8283373 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2303,8 +2303,8 @@ reuse_framebuffer_texture_attachment(struct
gl_framebuffer *fb,
/**
- * Common code called by glFramebufferTexture1D/2D/3DEXT() and
- * glFramebufferTextureLayerEXT().
+ * Common code called by glFramebufferTexture1D/2D/3D() and
+ * glFramebufferTextureLayer().
*
* \param textarget is the textarget that was passed to the
* glFramebufferTexture...() function, or 0 if the corresponding function
@@ -2326,14 +2326,14 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
fb = get_framebuffer_target(ctx, target);
if (!fb) {
_mesa_error(ctx, GL_INVALID_ENUM,
- glFramebufferTexture%sEXT(target=0x%x), caller, target);
+ glFramebufferTexture%s(target=0x%x), caller, target);
return;
}
/* check framebuffer binding */
if (_mesa_is_winsys_fbo(fb)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glFramebufferTexture%sEXT, caller);
+ glFramebufferTexture%s, caller);
return;
}
@@ -2397,14 +2397,14 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
else {
/* can't render to a non-existant texture */
_mesa_error(ctx, GL_INVALID_OPERATION,
- glFramebufferTexture%sEXT(non existant texture),
+ glFramebufferTexture%s(non existant texture),
caller);
return;
}
if (err) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glFramebufferTexture%sEXT(texture target mismatch),
+ glFramebufferTexture%s(texture target mismatch),
caller);
return;
}
@@ -2413,7 +2413,7 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
const GLint maxSize = 1 (ctx-Const.Max3DTextureLevels - 1);
if (zoffset 0 || zoffset = maxSize) {
_mesa_error(ctx, GL_INVALID_VALUE,
-glFramebufferTexture%sEXT(zoffset), caller);
+glFramebufferTexture%s(zoffset), caller);
return;
}
}
@@ -2424,7 +2424,7 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
if (zoffset 0 ||
zoffset = (GLint) ctx-Const.MaxArrayTextureLayers) {
_mesa_error(ctx, GL_INVALID_VALUE,
-glFramebufferTexture%sEXT(layer), caller);
+glFramebufferTexture%s(layer), caller);
return;
}
}
@@ -2433,7 +2433,7 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
if ((level 0) ||
(level = _mesa_max_texture_levels(ctx, maxLevelsTarget))) {
_mesa_error(ctx, GL_INVALID_VALUE,
- glFramebufferTexture%sEXT(level), caller);
+ glFramebufferTexture%s(level), caller);
return;
}
}
@@ -2441,7 +2441,7 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
att = get_attachment(ctx, fb, attachment);
if (att == NULL) {
_mesa_error(ctx, GL_INVALID_ENUM,
- glFramebufferTexture%sEXT(attachment), caller);
+ glFramebufferTexture%s(attachment), caller);
return;
}
@@ -2531,7 +2531,7 @@ _mesa_FramebufferTexture1D(GLenum target, GLenum
attachment,
if (error) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glFramebufferTexture1DEXT(textarget=%s),
+ glFramebufferTexture1D(textarget=%s),
_mesa_lookup_enum_by_nr(textarget));
return;
}
@@ -2582,7 +2582,7 @@ _mesa_FramebufferTexture2D(GLenum target, GLenum
attachment,
if (error) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glFramebufferTexture2DEXT(textarget=%s),
+ glFramebufferTexture2D(textarget=%s),
_mesa_lookup_enum_by_nr(textarget));
return;
}
@@ -2602,7 +2602,7 @@ _mesa_FramebufferTexture3D(GLenum target, GLenum
attachment,
if ((texture != 0) (textarget != GL_TEXTURE_3D)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
- glFramebufferTexture3DEXT(textarget));
+ glFramebufferTexture3D(textarget));
return;
}
@@ -2629,7 +2629,7 @@ _mesa_FramebufferTexture(GLenum target, GLenum attachment,
GET_CURRENT_CONTEXT(ctx);
if (_mesa_has_geometry_shaders(ctx)) {
- framebuffer_texture(ctx, Layer, target, attachment,
Re: [Mesa-dev] Interest in participating in the OPW with X.org
Hi Juliet, There's definitely work that can be done for Piglit. For example, porting the old Glean tests to piglit's framework. I suggest we move this conversation to the Piglit mailing list though. The list is pig...@lists.freedesktop.org and you can subscribe at http://lists.freedesktop.org/mailman/listinfo/piglit -Brian On 09/24/2014 07:22 AM, Juliet Fru wrote: Hello, Thanks for the reply. I'll download and build piglit, take a look at the various tests written in it and either come up with a project to work on, or wait for some ideas from mentors to take on as a project. I will like to know whether any documentation work could be a viable project? Thanks, Juliet On Wed, Sep 24, 2014 at 6:06 AM, Peter Hutterer peter.hutte...@who-t.net mailto:peter.hutte...@who-t.net wrote: Hi Juliet, sorry about the delay, thanks for the email. I don't personally work on mesa so I'll wait if anyone on the list has a project to propose here. On Sat, Sep 20, 2014 at 07:52:38PM +0100, Juliet Fru wrote: I am Juliet Fru, a second year student of Computer Engineering at the University of Buea. I am interested in participating in the OPW this year. I've never worked on an open source project before; and I'll like to have this first experience with Xorg. I am proficient in C and i'm interested in writing tests for piglit. I'll like to know based on my discussions on IRC whether there is any programmer who is working on some functionality he/she would need me to write unit tests for? I would like to work on writing tests as my OPW project. One of the best ways to start is to build and run piglit and see if anything needs fixing. That way you get familiar with the code-base and the developers get to know you as well. Having a bit of a reputation from sending patches is a good thing to have. Cheers, Peter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=5mApqFAQr6eJchyCRldATs3zsTLCpKq0Zoav84cz1fI%3D%0As=3c3e2d7058943367dcc501690c29e5af645912670a90d5f939a80d66a36a530c ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 --- Comment #18 from Christoph Haag haa...@frickel.club --- Weird. Mesa git master + *only* the last patch did fix it for me. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: Disable gallivm to fix build with LLVM 3.6
Hi Jose, On Wednesday, September 24, 2014 12:42:24 Jose Fonseca wrote: That said, the way we use these things are still a bit in flux. Mathias has some pending patches. BTW, Mathis, should I submit your patches for making llvmpipe thread safe? Also, what are your thoughts on this issue? Just short, currently not at my box with the mesa sources. Feel free to push these two patches, I try to find time on a longer answer and the pending 3rd patch this european evening! Thanks! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context *st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
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 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 --- Comment #19 from smoki smoki00...@gmail.com --- (In reply to comment #18) Weird. Mesa git master + *only* the last patch did fix it for me. Weird or not, doublechecked and it does not work for me :). Previosly patched with 45b104e0a228595142ed4bc62bbc8948100b9325 and now on top of 2f7714e0717250c6737accc6c8259c6d9107fd6e again picture stay like in Comment 17 Only llvm is few days old here, but it worked with it when i bisected this... who knows lets build llvm :) -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84145] UE4: Realistic Rendering Demo render blue
https://bugs.freedesktop.org/show_bug.cgi?id=84145 --- Comment #20 from smoki smoki00...@gmail.com --- Oh my it worked :), it is about s3tc i removed lib so picture is without s3tc :D https://bugs.freedesktop.org/attachment.cgi?id=106762 So yeah, it is fixed for me too. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] st/va: skeleton VAAPI state tracker
Hi Emil, -Original Message- From: Emil Velikov [mailto:emil.l.veli...@gmail.com] Sent: Tuesday, September 23, 2014 3:49 PM To: Liu, Leo; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com; Koenig, Christian Subject: Re: [Mesa-dev] [PATCH 2/6] st/va: skeleton VAAPI state tracker .. + +gallium_drv_video_la_LIBADD = \ +$(top_builddir)/src/gallium/state_trackers/va/libvatracker.la \ +$(top_builddir)/src/gallium/auxiliary/libgallium.la \ +$(top_builddir)/src/util/libmesautil.la \ +$(LIBVA_LIBS) \ Unless I've missed something this link should not be needed. If in doubt just omit it, and let the _compiler_ shout about undefined symbols :) If you talk about $(LIBVA_LIBS), we probably need it. +PKG_CHECK_MODULES([LIBVA], [libva = 0.35.0 x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED]) Maybe I need change the name of LIBVA to VA I will fix the rest in the v2. Thanks, Leo Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: remove unused link_assign_uniform_block_offsets
Nice catch.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 09/24/2014 04:09 AM, Tapani Pälli wrote:
ubo offsets are assigned by link_uniform_blocks since 514f8c7e
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/link_uniforms.cpp | 34 --
src/glsl/linker.h | 3 ---
2 files changed, 37 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index dcce183..5772771 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -777,40 +777,6 @@ link_update_uniform_buffer_variables(struct gl_shader
*shader)
}
}
-void
-link_assign_uniform_block_offsets(struct gl_shader *shader)
-{
- for (unsigned b = 0; b shader-NumUniformBlocks; b++) {
- struct gl_uniform_block *block = shader-UniformBlocks[b];
-
- unsigned offset = 0;
- for (unsigned int i = 0; i block-NumUniforms; i++) {
- struct gl_uniform_buffer_variable *ubo_var = block-Uniforms[i];
- const struct glsl_type *type = ubo_var-Type;
-
- unsigned alignment = type-std140_base_alignment(ubo_var-RowMajor);
- unsigned size = type-std140_size(ubo_var-RowMajor);
-
- offset = glsl_align(offset, alignment);
- ubo_var-Offset = offset;
- offset += size;
- }
-
- /* From the GL_ARB_uniform_buffer_object spec:
- *
- * For uniform blocks laid out according to [std140] rules,
- * the minimum buffer object size returned by the
- * UNIFORM_BLOCK_DATA_SIZE query is derived by taking the
- * offset of the last basic machine unit consumed by the
- * last uniform of the uniform block (including any
- * end-of-array or end-of-structure padding), adding one,
- * and rounding up to the next multiple of the base
- * alignment required for a vec4.
- */
- block-UniformBufferSize = glsl_align(offset, 16);
- }
-}
-
/**
* Scan the program for image uniforms and store image unit access
* information into the gl_shader data structure.
diff --git a/src/glsl/linker.h b/src/glsl/linker.h
index beb9bb2..7a6908c 100644
--- a/src/glsl/linker.h
+++ b/src/glsl/linker.h
@@ -47,9 +47,6 @@ link_cross_validate_uniform_block(void *mem_ctx,
unsigned int *num_linked_blocks,
struct gl_uniform_block *new_block);
-void
-link_assign_uniform_block_offsets(struct gl_shader *shader);
-
extern bool
link_uniform_blocks_are_compatible(const gl_uniform_block *a,
const gl_uniform_block *b);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
Cubemaps have array_size == 1, but you can still set the target to 2D
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context *st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context *st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
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] gallivm: Disable gallivm to fix build with LLVM 3.6
Le mardi 23 septembre 2014, 16:23:03 Tom Stellard a écrit : LLVM commit r218316 removes the JITMemoryManager class, which is the parent for a seemingly important class in gallivm. In order to fix the build, I've wrapped most of lp_bld_misc.cpp in if HAVE_LLVM 0x0306 and modifyed the lp_build_create_jit_compiler_for_module() function to return false for 3.6 and newer which effectively disables the gallivm functionality. I realize this is overkill, but I could not come up with a simple solution to fix the build. Also, since 3.6 will be the first release without the old JIT, it would be really great if we could move gallivm to use the C API only for accessing MCJIT. There is still time before the 3.6 release to extend the C API in case it is missing some functionality that is required by gallivm. This fix isn't enough: make[4]: Entering directory '/build/mesa-git/src/mesa/src/gallium/auxiliary' GEN indices/u_indices_gen.c GEN indices/u_unfilled_gen.c GEN util/u_format_table.c CC draw/draw_llvm.lo CC draw/draw_llvm_sample.lo CC draw/draw_vs_llvm.lo CC draw/draw_pt_fetch_shade_pipeline_llvm.lo CXX gallivm/lp_bld_debug.lo CXX gallivm/lp_bld_misc.lo gallivm/lp_bld_misc.cpp:58:51: fatal error: llvm/ExecutionEngine/JITMemoryManager.h: No such file or directory #include llvm/ExecutionEngine/JITMemoryManager.h ^ compilation terminated. Makefile:1705: recipe for target 'gallivm/lp_bld_misc.lo' failed -- Laurent Carlier http://www.archlinux.org signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/14] i965/compaction: Reduce size of compacted_counts[] array.
On Tue, Sep 23, 2014 at 12:50 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner matts...@gmail.com wrote:
The array was previously indexed in units of brw_compact_inst (8-bytes),
but before compaction all instructions are uncompacted, so every odd
element was unused.
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 59
+++---
1 file changed, 37 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index c291f96..acce663 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
@@ -1033,20 +1033,32 @@ static void
update_uip_jip(struct brw_context *brw, brw_inst *insn,
int this_old_ip, int *compacted_counts)
{
- int scale = brw-gen = 8 ? sizeof(brw_compact_inst) : 1;
-
- int32_t jip = brw_inst_jip(brw, insn) / scale;
- jip -= compacted_between(this_old_ip, this_old_ip + jip,
compacted_counts);
- brw_inst_set_jip(brw, insn, jip * scale);
+ /* JIP and UIP are in units of:
+*- bytes on Gen8+; and
+*- compacted instructions on Gen6+.
+*/
+ int32_t jip = brw_inst_jip(brw, insn);
+ int32_t jip_compacted = jip / (brw-gen = 8 ?
sizeof(brw_compact_inst) : 1);
+ int32_t jip_uncompacted = jip / (brw-gen = 8 ? sizeof(brw_inst) :
2);
+ jip_compacted -= compacted_between(this_old_ip,
+ this_old_ip + jip_uncompacted,
+ compacted_counts);
Is this correct on gen = 8? It seems as if you would be missing a factor
of sizeof(brw_compact_inst). In general, this and the hunk below it seem
very fragile. Can we do these calculations without the gen = 8 specific
stuff and then do the factor of 8 at the end?
Not in a way I can see if we want to use the same array indexing on
all platforms (doing otherwise seems awful). The code is complicated
because the JIP and UIP are stored in different units on Gen8+. I
think immediately converting into common units of
compacted-instructions and uncompacted-instructions is the simplest
thing to do.
Unless I've misunderstood your feedback?
Also, the line below your comment converts the units of
compacted-instructions back into the hardware format:
+ brw_inst_set_jip(brw, insn,
+jip_compacted * (brw-gen = 8 ? sizeof(brw_inst) :
1));
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove EXT suffix from FBO error messages
Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix uniform location count used for glsl types
On Wed, Aug 27, 2014 at 4:12 AM, Tapani Pälli tapani.pa...@intel.com wrote: Patch fixes the slot count used by vector types and adds 1 slot to be used by image and sampler types. Signed-off-by: Tapani Pälli tapani.pa...@intel.com https://bugs.freedesktop.org/show_bug.cgi?id=82921 Prefix with Bugzilla: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
Interesting, I didn't know about that. Nevermind. st/mesa indeed sets it to 6.
Marek
On Wed, Sep 24, 2014 at 6:26 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context *st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true in core mesa of course (similar to 1d
array textures having height and so on) due to OpenGL weirdness for
historical reasons.
Roland
Am 24.09.2014 19:19, schrieb Marek Olšák:
Interesting, I didn't know about that. Nevermind. st/mesa indeed sets it to 6.
Marek
On Wed, Sep 24, 2014 at 6:26 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D84145k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=5599aec76e1694c8ec71dcfe6209603bf8b152884c942363fd84e9d56edaaa72
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context *st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=da68def8d99a0b8cd601334ed2b794d24bcb8e278d84e5a8aa06cc21afc5967d
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH 05/14] i965/compaction: Make src_offset local to the for loop.
On 08/28/2014 08:10 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 5617947..dd32175 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
@@ -737,6 +737,8 @@ brw_try_compact_instruction(struct brw_context *brw,
brw_compact_inst *dst,
{
brw_compact_inst temp;
+ assert(brw_inst_cmpt_control(brw, src) == 0);
+
if (brw_inst_opcode(brw, src) == BRW_OPCODE_IF ||
brw_inst_opcode(brw, src) == BRW_OPCODE_ELSE ||
brw_inst_opcode(brw, src) == BRW_OPCODE_ENDIF ||
@@ -1105,10 +1107,10 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
if (brw-gen 6)
return;
- int src_offset;
int offset = 0;
int compacted_count = 0;
- for (src_offset = 0; src_offset p-next_insn_offset - start_offset;) {
+ for (int src_offset = 0; src_offset p-next_insn_offset - start_offset;
+src_offset += sizeof(brw_inst)) {
brw_inst *src = store + src_offset;
void *dst = store + offset;
@@ -1117,8 +1119,7 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
brw_inst saved = *src;
- if (!brw_inst_cmpt_control(brw, src)
- brw_try_compact_instruction(brw, dst, src)) {
+ if (brw_try_compact_instruction(brw, dst, src)) {
compacted_count++;
if (INTEL_DEBUG) {
@@ -1130,10 +1131,7 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
}
offset += 8;
- src_offset += 16;
} else {
- int size = brw_inst_cmpt_control(brw, src) ? 8 : 16;
-
/* It appears that the end of thread SEND instruction needs to be
* aligned, or the GPU hangs.
*/
@@ -1154,10 +1152,9 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
* place.
*/
if (offset != src_offset) {
-memmove(dst, src, size);
+memmove(dst, src, sizeof(brw_inst));
}
- offset += size;
- src_offset += size;
+ offset += sizeof(brw_inst);
Sometimes this would increment src_offset by 8 and sometimes by 16. Now
src_offset is always incremented by sizeof(brw_inst). I'm not grokking
it enough to know if this is the same issue that Ken and Jason mentioned.
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/14] i965: Add BRW_OPCODE_NENOP for G45.
There are a bunch of other places that do special things for
BRW_OPCODE_NOP. Do any of those also need changes?
On 08/28/2014 08:10 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_disasm.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 0ef43e9..251f5b7 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -847,6 +847,7 @@ enum opcode {
BRW_OPCODE_PLN = 90, /** G45+ */
BRW_OPCODE_MAD = 91, /** Gen6+ */
BRW_OPCODE_LRP = 92, /** Gen6+ */
+ BRW_OPCODE_NENOP =125, /** G45 only */
BRW_OPCODE_NOP = 126,
/* These are compiler backend opcodes that get translated into other
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers/dri/i965/brw_disasm.c
index 5a56591..a729d11 100644
--- a/src/mesa/drivers/dri/i965/brw_disasm.c
+++ b/src/mesa/drivers/dri/i965/brw_disasm.c
@@ -84,6 +84,7 @@ const struct opcode_desc opcode_descs[128] = {
[BRW_OPCODE_SEND] = { .name = send,.nsrc = 1, .ndst = 1 },
[BRW_OPCODE_SENDC]= { .name = sendc, .nsrc = 1, .ndst = 1 },
[BRW_OPCODE_NOP] = { .name = nop, .nsrc = 0, .ndst = 0 },
+ [BRW_OPCODE_NENOP]= { .name = nenop, .nsrc = 0, .ndst = 0 },
[BRW_OPCODE_JMPI] = { .name = jmpi,.nsrc = 0, .ndst = 0 },
[BRW_OPCODE_IF] = { .name = if, .nsrc = 2, .ndst = 0 },
[BRW_OPCODE_IFF] = { .name = iff, .nsrc = 2, .ndst = 1 },
@@ -1225,7 +1226,7 @@ brw_disassemble_inst(FILE *file, struct brw_context
*brw, brw_inst *inst,
}
}
- if (opcode != BRW_OPCODE_NOP) {
+ if (opcode != BRW_OPCODE_NOP opcode != BRW_OPCODE_NENOP) {
string(file, ();
err |= control(file, execution size, exec_size,
brw_inst_exec_size(brw, inst), NULL);
@@ -1509,7 +1510,7 @@ brw_disassemble_inst(FILE *file, struct brw_context
*brw, brw_inst *inst,
}
}
pad(file, 64);
- if (opcode != BRW_OPCODE_NOP) {
+ if (opcode != BRW_OPCODE_NOP opcode != BRW_OPCODE_NENOP) {
string(file, {);
space = 1;
err |= control(file, access mode, access_mode,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/14] i965/compaction: Add support for G45.
On 08/28/2014 08:10 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 39
++
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 5008ba6..9c23d55 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
@@ -23,12 +23,12 @@
/** @file brw_eu_compact.c
*
- * Instruction compaction is a feature of gm45 and newer hardware that allows
+ * Instruction compaction is a feature of G45 and newer hardware that allows
* for a smaller instruction encoding.
*
* The instruction cache is on the order of 32KB, and many programs generate
* far more instructions than that. The instruction cache is built to barely
- * keep up with instruction dispatch abaility in cache hit cases -- L1
+ * keep up with instruction dispatch ability in cache hit cases -- L1
* instruction cache misses that still hit in the next level could limit
* throughput by around 50%.
*
@@ -1207,14 +1207,15 @@ static void
update_gen4_jump_count(struct brw_context *brw, brw_inst *insn,
int this_old_ip, int *compacted_counts)
{
- assert(brw-gen == 5);
+ assert(brw-gen == 5 || brw-is_g4x);
/* Jump Count is in units of:
+*- uncompacted instructions on G45; and
*- compacted instructions on Gen5.
*/
int jump_count = brw_inst_gen4_jump_count(brw, insn);
- int jump_count_compacted = jump_count;
- int jump_count_uncompacted = jump_count / 2;
+ int jump_count_compacted = jump_count * (brw-is_g4x ? 2 : 1);
+ int jump_count_uncompacted = jump_count / (brw-is_g4x ? 1 : 2);
int target_old_ip = this_old_ip + jump_count_uncompacted;
@@ -1222,7 +1223,8 @@ update_gen4_jump_count(struct brw_context *brw,
brw_inst *insn,
int target_compacted_count = compacted_counts[target_old_ip];
jump_count_compacted -= (target_compacted_count - this_compacted_count);
- brw_inst_set_gen4_jump_count(brw, insn, jump_count_compacted);
+ brw_inst_set_gen4_jump_count(brw, insn, jump_count_compacted /
+ (brw-is_g4x ? 2 : 1));
}
void
@@ -1265,13 +1267,14 @@ brw_init_compaction_tables(struct brw_context *brw)
src_index_table = gen6_src_index_table;
break;
case 5:
+ case 4:
control_index_table = g45_control_index_table;
datatype_table = g45_datatype_table;
subreg_table = g45_subreg_table;
src_index_table = g45_src_index_table;
break;
The check a couple hunks below prevents us from getting here on GEN4?
default:
- return;
+ unreachable(unknown generation);
}
}
@@ -1282,7 +1285,8 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
struct brw_context *brw = p-brw;
void *store = p-store + start_offset / 16;
/* For an instruction at byte offset 16*i before compaction, this is the
-* number of compacted instructions that preceded it.
+* number of compacted instructions minus the number of padding NOP/NENOPs
+* that preceded it.
*/
int compacted_counts[(p-next_insn_offset - start_offset) /
sizeof(brw_inst)];
/* For an instruction at byte offset 8*i after compaction, this was its IP
@@ -1290,7 +1294,7 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
*/
int old_ip[(p-next_insn_offset - start_offset) /
sizeof(brw_compact_inst)];
- if (brw-gen == 4)
+ if (brw-gen == 4 !brw-is_g4x)
return;
int offset = 0;
@@ -1319,17 +1323,22 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
offset += sizeof(brw_compact_inst);
} else {
/* It appears that the end of thread SEND instruction needs to be
- * aligned, or the GPU hangs.
+ * aligned, or the GPU hangs. All uncompacted instructions need to
be
+ * aligned on G45.
*/
- if ((brw_inst_opcode(brw, src) == BRW_OPCODE_SEND ||
- brw_inst_opcode(brw, src) == BRW_OPCODE_SENDC)
- brw_inst_eot(brw, src)
- (offset sizeof(brw_compact_inst)) != 0) {
+ if ((offset sizeof(brw_compact_inst)) != 0
+ (((brw_inst_opcode(brw, src) == BRW_OPCODE_SEND ||
+brw_inst_opcode(brw, src) == BRW_OPCODE_SENDC)
+ brw_inst_eot(brw, src)) ||
+ brw-is_g4x)) {
brw_compact_inst *align = store + offset;
memset(align, 0, sizeof(*align));
-brw_compact_inst_set_opcode(align, BRW_OPCODE_NOP);
+brw_compact_inst_set_opcode(align, brw-is_g4x ?
BRW_OPCODE_NENOP :
+ BRW_OPCODE_NOP);
brw_compact_inst_set_cmpt_control(align, true);
[Mesa-dev] [PATCH v2 2/6] st/va: skeleton VAAPI state tracker
From: Christian König christian.koe...@amd.com
This patch adds a skeleton VA-API state tracker,
which is filled with live in the subsequent patches.
v2: fixes in configure.ac and va state_tracker Makefile.am
Signed-off-by: Christian König christian.koe...@amd.com
Signed-off-by: Leo Liu leo@amd.com
---
configure.ac | 38 ++-
src/gallium/Makefile.am| 4 +
src/gallium/state_trackers/va/Makefile.am | 36 ++
src/gallium/state_trackers/va/Makefile.sources | 10 ++
src/gallium/state_trackers/va/buffer.c | 87 ++
src/gallium/state_trackers/va/config.c | 91 +++
src/gallium/state_trackers/va/context.c| 151 +
src/gallium/state_trackers/va/display.c| 61 ++
src/gallium/state_trackers/va/image.c | 106 +
src/gallium/state_trackers/va/picture.c| 56 +
src/gallium/state_trackers/va/subpicture.c | 115 +++
src/gallium/state_trackers/va/surface.c| 111 ++
src/gallium/state_trackers/va/va_private.h | 116 +++
src/gallium/targets/va/Makefile.am | 90 +++
src/gallium/targets/va/target.c| 1 +
src/gallium/targets/va/va.sym | 6 +
16 files changed, 1077 insertions(+), 2 deletions(-)
create mode 100644 src/gallium/state_trackers/va/Makefile.am
create mode 100644 src/gallium/state_trackers/va/Makefile.sources
create mode 100644 src/gallium/state_trackers/va/buffer.c
create mode 100644 src/gallium/state_trackers/va/config.c
create mode 100644 src/gallium/state_trackers/va/context.c
create mode 100644 src/gallium/state_trackers/va/display.c
create mode 100644 src/gallium/state_trackers/va/image.c
create mode 100644 src/gallium/state_trackers/va/picture.c
create mode 100644 src/gallium/state_trackers/va/subpicture.c
create mode 100644 src/gallium/state_trackers/va/surface.c
create mode 100644 src/gallium/state_trackers/va/va_private.h
create mode 100644 src/gallium/targets/va/Makefile.am
create mode 100644 src/gallium/targets/va/target.c
create mode 100644 src/gallium/targets/va/va.sym
diff --git a/configure.ac b/configure.ac
index 87c616b..5d363d7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -661,6 +661,11 @@ AC_ARG_ENABLE([omx],
[enable OpenMAX library @:@default=no@:@])],
[enable_omx=$enableval],
[enable_omx=no])
+AC_ARG_ENABLE([va],
+ [AS_HELP_STRING([--enable-va],
+ [enable va library @:@default=auto@:@])],
+ [enable_va=$enableval],
+ [enable_va=auto])
AC_ARG_ENABLE([opencl],
[AS_HELP_STRING([--enable-opencl],
[enable OpenCL library @:@default=no@:@])],
@@ -732,6 +737,7 @@ if test x$enable_opengl = xno -a \
x$enable_xvmc = xno -a \
x$enable_vdpau = xno -a \
x$enable_omx = xno -a \
+x$enable_va = xno -a \
x$enable_opencl = xno; then
AC_MSG_ERROR([at least one API should be enabled])
fi
@@ -1411,6 +1417,10 @@ if test -n $with_gallium_drivers -a
x$with_gallium_drivers != xswrast; then
if test x$enable_omx = xauto; then
PKG_CHECK_EXISTS([libomxil-bellagio], [enable_omx=yes], [enable_omx=no])
fi
+
+if test x$enable_va = xauto; then
+PKG_CHECK_EXISTS([libva], [enable_va=yes], [enable_va=no])
+fi
fi
if test x$enable_xvmc = xyes; then
@@ -1435,6 +1445,12 @@ if test x$enable_omx = xyes; then
fi
AM_CONDITIONAL(HAVE_ST_OMX, test x$enable_omx = xyes)
+if test x$enable_va = xyes; then
+PKG_CHECK_MODULES([VA], [libva = 0.35.0 x11-xcb xcb-dri2 =
$XCBDRI2_REQUIRED])
+GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS va
+fi
+AM_CONDITIONAL(HAVE_ST_VA, test x$enable_va = xyes)
+
dnl
dnl OpenCL configuration
dnl
@@ -1814,6 +1830,19 @@ AC_ARG_WITH([omx-libdir],
[OMX_LIB_INSTALL_DIR=$OMX_LIB_INSTALL_DIR_DEFAULT])
AC_SUBST([OMX_LIB_INSTALL_DIR])
+dnl Directory for VA libs
+VA_LIB_INSTALL_DIR_DEFAULT=''
+if test x$enable_va = xyes; then
+VA_LIB_INSTALL_DIR_DEFAULT=`$PKG_CONFIG libva --variable=driverdir`
+fi
+
+AC_ARG_WITH([va-libdir],
+[AS_HELP_STRING([--with-va-libdir=DIR],
+[directory for the VA libraries])],
+[VA_LIB_INSTALL_DIR=$withval],
+[VA_LIB_INSTALL_DIR=$VA_LIB_INSTALL_DIR_DEFAULT])
+AC_SUBST([VA_LIB_INSTALL_DIR])
+
dnl Directory for OpenCL libs
AC_ARG_WITH([opencl-libdir],
[AS_HELP_STRING([--with-opencl-libdir=DIR],
@@ -1846,6 +1875,9 @@ gallium_check_st() {
if test x$enable_omx = xyes test x$7 != x; then
GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS $7
fi
+if test x$enable_va = xyes test x$7 != x; then
+ GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS $7
+fi
}
gallium_require_llvm() {
@@ -1951,7 +1983,7 @@ if test -n $with_gallium_drivers; then
if test x$enable_opencl = xyes; then
LLVM_COMPONENTS=${LLVM_COMPONENTS} bitreader
Re: [Mesa-dev] [PATCH 00/14] i965: Instruction compaction improvements
Patches 1 through 4, 6, and 14 are Reviewed-by: Ian Romanick ian.d.roman...@intel.com Assuming sufficient pigliting, patch 9 is Acked-by: Ian Romanick ian.d.roman...@intel.com I sent a couple minor questions on a few others. The remaining will be left to more capable hands. On 08/28/2014 08:10 PM, Matt Turner wrote: This series adds instruction compaction support for G45 and Gen5 and enables compaction of control flow instructions. Available from git://people.freedesktop.org/~mattst88/mesa compaction-improvements [PATCH 01/14] i965: Set JumpCount, not JIP, on ENDIF on Gen 6. Benign bug fix. [PATCH 02/14] i965/sf: Disable instruction compaction. Preparation for compaction on gens using SF programs. [PATCH 03/14] i965/compaction: Rework 3-src compaction logic. [PATCH 04/14] i965/compaction: Don't set UIP on ELSE on Gen 8. Small clean ups/bug fixes. [PATCH 05/14] i965/compaction: Make src_offset local to the for loop. [PATCH 06/14] i965/compaction: Increment offset in for loop. [PATCH 07/14] i965/compaction: Use sizeof brw_inst/brw_compact_inst. Clean ups. [PATCH 08/14] i965/compaction: Reduce size of compacted_counts[] Memory usage reduction. [PATCH 09/14] i965/compaction: Add support for Gen5. [PATCH 10/14] i965: Add BRW_OPCODE_NENOP for G45. [PATCH 11/14] i965/compaction: Add support for G45. New compaction support for old Gens. [PATCH 12/14] i965/compaction: Support compaction of control flow [PATCH 13/14] i965: Emit ELSE/ENDIF JIP with type D on Gen 7. New compaction support for control flow (really, ELSE and ENDIF). [PATCH 14/14] i965/compaction: Document instruction compaction Brain dump while all of this is fresh. ___ 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 05/14] i965/compaction: Make src_offset local to the for loop.
On Wed, Sep 24, 2014 at 10:36 AM, Ian Romanick i...@freedesktop.org wrote:
On 08/28/2014 08:10 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 5617947..dd32175 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
@@ -737,6 +737,8 @@ brw_try_compact_instruction(struct brw_context *brw,
brw_compact_inst *dst,
{
brw_compact_inst temp;
+ assert(brw_inst_cmpt_control(brw, src) == 0);
+
if (brw_inst_opcode(brw, src) == BRW_OPCODE_IF ||
brw_inst_opcode(brw, src) == BRW_OPCODE_ELSE ||
brw_inst_opcode(brw, src) == BRW_OPCODE_ENDIF ||
@@ -1105,10 +1107,10 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
if (brw-gen 6)
return;
- int src_offset;
int offset = 0;
int compacted_count = 0;
- for (src_offset = 0; src_offset p-next_insn_offset - start_offset;) {
+ for (int src_offset = 0; src_offset p-next_insn_offset - start_offset;
+src_offset += sizeof(brw_inst)) {
brw_inst *src = store + src_offset;
void *dst = store + offset;
@@ -1117,8 +1119,7 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
brw_inst saved = *src;
- if (!brw_inst_cmpt_control(brw, src)
- brw_try_compact_instruction(brw, dst, src)) {
+ if (brw_try_compact_instruction(brw, dst, src)) {
compacted_count++;
if (INTEL_DEBUG) {
@@ -1130,10 +1131,7 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
}
offset += 8;
- src_offset += 16;
} else {
- int size = brw_inst_cmpt_control(brw, src) ? 8 : 16;
-
/* It appears that the end of thread SEND instruction needs to be
* aligned, or the GPU hangs.
*/
@@ -1154,10 +1152,9 @@ brw_compact_instructions(struct brw_compile *p, int
start_offset,
* place.
*/
if (offset != src_offset) {
-memmove(dst, src, size);
+memmove(dst, src, sizeof(brw_inst));
}
- offset += size;
- src_offset += size;
+ offset += sizeof(brw_inst);
Sometimes this would increment src_offset by 8 and sometimes by 16. Now
src_offset is always incremented by sizeof(brw_inst). I'm not grokking
it enough to know if this is the same issue that Ken and Jason mentioned.
Actually, thanks for pointing that out. *That's* why the hunks that
look unrelated are in this patch -- they're actually related.
We used to generate SIMD8 instructions, compact SIMD8 instructions,
generate SIMD16 instructions, and then recompact the whole program, so
we'd pass over the previously compacted SIMD8 instructions and not
want to touch them again. I fixed this so that we only attempt to
compact the instructions we've just generated, so we should never see
a compacted instruction in the source buffer read by
brw_compact_instructions().
So that's what the assert and the removal of the
!brw_inst_cmpt_control(brw, src) check is about.
With that knowledge, we can simplify the src_offset increment, since
we know we'll never see a compacted instruction.
In any case, I've already split the patch so I'll leave it split.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/14] i965: Add BRW_OPCODE_NENOP for G45.
On Wed, Sep 24, 2014 at 10:41 AM, Ian Romanick i...@freedesktop.org wrote: There are a bunch of other places that do special things for BRW_OPCODE_NOP. Do any of those also need changes? There's really not many. The main use of NOP is when we change the opcode of an instruction we want to remove to NOP, and then make a separate pass after the optimization to remove NOP instructions (to avoid removing things and changing instruction IPs which are used for liveness checks). Other than that, there's not really anything else. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/14] i965/compaction: Add support for G45.
On Wed, Sep 24, 2014 at 10:43 AM, Ian Romanick i...@freedesktop.org wrote:
On 08/28/2014 08:10 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 39
++
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 5008ba6..9c23d55 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
@@ -23,12 +23,12 @@
/** @file brw_eu_compact.c
*
- * Instruction compaction is a feature of gm45 and newer hardware that
allows
+ * Instruction compaction is a feature of G45 and newer hardware that allows
* for a smaller instruction encoding.
*
* The instruction cache is on the order of 32KB, and many programs generate
* far more instructions than that. The instruction cache is built to
barely
- * keep up with instruction dispatch abaility in cache hit cases -- L1
+ * keep up with instruction dispatch ability in cache hit cases -- L1
* instruction cache misses that still hit in the next level could limit
* throughput by around 50%.
*
@@ -1207,14 +1207,15 @@ static void
update_gen4_jump_count(struct brw_context *brw, brw_inst *insn,
int this_old_ip, int *compacted_counts)
{
- assert(brw-gen == 5);
+ assert(brw-gen == 5 || brw-is_g4x);
/* Jump Count is in units of:
+*- uncompacted instructions on G45; and
*- compacted instructions on Gen5.
*/
int jump_count = brw_inst_gen4_jump_count(brw, insn);
- int jump_count_compacted = jump_count;
- int jump_count_uncompacted = jump_count / 2;
+ int jump_count_compacted = jump_count * (brw-is_g4x ? 2 : 1);
+ int jump_count_uncompacted = jump_count / (brw-is_g4x ? 1 : 2);
int target_old_ip = this_old_ip + jump_count_uncompacted;
@@ -1222,7 +1223,8 @@ update_gen4_jump_count(struct brw_context *brw,
brw_inst *insn,
int target_compacted_count = compacted_counts[target_old_ip];
jump_count_compacted -= (target_compacted_count - this_compacted_count);
- brw_inst_set_gen4_jump_count(brw, insn, jump_count_compacted);
+ brw_inst_set_gen4_jump_count(brw, insn, jump_count_compacted /
+ (brw-is_g4x ? 2 : 1));
}
void
@@ -1265,13 +1267,14 @@ brw_init_compaction_tables(struct brw_context *brw)
src_index_table = gen6_src_index_table;
break;
case 5:
+ case 4:
control_index_table = g45_control_index_table;
datatype_table = g45_datatype_table;
subreg_table = g45_subreg_table;
src_index_table = g45_src_index_table;
break;
The check a couple hunks below prevents us from getting here on GEN4?
Right, there's no instruction compaction on the original 965. No harm
in setting the table pointers on it though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
Marek/Roland -- do either of those comments count as a R-b? I'd like
to push this out tonight, pending a full piglit run.
On Wed, Sep 24, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com wrote:
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true in core mesa of course (similar to 1d
array textures having height and so on) due to OpenGL weirdness for
historical reasons.
Roland
Am 24.09.2014 19:19, schrieb Marek Olšák:
Interesting, I didn't know about that. Nevermind. st/mesa indeed sets it to
6.
Marek
On Wed, Sep 24, 2014 at 6:26 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D84145k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=5599aec76e1694c8ec71dcfe6209603bf8b152884c942363fd84e9d56edaaa72
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object
*stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context
*st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=da68def8d99a0b8cd601334ed2b794d24bcb8e278d84e5a8aa06cc21afc5967d
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH] glsl: Structures must have same name to be considered same type.
On Mon, Sep 22, 2014 at 5:11 AM, Tapani Pälli tapani.pa...@intel.com wrote:
From: Kalyan Kondapally kalyan.kondapa...@intel.com
According to GLSL(4.2) and GLSL-ES (1.0, 3.0) spec, Structures must
have the same name to be considered same type. We currently ignore
the name check while checking if two records are same. This patch
fixes this.
Patch fixes failing tests in WebGL conformance test
'shaders-with-uniform-structs' when running Chrome on OpenGL ES.
v2: Do not force name comparison with unnamed types (Tapani)
Signed-off-by: Kalyan Kondapally kalyan.kondapa...@intel.com
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83934
---
src/glsl/glsl_types.cpp | 14 ++
src/glsl/glsl_types.h | 8
2 files changed, 22 insertions(+)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 66e9b13..4f8bb62 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -490,6 +490,20 @@ glsl_type::record_compare(const glsl_type *b) const
if (this-interface_packing != b-interface_packing)
return false;
+ /* From the GLSL 4.20 specification (Sec 4.2):
+*
+* Structures must have the same name, sequence of type names, and
+* type definitions, and field names to be considered the same type.
+*
+* GLSL ES behaves the same (Ver 1.00 Sec 4.2.4, Ver 3.00 Sec 4.2.5).
+*
+* Note that we cannot force type name check when comparing unnamed
+* structure types, these have a unique name assigned during parsing.
+*/
+ if (!(this-is_anonymous() b-is_anonymous()))
+ if (strcmp(this-name, b-name) != 0)
+ return false;
+
for (unsigned i = 0; i this-length; i++) {
if (this-fields.structure[i].type != b-fields.structure[i].type)
return false;
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index d545533..9693c80 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -486,6 +486,14 @@ struct glsl_type {
}
/**
+* Query if a type is unnamed/anonymous (named by the parser)
+*/
+ bool is_anonymous() const
+ {
+ return !strncmp(name, #anon, 5);
+ }
+
+ /**
* Get the type stripped of any arrays
*
* \return
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
Do we have piglit test for this?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Structures must have same name to be considered same type.
On Mon, Sep 22, 2014 at 5:11 AM, Tapani Pälli tapani.pa...@intel.com wrote:
From: Kalyan Kondapally kalyan.kondapa...@intel.com
According to GLSL(4.2) and GLSL-ES (1.0, 3.0) spec, Structures must
have the same name to be considered same type. We currently ignore
the name check while checking if two records are same. This patch
fixes this.
Patch fixes failing tests in WebGL conformance test
'shaders-with-uniform-structs' when running Chrome on OpenGL ES.
v2: Do not force name comparison with unnamed types (Tapani)
Signed-off-by: Kalyan Kondapally kalyan.kondapa...@intel.com
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83934
---
src/glsl/glsl_types.cpp | 14 ++
src/glsl/glsl_types.h | 8
2 files changed, 22 insertions(+)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 66e9b13..4f8bb62 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -490,6 +490,20 @@ glsl_type::record_compare(const glsl_type *b) const
if (this-interface_packing != b-interface_packing)
return false;
+ /* From the GLSL 4.20 specification (Sec 4.2):
+*
+* Structures must have the same name, sequence of type names, and
+* type definitions, and field names to be considered the same type.
+*
+* GLSL ES behaves the same (Ver 1.00 Sec 4.2.4, Ver 3.00 Sec 4.2.5).
+*
+* Note that we cannot force type name check when comparing unnamed
+* structure types, these have a unique name assigned during parsing.
+*/
+ if (!(this-is_anonymous() b-is_anonymous()))
This would be clearer as
if (!this-is_anonymous() !b-is_anonymous())
but you don't even need to check both of them. If
this-is_anonymous(), it doesn't matter whether b-is_anonymous().
That is to say, isn't
if (!this-is_anonymous())
if (strcmp(this-name, b-name) != 0)
return false;
sufficient?
Assuming that logic is right,
Reviewed-by: Matt Turner matts...@gmail.com
+ if (strcmp(this-name, b-name) != 0)
+ return false;
+
for (unsigned i = 0; i this-length; i++) {
if (this-fields.structure[i].type != b-fields.structure[i].type)
return false;
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index d545533..9693c80 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -486,6 +486,14 @@ struct glsl_type {
}
/**
+* Query if a type is unnamed/anonymous (named by the parser)
+*/
+ bool is_anonymous() const
+ {
+ return !strncmp(name, #anon, 5);
+ }
+
+ /**
* Get the type stripped of any arrays
*
* \return
--
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] gallivm: Disable gallivm to fix build with LLVM 3.6
Hi,
On Wednesday, September 24, 2014 12:42:24 Jose Fonseca wrote:
We're not the only one with similar needs. Webkit has similar needs.
Though they opted by using LLVMCreateSimpleMCJITMemoryManager
https://trac.webkit.org/browser/trunk/Tools/ReducedFTL/ReducedFTL.c#L321
and implemeting the memory manager themselves.
We could do the same. We even have the code for it in
src/gallium/auxiliary/rtasm/rtasm_execmem.*( And if we add a mutex
we could make this thread safe too, without needing multiple jit
managers around)
The other alternative would be to have another function besides
LLVMCreateSimpleMCJITMemoryManager that would create a standard
LLVMMCJITMemoryManagerRef.
That said, the way we use these things are still a bit in flux. Mathias
has some pending patches. BTW, Mathis, should I submit your patches
for making llvmpipe thread safe? Also, what are your thoughts on this
issue?
Ok, I have updated the patches to keep that compiling with both versions
and still be thread safe with old enough llvm.
These updated ones are attached to this mail.
I don't mind if you want to push them now.
I expect that its introducing less potential conflicts on your
site if you can coordinate when these get applied?
And thanks for the heads up!!
With respect to that shader memory manager, I have just tried to
make this recently introduced piece of code work with multiple threads in
action.
So, I do not need to keep this one. The time before that shader memory manager
was even easier for thread safety and the introduction of that one introduced
additional complications.
So every simple algorithm there is fine as long as the appropriate locks
are there to make them thread safe.
I only had a short look into your proposal, both variants look fine to me.
Thanks
MathiasFrom ae29a897c2b330408cdffd82c6b326121d1a6681 Mon Sep 17 00:00:00 2001
Message-Id: ae29a897c2b330408cdffd82c6b326121d1a6681.1411584609.git.mathias.froehl...@gmx.net
In-Reply-To: b82942217cba1a87df430e688e5a75491a205917.1411584609.git.mathias.froehl...@gmx.net
References: b82942217cba1a87df430e688e5a75491a205917.1411584609.git.mathias.froehl...@gmx.net
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@gmx.net
Date: Sun, 21 Sep 2014 08:54:00 +0200
Subject: [PATCH 3/3] llvmpipe: Reuse llvmpipes LLVMContext in the draw
context.
Reuse the LLVMContext already allocated in llvmpipe_context
for draw_llvm if ppossible. This should decrease the memory
footprint of an llvmpipe context.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/gallium/auxiliary/draw/draw_context.c | 18 ++
src/gallium/auxiliary/draw/draw_context.h | 5 +
src/gallium/auxiliary/draw/draw_llvm.c| 11 ---
src/gallium/auxiliary/draw/draw_llvm.h| 3 ++-
src/gallium/drivers/llvmpipe/lp_context.c | 3 ++-
5 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c b/src/gallium/auxiliary/draw/draw_context.c
index 001446f..18af6b5 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -81,7 +81,8 @@ draw_get_option_use_llvm(void)
* Create new draw module context with gallivm state for LLVM JIT.
*/
static struct draw_context *
-draw_create_context(struct pipe_context *pipe, boolean try_llvm)
+draw_create_context(struct pipe_context *pipe, void *context,
+boolean try_llvm)
{
struct draw_context *draw = CALLOC_STRUCT( draw_context );
if (draw == NULL)
@@ -92,7 +93,7 @@ draw_create_context(struct pipe_context *pipe, boolean try_llvm)
#if HAVE_LLVM
if (try_llvm draw_get_option_use_llvm()) {
- draw-llvm = draw_llvm_create(draw);
+ draw-llvm = draw_llvm_create(draw, (LLVMContextRef)context);
if (!draw-llvm)
goto err_destroy;
}
@@ -122,17 +123,26 @@ err_out:
struct draw_context *
draw_create(struct pipe_context *pipe)
{
- return draw_create_context(pipe, TRUE);
+ return draw_create_context(pipe, NULL, TRUE);
}
+#if HAVE_LLVM
+struct draw_context *
+draw_create_with_llvm_context(struct pipe_context *pipe,
+ void *context)
+{
+ return draw_create_context(pipe, context, TRUE);
+}
+#endif
+
/**
* Create a new draw context, without LLVM JIT.
*/
struct draw_context *
draw_create_no_llvm(struct pipe_context *pipe)
{
- return draw_create_context(pipe, FALSE);
+ return draw_create_context(pipe, NULL, FALSE);
}
diff --git a/src/gallium/auxiliary/draw/draw_context.h b/src/gallium/auxiliary/draw/draw_context.h
index 48549fe..a5a6df5 100644
--- a/src/gallium/auxiliary/draw/draw_context.h
+++ b/src/gallium/auxiliary/draw/draw_context.h
@@ -64,6 +64,11 @@ struct draw_so_target {
struct draw_context *draw_create( struct pipe_context *pipe );
+#if HAVE_LLVM
+struct draw_context *draw_create_with_llvm_context(struct pipe_context *pipe,
+
[Mesa-dev] [PATCH 02/16] i965/skl: Update 3DSTATE_SBE for Skylake.
From: Damien Lespiau damien.lesp...@intel.com
This commands has seen the addition of 2 dwords that allow to specify
which channels of which attributes need to be forwarded to the fragment
shader.
v2: Rebase forward a year (done by Ken).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 6 ++
src/mesa/drivers/dri/i965/gen8_sf_state.c | 30 --
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index b2216fe..aca78af 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1903,6 +1903,12 @@ enum brw_message_target {
/* DW12: attr 0-7 wrap shortest enables */
/* DW13: attr 8-16 wrap shortest enables */
+/* DW5-6: Attribute active components (gen9) */
+#define GEN9_SBE_ACTIVE_COMPONENT_NONE 0
+#define GEN9_SBE_ACTIVE_COMPONENT_XY 1
+#define GEN9_SBE_ACTIVE_COMPONENT_XYZ 2
+#define GEN9_SBE_ACTIVE_COMPONENT_XYZW 3
+
#define _3DSTATE_SBE_SWIZ 0x7851 /* GEN8+ */
#define _3DSTATE_RASTER 0x7850 /* GEN8+ */
diff --git a/src/mesa/drivers/dri/i965/gen8_sf_state.c
b/src/mesa/drivers/dri/i965/gen8_sf_state.c
index 4263eaf..05e5a2e 100644
--- a/src/mesa/drivers/dri/i965/gen8_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_sf_state.c
@@ -39,10 +39,13 @@ upload_sbe(struct brw_context *brw)
uint32_t urb_entry_read_length;
uint32_t point_sprite_enables;
uint32_t flat_enables;
+ int sbe_cmd_length;
uint32_t dw1 =
GEN7_SBE_SWIZZLE_ENABLE |
num_outputs GEN7_SBE_NUM_OUTPUTS_SHIFT;
+ uint32_t dw4 = 0;
+ uint32_t dw5 = 0;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
@@ -79,11 +82,34 @@ upload_sbe(struct brw_context *brw)
GEN8_SBE_FORCE_URB_ENTRY_READ_LENGTH |
GEN8_SBE_FORCE_URB_ENTRY_READ_OFFSET;
- BEGIN_BATCH(4);
- OUT_BATCH(_3DSTATE_SBE 16 | (4 - 2));
+ if (brw-gen == 8) {
+ sbe_cmd_length = 4;
+ } else {
+ sbe_cmd_length = 6;
+
+ /* prepare the active component dwords */
+ int input_index = 0;
+ for (int attr = 0; attr VARYING_SLOT_MAX; attr++) {
+ if (!(brw-fragment_program-Base.InputsRead BITFIELD64_BIT(attr)))
+continue;
+
+ if (input_index 16)
+dw4 |= (GEN9_SBE_ACTIVE_COMPONENT_XYZW (input_index 1));
+ else
+dw5 |= (GEN9_SBE_ACTIVE_COMPONENT_XYZW (input_index 1));
+
+ ++input_index;
+ }
+ }
+ BEGIN_BATCH(sbe_cmd_length);
+ OUT_BATCH(_3DSTATE_SBE 16 | (sbe_cmd_length - 2));
OUT_BATCH(dw1);
OUT_BATCH(point_sprite_enables);
OUT_BATCH(flat_enables);
+ if (sbe_cmd_length = 6) {
+ OUT_BATCH(dw4);
+ OUT_BATCH(dw5);
+ }
ADVANCE_BATCH();
BEGIN_BATCH(11);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/16] i965/skl: Use new MOCS for SKL
On Skylake, the MOCS bits are an index into a table of 63 different,
configurable cache configurations. As for previous GENs, we only care about
WB and WT, which are available in the documented default set. Define
SKL_MOCS_WB and SKL_MOCS_WT to the indices for those configucations and use
those for the Skylake MOCS values.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h| 6 ++
src/mesa/drivers/dri/i965/gen8_depth_state.c | 10 ++
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 8 +---
src/mesa/drivers/dri/i965/gen8_misc_state.c| 14 --
src/mesa/drivers/dri/i965/gen8_sol_state.c | 3 ++-
src/mesa/drivers/dri/i965/gen8_surface_state.c | 7 ---
6 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 39363c8..752f5d6 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2402,6 +2402,12 @@ enum brw_wm_barycentric_interp_mode {
#define BDW_MOCS_WB 0x78
#define BDW_MOCS_WT 0x58
+/* 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. */
+#define SKL_MOCS_WB 9
+#define SKL_MOCS_WT 5
+
#include intel_chipset.h
#endif
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 7c3bfe0..a0390f6 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -48,6 +48,8 @@ emit_depth_packets(struct brw_context *brw,
uint32_t lod,
uint32_t min_array_element)
{
+ uint32_t mocs_wb = brw-gen =9 ? SKL_MOCS_WB : BDW_MOCS_WB;
+
/* Skip repeated NULL depth/stencil emits (think 2D rendering). */
if (!depth_mt !stencil_mt brw-no_depth_or_stencil) {
assert(brw-hw_ctx);
@@ -73,7 +75,7 @@ emit_depth_packets(struct brw_context *brw,
OUT_BATCH(0);
}
OUT_BATCH(((width - 1) 4) | ((height - 1) 18) | lod);
- OUT_BATCH(((depth - 1) 21) | (min_array_element 10) | BDW_MOCS_WB);
+ OUT_BATCH(((depth - 1) 21) | (min_array_element 10) | mocs_wb);
OUT_BATCH(0);
OUT_BATCH(((depth - 1) 21) | (depth_mt ? depth_mt-qpitch 2 : 0));
ADVANCE_BATCH();
@@ -89,7 +91,7 @@ emit_depth_packets(struct brw_context *brw,
} else {
BEGIN_BATCH(5);
OUT_BATCH(GEN7_3DSTATE_HIER_DEPTH_BUFFER 16 | (5 - 2));
- OUT_BATCH((depth_mt-hiz_mt-pitch - 1) | BDW_MOCS_WB 25);
+ OUT_BATCH((depth_mt-hiz_mt-pitch - 1) | mocs_wb 25);
OUT_RELOC64(depth_mt-hiz_mt-bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
OUT_BATCH(depth_mt-hiz_mt-qpitch 2);
@@ -97,7 +99,7 @@ emit_depth_packets(struct brw_context *brw,
}
if (stencil_mt == NULL) {
- BEGIN_BATCH(5);
+ BEGIN_BATCH(5);
OUT_BATCH(GEN7_3DSTATE_STENCIL_BUFFER 16 | (5 - 2));
OUT_BATCH(0);
OUT_BATCH(0);
@@ -121,7 +123,7 @@ emit_depth_packets(struct brw_context *brw,
* page (which would imply that it does). Experiments with the hardware
* indicate that it does.
*/
- OUT_BATCH(HSW_STENCIL_ENABLED | BDW_MOCS_WB 22 |
+ OUT_BATCH(HSW_STENCIL_ENABLED | mocs_wb 22 |
(2 * stencil_mt-pitch - 1));
OUT_RELOC64(stencil_mt-bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
diff --git a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
index 8f0e515..bafdd6f 100644
--- a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
@@ -39,6 +39,7 @@ static void
gen8_emit_vertices(struct brw_context *brw)
{
struct gl_context *ctx = brw-ctx;
+ uint32_t mocs_wb = brw-gen =9 ? SKL_MOCS_WB : BDW_MOCS_WB;
brw_prepare_vertices(brw);
brw_prepare_shader_draw_parameters(brw);
@@ -119,7 +120,7 @@ gen8_emit_vertices(struct brw_context *brw)
dw0 |= i GEN6_VB0_INDEX_SHIFT;
dw0 |= GEN7_VB0_ADDRESS_MODIFYENABLE;
dw0 |= buffer-stride BRW_VB0_PITCH_SHIFT;
- dw0 |= BDW_MOCS_WB 16;
+ dw0 |= mocs_wb 16;
OUT_BATCH(dw0);
OUT_RELOC64(buffer-bo, I915_GEM_DOMAIN_VERTEX, 0, buffer-offset);
@@ -129,7 +130,7 @@ gen8_emit_vertices(struct brw_context *brw)
if (brw-vs.prog_data-uses_vertexid) {
OUT_BATCH(brw-vb.nr_buffers GEN6_VB0_INDEX_SHIFT |
GEN7_VB0_ADDRESS_MODIFYENABLE |
- BDW_MOCS_WB 16);
+ mocs_wb 16);
OUT_RELOC64(brw-draw.draw_params_bo, I915_GEM_DOMAIN_VERTEX, 0,
brw-draw.draw_params_offset);
OUT_BATCH(brw-draw.draw_params_bo-size);
@@ -242,13 +243,14 @@ static void
gen8_emit_index_buffer(struct brw_context
[Mesa-dev] [PATCH 08/16] i965/skl: Allocate 16 DWords for SURFACE_STATE on Skylake.
From: Kenneth Graunke kenn...@whitecape.org
Otherwise they overlap and horrible things happen. All the new DWords
are for fast color clear values, which we don't do yet.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c
b/src/mesa/drivers/dri/i965/gen8_surface_state.c
index f399029..1742012 100644
--- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
@@ -84,7 +84,7 @@ horizontal_alignment(struct intel_mipmap_tree *mt)
static uint32_t *
allocate_surface_state(const struct brw_context *brw, uint32_t *out_offset)
{
- int dwords = 13;
+ int dwords = brw-gen = 9 ? 16 : 13;
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
dwords * 4, 64, out_offset);
memset(surf, 0, dwords * 4);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/16] i965/skl: Implement workaround for VF Invalidate issue
From: Jordan Justen jordan.l.jus...@intel.com
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 71dc268..cd45af6 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -648,6 +648,15 @@ intel_batchbuffer_emit_mi_flush(struct brw_context *brw)
} else {
int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_WRITE_FLUSH;
if (brw-gen = 6) {
+ if (brw-gen == 9) {
+/* Hardware workaround: SKL
+ *
+ * Emit Pipe Control with all bits set to zero before emitting
+ * a Pipe Control with VF Cache Invalidate set.
+ */
+brw_emit_pipe_control_flush(brw, 0);
+ }
+
flags |= PIPE_CONTROL_INSTRUCTION_FLUSH |
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
PIPE_CONTROL_VF_CACHE_INVALIDATE |
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/16] i965/skl: Add fast clear resolve rect multipliers for SKL
SKL updates the resolve rectangle scaling factors again.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index b4e75a7..c8f2a14 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -643,11 +643,14 @@ get_resolve_rect(struct brw_context *brw,
* The scaledown factors in the table that follows are related to the
* alignment size returned by intel_get_non_msrt_mcs_alignment() by a
* multiplier. For IVB and HSW, we divide by two, for BDW we multiply
-* by 8 and 16.
+* by 8 and 16 and 8 and 8 for SKL.
*/
intel_get_non_msrt_mcs_alignment(brw, mt, x_align, y_align);
- if (brw-gen = 8) {
+ if (brw-gen = 9) {
+ x_scaledown = x_align * 8;
+ y_scaledown = y_align * 8;
+ } else if (brw-gen = 8) {
x_scaledown = x_align * 8;
y_scaledown = y_align * 16;
} else {
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/16] i965/bdw+: Remove depth stall workaround gen8 and up
As of BDW, this workaround is no longer necessary: WM HW will internally manage
the draining pipe and flushing of the caches when this commands is issued.
The PIPE_CONTROL restrictions are removed.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 2 --
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index a0390f6..0d2877d 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -56,8 +56,6 @@ emit_depth_packets(struct brw_context *brw,
return;
}
- intel_emit_depth_stall_flushes(brw);
-
/* _NEW_BUFFERS, _NEW_DEPTH, _NEW_STENCIL */
BEGIN_BATCH(8);
OUT_BATCH(GEN7_3DSTATE_DEPTH_BUFFER 16 | (8 - 2));
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index cd45af6..0bc35bf 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -535,7 +535,7 @@ brw_emit_pipe_control_write(struct brw_context *brw,
uint32_t flags,
void
intel_emit_depth_stall_flushes(struct brw_context *brw)
{
- assert(brw-gen = 6 brw-gen = 8);
+ assert(brw-gen = 6 brw-gen = 7);
brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_STALL);
brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_CACHE_FLUSH);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/16] i965/skl: Always emit 3DSTATE_BINDING_TABLE_POINTERS_* on Skylake.
From: Kenneth Graunke kenn...@whitecape.org
On SKL, 3DSTATE_CONSTANT_* command is not committed until we give
the corresponding 3DSTATE_BINDING_TABLE_POINTERS_* command. If we
fail to do so, the constant buffers wont be read and push constants
will be wrong.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_binding_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c
b/src/mesa/drivers/dri/i965/brw_binding_tables.c
index 709cb9c..cb50d3b 100644
--- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
+++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
@@ -61,7 +61,7 @@ brw_upload_binding_table(struct brw_context *brw,
if (prog_data-binding_table.size_bytes == 0) {
/* There are no surfaces; skip making the binding table altogether. */
- if (stage_state-bind_bo_offset == 0)
+ if (stage_state-bind_bo_offset == 0 brw-gen 9)
return;
stage_state-bind_bo_offset = 0;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/16] i965/skl: Update Viewport Z Clip Test Enable bits for Skylake.
From: Kenneth Graunke kenn...@whitecape.org
Skylake has separate controls for enabling the Z Clip Test for the near
and far planes. For now, maintain the legacy behavior by setting both.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 2 ++
src/mesa/drivers/dri/i965/gen8_sf_state.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 3953924..39363c8 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1913,6 +1913,7 @@ enum brw_message_target {
#define _3DSTATE_RASTER 0x7850 /* GEN8+ */
/* DW1 */
+# define GEN9_RASTER_VIEWPORT_Z_FAR_CLIP_TEST_ENABLE(1 26)
# define GEN8_RASTER_FRONT_WINDING_CCW (1 21)
# define GEN8_RASTER_CULL_BOTH (0 16)
# define GEN8_RASTER_CULL_NONE (1 16)
@@ -1923,6 +1924,7 @@ enum brw_message_target {
# define GEN8_RASTER_LINE_AA_ENABLE (1 2)
# define GEN8_RASTER_SCISSOR_ENABLE (1 1)
# define GEN8_RASTER_VIEWPORT_Z_CLIP_TEST_ENABLE(1 0)
+# define GEN9_RASTER_VIEWPORT_Z_NEAR_CLIP_TEST_ENABLE (1 0)
/* Gen8 BLEND_STATE */
/* DW0 */
diff --git a/src/mesa/drivers/dri/i965/gen8_sf_state.c
b/src/mesa/drivers/dri/i965/gen8_sf_state.c
index 05e5a2e..5b176c7 100644
--- a/src/mesa/drivers/dri/i965/gen8_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_sf_state.c
@@ -291,8 +291,14 @@ upload_raster(struct brw_context *brw)
dw1 |= GEN8_RASTER_SCISSOR_ENABLE;
/* _NEW_TRANSFORM */
- if (!ctx-Transform.DepthClamp)
- dw1 |= GEN8_RASTER_VIEWPORT_Z_CLIP_TEST_ENABLE;
+ if (!ctx-Transform.DepthClamp) {
+ if (brw-gen = 9) {
+ dw1 |= GEN9_RASTER_VIEWPORT_Z_NEAR_CLIP_TEST_ENABLE |
+GEN9_RASTER_VIEWPORT_Z_FAR_CLIP_TEST_ENABLE;
+ } else {
+ dw1 |= GEN8_RASTER_VIEWPORT_Z_CLIP_TEST_ENABLE;
+ }
+ }
BEGIN_BATCH(5);
OUT_BATCH(_3DSTATE_RASTER 16 | (5 - 2));
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/16] i965/skl: Set max OpenGL version the same as gen7/8
From: Jordan Justen jordan.l.jus...@intel.com
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/intel_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 41964ec..62e42aa 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1267,6 +1267,7 @@ set_max_gl_versions(struct intel_screen *screen)
__DRIscreen *psp = screen-driScrnPriv;
switch (screen-devinfo-gen) {
+ case 9:
case 8:
case 7:
case 6:
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/16] i965/skl: Emit extra zeros in 3DSTATE_DS on Skylake.
From: Kenneth Graunke kenn...@whitecape.org Skylake's 3DSTATE_DS packet has a few more fields; we don't support domain shaders yet though. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Reviewed-by: Kristian Høgsberg k...@bitplanet.net --- src/mesa/drivers/dri/i965/gen8_disable.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen8_disable.c b/src/mesa/drivers/dri/i965/gen8_disable.c index 276bd2e..0839a49 100644 --- a/src/mesa/drivers/dri/i965/gen8_disable.c +++ b/src/mesa/drivers/dri/i965/gen8_disable.c @@ -92,16 +92,11 @@ disable_stages(struct brw_context *brw) OUT_BATCH(0); ADVANCE_BATCH(); - BEGIN_BATCH(9); - OUT_BATCH(_3DSTATE_DS 16 | (9 - 2)); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_BATCH(0); - OUT_BATCH(0); + int ds_pkt_len = brw-gen = 9 ? 11 : 9; + BEGIN_BATCH(ds_pkt_len); + OUT_BATCH(_3DSTATE_DS 16 | (ds_pkt_len - 2)); + for (int i = 0; i ds_pkt_len - 1; i++) + OUT_BATCH(0); ADVANCE_BATCH(); BEGIN_BATCH(2); -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/16] i965/skl: Add Skylake PCI IDs
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
include/pci_ids/i965_pci_ids.h | 15 +++
src/mesa/drivers/dri/i965/brw_device_info.c | 29 +
2 files changed, 44 insertions(+)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 2e04301..3e3e8fe 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -109,6 +109,21 @@ CHIPSET(0x162A, bdw_gt3, Intel(R) Iris Pro P6300
(Broadwell GT3e))
CHIPSET(0x162B, bdw_gt3, Intel(R) Iris 6100 (Broadwell GT3))
CHIPSET(0x162D, bdw_gt3, Intel(R) Broadwell GT3)
CHIPSET(0x162E, bdw_gt3, Intel(R) Broadwell GT3)
+CHIPSET(0x1902, skl_gt1, Intel(R) Skylake DT GT1)
+CHIPSET(0x1906, skl_gt1, Intel(R) Skylake ULT GT1)
+CHIPSET(0x190A, skl_gt1, Intel(R) Skylake SRV GT1)
+CHIPSET(0x190B, skl_gt1, Intel(R) Skylake Halo GT1)
+CHIPSET(0x190E, skl_gt1, Intel(R) Skylake ULX GT1)
+CHIPSET(0x1912, skl_gt2, Intel(R) Skylake DT GT2)
+CHIPSET(0x1916, skl_gt2, Intel(R) Skylake ULT GT2)
+CHIPSET(0x191A, skl_gt2, Intel(R) Skylake SRV GT2)
+CHIPSET(0x191B, skl_gt2, Intel(R) Skylake Halo GT2)
+CHIPSET(0x191D, skl_gt2, Intel(R) Skylake WKS GT2)
+CHIPSET(0x191E, skl_gt2, Intel(R) Skylake ULX GT2)
+CHIPSET(0x1921, skl_gt2, Intel(R) Skylake ULT GT2F)
+CHIPSET(0x1926, skl_gt3, Intel(R) Skylake ULT GT3)
+CHIPSET(0x192A, skl_gt3, Intel(R) Skylake SRV GT3)
+CHIPSET(0x192B, skl_gt3, Intel(R) Skylake Halo GT3)
CHIPSET(0x22B0, chv, Intel(R) Cherryview)
CHIPSET(0x22B1, chv, Intel(R) Cherryview)
CHIPSET(0x22B2, chv, Intel(R) Cherryview)
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c
b/src/mesa/drivers/dri/i965/brw_device_info.c
index 18e4c80..378e7b3 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -251,6 +251,35 @@ static const struct brw_device_info brw_device_info_chv = {
}
};
+/* Thread counts and URB limits are placeholders, and may not be accurate. */
+#define GEN9_FEATURES \
+ .gen = 9,\
+ .has_hiz_and_separate_stencil = true,\
+ .must_use_separate_stencil = true, \
+ .has_llc = true, \
+ .has_pln = true, \
+ .max_vs_threads = 280, \
+ .max_gs_threads = 256, \
+ .max_wm_threads = 408, \
+ .urb = { \
+ .size = 128, \
+ .min_vs_entries = 64, \
+ .max_vs_entries = 1664, \
+ .max_gs_entries = 640,\
+ }
+
+static const struct brw_device_info brw_device_info_skl_gt1 = {
+ GEN9_FEATURES, .gt = 1
+};
+
+static const struct brw_device_info brw_device_info_skl_gt2 = {
+ GEN9_FEATURES, .gt = 2
+};
+
+static const struct brw_device_info brw_device_info_skl_gt3 = {
+ GEN9_FEATURES, .gt = 3
+};
+
const struct brw_device_info *
brw_get_device_info(int devid)
{
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/16] i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on Skylake.
From: Kenneth Graunke kenn...@whitecape.org
Skylake introduces a new base address for a feature we don't yet expose.
Setting these to 0 should be safe.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/gen8_misc_state.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c
b/src/mesa/drivers/dri/i965/gen8_misc_state.c
index 3c27c1a..16567c2 100644
--- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
@@ -31,8 +31,12 @@
*/
static void upload_state_base_address(struct brw_context *brw)
{
- BEGIN_BATCH(16);
- OUT_BATCH(CMD_STATE_BASE_ADDRESS 16 | (16 - 2));
+ perf_debug(Missing MOCS setup for STATE_BASE_ADDRESS.);
+
+ int pkt_len = brw-gen = 9 ? 19 : 16;
+
+ BEGIN_BATCH(pkt_len);
+ OUT_BATCH(CMD_STATE_BASE_ADDRESS 16 | (pkt_len - 2));
/* General state base address: stateless DP read/write requests */
OUT_BATCH(BDW_MOCS_WB 4 | 1);
OUT_BATCH(0);
@@ -59,6 +63,11 @@ static void upload_state_base_address(struct brw_context
*brw)
OUT_BATCH(0xf001);
/* Instruction access upper bound */
OUT_BATCH(ALIGN(brw-cache.bo-size, 4096) | 1);
+ if (brw-gen = 9) {
+ OUT_BATCH(1);
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ }
ADVANCE_BATCH();
brw-state.dirty.brw |= BRW_NEW_STATE_BASE_ADDRESS;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/16] i915/skl: Init instructions compaction tables for SKL
They are the same as for BDW, so just add a case for SKL to the init switch.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 4f509dd..99572ed 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
@@ -1059,6 +1059,7 @@ brw_init_compaction_tables(struct brw_context *brw)
assert(gen8_src_index_table[ARRAY_SIZE(gen8_src_index_table) - 1] != 0);
switch (brw-gen) {
+ case 9:
case 8:
control_index_table = gen8_control_index_table;
datatype_table = gen8_datatype_table;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/16] i965/skl: Update stencil reference handling for Skylake.
From: Kenneth Graunke kenn...@whitecape.org
Skylake uploads the stencil reference values in DW3 of the
3DSTATE_WM_DEPTH_STENCIL packet, rather than in COLOR_CALC_STATE.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 5 +
src/mesa/drivers/dri/i965/gen6_cc.c | 9 ++---
src/mesa/drivers/dri/i965/gen8_wm_depth_stencil.c | 20 +---
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index aca78af..3953924 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2033,6 +2033,11 @@ enum brw_message_target {
# define GEN8_WM_DS_BF_STENCIL_TEST_MASK_SHIFT 8
# define GEN8_WM_DS_BF_STENCIL_WRITE_MASK_MASK INTEL_MASK(7, 0)
# define GEN8_WM_DS_BF_STENCIL_WRITE_MASK_SHIFT 0
+/* DW3 */
+# define GEN9_WM_DS_STENCIL_REF_MASKINTEL_MASK(15, 8)
+# define GEN9_WM_DS_STENCIL_REF_SHIFT 8
+# define GEN9_WM_DS_BF_STENCIL_REF_MASK INTEL_MASK(7, 0)
+# define GEN9_WM_DS_BF_STENCIL_REF_SHIFT0
#define _3DSTATE_PS_EXTRA 0x784F /* GEN8+ */
/* DW1 */
diff --git a/src/mesa/drivers/dri/i965/gen6_cc.c
b/src/mesa/drivers/dri/i965/gen6_cc.c
index 45c926c..4770063 100644
--- a/src/mesa/drivers/dri/i965/gen6_cc.c
+++ b/src/mesa/drivers/dri/i965/gen6_cc.c
@@ -264,9 +264,12 @@ gen6_upload_color_calc_state(struct brw_context *brw)
cc-cc0.alpha_test_format = BRW_ALPHATEST_FORMAT_UNORM8;
UNCLAMPED_FLOAT_TO_UBYTE(cc-cc1.alpha_ref_fi.ui, ctx-Color.AlphaRef);
- /* _NEW_STENCIL */
- cc-cc0.stencil_ref = _mesa_get_stencil_ref(ctx, 0);
- cc-cc0.bf_stencil_ref = _mesa_get_stencil_ref(ctx, ctx-Stencil._BackFace);
+ if (brw-gen 9) {
+ /* _NEW_STENCIL */
+ cc-cc0.stencil_ref = _mesa_get_stencil_ref(ctx, 0);
+ cc-cc0.bf_stencil_ref =
+ _mesa_get_stencil_ref(ctx, ctx-Stencil._BackFace);
+ }
/* _NEW_COLOR */
cc-constant_r = ctx-Color.BlendColorUnclamped[0];
diff --git a/src/mesa/drivers/dri/i965/gen8_wm_depth_stencil.c
b/src/mesa/drivers/dri/i965/gen8_wm_depth_stencil.c
index 8f5728f..38212cd 100644
--- a/src/mesa/drivers/dri/i965/gen8_wm_depth_stencil.c
+++ b/src/mesa/drivers/dri/i965/gen8_wm_depth_stencil.c
@@ -26,12 +26,13 @@
#include brw_context.h
#include brw_defines.h
#include brw_state.h
+#include main/stencil.h
static void
gen8_upload_wm_depth_stencil(struct brw_context *brw)
{
struct gl_context *ctx = brw-ctx;
- uint32_t dw1 = 0, dw2 = 0;
+ uint32_t dw1 = 0, dw2 = 0, dw3 = 0;
/* _NEW_BUFFERS */
struct intel_renderbuffer *depth_irb =
@@ -73,6 +74,14 @@ gen8_upload_wm_depth_stencil(struct brw_context *brw)
SET_FIELD(stencil-ValueMask[b] 0xff,
GEN8_WM_DS_BF_STENCIL_TEST_MASK);
}
+
+ if (brw-gen = 9) {
+ int stencil_ref = _mesa_get_stencil_ref(ctx, 0);
+ int backface_ref = _mesa_get_stencil_ref(ctx, ctx-Stencil._BackFace);
+
+ dw3 = SET_FIELD(stencil_ref, GEN9_WM_DS_STENCIL_REF) |
+ SET_FIELD(backface_ref, GEN9_WM_DS_BF_STENCIL_REF);
+ }
}
/* _NEW_DEPTH */
@@ -85,10 +94,15 @@ gen8_upload_wm_depth_stencil(struct brw_context *brw)
dw1 |= GEN8_WM_DS_DEPTH_BUFFER_WRITE_ENABLE;
}
- BEGIN_BATCH(3);
- OUT_BATCH(_3DSTATE_WM_DEPTH_STENCIL 16 | (3 - 2));
+ int pkt_len = brw-gen = 9 ? 4 : 3;
+
+ BEGIN_BATCH(pkt_len);
+ OUT_BATCH(_3DSTATE_WM_DEPTH_STENCIL 16 | (pkt_len - 2));
OUT_BATCH(dw1);
OUT_BATCH(dw2);
+ if (pkt_len 3) {
+ OUT_BATCH(dw3);
+ }
ADVANCE_BATCH();
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/16] i965/skl: Refactor surface state allocation.
From: Kenneth Graunke kenn...@whitecape.org
We will need to allocate more DWords on Skylake.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c
b/src/mesa/drivers/dri/i965/gen8_surface_state.c
index 40eb2ea..f399029 100644
--- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
@@ -81,6 +81,16 @@ horizontal_alignment(struct intel_mipmap_tree *mt)
}
}
+static uint32_t *
+allocate_surface_state(const struct brw_context *brw, uint32_t *out_offset)
+{
+ int dwords = 13;
+ uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
+dwords * 4, 64, out_offset);
+ memset(surf, 0, dwords * 4);
+ return surf;
+}
+
static void
gen8_emit_buffer_surface_state(struct brw_context *brw,
uint32_t *out_offset,
@@ -92,9 +102,7 @@ gen8_emit_buffer_surface_state(struct brw_context *brw,
unsigned mocs,
bool rw)
{
- uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
-13 * 4, 64, out_offset);
- memset(surf, 0, 13 * 4);
+ uint32_t *surf = allocate_surface_state(brw, out_offset);
surf[0] = BRW_SURFACE_BUFFER BRW_SURFACE_TYPE_SHIFT |
surface_format BRW_SURFACE_FORMAT_SHIFT |
@@ -169,8 +177,7 @@ gen8_update_texture_surface(struct gl_context *ctx,
uint32_t tex_format = translate_tex_format(brw, format,
sampler-sRGBDecode);
- uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
-13 * 4, 64, surf_offset);
+ uint32_t *surf = allocate_surface_state(brw, surf_offset);
surf[0] = translate_tex_target(tObj-Target) BRW_SURFACE_TYPE_SHIFT |
tex_format BRW_SURFACE_FORMAT_SHIFT |
@@ -283,9 +290,8 @@ gen8_update_null_renderbuffer_surface(struct brw_context
*brw, unsigned unit)
uint32_t surf_index =
brw-wm.prog_data-binding_table.render_target_start + unit;
- uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 13 * 4, 64,
-brw-wm.base.surf_offset[surf_index]);
- memset(surf, 0, 13 * 4);
+ uint32_t *surf =
+ allocate_surface_state(brw, brw-wm.base.surf_offset[surf_index]);
surf[0] = BRW_SURFACE_NULL BRW_SURFACE_TYPE_SHIFT |
BRW_SURFACEFORMAT_B8G8R8A8_UNORM BRW_SURFACE_FORMAT_SHIFT |
@@ -367,8 +373,8 @@ gen8_update_renderbuffer_surface(struct brw_context *brw,
aux_mode = GEN8_SURFACE_AUX_MODE_MCS;
}
- uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 13 * 4, 64,
-brw-wm.base.surf_offset[surf_index]);
+ uint32_t *surf =
+ allocate_surface_state(brw, brw-wm.base.surf_offset[surf_index]);
surf[0] = (surf_type BRW_SURFACE_TYPE_SHIFT) |
(is_array ? GEN7_SURFACE_IS_ARRAY : 0) |
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/16] i965/skl: Set mask bits in PIPELINE_SELECT on Skylake.
From: Kenneth Graunke kenn...@whitecape.org
Skylake has some extra bits in PIPELINE_SELECT, none of which are
interesting for a 3D driver. In order to selectively change them, it
also introduces new mask bits in 15:8. We care about the Pipeline
Selection bits (1:0), so set the mask to 0x3.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index e3980fc..99fcddc 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -902,7 +902,7 @@ brw_upload_invariant_state(struct brw_context *brw)
const uint32_t _3DSTATE_PIPELINE_SELECT =
is_965 ? CMD_PIPELINE_SELECT_965 : CMD_PIPELINE_SELECT_GM45;
BEGIN_BATCH(1);
- OUT_BATCH(_3DSTATE_PIPELINE_SELECT 16 | 0);
+ OUT_BATCH(_3DSTATE_PIPELINE_SELECT 16 | (brw-gen = 9 ? (3 8) : 0));
ADVANCE_BATCH();
if (brw-gen 6) {
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Initial Skylake enabling
Here's a set of 16 patches to bring up mesa on Skylake (GEN 9). This is just initial enabling, there's more work to do. Most patches have been written/reviewed/signed-off by at least two developers and are ready to go. There are a few new patches from me in the set that haven't been reviewed yet: 1/16: The PCI ID list matches Damiens from the kernel series, with brw_device_info added for mesa. 10/16: The fast clear scaling factors changed again for SKL. 11/16: Compaction tables are the same as for BDW. 15/16: The MOCS bit changed format, add new #defines for SKL. 16/16: The depth stall workaround isn't needed for SKL or BDW, remove. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.
Roland Scheidegger srol...@vmware.com writes: Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these to util code. That plus the things I already mentioned should be all needed I think. But I strongly believe either this needs to be done or we should revert it. What's the actual problem being caused, though, other than needing to add an include dir? I mean, the previous state was that drivers were compiling a second copy of the file themselves inside of gallium, and being careful to make all our link targets link it exactly once, which seems definitely worse than oh, yeah, something outside of mesa/ includes some mesa/ static inlines and #define helpers. If someone was really offended by this, you could move bitset to util/, and evict ffs code to the single caller in nouveau (which is probably a good idea, because using ffs in your loop is probably a terrible idea anyway). But I think we all have more important things to be doing, and I don't think there's any actual harm being done. pgpRIqsu3Y6Cu.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/16] i965/skl: Use new MOCS for SKL
On Wednesday, September 24, 2014 12:28:20 PM Kristian Høgsberg wrote:
On Skylake, the MOCS bits are an index into a table of 63 different,
configurable cache configurations. As for previous GENs, we only care about
WB and WT, which are available in the documented default set. Define
SKL_MOCS_WB and SKL_MOCS_WT to the indices for those configucations and use
those for the Skylake MOCS values.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h| 6 ++
src/mesa/drivers/dri/i965/gen8_depth_state.c | 10 ++
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 8 +---
src/mesa/drivers/dri/i965/gen8_misc_state.c| 14 --
src/mesa/drivers/dri/i965/gen8_sol_state.c | 3 ++-
src/mesa/drivers/dri/i965/gen8_surface_state.c | 7 ---
6 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 39363c8..752f5d6 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2402,6 +2402,12 @@ enum brw_wm_barycentric_interp_mode {
#define BDW_MOCS_WB 0x78
#define BDW_MOCS_WT 0x58
+/* 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. */
*/ goes on the next line.
+#define SKL_MOCS_WB 9
+#define SKL_MOCS_WT 5
+
#include intel_chipset.h
#endif
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 7c3bfe0..a0390f6 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -48,6 +48,8 @@ emit_depth_packets(struct brw_context *brw,
uint32_t lod,
uint32_t min_array_element)
{
+ uint32_t mocs_wb = brw-gen =9 ? SKL_MOCS_WB : BDW_MOCS_WB;
missing space after =, here and elsewhere in the patch.
Patches 1, 3, 10-11, 14, 15, and 16 (the ones not authored by me) are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/16] i965/skl: Add Skylake PCI IDs
On Wednesday, September 24, 2014 12:28:06 PM Kristian Høgsberg wrote:
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
include/pci_ids/i965_pci_ids.h | 15 +++
src/mesa/drivers/dri/i965/brw_device_info.c | 29
+
2 files changed, 44 insertions(+)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 2e04301..3e3e8fe 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -109,6 +109,21 @@ CHIPSET(0x162A, bdw_gt3, Intel(R) Iris Pro P6300
(Broadwell GT3e))
CHIPSET(0x162B, bdw_gt3, Intel(R) Iris 6100 (Broadwell GT3))
CHIPSET(0x162D, bdw_gt3, Intel(R) Broadwell GT3)
CHIPSET(0x162E, bdw_gt3, Intel(R) Broadwell GT3)
+CHIPSET(0x1902, skl_gt1, Intel(R) Skylake DT GT1)
+CHIPSET(0x1906, skl_gt1, Intel(R) Skylake ULT GT1)
+CHIPSET(0x190A, skl_gt1, Intel(R) Skylake SRV GT1)
+CHIPSET(0x190B, skl_gt1, Intel(R) Skylake Halo GT1)
+CHIPSET(0x190E, skl_gt1, Intel(R) Skylake ULX GT1)
+CHIPSET(0x1912, skl_gt2, Intel(R) Skylake DT GT2)
+CHIPSET(0x1916, skl_gt2, Intel(R) Skylake ULT GT2)
+CHIPSET(0x191A, skl_gt2, Intel(R) Skylake SRV GT2)
+CHIPSET(0x191B, skl_gt2, Intel(R) Skylake Halo GT2)
+CHIPSET(0x191D, skl_gt2, Intel(R) Skylake WKS GT2)
+CHIPSET(0x191E, skl_gt2, Intel(R) Skylake ULX GT2)
+CHIPSET(0x1921, skl_gt2, Intel(R) Skylake ULT GT2F)
+CHIPSET(0x1926, skl_gt3, Intel(R) Skylake ULT GT3)
+CHIPSET(0x192A, skl_gt3, Intel(R) Skylake SRV GT3)
+CHIPSET(0x192B, skl_gt3, Intel(R) Skylake Halo GT3)
CHIPSET(0x22B0, chv, Intel(R) Cherryview)
CHIPSET(0x22B1, chv, Intel(R) Cherryview)
CHIPSET(0x22B2, chv, Intel(R) Cherryview)
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c
b/src/mesa/drivers/dri/i965/brw_device_info.c
index 18e4c80..378e7b3 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -251,6 +251,35 @@ static const struct brw_device_info brw_device_info_chv
= {
}
};
+/* Thread counts and URB limits are placeholders, and may not be accurate. */
+#define GEN9_FEATURES \
+ .gen = 9,\
+ .has_hiz_and_separate_stencil = true,\
+ .must_use_separate_stencil = true, \
+ .has_llc = true, \
+ .has_pln = true, \
+ .max_vs_threads = 280, \
+ .max_gs_threads = 256, \
+ .max_wm_threads = 408, \
+ .urb = { \
+ .size = 128, \
+ .min_vs_entries = 64, \
+ .max_vs_entries = 1664, \
+ .max_gs_entries = 640,\
+ }
+
+static const struct brw_device_info brw_device_info_skl_gt1 = {
+ GEN9_FEATURES, .gt = 1
+};
+
+static const struct brw_device_info brw_device_info_skl_gt2 = {
+ GEN9_FEATURES, .gt = 2
+};
+
+static const struct brw_device_info brw_device_info_skl_gt3 = {
+ GEN9_FEATURES, .gt = 3
+};
+
const struct brw_device_info *
brw_get_device_info(int devid)
{
We typically put the patch that adds the PCI IDs at the end of the series, so
support doesn't get turned on before the code is in place to make it work. I'm
not sure it really matters that much at this stage in the game, but if you
don't mind, please do move it to the end.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/16] i965/skl: Allocate 16 DWords for SURFACE_STATE on Skylake.
On Wednesday, September 24, 2014 12:28:13 PM Kristian Høgsberg wrote:
From: Kenneth Graunke kenn...@whitecape.org
Otherwise they overlap and horrible things happen. All the new DWords
are for fast color clear values, which we don't do yet.
This is no longer true. I see nothing prohibiting fast color clears from
happening on Skylake, but with this patch alone, we don't set up the fast color
clear values properly. So, it will almost certainly break (or at least always
clear to black).
I would probably recommend disabling fast color clears at this point, and then
send a later patch that fills in the proper info and turns them on. But it's
your call.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c
b/src/mesa/drivers/dri/i965/gen8_surface_state.c
index f399029..1742012 100644
--- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
@@ -84,7 +84,7 @@ horizontal_alignment(struct intel_mipmap_tree *mt)
static uint32_t *
allocate_surface_state(const struct brw_context *brw, uint32_t *out_offset)
{
- int dwords = 13;
+ int dwords = brw-gen = 9 ? 16 : 13;
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
dwords * 4, 64, out_offset);
memset(surf, 0, dwords * 4);
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/16] i965/bdw+: Remove depth stall workaround gen8 and up
On Wednesday, September 24, 2014 12:28:21 PM Kristian Høgsberg wrote:
As of BDW, this workaround is no longer necessary: WM HW will internally
manage
the draining pipe and flushing of the caches when this commands is issued.
The PIPE_CONTROL restrictions are removed.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 2 --
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index a0390f6..0d2877d 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -56,8 +56,6 @@ emit_depth_packets(struct brw_context *brw,
return;
}
- intel_emit_depth_stall_flushes(brw);
-
/* _NEW_BUFFERS, _NEW_DEPTH, _NEW_STENCIL */
BEGIN_BATCH(8);
OUT_BATCH(GEN7_3DSTATE_DEPTH_BUFFER 16 | (8 - 2));
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index cd45af6..0bc35bf 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -535,7 +535,7 @@ brw_emit_pipe_control_write(struct brw_context *brw,
uint32_t flags,
void
intel_emit_depth_stall_flushes(struct brw_context *brw)
{
- assert(brw-gen = 6 brw-gen = 8);
+ assert(brw-gen = 6 brw-gen = 7);
brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_STALL);
brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_CACHE_FLUSH);
Please make sure to do a full Piglit run (quick.py) on Broadwell with this
change before pushing. (I wasn't sure if you ran it there, or just on Gen9.)
It does look right, and I think I've tried that before too, but one can never
be too careful about these things.
Thanks Kristian!
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.
On Wed, Sep 24, 2014 at 12:52 PM, Eric Anholt e...@anholt.net wrote: Roland Scheidegger srol...@vmware.com writes: Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these to util code. That plus the things I already mentioned should be all needed I think. But I strongly believe either this needs to be done or we should revert it. What's the actual problem being caused, though, other than needing to add an include dir? I mean, the previous state was that drivers were compiling a second copy of the file themselves inside of gallium, and being careful to make all our link targets link it exactly once, which seems definitely worse than oh, yeah, something outside of mesa/ includes some mesa/ static inlines and #define helpers. If someone was really offended by this, you could move bitset to util/, and evict ffs code to the single caller in nouveau (which is probably a good idea, because using ffs in your loop is probably a terrible idea anyway). But I think we all have more important things to be doing, and I don't think there's any actual harm being done. Yes, we should continue moving stuff to util/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/16] i915/skl: Init instructions compaction tables for SKL
On Wed, Sep 24, 2014 at 12:28 PM, Kristian Høgsberg k...@bitplanet.net wrote: They are the same as for BDW, so just add a case for SKL to the init switch. Confirmed. I should have added case 9 in my series, I suppose. The BSpec isn't clear, but I think CHV and SKL have the same changes for mixed-mode hf/f operations, I think you'll need to update all of the brw-is_cherryview checks to brw-is_cherryview || brw-gen = 9. We haven't started using that feature, so you couldn't have triggered the problem. With those fixed, Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Structures must have same name to be considered same type.
On Wed, Sep 24, 2014 at 11:56 AM, Matt Turner matts...@gmail.com wrote: On Mon, Sep 22, 2014 at 5:11 AM, Tapani Pälli tapani.pa...@intel.com wrote: From: Kalyan Kondapally kalyan.kondapa...@intel.com According to GLSL(4.2) and GLSL-ES (1.0, 3.0) spec, Structures must have the same name to be considered same type. We currently ignore the name check while checking if two records are same. This patch fixes this. Patch fixes failing tests in WebGL conformance test 'shaders-with-uniform-structs' when running Chrome on OpenGL ES. v2: Do not force name comparison with unnamed types (Tapani) Signed-off-by: Kalyan Kondapally kalyan.kondapa...@intel.com Signed-off-by: Tapani Pälli tapani.pa...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83934 --- src/glsl/glsl_types.cpp | 14 ++ src/glsl/glsl_types.h | 8 2 files changed, 22 insertions(+) diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp + /* From the GLSL 4.20 specification (Sec 4.2): +* +* Structures must have the same name, sequence of type names, and +* type definitions, and field names to be considered the same type. +* +* GLSL ES behaves the same (Ver 1.00 Sec 4.2.4, Ver 3.00 Sec 4.2.5). +* +* Note that we cannot force type name check when comparing unnamed +* structure types, these have a unique name assigned during parsing. +*/ + if (!(this-is_anonymous() b-is_anonymous())) This would be clearer as if (!this-is_anonymous() !b-is_anonymous()) but you don't even need to check both of them. If this-is_anonymous(), it doesn't matter whether b-is_anonymous(). That is to say, isn't if (!this-is_anonymous()) if (strcmp(this-name, b-name) != 0) return false; sufficient? Assuming that logic is right, Reviewed-by: Matt Turner matts...@gmail.com This would ignore the case when record A is anonymous but record B is not. Br, Kalyan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Structures must have same name to be considered same type.
On Wed, Sep 24, 2014 at 1:39 PM, kalyan kondapally kondapallykalyancontrib...@gmail.com wrote: This would ignore the case when record A is anonymous but record B is not. Bah, I think you're right. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
I don't really qualified to review, IIRC I mentioned it was tricky to
see if it's right when you pushed it first, and this has not changed.
Some comment inline though...
Am 24.09.2014 20:30, schrieb Ilia Mirkin:
Marek/Roland -- do either of those comments count as a R-b? I'd like
to push this out tonight, pending a full piglit run.
On Wed, Sep 24, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com
wrote:
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true in core mesa of course (similar to 1d
array textures having height and so on) due to OpenGL weirdness for
historical reasons.
Roland
Am 24.09.2014 19:19, schrieb Marek Olšák:
Interesting, I didn't know about that. Nevermind. st/mesa indeed sets it to
6.
Marek
On Wed, Sep 24, 2014 at 6:26 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D84145k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=5599aec76e1694c8ec71dcfe6209603bf8b152884c942363fd84e9d56edaaa72
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct
st_texture_object *stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context
*st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct
st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
This is pretty confusing, so for a cubemap you get the initial z
(presumably zero), add the MinLayer for the view, then also the Face
from the initial image? This isn't new but all the translation from mesa
seems really tricky here and elsewhere.
The fix though is probably correct but really I can't tell...
But as long as it fixes things go for it...
Roland
--
1.8.5.5
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
On Wed, Sep 24, 2014 at 5:17 PM, Roland Scheidegger srol...@vmware.com wrote:
I don't really qualified to review, IIRC I mentioned it was tricky to
see if it's right when you pushed it first, and this has not changed.
Some comment inline though...
Am 24.09.2014 20:30, schrieb Ilia Mirkin:
Marek/Roland -- do either of those comments count as a R-b? I'd like
to push this out tonight, pending a full piglit run.
On Wed, Sep 24, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com
wrote:
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true in core mesa of course (similar to 1d
array textures having height and so on) due to OpenGL weirdness for
historical reasons.
Roland
Am 24.09.2014 19:19, schrieb Marek Olšák:
Interesting, I didn't know about that. Nevermind. st/mesa indeed sets it
to 6.
Marek
On Wed, Sep 24, 2014 at 6:26 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
For 3d textures, NumLayers is set to 1, which is not what we want.
This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D84145k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=5599aec76e1694c8ec71dcfe6209603bf8b152884c942363fd84e9d56edaaa72
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct
st_texture_object *stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context
*st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st,
struct st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
This is pretty confusing, so for a cubemap you get the initial z
(presumably zero), add the MinLayer for the view, then also the Face
from the initial image? This isn't new but all the translation from mesa
seems really tricky here and elsewhere.
The fix though is probably correct but really I
Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.
Am 24.09.2014 21:52, schrieb Eric Anholt: Roland Scheidegger srol...@vmware.com writes: Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these to util code. That plus the things I already mentioned should be all needed I think. But I strongly believe either this needs to be done or we should revert it. What's the actual problem being caused, though, other than needing to add an include dir? I mean, the previous state was that drivers were compiling a second copy of the file themselves inside of gallium, and being careful to make all our link targets link it exactly once, which seems definitely worse than oh, yeah, something outside of mesa/ includes some mesa/ static inlines and #define helpers. It also brings in lots of function declarations which obviously would result in a link error if you'd try to use them. If someone was really offended by this, Yes I am. This seems to really really be against any good coding practice. You can't just pull in random stuff from subprojects (even if it's just headers) imho, the util code was explicitly moved there to not be dependent on neither mesa core bits nor gallium. Don't forget gallium drivers can be compiled without using the core mesa bits at all. you could move bitset to util/, and evict ffs code to the single caller in nouveau (which is probably a good idea, because using ffs in your loop is probably a terrible idea anyway). But I think we all have more important things to be doing, and I don't think there's any actual harm being done. Yes, I suspect moving bitset to util would be the right solution. As said though you'd also have to bring over align/max2 (either the gallium or mesa version...), I guess it wouldn't hurt consolidating them, and ffs is pretty much the same (also has mesa and gallium definitions). Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures
Am 24.09.2014 23:23, schrieb Ilia Mirkin:
On Wed, Sep 24, 2014 at 5:17 PM, Roland Scheidegger srol...@vmware.com
wrote:
I don't really qualified to review, IIRC I mentioned it was tricky to
see if it's right when you pushed it first, and this has not changed.
Some comment inline though...
Am 24.09.2014 20:30, schrieb Ilia Mirkin:
Marek/Roland -- do either of those comments count as a R-b? I'd like
to push this out tonight, pending a full piglit run.
On Wed, Sep 24, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com
wrote:
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true in core mesa of course (similar to 1d
array textures having height and so on) due to OpenGL weirdness for
historical reasons.
Roland
Am 24.09.2014 19:19, schrieb Marek Olšák:
Interesting, I didn't know about that. Nevermind. st/mesa indeed sets it
to 6.
Marek
On Wed, Sep 24, 2014 at 6:26 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Sep 24, 2014 at 12:20 PM, Marek Olšák mar...@gmail.com wrote:
Cubemaps have array_size == 1, but you can still set the target to 2D
Are you *sure* about that? Everything I'm seeing indicates that
cubemaps have array_size == 6. For example this code in nv50_tex.c:
depth = MAX2(mt-base.base.array_size, mt-base.base.depth0);
...
case PIPE_TEXTURE_CUBE:
depth /= 6;
...
and set first_layer = last_layer = 6 in the sample view. Instead of
checking array_size, maybe NumLayers should be used instead. Just
guessing.
Marek
On Wed, Sep 24, 2014 at 5:05 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
The disguise of cubemap's layeredness is insufficient to trip up this
code :) They still get their NumLayers set, and the resources still
have an array size. Perhaps there's a scenario I'm not considering?
On Wed, Sep 24, 2014 at 5:23 AM, Marek Olšák mar...@gmail.com wrote:
Maybe something similar also needs to be done for cubemaps, because
they are just layered textures in disguise?
Marek
On Wed, Sep 24, 2014 at 7:01 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
For 3d textures, NumLayers is set to 1, which is not what we want.
This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D84145k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=p4L3w5mFWeprslDAPtBcySi4H8PhKEdqz0pOU77lcjg%3D%0As=5599aec76e1694c8ec71dcfe6209603bf8b152884c942363fd84e9d56edaaa72
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 3 ++-
src/mesa/state_tracker/st_texture.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index ed9a444..19072ae 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct
st_texture_object *stObj)
static unsigned last_layer(struct st_texture_object *stObj)
{
- if (stObj-base.Immutable)
+ if (stObj-base.Immutable stObj-pt-array_size 1)
return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
stObj-pt-array_size - 1);
return stObj-pt-array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..7b6a444 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,8 @@ st_update_renderbuffer_surface(struct st_context
*st,
}
/* Adjust for texture views */
- if (strb-is_rtt) {
+ if (strb-is_rtt resource-array_size 1
+ strb-Base.TexImage-TexObject-Immutable) {
struct gl_texture_object *tex =
strb-Base.TexImage-TexObject;
first_layer += tex-MinLayer;
if (!strb-rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st,
struct st_texture_image *stImage,
if (stObj-base.Immutable) {
level += stObj-base.MinLevel;
z += stObj-base.MinLayer;
- d = MIN2(d, stObj-base.NumLayers);
+ if (stObj-pt-array_size 1)
+ d = MIN2(d, stObj-base.NumLayers);
}
z += stImage-base.Face;
This is pretty confusing, so for a cubemap you get the initial z
(presumably zero), add the MinLayer for the view, then also the Face
from the initial image? This isn't new but all the translation from mesa
seems really tricky here and elsewhere.
The
Re: [Mesa-dev] [PATCH 02/16] i965/skl: Update 3DSTATE_SBE for Skylake.
On Wed, Sep 24, 2014 at 12:28 PM, Kristian Høgsberg k...@bitplanet.net wrote:
From: Damien Lespiau damien.lesp...@intel.com
This commands has seen the addition of 2 dwords that allow to specify
which channels of which attributes need to be forwarded to the fragment
shader.
v2: Rebase forward a year (done by Ken).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 6 ++
src/mesa/drivers/dri/i965/gen8_sf_state.c | 30 --
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index b2216fe..aca78af 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1903,6 +1903,12 @@ enum brw_message_target {
/* DW12: attr 0-7 wrap shortest enables */
/* DW13: attr 8-16 wrap shortest enables */
+/* DW5-6: Attribute active components (gen9) */
Aren't they DW4-5?
+#define GEN9_SBE_ACTIVE_COMPONENT_NONE 0
+#define GEN9_SBE_ACTIVE_COMPONENT_XY 1
+#define GEN9_SBE_ACTIVE_COMPONENT_XYZ 2
+#define GEN9_SBE_ACTIVE_COMPONENT_XYZW 3
+
#define _3DSTATE_SBE_SWIZ 0x7851 /* GEN8+ */
#define _3DSTATE_RASTER 0x7850 /* GEN8+ */
diff --git a/src/mesa/drivers/dri/i965/gen8_sf_state.c
b/src/mesa/drivers/dri/i965/gen8_sf_state.c
index 4263eaf..05e5a2e 100644
--- a/src/mesa/drivers/dri/i965/gen8_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_sf_state.c
@@ -39,10 +39,13 @@ upload_sbe(struct brw_context *brw)
uint32_t urb_entry_read_length;
uint32_t point_sprite_enables;
uint32_t flat_enables;
+ int sbe_cmd_length;
uint32_t dw1 =
GEN7_SBE_SWIZZLE_ENABLE |
num_outputs GEN7_SBE_NUM_OUTPUTS_SHIFT;
+ uint32_t dw4 = 0;
+ uint32_t dw5 = 0;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
@@ -79,11 +82,34 @@ upload_sbe(struct brw_context *brw)
GEN8_SBE_FORCE_URB_ENTRY_READ_LENGTH |
GEN8_SBE_FORCE_URB_ENTRY_READ_OFFSET;
- BEGIN_BATCH(4);
- OUT_BATCH(_3DSTATE_SBE 16 | (4 - 2));
+ if (brw-gen == 8) {
+ sbe_cmd_length = 4;
+ } else {
+ sbe_cmd_length = 6;
+
+ /* prepare the active component dwords */
+ int input_index = 0;
+ for (int attr = 0; attr VARYING_SLOT_MAX; attr++) {
+ if (!(brw-fragment_program-Base.InputsRead
BITFIELD64_BIT(attr)))
+continue;
+
+ if (input_index 16)
+dw4 |= (GEN9_SBE_ACTIVE_COMPONENT_XYZW (input_index 1));
+ else
+dw5 |= (GEN9_SBE_ACTIVE_COMPONENT_XYZW (input_index 1));
+
+ ++input_index;
+ }
+ }
+ BEGIN_BATCH(sbe_cmd_length);
+ OUT_BATCH(_3DSTATE_SBE 16 | (sbe_cmd_length - 2));
OUT_BATCH(dw1);
OUT_BATCH(point_sprite_enables);
OUT_BATCH(flat_enables);
+ if (sbe_cmd_length = 6) {
+ OUT_BATCH(dw4);
+ OUT_BATCH(dw5);
+ }
ADVANCE_BATCH();
BEGIN_BATCH(11);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.
On 09/24/2014 12:52 PM, Eric Anholt wrote: Roland Scheidegger srol...@vmware.com writes: Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these to util code. That plus the things I already mentioned should be all needed I think. But I strongly believe either this needs to be done or we should revert it. What's the actual problem being caused, though, other than needing to add an include dir? I mean, the previous state was that drivers were compiling a second copy of the file themselves inside of gallium, and being careful to make all our link targets link it exactly once, which seems definitely worse than oh, yeah, something outside of mesa/ includes some mesa/ static inlines and #define helpers. If someone was really offended by this, you could move bitset to util/, and evict ffs code to the single caller in nouveau (which is probably a good idea, because using ffs in your loop is probably a terrible idea anyway). But I think we all have more important things to be doing, and I don't think there's any actual harm being done. Yeah... these sound like great janitor projects for new community developers... not so much for people with deadlines and deliverables. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.
On 25 September 2014 08:51, Ian Romanick i...@freedesktop.org wrote: On 09/24/2014 12:52 PM, Eric Anholt wrote: Roland Scheidegger srol...@vmware.com writes: Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these to util code. That plus the things I already mentioned should be all needed I think. But I strongly believe either this needs to be done or we should revert it. What's the actual problem being caused, though, other than needing to add an include dir? I mean, the previous state was that drivers were compiling a second copy of the file themselves inside of gallium, and being careful to make all our link targets link it exactly once, which seems definitely worse than oh, yeah, something outside of mesa/ includes some mesa/ static inlines and #define helpers. If someone was really offended by this, you could move bitset to util/, and evict ffs code to the single caller in nouveau (which is probably a good idea, because using ffs in your loop is probably a terrible idea anyway). But I think we all have more important things to be doing, and I don't think there's any actual harm being done. Yeah... these sound like great janitor projects for new community developers... not so much for people with deadlines and deliverables. Hey less snark, thats my job, but really these are good jobs for people with deadlines and deliverables to do before they go moving code around, we haven't had util for 5 years, why the push to mess it up already, if the code isn't ready to move yet cleanly, don't move it. personally I'd rather we revert this until util can grow the required bits. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/16] i965/skl: Update 3DSTATE_SBE for Skylake.
On Wed, Sep 24, 2014 at 3:33 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
On Wed, Sep 24, 2014 at 12:28 PM, Kristian Høgsberg k...@bitplanet.net
wrote:
From: Damien Lespiau damien.lesp...@intel.com
This commands has seen the addition of 2 dwords that allow to specify
which channels of which attributes need to be forwarded to the fragment
shader.
v2: Rebase forward a year (done by Ken).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 6 ++
src/mesa/drivers/dri/i965/gen8_sf_state.c | 30
--
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index b2216fe..aca78af 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1903,6 +1903,12 @@ enum brw_message_target {
/* DW12: attr 0-7 wrap shortest enables */
/* DW13: attr 8-16 wrap shortest enables */
+/* DW5-6: Attribute active components (gen9) */
Aren't they DW4-5?
They are. I updated the comment, thanks.
Kristian
+#define GEN9_SBE_ACTIVE_COMPONENT_NONE 0
+#define GEN9_SBE_ACTIVE_COMPONENT_XY 1
+#define GEN9_SBE_ACTIVE_COMPONENT_XYZ 2
+#define GEN9_SBE_ACTIVE_COMPONENT_XYZW 3
+
#define _3DSTATE_SBE_SWIZ 0x7851 /* GEN8+ */
#define _3DSTATE_RASTER 0x7850 /* GEN8+ */
diff --git a/src/mesa/drivers/dri/i965/gen8_sf_state.c
b/src/mesa/drivers/dri/i965/gen8_sf_state.c
index 4263eaf..05e5a2e 100644
--- a/src/mesa/drivers/dri/i965/gen8_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_sf_state.c
@@ -39,10 +39,13 @@ upload_sbe(struct brw_context *brw)
uint32_t urb_entry_read_length;
uint32_t point_sprite_enables;
uint32_t flat_enables;
+ int sbe_cmd_length;
uint32_t dw1 =
GEN7_SBE_SWIZZLE_ENABLE |
num_outputs GEN7_SBE_NUM_OUTPUTS_SHIFT;
+ uint32_t dw4 = 0;
+ uint32_t dw5 = 0;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
@@ -79,11 +82,34 @@ upload_sbe(struct brw_context *brw)
GEN8_SBE_FORCE_URB_ENTRY_READ_LENGTH |
GEN8_SBE_FORCE_URB_ENTRY_READ_OFFSET;
- BEGIN_BATCH(4);
- OUT_BATCH(_3DSTATE_SBE 16 | (4 - 2));
+ if (brw-gen == 8) {
+ sbe_cmd_length = 4;
+ } else {
+ sbe_cmd_length = 6;
+
+ /* prepare the active component dwords */
+ int input_index = 0;
+ for (int attr = 0; attr VARYING_SLOT_MAX; attr++) {
+ if (!(brw-fragment_program-Base.InputsRead
BITFIELD64_BIT(attr)))
+continue;
+
+ if (input_index 16)
+dw4 |= (GEN9_SBE_ACTIVE_COMPONENT_XYZW (input_index 1));
+ else
+dw5 |= (GEN9_SBE_ACTIVE_COMPONENT_XYZW (input_index 1));
+
+ ++input_index;
+ }
+ }
+ BEGIN_BATCH(sbe_cmd_length);
+ OUT_BATCH(_3DSTATE_SBE 16 | (sbe_cmd_length - 2));
OUT_BATCH(dw1);
OUT_BATCH(point_sprite_enables);
OUT_BATCH(flat_enables);
+ if (sbe_cmd_length = 6) {
+ OUT_BATCH(dw4);
+ OUT_BATCH(dw5);
+ }
ADVANCE_BATCH();
BEGIN_BATCH(11);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/16] i965/skl: Use new MOCS for SKL
On Wed, Sep 24, 2014 at 12:57 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On Wednesday, September 24, 2014 12:28:20 PM Kristian Høgsberg wrote:
On Skylake, the MOCS bits are an index into a table of 63 different,
configurable cache configurations. As for previous GENs, we only care
about
WB and WT, which are available in the documented default set. Define
SKL_MOCS_WB and SKL_MOCS_WT to the indices for those configucations and
use
those for the Skylake MOCS values.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 6 ++
src/mesa/drivers/dri/i965/gen8_depth_state.c | 10 ++
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 8 +---
src/mesa/drivers/dri/i965/gen8_misc_state.c | 14 --
src/mesa/drivers/dri/i965/gen8_sol_state.c | 3 ++-
src/mesa/drivers/dri/i965/gen8_surface_state.c | 7 ---
6 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 39363c8..752f5d6 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2402,6 +2402,12 @@ enum brw_wm_barycentric_interp_mode {
#define BDW_MOCS_WB 0x78
#define BDW_MOCS_WT 0x58
+/* 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. */
*/ goes on the next line.
+#define SKL_MOCS_WB 9
+#define SKL_MOCS_WT 5
+
#include intel_chipset.h
#endif
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 7c3bfe0..a0390f6 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -48,6 +48,8 @@ emit_depth_packets(struct brw_context *brw,
uint32_t lod,
uint32_t min_array_element)
{
+ uint32_t mocs_wb = brw-gen =9 ? SKL_MOCS_WB : BDW_MOCS_WB;
missing space after =, here and elsewhere in the patch.
Oops, fixed... =9 kinda looks like a duck though...
Patches 1, 3, 10-11, 14, 15, and 16 (the ones not authored by me) are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
thanks,
Kristian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.
On Wed, Sep 24, 2014 at 3:57 PM, Dave Airlie airl...@gmail.com wrote:
On 25 September 2014 08:51, Ian Romanick i...@freedesktop.org wrote:
On 09/24/2014 12:52 PM, Eric Anholt wrote:
Roland Scheidegger srol...@vmware.com writes:
Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
to util code. That plus the things I already mentioned should be all
needed I think. But I strongly believe either this needs to be done or
we should revert it.
What's the actual problem being caused, though, other than needing to
add an include dir? I mean, the previous state was that drivers were
compiling a second copy of the file themselves inside of gallium, and
being careful to make all our link targets link it exactly once, which
seems definitely worse than oh, yeah, something outside of mesa/
includes some mesa/ static inlines and #define helpers.
If someone was really offended by this, you could move bitset to util/,
and evict ffs code to the single caller in nouveau (which is probably a
good idea, because using ffs in your loop is probably a terrible idea
anyway). But I think we all have more important things to be doing, and
I don't think there's any actual harm being done.
Yeah... these sound like great janitor projects for new community
developers... not so much for people with deadlines and deliverables.
Hey less snark, thats my job,
but really these are good jobs for people with deadlines and
deliverables to do before they go moving code around, we haven't had
util for 5 years, why the push to mess it up already, if the code
isn't ready to move yet cleanly, don't move it.
personally I'd rather we revert this until util can grow the required bits.
We could have fixed it by now. Here's a branch to start things:
git://people.freedesktop.org/~mattst88/mesa util
We should work on getting rid of
src/mesa/main/{imports,macros,compiler}* and moving useful bits to
util/
Does anyone else want to do this, or do I just need to?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Initial Skylake enabling
On Wed, Sep 24, 2014 at 12:28 PM, Kristian Høgsberg k...@bitplanet.net wrote: Here's a set of 16 patches to bring up mesa on Skylake (GEN 9). This is just initial enabling, there's more work to do. Most patches have been written/reviewed/signed-off by at least two developers and are ready to go. There are a few new patches from me in the set that haven't been reviewed yet: 1/16: The PCI ID list matches Damiens from the kernel series, with brw_device_info added for mesa. 10/16: The fast clear scaling factors changed again for SKL. 11/16: Compaction tables are the same as for BDW. 15/16: The MOCS bit changed format, add new #defines for SKL. 16/16: The depth stall workaround isn't needed for SKL or BDW, remove. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Patches 1-8 are Reviewed-by: Anuj Phogat anuj.pho...@gmail.com Will review rest of the patches tomorrow. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Interest in participating in the OPW with X.org
Hi Juliet, sorry about the delay, thanks for the email. I don't personally work on mesa so I'll wait if anyone on the list has a project to propose here. On Sat, Sep 20, 2014 at 07:52:38PM +0100, Juliet Fru wrote: I am Juliet Fru, a second year student of Computer Engineering at the University of Buea. I am interested in participating in the OPW this year. I've never worked on an open source project before; and I'll like to have this first experience with Xorg. I am proficient in C and i'm interested in writing tests for piglit. I'll like to know based on my discussions on IRC whether there is any programmer who is working on some functionality he/she would need me to write unit tests for? I would like to work on writing tests as my OPW project. One of the best ways to start is to build and run piglit and see if anything needs fixing. That way you get familiar with the code-base and the developers get to know you as well. Having a bit of a reputation from sending patches is a good thing to have. Cheers, Peter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] replace file specific compiler optimization withinline attibute
On Wed, Sep 24, 2014 at 6:25 AM, Marc Dietrich marvi...@gmx.de wrote: Am Montag, 22. September 2014, 11:48:29 schrieb Matt Turner: We need a configure check for support for __attribute__((target)). I'm going to send a series that adds support for this (and does the check for existing attribute uses, so once that goes in you can rebase this patch on that). nice, but won't work with the workaround above. Pragma and attribute does the same so, we could check for the attribute and use the pragma instead. I wonder if the best thing to do is to add target(sse4.1) in addition to using -msse4.1. That way, we'll retain compatibility with clang (and gcc-4.3, but who cares?) and we'll mark the function with enough information for LTO to work. Does that seem plausible? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/ir: avoid deleting pseudo instructions too early
What happens is that a SPLIT operation is part of the spill node, and as
a pseudo op, the instruction gets erased after processing its first def.
However the later defs still need to refer to it, so instead delay
spilling until after that whole RA node is done processing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79462
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 4b105b4..d47fed2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -25,6 +25,7 @@
#include stack
#include limits
+#include tr1/unordered_set
namespace nv50_ir {
@@ -1547,6 +1548,11 @@ SpillCodeInserter::run(const std::listValuePair lst)
LValue *lval = it-first-asLValue();
Symbol *mem = it-second ? it-second-asSym() : NULL;
+ // Keep track of which instructions to delete later. Deleting them
+ // inside the loop is unsafe since a single instruction may have
+ // multiple destinations that all need to be spilled (like OP_SPLIT).
+ std::tr1::unordered_setInstruction * to_del;
+
for (Value::DefIterator d = lval-defs.begin(); d != lval-defs.end();
++d) {
Value *slot = mem ?
@@ -1579,7 +1585,7 @@ SpillCodeInserter::run(const std::listValuePair lst)
d = lval-defs.erase(d);
--d;
if (slot-reg.file == FILE_MEMORY_LOCAL)
- delete_Instruction(func-getProgram(), defi);
+ to_del.insert(defi);
else
defi-setDef(0, slot);
} else {
@@ -1587,6 +1593,9 @@ SpillCodeInserter::run(const std::listValuePair lst)
}
}
+ for (std::tr1::unordered_setInstruction *::const_iterator it =
to_del.begin();
+ it != to_del.end(); ++it)
+ delete_Instruction(func-getProgram(), *it);
}
// TODO: We're not trying to reuse old slots in a potential next iteration.
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: More fallout from disabling with LLVM 3.6
From: Michel Dänzer michel.daen...@amd.com
The draw module would still try to use gallivm, causing many piglit tests
to fail with an assertion failure. llvmpipe might have been similarly
affected.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/auxiliary/draw/draw_context.c | 2 --
src/gallium/auxiliary/draw/draw_llvm.c | 5 +++--
src/gallium/auxiliary/gallivm/lp_bld_init.c | 16 +---
src/gallium/auxiliary/gallivm/lp_bld_init.h | 2 +-
src/gallium/drivers/llvmpipe/lp_jit.c | 4 ++--
src/gallium/drivers/llvmpipe/lp_jit.h | 2 +-
src/gallium/drivers/llvmpipe/lp_screen.c| 5 +++--
src/gallium/drivers/llvmpipe/lp_test_main.c | 5 +++--
8 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b/src/gallium/auxiliary/draw/draw_context.c
index 001446f..85f8e26 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -93,8 +93,6 @@ draw_create_context(struct pipe_context *pipe, boolean
try_llvm)
#if HAVE_LLVM
if (try_llvm draw_get_option_use_llvm()) {
draw-llvm = draw_llvm_create(draw);
- if (!draw-llvm)
- goto err_destroy;
}
#endif
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e8e837a..504f3ef 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -484,12 +484,13 @@ draw_llvm_create(struct draw_context *draw)
{
struct draw_llvm *llvm;
+ if (!lp_build_init())
+ return NULL;
+
llvm = CALLOC_STRUCT( draw_llvm );
if (!llvm)
return NULL;
- lp_build_init();
-
llvm-draw = draw;
llvm-nr_variants = 0;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 243d248..75ef935 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -306,7 +306,8 @@ init_gallivm_state(struct gallivm_state *gallivm, const
char *name)
assert(!gallivm-context);
assert(!gallivm-module);
- lp_build_init();
+ if (!lp_build_init())
+ return FALSE;
if (USE_GLOBAL_CONTEXT) {
gallivm-context = LLVMGetGlobalContext();
@@ -382,11 +383,18 @@ fail:
}
-void
+boolean
lp_build_init(void)
{
if (gallivm_initialized)
- return;
+ return TRUE;
+
+ /* XXX: Remove this once lp_bld_misc.cpp has been adapted to the removal
+* of JITMemoryManager
+*/
+#if HAVE_LLVM = 0x0306
+ return FALSE;
+#endif
#ifdef DEBUG
gallivm_debug = debug_get_option_gallivm_debug();
@@ -477,6 +485,8 @@ lp_build_init(void)
util_cpu_caps.has_avx = 0;
util_cpu_caps.has_f16c = 0;
#endif
+
+ return TRUE;
}
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.h
b/src/gallium/auxiliary/gallivm/lp_bld_init.h
index 2e32cf8..64c5278 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.h
@@ -49,7 +49,7 @@ struct gallivm_state
};
-void
+boolean
lp_build_init(void);
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c
b/src/gallium/drivers/llvmpipe/lp_jit.c
index 261702f..9acde4f 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.c
+++ b/src/gallium/drivers/llvmpipe/lp_jit.c
@@ -231,10 +231,10 @@ lp_jit_screen_cleanup(struct llvmpipe_screen *screen)
}
-void
+boolean
lp_jit_screen_init(struct llvmpipe_screen *screen)
{
- lp_build_init();
+ return lp_build_init();
}
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.h
b/src/gallium/drivers/llvmpipe/lp_jit.h
index 1325a8c..097fa7d 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.h
+++ b/src/gallium/drivers/llvmpipe/lp_jit.h
@@ -252,7 +252,7 @@ void
lp_jit_screen_cleanup(struct llvmpipe_screen *screen);
-void
+boolean
lp_jit_screen_init(struct llvmpipe_screen *screen);
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index e6597e9..3025322 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -557,6 +557,9 @@ llvmpipe_create_screen(struct sw_winsys *winsys)
return NULL;
#endif
+ if (!lp_jit_screen_init(screen))
+ return NULL;
+
#ifdef DEBUG
LP_DEBUG = debug_get_flags_option(LP_DEBUG, lp_debug_flags, 0 );
#endif
@@ -588,8 +591,6 @@ llvmpipe_create_screen(struct sw_winsys *winsys)
llvmpipe_init_screen_resource_funcs(screen-base);
- lp_jit_screen_init(screen);
-
screen-num_threads = util_cpu_caps.nr_cpus 1 ? util_cpu_caps.nr_cpus : 0;
#ifdef PIPE_SUBSYSTEM_EMBEDDED
screen-num_threads = 0;
diff --git a/src/gallium/drivers/llvmpipe/lp_test_main.c
b/src/gallium/drivers/llvmpipe/lp_test_main.c
index 8a896be..c7b6d65 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_main.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_main.c
@@ -376,6 +376,9 @@ int main(int argc, char **argv)
fpstate = util_fpstate_get();
