[Mesa-dev] Textures all black
Hi all, I hope you can help me, when using Mesa on Windows as a software renderer, all the textures show only black, is there something special I need to do to get the textures to work in windows ? Cheers and thank you in advance. Jason Anderssen Internet Email Confidentiality Footer: This email and any files transmitted with it contain privileged/confidential information intended for the addressee. Neither the confidentiality of nor any privilege in the email is waived, lost or destroyed by reason that it has been transmitted other than to the addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Linking fails when not writing gl_Position.
From: Kalyan Kondapally kalyan.kondapa...@intel.com
According to GLSL-ES Spec(i.e. 1.0, 3.0), gl_Position value is undefined
after the vertex processing stage if we don't write gl_Position. However,
GLSL 1.10 Spec mentions that writing to gl_Position is mandatory. In case
of GLSL-ES, it's not an error and atleast the linking should pass.
Currently, Mesa throws an linker error in case we dont write to gl_position
and Version is less then 140(GLSL) and 300(GLSL-ES). This patch changes
it so that we don't report an error in case of GLSL-ES.
Signed-off-by: Kalyan Kondapally kalyan.kondapa...@intel.com
Reviewed-by: Tapani Pälli tapani.pa...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83380
---
src/glsl/linker.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 57be493..e9cf550 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -559,10 +559,10 @@ validate_vertex_shader_executable(struct
gl_shader_program *prog,
* vertex processing has occurred. Its value is undefined if
* the vertex shader executable does not write gl_Position.
*
-* GLSL ES 3.00 is similar to GLSL 1.40--failing to write to gl_Position is
-* not an error.
+* All GLSL ES Versions are similar to GLSL 1.40--failing to write to
+* gl_Position is not an error.
*/
- if (prog-Version (prog-IsES ? 300 : 140)) {
+ if (!prog-IsES prog-Version 140) {
find_assignment_visitor find(gl_Position);
find.run(shader-ir);
if (!find.variable_found()) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83596] reuse_framebuffer_texture_attachment does not set Layered field
https://bugs.freedesktop.org/show_bug.cgi?id=83596 --- Comment #1 from Michel Dänzer mic...@daenzer.net --- Please submit the patch directly to the mesa-dev mailing list. -- 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] Add support for NV_depth_buffer_float.
Am 06.09.2014 19:17, schrieb Mathias Froehlich:
Hi,
Please review:
Add support for the unclamped versions of glDepthRange
and relatives. Also starting with OpenGL 4.2 the traditional
functions for this should no longer clamp the values to [0, 1].
This looks wrong to me (the NV_depth_buffer part may be ok, just skimmed
through it).
The core functions still (some would probably say unfortunately...)
clamp the values to [0,1]. Only 4.2 had language indicating otherwise,
however this was retroactively fixed (see GL 4.3 spec, chapter F.5,
Change Log for Released Specifications, page 647).
Roland
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
docs/GL3.txt | 1 +
src/mapi/glapi/gen/NV_depth_buffer_float.xml | 24
src/mapi/glapi/gen/gl_API.xml| 2 +
src/mesa/drivers/common/meta.c | 3 +-
src/mesa/main/attrib.c | 6 +-
src/mesa/main/depth.c| 82
+++-
src/mesa/main/depth.h| 6 ++
src/mesa/main/dlist.c| 67 +++
src/mesa/main/extensions.c | 1 +
src/mesa/main/viewport.c | 77 +-
src/mesa/main/viewport.h | 9 ++-
11 files changed, 223 insertions(+), 55 deletions(-)
create mode 100644 src/mapi/glapi/gen/NV_depth_buffer_float.xml
diff --git a/docs/GL3.txt b/docs/GL3.txt
index f5d5e72..a869beb 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -144,6 +144,7 @@ GL 4.2, GLSL 4.20:
GL_ARB_shading_language_420pack DONE (all drivers
that support GLSL 1.30)
GL_ARB_internalformat_query DONE (i965, nv50,
nvc0, r300, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_map_buffer_alignment DONE (all drivers)
+ Unclamped glDepthRange and GL_NV_depth_buffer_float DONE (all drivers)
GL 4.3, GLSL 4.30:
diff --git a/src/mapi/glapi/gen/NV_depth_buffer_float.xml
b/src/mapi/glapi/gen/NV_depth_buffer_float.xml
new file mode 100644
index 000..17ee268
--- /dev/null
+++ b/src/mapi/glapi/gen/NV_depth_buffer_float.xml
@@ -0,0 +1,24 @@
+?xml version=1.0?
+!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd
+
+!-- Note: no GLX protocol info yet. --
+
+OpenGLAPI
+
+category name=GL_NV_depth_buffer_float number=417
+
+function name=DepthRangedNV offset=assign
+param name=n type=GLdouble/
+param name=f type=GLdouble/
+/function
+function name=ClearDepthdNV offset=assign
+param name=d type=GLdouble/
+/function
+function name=DepthBoundsdNV offset=assign
+param name=zmin type=GLdouble/
+param name=zmax type=GLdouble/
+/function
+
+/category
+
+/OpenGLAPI
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 73f2f75..d504faf 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -13027,6 +13027,8 @@
xi:include href=NV_vdpau_interop.xml
xmlns:xi=http://www.w3.org/2001/XInclude/
+xi:include href=NV_depth_buffer_float.xml
xmlns:xi=http://www.w3.org/2001/XInclude/
+
xi:include href=GL4x.xml xmlns:xi=http://www.w3.org/2001/XInclude/
/OpenGLAPI
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 7a8e627..d165f12 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1112,7 +1112,8 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_set_viewport(ctx, 0, save-ViewportX, save-ViewportY,
save-ViewportW, save-ViewportH);
}
- _mesa_DepthRange(save-DepthNear, save-DepthFar);
+ /* Need to call ...NV since this is guaranteed not to clamp to [0,1] */
+ _mesa_DepthRangedNV(save-DepthNear, save-DepthFar);
}
if (state MESA_META_CLAMP_FRAGMENT_COLOR
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 2e289b6..7368ee1 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1072,7 +1072,9 @@ _mesa_PopAttrib(void)
const struct gl_depthbuffer_attrib *depth;
depth = (const struct gl_depthbuffer_attrib *) attr-data;
_mesa_DepthFunc(depth-Func);
- _mesa_ClearDepth(depth-Clear);
+ /* The ...NV variant is guaranteed not to clamp */
+ /* what was not clamped before. */
+ _mesa_ClearDepthdNV(depth-Clear);
_mesa_set_enable(ctx, GL_DEPTH_TEST, depth-Test);
_mesa_DepthMask(depth-Mask);
}
@@ -1364,7 +1366,7 @@ _mesa_PopAttrib(void)
for (i = 0; i ctx-Const.MaxViewports; i++) {
_mesa_set_viewport(ctx, i, vp[i].X, vp[i].Y, vp[i].Width,
vp[i].Height);
-
[Mesa-dev] [Bug 81174] Gallium: GL_LINE_LOOP broken with more than 512 points
https://bugs.freedesktop.org/show_bug.cgi?id=81174 --- Comment #15 from Florian Link florianl...@gmail.com --- In addition to the above bug, I found that the stippling pattern is reset when the intermediate buffer is commited. Thus, GL_LINE_STRIP and GL_LINE_LOOP stipple patterns jump at the same places where the GL_LINE_LOOP bug appears. The correct solution would be to correctly restart the stipple pattern when flushing the buffer on long line loops. Another stippling issue is that stippling does not stay at fixed places when parts of the line strip is outside of the viewport. -- 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 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #4 from Roland Scheidegger srol...@vmware.com --- Ok, I just was thinking it is probably something along these lines, and could reproduce this with some hacked up piglit test doing integer division by zero. Though I got a SIGFPE instead, I guess that's due to different environment. Should be in lp_build_div(). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallivm: (trivial) fix min / max variable names
From: Roland Scheidegger srol...@vmware.com
Calling the variable min when it's really max and vice versa seems a bit
confusing.
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index 82eebfb..8f3b568 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -205,17 +205,17 @@ lp_build_min_simple(struct lp_build_context *bld,
nan_behavior != GALLIVM_NAN_BEHAVIOR_UNDEFINED
nan_behavior != GALLIVM_NAN_RETURN_OTHER_SECOND_NONNAN
nan_behavior != GALLIVM_NAN_RETURN_NAN_FIRST_NONNAN) {
- LLVMValueRef isnan, max;
- max = lp_build_intrinsic_binary_anylength(bld-gallivm, intrinsic,
+ LLVMValueRef isnan, min;
+ min = lp_build_intrinsic_binary_anylength(bld-gallivm, intrinsic,
type,
intr_size, a, b);
if (nan_behavior == GALLIVM_NAN_RETURN_OTHER) {
isnan = lp_build_isnan(bld, b);
-return lp_build_select(bld, isnan, a, max);
+return lp_build_select(bld, isnan, a, min);
} else {
assert(nan_behavior == GALLIVM_NAN_RETURN_NAN);
isnan = lp_build_isnan(bld, a);
-return lp_build_select(bld, isnan, a, max);
+return lp_build_select(bld, isnan, a, min);
}
} else {
return lp_build_intrinsic_binary_anylength(bld-gallivm, intrinsic,
@@ -381,17 +381,17 @@ lp_build_max_simple(struct lp_build_context *bld,
nan_behavior != GALLIVM_NAN_BEHAVIOR_UNDEFINED
nan_behavior != GALLIVM_NAN_RETURN_OTHER_SECOND_NONNAN
nan_behavior != GALLIVM_NAN_RETURN_NAN_FIRST_NONNAN) {
- LLVMValueRef isnan, min;
- min = lp_build_intrinsic_binary_anylength(bld-gallivm, intrinsic,
+ LLVMValueRef isnan, max;
+ max = lp_build_intrinsic_binary_anylength(bld-gallivm, intrinsic,
type,
intr_size, a, b);
if (nan_behavior == GALLIVM_NAN_RETURN_OTHER) {
isnan = lp_build_isnan(bld, b);
-return lp_build_select(bld, isnan, a, min);
+return lp_build_select(bld, isnan, a, max);
} else {
assert(nan_behavior == GALLIVM_NAN_RETURN_NAN);
isnan = lp_build_isnan(bld, a);
-return lp_build_select(bld, isnan, a, min);
+return lp_build_select(bld, isnan, a, max);
}
} else {
return lp_build_intrinsic_binary_anylength(bld-gallivm, intrinsic,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] docs: (trivial) mark softpipe, llvmpipe as done for GL_ARB_base_instance
From: Roland Scheidegger srol...@vmware.com Forgot to add it when I fixed up the start instance handling in (llvm) draw. --- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index f5d5e72..f02ad67 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -138,7 +138,7 @@ GL 4.2, GLSL 4.20: GL_ARB_shader_atomic_countersDONE (i965) GL_ARB_texture_storage DONE (all drivers) GL_ARB_transform_feedback_instanced DONE (i965, nv50, nvc0, r600, radeonsi) - GL_ARB_base_instance DONE (i965, nv50, nvc0, r600, radeonsi) + GL_ARB_base_instance DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe) GL_ARB_shader_image_load_store in progress (curro) GL_ARB_conservative_depthDONE (all drivers that support GLSL 1.30) GL_ARB_shading_language_420pack DONE (all drivers that support GLSL 1.30) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] gallivm: (trivial) don't try to use rcp when the division 1/x is integer
From: Roland Scheidegger srol...@vmware.com This would just crash. Noticed by accident while checking int divisions by zero with a quickly hacked piglit test. --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c index 8f3b568..f9c0799 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c @@ -1073,7 +1073,7 @@ lp_build_div(struct lp_build_context *bld, if(a == bld-zero) return bld-zero; - if(a == bld-one) + if(a == bld-one type.floating) return lp_build_rcp(bld, b); if(b == bld-zero) return bld-undef; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #5 from Roland Scheidegger srol...@vmware.com --- Actually, I think it would be a good idea if you could return 0x instead of 0. This is typically what GPUs will do, since the d3d10 docs claim this is required, both for div and mod - http://msdn.microsoft.com/en-us/library/windows/desktop/hh447244%28v=vs.85%29.aspx -- 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 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #6 from Roland Scheidegger srol...@vmware.com --- (In reply to comment #5) Actually, I think it would be a good idea if you could return 0x instead of 0. This is typically what GPUs will do, since the d3d10 docs claim this is required, both for div and mod - http://msdn.microsoft.com/en-us/library/windows/desktop/hh447244%28v=vs. 85%29.aspx Though actually that might not make sense for signed div (which d3d10 doesn't have). -- 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 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #7 from Roland Scheidegger srol...@vmware.com --- (In reply to comment #6) (In reply to comment #5) Actually, I think it would be a good idea if you could return 0x instead of 0. This is typically what GPUs will do, since the d3d10 docs claim this is required, both for div and mod - http://msdn.microsoft.com/en-us/library/windows/desktop/hh447244%28v=vs. 85%29.aspx Though actually that might not make sense for signed div (which d3d10 doesn't have). And actually I didn't look closely enough, the unsigned versions already handle this (in udiv_emit_cpu() etc for gallivm), so it's just idiv_emit_cpu() which needs fixing. And zero is probably fine, I can't really think of a more useful value (maybe -MAX_INT or something would work too if anyone cares). -- 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 06/20] i965: Preserve the CFG in instruction scheduling.
On Tue, Sep 02, 2014 at 09:34:17PM -0700, Matt Turner wrote:
---
.../drivers/dri/i965/brw_schedule_instructions.cpp | 74
--
1 file changed, 42 insertions(+), 32 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 04ac242..bac0d55 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -27,6 +27,8 @@
#include brw_fs.h
#include brw_vec4.h
+#include brw_cfg.h
+#include brw_shader.h
#include glsl/glsl_types.h
#include glsl/ir_optimization.h
@@ -411,6 +413,7 @@ public:
this-remaining_grf_uses = NULL;
this-grf_active = NULL;
}
+ v-calculate_cfg();
}
~instruction_scheduler()
@@ -421,8 +424,8 @@ public:
void add_dep(schedule_node *before, schedule_node *after, int latency);
void add_dep(schedule_node *before, schedule_node *after);
- void run(exec_list *instructions);
- void add_inst(backend_instruction *inst);
+ void run(cfg_t *cfg);
+ void add_insts_from_block(bblock_t *block);
void compute_delay(schedule_node *node);
virtual void calculate_deps() = 0;
virtual schedule_node *choose_instruction_to_schedule() = 0;
@@ -440,7 +443,7 @@ public:
virtual void update_register_pressure(backend_instruction *inst) = 0;
virtual int get_register_pressure_benefit(backend_instruction *inst) = 0;
- void schedule_instructions(backend_instruction *next_block_header);
+ void schedule_instructions(bblock_t *block);
void *mem_ctx;
@@ -624,17 +627,28 @@ schedule_node::schedule_node(backend_instruction *inst,
}
void
-instruction_scheduler::add_inst(backend_instruction *inst)
+instruction_scheduler::add_insts_from_block(bblock_t *block)
{
- schedule_node *n = new(mem_ctx) schedule_node(inst, this);
+ /* Removing the last instruction from a basic block removes the block as
+* well, so put a NOP at the end to keep it alive.
+*/
Initially using the nop-instruction to keep the block non-empty seemed a
little artifical. Then I started thinking alternatives.
I started wondering why we couldn't simply copy the incoming block::start and
block::end into the instance of instruction_scheduler here instead of manually
creating a new instruction list. And then just set the original block::start
and block::end to NULL. If we named the new members of instruction_scheduler
the same as in bblock_t (start, end), we could even use the existing macros
for iterating (the macros are not concerned about the data type as long as it
has members 'start' and 'end').
I understood that the idea is to store the instructions represented by the
block somewhere, set the block empty and re-insert the instructions in possibly
different order back into the block, right?
+ if (!block-end-is_control_flow()) {
+ backend_instruction *nop = new(mem_ctx) backend_instruction();
+ nop-opcode = BRW_OPCODE_NOP;
+ block-end-insert_after(block, nop);
+ }
- assert(!inst-is_head_sentinel());
- assert(!inst-is_tail_sentinel());
+ foreach_inst_in_block_safe(backend_instruction, inst, block) {
+ if (inst-opcode == BRW_OPCODE_NOP || inst-is_control_flow())
+ continue;
Shouldn't this simply return? Original logic below simply quits iterating
when it finds a control flow instruction - there can be in the maximum one
control flow instruction per block, and it is always the last, right?
I also thought that it is not possible to have nop-instructions at this point
anymore other than those inserted above.
- this-instructions_to_schedule++;
+ schedule_node *n = new(mem_ctx) schedule_node(inst, this);
- inst-remove();
- instructions.push_tail(n);
+ this-instructions_to_schedule++;
+
+ inst-remove(block);
+ instructions.push_tail(n);
+ }
}
/** Recursive computation of the delay member of a node. */
@@ -1354,9 +1368,10 @@
vec4_instruction_scheduler::issue_time(backend_instruction *inst)
}
void
-instruction_scheduler::schedule_instructions(backend_instruction
*next_block_header)
+instruction_scheduler::schedule_instructions(bblock_t *block)
{
struct brw_context *brw = bv-brw;
+ backend_instruction *inst = block-end;
time = 0;
/* Remove non-DAG heads from the list. */
@@ -1372,7 +1387,7 @@
instruction_scheduler::schedule_instructions(backend_instruction
*next_block_hea
/* Schedule this instruction. */
assert(chosen);
chosen-remove();
- next_block_header-insert_before(chosen-inst);
+ inst-insert_before(block, chosen-inst);
instructions_to_schedule--;
update_register_pressure(chosen-inst);
@@ -1434,15 +1449,14 @@
instruction_scheduler::schedule_instructions(backend_instruction
*next_block_hea
}
}
+ if
Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
Hi, When reading si_dma.c code, it looks like the requested width of the copy is ignored except for PIPE_BUFFER. Perhaps that explains the bugs observed ? Axel Davy On 06/09/2014 19:14, Andy Furniss wrote : Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com --- Turn this on, run piglit, and pray for mercy. It might be interesting to see if it makes 3D apps any faster. Or piglit. Well it's not piglit and I haven't benchmarked anything yet, but I get a couple of faults at the start of Unigine Valley. [20635.429686] radeon :01:00.0: GPU fault detected: 146 0x07bd3d14 [20635.429690] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x683D [20635.429691] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1D03D014 [20635.429693] VM fault (0x04, vmid 14) at page 26685, write from DMA1 (61) [20635.429708] radeon :01:00.0: GPU fault detected: 146 0x07bd3d14 [20635.429709] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [20635.429710] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1C03D00C [20635.429711] VM fault (0x0c, vmid 14) at page 0, read from DMA1 (61) ___ 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 83463] [swrast] piglit glsl-vs-clamp-1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=83463 Abdiel Janulgue xynop...@gmail.com changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |xynop...@gmail.com |org | --- Comment #1 from Abdiel Janulgue xynop...@gmail.com --- We got an infinite loop in swrast which is caused by the back and forth ping-pong between saturate-to-clamp lowering pass and the clamp-to-saturate opt_algebraic optimization pass. I got a fix coming up which optionally disables the opt_algebraic optimization by adding an EmitNoSat toggle in gl_shader_compiler_options. -- 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 07/20] i965: Remove cfg-invalidating parameter from invalidate_live_intervals.
On Tue, Sep 02, 2014 at 09:34:18PM -0700, Matt Turner wrote: Everything has been converted to preserve the CFG. --- 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 09/20] i965/fs: Don't use instruction list after calculating the cfg.
On Tue, Sep 02, 2014 at 09:34:20PM -0700, Matt Turner wrote: The only trick is changing a break into a return true in register coalescing, since the macro is actually a double loop, and break will do something different than you expect. (Wish I'd realized that earlier!) I didn't double check for other such occurrences, I only re-checked that safe iterations were replaced by safe counterparts. If any former were left for some reason, I doubt tests would pass. 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 08/20] i965: Remove now unneeded calls to calculate_cfg().
On Tue, Sep 02, 2014 at 09:34:19PM -0700, Matt Turner wrote: Now that nothing invalidates the CFG, we can calculate_cfg() immediately after emit_fb_writes()/emit_thread_end() and never again. 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 10/20] i965/vec4: Don't use instruction list after calculating the cfg.
On Tue, Sep 02, 2014 at 09:34:21PM -0700, Matt Turner wrote: --- src/mesa/drivers/dri/i965/brw_shader.cpp| 2 +- src/mesa/drivers/dri/i965/brw_vec4.cpp | 14 +++--- src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 3 ++- src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp | 2 +- src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 8 5 files changed, 15 insertions(+), 14 deletions(-) Same here, I only re-checked that safe iterations were replaced by safe counterparts. 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
[Mesa-dev] [Bug 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #8 from rcond...@hotmail.com --- for the llvm version I was going to return bld-undef. I figure I might as well change tgsi_exec.c version to 0x for consistency...but I don't have strong feelings either way. -- 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] r600: Use DMA transfers in r600_copy_global_buffer
Hi,
I'm not sure if this will work. Imagine this case:
We have an item in the pool, and we want to use
r600_resource_copy_region with it, for example because we want to demote
it. This will call r600_copy_global_buffer, and with your patch it will
call r600_compute_global_demote_or_alloc, which will again call
compute_memory_demote_item causing an infinite cycle.
Also, why are you reassigning src and dst in r600_copy_global_buffer?
- Bruno
On Sun, 2014-09-07 at 18:32 +0200, Niels Ole Salscheider wrote:
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/drivers/r600/evergreen_compute.c | 27 ---
src/gallium/drivers/r600/evergreen_compute.h | 1 +
src/gallium/drivers/r600/r600_blit.c | 40
3 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 38b78c7..b495868 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -953,6 +953,22 @@ void r600_compute_global_buffer_destroy(
free(res);
}
+void r600_compute_global_demote_or_alloc(
+ struct compute_memory_pool *pool,
+ struct compute_memory_item *item,
+ struct pipe_context *ctx)
+{
+ if (is_item_in_pool(item)) {
+ compute_memory_demote_item(pool, item, ctx);
+ } else {
+ if (item-real_buffer == NULL) {
+ item-real_buffer = (struct r600_resource*)
+
r600_compute_buffer_alloc_vram(pool-screen, item-size_in_dw * 4);
+ }
+ }
+
+}
+
void *r600_compute_global_transfer_map(
struct pipe_context *ctx_,
struct pipe_resource *resource,
@@ -970,16 +986,7 @@ void *r600_compute_global_transfer_map(
struct pipe_resource *dst = NULL;
unsigned offset = box-x;
- if (is_item_in_pool(item)) {
- compute_memory_demote_item(pool, item, ctx_);
- }
- else {
- if (item-real_buffer == NULL) {
- item-real_buffer = (struct r600_resource*)
-
r600_compute_buffer_alloc_vram(pool-screen, item-size_in_dw * 4);
- }
- }
-
+ r600_compute_global_demote_or_alloc(pool, item, ctx_);
dst = (struct pipe_resource*)item-real_buffer;
if (usage PIPE_TRANSFER_READ)
diff --git a/src/gallium/drivers/r600/evergreen_compute.h
b/src/gallium/drivers/r600/evergreen_compute.h
index 4fb53a1..39bb854 100644
--- a/src/gallium/drivers/r600/evergreen_compute.h
+++ b/src/gallium/drivers/r600/evergreen_compute.h
@@ -47,6 +47,7 @@ void evergreen_emit_cs_shader(struct r600_context *rctx,
struct r600_atom * atom
struct pipe_resource *r600_compute_global_buffer_create(struct pipe_screen
*screen, const struct pipe_resource *templ);
void r600_compute_global_buffer_destroy(struct pipe_screen *screen, struct
pipe_resource *res);
+void r600_compute_global_demote_or_alloc(struct compute_memory_pool *pool,
struct compute_memory_item *item, struct pipe_context *ctx);
void *r600_compute_global_transfer_map(
struct pipe_context *ctx_,
struct pipe_resource *resource,
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index f766e37..f6471cb 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -21,6 +21,8 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include r600_pipe.h
+#include compute_memory_pool.h
+#include evergreen_compute.h
#include util/u_surface.h
#include util/u_format.h
#include evergreend.h
@@ -514,29 +516,33 @@ static void r600_copy_buffer(struct pipe_context *ctx,
struct pipe_resource *dst
* into a single global resource (r600_screen::global_pool). The means
* they don't have their own cs_buf handle, so they cannot be passed
* to r600_copy_buffer() and must be handled separately.
- *
- * XXX: It should be possible to implement this function using
- * r600_copy_buffer() by passing the memory_pool resource as both src
- * and dst and updating dstx and src_box to point to the correct offsets.
- * This would likely perform better than the current implementation.
*/
static void r600_copy_global_buffer(struct pipe_context *ctx,
struct pipe_resource *dst, unsigned
dstx, struct pipe_resource *src,
const struct pipe_box *src_box)
{
- struct pipe_box dst_box; struct pipe_transfer *src_pxfer,
- *dst_pxfer;
-
- u_box_1d(dstx, src_box-width, dst_box);
- void *src_ptr = ctx-transfer_map(ctx, src, 0, PIPE_TRANSFER_READ,
- src_box, src_pxfer);
- void *dst_ptr = ctx-transfer_map(ctx, dst, 0, PIPE_TRANSFER_WRITE,
-
Re: [Mesa-dev] [PATCH 11/20] i965/fs: Make count_to_loop_end() use basic blocks.
On Tue, Sep 02, 2014 at 09:34:22PM -0700, Matt Turner wrote:
When the instructions aren't in a flat list, this wouldn't have worked.
Also, this should be faster.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 28
+++
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 88f394d..7e391ea 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -190,27 +190,25 @@ brw_fs_alloc_reg_sets(struct intel_screen *screen)
brw_alloc_reg_set(screen, 2);
}
-int
-count_to_loop_end(fs_inst *do_inst)
+static int
+count_to_loop_end(bblock_t *block)
Could be constant, and naturally below in the loop also. With that:
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
I would probably change the name also, it isn't really counting the
instructions anymore (maybe find_loop_end()). But I leave it to you.
{
int depth = 1;
- int ip = 1;
- for (fs_inst *inst = (fs_inst *)do_inst-next;
+ /* Skip the first block, since we don't want to count the do the calling
+* function found.
+*/
+ for (block = (bblock_t *)block-link.next;
depth 0;
-inst = (fs_inst *)inst-next) {
- switch (inst-opcode) {
- case BRW_OPCODE_DO:
+block = (bblock_t *)block-link.next) {
+ if (block-start-opcode == BRW_OPCODE_DO)
depth++;
- break;
- case BRW_OPCODE_WHILE:
+ if (block-end-opcode == BRW_OPCODE_WHILE) {
depth--;
- break;
- default:
- break;
+ if (depth == 0)
+return block-end_ip;
}
- ip++;
}
- return ip;
+ unreachable(not reached);
}
/**
@@ -253,7 +251,7 @@ fs_visitor::setup_payload_interference(struct ra_graph *g,
* the end now.
*/
if (loop_depth == 1)
-loop_end_ip = ip + count_to_loop_end(inst);
+loop_end_ip = count_to_loop_end(block);
break;
case BRW_OPCODE_WHILE:
loop_depth--;
--
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] pipe-loader: Include unistd.h in pipe_loader_drm.c for close function.
On 09/06/2014 05:00 PM, Vinson Lee wrote: This patch fixes a build error on DragonFly. CC libpipe_loader_la-pipe_loader_drm.lo pipe_loader_drm.c: In function 'pipe_loader_drm_probe': pipe_loader_drm.c:207:10: error: implicit declaration of function 'close' [-Werror=implicit-function-declaration] Signed-off-by: Vinson Lee v...@freedesktop.org --- src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c index f531dbf..ffeb299 100644 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c @@ -33,6 +33,7 @@ #include fcntl.h #include stdio.h #include xf86drm.h +#include unistd.h #ifdef HAVE_PIPE_LOADER_XCB Reviewed-by: Brian Paul bri...@vmware.com Does this need to be tagged for the 10.3 or 10.2 branches? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] gallivm: (trivial) don't try to use rcp when the division 1/x is integer
On 09/08/2014 05:56 AM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com This would just crash. Noticed by accident while checking int divisions by zero with a quickly hacked piglit test. --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c index 8f3b568..f9c0799 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c @@ -1073,7 +1073,7 @@ lp_build_div(struct lp_build_context *bld, if(a == bld-zero) return bld-zero; - if(a == bld-one) + if(a == bld-one type.floating) return lp_build_rcp(bld, b); if(b == bld-zero) return bld-undef; For all 3, Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] Suppress any libGL:... warnings when LIBGL_DEBUG == quiet
Gents,
Can anyone review this trivial patch ?
Stefan, Johannes
Why do I need to register in order to view the bugreport ? Afaict it is not a
security issue, so I believe the bug should be publicly accessible.
-Emil
On 26/08/14 21:47, Johannes Obermayr wrote:
From: Stefan Dirsch sndir...@suse.de
Let's handle LIBGL_DEBUG env. variable in Mesa in a consistent way.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=892896
---
To: mesa-dev@lists.freedesktop.org
Cc: 10.3 mesa-sta...@lists.freedesktop.org
openSUSE maintainers: Why can't you forward your applied u_* patches to
upstream
to get them included in final/next release?
---
src/mesa/drivers/dri/common/xmlconfig.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index ce37647..8e48522 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -429,8 +429,10 @@ static void
__driUtilMessage(const char *f, ...)
{
va_list args;
+const char *libgl_debug;
-if (getenv(LIBGL_DEBUG)) {
+libgl_debug=getenv(LIBGL_DEBUG);
+if (libgl_debug !strstr(libgl_debug, quiet)) {
fprintf(stderr, libGL: );
va_start(args, f);
vfprintf(stderr, f, args);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83573] [swrast] piglit fs-op-not-bool-using-if regression
https://bugs.freedesktop.org/show_bug.cgi?id=83573 Kenneth Graunke kenn...@whitecape.org changed: What|Removed |Added CC||bri...@vmware.com, ||mar...@gmail.com --- Comment #1 from Kenneth Graunke kenn...@whitecape.org --- I thought Marek's patch (mesa: set UniformBooleanTrue = 1.0f by default) would fix this, but it doesn't. Using integer 1 works. Setting DEBUG_PROG = 1 in prog_execute.c and making ADD print values in hexadecimal, I see: false case ADD (3f80 3f80 3f80 3f80) = (8000 8000 8000 8000 ) + (3f80 3f80 3f80 3f80) ADD (1 1 1 1) = (-0 -0 -0 -0) + (1 1 1 1) true case ADD (ce7e ce7e ce7e ce7e) = (ce7e ce7e ce7e ce7e) + (3f80 3f80 3f80 3f80) ADD (-1.06535e+09 -1.06535e+09 -1.06535e+09 -1.06535e+09) = (-1.06535e+09 -1.06535e+09 -1.06535e+09 -1.06535e+09) + (1 1 1 1) So, it looks like we're seeing 1.0f = 3f80 numerically converted to a float somewhere (rather than bitcast). 0x3f80 = 1065353216 = 1.06535322E9. The ADD negates op[0], giving -1.06535322E9 = 0xce7e. I'm not sure where that's happening yet. -- 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 83573] [swrast] piglit fs-op-not-bool-using-if regression
https://bugs.freedesktop.org/show_bug.cgi?id=83573 --- Comment #2 from Ilia Mirkin imir...@alum.mit.edu --- On quick inspection that's happening in _mesa_propagate_uniforms_to_driver_storage The format gets set to uniform_bool_float which in turn goes through ((float *) dst)[c] = (float) *isrc; -- 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 83573] [swrast] piglit fs-op-not-bool-using-if regression
https://bugs.freedesktop.org/show_bug.cgi?id=83573 Kenneth Graunke kenn...@whitecape.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |kenn...@whitecape.org |org | --- Comment #3 from Kenneth Graunke kenn...@whitecape.org --- Right, I just found that too. Testing a patch to fix it now. -- 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 83567] Mesa 10.2.6 does not compile with llvm 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=83567 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Emil Velikov emil.l.veli...@gmail.com --- Shame that we did not get this report prior to the 10.2.7 release :'( Queued to the 10.2 branch. Should be out with mesa 10.2.8. Thanks -- 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] r600: Use DMA transfers in r600_copy_global_buffer
On Monday 08 September 2014, 15:19:15, Bruno Jimenez wrote:
Hi,
I'm not sure if this will work. Imagine this case:
We have an item in the pool, and we want to use
r600_resource_copy_region with it, for example because we want to demote
it. This will call r600_copy_global_buffer, and with your patch it will
call r600_compute_global_demote_or_alloc, which will again call
compute_memory_demote_item causing an infinite cycle.
I think this will not be a problem because neither the pool bo nor the
real_buffer will have the PIPE_BIND_GLOBAL flag. Therefore,
r600_compute_global_demote_or_alloc will not be called again.
Also, why are you reassigning src and dst in r600_copy_global_buffer?
For r600, resources with PIPE_BIND_GLOBAL are not real resources but only
correspond to items in the compute pool. There they can either have the
real_buffer bo when they should be mapped or be part of the pool bo.
Therefore the pipe_resources have to be reassigned accordingly.
I am however not sure if it is really necessary to demote the item from the
pool before copying data to it. Otherwise it would be possible to directly
access the pool bo if the item is already in it.
- Bruno
On Sun, 2014-09-07 at 18:32 +0200, Niels Ole Salscheider wrote:
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/drivers/r600/evergreen_compute.c | 27 ---
src/gallium/drivers/r600/evergreen_compute.h | 1 +
src/gallium/drivers/r600/r600_blit.c | 40
3 files changed, 41 insertions(+), 27
deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c index 38b78c7..b495868
100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -953,6 +953,22 @@ void r600_compute_global_buffer_destroy(
free(res);
}
+void r600_compute_global_demote_or_alloc(
+ struct compute_memory_pool *pool,
+ struct compute_memory_item *item,
+ struct pipe_context *ctx)
+{
+ if (is_item_in_pool(item)) {
+ compute_memory_demote_item(pool, item, ctx);
+ } else {
+ if (item-real_buffer == NULL) {
+ item-real_buffer = (struct r600_resource*)
+
r600_compute_buffer_alloc_vram(pool-screen, item-
size_in_dw * 4);
+ }
+ }
+
+}
+
void *r600_compute_global_transfer_map(
struct pipe_context *ctx_,
struct pipe_resource *resource,
@@ -970,16 +986,7 @@ void *r600_compute_global_transfer_map(
struct pipe_resource *dst = NULL;
unsigned offset = box-x;
- if (is_item_in_pool(item)) {
- compute_memory_demote_item(pool, item, ctx_);
- }
- else {
- if (item-real_buffer == NULL) {
- item-real_buffer = (struct r600_resource*)
-
r600_compute_buffer_alloc_vram(pool-screen, item-
size_in_dw * 4);
- }
- }
-
+ r600_compute_global_demote_or_alloc(pool, item, ctx_);
dst = (struct pipe_resource*)item-real_buffer;
if (usage PIPE_TRANSFER_READ)
diff --git a/src/gallium/drivers/r600/evergreen_compute.h
b/src/gallium/drivers/r600/evergreen_compute.h index 4fb53a1..39bb854
100644
--- a/src/gallium/drivers/r600/evergreen_compute.h
+++ b/src/gallium/drivers/r600/evergreen_compute.h
@@ -47,6 +47,7 @@ void evergreen_emit_cs_shader(struct r600_context *rctx,
struct r600_atom * atom
struct pipe_resource *r600_compute_global_buffer_create(struct
pipe_screen *screen, const struct pipe_resource *templ); void
r600_compute_global_buffer_destroy(struct pipe_screen *screen, struct
pipe_resource *res);
+void r600_compute_global_demote_or_alloc(struct compute_memory_pool
*pool, struct compute_memory_item *item, struct pipe_context *ctx);
void *r600_compute_global_transfer_map(
struct pipe_context *ctx_,
struct pipe_resource *resource,
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c index f766e37..f6471cb 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -21,6 +21,8 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include r600_pipe.h
+#include compute_memory_pool.h
+#include evergreen_compute.h
#include util/u_surface.h
#include util/u_format.h
#include evergreend.h
@@ -514,29 +516,33 @@ static void r600_copy_buffer(struct pipe_context
*ctx, struct pipe_resource *dst
* into a single global resource (r600_screen::global_pool). The means
* they don't have their own cs_buf handle, so they cannot be passed
* to r600_copy_buffer() and must be handled separately.
- *
- * XXX: It should be possible to implement this function using
- *
[Mesa-dev] [Bug 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570
--- Comment #10 from rcond...@hotmail.com ---
Could be totally borked, but this is what I have at the moment:
if (type.floating) {
return LLVMBuildFDiv(builder, a, b, );
}
else {
//The spec says divide by zero is undefined, but shouldn't throw an
exception
LLVMValueRef zeromask = lp_build_cmp(bld,
PIPE_FUNC_EQUAL,
b,
lp_build_zero(bld-gallivm,type));
if (type.sign) {
return lp_build_select(bld,
zeromask,
bld-undef,
LLVMBuildSDiv(builder, a, b, ));
}
else {
return lp_build_select(bld,
zeromask,
bld-undef,
LLVMBuildUDiv(builder, a, b, ));
}
}
I'll take a look at udiv_emit_cpu
--
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] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
On Thu, Aug 28, 2014 at 9:46 PM, Michel Dänzer mic...@daenzer.net wrote:
On 29.08.2014 00:01, Alex Deucher wrote:
On Thu, Aug 28, 2014 at 4:57 AM, Christian König
deathsim...@vodafone.de wrote:
Am 28.08.2014 um 08:56 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from ever being stored in
the CPU inaccessible part of VRAM.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
This patch is Reviewed-by: Christian König christian.koe...@amd.com
Applied to my -next tree.
Thanks!
I think we need a similar negative flags as well, e.g.
RADEON_GEM_NO_CPU_ACCESS.
This way we can stop forcing buffers into the visible VRAM while pinning
them for scanout.
How about the attached patch?
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 09b039a..b71e8e0 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -314,10 +314,14 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
unsigned lpfn = 0;
/* force to pin into visible video ram */
- if (bo-placements[i].flags TTM_PL_FLAG_VRAM)
- lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
- else
+ if (bo-placements[i].flags TTM_PL_FLAG_VRAM) {
+ if (bo-flags RADEON_GEM_NO_CPU_ACCESS)
+ lpfn = bo-rdev-mc.real_vram_size
PAGE_SHIFT;
+ else
+ lpfn = bo-rdev-mc.visible_vram_size
PAGE_SHIFT;
lpfn can be left at 0 if RADEON_GEM_NO_CPU_ACCESS is set, so this can
be simplified to:
if (!(bo-flags RADEON_GEM_NO_CPU_ACCESS))
lpfn = bo-rdev-mc.visible_vram_size
PAGE_SHIFT;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index f755f20..d2346fd 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -803,6 +803,8 @@ struct drm_radeon_gem_info {
#define RADEON_GEM_GTT_WC(1 2)
/* BO is expected to be accessed by the CPU */
#define RADEON_GEM_CPU_ACCESS(1 3)
+/* BO is expected to not be accessed by the CPU */
+#define RADEON_GEM_NO_CPU_ACCESS (1 4)
I'd use stronger wording for this, e.g.
/* CPU access is not expected to work for this BO */
Updated version with comments integrated.
Alex
From 8e0fe1b090f75e5b7cadc9c316d1a9e3668c8ed2 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Thu, 28 Aug 2014 10:59:05 -0400
Subject: [PATCH] drm/radeon: add RADEON_GEM_NO_CPU_ACCESS BO creation flag
(v2)
Allows pinning of buffers in the non-CPU visible portion of
vram.
v2: incorporate Michel's comments.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/radeon_object.c | 8 +---
include/uapi/drm/radeon_drm.h | 2 ++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index eef60aa..c7ad231d 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 max_offset,
unsigned lpfn = 0;
/* force to pin into visible video ram */
- if (bo-placements[i].flags TTM_PL_FLAG_VRAM)
- lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
- else
+ if (bo-placements[i].flags TTM_PL_FLAG_VRAM) {
+ if (!(bo-flags RADEON_GEM_NO_CPU_ACCESS))
+lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
+ } else {
lpfn = bo-rdev-mc.gtt_size PAGE_SHIFT; /* ??? */
+ }
if (max_offset)
lpfn = min (lpfn, (unsigned)(max_offset PAGE_SHIFT));
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index f755f20..50d0fb4 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -803,6 +803,8 @@ struct drm_radeon_gem_info {
#define RADEON_GEM_GTT_WC (1 2)
/* BO is expected to be accessed by the CPU */
#define RADEON_GEM_CPU_ACCESS (1 3)
+/* CPU access is not expected to work for this BO */
+#define RADEON_GEM_NO_CPU_ACCESS (1 4)
struct drm_radeon_gem_create {
uint64_t size;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/20] i965: Preserve the CFG in instruction scheduling.
On Mon, Sep 8, 2014 at 5:43 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Tue, Sep 02, 2014 at 09:34:17PM -0700, Matt Turner wrote:
---
.../drivers/dri/i965/brw_schedule_instructions.cpp | 74
--
1 file changed, 42 insertions(+), 32 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 04ac242..bac0d55 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -27,6 +27,8 @@
#include brw_fs.h
#include brw_vec4.h
+#include brw_cfg.h
+#include brw_shader.h
#include glsl/glsl_types.h
#include glsl/ir_optimization.h
@@ -411,6 +413,7 @@ public:
this-remaining_grf_uses = NULL;
this-grf_active = NULL;
}
+ v-calculate_cfg();
}
~instruction_scheduler()
@@ -421,8 +424,8 @@ public:
void add_dep(schedule_node *before, schedule_node *after, int latency);
void add_dep(schedule_node *before, schedule_node *after);
- void run(exec_list *instructions);
- void add_inst(backend_instruction *inst);
+ void run(cfg_t *cfg);
+ void add_insts_from_block(bblock_t *block);
void compute_delay(schedule_node *node);
virtual void calculate_deps() = 0;
virtual schedule_node *choose_instruction_to_schedule() = 0;
@@ -440,7 +443,7 @@ public:
virtual void update_register_pressure(backend_instruction *inst) = 0;
virtual int get_register_pressure_benefit(backend_instruction *inst) = 0;
- void schedule_instructions(backend_instruction *next_block_header);
+ void schedule_instructions(bblock_t *block);
void *mem_ctx;
@@ -624,17 +627,28 @@ schedule_node::schedule_node(backend_instruction *inst,
}
void
-instruction_scheduler::add_inst(backend_instruction *inst)
+instruction_scheduler::add_insts_from_block(bblock_t *block)
{
- schedule_node *n = new(mem_ctx) schedule_node(inst, this);
+ /* Removing the last instruction from a basic block removes the block as
+* well, so put a NOP at the end to keep it alive.
+*/
Initially using the nop-instruction to keep the block non-empty seemed a
little artifical. Then I started thinking alternatives.
I started wondering why we couldn't simply copy the incoming block::start and
block::end into the instance of instruction_scheduler here instead of manually
creating a new instruction list. And then just set the original block::start
and block::end to NULL. If we named the new members of instruction_scheduler
the same as in bblock_t (start, end), we could even use the existing macros
for iterating (the macros are not concerned about the data type as long as it
has members 'start' and 'end').
That sounds like a good idea, except that we have to leave control
flow instructions in place in add_insts_from_block(), since we cannot
move them. I guess we could just remove their schedule_node in
schedule_instructions(bblock_t *)?
So we'd be pulling instructions out of the list and reinserting them
immediately before the last control flow instruction?
I haven't thought through all of the logic required to do that, but if
we were to do it I'd want it to be as a separate patch.
I understood that the idea is to store the instructions represented by the
block somewhere, set the block empty and re-insert the instructions in
possibly
different order back into the block, right?
Right.
+ if (!block-end-is_control_flow()) {
+ backend_instruction *nop = new(mem_ctx) backend_instruction();
+ nop-opcode = BRW_OPCODE_NOP;
+ block-end-insert_after(block, nop);
+ }
- assert(!inst-is_head_sentinel());
- assert(!inst-is_tail_sentinel());
+ foreach_inst_in_block_safe(backend_instruction, inst, block) {
+ if (inst-opcode == BRW_OPCODE_NOP || inst-is_control_flow())
+ continue;
Shouldn't this simply return? Original logic below simply quits iterating
when it finds a control flow instruction - there can be in the maximum one
control flow instruction per block, and it is always the last, right?
No, endif and do instructions begin a basic block, so we need to leave
them in place, since we don't want to schedule control flow
instructions. So two control flow instructions can be in a basic
block. E.g., one starts with an endif and ends in an if.
I also thought that it is not possible to have nop-instructions at this point
anymore other than those inserted above.
Right, the only NOP that can be in the block is the one we added to
the end of the block immediately before this loop.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] r600: Use DMA transfers in r600_copy_global_buffer
v2: Do not demote items that are already in the pool
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/drivers/r600/evergreen_compute.h | 1 +
src/gallium/drivers/r600/r600_blit.c | 59
2 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.h
b/src/gallium/drivers/r600/evergreen_compute.h
index 4fb53a1..e4d3a38 100644
--- a/src/gallium/drivers/r600/evergreen_compute.h
+++ b/src/gallium/drivers/r600/evergreen_compute.h
@@ -45,6 +45,7 @@ void evergreen_init_atom_start_compute_cs(struct r600_context
*rctx);
void evergreen_init_compute_state_functions(struct r600_context *rctx);
void evergreen_emit_cs_shader(struct r600_context *rctx, struct r600_atom *
atom);
+struct r600_resource* r600_compute_buffer_alloc_vram(struct r600_screen
*screen, unsigned size);
struct pipe_resource *r600_compute_global_buffer_create(struct pipe_screen
*screen, const struct pipe_resource *templ);
void r600_compute_global_buffer_destroy(struct pipe_screen *screen, struct
pipe_resource *res);
void *r600_compute_global_transfer_map(
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index f766e37..b334a75 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -21,6 +21,8 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include r600_pipe.h
+#include compute_memory_pool.h
+#include evergreen_compute.h
#include util/u_surface.h
#include util/u_format.h
#include evergreend.h
@@ -514,29 +516,52 @@ static void r600_copy_buffer(struct pipe_context *ctx,
struct pipe_resource *dst
* into a single global resource (r600_screen::global_pool). The means
* they don't have their own cs_buf handle, so they cannot be passed
* to r600_copy_buffer() and must be handled separately.
- *
- * XXX: It should be possible to implement this function using
- * r600_copy_buffer() by passing the memory_pool resource as both src
- * and dst and updating dstx and src_box to point to the correct offsets.
- * This would likely perform better than the current implementation.
*/
static void r600_copy_global_buffer(struct pipe_context *ctx,
struct pipe_resource *dst, unsigned
dstx, struct pipe_resource *src,
const struct pipe_box *src_box)
{
- struct pipe_box dst_box; struct pipe_transfer *src_pxfer,
- *dst_pxfer;
-
- u_box_1d(dstx, src_box-width, dst_box);
- void *src_ptr = ctx-transfer_map(ctx, src, 0, PIPE_TRANSFER_READ,
- src_box, src_pxfer);
- void *dst_ptr = ctx-transfer_map(ctx, dst, 0, PIPE_TRANSFER_WRITE,
- dst_box, dst_pxfer);
- memcpy(dst_ptr, src_ptr, src_box-width);
-
- ctx-transfer_unmap(ctx, src_pxfer);
- ctx-transfer_unmap(ctx, dst_pxfer);
+ struct r600_context *rctx = (struct r600_context*)ctx;
+ struct compute_memory_pool *pool = rctx-screen-global_pool;
+ struct pipe_box new_src_box = *src_box;
+
+ if (src-bind PIPE_BIND_GLOBAL) {
+ struct r600_resource_global *rsrc =
+ (struct r600_resource_global *)src;
+ struct compute_memory_item *item = rsrc-chunk;
+
+ if (is_item_in_pool(item)) {
+ new_src_box.x += 4 * item-start_in_dw;
+ src = (struct pipe_resource *)pool-bo;
+ } else {
+ if (item-real_buffer == NULL) {
+ item-real_buffer = (struct r600_resource*)
+
r600_compute_buffer_alloc_vram(pool-screen,
+
item-size_in_dw * 4);
+ }
+ src = (struct pipe_resource*)item-real_buffer;
+ }
+ }
+ if (dst-bind PIPE_BIND_GLOBAL) {
+ struct r600_resource_global *rdst =
+ (struct r600_resource_global *)dst;
+ struct compute_memory_item *item = rdst-chunk;
+
+ if (is_item_in_pool(item)) {
+ dstx += 4 * item-start_in_dw;
+ dst = (struct pipe_resource *)pool-bo;
+ } else {
+ if (item-real_buffer == NULL) {
+ item-real_buffer = (struct r600_resource*)
+
r600_compute_buffer_alloc_vram(pool-screen,
+
item-size_in_dw * 4);
+ }
+ dst = (struct pipe_resource*)item-real_buffer;
+ }
+ }
+
+ r600_copy_buffer(ctx, dst, dstx, src, new_src_box);
}
static void r600_clear_buffer(struct
Re: [Mesa-dev] [PATCH 3/3] gallivm: (trivial) don't try to use rcp when the division 1/x is integer
Series looks good to me too. Jose From: srol...@vmware.com srol...@vmware.com Sent: 08 September 2014 12:56 To: Jose Fonseca; mesa-dev@lists.freedesktop.org Cc: Roland Scheidegger Subject: [PATCH 3/3] gallivm: (trivial) don't try to use rcp when the division 1/x is integer From: Roland Scheidegger srol...@vmware.com This would just crash. Noticed by accident while checking int divisions by zero with a quickly hacked piglit test. --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c index 8f3b568..f9c0799 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c @@ -1073,7 +1073,7 @@ lp_build_div(struct lp_build_context *bld, if(a == bld-zero) return bld-zero; - if(a == bld-one) + if(a == bld-one type.floating) return lp_build_rcp(bld, b); if(b == bld-zero) return bld-undef; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add support for NV_depth_buffer_float v2.
Hi Mathias On 08/09/14 17:39, Mathias Fröhlich wrote: Hi, On Monday, September 08, 2014 13:16:27 Roland Scheidegger wrote: Add support for the unclamped versions of glDepthRange and relatives. Also starting with OpenGL 4.2 the traditional functions for this should no longer clamp the values to [0, 1]. This looks wrong to me (the NV_depth_buffer part may be ok, just skimmed through it). The core functions still (some would probably say unfortunately...) clamp the values to [0,1]. Only 4.2 had language indicating otherwise, however this was retroactively fixed (see GL 4.3 spec, chapter F.5, Change Log for Released Specifications, page 647). Thanks for pointing this out. I did indeed only look at 4.2 where I did find hints that clamping got removed. Below the v2 patch that only avoids clamping when being called through the *NV functions. I have the sneaky feeling that you've not ran 'make check' after the patch ? To confirm that it's ran fully you might need to build mesa twice - once with --disable-shared-glapi and once without (disable egl and gles* for the time being). This will lead you to some changes in src/mapi/*glapi/tests/check_table.cpp. A couple of other nitpicks - Please split the patch - one for the rework of existing functions and another one for the new extension. - Adding a line to the release notes :) Thanks Emil Greetings Mathias Add support for the unclamped versions of glDepthRange and relatives. Note that OpenGL 4.2 introduced that the traditonal glDepthRange functions may no longer clamp to [0, 1], but OpenGL 4.3 already revoked this behavior to clamp the arguments. Signed-off-by: Mathias Froehlich mathias.froehl...@web.de --- docs/GL3.txt | 1 + src/mapi/glapi/gen/NV_depth_buffer_float.xml | 24 src/mapi/glapi/gen/gl_API.xml| 2 + src/mesa/drivers/common/meta.c | 3 +- src/mesa/main/attrib.c | 6 +- src/mesa/main/depth.c| 82 +++- src/mesa/main/depth.h| 6 ++ src/mesa/main/dlist.c| 67 +++ src/mesa/main/extensions.c | 1 + src/mesa/main/viewport.c | 77 +- src/mesa/main/viewport.h | 9 ++- 11 files changed, 223 insertions(+), 55 deletions(-) create mode 100644 src/mapi/glapi/gen/NV_depth_buffer_float.xml diff --git a/docs/GL3.txt b/docs/GL3.txt index f5d5e72..9a3ceb9 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -144,6 +144,7 @@ GL 4.2, GLSL 4.20: GL_ARB_shading_language_420pack DONE (all drivers that support GLSL 1.30) GL_ARB_internalformat_query DONE (i965, nv50, nvc0, r300, r600, radeonsi, llvmpipe, softpipe) GL_ARB_map_buffer_alignment DONE (all drivers) + GL_NV_depth_buffer_float DONE (all drivers) GL 4.3, GLSL 4.30: diff --git a/src/mapi/glapi/gen/NV_depth_buffer_float.xml b/src/mapi/glapi/gen/NV_depth_buffer_float.xml new file mode 100644 index 000..17ee268 --- /dev/null +++ b/src/mapi/glapi/gen/NV_depth_buffer_float.xml @@ -0,0 +1,24 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +!-- Note: no GLX protocol info yet. -- + +OpenGLAPI + +category name=GL_NV_depth_buffer_float number=417 + +function name=DepthRangedNV offset=assign +param name=n type=GLdouble/ +param name=f type=GLdouble/ +/function +function name=ClearDepthdNV offset=assign +param name=d type=GLdouble/ +/function +function name=DepthBoundsdNV offset=assign +param name=zmin type=GLdouble/ +param name=zmax type=GLdouble/ +/function + +/category + +/OpenGLAPI diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 73f2f75..d504faf 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -13027,6 +13027,8 @@ xi:include href=NV_vdpau_interop.xml xmlns:xi=http://www.w3.org/2001/XInclude/ +xi:include href=NV_depth_buffer_float.xml xmlns:xi=http://www.w3.org/2001/XInclude/ + xi:include href=GL4x.xml xmlns:xi=http://www.w3.org/2001/XInclude/ /OpenGLAPI diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index 7a8e627..d165f12 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -1112,7 +1112,8 @@ _mesa_meta_end(struct gl_context *ctx) _mesa_set_viewport(ctx, 0, save-ViewportX, save-ViewportY, save-ViewportW, save-ViewportH); } - _mesa_DepthRange(save-DepthNear, save-DepthFar); + /* Need to call ...NV since this is guaranteed not to clamp to [0,1] */ + _mesa_DepthRangedNV(save-DepthNear, save-DepthFar); } if
[Mesa-dev] [PATCH 2/2] i965: Enable EXT_framebuffer_multisample_blit_scaled for gen8
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com --- src/mesa/drivers/dri/i965/intel_extensions.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c b/src/mesa/drivers/dri/i965/intel_extensions.c index 046d2a1..10fe10e 100644 --- a/src/mesa/drivers/dri/i965/intel_extensions.c +++ b/src/mesa/drivers/dri/i965/intel_extensions.c @@ -256,8 +256,7 @@ intelInitExtensions(struct gl_context *ctx) ctx-Extensions.EXT_framebuffer_multisample = true; ctx-Extensions.EXT_transform_feedback = true; - if (brw-gen 8) - ctx-Extensions.EXT_framebuffer_multisample_blit_scaled = true; + ctx-Extensions.EXT_framebuffer_multisample_blit_scaled = true; ctx-Extensions.ARB_blend_func_extended = !driQueryOptionb(brw-optionCache, disable_blend_func_extended); ctx-Extensions.ARB_draw_buffers_blend = true; ctx-Extensions.ARB_ES3_compatibility = true; -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] meta: Implement ext_framebuffer_multisample_blit_scaled extension
Extension enables doing a multisample buffer resolve and buffer
scaling using a single glBlitFrameBuffer() call. Currently, we
have this extension implemented in BLORP which is only used by
SNB and IVB. This patch implements the extension in meta path
which makes it available to Broadwell.
Implementation features:
- Supports scaled resolves of 2X, 4X and 8X multisample buffers.
- Avoids unnecessary shader compilations by storing the pre compiled
shaders for each supported sample count.
- Uses bilinear filtering for both GL_SCALED_RESOLVE_FASTEST_EXT and
GL_SCALED_RESOLVE_NICEST_EXT filter options. Although, extension
allows this behavior, it'll be nice to use trilinear or anistropic
filtering for GL_SCALED_RESOLVE_NICEST_EXT filter. I'll work on it
after pushing this series.
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/common/meta.h | 6 +
src/mesa/drivers/common/meta_blit.c | 213 ++--
2 files changed, 208 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index edc3e8c..2c9517b 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -279,6 +279,12 @@ enum blit_msaa_shader {
BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_COPY_UINT,
BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_RESOLVE,
BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_COPY,
+ BLIT_2X_MSAA_SHADER_2D_MULTISAMPLE_SCALED_RESOLVE,
+ BLIT_4X_MSAA_SHADER_2D_MULTISAMPLE_SCALED_RESOLVE,
+ BLIT_8X_MSAA_SHADER_2D_MULTISAMPLE_SCALED_RESOLVE,
+ BLIT_2X_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_SCALED_RESOLVE,
+ BLIT_4X_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_SCALED_RESOLVE,
+ BLIT_8X_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_SCALED_RESOLVE,
BLIT_MSAA_SHADER_COUNT,
};
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index fc9848a..0fe4410 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -55,6 +55,194 @@
#define OFFSET(FIELD) ((void *) offsetof(struct vertex, FIELD))
static void
+setup_glsl_msaa_blit_scaled_shader(struct gl_context *ctx,
+ struct blit_state *blit,
+ struct gl_renderbuffer *src_rb,
+ GLenum target, GLenum filter)
+{
+ GLint loc_src_width, loc_src_height;
+ int shader_offset = 0;
+ void *mem_ctx = ralloc_context(NULL);
+ char *fs_source;
+ char *name, *sample_number;
+ char* sample_map = ;
+ char *texel_fetch_macro = rzalloc_size(mem_ctx, 1);;
+ const char *vs_source;
+ const char *sampler_array_suffix = ;
+ const char *texcoord_type = vec2;
+ const int samples = MAX2(src_rb-NumSamples, 1);
+ const float y_scale = samples * 0.5;
+ enum blit_msaa_shader shader_index;
+
+ /* We expect only power of 2 samples in source multisample buffer. */
+ assert((samples (samples - 1)) == 0);
+ while (samples (shader_offset + 1)) {
+ shader_offset++;
+ }
+ /* Update the assert if we plan to support more than 8X MSAA. */
+ assert(shader_offset 0 shader_offset 4);
+
+ assert(target == GL_TEXTURE_2D_MULTISAMPLE ||
+ target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY);
+
+ shader_index = BLIT_2X_MSAA_SHADER_2D_MULTISAMPLE_SCALED_RESOLVE +
+ shader_offset - 1;
+
+ if (target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY) {
+ shader_index += BLIT_2X_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_SCALED_RESOLVE -
+ BLIT_2X_MSAA_SHADER_2D_MULTISAMPLE_SCALED_RESOLVE;
+ sampler_array_suffix = Array;
+ texcoord_type = vec3;
+ }
+
+ if (blit-msaa_shaders[shader_index]) {
+ _mesa_UseProgram(blit-msaa_shaders[shader_index]);
+ /* Update the uniform values. */
+ loc_src_width =
+ glGetUniformLocation(blit-msaa_shaders[shader_index], src_width);
+ loc_src_height =
+ glGetUniformLocation(blit-msaa_shaders[shader_index], src_height);
+ glUniform1f(loc_src_width, src_rb-Width);
+ glUniform1f(loc_src_height, src_rb-Height);
+ return;
+ }
+
+ name = ralloc_asprintf(mem_ctx, vec4 MSAA scaled resolve);
+
+ /* Below switch is used to setup the shader expression, which computes
+ * sample index and map it to to a sample number on Intel hardware.
+ * Sample index layout shows the numbering of slots in a rectangular
+ * grid of samples with in a pixel. Sample number layout shows the
+ * rectangular grid of samples roughly corresponding to the real sample
+ * locations with in a pixel. Sample number layout matches the sample
+ * index layout in case of 2X and 4x MSAA, but they are different in
+ * case of 8X MSAA.
+ *
+ * 2X MSAA sample index / number layout
+ * -
+ * | 0 | 1 |
+ * -
+ *
+ * 4X MSAA sample index / number layout
+ * -
+ * | 0 | 1 |
+ * -
+ * |
Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
On 08.09.2014 14:50, Axel Davy wrote: Hi, When reading si_dma.c code, it looks like the requested width of the copy is ignored except for PIPE_BUFFER. Perhaps that explains the bugs observed ? It isn't ignored. Partial DMA copies (i.e. operations that do not copy whole lines) are simply not supported right now, and will fall back to resource_copy_region. In fact, it's even stricter: the picthes of source and destination have to match. Grigori Axel Davy On 06/09/2014 19:14, Andy Furniss wrote : Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com --- Turn this on, run piglit, and pray for mercy. It might be interesting to see if it makes 3D apps any faster. Or piglit. Well it's not piglit and I haven't benchmarked anything yet, but I get a couple of faults at the start of Unigine Valley. [20635.429686] radeon :01:00.0: GPU fault detected: 146 0x07bd3d14 [20635.429690] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x683D [20635.429691] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1D03D014 [20635.429693] VM fault (0x04, vmid 14) at page 26685, write from DMA1 (61) [20635.429708] radeon :01:00.0: GPU fault detected: 146 0x07bd3d14 [20635.429709] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [20635.429710] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1C03D00C [20635.429711] VM fault (0x0c, vmid 14) at page 0, read from DMA1 (61) ___ 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 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] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
On 08/09/2014 20:21, Grigori Goronzy wrote : On 08.09.2014 14:50, Axel Davy wrote: Hi, When reading si_dma.c code, it looks like the requested width of the copy is ignored except for PIPE_BUFFER. Perhaps that explains the bugs observed ? It isn't ignored. Partial DMA copies (i.e. operations that do not copy whole lines) are simply not supported right now, and will fall back to resource_copy_region. In fact, it's even stricter: the picthes of source and destination have to match. Grigori My point is I don't see a check to verify the width of the copy equals the width of the buffers, even if I see the pitch test. Axel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
On 08.09.2014 21:07, Axel Davy wrote: On 08/09/2014 20:21, Grigori Goronzy wrote : On 08.09.2014 14:50, Axel Davy wrote: Hi, When reading si_dma.c code, it looks like the requested width of the copy is ignored except for PIPE_BUFFER. Perhaps that explains the bugs observed ? It isn't ignored. Partial DMA copies (i.e. operations that do not copy whole lines) are simply not supported right now, and will fall back to resource_copy_region. In fact, it's even stricter: the picthes of source and destination have to match. Grigori My point is I don't see a check to verify the width of the copy equals the width of the buffers, even if I see the pitch test. There's a check for that (src_w != dst_w) in si_dma_copy. Grigori Axel ___ 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] Add support for NV_depth_buffer_float v2.
Do we have a piglit to confirm unclamped Z values really work with current hardware drivers? Marek On Mon, Sep 8, 2014 at 6:39 PM, Mathias Fröhlich mathias.froehl...@gmx.net wrote: Hi, On Monday, September 08, 2014 13:16:27 Roland Scheidegger wrote: Add support for the unclamped versions of glDepthRange and relatives. Also starting with OpenGL 4.2 the traditional functions for this should no longer clamp the values to [0, 1]. This looks wrong to me (the NV_depth_buffer part may be ok, just skimmed through it). The core functions still (some would probably say unfortunately...) clamp the values to [0,1]. Only 4.2 had language indicating otherwise, however this was retroactively fixed (see GL 4.3 spec, chapter F.5, Change Log for Released Specifications, page 647). Thanks for pointing this out. I did indeed only look at 4.2 where I did find hints that clamping got removed. Below the v2 patch that only avoids clamping when being called through the *NV functions. Greetings Mathias Add support for the unclamped versions of glDepthRange and relatives. Note that OpenGL 4.2 introduced that the traditonal glDepthRange functions may no longer clamp to [0, 1], but OpenGL 4.3 already revoked this behavior to clamp the arguments. Signed-off-by: Mathias Froehlich mathias.froehl...@web.de --- docs/GL3.txt | 1 + src/mapi/glapi/gen/NV_depth_buffer_float.xml | 24 src/mapi/glapi/gen/gl_API.xml| 2 + src/mesa/drivers/common/meta.c | 3 +- src/mesa/main/attrib.c | 6 +- src/mesa/main/depth.c| 82 +++- src/mesa/main/depth.h| 6 ++ src/mesa/main/dlist.c| 67 +++ src/mesa/main/extensions.c | 1 + src/mesa/main/viewport.c | 77 +- src/mesa/main/viewport.h | 9 ++- 11 files changed, 223 insertions(+), 55 deletions(-) create mode 100644 src/mapi/glapi/gen/NV_depth_buffer_float.xml diff --git a/docs/GL3.txt b/docs/GL3.txt index f5d5e72..9a3ceb9 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -144,6 +144,7 @@ GL 4.2, GLSL 4.20: GL_ARB_shading_language_420pack DONE (all drivers that support GLSL 1.30) GL_ARB_internalformat_query DONE (i965, nv50, nvc0, r300, r600, radeonsi, llvmpipe, softpipe) GL_ARB_map_buffer_alignment DONE (all drivers) + GL_NV_depth_buffer_float DONE (all drivers) GL 4.3, GLSL 4.30: diff --git a/src/mapi/glapi/gen/NV_depth_buffer_float.xml b/src/mapi/glapi/gen/NV_depth_buffer_float.xml new file mode 100644 index 000..17ee268 --- /dev/null +++ b/src/mapi/glapi/gen/NV_depth_buffer_float.xml @@ -0,0 +1,24 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +!-- Note: no GLX protocol info yet. -- + +OpenGLAPI + +category name=GL_NV_depth_buffer_float number=417 + +function name=DepthRangedNV offset=assign +param name=n type=GLdouble/ +param name=f type=GLdouble/ +/function +function name=ClearDepthdNV offset=assign +param name=d type=GLdouble/ +/function +function name=DepthBoundsdNV offset=assign +param name=zmin type=GLdouble/ +param name=zmax type=GLdouble/ +/function + +/category + +/OpenGLAPI diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 73f2f75..d504faf 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -13027,6 +13027,8 @@ xi:include href=NV_vdpau_interop.xml xmlns:xi=http://www.w3.org/2001/XInclude/ +xi:include href=NV_depth_buffer_float.xml xmlns:xi=http://www.w3.org/2001/XInclude/ + xi:include href=GL4x.xml xmlns:xi=http://www.w3.org/2001/XInclude/ /OpenGLAPI diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index 7a8e627..d165f12 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -1112,7 +1112,8 @@ _mesa_meta_end(struct gl_context *ctx) _mesa_set_viewport(ctx, 0, save-ViewportX, save-ViewportY, save-ViewportW, save-ViewportH); } - _mesa_DepthRange(save-DepthNear, save-DepthFar); + /* Need to call ...NV since this is guaranteed not to clamp to [0,1] */ + _mesa_DepthRangedNV(save-DepthNear, save-DepthFar); } if (state MESA_META_CLAMP_FRAGMENT_COLOR diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c index 2e289b6..7368ee1 100644 --- a/src/mesa/main/attrib.c +++ b/src/mesa/main/attrib.c @@ -1072,7 +1072,9 @@ _mesa_PopAttrib(void) const struct gl_depthbuffer_attrib *depth; depth = (const struct gl_depthbuffer_attrib *) attr-data;
[Mesa-dev] [PATCH 5/5] glsl: Recognize open-coded pow(x, y).
pow(x, y) is equivalent to exp(log(x) * y).
instructions in affected programs: 578 - 458 (-20.76%)
---
src/glsl/opt_algebraic.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 447618f..0cdb8ec 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -357,6 +357,20 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
if (op_expr[0]-operation == ir_unop_log2) {
return op_expr[0]-operands[0];
}
+
+ if (!options-EmitNoPow op_expr[0]-operation == ir_binop_mul) {
+ for (int log2_pos = 0; log2_pos 2; log2_pos++) {
+ir_expression *log2_expr =
+ op_expr[0]-operands[log2_pos]-as_expression();
+
+if (log2_expr log2_expr-operation == ir_unop_log2) {
+ return new(mem_ctx) ir_expression(ir_binop_pow,
+ ir-type,
+ log2_expr-operands[0],
+ op_expr[0]-operands[1 -
log2_pos]);
+}
+ }
+ }
break;
case ir_unop_log2:
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] i965/fs: Extend predicated break pass to predicate WHILE.
Helps a handful of programs in Serious Sam 3 that use do-while loops.
instructions in affected programs: 16114 - 16075 (-0.24%)
---
This patch depends on the save-cfg series.
.../dri/i965/brw_fs_peephole_predicated_break.cpp | 37 ++
1 file changed, 37 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
index 31b287a..66440d4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
@@ -38,6 +38,18 @@
*
* This peephole pass removes the IF and ENDIF instructions and predicates the
* BREAK, dropping two instructions from the loop body.
+ *
+ * If the loop was a DO { ... } WHILE loop, it looks like
+ *
+ * loop:
+ *...
+ *CMP.f0
+ *(+f0) IF
+ *BREAK
+ *ENDIF
+ *WHILE loop
+ *
+ * and we can remove the BREAK instruction and predicate the WHILE.
*/
bool
@@ -107,6 +119,31 @@ fs_visitor::opt_peephole_predicated_break()
block = earlier_block;
}
+ /* Now look at the first instruction of the block following the BREAK. If
+ * it's a WHILE, we can delete the break, predicate the WHILE, and join
+ * the two basic blocks.
+ */
+ bblock_t *while_block = earlier_block-next();
+ fs_inst *while_inst = (fs_inst *)while_block-start();
+
+ if (jump_inst-opcode == BRW_OPCODE_BREAK
+ while_inst-opcode == BRW_OPCODE_WHILE
+ while_inst-predicate == BRW_PREDICATE_NONE) {
+ jump_inst-remove(earlier_block);
+ while_inst-predicate = jump_inst-predicate;
+ while_inst-predicate_inverse = !jump_inst-predicate_inverse;
+
+ earlier_block-children.make_empty();
+ earlier_block-add_successor(cfg-mem_ctx, while_block);
+
+ assert(earlier_block-can_combine_with(while_block));
+ earlier_block-combine_with(while_block);
+
+ earlier_block-next()-parents.make_empty();
+ earlier_block-add_successor(cfg-mem_ctx, earlier_block-next());
+ }
+
+
progress = true;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] i965/fs: Ignore mov.sat instructions in interference check in sat prop.
When an instruction's result was consumed by multiple mov.sat
instructions, we would decide that we couldn't move the saturate
modifier because something else was using the result, even though it was
just another mov.sat!
total instructions in shared programs: 4275598 - 4274842 (-0.02%)
instructions in affected programs: 75634 - 74878 (-1.00%)
---
src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
index 6f8f8d0..6f7fb6c 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
@@ -67,7 +67,8 @@ opt_saturate_propagation_local(fs_visitor *v, bblock_t *block)
break;
}
for (int i = 0; i scan_inst-sources; i++) {
-if (scan_inst-src[i].file == GRF
+if ((scan_inst-opcode != BRW_OPCODE_MOV || !scan_inst-saturate)
+scan_inst-src[i].file == GRF
scan_inst-src[i].reg == inst-src[0].reg
scan_inst-src[i].reg_offset == inst-src[0].reg_offset) {
interfered = true;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] i965/fs: Walk instructions in reverse in saturate propagation.
When we find a mov.sat, we search backwards. We might as well search
everything else backwards as well and potentially look at fewer
instructions.
This change enables the next patch.
---
src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
index 4c4b6bf..6f8f8d0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
@@ -32,10 +32,10 @@ static bool
opt_saturate_propagation_local(fs_visitor *v, bblock_t *block)
{
bool progress = false;
- int ip = block-start_ip - 1;
+ int ip = block-end_ip + 1;
- foreach_inst_in_block(fs_inst, inst, block) {
- ip++;
+ foreach_inst_in_block_reverse(fs_inst, inst, block) {
+ ip--;
if (inst-opcode != BRW_OPCODE_MOV ||
inst-dst.file != GRF ||
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] i965/fs: Don't invalidate live intervals in saturate propagation.
--- src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp index 6f7fb6c..347a78e 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp @@ -95,8 +95,7 @@ fs_visitor::opt_saturate_propagation() progress = opt_saturate_propagation_local(this, block) || progress; } - if (progress) - invalidate_live_intervals(); + /* Live intervals are still valid. */ return progress; } -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/20] i965/fs: Make count_to_loop_end() use basic blocks.
On Tue, Sep 2, 2014 at 9:34 PM, Matt Turner matts...@gmail.com wrote:
When the instructions aren't in a flat list, this wouldn't have worked.
Also, this should be faster.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 28
+++
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 88f394d..7e391ea 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -190,27 +190,25 @@ brw_fs_alloc_reg_sets(struct intel_screen *screen)
brw_alloc_reg_set(screen, 2);
}
-int
-count_to_loop_end(fs_inst *do_inst)
+static int
+count_to_loop_end(bblock_t *block)
{
The predicated WHILE patch I sent lets us merge blocks such that a
block can start with a DO and end with a WHILE, so I'm going to add
+ if (block-end-opcode == BRW_OPCODE_WHILE)
+ return block-end_ip;
to the top of this function to handle that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570
--- Comment #11 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #10)
Could be totally borked, but this is what I have at the moment:
if (type.floating) {
return LLVMBuildFDiv(builder, a, b, );
}
else {
//The spec says divide by zero is undefined, but shouldn't throw an
exception
LLVMValueRef zeromask = lp_build_cmp(bld,
PIPE_FUNC_EQUAL,
b,
lp_build_zero(bld-gallivm,type));
if (type.sign) {
return lp_build_select(bld,
zeromask,
bld-undef,
LLVMBuildSDiv(builder, a, b, ));
}
else {
return lp_build_select(bld,
zeromask,
bld-undef,
LLVMBuildUDiv(builder, a, b, ));
}
}
I'll take a look at udiv_emit_cpu
Hmm that can't quite work since you still do the division by zero, you just
don't use the result in the end.
--
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] Add support for NV_depth_buffer_float v2.
Given that this was an unintentional relaxation in the 4.2 spec (and so there is no non-NV way to invoke this behavior), I don't think we want the line in the 4.2 block of GL3.txt. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/5] Fix handling of LnAn and RnGn formats for big-endian
Hi,
Thanks to Richard for these patches. Well done! Are these patches in the
latest Mesa version?
Rgds,
Christian
On 07/22/2014 03:51 AM, Richard Sandiford wrote:
MESA_FORMAT_LnAn_* puts the luminance in the low part of the integer and
the alpha in the high part. The same goes for MESA_FORMAT_RnGn with the
red and green channels.
This series fixes gallium to be consistent with that layout on
big-endian.
Following the convention established last year, PIPE_FORMAT_LAnn and
PIPE_FORMAT_RGnn are the equivalent gallium formats. Where defined,
PIPE_FORMAT_LnAn puts the luminance first in memory and the alpha
last in memory.
Patch 1 also fixes an endianness bug in mesa swrast for
MESA_FORMAT_L8A8_SRGB.
AFAICT all other L/A and R/G formats are handled correctly.
v2, with subject lines fixed to include the component: bit. No code
changes
from v1.
Richard Sandiford (5):
swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian
util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formats
util: Define PIPE_FORMAT_{LA,AL,RG,GR}nn aliases
mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}
st/mesa: Fix handling of LA and RG formats for big-endian
This series looks good to me.
Reviewed-by: Brian Paul brianp at vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
Le 08/09/2014 21:11, Grigori Goronzy a écrit : On 08.09.2014 21:07, Axel Davy wrote: On 08/09/2014 20:21, Grigori Goronzy wrote : On 08.09.2014 14:50, Axel Davy wrote: Hi, When reading si_dma.c code, it looks like the requested width of the copy is ignored except for PIPE_BUFFER. Perhaps that explains the bugs observed ? It isn't ignored. Partial DMA copies (i.e. operations that do not copy whole lines) are simply not supported right now, and will fall back to resource_copy_region. In fact, it's even stricter: the picthes of source and destination have to match. Grigori My point is I don't see a check to verify the width of the copy equals the width of the buffers, even if I see the pitch test. There's a check for that (src_w != dst_w) in si_dma_copy. Grigori I don't know exactly what src_x and dst_x represent, they are calculated by: src_w = rsrc-surface.level[src_level].npix_x; dst_w = rdst-surface.level[dst_level].npix_x; the width of the copy should be src_box-width Axel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83631] New: /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=83631 Priority: medium Bug ID: 83631 Assignee: mesa-dev@lists.freedesktop.org Summary: /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared Severity: normal Classification: Unclassified OS: All Reporter: or...@cora.nwra.com Hardware: All Status: NEW Version: git Component: GLX Product: Mesa Starting to see this in Fedora rawhide: In file included from /usr/include/GL/glx.h:333:0, from /builddir/build/BUILD/VTK-6.1.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:31: /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared Seems like GL should have defined that. Version-Release number of selected component (if applicable): mesa-libGL-devel-10.4-0.devel.2.1.80771e47b6c1e47ab55f17311e1d4e227a9eb3d8.fc22.x86_64 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ir_to_mesa: Stop converting uniform booleans.
Excess conversions considered harmful.
Recently Matt reworked the boolean uniform handling to use the value of
UniformBooleanTrue, rather than integer 1, when uploading uniforms:
mesa: Upload boolean uniforms using UniformBooleanTrue.
glsl: Use UniformBooleanTrue value for uniform initializers.
Marek then set the default to 1.0f for drivers without native integer
support:
mesa: set UniformBooleanTrue = 1.0f by default
However, ir_to_mesa was assuming a value of integer 1, and arranging for
it to be converted to 1.0f on upload. Since Marek's commit, we were
uploading 1.0f = 0x3f80 which was being interpreted as the integer
value 1065353216 and converted to float as 1.06535322E9, which broke
assumptions in ir_to_mesa that true was exactly 1.0f.
+13 Piglits on classic swrast (fs-bool-less-compare-true,
{vs,fs}-op-not-bool-using-if, glsl-1.20/execution/uniform-initializer).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83573
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/program/ir_to_mesa.cpp | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 49e4a7a..293fe34 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2505,12 +2505,7 @@ _mesa_associate_uniform_storage(struct gl_context *ctx,
columns = storage-type-matrix_columns;
break;
case GLSL_TYPE_BOOL:
- if (ctx-Const.NativeIntegers) {
- format = (ctx-Const.UniformBooleanTrue == 1)
- ? uniform_bool_int_0_1 : uniform_bool_int_0_not0;
- } else {
- format = uniform_bool_float;
- }
+ format = uniform_native;
columns = 1;
break;
case GLSL_TYPE_SAMPLER:
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ir_to_mesa: Stop converting uniform booleans.
On Mon, Sep 8, 2014 at 2:28 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Excess conversions considered harmful.
Recently Matt reworked the boolean uniform handling to use the value of
UniformBooleanTrue, rather than integer 1, when uploading uniforms:
mesa: Upload boolean uniforms using UniformBooleanTrue.
glsl: Use UniformBooleanTrue value for uniform initializers.
Marek then set the default to 1.0f for drivers without native integer
support:
mesa: set UniformBooleanTrue = 1.0f by default
However, ir_to_mesa was assuming a value of integer 1, and arranging for
it to be converted to 1.0f on upload. Since Marek's commit, we were
uploading 1.0f = 0x3f80 which was being interpreted as the integer
value 1065353216 and converted to float as 1.06535322E9, which broke
assumptions in ir_to_mesa that true was exactly 1.0f.
+13 Piglits on classic swrast (fs-bool-less-compare-true,
{vs,fs}-op-not-bool-using-if, glsl-1.20/execution/uniform-initializer).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83573
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/program/ir_to_mesa.cpp | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 49e4a7a..293fe34 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2505,12 +2505,7 @@ _mesa_associate_uniform_storage(struct gl_context *ctx,
columns = storage-type-matrix_columns;
break;
case GLSL_TYPE_BOOL:
- if (ctx-Const.NativeIntegers) {
- format = (ctx-Const.UniformBooleanTrue == 1)
- ? uniform_bool_int_0_1 : uniform_bool_int_0_not0;
- } else {
- format = uniform_bool_float;
- }
+ format = uniform_native;
columns = 1;
break;
case GLSL_TYPE_SAMPLER:
--
Nice. Thanks for fixing my bug! (and for doing the annoying work to
get swrast going)
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] [Mesa-stable] [PATCH] Suppress any libGL:... warnings when LIBGL_DEBUG == quiet
Looks good to me. Matches what ErrorMessageF is doing.
Reviewed-by: Courtney Goeltzenleuchter court...@lunarg.com
On Tue, Aug 26, 2014 at 2:47 PM, Johannes Obermayr johannesoberm...@gmx.de
wrote:
From: Stefan Dirsch sndir...@suse.de
Let's handle LIBGL_DEBUG env. variable in Mesa in a consistent way.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=892896
---
To: mesa-dev@lists.freedesktop.org
Cc: 10.3 mesa-sta...@lists.freedesktop.org
openSUSE maintainers: Why can't you forward your applied u_* patches to
upstream
to get them included in final/next release?
---
src/mesa/drivers/dri/common/xmlconfig.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index ce37647..8e48522 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -429,8 +429,10 @@ static void
__driUtilMessage(const char *f, ...)
{
va_list args;
+const char *libgl_debug;
-if (getenv(LIBGL_DEBUG)) {
+libgl_debug=getenv(LIBGL_DEBUG);
+if (libgl_debug !strstr(libgl_debug, quiet)) {
fprintf(stderr, libGL: );
va_start(args, f);
vfprintf(stderr, f, args);
--
2.0.4
___
mesa-stable mailing list
mesa-sta...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-stable
--
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC2014: Call for paper
Le 02/05/2014 00:52, Martin Peres a écrit : Hello, I have the pleasure to announce that the X.org Developer Conference 2014 will be held in Bordeaux, France from October 8th to October 10th. The venue is located in the campus of the University of Bordeaux 1, in the computer science research lab called LaBRI. The official page for the event is http://www.x.org/wiki/Events/XDC2014 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2014/ As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and opened to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering. I am looking forward to seeing you there, if you have any inquiries/questions, please send them to me (please also CC: bo...@foundation.x.org). Martin Peres Two days left for submitting your talk proposal for the XDC2014. After this date, the remaining slots will be attributed on a first-come, first-served basis. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=83631 --- Comment #1 from Brian Paul bri...@vmware.com --- Which version of glext.h (look for GL_GLEXT_VERSION)? In version 20140810 it's defined on line 469: typedef ptrdiff_t GLintptr; -- 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 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=83631 --- Comment #2 from Orion Poplawski or...@cora.nwra.com --- /usr/include/GL/glext.h:#define GL_GLEXT_VERSION 20140810 But we're including GL/glx.h which includes GL/glxext.h, not GL/glext.h. Too many x's floating around here. # grep '^typedef .* GLintptr;' /usr/include/GL/*.h /usr/include/GL/glcorearb.h:typedef ptrdiff_t GLintptr; /usr/include/GL/glext.h:typedef ptrdiff_t GLintptr; I'll keep digging. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] configure: enable the gallium loader only when needed
With the gallium megadrivers we've converted most ST to optionally use either statically linked in or shared pipe-drivers. The hardcoded switch forgot to conditionally enable the build of the shared pipe-drivers which resulted in them being constantly build. Cc: 10.3 mesa-sta...@lists.freedesktop.org Cc: James Ausmus james.aus...@intel.com Reported-by: James Ausmus james.aus...@intel.com Bugzilla: https://code.google.com/p/chromium/issues/detail?id=412089 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index 050bcaf..8ccb803 100644 --- a/configure.ac +++ b/configure.ac @@ -820,6 +820,11 @@ fi AM_CONDITIONAL(HAVE_SHARED_GLAPI, test x$enable_shared_glapi = xyes) +# Build the pipe-drivers as separate libraries/modules. +# Do not touch this unless you know what you are doing. +# XXX: Expose via configure option ? +enable_shared_pipe_drivers=no + dnl dnl Driver specific build directories dnl @@ -840,7 +845,7 @@ esac if test x$enable_dri = xyes; then GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/dri GALLIUM_STATE_TRACKERS_DIRS=dri $GALLIUM_STATE_TRACKERS_DIRS -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi if test x$enable_gallium_osmesa = xyes; then @@ -1313,7 +1318,8 @@ if test x$enable_gallium_egl = xyes; then GALLIUM_STATE_TRACKERS_DIRS=egl $GALLIUM_STATE_TRACKERS_DIRS GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS egl-static -#enable_gallium_loader=yes +# XXX: Uncomment once converted to use static/shared pipe-drivers +#enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_GALLIUM_EGL, test x$enable_gallium_egl = xyes) @@ -1342,7 +1348,7 @@ if test x$enable_gallium_gbm = xyes; then GALLIUM_STATE_TRACKERS_DIRS=gbm $GALLIUM_STATE_TRACKERS_DIRS GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS gbm -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_GALLIUM_GBM, test x$enable_gallium_gbm = xyes) @@ -1359,7 +1365,7 @@ if test x$enable_xa = xyes; then Example: ./configure --enable-xa --with-gallium-drivers=svga...]) fi GALLIUM_STATE_TRACKERS_DIRS=xa $GALLIUM_STATE_TRACKERS_DIRS -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_XA, test x$enable_xa = xyes) @@ -1407,7 +1413,7 @@ fi if test x$enable_xvmc = xyes; then PKG_CHECK_MODULES([XVMC], [xvmc = $XVMC_REQUIRED x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS xvmc -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_XVMC, test x$enable_xvmc = xyes) @@ -1415,14 +1421,14 @@ if test x$enable_vdpau = xyes; then PKG_CHECK_MODULES([VDPAU], [vdpau = $VDPAU_REQUIRED x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED], [VDPAU_LIBS=`$PKG_CONFIG --libs x11-xcb xcb-dri2`]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS vdpau -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_VDPAU, test x$enable_vdpau = xyes) if test x$enable_omx = xyes; then PKG_CHECK_MODULES([OMX], [libomxil-bellagio = $LIBOMXIL_BELLAGIO_REQUIRED x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS omx -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_OMX, test x$enable_omx = xyes) @@ -1474,6 +1480,7 @@ if test x$enable_opencl = xyes; then GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS clover GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS opencl +# XXX: Use $enable_shared_pipe_drivers once converted to use static/shared pipe-drivers enable_gallium_loader=yes if test x$enable_opencl_icd = xyes; then @@ -1774,6 +1781,7 @@ dnl dnl Gallium Tests dnl if test x$enable_gallium_tests = xyes; then +# XXX: Use $enable_shared_pipe_drivers once converted to use static/shared pipe-drivers enable_gallium_loader=yes fi AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test x$enable_gallium_tests = xyes) @@ -2069,9 +2077,7 @@ AM_CONDITIONAL(NEED_GALLIUM_SOFTPIPE_DRIVER, test x$HAVE_GALLIUM_SVGA = xyes - AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test x$HAVE_GALLIUM_SOFTPIPE = xyes \ test x$MESA_LLVM = x1) -# Enable static gallium targets for now. -# Do not touch this unless you know what you are doing. -AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test xyes = xyes) +AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test x$enable_shared_pipe_drivers = xno) # NOTE: anything using xcb or other client side libs ends up in separate # _CLIENT variables. The pipe loader is built in two variants, -- 2.0.2
[Mesa-dev] [PATCH 2/2] automake: remove obsolete NEED_GALLIUM_LOADER
Superseded by HAVE_LOADER_GALLIUM. The latter has a *DRM* brethren making the whose easier on which one to keep. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 1 - src/gallium/Makefile.am | 2 +- src/gallium/auxiliary/Makefile.am | 4 src/gallium/auxiliary/Makefile.sources| 2 -- src/gallium/auxiliary/pipe-loader/Makefile.am | 7 +-- 5 files changed, 6 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index 8ccb803..9930f43 100644 --- a/configure.ac +++ b/configure.ac @@ -1789,7 +1789,6 @@ AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test x$enable_gallium_tests = xyes) if test x$enable_gallium_loader = xyes; then GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS pipe-loader fi -AM_CONDITIONAL(NEED_GALLIUM_LOADER, test x$enable_gallium_loader = xyes) dnl Directory for VDPAU libs AC_ARG_WITH([vdpau-libdir], diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am index 1e1fd43..21b905c 100644 --- a/src/gallium/Makefile.am +++ b/src/gallium/Makefile.am @@ -114,7 +114,7 @@ endif ## Gallium state trackers and their users (targets) ## -if NEED_GALLIUM_LOADER +if HAVE_LOADER_GALLIUM SUBDIRS += targets/pipe-loader endif diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index 493d306..4d8ba89 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -1,5 +1,9 @@ AUTOMAKE_OPTIONS = subdir-objects +if HAVE_LOADER_GALLIUM +SUBDIRS := pipe-loader +endif + include Makefile.sources include $(top_srcdir)/src/gallium/Automake.inc diff --git a/src/gallium/auxiliary/Makefile.sources b/src/gallium/auxiliary/Makefile.sources index 9bfaa0e..58d8af7 100644 --- a/src/gallium/auxiliary/Makefile.sources +++ b/src/gallium/auxiliary/Makefile.sources @@ -1,5 +1,3 @@ -SUBDIRS := pipe-loader - C_SOURCES := \ cso_cache/cso_cache.c \ cso_cache/cso_context.c \ diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am b/src/gallium/auxiliary/pipe-loader/Makefile.am index ccdbea5..1204c79 100644 --- a/src/gallium/auxiliary/pipe-loader/Makefile.am +++ b/src/gallium/auxiliary/pipe-loader/Makefile.am @@ -8,10 +8,7 @@ AM_CPPFLAGS = $(DEFINES) \ -I$(top_srcdir)/src/gallium/auxiliary \ -I$(top_srcdir)/src/gallium/winsys -noinst_LTLIBRARIES = - -if HAVE_LOADER_GALLIUM -noinst_LTLIBRARIES += libpipe_loader.la +noinst_LTLIBRARIES = libpipe_loader.la noinst_LTLIBRARIES += libpipe_loader_client.la COMMON_SOURCES = \ @@ -43,5 +40,3 @@ libpipe_loader_client_la_CFLAGS = \ libpipe_loader_client_la_SOURCES = $(COMMON_SOURCES) libpipe_loader_client_la_LIBADD = $(COMMON_LIBADD) \ $(GALLIUM_PIPE_LOADER_CLIENT_LIBS) - -endif -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83636] New: [LLVM 3.5] Mesa32 build failure with LLVM 3.5.
https://bugs.freedesktop.org/show_bug.cgi?id=83636
Priority: medium
Bug ID: 83636
Assignee: mesa-dev@lists.freedesktop.org
Summary: [LLVM 3.5] Mesa32 build failure with LLVM 3.5.
Severity: normal
Classification: Unclassified
OS: All
Reporter: aaronbotte...@gmail.com
Hardware: Other
Status: NEW
Version: git
Component: Other
Product: Mesa
gallivm/lp_bld_debug.cpp:246:79: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:41:0:
/usr/include/llvm/Support/TargetRegistry.h:384:21: note: llvm::MCDisassembler*
llvm::Target::createMCDisassembler(const llvm::MCSubtargetInfo) const
MCDisassembler *createMCDisassembler(const MCSubtargetInfo STI) const {
^
/usr/include/llvm/Support/TargetRegistry.h:384:21: note: candidate expects 1
argument, 2 provided
Makefile:1706: recipe for target 'gallivm/lp_bld_debug.lo' failed
Seems they changed the arguments on this function or something along those
lines.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] meta: Avoid shader recompilation for msaa color resolve blit
On Sat, Sep 6, 2014 at 4:49 PM, Dave Airlie airl...@gmail.com wrote:
coverity reported a use before NULL check for src_rb in the below code,
maybe it was there already, but it noticed it now you changed it,
we check src_rb-NumSamples then later src_rb is checked. Could you take a
look.
Yes, the issue existed earlier as well. I'll take a look.
Dave.
const char *texcoord_type = vec2;
const int samples = MAX2(src_rb-NumSamples, 1);
+ int shader_offset = 0;
+
+ /* We expect only power of 2 samples in source multisample buffer. */
+ assert((samples (samples - 1)) == 0);
+ while (samples (shader_offset + 1)) {
+ shader_offset++;
+ }
+ /* Update the assert if we plan to support more than 16X MSAA. */
+ assert(shader_offset = 0 shader_offset = 4);
if (src_rb) {
src_datatype = _mesa_get_format_datatype(src_rb-Format);
@@ -109,13 +118,15 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
} else {
if (dst_is_msaa)
shader_index = BLIT_MSAA_SHADER_2D_MULTISAMPLE_COPY;
- else
-shader_index = BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE;
+ else {
+shader_index = BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE +
+ shader_offset;
+ }
}
if (target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY) {
- shader_index += (BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE -
- BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE);
+ shader_index += (BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE -
+ BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE);
sampler_array_suffix = Array;
texcoord_type = vec3;
}
@@ -123,19 +134,19 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
default:
_mesa_problem(ctx, Unkown texture target %s\n,
_mesa_lookup_enum_by_nr(target));
- shader_index = BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE;
+ shader_index = BLIT_2X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE;
}
/* We rely on the enum being sorted this way. */
- STATIC_ASSERT(BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE_INT ==
- BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE + 1);
- STATIC_ASSERT(BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE_UINT ==
- BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE + 2);
+ STATIC_ASSERT(BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE_INT ==
+ BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE + 5);
+ STATIC_ASSERT(BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE_UINT ==
+ BLIT_1X_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE + 10);
if (src_datatype == GL_INT) {
- shader_index++;
+ shader_index += 5;
vec4_prefix = i;
} else if (src_datatype == GL_UNSIGNED_INT) {
- shader_index += 2;
+ shader_index += 10;
vec4_prefix = u;
} else {
vec4_prefix = ;
@@ -147,9 +158,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_COPY ||
shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_COPY;
- if (blit-msaa_shaders[shader_index]
- (is_shader_msaa_depth_resolve_or_copy ||
-blit-samples == samples)) {
+ if (blit-msaa_shaders[shader_index]) {
_mesa_UseProgram(blit-msaa_shaders[shader_index]);
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 1/2] configure: enable the gallium loader only when needed
Thanks Emil - works great! Tested-by: James Ausmus james.aus...@intel.com On Mon, Sep 8, 2014 at 3:52 PM, Emil Velikov emil.l.veli...@gmail.com wrote: With the gallium megadrivers we've converted most ST to optionally use either statically linked in or shared pipe-drivers. The hardcoded switch forgot to conditionally enable the build of the shared pipe-drivers which resulted in them being constantly build. Cc: 10.3 mesa-sta...@lists.freedesktop.org Cc: James Ausmus james.aus...@intel.com Reported-by: James Ausmus james.aus...@intel.com Bugzilla: https://code.google.com/p/chromium/issues/detail?id=412089 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index 050bcaf..8ccb803 100644 --- a/configure.ac +++ b/configure.ac @@ -820,6 +820,11 @@ fi AM_CONDITIONAL(HAVE_SHARED_GLAPI, test x$enable_shared_glapi = xyes) +# Build the pipe-drivers as separate libraries/modules. +# Do not touch this unless you know what you are doing. +# XXX: Expose via configure option ? +enable_shared_pipe_drivers=no + dnl dnl Driver specific build directories dnl @@ -840,7 +845,7 @@ esac if test x$enable_dri = xyes; then GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/dri GALLIUM_STATE_TRACKERS_DIRS=dri $GALLIUM_STATE_TRACKERS_DIRS -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi if test x$enable_gallium_osmesa = xyes; then @@ -1313,7 +1318,8 @@ if test x$enable_gallium_egl = xyes; then GALLIUM_STATE_TRACKERS_DIRS=egl $GALLIUM_STATE_TRACKERS_DIRS GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS egl-static -#enable_gallium_loader=yes +# XXX: Uncomment once converted to use static/shared pipe-drivers +#enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_GALLIUM_EGL, test x$enable_gallium_egl = xyes) @@ -1342,7 +1348,7 @@ if test x$enable_gallium_gbm = xyes; then GALLIUM_STATE_TRACKERS_DIRS=gbm $GALLIUM_STATE_TRACKERS_DIRS GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS gbm -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_GALLIUM_GBM, test x$enable_gallium_gbm = xyes) @@ -1359,7 +1365,7 @@ if test x$enable_xa = xyes; then Example: ./configure --enable-xa --with-gallium-drivers=svga...]) fi GALLIUM_STATE_TRACKERS_DIRS=xa $GALLIUM_STATE_TRACKERS_DIRS -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_XA, test x$enable_xa = xyes) @@ -1407,7 +1413,7 @@ fi if test x$enable_xvmc = xyes; then PKG_CHECK_MODULES([XVMC], [xvmc = $XVMC_REQUIRED x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS xvmc -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_XVMC, test x$enable_xvmc = xyes) @@ -1415,14 +1421,14 @@ if test x$enable_vdpau = xyes; then PKG_CHECK_MODULES([VDPAU], [vdpau = $VDPAU_REQUIRED x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED], [VDPAU_LIBS=`$PKG_CONFIG --libs x11-xcb xcb-dri2`]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS vdpau -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_VDPAU, test x$enable_vdpau = xyes) if test x$enable_omx = xyes; then PKG_CHECK_MODULES([OMX], [libomxil-bellagio = $LIBOMXIL_BELLAGIO_REQUIRED x11-xcb xcb-dri2 = $XCBDRI2_REQUIRED]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS omx -enable_gallium_loader=yes +enable_gallium_loader=$enable_shared_pipe_drivers fi AM_CONDITIONAL(HAVE_ST_OMX, test x$enable_omx = xyes) @@ -1474,6 +1480,7 @@ if test x$enable_opencl = xyes; then GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS clover GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS opencl +# XXX: Use $enable_shared_pipe_drivers once converted to use static/shared pipe-drivers enable_gallium_loader=yes if test x$enable_opencl_icd = xyes; then @@ -1774,6 +1781,7 @@ dnl dnl Gallium Tests dnl if test x$enable_gallium_tests = xyes; then +# XXX: Use $enable_shared_pipe_drivers once converted to use static/shared pipe-drivers enable_gallium_loader=yes fi AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test x$enable_gallium_tests = xyes) @@ -2069,9 +2077,7 @@ AM_CONDITIONAL(NEED_GALLIUM_SOFTPIPE_DRIVER, test x$HAVE_GALLIUM_SVGA = xyes - AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test x$HAVE_GALLIUM_SOFTPIPE = xyes \ test x$MESA_LLVM = x1) -# Enable static gallium targets for now. -# Do not touch this unless you know what you are doing. -AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test xyes = xyes)
Re: [Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
On 09.09.2014 02:36, Alex Deucher wrote:
Updated version with comments integrated.
[...]
@@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
unsigned lpfn = 0;
/* force to pin into visible video ram */
- if (bo-placements[i].flags TTM_PL_FLAG_VRAM)
- lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
- else
+ if (bo-placements[i].flags TTM_PL_FLAG_VRAM) {
+ if (!(bo-flags RADEON_GEM_NO_CPU_ACCESS))
+ lpfn = bo-rdev-mc.visible_vram_size
PAGE_SHIFT;
+ } else {
lpfn = bo-rdev-mc.gtt_size PAGE_SHIFT; /* ??? */
+ }
The else block can be removed as well, but that can be done in another
patch.
Either way, v2 is
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/3] mesa/st: add ARB_texture_view support
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Roland, it was unclear to me whether you were happy with this change or not.
v2 - v3:
no change
src/mesa/state_tracker/st_atom_texture.c | 30
src/mesa/state_tracker/st_cb_fbo.c | 10 ++
src/mesa/state_tracker/st_cb_texture.c | 62 +++-
src/mesa/state_tracker/st_extensions.c | 1 +
src/mesa/state_tracker/st_format.c | 5 +--
src/mesa/state_tracker/st_texture.c | 15 ++--
6 files changed, 105 insertions(+), 18 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 03d0593..ed9a444 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -192,9 +192,9 @@ get_texture_format_swizzle(const struct st_texture_object
*stObj)
return swizzle_swizzle(stObj-base._Swizzle, tex_swizzle);
}
-
+
/**
- * Return TRUE if the texture's sampler view swizzle is equal to
+ * Return TRUE if the texture's sampler view swizzle is not equal to
* the texture's swizzle.
*
* \param stObj the st texture object,
@@ -214,9 +214,20 @@ check_sampler_swizzle(const struct st_texture_object
*stObj,
static unsigned last_level(struct st_texture_object *stObj)
{
- return MIN2(stObj-base._MaxLevel, stObj-pt-last_level);
+ unsigned ret = MIN2(stObj-base.MinLevel + stObj-base._MaxLevel,
+ stObj-pt-last_level);
+ if (stObj-base.Immutable)
+ ret = MIN2(ret, stObj-base.MinLevel + stObj-base.NumLevels - 1);
+ return ret;
}
+static unsigned last_layer(struct st_texture_object *stObj)
+{
+ if (stObj-base.Immutable)
+ return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
+ stObj-pt-array_size - 1);
+ return stObj-pt-array_size - 1;
+}
static struct pipe_sampler_view *
st_create_texture_sampler_view_from_stobj(struct pipe_context *pipe,
@@ -249,9 +260,13 @@ st_create_texture_sampler_view_from_stobj(struct
pipe_context *pipe,
templ.u.buf.first_element = f;
templ.u.buf.last_element = f + (n - 1);
} else {
- templ.u.tex.first_level = stObj-base.BaseLevel;
+ templ.u.tex.first_level = stObj-base.MinLevel + stObj-base.BaseLevel;
templ.u.tex.last_level = last_level(stObj);
assert(templ.u.tex.first_level = templ.u.tex.last_level);
+ templ.u.tex.first_layer = stObj-base.MinLayer;
+ templ.u.tex.last_layer = last_layer(stObj);
+ assert(templ.u.tex.first_layer = templ.u.tex.last_layer);
+ templ.target = gl_target_to_pipe(stObj-base.Target);
}
if (swizzle != SWIZZLE_NOOP) {
@@ -287,8 +302,11 @@ st_get_texture_sampler_view_from_stobj(struct st_context
*st,
if (*sv) {
if (check_sampler_swizzle(stObj, *sv) ||
(format != (*sv)-format) ||
- stObj-base.BaseLevel != (*sv)-u.tex.first_level ||
- last_level(stObj) != (*sv)-u.tex.last_level) {
+ gl_target_to_pipe(stObj-base.Target) != (*sv)-target ||
+ stObj-base.MinLevel + stObj-base.BaseLevel !=
(*sv)-u.tex.first_level ||
+ last_level(stObj) != (*sv)-u.tex.last_level ||
+ stObj-base.MinLayer != (*sv)-u.tex.first_layer ||
+ last_layer(stObj) != (*sv)-u.tex.last_layer) {
pipe_sampler_view_reference(sv, NULL);
}
}
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 7cfd3da..470ab27 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -450,6 +450,16 @@ st_update_renderbuffer_surface(struct st_context *st,
last_layer = strb-rtt_face + strb-rtt_slice;
}
+ /* Adjust for texture views */
+ if (strb-is_rtt) {
+ struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
+ first_layer += tex-MinLayer;
+ if (!strb-rtt_layered)
+ last_layer += tex-MinLayer;
+ else
+ last_layer = MIN2(first_layer + tex-NumLayers - 1, last_layer);
+ }
+
if (!strb-surface ||
strb-surface-texture-nr_samples != strb-Base.NumSamples ||
strb-surface-format != format ||
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index ad14bd9..dfa188a 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -829,12 +829,12 @@ st_TexSubImage(struct gl_context *ctx, GLuint dims,
blit.src.level = 0;
blit.src.format = src_format;
blit.dst.resource = dst;
- blit.dst.level = stObj-pt != stImage-pt ? 0 : texImage-Level;
+ blit.dst.level = stObj-pt != stImage-pt ? 0 :
texImage-TexObject-MinLevel + texImage-Level;
blit.dst.format = dst_format;
blit.src.box.x = blit.src.box.y = blit.src.box.z = 0;
blit.dst.box.x = xoffset;
blit.dst.box.y = yoffset;
- blit.dst.box.z = zoffset + texImage-Face;
+ blit.dst.box.z = zoffset + texImage-Face + texImage-TexObject-MinLayer;
[Mesa-dev] [PATCH v3 1/3] gallium: add a texture target to sampler view and a CAP to use it
This allows a sampler view to have a different texture target than the underlying resource. This will be used to implement the type casting between 2d arrays and cube maps as specified in ARB_texture_view. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Reviewed-by: Roland Scheidegger srol...@vmware.com --- Roland thought this change could benefit from another reviewer... volunteers? v2 - v3: - small adjustment to PIPE_CAP doc comment, included mention of ARB_texture_view - added Roland's R-b src/gallium/auxiliary/util/u_sampler.c | 1 + src/gallium/docs/source/screen.rst | 4 src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/gallium/include/pipe/p_state.h | 1 + 17 files changed, 20 insertions(+) diff --git a/src/gallium/auxiliary/util/u_sampler.c b/src/gallium/auxiliary/util/u_sampler.c index 227641b..86799fd 100644 --- a/src/gallium/auxiliary/util/u_sampler.c +++ b/src/gallium/auxiliary/util/u_sampler.c @@ -45,6 +45,7 @@ default_template(struct pipe_sampler_view *view, /* XXX: Check if format is compatible with texture-format. */ + view-target = texture-target; view-format = format; view-u.tex.first_level = 0; view-u.tex.last_level = texture-last_level; diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 13bf705..c83be12 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -226,6 +226,10 @@ The integer capabilities: * ``PIPE_CAP_CONDITIONAL_RENDER_INVERTED``: Whether the driver supports inverted condition for conditional rendering. * ``PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE``: The maximum supported vertex stride. +* ``PIPE_CAP_SAMPLER_VIEW_TARGET``: Whether the sampler view's target can be + different than the underlying resource's, as permitted by + ARB_texture_view. For example a 2d array texture may be reinterpreted as a + cube (array) texture and vice-versa. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 34594ae..461033a 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -218,6 +218,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 24e444f..9006734 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -234,6 +234,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT: case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 3f997a1..c56e0e5 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -438,6 +438,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 2da5208..e6597e9 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -253,6 +253,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_FAKE_SW_MSAA: return 1; diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index
[Mesa-dev] [PATCH v3 3/3] nv50,nvc0: enable ARB_texture_view
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Erm... oops, that will obviously modify 10.4.html relnotes, not 10.3. But no
one looks at these nouveau changes anyways...
docs/GL3.txt | 2 +-
docs/relnotes/10.3.html| 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
src/gallium/drivers/nouveau/nv50/nv50_tex.c| 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c| 4 ++--
6 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index f02ad67..5adc759 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -168,7 +168,7 @@ GL 4.3, GLSL 4.30:
GL_ARB_texture_buffer_range DONE (nv50, nvc0, i965,
r600, radeonsi, llvmpipe)
GL_ARB_texture_query_levels DONE (all drivers that
support GLSL 1.30)
GL_ARB_texture_storage_multisample DONE (all drivers that
support GL_ARB_texture_multisample)
- GL_ARB_texture_view DONE (i965)
+ GL_ARB_texture_view DONE (i965, nv50, nvc0)
GL_ARB_vertex_attrib_binding DONE (all drivers)
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index fa4ea23..68da8f4 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -63,6 +63,7 @@ Note: some of the new features are only available with
certain drivers.
liGL_ARB_texture_gather on r600, radeonsi/li
liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi,
softpipe/li
liGL_ARB_texture_query_lod on r600, radeonsi/li
+liGL_ARB_texture_view on nv50, nvc0/li
liGL_ARB_viewport_array on nvc0/li
liGL_AMD_vertex_shader_viewport_index on i965/gen7+, r600/li
liGL_OES_compressed_ETC1_RGB8_texture on nv30, nv50, nvc0, r300, r600,
radeonsi, softpipe, llvmpipe/li
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index b2a3019..3a46e72 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -171,6 +171,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TEXTURE_MULTISAMPLE:
case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
+ case PIPE_CAP_SAMPLER_VIEW_TARGET:
return 1;
case PIPE_CAP_SEAMLESS_CUBE_MAP:
return 1; /* class_3d = NVA0_3D_CLASS; */
@@ -203,7 +204,6 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_COMPUTE:
case PIPE_CAP_DRAW_INDIRECT:
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
- case PIPE_CAP_SAMPLER_VIEW_TARGET:
return 0;
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index 0d2604e..d69c8d6 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -58,10 +58,10 @@ nv50_create_sampler_view(struct pipe_context *pipe,
{
uint32_t flags = 0;
- if (res-target == PIPE_TEXTURE_RECT || res-target == PIPE_BUFFER)
+ if (templ-target == PIPE_TEXTURE_RECT || templ-target == PIPE_BUFFER)
flags |= NV50_TEXVIEW_SCALED_COORDS;
- return nv50_create_texture_view(pipe, res, templ, flags, res-target);
+ return nv50_create_texture_view(pipe, res, templ, flags, templ-target);
}
struct pipe_sampler_view *
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 4e7b8d6..3858981 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -170,6 +170,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
+ case PIPE_CAP_SAMPLER_VIEW_TARGET:
return 1;
case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
return (class_3d = NVE4_3D_CLASS) ? 1 : 0;
@@ -187,7 +188,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
case PIPE_CAP_FAKE_SW_MSAA:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
- case PIPE_CAP_SAMPLER_VIEW_TARGET:
return 0;
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
index 1b11bd0..db6b603 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
@@ -61,10 +61,10 @@ nvc0_create_sampler_view(struct pipe_context *pipe,
{
uint32_t flags = 0;
- if (res-target == PIPE_TEXTURE_RECT || res-target == PIPE_BUFFER)
+ if (templ-target == PIPE_TEXTURE_RECT || templ-target == PIPE_BUFFER)
flags |= NV50_TEXVIEW_SCALED_COORDS;
- return
Re: [Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
On 09.09.2014 09:47, Michel Dänzer wrote:
On 09.09.2014 02:36, Alex Deucher wrote:
Updated version with comments integrated.
[...]
@@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo
*bo, u32 domain, u64 max_offset,
unsigned lpfn = 0;
/* force to pin into visible video ram */
-if (bo-placements[i].flags TTM_PL_FLAG_VRAM)
-lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
-else
+if (bo-placements[i].flags TTM_PL_FLAG_VRAM) {
+if (!(bo-flags RADEON_GEM_NO_CPU_ACCESS))
+lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
+} else {
lpfn = bo-rdev-mc.gtt_size PAGE_SHIFT; /* ??? */
+}
The else block can be removed as well, but that can be done in another
patch.
Actually, I just noticed a problem, the following if statement:
if (max_offset)
lpfn = min (lpfn, (unsigned)(max_offset PAGE_SHIFT));
This will ignore max_offset if lpfn is 0. So either go with v1 of this hunk,
or rebase on top of the patch below.
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= michel.daen...@amd.com
Date: Tue, 9 Sep 2014 10:09:23 +0900
Subject: [PATCH] drm/radeon: Clean up assignment of TTM placement lpfn member
for pinning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
drivers/gpu/drm/radeon/radeon_object.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 908ea541..8ec8150 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -307,18 +307,14 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
}
radeon_ttm_placement_from_domain(bo, domain);
for (i = 0; i bo-placement.num_placement; i++) {
- unsigned lpfn = 0;
-
/* force to pin into visible video ram */
if (bo-placements[i].flags TTM_PL_FLAG_VRAM)
- lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
+ bo-placements[i].lpfn =
+ min(bo-rdev-mc.visible_vram_size, max_offset)
+PAGE_SHIFT;
else
- lpfn = bo-rdev-mc.gtt_size PAGE_SHIFT; /* ??? */
-
- if (max_offset)
- lpfn = min (lpfn, (unsigned)(max_offset PAGE_SHIFT));
+ bo-placements[i].lpfn = max_offset PAGE_SHIFT;
- bo-placements[i].lpfn = lpfn;
bo-placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
}
--
2.1.0
--
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
Re: [Mesa-dev] [PATCH 1/2] configure: enable the gallium loader only when needed
On Mon, Sep 8, 2014 at 4:56 PM, Ausmus, James james.aus...@intel.com wrote: Thanks Emil - works great! Tested-by: James Ausmus james.aus...@intel.com You know, if you care about image size, you shouldn't be building Gallium at all. Neither of the two Intel drivers use it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure: enable the gallium loader only when needed
On Mon, Sep 8, 2014 at 6:21 PM, Matt Turner matts...@gmail.com wrote: On Mon, Sep 8, 2014 at 4:56 PM, Ausmus, James james.aus...@intel.com wrote: Thanks Emil - works great! Tested-by: James Ausmus james.aus...@intel.com You know, if you care about image size, you shouldn't be building Gallium at all. Neither of the two Intel drivers use it. Well, I guess you might be shipping i915g. Not sure. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading
Am 05.09.2014 00:14, schrieb Glenn Kennard: Also fixes two sided lighting which was broken at least on pre-evergreen by commit b1eb00. Maybe there is a (Mesa-demos) test case around? Signed-off-by: Glenn Kennard glenn.kenn...@gmail.com --- Changes since patch v1: Factor out and set sample positions also for pre-evergreen Misc r600 breakage fixes Some cleanup Passes piglit without regressions on radeon 6670. Cayman and pre-evergreen still needs testing before committing. Hello Glenn, I have it running on RV730 AGP, but no (demanding) games or piglit, here (system is too weak). Can you point me to some (smaller) tests? Under current git (4ea1565) I get this warnings: Making all in drivers/r600 gmake[3]: Entering directory `/opt/mesa/src/gallium/drivers/r600' CC compute_memory_pool.lo compute_memory_pool.c: In function 'compute_memory_prealloc_chunk': compute_memory_pool.c:123:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'int64_t' [-Wformat=] COMPUTE_DBG(pool-screen, * compute_memory_prealloc_chunk() size_in_dw = %ld\n, ^ compute_memory_pool.c: In function 'compute_memory_postalloc_chunk': compute_memory_pool.c:154:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'int64_t' [-Wformat=] COMPUTE_DBG(pool-screen, * compute_memory_postalloc_chunck() start_in_dw = %ld\n, ^ compute_memory_pool.c: In function 'compute_memory_free': compute_memory_pool.c:571:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'int64_t' [-Wformat=] COMPUTE_DBG(pool-screen, * compute_memory_free() id + %ld \n, id); ^ compute_memory_pool.c: In function 'compute_memory_alloc': compute_memory_pool.c:631:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'int64_t' [-Wformat=] COMPUTE_DBG(pool-screen, * compute_memory_alloc() size_in_dw = %ld (%ld bytes)\n, ^ compute_memory_pool.c:631:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'int64_t' [-Wformat=] GREAT work! Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83636] [LLVM 3.5] Mesa32 build failure with LLVM 3.5.
https://bugs.freedesktop.org/show_bug.cgi?id=83636 Vladimir Ysikov granti...@gmail.com changed: What|Removed |Added CC||granti...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g, radeonsi: Set RADEON_GEM_NO_CPU_ACCESS flag for tiled BOs
From: Michel Dänzer michel.daen...@amd.com
This lets the kernel know that such BOs can be pinned outside of the CPU
accessible part of VRAM.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c | 1 +
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 12 +---
src/gallium/winsys/radeon/drm/radeon_winsys.h | 5 +++--
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index d85b64b..227a221 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -156,6 +156,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
rtex-surface.level[0].mode = RADEON_SURF_MODE_1D) {
res-domains = RADEON_DOMAIN_VRAM;
flags = ~RADEON_FLAG_CPU_ACCESS;
+ flags |= RADEON_FLAG_NO_CPU_ACCESS;
}
/* Allocate a new resource. */
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 5a5a2f1..e61e9fd 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -477,11 +477,15 @@ const struct pb_vtbl radeon_bo_vtbl = {
};
#ifndef RADEON_GEM_GTT_WC
-#define RADEON_GEM_GTT_WC (1 2)
+#define RADEON_GEM_GTT_WC (1 2)
#endif
-#ifndef RADEON_GTM_CPU_ACCESS
+#ifndef RADEON_GEM_CPU_ACCESS
/* BO is expected to be accessed by the CPU */
-#define RADEON_GEM_CPU_ACCESS (1 3)
+#define RADEON_GEM_CPU_ACCESS (1 3)
+#endif
+#ifndef RADEON_GEM_NO_CPU_ACCESS
+/* CPU access is not expected to work for this BO */
+#define RADEON_GEM_NO_CPU_ACCESS (1 4)
#endif
static struct pb_buffer *radeon_bomgr_create_bo(struct pb_manager *_mgr,
@@ -510,6 +514,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct
pb_manager *_mgr,
args.flags |= RADEON_GEM_GTT_WC;
if (rdesc-flags RADEON_FLAG_CPU_ACCESS)
args.flags |= RADEON_GEM_CPU_ACCESS;
+if (rdesc-flags RADEON_FLAG_NO_CPU_ACCESS)
+args.flags |= RADEON_GEM_NO_CPU_ACCESS;
if (drmCommandWriteRead(rws-fd, DRM_RADEON_GEM_CREATE,
args, sizeof(args))) {
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index 69bf6ed..18fefbe 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -66,8 +66,9 @@ enum radeon_bo_domain { /* bitfield */
};
enum radeon_bo_flag { /* bitfield */
-RADEON_FLAG_GTT_WC = (1 0),
-RADEON_FLAG_CPU_ACCESS = (1 1),
+RADEON_FLAG_GTT_WC =(1 0),
+RADEON_FLAG_CPU_ACCESS =(1 1),
+RADEON_FLAG_NO_CPU_ACCESS = (1 2),
};
enum radeon_bo_usage { /* bitfield */
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
