date:20140224

Before you read any further, this is nowhere close to working. However it's in
a state where I think most of the structure is there, albeit with a lot of XXX
comments. And I haven't actually implemented the new opcodes I've added.

I was hoping one or two Intel people could take a look at this and let me know
of any pitfalls I'm likely to run into. I've already gotten a lot of help and
advice from Ken, but wanted to put something out publicly.

Any and all feedback much appreciated!

Not-Signed-off-by: Ilia Mirkin imir...@alum.mit.edu

---
 src/mesa/drivers/dri/i965/Makefile.sources|   1 +
 src/mesa/drivers/dri/i965/brw_defines.h   |  13 +
 src/mesa/drivers/dri/i965/brw_vec4.h  |   1 +
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp |  36 ++-
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h   |   5 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp|  14 ++
 src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp | 285 ++
 src/mesa/drivers/dri/i965/gen6_gs_visitor.h   |  63 +
 8 files changed, 405 insertions(+), 13 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp
 create mode 100644 src/mesa/drivers/dri/i965/gen6_gs_visitor.h

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index dc30eb3..96b637f 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -119,6 +119,7 @@ i965_FILES = \
gen6_clip_state.c \
gen6_depthstencil.c \
gen6_gs_state.c \
+   gen6_gs_visitor.cpp \
 gen6_multisample_state.c \
gen6_queryobj.c \
gen6_sampler_state.c \
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 01d3cb6..a24919c 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -909,6 +909,19 @@ enum opcode {
 * - dst is the GRF for gl_InvocationID.
 */
GS_OPCODE_GET_INSTANCE_ID,
+
+   /**
+* Sets DWORD 2 of dst to the value in src DWORD 0. Used by geometry
+* shaders to initialize DWORD 2 of the message header, which contains
+* primitive start/end flags.
+*/
+   GS_OPCODE_SET_DWORD_2,
+
+   /**
+* Emits a FF_SYNC, which on Gen6 returns a VUE handle, which is needed to
+* emit state in GS.
+*/
+   GS_OPCODE_FF_SYNC,
 };
 
 enum brw_urb_write_flags {
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 6bd8b80..14d67b7 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -130,6 +130,7 @@ public:
bool is_one() const;
 
src_reg(class vec4_visitor *v, const struct glsl_type *type);
+   src_reg(class vec4_visitor *v, const struct glsl_type *type, int size);
 
explicit src_reg(dst_reg reg);
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 0a2d8ff..ede9002 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -28,6 +28,7 @@
  */
 
 #include brw_vec4_gs_visitor.h
+#include gen6_gs_visitor.h
 
 const unsigned MAX_GS_INPUT_VERTICES = 6;
 
@@ -587,6 +588,8 @@ brw_gs_emit(struct brw_context *brw,
 {
struct brw_shader *shader =
   (brw_shader *) prog-_LinkedShaders[MESA_SHADER_GEOMETRY];
+   vec4_gs_visitor *gs;
+   const unsigned *ret = NULL;
 
if (unlikely(INTEL_DEBUG  DEBUG_GS)) {
   printf(GLSL IR for native geometry shader %d:\n, prog-Name);
@@ -602,12 +605,17 @@ brw_gs_emit(struct brw_context *brw,
likely(!(INTEL_DEBUG  DEBUG_NO_DUAL_OBJECT_GS))) {
   c-prog_data.dual_instanced_dispatch = false;
 
-  vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills */);
-  if (v.run()) {
- return generate_assembly(brw, prog, c-gp-program.Base,
-  c-prog_data.base, mem_ctx, v.instructions,
-  final_assembly_size);
+  if (brw-gen = 7)
+ gs = new vec4_gs_visitor(brw, c, prog, shader, mem_ctx, true /* 
no_spills */);
+  else
+ gs = new gen6_gs_visitor(brw, c, prog, shader, mem_ctx, true /* 
no_spills */);
+  if (gs-run()) {
+ ret = generate_assembly(brw, prog, c-gp-program.Base,
+ c-prog_data.base, mem_ctx, 
gs-instructions,
+ final_assembly_size);
+ goto done;
   }
+  delete gs;
}
 
/* Either we failed to compile in DUAL_OBJECT mode (probably because it
@@ -622,15 +630,21 @@ brw_gs_emit(struct brw_context *brw,
 */
c-prog_data.dual_instanced_dispatch = true;
 
-   vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, false /* no_spills */);
-   if (!v.run()) {
+   if (brw-gen = 7)
+  gs = new vec4_gs_visitor(brw, c, prog, shader, mem_ctx, false /* 
no_spills */);
+   else
+  gs = new

[Mesa-dev] gallium and ARB_texture_query_levels

2014-02-24 Thread Dave Airlie

I've taken a quick look at ARB_texture_query_levels,

and the HW generally seems to implement this by returning it in the W
channel of RESINFO, which would map to the TXQ instruction,

So my initial implementation added a LEVQ TGSI instruction but I do
think this isn't representative of the hw and I should add it to TXQ
with maybe a CAP to say it supports levels.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] R600/SI: Optimize SI_KILL for constant operands

From: Michel Dänzer michel.daen...@amd.com

If the SI_KILL operand is constant, we can either clear the exec mask if
the operand is negative, or do nothing otherwise.

Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
 lib/Target/R600/SIInstructions.td  |  4 ++--
 lib/Target/R600/SILowerControlFlow.cpp | 25 ++---
 test/CodeGen/R600/llvm.AMDGPU.kill.ll  | 10 +++---
 3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/lib/Target/R600/SIInstructions.td 
b/lib/Target/R600/SIInstructions.td
index 9da05c3..bd75539 100644
--- a/lib/Target/R600/SIInstructions.td
+++ b/lib/Target/R600/SIInstructions.td
@@ -1330,7 +1330,7 @@ def SI_END_CF : InstSI 
 
 def SI_KILL : InstSI 
   (outs),
-  (ins VReg_32:$src),
+  (ins SSrc_32:$src),
   SI_KILL $src,
   [(int_AMDGPU_kill f32:$src)]
 ;
@@ -1422,7 +1422,7 @@ def : Pat
 
 def : Pat 
   (int_AMDGPU_kilp),
-  (SI_KILL (V_MOV_B32_e32 0xbf80))
+  (SI_KILL 0xbf80)
 ;
 
 /* int_SI_vs_load_input */
diff --git a/lib/Target/R600/SILowerControlFlow.cpp 
b/lib/Target/R600/SILowerControlFlow.cpp
index 1fe620b..e04dd89 100644
--- a/lib/Target/R600/SILowerControlFlow.cpp
+++ b/lib/Target/R600/SILowerControlFlow.cpp
@@ -55,6 +55,7 @@
 #include llvm/CodeGen/MachineFunctionPass.h
 #include llvm/CodeGen/MachineInstrBuilder.h
 #include llvm/CodeGen/MachineRegisterInfo.h
+#include llvm/IR/Constants.h
 
 using namespace llvm;
 
@@ -82,7 +83,7 @@ private:
   void Loop(MachineInstr MI);
   void EndCf(MachineInstr MI);
 
-  void Kill(MachineInstr MI);
+  void Kill(MachineInstr MI, unsigned Depth);
   void Branch(MachineInstr MI);
 
   void LoadM0(MachineInstr MI, MachineInstr *MovRel);
@@ -301,9 +302,10 @@ void SILowerControlFlowPass::Branch(MachineInstr MI) {
   // If these aren't equal, this is probably an infinite loop.
 }
 
-void SILowerControlFlowPass::Kill(MachineInstr MI) {
+void SILowerControlFlowPass::Kill(MachineInstr MI, unsigned Depth) {
   MachineBasicBlock MBB = *MI.getParent();
   DebugLoc DL = MI.getDebugLoc();
+  const MachineOperand Op = MI.getOperand(0);
 
   // Kill is only allowed in pixel / geometry shaders
   assert(MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
@@ -311,10 +313,19 @@ void SILowerControlFlowPass::Kill(MachineInstr MI) {
  MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
  ShaderType::GEOMETRY);
 
-  // Clear this pixel from the exec mask if the operand is negative
-  BuildMI(MBB, MI, DL, TII-get(AMDGPU::V_CMPX_LE_F32_e32), AMDGPU::VCC)
-  .addImm(0)
-  .addOperand(MI.getOperand(0));
+  // Clear this thread from the exec mask if the operand is negative
+  if ((Op.isImm() || Op.isFPImm())) {
+// Constant operand: Set exec mask to 0 or do nothing
+if (Op.isImm() ? (Op.getImm()  0x8000) :
+Op.getFPImm()-isNegative()) {
+  BuildMI(MBB, MI, DL, TII-get(AMDGPU::S_MOV_B64), AMDGPU::EXEC)
+  .addImm(0);
+}
+  } else {
+BuildMI(MBB, MI, DL, TII-get(AMDGPU::V_CMPX_LE_F32_e32), AMDGPU::VCC)
+   .addImm(0)
+   .addOperand(MI.getOperand(0));
+  }
 
   MI.eraseFromParent();
 }
@@ -488,7 +499,7 @@ bool 
SILowerControlFlowPass::runOnMachineFunction(MachineFunction MF) {
 SkipIfDead(MI);
   else
 HaveKill = true;
-  Kill(MI);
+  Kill(MI, Depth);
   break;
 
 case AMDGPU::S_BRANCH:
diff --git a/test/CodeGen/R600/llvm.AMDGPU.kill.ll 
b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
index 0abe694..8e82282 100644
--- a/test/CodeGen/R600/llvm.AMDGPU.kill.ll
+++ b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
@@ -1,13 +1,17 @@
 ; RUN: llc  %s -march=r600 -mcpu=verde -verify-machineinstrs | FileCheck 
--check-prefix=SI-CHECK %s
 
-; SI-LABEL: @kill_gs
-; SI-CHECK: V_CMPX_LE_F32
+; SI-LABEL: @kill_gs_const
+; SI-CHECK-NOT: V_CMPX_LE_F32
+; SI-CHECK: S_MOV_B64 exec, 0
 
-define void @kill_gs() #0 {
+define void @kill_gs_const() #0 {
 main_body:
   %0 = icmp ule i32 0, 3
   %1 = select i1 %0, float 1.00e+00, float -1.00e+00
   call void @llvm.AMDGPU.kill(float %1)
+  %2 = icmp ule i32 3, 0
+  %3 = select i1 %2, float 1.00e+00, float -1.00e+00
+  call void @llvm.AMDGPU.kill(float %3)
   ret void
 }
 
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] R600/SI: Allow SI_KILL for geometry shaders

From: Michel Dänzer michel.daen...@amd.com

Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
 lib/Target/R600/SILowerControlFlow.cpp | 50 ++
 test/CodeGen/R600/llvm.AMDGPU.kill.ll  | 18 
 2 files changed, 50 insertions(+), 18 deletions(-)
 create mode 100644 test/CodeGen/R600/llvm.AMDGPU.kill.ll

diff --git a/lib/Target/R600/SILowerControlFlow.cpp 
b/lib/Target/R600/SILowerControlFlow.cpp
index f6f9016..1fe620b 100644
--- a/lib/Target/R600/SILowerControlFlow.cpp
+++ b/lib/Target/R600/SILowerControlFlow.cpp
@@ -151,22 +151,34 @@ void SILowerControlFlowPass::SkipIfDead(MachineInstr MI) 
{
   MachineBasicBlock::iterator Insert = MI;
   ++Insert;
 
-  // If the exec mask is non-zero, skip the next two instructions
-  BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_CBRANCH_EXECNZ))
-  .addImm(3)
-  .addReg(AMDGPU::EXEC);
-
-  // Exec mask is zero: Export to NULL target...
-  BuildMI(MBB, Insert, DL, TII-get(AMDGPU::EXP))
-  .addImm(0)
-  .addImm(0x09) // V_008DFC_SQ_EXP_NULL
-  .addImm(0)
-  .addImm(1)
-  .addImm(1)
-  .addReg(AMDGPU::VGPR0)
-  .addReg(AMDGPU::VGPR0)
-  .addReg(AMDGPU::VGPR0)
-  .addReg(AMDGPU::VGPR0);
+  if (MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
+  ShaderType::PIXEL) {
+// If the exec mask is non-zero, skip the next two instructions
+BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_CBRANCH_EXECNZ))
+.addImm(3)
+.addReg(AMDGPU::EXEC);
+
+// Exec mask is zero: Export to NULL target...
+BuildMI(MBB, Insert, DL, TII-get(AMDGPU::EXP))
+.addImm(0)
+.addImm(0x09) // V_008DFC_SQ_EXP_NULL
+.addImm(0)
+.addImm(1)
+.addImm(1)
+.addReg(AMDGPU::VGPR0)
+.addReg(AMDGPU::VGPR0)
+.addReg(AMDGPU::VGPR0)
+.addReg(AMDGPU::VGPR0);
+  } else {
+// If the exec mask is non-zero, skip the next two instructions
+BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_CBRANCH_EXECNZ))
+.addImm(2)
+.addReg(AMDGPU::EXEC);
+
+// Signal GS done
+BuildMI(MBB, MI, DL, TII-get(AMDGPU::S_SENDMSG))
+.addImm(3);
+  }
 
   // ... and terminate wavefront
   BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_ENDPGM));
@@ -293,9 +305,11 @@ void SILowerControlFlowPass::Kill(MachineInstr MI) {
   MachineBasicBlock MBB = *MI.getParent();
   DebugLoc DL = MI.getDebugLoc();
 
-  // Kill is only allowed in pixel shaders
+  // Kill is only allowed in pixel / geometry shaders
   assert(MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
- ShaderType::PIXEL);
+ ShaderType::PIXEL ||
+ MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
+ ShaderType::GEOMETRY);
 
   // Clear this pixel from the exec mask if the operand is negative
   BuildMI(MBB, MI, DL, TII-get(AMDGPU::V_CMPX_LE_F32_e32), AMDGPU::VCC)
diff --git a/test/CodeGen/R600/llvm.AMDGPU.kill.ll 
b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
new file mode 100644
index 000..0abe694
--- /dev/null
+++ b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
@@ -0,0 +1,18 @@
+; RUN: llc  %s -march=r600 -mcpu=verde -verify-machineinstrs | FileCheck 
--check-prefix=SI-CHECK %s
+
+; SI-LABEL: @kill_gs
+; SI-CHECK: V_CMPX_LE_F32
+
+define void @kill_gs() #0 {
+main_body:
+  %0 = icmp ule i32 0, 3
+  %1 = select i1 %0, float 1.00e+00, float -1.00e+00
+  call void @llvm.AMDGPU.kill(float %1)
+  ret void
+}
+
+declare void @llvm.AMDGPU.kill(float)
+
+attributes #0 = { ShaderType=2 }
+
+!0 = metadata !{metadata !const, null, i32 1}
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium and ARB_texture_query_levels

On Mon, Feb 24, 2014 at 3:38 AM, Dave Airlie airl...@gmail.com wrote:
 I've taken a quick look at ARB_texture_query_levels,

 and the HW generally seems to implement this by returning it in the W
 channel of RESINFO, which would map to the TXQ instruction,

 So my initial implementation added a LEVQ TGSI instruction but I do
 think this isn't representative of the hw and I should add it to TXQ
 with maybe a CAP to say it supports levels.

Is there even hw that supports TXQ but doesn't return the levels info
in W? A quick grep suggests that llvmpipe, ilo, nv50+, r600+ support
TXQ. I assume that llvmpipe shouldn't be an issue, nv50+ has it, and I
believe you've indicated that r600+ has it. So the question is whether
ilo can do it or not... looking at the i965 code, it seems like ir_txs
and ir_query_levels are handled with the same shader opcode. And
there's a comment /* # levels is in .w */...

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: Prevent geometry shader from emitting too many vertices

From: Michel Daenzer michel.daen...@amd.com

Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
 src/gallium/drivers/radeonsi/si_shader.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 54270cd..b22db0b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1905,6 +1905,7 @@ static void si_llvm_emit_vertex(
LLVMValueRef soffset = LLVMGetParam(si_shader_ctx-radeon_bld.main_fn,
SI_PARAM_GS2VS_OFFSET);
LLVMValueRef gs_next_vertex;
+   LLVMValueRef can_emit, kill;
LLVMValueRef t_list_ptr;
LLVMValueRef t_list;
LLVMValueRef args[2];
@@ -1934,6 +1935,21 @@ static void si_llvm_emit_vertex(
 
/* Write vertex attribute values to GSVS ring */
gs_next_vertex = LLVMBuildLoad(gallivm-builder, 
si_shader_ctx-gs_next_vertex, );
+
+   /* If this thread has already emitted the declared maximum number of
+* vertices, kill it: excessive vertex emissions are not supposed to
+* have any effect, and GS threads have no externally observable
+* effects other than emitting vertices.
+*/
+   can_emit = LLVMBuildICmp(gallivm-builder, LLVMIntULE, gs_next_vertex,
+lp_build_const_int32(gallivm,
+ 
shader-gs_max_out_vertices), );
+   kill = lp_build_select(bld_base-base, can_emit,
+  lp_build_const_float(gallivm, 1.0f),
+  lp_build_const_float(gallivm, -1.0f));
+   build_intrinsic(gallivm-builder, llvm.AMDGPU.kill,
+   LLVMVoidTypeInContext(gallivm-context), kill, 1, 0);
+
for (i = 0; i  shader-noutput; i++) {
LLVMValueRef *out_ptr =

si_shader_ctx-radeon_bld.soa.outputs[shader-output[i].index];
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] winsys/svga: Avoid calling drm getparam for max surface size on older kernels

2014-02-24 Thread Thomas Hellstrom

This avoids the kernel driver spewing out errors about the param not being
supported.

Also correct the max surface size used when the kernel does not support the
query.

Reported-by: Brian Paul bri...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Reviewed-by: Charmaine Lee charmai...@vmware.com
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
 src/gallium/winsys/svga/drm/vmw_screen_ioctl.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c 
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index b7bedb1..2866a29 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -762,7 +762,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
int ret;
uint32_t *cap_buffer;
drmVersionPtr version;
-   boolean drm_gb_capable;
+   boolean have_drm_2_5;
 
VMW_FUNC;
 
@@ -770,7 +770,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
if (!version)
   goto out_no_version;
 
-   drm_gb_capable = version-version_major  2 ||
+   have_drm_2_5 = version-version_major  2 ||
   (version-version_major == 2  version-version_minor  4);
 
memset(gp_arg, 0, sizeof(gp_arg));
@@ -803,7 +803,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
   vws-base.have_gb_objects =
  !!(gp_arg.value  (uint64_t) SVGA_CAP_GBOBJECTS);

-   if (vws-base.have_gb_objects  !drm_gb_capable)
+   if (vws-base.have_gb_objects  !have_drm_2_5)
   goto out_no_3d;
 
if (vws-base.have_gb_objects) {
@@ -839,11 +839,12 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
 
   memset(gp_arg, 0, sizeof(gp_arg));
   gp_arg.param = DRM_VMW_PARAM_MAX_SURF_MEMORY;
-  ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_GET_PARAM,
-gp_arg, sizeof(gp_arg));
-  if (ret) {
+  if (have_drm_2_5)
+ ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_GET_PARAM,
+   gp_arg, sizeof(gp_arg));
+  if (!have_drm_2_5 || ret) {
  /* Just guess a large enough value, around 800mb. */
- vws-ioctl.max_surface_memory = 0x3;
+ vws-ioctl.max_surface_memory = 0x3000;
   } else {
  vws-ioctl.max_surface_memory = gp_arg.value;
   }
-- 
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium and ARB_texture_query_levels

2014-02-24 Thread Chia-I Wu

On Mon, Feb 24, 2014 at 5:03 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 On Mon, Feb 24, 2014 at 3:38 AM, Dave Airlie airl...@gmail.com wrote:
 I've taken a quick look at ARB_texture_query_levels,

 and the HW generally seems to implement this by returning it in the W
 channel of RESINFO, which would map to the TXQ instruction,

 So my initial implementation added a LEVQ TGSI instruction but I do
 think this isn't representative of the hw and I should add it to TXQ
 with maybe a CAP to say it supports levels.

 Is there even hw that supports TXQ but doesn't return the levels info
 in W? A quick grep suggests that llvmpipe, ilo, nv50+, r600+ support
 TXQ. I assume that llvmpipe shouldn't be an issue, nv50+ has it, and I
 believe you've indicated that r600+ has it. So the question is whether
 ilo can do it or not... looking at the i965 code, it seems like ir_txs
 and ir_query_levels are handled with the same shader opcode. And
 there's a comment /* # levels is in .w */...
Yes, GENs supported by ilo have it in W of RESINFO.


   -ilia
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev



-- 
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium and ARB_texture_query_levels

Using TXQ for this sounds good to me.

Marek

On Mon, Feb 24, 2014 at 9:38 AM, Dave Airlie airl...@gmail.com wrote:
 I've taken a quick look at ARB_texture_query_levels,

 and the HW generally seems to implement this by returning it in the W
 channel of RESINFO, which would map to the TXQ instruction,

 So my initial implementation added a LEVQ TGSI instruction but I do
 think this isn't representative of the hw and I should add it to TXQ
 with maybe a CAP to say it supports levels.

 Dave.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/targets: resolve undefined reference to

With the introduction of the pipe_loader_sw_probe_dri helper we
require the sw/dri winsys during linking stage despite it being
unused by any of the targets. This will cause a minor increase
in the resulting library which will be cleaned up via linker
options with upcoming patches.

Cc: Tom Stellard thomas.stell...@amd.com
Reported-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---

This should cover the final breakages caused by the recent
pipe-loader changes.

-Emil 

 src/gallium/targets/gbm/Makefile.am| 1 +
 src/gallium/targets/opencl/Makefile.am | 1 +
 src/gallium/targets/xa/Makefile.am | 1 +
 3 files changed, 3 insertions(+)

diff --git a/src/gallium/targets/gbm/Makefile.am 
b/src/gallium/targets/gbm/Makefile.am
index ecbb9ad..63195fa 100644
--- a/src/gallium/targets/gbm/Makefile.am
+++ b/src/gallium/targets/gbm/Makefile.am
@@ -44,6 +44,7 @@ gbm_gallium_drm_la_SOURCES = gbm.c
 gbm_gallium_drm_la_LIBADD = \
$(GALLIUM_PIPE_LOADER_CLIENT_LIBS) \

$(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la \
+   $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
$(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
$(top_builddir)/src/gallium/state_trackers/gbm/libgbm.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index e82889e..1c84411 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -8,6 +8,7 @@ lib@OPENCL_LIBNAME@_la_LDFLAGS = \
 
 lib@OPENCL_LIBNAME@_la_LIBADD = \

$(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la \
+   $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
$(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
$(top_builddir)/src/gallium/state_trackers/clover/libclover.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
diff --git a/src/gallium/targets/xa/Makefile.am 
b/src/gallium/targets/xa/Makefile.am
index 7ab57ff..245dfff 100644
--- a/src/gallium/targets/xa/Makefile.am
+++ b/src/gallium/targets/xa/Makefile.am
@@ -42,6 +42,7 @@ libxatracker_la_SOURCES =
 libxatracker_la_LIBADD = \
$(GALLIUM_PIPE_LOADER_LIBS) \
$(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \
+   $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
$(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
$(top_builddir)/src/gallium/state_trackers/xa/libxatracker.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75445] New: Mesa 10.2.0-devel implementation error: meta program compile failed:

https://bugs.freedesktop.org/show_bug.cgi?id=75445

  Priority: medium
Bug ID: 75445
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Mesa 10.2.0-devel implementation error: meta program
compile failed:
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: scampa.giova...@gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Mesa core
   Product: Mesa

0:6(12): error: value of type vec3 cannot be assigned to variable of type vec4

source:
attribute vec2 position;
attribute vec3 textureCoords;
varying vec4 texCoords;
void main()
{
   texCoords = textureCoords;
   gl_Position = vec4(position, 0.0, 1.0);
}

This is mesa 8b5f894e13c0e290b2d3218ed8305e7428f2242f on an Intel GM45.
Configure line:
'--prefix' '/opt/gnome' '--libdir' '/opt/gnome/lib64' '--enable-silent-rules'
'--disable-static' '--config-cache' '--enable-gtk-doc'
'--with-egl-platforms=x11,wayland,drm' '--enable-gbm'
'--with-gallium-drivers=swrast,ilo,r300,r600,nouveau,freedreno'
'--with-dri-drivers=i965,r200' '--enable-shared-glapi' '--enable-gles2'
'CFLAGS=-g -O2 -Wno-error=deprecated-declarations -Wno-unused-local-typedefs
-DG_DISABLE_CAST_CHECKS -pipe' 'LDFLAGS=-L/opt/gnome/lib64 -fuse-linker-plugin
-pipe' 'CXXFLAGS=-g -O2 -Wno-error=deprecated-declarations
-Wno-unused-local-typedefs -DG_DISABLE_CAST_CHECKS -pipe'
'PKG_CONFIG_PATH=/opt/gnome/lib64/pkgconfig:/opt/gnome/share/pkgconfig:/usr/lib64/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig'
'--enable-opencl' '--with-clang-libdir=/usr/lib' '--enable-vdpau'

The failing program is gnome-maps (v3.11.90), with libchamplain
(LIBCHAMPLAIN_0_12_7-1-geb40691) and cogl (1.17.2-17-gf9cd179)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] targets/gbm: exit gracefully if pipe_loader_drm_probe_fd is not available

2014-02-24 Thread Tom Stellard

These four patches fix the OpenCL build errors.

Tested-by: Tom Stellard thomas.stell...@amd.com

On Sat, Feb 22, 2014 at 04:53:47PM +, Emil Velikov wrote:
 When one builds without gallium_drm_loader, the above function will
 not be available, thus we'll segfault in gallium_screen_create due
 to memory access violation.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75335
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/targets/gbm/gbm.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/src/gallium/targets/gbm/gbm.c b/src/gallium/targets/gbm/gbm.c
 index deaa401..160cbb8 100644
 --- a/src/gallium/targets/gbm/gbm.c
 +++ b/src/gallium/targets/gbm/gbm.c
 @@ -49,13 +49,14 @@ int
  gallium_screen_create(struct gbm_gallium_drm_device *gdrm)
  {
 struct pipe_loader_device *dev;
 -#ifdef HAVE_PIPE_LOADER_DRM
 -   int ret;
 +   int ret = 0;
  
 +#ifdef HAVE_PIPE_LOADER_DRM
 ret = pipe_loader_drm_probe_fd(dev, gdrm-base.base.fd, true);
 +#endif /* HAVE_PIPE_LOADER_DRM */
 +
 if (!ret)
return -1;
 -#endif /* HAVE_PIPE_LOADER_DRM */
  
 gdrm-screen = pipe_loader_create_screen(dev, get_library_search_path());
 if (gdrm-screen == NULL) {
 -- 
 1.9.0
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/targets: resolve undefined reference to

On 24/02/14 14:26, Emil Velikov wrote:
 With the introduction of the pipe_loader_sw_probe_dri helper we
 require the sw/dri winsys during linking stage despite it being
 unused by any of the targets. This will cause a minor increase
 in the resulting library which will be cleaned up via linker
 options with upcoming patches.
 
 Cc: Tom Stellard thomas.stell...@amd.com
 Reported-by: Tom Stellard thomas.stell...@amd.com
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
 
 This should cover the final breakages caused by the recent
 pipe-loader changes.
 
 -Emil 
 
  src/gallium/targets/gbm/Makefile.am| 1 +
  src/gallium/targets/opencl/Makefile.am | 1 +
  src/gallium/targets/xa/Makefile.am | 1 +
  3 files changed, 3 insertions(+)
 
 diff --git a/src/gallium/targets/gbm/Makefile.am 
 b/src/gallium/targets/gbm/Makefile.am
 index ecbb9ad..63195fa 100644
 --- a/src/gallium/targets/gbm/Makefile.am
 +++ b/src/gallium/targets/gbm/Makefile.am
 @@ -44,6 +44,7 @@ gbm_gallium_drm_la_SOURCES = gbm.c
  gbm_gallium_drm_la_LIBADD = \
   $(GALLIUM_PIPE_LOADER_CLIENT_LIBS) \
   
 $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la \
 + $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
Sigh seems like I would need to wrap all the occurrences in

if HAVE_DRI
endif

-Emil
   $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
   $(top_builddir)/src/gallium/state_trackers/gbm/libgbm.la \
   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
 diff --git a/src/gallium/targets/opencl/Makefile.am 
 b/src/gallium/targets/opencl/Makefile.am
 index e82889e..1c84411 100644
 --- a/src/gallium/targets/opencl/Makefile.am
 +++ b/src/gallium/targets/opencl/Makefile.am
 @@ -8,6 +8,7 @@ lib@OPENCL_LIBNAME@_la_LDFLAGS = \
  
  lib@OPENCL_LIBNAME@_la_LIBADD = \
   
 $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la \
 + $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
   $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
   $(top_builddir)/src/gallium/state_trackers/clover/libclover.la \
   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
 diff --git a/src/gallium/targets/xa/Makefile.am 
 b/src/gallium/targets/xa/Makefile.am
 index 7ab57ff..245dfff 100644
 --- a/src/gallium/targets/xa/Makefile.am
 +++ b/src/gallium/targets/xa/Makefile.am
 @@ -42,6 +42,7 @@ libxatracker_la_SOURCES =
  libxatracker_la_LIBADD = \
   $(GALLIUM_PIPE_LOADER_LIBS) \
   $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \
 + $(top_builddir)/src/gallium/winsys/sw/dri/libswdri.la \
   $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
   $(top_builddir)/src/gallium/state_trackers/xa/libxatracker.la \
   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75335] Use of uninitialized pointer in 'gallium_screen_create()'

https://bugs.freedesktop.org/show_bug.cgi?id=75335

Emil Velikov emil.l.veli...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Emil Velikov emil.l.veli...@gmail.com ---
Pushed to master

commit 0e7c30233f10d834ee26b7d6d32b397625e11e10
Author: Emil Velikov emil.l.veli...@gmail.com
Date:   Sat Feb 22 16:20:04 2014 +

targets/gbm: exit gracefully if pipe_loader_drm_probe_fd is not available

When one builds without gallium_drm_loader, the above function will
not be available, thus we'll segfault in gallium_screen_create due
to memory access violation.

-- 
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 75356] pipe_loader_sw.c:64: undefined reference to `xlib_create_sw_winsys'

https://bugs.freedesktop.org/show_bug.cgi?id=75356

Emil Velikov emil.l.veli...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Emil Velikov emil.l.veli...@gmail.com ---
Pushed to master

commit 3445e8bb921545f74e2b6a823d47fa29352e9262
Author: Emil Velikov emil.l.veli...@gmail.com
Date:   Sat Feb 22 16:44:14 2014 +

pipe-loader: wrap pipe_loader_sw_probe_xlib within HAVE_PIPE_LOADER_XLIB

The above function implies using the the xlib winsys, which
has additional library dependencies that should not be forced.

Make the software xlib pipe loader optional thus avoid all
the dependency hell. A user that wishes to use the particular
pipe-loader would need to set the following within configure.ac.

 enable_gallium_xlib_loader=yes

v2:
 - Wrap sw/xlib/xlib_sw_winsys.h to handle compilation on systems
lacking X11 headers. Spotted by Christian Prochaska.

-- 
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 13/25] gallium: Introduce max_gl*version pipe-caps

Am 23.02.2014 16:26, schrieb Emil Velikov:
 On 22/02/14 21:46, Roland Scheidegger wrote:

 - Original Message -
 From: Emil Velikov emil.l.veli...@gmail.com
 To: Roland Scheidegger srol...@vmware.com, 
 mesa-dev@lists.freedesktop.org
 Cc: emil l velikov emil.l.veli...@gmail.com
 Sent: Saturday, February 22, 2014 2:02:08 PM
 Subject: Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version 
 pipe-caps

 On 22/02/14 12:02, Roland Scheidegger wrote:
 Am 22.02.2014 04:04, schrieb Emil Velikov:
 According to the GLX_MESA_query_renderer spec each driver should
 be able to report the version of each GL api they support before
 creating a context.

 Currently both classic mesa and gallium evaluate the version post
 context creation and while the classic drivers set the max_gl*version
 according to their capabilities, gallium uses fixed values which
 are not the best approach due to driver differences.

 Add pipe-caps so that each driver can provide their individual
 capabilites.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/docs/source/screen.rst   | 8 +++-
  src/gallium/include/pipe/p_defines.h | 6 +-
  2 files changed, 12 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/docs/source/screen.rst
 b/src/gallium/docs/source/screen.rst
 index bd553f4..7b72133 100644
 --- a/src/gallium/docs/source/screen.rst
 +++ b/src/gallium/docs/source/screen.rst
 @@ -169,7 +169,7 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
 -* ''PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
 +* ``PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE.
  * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
different sizes for fb color/zs attachments. This controls whether
 @@ -182,6 +182,12 @@ The integer capabilities:
vertex components output by a single invocation of a geometry shader.
This is the product of the number of attribute components per vertex
and
the number of output vertices.
 +* ``PIPE_CAP_MAX_GL_CORE_VERSION``: The maximum OpenGL (Core profile)
 version
 +  supported.
 +* ``PIPE_CAP_MAX_GL_COMPAT_VERSION``: The maximum OpenGL (Compatibility
 profile)
 +  version supported.
 +* ``PIPE_CAP_MAX_GL_ES1_VERSION``: The maximum OpenGL ES1 version
 supported.
 +* ``PIPE_CAP_MAX_GL_ES2_VERSION``: The maximum OpenGL ES2 version
 supported.

  .. _pipe_capf:
 diff --git a/src/gallium/include/pipe/p_defines.h
 b/src/gallium/include/pipe/p_defines.h
 index 83815cd..5c27f9c 100644
 --- a/src/gallium/include/pipe/p_defines.h
 +++ b/src/gallium/include/pipe/p_defines.h
 @@ -522,7 +522,11 @@ enum pipe_cap {
 PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
 PIPE_CAP_TGSI_VS_LAYER = 87,
 PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES = 88,
 -   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89
 +   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89,
 +   PIPE_CAP_MAX_GL_CORE_VERSION = 90,
 +   PIPE_CAP_MAX_GL_COMPAT_VERSION = 91,
 +   PIPE_CAP_MAX_GL_ES1_VERSION = 92,
 +   PIPE_CAP_MAX_GL_ES2_VERSION = 93,
  };

  #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1  0)

 Hmm do you really need all these different cap bits? Generally, the
 difference between ES/CORE/COMPAT contexts isn't hw related at all, and
 thus not really (gallium) driver related. So, obviously, every driver
 can do ES11 for instance, it should be impossible to write a gallium
 driver which can't. Similarly, I don't think core/compat needs a
 different query neither, though I guess ES2 version being separate might
 make sense.

 If you can think of a way to retrieve the gl* version that a driver
 support without ever having a gl_context I would love to hear how we can
 do that. GLX_MESA_query_renderer requires from the driver to state the
 version of each api it supports prior of context creation.

 Honestly I felt a bit bad about adding all those caps, but this is the
 least evasive way of handling it. I will drop the ES1 cap would love to
 nuke the rest as well :-)

 I think you could easily derive compat and core version from some gl driver
 version instead of having two (the driver knows nothing about core or compat
 contexts, after all). ES might be different (at least with OES 4.0).
 But technically, you shouldn't even need any version queries as you could 
 derive
 this from all the other cap bits I think (much the same way as 
 st_extensions.c
 figures out what extensions are supported, plus mesa's compute_version then 
 does).
 None of that cap query stuff (including querying for msaa formats and the 
 like)
 requires a context. At least I can't see why it wouldn't work.

 Now that I think about it, one could copy the extension list and
 (context) constants to pipe_screen. This way on st_api_create_context,
 we'll just copy the initial values

Re: [Mesa-dev] [PATCH 2/3] gallium: add texture gather support to gallium (v3)

Am 24.02.2014 09:33, schrieb Dave Airlie:
 On Wed, Feb 12, 2014 at 9:10 AM, Roland Scheidegger srol...@vmware.com 
 wrote:
 Am 11.02.2014 22:58, schrieb Dave Airlie:
dst.z = texture_depth(unit, lod)

 +.. opcode:: TG4 - Texture Gather (as per ARB_texture_gather)
 +   Gathers the four texels to be used in a bi-linear
 +   filtering operation and packs them into a single register.
 +   Only works with 2D, 2D array, cubemaps, and cubemaps 
 arrays.
 +   For 2D textures, only the addressing modes of the sampler 
 and
 +   the top level of any mip pyramid are used. Set W to zero.
 +   It behaves like the TEX instruction, but a filtered
 +   sample is not generated. The four samples that contribute
 +   to filtering are placed into xyzw in clockwise order,
 +   starting with the (u,v) texture coordinate delta at the
 +   following locations (-, +), (+, +), (+, -), (-, -), where
 +   the magnitude of the deltas are half a texel.
 +
 +   PIPE_CAP_TEXTURE_SM5 enhances this instruction to support
 +   shadow per-sample depth compares, single component 
 selection,
 +   and a non-constant offset. It doesn't allow support for 
 the
 +   GL independent offset to get i0,j0. This would require 
 another
 +   CAP is hw can do it natively. For now we lower that before
 +   TGSI.
 +
 +.. math::
 +
 +   coord = src0
 +
 +   component = src1
 +
 +   dst = texture_gather4 (unit, coord, component)
 +
 +(with SM5 - cube array shadow)
 +
 +   coord = src0
 +
 +   compare = src1
 +
 +   dst = texture_gather (uint, coord, compare)
 +
 So how does component selection work with the latter version?
 I think it would be nice if you wouldn't really need two versions (so if
 you don't support comparisons, the src would just be unused).

 That's docs not being clear enough if you read it like that. The
 second version is only for cube array shadow compares, which have no
 components. The first version is the same for non-shadow compares.
 Ah right that works, I forgot you don't need the channel select with
 shadow comparisons (not that I'm a big fan of such overloaded sources
 but that's nothing new really).


 Also, FWIW for llvmpipe you'd probably wanted a native 4 offsets
 versions, I don't think llvm could eliminate the huge amount of
 duplicated code completely if you generate 4 texture lookups. Of course,
 someone would need to implement it first (shouldn't be too difficult).

 Yeah llvmpipe might be in the category for using the extra CAP, I'm
 really hoping nvidia hw does do this, but the interface is kinda
 arbitrary and maybe we should consider another opcode,

 Since we have for SM5 nonconstant ones something like,

 TG4 TEMP[1], TEMP[1], SAMP[0] , TEMP[2].xyz
 which will sample around temp[1] i0,j0 - i1, j1 at the offset in temp[2]

 and
 TG4 TEMP[1], TEMP[1], SAMP[0], TEMP[2].xyz, TEMP[3].xyz, TEMP[4].xyz,
 TEMP[5].xyz
 which will sample i0,j0 from TEMP[1] and the respective offsets.


 Yes since the offsets are in separate offset structure and the amount of
 offsets is indicated I think it should just work actually if a driver
 wants to implement multiple offsets natively.
 
 So you okay with this version I think it covers everything, and we can
 add a CAP if/when someone works out hw/llvmpipe for the 4 offset case.
 
 Dave
 

Yes, looks good to me.

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/svga: Avoid calling drm getparam for max surface size on older kernels

2014-02-24 Thread Brian Paul

On Mon, Feb 24, 2014 at 2:05 AM, Thomas Hellstrom thellst...@vmware.comwrote:

 This avoids the kernel driver spewing out errors about the param not being
 supported.

 Also correct the max surface size used when the kernel does not support the
 query.

 Reported-by: Brian Paul bri...@vmware.com
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 Reviewed-by: Charmaine Lee charmai...@vmware.com
 Cc: 10.1 mesa-sta...@lists.freedesktop.org
 ---
  src/gallium/winsys/svga/drm/vmw_screen_ioctl.c |   15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

 diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
 b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
 index b7bedb1..2866a29 100644
 --- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
 +++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
 @@ -762,7 +762,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
 int ret;
 uint32_t *cap_buffer;
 drmVersionPtr version;
 -   boolean drm_gb_capable;
 +   boolean have_drm_2_5;

 VMW_FUNC;

 @@ -770,7 +770,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
 if (!version)
goto out_no_version;

 -   drm_gb_capable = version-version_major  2 ||
 +   have_drm_2_5 = version-version_major  2 ||
(version-version_major == 2  version-version_minor  4);


How about something like:

have_drm_2_5 = version-version_major * 100 + version-version_minor = 205?

Not a big deal though.  Thanks for fixing this.

Reviewed-by: Brian Paul bri...@vmware.com




 memset(gp_arg, 0, sizeof(gp_arg));
 @@ -803,7 +803,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
vws-base.have_gb_objects =
   !!(gp_arg.value  (uint64_t) SVGA_CAP_GBOBJECTS);

 -   if (vws-base.have_gb_objects  !drm_gb_capable)
 +   if (vws-base.have_gb_objects  !have_drm_2_5)
goto out_no_3d;

 if (vws-base.have_gb_objects) {
 @@ -839,11 +839,12 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)

memset(gp_arg, 0, sizeof(gp_arg));
gp_arg.param = DRM_VMW_PARAM_MAX_SURF_MEMORY;
 -  ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_GET_PARAM,
 -gp_arg, sizeof(gp_arg));
 -  if (ret) {
 +  if (have_drm_2_5)
 + ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_GET_PARAM,
 +   gp_arg, sizeof(gp_arg));
 +  if (!have_drm_2_5 || ret) {
   /* Just guess a large enough value, around 800mb. */
 - vws-ioctl.max_surface_memory = 0x3;
 + vws-ioctl.max_surface_memory = 0x3000;
} else {
   vws-ioctl.max_surface_memory = gp_arg.value;
}
 --
 1.7.10.4
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium and ARB_texture_query_levels

Am 24.02.2014 09:38, schrieb Dave Airlie:
I've taken a quick look at ARB_texture_query_levels,

and the HW generally seems to implement this by returning it in the W
channel of RESINFO, which would map to the TXQ instruction,

So my initial implementation added a LEVQ TGSI instruction but I do
think this isn't representative of the hw and I should add it to TXQ
with maybe a CAP to say it supports levels.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=5d7NG60G1rh6MNbfSxLGJ6BP279NlasrWRKYXmIL1rA%3D%0As=3d194a0f62820a267c7954a144cc78ebcca134ea4e9c1d3cb6e3c7aafe6678bb

Doing this with TXQ sounds right to me. I'm not sure you even need a cap
bit - this is typically dx10 hw which can do resinfo and dx10 is the
reason all hw returns number of levels in the w channel anyway.
Though it's possible there's some newer non-desktop hw out there not
concerned about d3d (but OpenGL ES instead) which can't do it, so a cap
is fine too.
llvmpipe actually right now will only return this in the w channel for
sviewinfo, not txq, but it could be changed. I think as long as you give
it the right write mask it should be able to drop all the extra unneeded
calculations. Though obviously for llvmpipe/softpipe it can be
implemented easily either way.

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nv50: correctly calculate the number of vertical blocks during transfer map

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 src/gallium/drivers/nouveau/nv50/nv50_transfer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_transfer.c 
b/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
index a990682..f716052 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
@@ -278,7 +278,7 @@ nv50_miptree_transfer_map(struct pipe_context *pctx,
 
if (util_format_is_plain(res-format)) {
   tx-nblocksx = box-width  mt-ms_x;
-  tx-nblocksy = box-height  mt-ms_x;
+  tx-nblocksy = box-height  mt-ms_y;
} else {
   tx-nblocksx = util_format_get_nblocksx(res-format, box-width);
   tx-nblocksy = util_format_get_nblocksy(res-format, box-height);
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] dri3: Add GLX_EXT_buffer_age support

2014-02-24 Thread Robert Bragg

Hi Adel,

Thanks for look at this; just a few comments...

 diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
 index 978730c..afb4206 100644
 --- a/src/glx/glx_pbuffer.c
 +++ b/src/glx/glx_pbuffer.c
 @@ -373,6 +373,14 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
  if (!pdraw-textureFormat)
 pdraw-textureFormat =
determineTextureFormat((const int *) data, num_attributes);
 +
 +if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
 +   struct glx_screen *psc = pdraw-psc;
 +
 +   if (psc-driScreen-getBufferAge != NULL)
 + *value = psc-driScreen-getBufferAge(pdraw);
 +}
 +
   }
  #endif

Since with dri3 this is a client side only attribute, shouldn't we be
able to simply skip the redundant X round trip above to query the
drawable's attributes?

Technically we're supposed to report a GLXBadDrawable if the drawable
isn't currently bound to the current thread's context. I think the
requirement to be bound to a context was added to the spec considering
that if an app were switching between a direct/indirect context the
age state may switch from being client-side to server-side and they
shouldn't have to be kept in sync. glXSwapBuffers has a similar
requirement so it should be possible to borrow some checks from there.

Apart from that, this patch looks good to me:

Reviewed-by: Robert Bragg rob...@sixbynine.org

--
Regards,
Robert
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nv50: correctly calculate the number of vertical blocks during transfer map

On Mon, Feb 24, 2014 at 11:46 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Nice catch! Does this fix any piglits, or just fixes some
XY_OUT_OF_BOUNDS errors? ms_x == ms_y for ms = 4, which oddly enough
is where copyteximage passed (should have noticed that earlier, but
only made the connection just now). [Interesting, copyteximage
samples=4 even passes on nva0+, where it fails without samples being
set...]

Reviewed-by: Ilia Mirkin imir...@alum.mit.edu

 ---
  src/gallium/drivers/nouveau/nv50/nv50_transfer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_transfer.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
 index a990682..f716052 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
 @@ -278,7 +278,7 @@ nv50_miptree_transfer_map(struct pipe_context *pctx,

 if (util_format_is_plain(res-format)) {
tx-nblocksx = box-width  mt-ms_x;
 -  tx-nblocksy = box-height  mt-ms_x;
 +  tx-nblocksy = box-height  mt-ms_y;
 } else {
tx-nblocksx = util_format_get_nblocksx(res-format, box-width);
tx-nblocksy = util_format_get_nblocksy(res-format, box-height);
 --
 1.9.0

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nv50: correctly calculate the number of vertical blocks during transfer map

On 24/02/14 17:04, Ilia Mirkin wrote:
 On Mon, Feb 24, 2014 at 11:46 AM, Emil Velikov emil.l.veli...@gmail.com 
 wrote:
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 
 Nice catch! Does this fix any piglits, or just fixes some
 XY_OUT_OF_BOUNDS errors? ms_x == ms_y for ms = 4, which oddly enough
 is where copyteximage passed (should have noticed that earlier, but
 only made the connection just now). [Interesting, copyteximage
 samples=4 even passes on nva0+, where it fails without samples being
 set...]
 
 Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
 
That's the bad part, I did not notice any difference in a couple of
piglits including the XY_OUT_OF_BOUNDS errors that brought me there in
the first place. There is minor improvements in some
EXT_framebuffer_multisample/accuracy tests but they were still failing.

Btw I will cc stable before pushing, unless someone objects on the subject.

Thanks
-Emil

 ---
  src/gallium/drivers/nouveau/nv50/nv50_transfer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_transfer.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
 index a990682..f716052 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_transfer.c
 @@ -278,7 +278,7 @@ nv50_miptree_transfer_map(struct pipe_context *pctx,

 if (util_format_is_plain(res-format)) {
tx-nblocksx = box-width  mt-ms_x;
 -  tx-nblocksy = box-height  mt-ms_x;
 +  tx-nblocksy = box-height  mt-ms_y;
 } else {
tx-nblocksx = util_format_get_nblocksx(res-format, box-width);
tx-nblocksy = util_format_get_nblocksy(res-format, box-height);
 --
 1.9.0

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meta: Use a #define for the vector type to avoid %svec4 everywhere.


On 02/21/2014 07:15 PM, Kenneth Graunke wrote:

By adding #define gvec4 %svec4 to the top of our fragment shader, we
can write generic code without needing to specialize it to vec4, ivec4,
or uvec4 via asprintf.

This also makes the INT and UNSIGNED_INT merge function code identical,
so I combined those two cases.

It's not a big savings, but a little bit tidier.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org


Reviewed-by: Ian Romanick ian.d.roman...@intel.com


---
  src/mesa/drivers/common/meta_blit.c | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 69c2590..f9c8814 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -228,12 +228,9 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
   sample_resolve = ralloc_asprintf(mem_ctx,out_color = 
texelFetch(texSampler, ivec2(texCoords), gl_SampleID););
   merge_function = ;
} else {
- if (src_datatype == GL_INT) {
+ if (src_datatype == GL_INT || src_datatype == GL_UNSIGNED_INT) {
  merge_function =
-   ivec4 merge(ivec4 a, ivec4 b) { return (a  ivec4(1)) + (b  ivec4(1)) + 
(a  b  ivec4(1)); }\n;
- } else if (src_datatype == GL_UNSIGNED_INT) {
-merge_function =
-   uvec4 merge(uvec4 a, uvec4 b) { return (a  uvec4(1)) + (b  uvec4(1)) + 
(a  b  uvec4(1)); }\n;
+   gvec4 merge(gvec4 a, gvec4 b) { return (a  gvec4(1)) + (b  gvec4(1)) + 
(a  b  gvec4(1)); }\n;
   } else {
  /* The divide will happen at the end for floats. */
  merge_function =
@@ -254,8 +251,8 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
   sample_resolve = rzalloc_size(mem_ctx, 1);
   for (int i = 0; i  samples; i++) {
  ralloc_asprintf_append(sample_resolve,
-  %svec4 sample_1_%d = texelFetch(texSampler, 
ivec2(texCoords), %d);\n,
-   vec4_prefix, i, i);
+  gvec4 sample_1_%d = texelFetch(texSampler, 
ivec2(texCoords), %d);\n,
+   i, i);
   }
   /* Now, merge each pair of samples, then merge each pair of those,
* etc.
@@ -263,8 +260,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
   for (int step = 2; step = samples; step *= 2) {
  for (int i = 0; i  samples; i += step) {
 ralloc_asprintf_append(sample_resolve,
- %svec4 sample_%d_%d = merge(sample_%d_%d, 
sample_%d_%d);\n,
-  vec4_prefix,
+ gvec4 sample_%d_%d = merge(sample_%d_%d, 
sample_%d_%d);\n,
step, i,
step / 2, i,
step / 2, i + step / 2);
@@ -297,9 +293,10 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
#version 130\n
#extension GL_ARB_texture_multisample : 
enable\n
%s\n
+  #define gvec4 %svec4\n
uniform %ssampler2DMS texSampler;\n
in vec2 texCoords;\n
-  out %svec4 out_color;\n
+  out gvec4 out_color;\n
\n
%s /* merge_function */
void main()\n



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75445] Mesa 10.2.0-devel implementation error: meta program compile failed:

https://bugs.freedesktop.org/show_bug.cgi?id=75445

Ian Romanick i...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Ian Romanick i...@freedesktop.org ---


*** This bug has been marked as a duplicate of bug 74911 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] glsl: Add is_horizontal() method to ir_expression.


On 02/22/2014 04:35 PM, Matt Turner wrote:

Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
  src/glsl/ir.h | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index e27e30a..55ec5ff 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1458,6 +1458,16 @@ public:
 }

 /**
+* Return whether the expression operates on vectors horizontally.
+*/
+   bool is_horizontal() const
+   {
+  return operation == ir_binop_all_equal ||
+ operation == ir_binop_any_nequal ||
+ operation == ir_binop_dot;


I'm pretty sure ir_unop_any should also be in this list  I also wonder a 
bit about the various pack / unpack opcodes.  Maybe ir_quadop_vector 
too, but we get rid of most of those.



+   }
+
+   /**
  * Return a string representing this expression's operator.
  */
 const char *operator_string();



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] glsl: Delete LRP_TO_ARITH lowering pass flag.


On 02/23/2014 07:19 PM, Kenneth Graunke wrote:

Tt's kind of a trap---calling do_common_optimization() after
lower_instructions() may cause opt_algebraic() to reintroduce
ir_triop_lrp expressions that were lowered, effectively defeating the
point.  Because of this, nobody uses it.

Cc: 10.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
  src/glsl/ir_optimization.h  |  5 ++---
  src/glsl/lower_instructions.cpp | 10 --
  2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index 055d655..1777b84 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -36,9 +36,8 @@
  #define LOG_TO_LOG20x10
  #define MOD_TO_FRACT   0x20
  #define INT_DIV_TO_MUL_RCP 0x40
-#define LRP_TO_ARITH   0x80
-#define BITFIELD_INSERT_TO_BFM_BFI 0x100
-#define LDEXP_TO_ARITH 0x200
+#define BITFIELD_INSERT_TO_BFM_BFI 0x80
+#define LDEXP_TO_ARITH 0x100

  /**
   * \see class lower_packing_builtins_visitor
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
index 44a6e80..9c5e7b3 100644
--- a/src/glsl/lower_instructions.cpp
+++ b/src/glsl/lower_instructions.cpp
@@ -38,7 +38,6 @@
   * - LOG_TO_LOG2
   * - MOD_TO_FRACT
   * - LDEXP_TO_ARITH
- * - LRP_TO_ARITH
   * - BITFIELD_INSERT_TO_BFM_BFI
   *
   * SUB_TO_ADD_NEG:
@@ -87,10 +86,6 @@
   * -
   * Converts ir_binop_ldexp to arithmetic and bit operations.
   *
- * LRP_TO_ARITH:
- * -
- * Converts ir_triop_lrp to (op0 * (1.0f - op2)) + (op1 * op2).
- *
   * BITFIELD_INSERT_TO_BFM_BFI:
   * ---
   * Breaks ir_quadop_bitfield_insert into ir_binop_bfm (bitfield mask) and
@@ -499,11 +494,6 @@ lower_instructions_visitor::visit_leave(ir_expression *ir)
 pow_to_exp2(ir);
break;

-   case ir_triop_lrp:
-  if (lowering(LRP_TO_ARITH))
-lrp_to_arith(ir);


Shouldn't the lrp_to_arith implementation also get removed?  This 
appears to be the only caller...



-  break;
-
 case ir_quadop_bitfield_insert:
if (lowering(BITFIELD_INSERT_TO_BFM_BFI))
   bitfield_insert_to_bfm_bfi(ir);



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75226] Dark rendering of War for the Overworld

https://bugs.freedesktop.org/show_bug.cgi?id=75226

--- Comment #13 from Erich Hoover erich.e.hoo...@gmail.com ---
Created attachment 94676
  -- https://bugs.freedesktop.org/attachment.cgi?id=94676action=edit
Other user's logs

Attached are the logs for the other user, it sounds like you guys already have
things figured out - but maybe more information is better.

(In reply to comment #9)
 Created attachment 94530 [details] [review]
 assume sRGB by default
 
 Does this help?

I'm trying to think of a way to easily help the end users test this, do they
only need this patch or do they need the others as well?  Based on distro I
initially assumed one of them had built their graphics stack from source and,
unfortunately, my assumption was incorrect :/

Also, sorry for the delayed reply - things have been a little crazy lately.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] glsl: Add is_horizontal() method to ir_expression.

On Mon, Feb 24, 2014 at 9:43 AM, Ian Romanick i...@freedesktop.org wrote:
 On 02/22/2014 04:35 PM, Matt Turner wrote:

 Cc: 10.1 mesa-sta...@lists.freedesktop.org
 ---
   src/glsl/ir.h | 10 ++
   1 file changed, 10 insertions(+)

 diff --git a/src/glsl/ir.h b/src/glsl/ir.h
 index e27e30a..55ec5ff 100644
 --- a/src/glsl/ir.h
 +++ b/src/glsl/ir.h
 @@ -1458,6 +1458,16 @@ public:
  }

  /**
 +* Return whether the expression operates on vectors horizontally.
 +*/
 +   bool is_horizontal() const
 +   {
 +  return operation == ir_binop_all_equal ||
 + operation == ir_binop_any_nequal ||
 + operation == ir_binop_dot;


 I'm pretty sure ir_unop_any should also be in this list  I also wonder a bit
 about the various pack / unpack opcodes.  Maybe ir_quadop_vector too, but we
 get rid of most of those.

Yeah, ir_unop_any definitely should. I'll add quadop_vector as well. I
think all of the pack / unpack opcodes are safe though, after
reminding myself what the split opcodes do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] R600/SI: Allow SI_KILL for geometry shaders

2014-02-24 Thread Tom Stellard

On Mon, Feb 24, 2014 at 06:02:23PM +0900, Michel Dänzer wrote:
 From: Michel Dänzer michel.daen...@amd.com
 
 Signed-off-by: Michel Dänzer michel.daen...@amd.com
 ---
  lib/Target/R600/SILowerControlFlow.cpp | 50 
 ++
  test/CodeGen/R600/llvm.AMDGPU.kill.ll  | 18 
  2 files changed, 50 insertions(+), 18 deletions(-)
  create mode 100644 test/CodeGen/R600/llvm.AMDGPU.kill.ll
 
 diff --git a/lib/Target/R600/SILowerControlFlow.cpp 
 b/lib/Target/R600/SILowerControlFlow.cpp
 index f6f9016..1fe620b 100644
 --- a/lib/Target/R600/SILowerControlFlow.cpp
 +++ b/lib/Target/R600/SILowerControlFlow.cpp
 @@ -151,22 +151,34 @@ void SILowerControlFlowPass::SkipIfDead(MachineInstr 
 MI) {
MachineBasicBlock::iterator Insert = MI;
++Insert;
  
 -  // If the exec mask is non-zero, skip the next two instructions
 -  BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_CBRANCH_EXECNZ))
 -  .addImm(3)
 -  .addReg(AMDGPU::EXEC);
 -
 -  // Exec mask is zero: Export to NULL target...
 -  BuildMI(MBB, Insert, DL, TII-get(AMDGPU::EXP))
 -  .addImm(0)
 -  .addImm(0x09) // V_008DFC_SQ_EXP_NULL
 -  .addImm(0)
 -  .addImm(1)
 -  .addImm(1)
 -  .addReg(AMDGPU::VGPR0)
 -  .addReg(AMDGPU::VGPR0)
 -  .addReg(AMDGPU::VGPR0)
 -  .addReg(AMDGPU::VGPR0);
 +  if (MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
 +  ShaderType::PIXEL) {
 +// If the exec mask is non-zero, skip the next two instructions
 +BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_CBRANCH_EXECNZ))
 +.addImm(3)
 +.addReg(AMDGPU::EXEC);
 +
 +// Exec mask is zero: Export to NULL target...
 +BuildMI(MBB, Insert, DL, TII-get(AMDGPU::EXP))
 +.addImm(0)
 +.addImm(0x09) // V_008DFC_SQ_EXP_NULL
 +.addImm(0)
 +.addImm(1)
 +.addImm(1)
 +.addReg(AMDGPU::VGPR0)
 +.addReg(AMDGPU::VGPR0)
 +.addReg(AMDGPU::VGPR0)
 +.addReg(AMDGPU::VGPR0);
 +  } else {
 +// If the exec mask is non-zero, skip the next two instructions
 +BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_CBRANCH_EXECNZ))
 +.addImm(2)
 +.addReg(AMDGPU::EXEC);
 +
 +// Signal GS done
 +BuildMI(MBB, MI, DL, TII-get(AMDGPU::S_SENDMSG))
 +.addImm(3);
 +  }
  
// ... and terminate wavefront
BuildMI(MBB, Insert, DL, TII-get(AMDGPU::S_ENDPGM));
 @@ -293,9 +305,11 @@ void SILowerControlFlowPass::Kill(MachineInstr MI) {
MachineBasicBlock MBB = *MI.getParent();
DebugLoc DL = MI.getDebugLoc();
  
 -  // Kill is only allowed in pixel shaders
 +  // Kill is only allowed in pixel / geometry shaders
assert(MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
 - ShaderType::PIXEL);
 + ShaderType::PIXEL ||
 + MBB.getParent()-getInfoSIMachineFunctionInfo()-ShaderType ==
 + ShaderType::GEOMETRY);
  
// Clear this pixel from the exec mask if the operand is negative
BuildMI(MBB, MI, DL, TII-get(AMDGPU::V_CMPX_LE_F32_e32), AMDGPU::VCC)
 diff --git a/test/CodeGen/R600/llvm.AMDGPU.kill.ll 
 b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
 new file mode 100644
 index 000..0abe694
 --- /dev/null
 +++ b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
 @@ -0,0 +1,18 @@
 +; RUN: llc  %s -march=r600 -mcpu=verde -verify-machineinstrs | FileCheck 
 --check-prefix=SI-CHECK %s
 +
 +; SI-LABEL: @kill_gs

Since your prefix is SI-CHECK, this would need to be SI-CHECK-LABEL.

With that fix,
Reviewed-by: Tom Stellard thomas.stell...@amd.com

 +; SI-CHECK: V_CMPX_LE_F32
 +
 +define void @kill_gs() #0 {
 +main_body:
 +  %0 = icmp ule i32 0, 3
 +  %1 = select i1 %0, float 1.00e+00, float -1.00e+00
 +  call void @llvm.AMDGPU.kill(float %1)
 +  ret void
 +}
 +
 +declare void @llvm.AMDGPU.kill(float)
 +
 +attributes #0 = { ShaderType=2 }
 +
 +!0 = metadata !{metadata !const, null, i32 1}
 -- 
 1.9.0
 
 ___
 llvm-commits mailing list
 llvm-comm...@cs.uiuc.edu
 http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] i965/vec4: Handle ir_triop_lrp on Gen4-5 as well.

Kenneth Graunke kenn...@whitecape.org writes:

 When the vec4 backend encountered an ir_triop_lrp, it always emitted an
 actual LRP instruction, which only exists on Gen6+.  Gen4-5 used
 lower_instructions() to decompose ir_triop_lrp at the IR level.

 Since commit 8d37e9915a3b21 (glsl: Optimize open-coded lrp into lrp.),
 we've had an bug where lower_instructions translates ir_triop_lrp into
 arithmetic, but opt_algebraic reassembles it back into a lrp.

 To avoid this ordering concern, just handle ir_triop_lrp in the backend.
 The FS backend already does this, so we may as well do likewise.

 Cc: 10.1 mesa-sta...@lists.freedesktop.org
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75253
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/drivers/dri/i965/brw_vec4.h   |  3 +++
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 36 
 +-
  2 files changed, 32 insertions(+), 7 deletions(-)

 This patch fixes a regression from 10.0 to 10.1, and really needs to be
 cherry-picked before the final 10.1.0 release.

 Technically, it's the only one that needs to be cherry-picked, but I figured
 I may as well CC the whole series and leave it up to the stable maintainers.

 diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
 b/src/mesa/drivers/dri/i965/brw_vec4.h
 index 6bd8b80..fb5c0a6 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4.h
 +++ b/src/mesa/drivers/dri/i965/brw_vec4.h
 @@ -506,6 +506,9 @@ public:
  
 void emit_minmax(uint32_t condmod, dst_reg dst, src_reg src0, src_reg 
 src1);
  
 +   void emit_lrp(const dst_reg dst,
 + const src_reg x, const src_reg y, const src_reg a);
 +
 void emit_block_move(dst_reg *dst, src_reg *src,
   const struct glsl_type *type, uint32_t predicate);
  
 diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
 b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 index 95e0064..d4f1899 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 @@ -1132,6 +1132,34 @@ vec4_visitor::emit_minmax(uint32_t conditionalmod, 
 dst_reg dst,
 }
  }
  
 +void
 +vec4_visitor::emit_lrp(const dst_reg dst,
 +   const src_reg x, const src_reg y, const src_reg a)
 +{
 +   if (brw-gen = 6) {
 +  /* Note that the instruction's argument order is reversed from GLSL
 +   * and the IR.
 +   */
 +  emit(LRP(dst,
 +   fix_3src_operand(a), fix_3src_operand(y), 
 fix_3src_operand(x)));
 +   } else {
 +  /* Earlier generations don't support three source operations, so we
 +   * need to emit x*(1-a) + y*a.
 +   */
 +  dst_reg y_times_a   = dst_reg(this, glsl_type::vec4_type);
 +  dst_reg one_minus_a = dst_reg(this, glsl_type::vec4_type);
 +  dst_reg x_times_one_minus_a = dst_reg(this, glsl_type::vec4_type);
 +  y_times_a.writemask   = dst.writemask;
 +  one_minus_a.writemask = dst.writemask;
 +  x_times_one_minus_a.writemask = dst.writemask;
 +
 +  emit(MUL(y_times_a, y, a));
 +  emit(ADD(one_minus_a, negate(a), src_reg(1.0f)));
 +  emit(MUL(x_times_one_minus_a, x, src_reg(one_minus_a)));
 +  emit(ADD(dst, src_reg(x_times_one_minus_a), src_reg(y_times_a)));
 +   }
 +}

I think we would do better by emitting
ADD(y_minus_x, y, negate(x))
MAC(dst, x, y_minus_x, a)

Then gen4/5 get a win from the algebraic pass existing, like gen6+.
Other than that, I like the series.


pgpFysDz6zu1H.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] mesa: Add core API support for GL_ARB_stencil_texturing (from 4.3).

Kenneth Graunke kenn...@whitecape.org writes:

 While the GL_ARB_stencil_texturing extension does not allow the creation
 of stencil textures, it does allow shaders to sample stencil values
 stored in packed depth/stencil textures.

 Specifically, applications can call glTexParameter* with a pname of
 GL_DEPTH_STENCIL_TEXTURE_MODE and value of either GL_DEPTH_COMPONENT or
 GL_STENCIL_INDEX to select which component they wish to sample.  The
 default value is GL_DEPTH_COMPONENT (for traditional depth sampling).

 Shaders should use an unsigned integer sampler (presumably usampler2D)
 to access stencil data.  Otherwise, results are undefined.  Using shadow
 samplers with GL_STENCIL_INDEX selected also is undefined behavior.

 This patch creates a new gl_texture_object field, StencilSampling, to
 indicate that stencil should be sampled rather than depth.  (I chose to
 use a boolean since I figured it would be more convenient for drivers.)
 It also introduces the [Get]TexParameter code to get and set the value,
 and of course the extension plumbing.

The only thing I see missing is:

'Add a new bullet point for the conditions that cause the texture
 to not be complete:

 * The internal format of the texture is DEPTH_STENCIL, the
 DEPTH_STENCIL_TEXTURE_MODE for the texture is STENCIL_INDEX and either 
the
 magnification filter or the minification filter is not NEAREST.'

Other than that, this series looks great.  Patch 2 is

Reviewed-by: Eric Anholt e...@anholt.net


pgp8fZNF2zpJt.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] i965/vec4: Handle ir_triop_lrp on Gen4-5 as well.

On Mon, Feb 24, 2014 at 10:15 AM, Eric Anholt e...@anholt.net wrote:
 I think we would do better by emitting
 ADD(y_minus_x, y, negate(x))
 MAC(dst, x, y_minus_x, a)

MAC only takes two arguments, so
 - if you meant MAD, there's no MAD on platforms that don't have LRP
 - if you meant MAC(dst, ...) I don't see a way of doing it only two
instructions, but we could do

MOV(acc, x)
ADD(y_minus_x, y, negate(x)
MAC(dst, y_minus_x, a)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] dri3: Add GLX_EXT_buffer_age support

Adel Gadllah adel.gadl...@gmail.com writes:

 ---
  src/glx/dri2_glx.c  |  1 +
  src/glx/dri3_glx.c  | 18 ++
  src/glx/dri3_priv.h |  2 ++
  src/glx/glx_pbuffer.c   |  8 
  src/glx/glxclient.h |  1 +
  src/glx/glxextensions.c |  1 +
  src/glx/glxextensions.h |  1 +
  7 files changed, 32 insertions(+)

 diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
 index 67fe9c1..146802a 100644
 --- a/src/glx/dri2_glx.c
 +++ b/src/glx/dri2_glx.c
 @@ -1288,6 +1288,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
 psp-waitForSBC = NULL;
 psp-setSwapInterval = NULL;
 psp-getSwapInterval = NULL;
 +   psp-getBufferAge = NULL;
  
 if (pdp-driMinor = 2) {
psp-getDrawableMSC = dri2DrawableGetMSC;
 diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
 index 70ec057..697d448 100644
 --- a/src/glx/dri3_glx.c
 +++ b/src/glx/dri3_glx.c
 @@ -1345,6 +1345,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
 target_msc, int64_t divisor,
   target_msc = priv-msc + priv-swap_interval * (priv-send_sbc - 
 priv-recv_sbc);
  
priv-buffers[buf_id]-busy = 1;
 +  priv-buffers[buf_id]-last_swap = priv-swap_count;
xcb_present_pixmap(c,
   priv-base.xDrawable,
   priv-buffers[buf_id]-pixmap,
 @@ -1379,11 +1380,25 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
 target_msc, int64_t divisor,
xcb_flush(c);
if (priv-stamp)
   ++(*priv-stamp);
 +
 +  priv-swap_count++;
 }

Can't you just use priv-send_sbc for swap_count?  It looks like you've
got the order swapped of the two operations currently:

   * The current back buffer's age is set to 1.
* Any other color buffers' ages are incremented by 1 if
  their age was previously greater than 0.

As is, when an application gets the buffer from the first swap back, it
will get a 0 (invalid) age instead of a valid age.


pgp9uKajCZHwR.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 01/27] i965: Remove unused sampler key fields

It seems very weird that these are unused.  Are GL_YCBCR_MESA just 
completely broken on our driver?  If so, we should probably disable that 
extension...


On 02/22/2014 01:05 AM, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
  src/mesa/drivers/dri/i965/brw_program.h |  6 --
  src/mesa/drivers/dri/i965/brw_wm.c  | 10 --
  2 files changed, 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 59f628b..6aa0ac1 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -42,12 +42,6 @@ struct brw_sampler_prog_key_data {
 uint16_t gl_clamp_mask[3];

 /**
-* YUV conversions, needed for the GL_MESA_ycbcr extension.
-*/
-   uint16_t yuvtex_mask;
-   uint16_t yuvtex_swap_mask; /** UV swaped */
-
-   /**
  * For RG32F, gather4's channel select is broken.
  */
 uint16_t gather_channel_quirk_mask;
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index 0d0d6ec..9edb245 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -238,10 +238,6 @@ brw_debug_recompile_sampler_key(struct brw_context *brw,
old_key-gl_clamp_mask[1], key-gl_clamp_mask[1]);
 found |= key_debug(brw, GL_CLAMP enabled on any texture unit's 3rd 
coordinate,
old_key-gl_clamp_mask[2], key-gl_clamp_mask[2]);
-   found |= key_debug(brw, GL_MESA_ycbcr texturing\n,
-  old_key-yuvtex_mask, key-yuvtex_mask);
-   found |= key_debug(brw, GL_MESA_ycbcr UV swapping\n,
-  old_key-yuvtex_swap_mask, key-yuvtex_swap_mask);
 found |= key_debug(brw, gather channel quirk on any texture unit,
old_key-gather_channel_quirk_mask, 
key-gather_channel_quirk_mask);

@@ -356,12 +352,6 @@ brw_populate_sampler_prog_key_data(struct gl_context *ctx,
   if (alpha_depth || (brw-gen  8  !brw-is_haswell))
  key-swizzles[s] = brw_get_texture_swizzle(ctx, t);

-if (img-InternalFormat == GL_YCBCR_MESA) {
-   key-yuvtex_mask |= 1  s;
-   if (img-TexFormat == MESA_FORMAT_YCBCR)
-   key-yuvtex_swap_mask |= 1  s;
-}
-
 if (sampler-MinFilter != GL_NEAREST 
 sampler-MagFilter != GL_NEAREST) {
if (sampler-WrapS == GL_CLAMP)



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 04/27] i965: Allow w-tiled miptree offsets to be resolved as y-tiled directly


On 02/22/2014 01:05 AM, Topi Pohjolainen wrote:

This is not utilised yet but will be needed when W-tiled stencil is
sampled as Y-tiled.

Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
  src/mesa/drivers/dri/i965/intel_fbo.h |  2 +-
  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 11 +--
  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  1 +
  src/mesa/drivers/dri/i965/intel_tex_image.c   |  3 ++-
  4 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.h 
b/src/mesa/drivers/dri/i965/intel_fbo.h
index b8db7e2..05a2ea8 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.h
+++ b/src/mesa/drivers/dri/i965/intel_fbo.h
@@ -191,7 +191,7 @@ intel_renderbuffer_get_tile_offsets(struct 
intel_renderbuffer *irb,
  uint32_t *tile_y)
  {
 return intel_miptree_get_tile_offsets(irb-mt, irb-mt_level, 
irb-mt_layer,
- tile_x, tile_y);
+ false, tile_x, tile_y);
  }

  bool
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 89df0d3..b48dc5f 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -943,6 +943,7 @@ intel_miptree_get_image_offset(const struct 
intel_mipmap_tree *mt,
  uint32_t
  intel_miptree_get_tile_offsets(const struct intel_mipmap_tree *mt,
 GLuint level, GLuint slice,
+   bool map_w_as_y_tiled,
 uint32_t *tile_x,
 uint32_t *tile_y)


It seems that all the other functions have map_w_as_y_tiled as the last 
parameter.  This function should use the same pattern... to prevent 
future typos.



  {
@@ -950,14 +951,20 @@ intel_miptree_get_tile_offsets(const struct 
intel_mipmap_tree *mt,
 uint32_t x, y;
 uint32_t mask_x, mask_y;

-   intel_region_get_tile_masks(region, mask_x, mask_y, false);
+   intel_region_get_tile_masks(region, mask_x, mask_y, map_w_as_y_tiled);
 intel_miptree_get_image_offset(mt, level, slice, x, y);
+
+   /* Y-tile is twice as wide and half as high as W-tile */
+   if (map_w_as_y_tiled) {
+  x *= 2;
+  y /= 2;
+   }

 *tile_x = x  mask_x;
 *tile_y = y  mask_y;

 return intel_region_get_aligned_offset(region, x  ~mask_x, y  ~mask_y,
-  false);
+  map_w_as_y_tiled);




  }

  static void
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 4250e0f..ba80baa 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -531,6 +531,7 @@ intel_miptree_get_dimensions_for_image(struct 
gl_texture_image *image,
  uint32_t
  intel_miptree_get_tile_offsets(const struct intel_mipmap_tree *mt,
 GLuint level, GLuint slice,
+   bool map_w_as_y_tiled,
 uint32_t *tile_x,
 uint32_t *tile_y);

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index ee02e68..2e66729 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -242,7 +242,8 @@ intel_set_texture_image_region(struct gl_context *ctx,
 intel_image-mt-level[0].slice[0].x_offset = tile_x;
 intel_image-mt-level[0].slice[0].y_offset = tile_y;

-   intel_miptree_get_tile_offsets(intel_image-mt, 0, 0, draw_x, draw_y);
+   intel_miptree_get_tile_offsets(intel_image-mt, 0, 0, false,
+  draw_x, draw_y);

 /* From OES_EGL_image error reporting. We report GL_INVALID_OPERATION
  * for EGL images from non-tile aligned sufaces in gen4 hw and earlier 
which has



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 02/27] i965: Mark sources for offset getters as constants


Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 02/22/2014 01:05 AM, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +++---
  src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4 ++--
  src/mesa/drivers/dri/i965/intel_regions.c | 4 ++--
  src/mesa/drivers/dri/i965/intel_regions.h | 4 ++--
  4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 8e0d2be..89df0d3 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -920,7 +920,7 @@ intel_miptree_set_image_offset(struct intel_mipmap_tree *mt,
  }

  void
-intel_miptree_get_image_offset(struct intel_mipmap_tree *mt,
+intel_miptree_get_image_offset(const struct intel_mipmap_tree *mt,
   GLuint level, GLuint slice,
   GLuint *x, GLuint *y)
  {
@@ -941,12 +941,12 @@ intel_miptree_get_image_offset(struct intel_mipmap_tree 
*mt,
   * from there.
   */
  uint32_t
-intel_miptree_get_tile_offsets(struct intel_mipmap_tree *mt,
+intel_miptree_get_tile_offsets(const struct intel_mipmap_tree *mt,
 GLuint level, GLuint slice,
 uint32_t *tile_x,
 uint32_t *tile_y)
  {
-   struct intel_region *region = mt-region;
+   const struct intel_region *region = mt-region;
 uint32_t x, y;
 uint32_t mask_x, mask_y;

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 6c45cfd..4250e0f 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -520,7 +520,7 @@ bool intel_miptree_match_image(struct intel_mipmap_tree *mt,
  struct gl_texture_image *image);

  void
-intel_miptree_get_image_offset(struct intel_mipmap_tree *mt,
+intel_miptree_get_image_offset(const struct intel_mipmap_tree *mt,
   GLuint level, GLuint slice,
   GLuint *x, GLuint *y);

@@ -529,7 +529,7 @@ intel_miptree_get_dimensions_for_image(struct 
gl_texture_image *image,
 int *width, int *height, int *depth);

  uint32_t
-intel_miptree_get_tile_offsets(struct intel_mipmap_tree *mt,
+intel_miptree_get_tile_offsets(const struct intel_mipmap_tree *mt,
 GLuint level, GLuint slice,
 uint32_t *tile_x,
 uint32_t *tile_y);
diff --git a/src/mesa/drivers/dri/i965/intel_regions.c 
b/src/mesa/drivers/dri/i965/intel_regions.c
index a845683..d891e09 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.c
+++ b/src/mesa/drivers/dri/i965/intel_regions.c
@@ -283,7 +283,7 @@ intel_region_release(struct intel_region **region_handle)
   * untiled, the masks are set to 0.
   */
  void
-intel_region_get_tile_masks(struct intel_region *region,
+intel_region_get_tile_masks(const struct intel_region *region,
  uint32_t *mask_x, uint32_t *mask_y,
  bool map_stencil_as_y_tiled)
  {
@@ -316,7 +316,7 @@ intel_region_get_tile_masks(struct intel_region *region,
   * multiples of the tile size.
   */
  uint32_t
-intel_region_get_aligned_offset(struct intel_region *region, uint32_t x,
+intel_region_get_aligned_offset(const struct intel_region *region, uint32_t x,
  uint32_t y, bool map_stencil_as_y_tiled)
  {
 int cpp = region-cpp;
diff --git a/src/mesa/drivers/dri/i965/intel_regions.h 
b/src/mesa/drivers/dri/i965/intel_regions.h
index c301f23..eb2123e 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.h
+++ b/src/mesa/drivers/dri/i965/intel_regions.h
@@ -104,12 +104,12 @@ void intel_region_reference(struct intel_region **dst,
  void intel_region_release(struct intel_region **ib);

  void
-intel_region_get_tile_masks(struct intel_region *region,
+intel_region_get_tile_masks(const struct intel_region *region,
  uint32_t *mask_x, uint32_t *mask_y,
  bool map_stencil_as_y_tiled);

  uint32_t
-intel_region_get_aligned_offset(struct intel_region *region, uint32_t x,
+intel_region_get_aligned_offset(const struct intel_region *region, uint32_t x,
  uint32_t y, bool map_stencil_as_y_tiled);

  /**



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 03/27] i965/vec4: Mark invariant members as constants in vec4_visitor


Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 02/22/2014 01:05 AM, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
  src/mesa/drivers/dri/i965/brw_vec4.h   | 6 +++---
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8 
  2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 1e0d882..a79a289 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -311,9 +311,9 @@ public:
return dst_reg(retype(brw_null_reg(), BRW_REGISTER_TYPE_UD));
 }

-   struct brw_vec4_compile *c;
-   const struct brw_vec4_prog_key *key;
-   struct brw_vec4_prog_data *prog_data;
+   struct brw_vec4_compile * const c;
+   const struct brw_vec4_prog_key * const key;
+   struct brw_vec4_prog_data * const prog_data;
 unsigned int sanity_param_count;

 char *fail_msg;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index ba299be..c11c514 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3315,7 +3315,10 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
 shader_time_shader_type st_base,
 shader_time_shader_type st_written,
 shader_time_shader_type st_reset)
-   : sanity_param_count(0),
+   : c(c),
+ key(key),
+ prog_data(prog_data),
+ sanity_param_count(0),
   fail_msg(NULL),
   first_non_payload_grf(0),
   need_all_constants_in_pull_buffer(false),
@@ -3337,10 +3340,7 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
 this-current_annotation = NULL;
 memset(this-output_reg_annotation, 0, 
sizeof(this-output_reg_annotation));

-   this-c = c;
 this-prog = prog;
-   this-key = key;
-   this-prog_data = prog_data;
 this-stage_prog_data = prog_data-base;

 this-variable_ht = hash_table_ctor(0,



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 05/27] i965/wm: Use resolved miptree consistently in surface setup


On 02/22/2014 01:05 AM, Topi Pohjolainen wrote:

Most of the logic refers to the local variable 'mt' directly but
a few cases use 'intelObj-mt' instead. These are the same for
now but will be different once stencil miptree gets used.

Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
  src/mesa/drivers/dri/i965/brw_wm_surface_state.c  | 12 ++--
  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |  6 +++---
  2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 303b5cb..73acae5 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -319,18 +319,18 @@ brw_update_texture_surface(struct gl_context *ctx,
  BRW_SURFACE_CUBEFACE_ENABLES |
  tex_format  BRW_SURFACE_FORMAT_SHIFT);

-   surf[1] = intelObj-mt-region-bo-offset64 + intelObj-mt-offset; /* 
reloc */
+   surf[1] = mt-region-bo-offset64 + mt-offset; /* reloc */

 surf[2] = ((intelObj-_MaxLevel - tObj-BaseLevel)  
BRW_SURFACE_LOD_SHIFT |
  (mt-logical_width0 - 1)  BRW_SURFACE_WIDTH_SHIFT |
  (mt-logical_height0 - 1)  BRW_SURFACE_HEIGHT_SHIFT);

-   surf[3] = (brw_get_surface_tiling_bits(intelObj-mt-region-tiling) |
+   surf[3] = (brw_get_surface_tiling_bits(mt-region-tiling) |
  (mt-logical_depth0 - 1)  BRW_SURFACE_DEPTH_SHIFT |
- (intelObj-mt-region-pitch - 1) 
+ (mt-region-pitch - 1) 
  BRW_SURFACE_PITCH_SHIFT);

-   surf[4] = (brw_get_surface_num_multisamples(intelObj-mt-num_samples) |
+   surf[4] = (brw_get_surface_num_multisamples(mt-num_samples) |
SET_FIELD(tObj-BaseLevel - mt-first_level, 
BRW_SURFACE_MIN_LOD));

 surf[5] = mt-align_h == 4 ? BRW_SURFACE_VERTICAL_ALIGN_ENABLE : 0;
@@ -338,8 +338,8 @@ brw_update_texture_surface(struct gl_context *ctx,
 /* Emit relocation to surface contents */
 drm_intel_bo_emit_reloc(brw-batch.bo,
   *surf_offset + 4,
-  intelObj-mt-region-bo,
-   surf[1] - intelObj-mt-region-bo-offset64,
+  mt-region-bo,


Can also fix the indentation of this line.  It looks like it has 
(previously) mixed tabs and spaces.  With that changed,


Reviewed-by: Ian Romanick ian.d.roman...@intel.com


+   surf[1] - mt-region-bo-offset64,
   I915_GEM_DOMAIN_SAMPLER, 0);
  }

diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index 12d0fa9..9d9c375 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -320,7 +320,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
 surf[2] = SET_FIELD(mt-logical_width0 - 1, GEN7_SURFACE_WIDTH) |
   SET_FIELD(mt-logical_height0 - 1, GEN7_SURFACE_HEIGHT);
 surf[3] = SET_FIELD(mt-logical_depth0 - 1, BRW_SURFACE_DEPTH) |
- ((intelObj-mt-region-pitch) - 1);
+ (mt-region-pitch - 1);

 surf[4] = gen7_surface_msaa_bits(mt-num_samples, mt-msaa_layout);

@@ -359,8 +359,8 @@ gen7_update_texture_surface(struct gl_context *ctx,
 /* Emit relocation to surface contents */
 drm_intel_bo_emit_reloc(brw-batch.bo,
   *surf_offset + 4,
-  intelObj-mt-region-bo,
-   surf[1] - intelObj-mt-region-bo-offset64,
+   mt-region-bo,
+   surf[1] - mt-region-bo-offset64,
   I915_GEM_DOMAIN_SAMPLER, 0);

 gen7_check_surface_setup(surf, false /* is_render_target */);



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 01/27] i965: Remove unused sampler key fields

2014-02-24 Thread Kenneth Graunke

On 02/24/2014 10:48 AM, Ian Romanick wrote:
 It seems very weird that these are unused.  Are GL_YCBCR_MESA just
 completely broken on our driver?  If so, we should probably disable that
 extension...

Yeah.  The old fragment shader backend had code for this, which used
these fields, but the new backend never had any.  So, I'm pretty sure
GL_YCBCR_MESA has just been broken since Mesa 7.10.

I'm in favor of dropping it.  I think mplayer had code to use it, and
they've just moved on to other paths at this point.



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] [RFC 08/27] i965/fs: Configure w-tiled stencil surfaces as y-tiled on gen6/7

Topi Pohjolainen topi.pohjolai...@intel.com writes:

 Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
 ---
  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 28 
 ++--
  1 file changed, 26 insertions(+), 2 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
 b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
 index 6f23cec..2e841d9 100644
 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
 +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
 @@ -194,12 +194,36 @@ const struct intel_mipmap_tree *
  brw_get_texture_surface(const struct gl_texture_object *tex_obj,
  struct brw_wm_surface *surface)
  {
 -   const struct intel_texture_object *intel_tex = 
 intel_texture_object(tex_obj);
 +   const struct intel_texture_object *intel_tex =
 +  (const struct intel_texture_object *)tex_obj;
 const struct gl_texture_image *first = 
 tex_obj-Image[0][tex_obj-BaseLevel];
 const struct intel_mipmap_tree *mt = intel_tex-mt;
  
 if (tex_obj-StencilSampling  first-_BaseFormat == GL_DEPTH_STENCIL) {
 -  assert(!Stencil indexing shouldn't be enabled yet);
 +  const unsigned level = tex_obj-BaseLevel - mt-first_level;
 +
 +  mt = mt-stencil_mt;
 +
 +  /* Stencil is really W-tiled but as the hardware does not support
 +   * sampling from it, it needs to be treated as Y-tiled with adjusted
 +   * dimensions instead. Y-tiles are twice as wide and half as high as W.
 +   * Also one needs to take into account that both tilings consist of
 +   * 8x4 subtiles.
 +   */
 +  const unsigned x_align = 8, y_align = 4;
 +
 +  surface-tiling = I915_TILING_Y;
 +  surface-width = ALIGN(minify(mt-physical_width0, level), x_align) * 
 2;
 +  surface-height = ALIGN(minify(mt-physical_height0, level), y_align) 
 / 2;
 +  surface-pitch = 2 * mt-region-pitch;
 +  surface-min_lod = 0;
 +  surface-mip_count = 0;
 +  surface-depth = 1;
 +
 +  /* Texture surfaces are always resolved to the layer zero. */
 +  surface-page_offset = intel_miptree_get_tile_offsets(
 +mt, level, 0, true,
 +surface-tile_x, surface-tile_y);

I'm skeptical of this getter -- if you're not just dereferencing the
miptree, something is probably wrong, and Ken's changes for
stencil_texturing looked much more like what I was expecting.  In
particular, it looks like in yours, multiple-miplevel information is
dropped, and the width/height adjustments you're doing mean that you
couldn't sample from multiple miplevels anyway.

Also, all these 2 * mt-region-pitches I'm seeing related to stencil
make me wonder if we can't just change the region pitch to be that.


pgpXPrpMewEoP.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 01/27] i965: Remove unused sampler key fields

2014-02-24 Thread Chris Forbes

Ken,

Just noticed -- all those fields that we're keeping need to be widened
to uint32_t for 32 samplers. None of our sampler quirks get flagged
correctly for `high` samplers on Haswell at present. I'll send some
patches for that this evening if no one beats me to it.

-- Chris

On Tue, Feb 25, 2014 at 8:00 AM, Kenneth Graunke kenn...@whitecape.org wrote:
 On 02/24/2014 10:48 AM, Ian Romanick wrote:
 It seems very weird that these are unused.  Are GL_YCBCR_MESA just
 completely broken on our driver?  If so, we should probably disable that
 extension...

 Yeah.  The old fragment shader backend had code for this, which used
 these fields, but the new backend never had any.  So, I'm pretty sure
 GL_YCBCR_MESA has just been broken since Mesa 7.10.

 I'm in favor of dropping it.  I think mplayer had code to use it, and
 they've just moved on to other paths at this point.


 ___
 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 3/3] dri3: Add GLX_EXT_buffer_age support


Am 24.02.2014 17:58, schrieb Robert Bragg:

Hi Adel,

Hi,

Thanks for look at this; just a few comments...


diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 978730c..afb4206 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -373,6 +373,14 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
  if (!pdraw-textureFormat)
 pdraw-textureFormat =
determineTextureFormat((const int *) data, num_attributes);
+
+if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
+   struct glx_screen *psc = pdraw-psc;
+
+   if (psc-driScreen-getBufferAge != NULL)
+ *value = psc-driScreen-getBufferAge(pdraw);
+}
+
   }
  #endif

Since with dri3 this is a client side only attribute, shouldn't we be
able to simply skip the redundant X round trip above to query the
drawable's attributes?

Yeah good point.


Technically we're supposed to report a GLXBadDrawable if the drawable
isn't currently bound to the current thread's context. I think the
requirement to be bound to a context was added to the spec considering
that if an app were switching between a direct/indirect context the
age state may switch from being client-side to server-side and they
shouldn't have to be kept in sync. glXSwapBuffers has a similar
requirement so it should be possible to borrow some checks from there.

That too.

Apart from that, this patch looks good to me:

Reviewed-by: Robert Bragg rob...@sixbynine.org


Thanks for the review.

Adel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCHv3 0/3] dri3: Add GLX_EXT_buffer_age support

Hi,

OK this version of the patches address the review comments from Ian and
Robert.

The first two ones are actually unmodified just signed them off and added Ian's 
reviewed-by.

The third one now skips the redundant round trip and reports BadDrawable when
the drawable isn't bound to the current context as mandated by the spec.

Adel Gadllah (3):
  glx: Update glxext.h to revision 25407
  glx_pbuffer: Refactor GetDrawableAttribute
  dri3: Add GLX_EXT_buffer_age support

 include/GL/glxext.h | 32 +---
 src/glx/dri2_glx.c  |  1 +
 src/glx/dri3_glx.c  | 18 ++
 src/glx/dri3_priv.h |  2 ++
 src/glx/glx_pbuffer.c   | 38 +-
 src/glx/glxclient.h |  1 +
 src/glx/glxextensions.c |  1 +
 src/glx/glxextensions.h |  1 +
 8 files changed, 86 insertions(+), 8 deletions(-)

-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCHv3 1/3] glx: Update glxext.h to revision 25407

Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
 include/GL/glxext.h | 32 +---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/include/GL/glxext.h b/include/GL/glxext.h
index 8c642f3..826fda5 100644
--- a/include/GL/glxext.h
+++ b/include/GL/glxext.h
@@ -6,7 +6,7 @@ extern C {
 #endif
 
 /*
-** Copyright (c) 2013 The Khronos Group Inc.
+** Copyright (c) 2013-2014 The Khronos Group Inc.
 **
 ** Permission is hereby granted, free of charge, to any person obtaining a
 ** copy of this software and/or associated documentation files (the
@@ -33,10 +33,10 @@ extern C {
 ** used to make the header, and the header can be found at
 **   http://www.opengl.org/registry/
 **
-** Khronos $Revision: 24777 $ on $Date: 2014-01-14 14:02:32 -0800 (Tue, 14 Jan 
2014) $
+** Khronos $Revision: 25407 $ on $Date: 2014-02-18 16:51:56 -0800 (Tue, 18 Feb 
2014) $
 */
 
-#define GLX_GLXEXT_VERSION 20140114
+#define GLX_GLXEXT_VERSION 20140218
 
 /* Generated C header for:
  * API: glx
@@ -407,6 +407,32 @@ GLXPixmap glXCreateGLXPixmapMESA (Display *dpy, 
XVisualInfo *visual, Pixmap pixm
 #endif
 #endif /* GLX_MESA_pixmap_colormap */
 
+#ifndef GLX_MESA_query_renderer
+#define GLX_MESA_query_renderer 1
+#define GLX_RENDERER_VENDOR_ID_MESA   0x8183
+#define GLX_RENDERER_DEVICE_ID_MESA   0x8184
+#define GLX_RENDERER_VERSION_MESA 0x8185
+#define GLX_RENDERER_ACCELERATED_MESA 0x8186
+#define GLX_RENDERER_VIDEO_MEMORY_MESA0x8187
+#define GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA 0x8188
+#define GLX_RENDERER_PREFERRED_PROFILE_MESA 0x8189
+#define GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA 0x818A
+#define GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA 0x818B
+#define GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA 0x818C
+#define GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x818D
+#define GLX_RENDERER_ID_MESA  0x818E
+typedef Bool ( *PFNGLXQUERYCURRENTRENDERERINTEGERMESAPROC) (int attribute, 
unsigned int *value);
+typedef const char *( *PFNGLXQUERYCURRENTRENDERERSTRINGMESAPROC) (int 
attribute);
+typedef Bool ( *PFNGLXQUERYRENDERERINTEGERMESAPROC) (Display *dpy, int screen, 
int renderer, int attribute, unsigned int *value);
+typedef const char *( *PFNGLXQUERYRENDERERSTRINGMESAPROC) (Display *dpy, int 
screen, int renderer, int attribute);
+#ifdef GLX_GLXEXT_PROTOTYPES
+Bool glXQueryCurrentRendererIntegerMESA (int attribute, unsigned int *value);
+const char *glXQueryCurrentRendererStringMESA (int attribute);
+Bool glXQueryRendererIntegerMESA (Display *dpy, int screen, int renderer, int 
attribute, unsigned int *value);
+const char *glXQueryRendererStringMESA (Display *dpy, int screen, int 
renderer, int attribute);
+#endif
+#endif /* GLX_MESA_query_renderer */
+
 #ifndef GLX_MESA_release_buffers
 #define GLX_MESA_release_buffers 1
 typedef Bool ( *PFNGLXRELEASEBUFFERSMESAPROC) (Display *dpy, GLXDrawable 
drawable);
-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCHv3 2/3] glx_pbuffer: Refactor GetDrawableAttribute

Move the pdraw != NULL check out so that they don't
have to be duplicated.

Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
 src/glx/glx_pbuffer.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 411d6e5..978730c 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -350,6 +350,9 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
  _XEatData(dpy, length);
   }
   else {
+#if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
+ __GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable);
+#endif
  _XRead(dpy, (char *) data, length * sizeof(CARD32));
 
  /* Search the set of returned attributes for the attribute requested 
by
@@ -363,13 +366,11 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
  }
 
 #if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
- {
-__GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable);
-
-if (pdraw != NULL  !pdraw-textureTarget)
+ if (pdraw != NULL) {
+if (!pdraw-textureTarget)
pdraw-textureTarget =
   determineTextureTarget((const int *) data, num_attributes);
-if (pdraw != NULL  !pdraw-textureFormat)
+if (!pdraw-textureFormat)
pdraw-textureFormat =
   determineTextureFormat((const int *) data, num_attributes);
  }
-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCHv3 3/3] dri3: Add GLX_EXT_buffer_age support

Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
Reviewed-by: Robert Bragg rob...@sixbynine.org
---
 src/glx/dri2_glx.c  |  1 +
 src/glx/dri3_glx.c  | 18 ++
 src/glx/dri3_priv.h |  2 ++
 src/glx/glx_pbuffer.c   | 33 ++---
 src/glx/glxclient.h |  1 +
 src/glx/glxextensions.c |  1 +
 src/glx/glxextensions.h |  1 +
 7 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 67fe9c1..146802a 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1288,6 +1288,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
psp-waitForSBC = NULL;
psp-setSwapInterval = NULL;
psp-getSwapInterval = NULL;
+   psp-getBufferAge = NULL;
 
if (pdp-driMinor = 2) {
   psp-getDrawableMSC = dri2DrawableGetMSC;
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 70ec057..697d448 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1345,6 +1345,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc = priv-msc + priv-swap_interval * (priv-send_sbc - 
priv-recv_sbc);
 
   priv-buffers[buf_id]-busy = 1;
+  priv-buffers[buf_id]-last_swap = priv-swap_count;
   xcb_present_pixmap(c,
  priv-base.xDrawable,
  priv-buffers[buf_id]-pixmap,
@@ -1379,11 +1380,25 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   xcb_flush(c);
   if (priv-stamp)
  ++(*priv-stamp);
+
+  priv-swap_count++;
}
 
return ret;
 }
 
+static int
+dri3_get_buffer_age(__GLXDRIdrawable *pdraw)
+{
+  struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+  const struct dri3_buffer *const back = dri3_back_buffer(priv);
+
+  if (back-last_swap != 0)
+ return priv-swap_count - back-last_swap;
+  else
+ return 0;
+}
+
 /** dri3_open
  *
  * Wrapper around xcb_dri3_open
@@ -1742,6 +1757,9 @@ dri3_create_screen(int screen, struct glx_display * priv)
psp-copySubBuffer = dri3_copy_sub_buffer;
__glXEnableDirectExtension(psc-base, GLX_MESA_copy_sub_buffer);
 
+   psp-getBufferAge = dri3_get_buffer_age;
+   __glXEnableDirectExtension(psc-base, GLX_EXT_buffer_age);
+
free(driverName);
free(deviceName);
 
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 1d124f8..d00440a 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -97,6 +97,7 @@ struct dri3_buffer {
uint32_t cpp;
uint32_t flags;
uint32_t width, height;
+   uint32_t last_swap;
 
enum dri3_buffer_typebuffer_type;
 };
@@ -184,6 +185,7 @@ struct dri3_drawable {
struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
int num_back;
+   uint32_t swap_count;
 
uint32_t *stamp;
 
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 978730c..0cd0554 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -285,6 +285,10 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
unsigned int num_attributes;
GLboolean use_glx_1_3;
 
+#if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
+   __GLXDRIdrawable *pdraw;
+#endif
+
if (dpy == NULL)
   return 0;
 
@@ -311,6 +315,32 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
if (!opcode)
   return 0;
 
+#if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
+   pdraw = GetGLXDRIDrawable(dpy, drawable);
+
+   if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
+  struct glx_screen *psc = pdraw-psc;
+  struct glx_context *gc = __glXGetCurrentContext();
+
+  /* The GLX_EXT_buffer_age spec says:
+   *
+   *   If querying GLX_BACK_BUFFER_AGE_EXT and draw is not bound to
+   *   the calling thread's current context a GLXBadDrawable error is
+   *   generated.
+   */
+  if (gc == NULL || gc-currentDpy != dpy ||
+ (gc-currentDrawable != drawable  gc-currentReadable != drawable)) 
{
+ __glXSendError(dpy, GLXBadDrawable, drawable, 
X_GLXGetDrawableAttributes, false);
+ return 0;
+  }
+
+  if (psc-driScreen-getBufferAge != NULL)
+ *value = psc-driScreen-getBufferAge(pdraw);
+
+  return 0;
+   }
+#endif
+
LockDisplay(dpy);
 
if (use_glx_1_3) {
@@ -350,9 +380,6 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
  _XEatData(dpy, length);
   }
   else {
-#if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
- __GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable);
-#endif
  _XRead(dpy, (char *) data, length * sizeof(CARD32));
 
  /* Search the set of returned attributes for the attribute requested 
by
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index a7118af..74c19c4 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -125,6 +125,7 @@ struct __GLXDRIscreenRec {
 int64_t *msc, int64_t *sbc);
int

Re: [Mesa-dev] [RFC PATCH] i965/gs: add snb support

2014-02-24 Thread Paul Berry

On 24 February 2014 00:36, Ilia Mirkin imir...@alum.mit.edu wrote:

 Before you read any further, this is nowhere close to working. However
 it's in
 a state where I think most of the structure is there, albeit with a lot of
 XXX
 comments. And I haven't actually implemented the new opcodes I've added.

 I was hoping one or two Intel people could take a look at this and let me
 know
 of any pitfalls I'm likely to run into. I've already gotten a lot of help
 and
 advice from Ken, but wanted to put something out publicly.

 Any and all feedback much appreciated!

 Not-Signed-off-by: Ilia Mirkin imir...@alum.mit.edu


I'm really excited to see you're working on this!  A lot of people are
going to be really happy to see geometry shader support added to Gen6.

AFAICT, your approach is good.  I plan to look at it in more detail later
today or sometime tomorrow.  But before I do, here are some general
comments:

1. For long-term readability, it might be useful to have 3 classes:
vec4_gs_visitor (for stuff that's common to all gs visitors),
gen6_gs_visitor (for the stuff that's specific to gen6 geometry shaders),
and gen7plus_gs_visitor (for the stuff that's specific to gen7+ geometry
shaders).  What you currently have is a little harder to read, because it
means that to understand gen6 geometry shaders, you have to keep in mind
that some of the code in vec4_gs_visitor is never going to be executed
because it will always be overridden by gen6_gs_visitor.

2. Stream output (a.k.a. transform feedback): As you've probably already
figured out, transform feedback on gen6 is tricky because the hardware
doesn't have a dedicated pipeline stage for it; you have to emit code in
the geometry shader to do it.  This is a problem because the GL spec says
that two things are supposed to happen in between the GS stage and
transform feedback: dangling vertex removal (ignoring line strips
containing just a single vertex and ignoring triangle strips containing
less than 2 vertices), and expanding line/triangle strips into individual
line segments/triangles.  In Gen6, these operations happen after the GS
stage, so the code you emit in the geometry shader to do transform feedback
needs to simulate them.

Back when I first implemented transform feedback for Gen6, supporting
user-defined geometry shaders was the furthest thing from my mind, so I
implemented the transform feedback code in raw assembly rather than
re-using the vec4_visitor/vec4_generator infrastructure (see
gen6_sol_program()).  Unfortunately that's going to make it hard to re-use
that code in user-defined geometry shaders.  Also, when I implemented that
code, I was able to make some major simplifying assumptions because there
was no user-defined geometry shader--that meant that the number of vertices
to process was known at compile time, and I didn't have to worry about
dangling vertex removal or expanding line/triangle strips into individual
line segments/triangles (because the hardware automatically performs those
operations before invoking the GS).  You're not going to have that luxury.
My recommendation is: feel free to use gen6_sol_program() as a reference
point, but don't bother trying to re-use it--the simplifying assumptions
are just going to make it too different from what you want.  I'd recommend
leaving gen6_sol_program() around to handle the case where there's no
user-defined geometry shader, and then you can write fresh code for
handling transform feedback when there *is* a user-defined geometry shader.

Before you go too far on the implementation, I'd also recommend writing
some new piglit tests in tests/spec/glsl-1.50/execution/geometry/ to verify
that dangling vertex removal and strip expansion are handled properly for
transform feedback data.  If you don't have gs-supporting hardware at your
disposal to validate those tests against, I (or one of the Intel folks)
would be happy to validate the tests for you.  Note in particular that in
order to expand a triangle strip to triangles, you have to be careful with
the order to make sure that both the provoking vertex and the triangle
orientation are preserved (it's not necessary to follow
ARB_provoking_vertex, though; you can just assume the GL default of
LAST_VERTEX_CONVENTION applies).  For example, if the pre-expansion vertex
order is ABCDEF, then the only correct post-expansion order is
ABC,CBD,CDE,EDF.  I'm not sure whether Gen7+ hardware gets this order
exactly right in all circumstances, but it seems like it should be easy to
get it right on Gen6, because the order is entirely determined by software
:)

I'd also recommend adding some piglit tests to make sure that transform
feedback overflow conditions are handled properly when a geometry shader is
in use, since overflow handling on Gen6 is (partially) the responsibility
of the shader code you generate, and you're not going to be able to
piggy-back on the overflow handling in gen6_sol_program().

One other note: check out this text from the Gen6

[Mesa-dev] [PATCH] build: llvm libs may not be in system search path, add rpath

On my gentoo system, llvm libs are in /usr/lib64/llvm, and llvm-config
 --ldflags does not provide the rpath (it does, of course, provide a -L).
This adds the llvm dir to the rpath. It should be harmless if the path
is a system path, and should make things work when it's not.

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 24ffc54..54f0de69 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1553,6 +1553,7 @@ if test x$enable_gallium_llvm = xyes; then
 LLVM_CXXFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cxxflags`
 LLVM_INCLUDEDIR=`$LLVM_CONFIG --includedir`
 LLVM_LIBDIR=`$LLVM_CONFIG --libdir`
+LLVM_LDFLAGS=-Wl,-rpath,$LLVM_LIBDIR $LLVM_LDFLAGS
 
 AC_COMPUTE_INT([LLVM_VERSION_MAJOR], [LLVM_VERSION_MAJOR],
 [#include ${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h])
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/25] dri/radeon: create radeon{Vendor, GetRenderer}String helpers

On Sat, Feb 22, 2014 at 4:03 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 To be used by the upcomming GLX_MESA_query_renderer implementation.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  .../drivers/dri/radeon/radeon_common_context.c | 50 
 +-
  .../drivers/dri/radeon/radeon_common_context.h |  4 ++
  src/mesa/drivers/dri/radeon/radeon_screen.h|  2 +
  3 files changed, 35 insertions(+), 21 deletions(-)

[snip]
 diff --git a/src/mesa/drivers/dri/radeon/radeon_screen.h 
 b/src/mesa/drivers/dri/radeon/radeon_screen.h
 index 03abb2a..39341c8 100644
 --- a/src/mesa/drivers/dri/radeon/radeon_screen.h
 +++ b/src/mesa/drivers/dri/radeon/radeon_screen.h
 @@ -211,6 +211,8 @@ struct __DRIimageRec {
  #define untile_imager200_untile_image
  #define set_re_cntl_d3d r200_set_re_cntl_d3d
  #define radeonDestroyBuffer r200_radeonDestroyBuffer
 +#define radeonVendorString  r200_radeonVendorString
 +#define radeonGetRendererString r200_radeonGetRendererString
  #endif

Where are these r200 functions implemented?

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

Roland,

The version CAPs that Emil wants to add have very little to do with
which features a driver supports. The versions cannot be derived from
other CAPs, instead, it should match what you get after you create an
OpenGL context. For example, if your driver can do GL 4.0, the driver
cannot report that it can do 4.0. Instead, it should say it can do
3.3, because that's what core Mesa can do. The only purpose of these
new version CAPs is to match what core Mesa does without asking core
Mesa. It's ugly, but it's the least invasive solution.

Of course, it can actually be done cleanly, e.g. making both
main/version.c and st_extensions.c independent of gl_context and only
using a DRI screen or something like that, but that needs a lot more
work.

Marek

On Sat, Feb 22, 2014 at 10:46 PM, Roland Scheidegger srol...@vmware.com wrote:


 - Original Message -
 From: Emil Velikov emil.l.veli...@gmail.com
 To: Roland Scheidegger srol...@vmware.com, mesa-dev@lists.freedesktop.org
 Cc: emil l velikov emil.l.veli...@gmail.com
 Sent: Saturday, February 22, 2014 2:02:08 PM
 Subject: Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version 
 pipe-caps

 On 22/02/14 12:02, Roland Scheidegger wrote:
  Am 22.02.2014 04:04, schrieb Emil Velikov:
  According to the GLX_MESA_query_renderer spec each driver should
  be able to report the version of each GL api they support before
  creating a context.
 
  Currently both classic mesa and gallium evaluate the version post
  context creation and while the classic drivers set the max_gl*version
  according to their capabilities, gallium uses fixed values which
  are not the best approach due to driver differences.
 
  Add pipe-caps so that each driver can provide their individual
  capabilites.
 
  Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
  ---
   src/gallium/docs/source/screen.rst   | 8 +++-
   src/gallium/include/pipe/p_defines.h | 6 +-
   2 files changed, 12 insertions(+), 2 deletions(-)
 
  diff --git a/src/gallium/docs/source/screen.rst
  b/src/gallium/docs/source/screen.rst
  index bd553f4..7b72133 100644
  --- a/src/gallium/docs/source/screen.rst
  +++ b/src/gallium/docs/source/screen.rst
  @@ -169,7 +169,7 @@ The integer capabilities:
 since they are linked) a driver can support. Returning 0 is equivalent
 to returning 1 because every driver has to support at least a single
 viewport/scissor combination.
  -* ''PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
  +* ``PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
 PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE.
   * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
 different sizes for fb color/zs attachments. This controls whether
  @@ -182,6 +182,12 @@ The integer capabilities:
 vertex components output by a single invocation of a geometry shader.
 This is the product of the number of attribute components per vertex
 and
 the number of output vertices.
  +* ``PIPE_CAP_MAX_GL_CORE_VERSION``: The maximum OpenGL (Core profile)
  version
  +  supported.
  +* ``PIPE_CAP_MAX_GL_COMPAT_VERSION``: The maximum OpenGL (Compatibility
  profile)
  +  version supported.
  +* ``PIPE_CAP_MAX_GL_ES1_VERSION``: The maximum OpenGL ES1 version
  supported.
  +* ``PIPE_CAP_MAX_GL_ES2_VERSION``: The maximum OpenGL ES2 version
  supported.
 
 
   .. _pipe_capf:
  diff --git a/src/gallium/include/pipe/p_defines.h
  b/src/gallium/include/pipe/p_defines.h
  index 83815cd..5c27f9c 100644
  --- a/src/gallium/include/pipe/p_defines.h
  +++ b/src/gallium/include/pipe/p_defines.h
  @@ -522,7 +522,11 @@ enum pipe_cap {
  PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
  PIPE_CAP_TGSI_VS_LAYER = 87,
  PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES = 88,
  -   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89
  +   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89,
  +   PIPE_CAP_MAX_GL_CORE_VERSION = 90,
  +   PIPE_CAP_MAX_GL_COMPAT_VERSION = 91,
  +   PIPE_CAP_MAX_GL_ES1_VERSION = 92,
  +   PIPE_CAP_MAX_GL_ES2_VERSION = 93,
   };
 
   #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1  0)
 
 
  Hmm do you really need all these different cap bits? Generally, the
  difference between ES/CORE/COMPAT contexts isn't hw related at all, and
  thus not really (gallium) driver related. So, obviously, every driver
  can do ES11 for instance, it should be impossible to write a gallium
  driver which can't. Similarly, I don't think core/compat needs a
  different query neither, though I guess ES2 version being separate might
  make sense.
 
 If you can think of a way to retrieve the gl* version that a driver
 support without ever having a gl_context I would love to hear how we can
 do that. GLX_MESA_query_renderer requires from the driver to state the
 version of each api it supports prior of context creation.

 Honestly I felt a bit bad about adding all those caps, but this is the
 least evasive way of handling it. I will drop the ES1 cap would love to

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

On Sun, Feb 23, 2014 at 4:26 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Now that I think about it, one could copy the extension list and
 (context) constants to pipe_screen. This way on st_api_create_context,
 we'll just copy the initial values over. FWIW we'll still be able to
 amend the extension list via MESA_EXTENSION_OVERRIDE, during the
 _mesa_make_current call.

State trackers cannot copy anything to pipe_screen. The pipe_screen
structure should be immutable after it's created.

Setting the GL versions for MESA_query_renderer in
st_api_create_context is too late. The extension queries must return
correct values before st_api_create_context is called.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

Am 24.02.2014 21:23, schrieb Marek Olšák:
 Roland,
 
 The version CAPs that Emil wants to add have very little to do with 
 which features a driver supports. The versions cannot be derived
 from other CAPs, instead, it should match what you get after you
 create an OpenGL context. For example, if your driver can do GL 4.0,
 the driver cannot report that it can do 4.0. Instead, it should say
 it can do 3.3, because that's what core Mesa can do. The only purpose
 of these new version CAPs is to match what core Mesa does without
 asking core Mesa. It's ugly, but it's the least invasive solution.
 
 Of course, it can actually be done cleanly, e.g. making both 
 main/version.c and st_extensions.c independent of gl_context and
 only using a DRI screen or something like that, but that needs a lot
 more work.
Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c
could be done without a context, as well as what mesa's compute_version
then does with it.
And yes you'd still need to clamp it to whatever the state tracker
actually supports (which is ugly since you can build mesa with non-gl
state trackers so querying the drivers that way ultimately makes not
much sense).
I'm not really against a gl version cap bit cause it looks like it would
be a pain otherwise, just pointing out that fundamentally this is really
a bit of a hack.

Roland


 Marek
 
 On Sat, Feb 22, 2014 at 10:46 PM, Roland Scheidegger
 srol...@vmware.com wrote:
 
 
 - Original Message -
 From: Emil Velikov emil.l.veli...@gmail.com To: Roland
 Scheidegger srol...@vmware.com,
 mesa-dev@lists.freedesktop.org Cc: emil l velikov
 emil.l.veli...@gmail.com Sent: Saturday, February 22, 2014
 2:02:08 PM Subject: Re: [Mesa-dev] [PATCH 13/25] gallium:
 Introduce max_gl*version pipe-caps
 
 On 22/02/14 12:02, Roland Scheidegger wrote:
 Am 22.02.2014 04:04, schrieb Emil Velikov:
 According to the GLX_MESA_query_renderer spec each driver
 should be able to report the version of each GL api they
 support before creating a context.
 
 Currently both classic mesa and gallium evaluate the version
 post context creation and while the classic drivers set the
 max_gl*version according to their capabilities, gallium uses
 fixed values which are not the best approach due to driver
 differences.
 
 Add pipe-caps so that each driver can provide their
 individual capabilites.
 
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- 
 src/gallium/docs/source/screen.rst   | 8 +++- 
 src/gallium/include/pipe/p_defines.h | 6 +- 2 files
 changed, 12 insertions(+), 2 deletions(-)
 
 diff --git a/src/gallium/docs/source/screen.rst 
 b/src/gallium/docs/source/screen.rst index bd553f4..7b72133
 100644 --- a/src/gallium/docs/source/screen.rst +++
 b/src/gallium/docs/source/screen.rst @@ -169,7 +169,7 @@ The
 integer capabilities: since they are linked) a driver can
 support. Returning 0 is equivalent to returning 1 because
 every driver has to support at least a single 
 viewport/scissor combination. -* ''PIPE_CAP_ENDIANNESS``::
 The endianness of the device.  Either +*
 ``PIPE_CAP_ENDIANNESS``:: The endianness of the device.
 Either PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE. *
 ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed
 to have different sizes for fb color/zs attachments. This
 controls whether @@ -182,6 +182,12 @@ The integer
 capabilities: vertex components output by a single invocation
 of a geometry shader. This is the product of the number of
 attribute components per vertex and the number of output
 vertices. +* ``PIPE_CAP_MAX_GL_CORE_VERSION``: The maximum
 OpenGL (Core profile) version +  supported. +*
 ``PIPE_CAP_MAX_GL_COMPAT_VERSION``: The maximum OpenGL
 (Compatibility profile) +  version supported. +*
 ``PIPE_CAP_MAX_GL_ES1_VERSION``: The maximum OpenGL ES1
 version supported. +* ``PIPE_CAP_MAX_GL_ES2_VERSION``: The
 maximum OpenGL ES2 version supported.
 
 
 .. _pipe_capf: diff --git
 a/src/gallium/include/pipe/p_defines.h 
 b/src/gallium/include/pipe/p_defines.h index 83815cd..5c27f9c
 100644 --- a/src/gallium/include/pipe/p_defines.h +++
 b/src/gallium/include/pipe/p_defines.h @@ -522,7 +522,11 @@
 enum pipe_cap { PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86, 
 PIPE_CAP_TGSI_VS_LAYER = 87, 
 PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES = 88, -
 PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89 +
 PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89, +
 PIPE_CAP_MAX_GL_CORE_VERSION = 90, +
 PIPE_CAP_MAX_GL_COMPAT_VERSION = 91, +
 PIPE_CAP_MAX_GL_ES1_VERSION = 92, +
 PIPE_CAP_MAX_GL_ES2_VERSION = 93, };
 
 #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 
 0)
 
 
 Hmm do you really need all these different cap bits? Generally,
 the difference between ES/CORE/COMPAT contexts isn't hw related
 at all, and thus not really (gallium) driver related. So,
 obviously, every driver can do ES11 for instance, it should be
 impossible to write a gallium driver which can't. Similarly, I
 don't think core/compat needs a different query

Re: [Mesa-dev] [PATCH 21/25] gallium/r300/r600/radeonsi: handle query_renderer caps

The GTT size shouldn't be reported. I think it's 1 GB on r600 and
later. It's not really important to know that, because the memory is
quite slow.

Marek

On Sat, Feb 22, 2014 at 4:04 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/drivers/r300/r300_screen.c | 12 
  src/gallium/drivers/r600/r600_pipe.c   | 12 
  src/gallium/drivers/radeonsi/si_pipe.c | 12 
  3 files changed, 36 insertions(+)

 diff --git a/src/gallium/drivers/r300/r300_screen.c 
 b/src/gallium/drivers/r300/r300_screen.c
 index 6be922e..bc0aa37 100644
 --- a/src/gallium/drivers/r300/r300_screen.c
 +++ b/src/gallium/drivers/r300/r300_screen.c
 @@ -205,6 +205,18 @@ static int r300_get_param(struct pipe_screen* pscreen, 
 enum pipe_cap param)
  return 11;
  case PIPE_CAP_MAX_GL_ES2_VERSION:
  return 20;
 +
 +case PIPE_CAP_VENDOR_ID:
 +return 0x1002;
 +case PIPE_CAP_DEVICE_ID:
 +return r300screen-info.pci_id;
 +case PIPE_CAP_ACCELERATED:
 +return 1;
 +case PIPE_CAP_VIDEO_MEMORY:
 +/* XXX: Do we want to return vram_size or gart_size ? */
 +return r300screen-info.vram_size  20;
 +case PIPE_CAP_UMA:
 +return 0;
  }
  return 0;
  }
 diff --git a/src/gallium/drivers/r600/r600_pipe.c 
 b/src/gallium/drivers/r600/r600_pipe.c
 index 02914b9..274877d 100644
 --- a/src/gallium/drivers/r600/r600_pipe.c
 +++ b/src/gallium/drivers/r600/r600_pipe.c
 @@ -462,6 +462,18 @@ static int r600_get_param(struct pipe_screen* pscreen, 
 enum pipe_cap param)
 return 11;
 case PIPE_CAP_MAX_GL_ES2_VERSION:
 return 30;
 +
 +   case PIPE_CAP_VENDOR_ID:
 +   return 0x1002;
 +   case PIPE_CAP_DEVICE_ID:
 +   return rscreen-b.info.pci_id;
 +   case PIPE_CAP_ACCELERATED:
 +   return 1;
 +   case PIPE_CAP_VIDEO_MEMORY:
 +   /* XXX: Do we want to return vram_size or gart_size ? */
 +   return rscreen-b.info.vram_size  20;
 +   case PIPE_CAP_UMA:
 +   return 0;
 }
 return 0;
  }
 diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
 b/src/gallium/drivers/radeonsi/si_pipe.c
 index 4e6478c..adbc981 100644
 --- a/src/gallium/drivers/radeonsi/si_pipe.c
 +++ b/src/gallium/drivers/radeonsi/si_pipe.c
 @@ -341,6 +341,18 @@ static int si_get_param(struct pipe_screen* pscreen, 
 enum pipe_cap param)
 return 11;
 case PIPE_CAP_MAX_GL_ES2_VERSION:
 return 30;
 +
 +   case PIPE_CAP_VENDOR_ID:
 +   return 0x1002;
 +   case PIPE_CAP_DEVICE_ID:
 +   return sscreen-b.info.pci_id;
 +   case PIPE_CAP_ACCELERATED:
 +   return 1;
 +   case PIPE_CAP_VIDEO_MEMORY:
 +   /* XXX: Do we want to return vram_size or gart_size ? */
 +   return sscreen-b.info.vram_size  20;
 +   case PIPE_CAP_UMA:
 +   return 0;
 }
 return 0;
  }
 --
 1.9.0

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

On Mon, Feb 24, 2014 at 9:43 PM, Roland Scheidegger srol...@vmware.com wrote:
 Am 24.02.2014 21:23, schrieb Marek Olšák:
 Roland,

 The version CAPs that Emil wants to add have very little to do with
 which features a driver supports. The versions cannot be derived
 from other CAPs, instead, it should match what you get after you
 create an OpenGL context. For example, if your driver can do GL 4.0,
 the driver cannot report that it can do 4.0. Instead, it should say
 it can do 3.3, because that's what core Mesa can do. The only purpose
 of these new version CAPs is to match what core Mesa does without
 asking core Mesa. It's ugly, but it's the least invasive solution.

 Of course, it can actually be done cleanly, e.g. making both
 main/version.c and st_extensions.c independent of gl_context and
 only using a DRI screen or something like that, but that needs a lot
 more work.
 Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c
 could be done without a context, as well as what mesa's compute_version
 then does with it.
 And yes you'd still need to clamp it to whatever the state tracker
 actually supports (which is ugly since you can build mesa with non-gl
 state trackers so querying the drivers that way ultimately makes not
 much sense).

I don't think the clamping would be needed. st_extensions.c contains
all that is needed for compute_version and compute_version can return
the supported version based on an enum gl_api parameter and that's
it. We could also remove the gl_extensions and gl_constants structures
from gl_context and put them in the DRI screen. Later when the first
context is created, we don't need to determine the version, extensions
and constants again.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

On 24/02/14 20:43, Roland Scheidegger wrote:
 Am 24.02.2014 21:23, schrieb Marek Olšák:
 Roland,

 The version CAPs that Emil wants to add have very little to do with 
 which features a driver supports. The versions cannot be derived
 from other CAPs, instead, it should match what you get after you
 create an OpenGL context. For example, if your driver can do GL 4.0,
 the driver cannot report that it can do 4.0. Instead, it should say
 it can do 3.3, because that's what core Mesa can do. The only purpose
 of these new version CAPs is to match what core Mesa does without
 asking core Mesa. It's ugly, but it's the least invasive solution.

 Of course, it can actually be done cleanly, e.g. making both 
 main/version.c and st_extensions.c independent of gl_context and
 only using a DRI screen or something like that, but that needs a lot
 more work.
 Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c
 could be done without a context, as well as what mesa's compute_version
 then does with it.
 And yes you'd still need to clamp it to whatever the state tracker
 actually supports (which is ugly since you can build mesa with non-gl
 state trackers so querying the drivers that way ultimately makes not
 much sense).
 I'm not really against a gl version cap bit cause it looks like it would
 be a pain otherwise, just pointing out that fundamentally this is really
 a bit of a hack.
 
It's not just a bit it's a decent sized one, but my main concern is
that doing that alone will result in a delta exceeding this whole series
by a magnitude of two if not more.

That would require some time which I can not spare in the next few weeks.

FWIW the intel guys landed support for the extension in mesa 10.0, and
it would be nice if everyone else can have it in time for 10.2.

-Emil
 Roland
 
 
 Marek

 On Sat, Feb 22, 2014 at 10:46 PM, Roland Scheidegger
 srol...@vmware.com wrote:


 - Original Message -
 From: Emil Velikov emil.l.veli...@gmail.com To: Roland
 Scheidegger srol...@vmware.com,
 mesa-dev@lists.freedesktop.org Cc: emil l velikov
 emil.l.veli...@gmail.com Sent: Saturday, February 22, 2014
 2:02:08 PM Subject: Re: [Mesa-dev] [PATCH 13/25] gallium:
 Introduce max_gl*version pipe-caps

 On 22/02/14 12:02, Roland Scheidegger wrote:
 Am 22.02.2014 04:04, schrieb Emil Velikov:
 According to the GLX_MESA_query_renderer spec each driver
 should be able to report the version of each GL api they
 support before creating a context.

 Currently both classic mesa and gallium evaluate the version
 post context creation and while the classic drivers set the
 max_gl*version according to their capabilities, gallium uses
 fixed values which are not the best approach due to driver
 differences.

 Add pipe-caps so that each driver can provide their
 individual capabilites.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- 
 src/gallium/docs/source/screen.rst   | 8 +++- 
 src/gallium/include/pipe/p_defines.h | 6 +- 2 files
 changed, 12 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/docs/source/screen.rst 
 b/src/gallium/docs/source/screen.rst index bd553f4..7b72133
 100644 --- a/src/gallium/docs/source/screen.rst +++
 b/src/gallium/docs/source/screen.rst @@ -169,7 +169,7 @@ The
 integer capabilities: since they are linked) a driver can
 support. Returning 0 is equivalent to returning 1 because
 every driver has to support at least a single 
 viewport/scissor combination. -* ''PIPE_CAP_ENDIANNESS``::
 The endianness of the device.  Either +*
 ``PIPE_CAP_ENDIANNESS``:: The endianness of the device.
 Either PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE. *
 ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed
 to have different sizes for fb color/zs attachments. This
 controls whether @@ -182,6 +182,12 @@ The integer
 capabilities: vertex components output by a single invocation
 of a geometry shader. This is the product of the number of
 attribute components per vertex and the number of output
 vertices. +* ``PIPE_CAP_MAX_GL_CORE_VERSION``: The maximum
 OpenGL (Core profile) version +  supported. +*
 ``PIPE_CAP_MAX_GL_COMPAT_VERSION``: The maximum OpenGL
 (Compatibility profile) +  version supported. +*
 ``PIPE_CAP_MAX_GL_ES1_VERSION``: The maximum OpenGL ES1
 version supported. +* ``PIPE_CAP_MAX_GL_ES2_VERSION``: The
 maximum OpenGL ES2 version supported.


 .. _pipe_capf: diff --git
 a/src/gallium/include/pipe/p_defines.h 
 b/src/gallium/include/pipe/p_defines.h index 83815cd..5c27f9c
 100644 --- a/src/gallium/include/pipe/p_defines.h +++
 b/src/gallium/include/pipe/p_defines.h @@ -522,7 +522,11 @@
 enum pipe_cap { PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86, 
 PIPE_CAP_TGSI_VS_LAYER = 87, 
 PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES = 88, -
 PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89 +
 PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89, +
 PIPE_CAP_MAX_GL_CORE_VERSION = 90, +
 PIPE_CAP_MAX_GL_COMPAT_VERSION = 91, +
 PIPE_CAP_MAX_GL_ES1_VERSION = 92, +
 PIPE_CAP_MAX_GL_ES2_VERSION = 93,

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

Am 24.02.2014 21:54, schrieb Marek Olšák:
 On Mon, Feb 24, 2014 at 9:43 PM, Roland Scheidegger srol...@vmware.com 
 wrote:
 Am 24.02.2014 21:23, schrieb Marek Olšák:
 Roland,

 The version CAPs that Emil wants to add have very little to do with
 which features a driver supports. The versions cannot be derived
 from other CAPs, instead, it should match what you get after you
 create an OpenGL context. For example, if your driver can do GL 4.0,
 the driver cannot report that it can do 4.0. Instead, it should say
 it can do 3.3, because that's what core Mesa can do. The only purpose
 of these new version CAPs is to match what core Mesa does without
 asking core Mesa. It's ugly, but it's the least invasive solution.

 Of course, it can actually be done cleanly, e.g. making both
 main/version.c and st_extensions.c independent of gl_context and
 only using a DRI screen or something like that, but that needs a lot
 more work.
 Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c
 could be done without a context, as well as what mesa's compute_version
 then does with it.
 And yes you'd still need to clamp it to whatever the state tracker
 actually supports (which is ugly since you can build mesa with non-gl
 state trackers so querying the drivers that way ultimately makes not
 much sense).
 
 I don't think the clamping would be needed. st_extensions.c contains
 all that is needed for compute_version and compute_version can return
 the supported version based on an enum gl_api parameter and that's
 it. We could also remove the gl_extensions and gl_constants structures
 from gl_context and put them in the DRI screen. Later when the first
 context is created, we don't need to determine the version, extensions
 and constants again.

Yes you are right, since the state tracker doesn't ask for things needed
in GL versions core mesa can't do (and compute_version wouldn't look at
them anyway) no clamping should be needed (only the restriction of
compat contexts to 3.0 max - which is a restriction coming from both the
state tracker and core mesa, but NOT the drivers).
But it would be a fair bit of work (if you wanted to do that including
the compute_version stuff from core mesa you'd need to change classic
drivers too), so I'd be happy enough for now if there are only the
necessary version cap bits, not those which are easily determined
otherwise (core/compat, es1) - ultimately they should probably disappear
again imho.

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600g/compute: PIPE_CAP_COMPUTE should be false for pre-evergreen GPUs

2014-02-24 Thread Tom Stellard

This prevents clover from using unsupported devices.
---
 src/gallium/drivers/r600/r600_pipe.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 0f75a53..157d560 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -348,7 +348,6 @@ static int r600_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_USER_INDEX_BUFFERS:
case PIPE_CAP_USER_CONSTANT_BUFFERS:
-   case PIPE_CAP_COMPUTE:
case PIPE_CAP_START_INSTANCE:
case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
@@ -357,6 +356,9 @@ static int r600_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_TEXTURE_MULTISAMPLE:
return 1;
 
+   case PIPE_CAP_COMPUTE:
+   return rscreen-b.chip_class  R700;
+
case PIPE_CAP_TGSI_TEXCOORD:
return 0;
 
-- 
1.8.1.4


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g/compute: PIPE_CAP_COMPUTE should be false for pre-evergreen GPUs

Reviewed-by: Marek Olšák marek.ol...@amd.com

Marek

On Mon, Feb 24, 2014 at 10:53 PM, Tom Stellard thomas.stell...@amd.com wrote:
 This prevents clover from using unsupported devices.
 ---
  src/gallium/drivers/r600/r600_pipe.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/src/gallium/drivers/r600/r600_pipe.c 
 b/src/gallium/drivers/r600/r600_pipe.c
 index 0f75a53..157d560 100644
 --- a/src/gallium/drivers/r600/r600_pipe.c
 +++ b/src/gallium/drivers/r600/r600_pipe.c
 @@ -348,7 +348,6 @@ static int r600_get_param(struct pipe_screen* pscreen, 
 enum pipe_cap param)
 case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
 case PIPE_CAP_USER_INDEX_BUFFERS:
 case PIPE_CAP_USER_CONSTANT_BUFFERS:
 -   case PIPE_CAP_COMPUTE:
 case PIPE_CAP_START_INSTANCE:
 case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
 case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
 @@ -357,6 +356,9 @@ static int r600_get_param(struct pipe_screen* pscreen, 
 enum pipe_cap param)
 case PIPE_CAP_TEXTURE_MULTISAMPLE:
 return 1;

 +   case PIPE_CAP_COMPUTE:
 +   return rscreen-b.chip_class  R700;
 +
 case PIPE_CAP_TGSI_TEXCOORD:
 return 0;

 --
 1.8.1.4


 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Add GPU BLIT of texture image to PBO in Intel driver

2014-02-24 Thread Jon Ashburn

Add Intel driver hook for glGetTexImage to accelerate the case of reading
texture image into a PBO.  This case gets huge performance gains by using
GPU BLIT directly to PBO rather than GPU BLIT to temporary texture followed
by memcpy.

No regressions on Piglit tests  with Intel driver.
---
 src/mesa/drivers/dri/i965/intel_tex_image.c | 111 
 1 file changed, 111 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index ee02e68..66a024b 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -15,6 +15,8 @@
 #include main/teximage.h
 #include main/texstore.h
 
+#include drivers/common/meta.h
+
 #include intel_mipmap_tree.h
 #include intel_buffer_objects.h
 #include intel_batchbuffer.h
@@ -415,10 +417,119 @@ intel_image_target_texture_2d(struct gl_context *ctx, 
GLenum target,
   image-tile_x, image-tile_y);
 }
 
+static bool
+IntelBlitTexToPbo(struct gl_context * ctx,
+   GLenum format, GLenum type,
+   GLvoid * pixels, struct gl_texture_image *texImage)
+{
+   struct intel_texture_image *intelImage = intel_texture_image(texImage);
+   struct brw_context *brw = brw_context(ctx);
+   const struct gl_pixelstore_attrib *pack = (ctx-Pack);
+   struct intel_buffer_object *dst = intel_buffer_object(pack-BufferObj);
+   GLuint dst_offset;
+   drm_intel_bo *dst_buffer;
+   GLenum target = texImage-TexObject-Target;
+
+   DBG(%s\n, __FUNCTION__);
+
+   /*
+* Check if we can use GPU blit to copy from the hardware texture
+* format to the user's format/type.
+* Note that GL's pixel transfer ops don't apply to glGetTexImage()
+*/
+
+   if (!_mesa_format_matches_format_and_type(
+   intelImage-mt-format, format, type, false) ||
+ (_mesa_is_format_compressed(texImage-TexFormat) 
+  _mesa_get_format_datatype(texImage-TexFormat) == 
GL_UNSIGNED_NORMALIZED)) {
+  DBG(%s - bad format for blit to PBO\n, __FUNCTION__);
+  return false;
+   }
+
+   if (ctx-_ImageTransferState) {
+  DBG(%s - bad transfer state for blit to PBO\n, __FUNCTION__);
+  return false;
+   }
+
+   if (pack-SkipPixels  || pack-SkipRows) {
+  DBG(%s - bad skip params for blit to PBO\n, __FUNCTION__);
+  return false;
+   }
+
+   if (pack-SwapBytes || pack-LsbFirst) {
+  DBG(%s: bad packing params\n, __FUNCTION__);
+  return false;
+   }
+
+   if (target == GL_TEXTURE_1D_ARRAY || target == GL_TEXTURE_CUBE_MAP_ARRAY ||
+   target == GL_TEXTURE_2D_ARRAY) {
+  DBG(%s: no support for array textures\n, __FUNCTION__);
+  return false;
+   }
+
+   int dst_stride = _mesa_image_row_stride(pack, texImage-Width, format, 
type);
+   bool dst_flip = false;
+   /* Mesa flips the dst_stride for ctx-Pack.Invert, our mt must have a
+* normal dst_stride.
+*/
+   struct gl_pixelstore_attrib uninverted_pack = *pack;
+   if (ctx-Pack.Invert) {
+  dst_stride = -dst_stride;
+  dst_flip = true;
+  uninverted_pack.Invert = false;
+   }
+   dst_offset = (GLintptr) pixels;
+   dst_offset += _mesa_image_offset(2, uninverted_pack, texImage-Width,
+texImage-Height, format, type, 0, 0, 0);
+   dst_buffer = intel_bufferobj_buffer(brw, dst, dst_offset,
+   texImage-Height * dst_stride);
+
+   struct intel_mipmap_tree *pbo_mt =
+intel_miptree_create_for_bo(brw,
+dst_buffer,
+intelImage-mt-format,
+dst_offset,
+texImage-Width, texImage-Height,
+dst_stride, I915_TILING_NONE);
+
+   if (!intel_miptree_blit(brw,
+   intelImage-mt, texImage-Level, texImage-Face,
+   0, 0, false,
+   pbo_mt, 0, 0,
+   0, 0, dst_flip,
+   texImage-Width, texImage-Height, GL_COPY))
+  return false;
+
+   intel_miptree_release(pbo_mt);
+
+   DBG(%s - DONE\n, __FUNCTION__);
+
+   return true;
+}
+
+static void
+intel_get_tex_image(struct gl_context *ctx,
+   GLenum format, GLenum type, GLvoid *pixels,
+   struct gl_texture_image *texImage) {
+   struct brw_context *brw = brw_context(ctx);
+   DBG(%s\n, __FUNCTION__);
+
+   if (_mesa_is_bufferobj(ctx-Pack.BufferObj)) {
+  /* Using PBOs, so try the BLT based path. */
+  if (IntelBlitTexToPbo(ctx, format, type, pixels, texImage))
+ return;
+
+  perf_debug(%s: fallback to CPU mapping in PBO case\n, __FUNCTION__);
+   }
+
+   _mesa_meta_GetTexImage(ctx, format, type, pixels, texImage);
+}
+
 void
 intelInitTextureImageFuncs(struct dd_function_table *functions)
 {
functions-TexImage = intelTexImage;

[Mesa-dev] [PATCH 1/3] glsl: Optimize lrp(0, y, a) into y * a.

Helps two programs in shader-db:

instructions in affected programs: 254 - 234 (-7.87%)
---
 src/glsl/opt_algebraic.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 1b4d319..28f95a4 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -568,6 +568,8 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
  return ir-operands[1];
   } else if (ir-operands[0]-equals(ir-operands[1])) {
  return ir-operands[0];
+  } else if (is_vec_zero(op_const[0])) {
+ return mul(ir-operands[1], ir-operands[2]);
   }
   break;
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] glsl: Optimize lrp(x, 0, a) into x - (x * a).

Helps one program in shader-db:

instructions in affected programs: 96 - 92 (-4.17%)
---
 src/glsl/opt_algebraic.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 28f95a4..778638c 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -570,6 +570,8 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
  return ir-operands[0];
   } else if (is_vec_zero(op_const[0])) {
  return mul(ir-operands[1], ir-operands[2]);
+  } else if (is_vec_zero(op_const[1])) {
+ return add(ir-operands[0], neg(mul(ir-operands[0], 
ir-operands[2])));
   }
   break;
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] glsl: Optimize division by two with a right shift.

---
 src/glsl/opt_algebraic.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 778638c..50342ac 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -421,6 +421,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   }
   if (is_vec_one(op_const[1]))
 return ir-operands[0];
+  if (is_vec_two(op_const[1])  ir-type-is_integer()) {
+ return rshift(ir-operands[0], new(mem_ctx) ir_constant(1));
+  }
   break;
 
case ir_binop_dot:
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] configure: enable the drm pipe-loader for non swrast drivers

All hardware drivers including the virtual vmwgfx require
the drm pipe-loader in order to be properly loaded by xa,
gbm and opencl.

Note this does _not_ add support for the above three it only
allows the pipe driver to be loaded by the library.

Eg. GBM will now properly open the pipe-i915 driver, should
one be working on the such hardware.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75453
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 configure.ac | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index d98dca9..df648a1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1239,7 +1239,6 @@ if test x$enable_xa = xyes; then
 fi
 GALLIUM_STATE_TRACKERS_DIRS=xa $GALLIUM_STATE_TRACKERS_DIRS
 enable_gallium_loader=yes
-enable_gallium_drm_loader=yes
 fi
 AM_CONDITIONAL(HAVE_ST_XA, test x$enable_xa = xyes)
 
@@ -1734,11 +1733,13 @@ if test -n $with_gallium_drivers; then
 xsvga)
 HAVE_GALLIUM_SVGA=yes
 GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS svga softpipe
+gallium_require_drm_loader
 gallium_check_st svga/drm dri-vmwgfx 
 ;;
 xi915)
 HAVE_GALLIUM_I915=yes
 PKG_CHECK_MODULES([INTEL], [libdrm_intel = 
$LIBDRM_INTEL_REQUIRED])
+gallium_require_drm_loader
 GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS i915 softpipe
 if test x$MESA_LLVM = x1; then
 GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS llvmpipe
@@ -1758,6 +1759,7 @@ if test -n $with_gallium_drivers; then
 xr300)
 HAVE_GALLIUM_R300=yes
 PKG_CHECK_MODULES([RADEON], [libdrm_radeon = 
$LIBDRM_RADEON_REQUIRED])
+gallium_require_drm_loader
 gallium_require_llvm Gallium R300
 GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS r300
 gallium_check_st radeon/drm r300/dri   
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] configure: avoid setting variables as empty strings

Recent patch converted our logic to use test -n and test -z.
An emptry string variable (empty_str=) return true for both
thus making the check unreliable.

Fix this by correctly setting the variable when applicable.

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 configure.ac | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index dfed7f8..6db3c1d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1308,7 +1308,7 @@ AC_ARG_WITH([libclc-path],
[AS_HELP_STRING([--with-libclc-path],
  [DEPRECATED: See 
http://dri.freedesktop.org/wiki/GalliumCompute#How_to_Install])],
[LIBCLC_PATH=$withval],
-   [LIBCLC_PATH=])
+   [LIBCLC_PATH=''])
 
 if test -n $LIBCLC_PATH; then
AC_MSG_ERROR([The --with-libclc-path option has been deprecated.
@@ -1321,7 +1321,7 @@ AC_ARG_WITH([clang-libdir],
[AS_HELP_STRING([--with-clang-libdir],
  [Path to Clang libraries @:@default=llvm-config --libdir@:@])],
[CLANG_LIBDIR=$withval],
-   [CLANG_LIBDIR=])
+   [CLANG_LIBDIR=''])
 
 PKG_CHECK_EXISTS([libclc], [have_libclc=yes], [have_libclc=no])
 
@@ -1513,7 +1513,7 @@ AC_ARG_WITH([llvm-prefix],
 [AS_HELP_STRING([--with-llvm-prefix],
 [Prefix for LLVM installations in non-standard locations])],
 [llvm_prefix=$withval],
-[llvm_prefix=])
+[llvm_prefix=''])
 
 
 # Call this inside ` ` to get the return value.
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] configure: error out when building xa only with swrast

Building to provide accelration using swrast does not make
sense.

Note: update your build script to explicitly mention svga
in the gallium drivers list, if you are building the vmwgfx
xa library.

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 configure.ac | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure.ac b/configure.ac
index 6db3c1d..d98dca9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1234,6 +1234,9 @@ dnl
 dnl XA configuration
 dnl
 if test x$enable_xa = xyes; then
+if test x$gallium_drivers = xswrast; then
+   AC_MSG_ERROR([Building xa requires at least one non swrast gallium 
driver])
+fi
 GALLIUM_STATE_TRACKERS_DIRS=xa $GALLIUM_STATE_TRACKERS_DIRS
 enable_gallium_loader=yes
 enable_gallium_drm_loader=yes
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] configure: avoid constantly building megadrivers 'core'

The issue is caused by a thinko that an empty string will be
considered of zero length by 'test'. This is not the case,
thus we were building the 'core' of megadrivers even when no
classic drivers were built.

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 configure.ac | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 24ffc54..dfed7f8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -960,6 +960,9 @@ if test x$with_dri_drivers = xauto; then
 with_dri_drivers=no
 fi
 fi
+if test x$with_dri_drivers = xno; then
+with_dri_drivers=''
+fi
 
 dnl If $with_dri_drivers is yes, drivers will be added through
 dnl platform checks. Set DEFINES and LIB_DEPS
@@ -1038,9 +1041,9 @@ fi
 AC_SUBST([DRI_LIB_DEPS])
 AC_SUBST([GALLIUM_DRI_LIB_DEPS])
 
-DRI_DIRS=
-dnl Duplicates in DRI_DIRS are removed by sorting it after this block
-if test x$with_dri_drivers != xno; then
+DRI_DIRS=''
+dnl Duplicates in DRI_DIRS are removed by sorting it at the end of this block
+if test -n $with_dri_drivers; then
 if test x$enable_opengl != xyes; then
 AC_MSG_ERROR([--with-dri-drivers requires OpenGL])
 fi
@@ -1077,8 +1080,8 @@ if test x$with_dri_drivers != xno; then
 ;;
 esac
 done
+DRI_DIRS=`echo $DRI_DIRS|tr   \n|sort -u|tr \n  `
 fi
-DRI_DIRS=`echo $DRI_DIRS|tr   \n|sort -u|tr \n  `
 
 AM_CONDITIONAL(NEED_MEGADRIVER, test -n $DRI_DIRS)
 AM_CONDITIONAL(NEED_LIBMESA, test x$enable_xlib_glx = xyes -o \
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glsl: Optimize lrp(0, y, a) into y * a.


Series is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

Though we'll eventually want to generalize patch 3.

On 02/24/2014 03:00 PM, Matt Turner wrote:

Helps two programs in shader-db:

instructions in affected programs: 254 - 234 (-7.87%)
---
  src/glsl/opt_algebraic.cpp | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 1b4d319..28f95a4 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -568,6 +568,8 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   return ir-operands[1];
} else if (ir-operands[0]-equals(ir-operands[1])) {
   return ir-operands[0];
+  } else if (is_vec_zero(op_const[0])) {
+ return mul(ir-operands[1], ir-operands[2]);
}
break;




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] glsl: Optimize division by two with a right shift.

Am 25.02.2014 00:00, schrieb Matt Turner:
 ---
  src/glsl/opt_algebraic.cpp | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
 index 778638c..50342ac 100644
 --- a/src/glsl/opt_algebraic.cpp
 +++ b/src/glsl/opt_algebraic.cpp
 @@ -421,6 +421,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
}
if (is_vec_one(op_const[1]))
return ir-operands[0];
 +  if (is_vec_two(op_const[1])  ir-type-is_integer()) {
 + return rshift(ir-operands[0], new(mem_ctx) ir_constant(1));
 +  }
break;
  
 case ir_binop_dot:
 

Does glsl require any particular rounding behavior for negative numbers
(like c99 does, which wouldn't work with shift emulation)? A quick look
didn't find anything but it might be implied somewhere...

Also, if you do this for two, wouldn't it make sense to extend that to
power-of-two numbers or is that too much cpu work?

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] glsl: Optimize division by two with a right shift.


On 02/24/2014 03:36 PM, Roland Scheidegger wrote:

Am 25.02.2014 00:00, schrieb Matt Turner:

---
  src/glsl/opt_algebraic.cpp | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 778638c..50342ac 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -421,6 +421,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
}
if (is_vec_one(op_const[1]))
 return ir-operands[0];
+  if (is_vec_two(op_const[1])  ir-type-is_integer()) {
+ return rshift(ir-operands[0], new(mem_ctx) ir_constant(1));
+  }
break;

 case ir_binop_dot:



Does glsl require any particular rounding behavior for negative numbers
(like c99 does, which wouldn't work with shift emulation)? A quick look
didn't find anything but it might be implied somewhere...


What is a case by C99 rules where x / 2 is not the same as x  2?


Also, if you do this for two, wouldn't it make sense to extend that to
power-of-two numbers or is that too much cpu work?


I think it was more a case that shader-db didn't have any occurances, 
and he didn't feel like doing the human work. :)



Roland
___
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 3/3] glsl: Optimize division by two with a right shift.

On Mon, Feb 24, 2014 at 3:36 PM, Roland Scheidegger srol...@vmware.com wrote:
 Am 25.02.2014 00:00, schrieb Matt Turner:
 ---
  src/glsl/opt_algebraic.cpp | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
 index 778638c..50342ac 100644
 --- a/src/glsl/opt_algebraic.cpp
 +++ b/src/glsl/opt_algebraic.cpp
 @@ -421,6 +421,9 @@ ir_algebraic_visitor::handle_expression(ir_expression 
 *ir)
}
if (is_vec_one(op_const[1]))
return ir-operands[0];
 +  if (is_vec_two(op_const[1])  ir-type-is_integer()) {
 + return rshift(ir-operands[0], new(mem_ctx) ir_constant(1));
 +  }
break;

 case ir_binop_dot:


 Does glsl require any particular rounding behavior for negative numbers
 (like c99 does, which wouldn't work with shift emulation)? A quick look
 didn't find anything but it might be implied somewhere...

Hm. I'll have to do some spec searching.

 Also, if you do this for two, wouldn't it make sense to extend that to
 power-of-two numbers or is that too much cpu work?

There's not a direct way to check if the operand is a power of two
without some additional infrastructure, so I punted for now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/7] r300g, uvd, vce: set priorities for relocations

From: Marek Olšák marek.ol...@amd.com

This updates all occurences of cs_add_reloc.
---
 src/gallium/drivers/r300/r300_emit.c  | 27 +++
 src/gallium/drivers/radeon/r600_cs.h  |  3 ++-
 src/gallium/drivers/radeon/radeon_uvd.c   |  3 ++-
 src/gallium/drivers/radeon/radeon_vce.h   |  2 +-
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c |  8 +---
 src/gallium/winsys/radeon/drm/radeon_winsys.h |  4 ++--
 6 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_emit.c 
b/src/gallium/drivers/r300/r300_emit.c
index b038a97..d99b919 100644
--- a/src/gallium/drivers/r300/r300_emit.c
+++ b/src/gallium/drivers/r300/r300_emit.c
@@ -1314,7 +1314,10 @@ validate:
 assert(tex  tex-buf  cbuf is marked, but NULL!);
 r300-rws-cs_add_reloc(r300-cs, tex-cs_buf,
 RADEON_USAGE_READWRITE,
-r300_surface(fb-cbufs[i])-domain);
+r300_surface(fb-cbufs[i])-domain,
+tex-b.b.nr_samples  1 ?
+RADEON_PRIO_COLOR_BUFFER_MSAA :
+RADEON_PRIO_COLOR_BUFFER);
 }
 /* ...depth buffer... */
 if (fb-zsbuf) {
@@ -1322,7 +1325,10 @@ validate:
 assert(tex  tex-buf  zsbuf is marked, but NULL!);
 r300-rws-cs_add_reloc(r300-cs, tex-cs_buf,
 RADEON_USAGE_READWRITE,
-r300_surface(fb-zsbuf)-domain);
+r300_surface(fb-zsbuf)-domain,
+tex-b.b.nr_samples  1 ?
+RADEON_PRIO_DEPTH_BUFFER_MSAA :
+RADEON_PRIO_DEPTH_BUFFER);
 }
 }
 /* The AA resolve buffer. */
@@ -1330,7 +1336,8 @@ validate:
 if (aa-dest) {
 r300-rws-cs_add_reloc(r300-cs, aa-dest-cs_buf,
 RADEON_USAGE_WRITE,
-aa-dest-domain);
+aa-dest-domain,
+RADEON_PRIO_COLOR_BUFFER);
 }
 }
 if (r300-textures_state.dirty) {
@@ -1342,17 +1349,19 @@ validate:
 
 tex = r300_resource(texstate-sampler_views[i]-base.texture);
 r300-rws-cs_add_reloc(r300-cs, tex-cs_buf, RADEON_USAGE_READ,
-tex-domain);
+tex-domain, 
RADEON_PRIO_SHADER_TEXTURE_RO);
 }
 }
 /* ...occlusion query buffer... */
 if (r300-query_current)
 r300-rws-cs_add_reloc(r300-cs, r300-query_current-cs_buf,
-RADEON_USAGE_WRITE, RADEON_DOMAIN_GTT);
+RADEON_USAGE_WRITE, RADEON_DOMAIN_GTT,
+RADEON_PRIO_MIN);
 /* ...vertex buffer for SWTCL path... */
 if (r300-vbo_cs)
 r300-rws-cs_add_reloc(r300-cs, r300-vbo_cs,
-RADEON_USAGE_READ, RADEON_DOMAIN_GTT);
+RADEON_USAGE_READ, RADEON_DOMAIN_GTT,
+RADEON_PRIO_MIN);
 /* ...vertex buffers for HWTCL path... */
 if (do_validate_vertex_buffers  r300-vertex_arrays_dirty) {
 struct pipe_vertex_buffer *vbuf = r300-vertex_buffer;
@@ -1367,14 +1376,16 @@ validate:
 
 r300-rws-cs_add_reloc(r300-cs, r300_resource(buf)-cs_buf,
 RADEON_USAGE_READ,
-r300_resource(buf)-domain);
+r300_resource(buf)-domain,
+RADEON_PRIO_SHADER_BUFFER_RO);
 }
 }
 /* ...and index buffer for HWTCL path. */
 if (index_buffer)
 r300-rws-cs_add_reloc(r300-cs, r300_resource(index_buffer)-cs_buf,
 RADEON_USAGE_READ,
-r300_resource(index_buffer)-domain);
+r300_resource(index_buffer)-domain,
+RADEON_PRIO_MIN);
 
 /* Now do the validation (flush is called inside cs_validate on failure). 
*/
 if (!r300-rws-cs_validate(r300-cs)) {
diff --git a/src/gallium/drivers/radeon/r600_cs.h 
b/src/gallium/drivers/radeon/r600_cs.h
index c3af3de..45dc76c 100644
--- a/src/gallium/drivers/radeon/r600_cs.h
+++ b/src/gallium/drivers/radeon/r600_cs.h
@@ -63,7 +63,8 @@ static INLINE unsigned r600_context_bo_reloc(struct 
r600_common_context *rctx,
rctx-rings.gfx.flush(rctx, RADEON_FLUSH_ASYNC);
}
}
-   return rctx-ws-cs_add_reloc(ring-cs, rbo-cs_buf, usage, 
rbo-domains) * 4;
+   return rctx-ws-cs_add_reloc(ring-cs, rbo-cs_buf, usage,
+ rbo-domains, RADEON_PRIO_MIN) *

[Mesa-dev] [PATCH 4/7] r600g, radeonsi: add a bunch of useful queries for the HUD

From: Marek Olšák marek.ol...@amd.com

---
 src/gallium/drivers/radeon/r600_pipe_common.c |  6 -
 src/gallium/drivers/radeon/r600_pipe_common.h |  4 +++
 src/gallium/drivers/radeon/r600_query.c   | 32 +++
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c |  2 ++
 src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 26 +++---
 src/gallium/winsys/radeon/drm/radeon_drm_winsys.h |  1 +
 src/gallium/winsys/radeon/drm/radeon_winsys.h |  6 -
 7 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 3aa718d..21bddb6 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -429,7 +429,11 @@ static int r600_get_driver_query_info(struct pipe_screen 
*screen,
{draw-calls, R600_QUERY_DRAW_CALLS, 0},
{requested-VRAM, R600_QUERY_REQUESTED_VRAM, 
rscreen-info.vram_size, TRUE},
{requested-GTT, R600_QUERY_REQUESTED_GTT, 
rscreen-info.gart_size, TRUE},
-   {buffer-wait-time, R600_QUERY_BUFFER_WAIT_TIME, 0, FALSE}
+   {buffer-wait-time, R600_QUERY_BUFFER_WAIT_TIME, 0, FALSE},
+   {num-cs-flushes, R600_QUERY_NUM_CS_FLUSHES, 0, FALSE},
+   {num-bytes-moved, R600_QUERY_NUM_BYTES_MOVED, 0, TRUE},
+   {VRAM-usage, R600_QUERY_VRAM_USAGE, rscreen-info.vram_size, 
TRUE},
+   {GTT-usage, R600_QUERY_GTT_USAGE, rscreen-info.gart_size, 
TRUE},
};
 
if (!info)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index fc61af1..4d6232f 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -50,6 +50,10 @@
 #define R600_QUERY_REQUESTED_VRAM  (PIPE_QUERY_DRIVER_SPECIFIC + 1)
 #define R600_QUERY_REQUESTED_GTT   (PIPE_QUERY_DRIVER_SPECIFIC + 2)
 #define R600_QUERY_BUFFER_WAIT_TIME(PIPE_QUERY_DRIVER_SPECIFIC + 3)
+#define R600_QUERY_NUM_CS_FLUSHES  (PIPE_QUERY_DRIVER_SPECIFIC + 4)
+#define R600_QUERY_NUM_BYTES_MOVED (PIPE_QUERY_DRIVER_SPECIFIC + 5)
+#define R600_QUERY_VRAM_USAGE  (PIPE_QUERY_DRIVER_SPECIFIC + 6)
+#define R600_QUERY_GTT_USAGE   (PIPE_QUERY_DRIVER_SPECIFIC + 7)
 
 /* read caches */
 #define R600_CONTEXT_INV_VERTEX_CACHE  (1  0)
diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 915d37a..eb76ae9 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -79,6 +79,10 @@ static struct r600_resource *r600_new_query_buffer(struct 
r600_common_context *c
case R600_QUERY_REQUESTED_VRAM:
case R600_QUERY_REQUESTED_GTT:
case R600_QUERY_BUFFER_WAIT_TIME:
+   case R600_QUERY_NUM_CS_FLUSHES:
+   case R600_QUERY_NUM_BYTES_MOVED:
+   case R600_QUERY_VRAM_USAGE:
+   case R600_QUERY_GTT_USAGE:
return NULL;
}
 
@@ -374,6 +378,10 @@ static struct pipe_query *r600_create_query(struct 
pipe_context *ctx, unsigned q
case R600_QUERY_REQUESTED_VRAM:
case R600_QUERY_REQUESTED_GTT:
case R600_QUERY_BUFFER_WAIT_TIME:
+   case R600_QUERY_NUM_CS_FLUSHES:
+   case R600_QUERY_NUM_BYTES_MOVED:
+   case R600_QUERY_VRAM_USAGE:
+   case R600_QUERY_GTT_USAGE:
skip_allocation = true;
break;
default:
@@ -427,11 +435,19 @@ static void r600_begin_query(struct pipe_context *ctx, 
struct pipe_query *query)
return;
case R600_QUERY_REQUESTED_VRAM:
case R600_QUERY_REQUESTED_GTT:
+   case R600_QUERY_VRAM_USAGE:
+   case R600_QUERY_GTT_USAGE:
rquery-begin_result = 0;
return;
case R600_QUERY_BUFFER_WAIT_TIME:
rquery-begin_result = rctx-ws-query_value(rctx-ws, 
RADEON_BUFFER_WAIT_TIME_NS);
return;
+   case R600_QUERY_NUM_CS_FLUSHES:
+   rquery-begin_result = rctx-ws-query_value(rctx-ws, 
RADEON_NUM_CS_FLUSHES);
+   return;
+   case R600_QUERY_NUM_BYTES_MOVED:
+   rquery-begin_result = rctx-ws-query_value(rctx-ws, 
RADEON_NUM_BYTES_MOVED);
+   return;
}
 
/* Discard the old query buffers. */
@@ -478,6 +494,18 @@ static void r600_end_query(struct pipe_context *ctx, 
struct pipe_query *query)
case R600_QUERY_BUFFER_WAIT_TIME:
rquery-end_result = rctx-ws-query_value(rctx-ws, 
RADEON_BUFFER_WAIT_TIME_NS);
return;
+   case R600_QUERY_NUM_CS_FLUSHES:
+   rquery-end_result = rctx-ws-query_value(rctx-ws, 
RADEON_NUM_CS_FLUSHES);
+   return;
+   case R600_QUERY_NUM_BYTES_MOVED:
+   rquery-end_result = rctx-ws-query_value(rctx-ws, 
RADEON_NUM_BYTES_MOVED);
+   return;
+

[Mesa-dev] [PATCH 1/7] winsys/radeon: if there's VRAM-only usage, keep it

From: Marek Olšák marek.ol...@amd.com

---
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 40 +++
 1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index ccba0c0..f6b9d62 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -211,14 +211,30 @@ static struct radeon_winsys_cs 
*radeon_drm_cs_create(struct radeon_winsys *rws,
 #define OUT_CS(cs, value) (cs)-buf[(cs)-cdw++] = (value)
 
 static INLINE void update_reloc_domains(struct drm_radeon_cs_reloc *reloc,
-enum radeon_bo_domain rd,
-enum radeon_bo_domain wd,
+enum radeon_bo_usage usage,
+enum radeon_bo_domain new_domain,
 enum radeon_bo_domain *added_domains)
 {
-*added_domains = (rd | wd)  ~(reloc-read_domains | reloc-write_domain);
-
-reloc-read_domains |= rd;
-reloc-write_domain |= wd;
+enum radeon_bo_domain current = reloc-read_domains | reloc-write_domain;
+enum radeon_bo_domain final;
+
+/* If there is at least one command which wants the buffer to be in VRAM
+ * only, keep it in VRAM. */
+if ((current  new_domain) == RADEON_DOMAIN_VRAM)
+final = RADEON_DOMAIN_VRAM;
+else
+final = current | new_domain;
+
+*added_domains = final  ~current;
+
+/* If we have at least one write usage... */
+if (usage  RADEON_USAGE_WRITE || reloc-write_domain) {
+reloc-write_domain = final;
+reloc-read_domains = 0;
+} else {
+/* write_domain is zero */
+reloc-read_domains = final;
+}
 }
 
 int radeon_get_reloc(struct radeon_cs_context *csc, struct radeon_bo *bo)
@@ -267,8 +283,6 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
 struct radeon_cs_context *csc = cs-csc;
 struct drm_radeon_cs_reloc *reloc;
 unsigned hash = bo-handle  (sizeof(csc-is_handle_added)-1);
-enum radeon_bo_domain rd = usage  RADEON_USAGE_READ ? domains : 0;
-enum radeon_bo_domain wd = usage  RADEON_USAGE_WRITE ? domains : 0;
 bool update_hash = TRUE;
 int i;
 
@@ -298,7 +312,7 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
  * update the cmd stream with proper buffer offset).
  */
 update_hash = FALSE;
-update_reloc_domains(reloc, rd, wd, added_domains);
+update_reloc_domains(reloc, usage, domains, added_domains);
 if (cs-base.ring_type != RING_DMA) {
 csc-reloc_indices_hashlist[hash] = i;
 return i;
@@ -326,8 +340,10 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
 p_atomic_inc(bo-num_cs_references);
 reloc = csc-relocs[csc-crelocs];
 reloc-handle = bo-handle;
-reloc-read_domains = rd;
-reloc-write_domain = wd;
+if (usage  RADEON_USAGE_WRITE)
+reloc-write_domain = domains;
+else
+reloc-read_domains = domains;
 reloc-flags = 0;
 
 csc-is_handle_added[hash] = TRUE;
@@ -337,7 +353,7 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
 
 csc-chunks[1].length_dw += RELOC_DWORDS;
 
-*added_domains = rd | wd;
+*added_domains = domains;
 return csc-crelocs++;
 }
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/7] r600g, radeonsi: set correct initial domain for shared resources

From: Marek Olšák marek.ol...@amd.com

This depends on the kernel patch.
---
 src/gallium/drivers/radeon/r600_texture.c |  2 +-
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 51 +++
 src/gallium/winsys/radeon/drm/radeon_winsys.h |  5 +++
 3 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 1966251..0b572ed 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -624,7 +624,7 @@ r600_texture_create_object(struct pipe_screen *screen,
} else {
resource-buf = buf;
resource-cs_buf = rscreen-ws-buffer_get_cs_handle(buf);
-   resource-domains = RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM;
+   resource-domains = 
rscreen-ws-buffer_get_initial_domain(resource-cs_buf);
}
 
if (rtex-cmask.size) {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 9665613..4c01295 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -92,6 +92,19 @@ struct drm_radeon_gem_va {
 #define DRM_RADEON_GEM_VA   0x2b
 #endif
 
+#ifndef DRM_RADEON_GEM_OP
+#define DRM_RADEON_GEM_OP  0x2c
+
+/* Sets or returns a value associated with a buffer. */
+struct drm_radeon_gem_op {
+uint32_t handle; /* buffer */
+uint32_t op; /* RADEON_GEM_OP_* */
+uint64_t value;  /* input or return value */
+};
+
+#define RADEON_GEM_OP_GET_INITIAL_DOMAIN   0
+#define RADEON_GEM_OP_SET_INITIAL_DOMAIN   1
+#endif
 
 
 extern const struct pb_vtbl radeon_bo_vtbl;
@@ -201,6 +214,18 @@ static boolean radeon_bo_is_busy(struct pb_buffer *_buf,
 }
 }
 
+static enum radeon_bo_domain get_valid_domain(enum radeon_bo_domain domain)
+{
+/* Zero domains the driver doesn't understand. */
+domain = RADEON_DOMAIN_VRAM_GTT;
+
+/* If no domain is set, we must set something... */
+if (!domain)
+domain = RADEON_DOMAIN_VRAM_GTT;
+
+return domain;
+}
+
 static enum radeon_bo_domain radeon_bo_get_current_domain(
struct radeon_winsys_cs_handle *buf)
 {
@@ -214,14 +239,27 @@ static enum radeon_bo_domain radeon_bo_get_current_domain(
 args, sizeof(args));
 
 /* GEM domains and winsys domains are defined the same. */
-/* Zero domains the driver doesn't understand. */
-args.domain = RADEON_DOMAIN_VRAM_GTT;
+return get_valid_domain(args.domain);
+}
 
-/* If no domain is set, we must set something... */
-if (!args.domain)
-args.domain = RADEON_DOMAIN_VRAM_GTT;
+static enum radeon_bo_domain radeon_bo_get_initial_domain(
+   struct radeon_winsys_cs_handle *buf)
+{
+struct radeon_bo *bo = (struct radeon_bo*)buf;
+struct drm_radeon_gem_op args;
+
+if (bo-rws-info.drm_minor  38)
+return RADEON_DOMAIN_VRAM_GTT;
 
-return args.domain;
+memset(args, 0, sizeof(args));
+args.handle = bo-handle;
+args.op = RADEON_GEM_OP_GET_INITIAL_DOMAIN;
+
+drmCommandWriteRead(bo-rws-fd, DRM_RADEON_GEM_OP,
+args, sizeof(args));
+
+/* GEM domains and winsys domains are defined the same. */
+return get_valid_domain(args.value);
 }
 
 static uint64_t radeon_bomgr_find_va(struct radeon_bomgr *mgr, uint64_t size, 
uint64_t alignment)
@@ -1113,4 +1151,5 @@ void radeon_bomgr_init_functions(struct radeon_drm_winsys 
*ws)
 ws-base.buffer_get_handle = radeon_winsys_bo_get_handle;
 ws-base.buffer_get_virtual_address = radeon_winsys_bo_va;
 ws-base.buffer_get_current_domain = radeon_bo_get_current_domain;
+ws-base.buffer_get_initial_domain = radeon_bo_get_initial_domain;
 }
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index dc34f95..4e614ec 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -384,6 +384,11 @@ struct radeon_winsys {
  */
 enum radeon_bo_domain (*buffer_get_current_domain)(struct 
radeon_winsys_cs_handle *buf);
 
+/**
+ * Query the initial placement of the buffer from the kernel driver.
+ */
+enum radeon_bo_domain (*buffer_get_initial_domain)(struct 
radeon_winsys_cs_handle *buf);
+
 /**
  * Command submission.
  *
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/7] winsys/radeon: add interface for setting a priority number for each relocation

From: Marek Olšák marek.ol...@amd.com

The cs_add_reloc change is commented out not to break compilation.
The highest priority of all cs_add_reloc calls is send to the kernel.
---
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 20 +---
 src/gallium/winsys/radeon/drm/radeon_winsys.h | 21 -
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 2e07fa5..a25a7d7 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -210,10 +210,11 @@ static struct radeon_winsys_cs 
*radeon_drm_cs_create(struct radeon_winsys *rws,
 
 #define OUT_CS(cs, value) (cs)-buf[(cs)-cdw++] = (value)
 
-static INLINE void update_reloc_domains(struct drm_radeon_cs_reloc *reloc,
-enum radeon_bo_usage usage,
-enum radeon_bo_domain new_domain,
-enum radeon_bo_domain *added_domains)
+static INLINE void update_reloc(struct drm_radeon_cs_reloc *reloc,
+enum radeon_bo_usage usage,
+enum radeon_bo_domain new_domain,
+unsigned priority,
+enum radeon_bo_domain *added_domains)
 {
 enum radeon_bo_domain current = reloc-read_domains | reloc-write_domain;
 enum radeon_bo_domain final;
@@ -235,6 +236,8 @@ static INLINE void update_reloc_domains(struct 
drm_radeon_cs_reloc *reloc,
 /* write_domain is zero */
 reloc-read_domains = final;
 }
+
+reloc-flags = MAX2(reloc-flags, priority);
 }
 
 int radeon_get_reloc(struct radeon_cs_context *csc, struct radeon_bo *bo)
@@ -278,6 +281,7 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
  struct radeon_bo *bo,
  enum radeon_bo_usage usage,
  enum radeon_bo_domain domains,
+ unsigned priority,
  enum radeon_bo_domain *added_domains)
 {
 struct radeon_cs_context *csc = cs-csc;
@@ -286,7 +290,9 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
 bool update_hash = TRUE;
 int i;
 
+priority = MIN2(priority, 15);
 *added_domains = 0;
+
 if (csc-is_handle_added[hash]) {
 i = csc-reloc_indices_hashlist[hash];
 reloc = csc-relocs[i];
@@ -312,7 +318,7 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
  * update the cmd stream with proper buffer offset).
  */
 update_hash = FALSE;
-update_reloc_domains(reloc, usage, domains, added_domains);
+update_reloc(reloc, usage, domains, priority, added_domains);
 if (cs-base.ring_type != RING_DMA) {
 csc-reloc_indices_hashlist[hash] = i;
 return i;
@@ -344,7 +350,7 @@ static unsigned radeon_add_reloc(struct radeon_drm_cs *cs,
 reloc-write_domain = domains;
 else
 reloc-read_domains = domains;
-reloc-flags = 0;
+reloc-flags = priority;
 
 csc-is_handle_added[hash] = TRUE;
 if (update_hash) {
@@ -365,7 +371,7 @@ static unsigned radeon_drm_cs_add_reloc(struct 
radeon_winsys_cs *rcs,
 struct radeon_drm_cs *cs = radeon_drm_cs(rcs);
 struct radeon_bo *bo = (struct radeon_bo*)buf;
 enum radeon_bo_domain added_domains;
-unsigned index = radeon_add_reloc(cs, bo, usage, domains, added_domains);
+unsigned index = radeon_add_reloc(cs, bo, usage, domains, 0, 
added_domains);
 
 if (added_domains  RADEON_DOMAIN_GTT)
 cs-csc-used_gart += bo-base.size;
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index a692408..650df4e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -165,6 +165,22 @@ enum radeon_value_id {
 RADEON_GTT_USAGE
 };
 
+enum radeon_bo_priority {
+RADEON_PRIO_MIN,
+RADEON_PRIO_SHADER_DATA, /* shader code, resource descriptors */
+RADEON_PRIO_SHADER_BUFFER_RO, /* read-only */
+RADEON_PRIO_SHADER_TEXTURE_RO, /* read-only */
+RADEON_PRIO_SHADER_RESOURCE_RW, /* buffers, textures, streamout, GS rings, 
RATs; read/write */
+RADEON_PRIO_COLOR_BUFFER,
+RADEON_PRIO_DEPTH_BUFFER,
+RADEON_PRIO_SHADER_TEXTURE_MSAA,
+RADEON_PRIO_COLOR_BUFFER_MSAA,
+RADEON_PRIO_DEPTH_BUFFER_MSAA,
+RADEON_PRIO_COLOR_META,
+RADEON_PRIO_DEPTH_META,
+RADEON_PRIO_MAX /* must be = 15 */
+};
+
 struct winsys_handle;
 struct radeon_winsys_cs_handle;
 
@@ -426,12 +442,15 @@ struct radeon_winsys {
  * \param buf A winsys buffer to validate.
  * \param usage   Whether the buffer is used for read and/or write.
  * \param domain  Bitmask of the

[Mesa-dev] [PATCH 2/7] r600g, radeonsi: use current domain for deciding when to do blit-based transfer

From: Marek Olšák marek.ol...@amd.com

---
 src/gallium/drivers/radeon/r600_texture.c |  3 ++-
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 24 
 src/gallium/winsys/radeon/drm/radeon_winsys.h |  8 +++-
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 35ad97b..1966251 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -910,7 +910,8 @@ static void *r600_texture_transfer_map(struct pipe_context 
*ctx,
 
/* Untiled buffers in VRAM, which is slow for CPU reads and writes */
if (!(usage  PIPE_TRANSFER_MAP_DIRECTLY) 
-   (rtex-resource.domains == RADEON_DOMAIN_VRAM)) {
+   (rctx-ws-buffer_get_current_domain(rtex-resource.cs_buf) ==
+RADEON_DOMAIN_VRAM)) {
use_staging_texture = TRUE;
}
 
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 2ac060b..9665613 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -201,6 +201,29 @@ static boolean radeon_bo_is_busy(struct pb_buffer *_buf,
 }
 }
 
+static enum radeon_bo_domain radeon_bo_get_current_domain(
+   struct radeon_winsys_cs_handle *buf)
+{
+struct radeon_bo *bo = (struct radeon_bo*)buf;
+struct drm_radeon_gem_busy args;
+
+memset(args, 0, sizeof(args));
+args.handle = bo-handle;
+
+drmCommandWriteRead(bo-rws-fd, DRM_RADEON_GEM_BUSY,
+args, sizeof(args));
+
+/* GEM domains and winsys domains are defined the same. */
+/* Zero domains the driver doesn't understand. */
+args.domain = RADEON_DOMAIN_VRAM_GTT;
+
+/* If no domain is set, we must set something... */
+if (!args.domain)
+args.domain = RADEON_DOMAIN_VRAM_GTT;
+
+return args.domain;
+}
+
 static uint64_t radeon_bomgr_find_va(struct radeon_bomgr *mgr, uint64_t size, 
uint64_t alignment)
 {
 struct radeon_bo_va_hole *hole, *n;
@@ -1089,4 +1112,5 @@ void radeon_bomgr_init_functions(struct radeon_drm_winsys 
*ws)
 ws-base.buffer_from_handle = radeon_winsys_bo_from_handle;
 ws-base.buffer_get_handle = radeon_winsys_bo_get_handle;
 ws-base.buffer_get_virtual_address = radeon_winsys_bo_va;
+ws-base.buffer_get_current_domain = radeon_bo_get_current_domain;
 }
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index 37affc3..dc34f95 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -61,7 +61,8 @@ enum radeon_bo_layout {
 
 enum radeon_bo_domain { /* bitfield */
 RADEON_DOMAIN_GTT  = 2,
-RADEON_DOMAIN_VRAM = 4
+RADEON_DOMAIN_VRAM = 4,
+RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT
 };
 
 enum radeon_bo_usage { /* bitfield */
@@ -378,6 +379,11 @@ struct radeon_winsys {
  */
 uint64_t (*buffer_get_virtual_address)(struct radeon_winsys_cs_handle 
*buf);
 
+/**
+ * Query the current placement of the buffer from the memory manager.
+ */
+enum radeon_bo_domain (*buffer_get_current_domain)(struct 
radeon_winsys_cs_handle *buf);
+
 /**
  * Command submission.
  *
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH V2 3/4] glsl: Link error if fs defines conflicting qualifiers for gl_FragCoord

GLSL 1.50 spec says:
   If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that
program that have a static use gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must
have the same set of qualifiers.

This patch causes the shader link to fail if we have multiple fragment
shaders with conflicting layout qualifiers for gl_FragCoord. For example:

fragment shader 1:
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;

void foo();
void main()
{
   gl_FragColor = vec4(gl_FragCoord.xyz, 1.0);
   foo();
}

fragment shader 2:
layout(origin_upper_left) in vec4 gl_FragCoord;
void foo()
{
   gl_FragColor.a = gl_FragCoord.z;
}

Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
 src/glsl/ast_to_hir.cpp |  5 
 src/glsl/glsl_parser_extras.cpp | 16 +++
 src/glsl/glsl_parser_extras.h   |  1 +
 src/glsl/linker.cpp | 60 +
 src/mesa/main/mtypes.h  |  8 ++
 5 files changed, 90 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index f5dacfd..b639f98 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -120,6 +120,11 @@ _mesa_ast_to_hir(exec_list *instructions, struct 
_mesa_glsl_parse_state *state)
   instructions-push_head(var);
}
 
+   /* Figure out if gl_FragCoord is actually used in fragment shader */
+   ir_variable *const var = state-symbols-get_variable(gl_FragCoord);
+   if (var != NULL)
+  state-fs_uses_gl_fragcoord = var-data.used;
+
/* From section 7.1 (Built-In Language Variables) of the GLSL 4.10 spec:
 *
 * If multiple shaders using members of a built-in block belonging to
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index fcbbf44..f953713 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -201,6 +201,7 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
gl_context *_ctx,
this-default_uniform_qualifier-flags.q.shared = 1;
this-default_uniform_qualifier-flags.q.column_major = 1;
 
+   this-fs_uses_gl_fragcoord = false;
this-fs_redeclares_gl_fragcoord = false;
this-fs_origin_upper_left = false;
this-fs_pixel_center_integer = false;
@@ -1363,6 +1364,14 @@ set_shader_inout_layout(struct gl_shader *shader,
   assert(!state-cs_input_local_size_specified);
}
 
+   if (shader-Stage != MESA_SHADER_FRAGMENT) {
+  /* Should have been prevented by the parser. */
+  assert(!state-fs_uses_gl_fragcoord);
+  assert(!state-fs_redeclares_gl_fragcoord);
+  assert(!state-fs_pixel_center_integer);
+  assert(!state-fs_origin_upper_left);
+   }
+
switch (shader-Stage) {
case MESA_SHADER_GEOMETRY:
   shader-Geom.VerticesOut = 0;
@@ -1396,6 +1405,13 @@ set_shader_inout_layout(struct gl_shader *shader,
   }
   break;
 
+   case MESA_SHADER_FRAGMENT:
+  shader-redeclares_gl_fragcoord = state-fs_redeclares_gl_fragcoord;
+  shader-uses_gl_fragcoord = state-fs_uses_gl_fragcoord;
+  shader-pixel_center_integer = state-fs_pixel_center_integer;
+  shader-origin_upper_left = state-fs_origin_upper_left;
+  break;
+
default:
   /* Nothing to do. */
   break;
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 2017913..511ca48 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -427,6 +427,7 @@ struct _mesa_glsl_parse_state {
const struct gl_extensions *extensions;
 
bool uses_builtin_functions;
+   bool fs_uses_gl_fragcoord;
 
/**
 * For geometry shaders, size of the most recently seen input declaration
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index f6b2661..1268aef 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1194,6 +1194,65 @@ private:
hash_table *unnamed_interfaces;
 };
 
+static bool
+fs_uses_conflicting_layout_qualifiers(struct gl_shader *shader,
+  struct gl_shader *linked_shader)
+{
+   bool qual_absent_in_shader_but_present_in_linked_shader =
+  (!shader-origin_upper_left  linked_shader-origin_upper_left) ||
+  (!shader-pixel_center_integer  linked_shader-pixel_center_integer);
+
+   bool qual_present_in_shader_but_absent_in_linked_shader =
+  (shader-origin_upper_left  !linked_shader-origin_upper_left) ||
+  (shader-pixel_center_integer  !linked_shader-pixel_center_integer);
+
+   return ((qual_absent_in_shader_but_present_in_linked_shader 
+shader-uses_gl_fragcoord) ||
+   (qual_present_in_shader_but_absent_in_linked_shader 
+linked_shader-uses_gl_fragcoord));
+}
+
+/**
+ * Performs the cross-validation of layout qualifiers specified in
+ * redeclaration of gl_FragCoord for the attached fragment shaders,
+ * and propagates them to the

[Mesa-dev] [PATCH V2 1/4] glsl: Compile error if fs defines conflicting qualifiers for gl_FragCoord

GLSL 1.50 spec says:
   If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that
program that have a static use gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must
have the same set of qualifiers.

This patch makes the glsl compiler to generate an error if we have a
fragment shader defined with conflicting layout qualifier declarations
for gl_FragCoord. For example:

layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;
layout(pixel_center_integer) in vec4 gl_FragCoord;

void main()
{
}

V2: Some code refactoring for better readability.
Add compiler error conditions for redeclarations like:

layout(origin_upper_left) in vec4 gl_FragCoord;
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;

and

in vec4 gl_FragCoord;
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;

Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
This series is also available at:
https://github.com/aphogat/mesa.git, branch='review'

 src/glsl/ast_to_hir.cpp | 60 +
 src/glsl/glsl_parser_extras.cpp |  5 
 src/glsl/glsl_parser_extras.h   | 12 +
 3 files changed, 77 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index f06baeb..9fe3095 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2295,6 +2295,36 @@ apply_image_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
}
 }
 
+static inline const char*
+get_layout_qualifier_string(bool origin_upper_left, bool pixel_center_integer)
+{
+   if (origin_upper_left  pixel_center_integer)
+  return origin_upper_left, pixel_center_integer;
+   else if (origin_upper_left)
+  return origin_upper_left;
+   else if (pixel_center_integer)
+  return pixel_center_integer;
+   else
+  return  ;
+}
+
+static inline bool
+is_conflicting_fragcoord_redeclaration(struct _mesa_glsl_parse_state *state,
+   const struct ast_type_qualifier *qual)
+{
+   bool conflicting_origin_upper_left =
+  (state-fs_origin_upper_left  !qual-flags.q.origin_upper_left) ||
+  (!state-fs_origin_upper_left  qual-flags.q.origin_upper_left 
+   state-fs_redeclares_gl_fragcoord);
+
+   bool conflicting_pixel_center_integer =
+  (state-fs_pixel_center_integer  !qual-flags.q.pixel_center_integer) 
||
+  (!state-fs_pixel_center_integer  qual-flags.q.pixel_center_integer 
+   state-fs_redeclares_gl_fragcoord);
+
+   return (conflicting_origin_upper_left || conflicting_pixel_center_integer);
+}
+
 static void
 apply_type_qualifier_to_variable(const struct ast_type_qualifier *qual,
 ir_variable *var,
@@ -2459,6 +2489,36 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
   qual_string);
}
 
+   if (strcmp(var-name, gl_FragCoord) == 0) {
+
+  /* Make sure all gl_FragCoord redeclarations specify the same layout
+   * qualifiers.
+   */
+  if (is_conflicting_fragcoord_redeclaration(state, qual)) {
+ const char *const qual_string =
+get_layout_qualifier_string(qual-flags.q.origin_upper_left,
+qual-flags.q.pixel_center_integer);
+
+ const char *const state_string =
+get_layout_qualifier_string(state-fs_origin_upper_left,
+state-fs_pixel_center_integer);
+
+ _mesa_glsl_error(loc, state,
+  gl_FragCoord redeclared with different layout 
+  qualifiers (%s) and (%s) ,
+  state_string,
+  qual_string);
+  }
+  state-fs_origin_upper_left = qual-flags.q.origin_upper_left;
+  state-fs_pixel_center_integer = qual-flags.q.pixel_center_integer;
+  state-fs_redeclares_gl_fragcoord_with_no_layout_qualifiers =
+ !qual-flags.q.origin_upper_left  
!qual-flags.q.pixel_center_integer;
+  state-fs_redeclares_gl_fragcoord =
+ state-fs_origin_upper_left ||
+ state-fs_pixel_center_integer ||
+ state-fs_redeclares_gl_fragcoord_with_no_layout_qualifiers;
+   }
+
if (qual-flags.q.explicit_location) {
   validate_explicit_location(qual, var, state, loc);
} else if (qual-flags.q.explicit_index) {
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index d7f5202..fcbbf44 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -201,6 +201,11 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
gl_context *_ctx,
this-default_uniform_qualifier-flags.q.shared = 1;
this-default_uniform_qualifier-flags.q.column_major = 1;
 
+   this-fs_redeclares_gl_fragcoord = false;
+   this-fs_origin_upper_left = false;
+

[Mesa-dev] [PATCH V2 2/4] glsl: Compile error if fs uses gl_FragCoord before first redeclaration

Section 4.3.8.1, page 39 of GLSL 1.50 spec says:
  Within any shader, the first redeclarations of gl_FragCoord
   must appear before any use of gl_FragCoord.

GLSL compiler should generate an error in following case:

vec4 p = gl_FragCoord;
layout(origin_upper_left) in vec4 gl_FragCoord;

void main()
{
}

Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
 src/glsl/ast_to_hir.cpp | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 9fe3095..f5dacfd 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2490,6 +2490,22 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
}
 
if (strcmp(var-name, gl_FragCoord) == 0) {
+  /* Section 4.3.8.1, page 39 of GLSL 1.50 spec says:
+   *
+   *Within any shader, the first redeclarations of gl_FragCoord
+   * must appear before any use of gl_FragCoord.
+   *
+   * Generate a compiler error if above condition is not met by the
+   * fragment shader.
+   */
+  ir_variable *earlier = state-symbols-get_variable(gl_FragCoord);
+  if (earlier != NULL 
+  earlier-data.used 
+  !state-fs_redeclares_gl_fragcoord) {
+ _mesa_glsl_error(loc, state,
+  gl_FragCoord used before its first redeclaration 
+  in fragment shader);
+  }
 
   /* Make sure all gl_FragCoord redeclarations specify the same layout
* qualifiers.
-- 
1.8.3.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH V2 4/4] glsl: Apply the link error conditions to GL_ARB_fragment_coord_conventions

Link error conditions added in previous patch are equally applicable
to GL_ARB_fragment_coord_conventions implementation. Extension's spec
says:
   If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that program
that have a static use of gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must have
the same set of qualifiers.

Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
 src/glsl/glsl_parser_extras.cpp | 2 ++
 src/glsl/linker.cpp | 7 ++-
 src/mesa/main/mtypes.h  | 6 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index f953713..bf5f5a2 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1410,6 +1410,8 @@ set_shader_inout_layout(struct gl_shader *shader,
   shader-uses_gl_fragcoord = state-fs_uses_gl_fragcoord;
   shader-pixel_center_integer = state-fs_pixel_center_integer;
   shader-origin_upper_left = state-fs_origin_upper_left;
+  shader-ARB_fragment_coord_conventions_enable =
+ state-ARB_fragment_coord_conventions_enable;
   break;
 
default:
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 1268aef..a84d679 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1227,7 +1227,8 @@ link_fs_input_layout_qualifiers(struct gl_shader_program 
*prog,
linked_shader-origin_upper_left = false;
linked_shader-pixel_center_integer = false;
 
-   if (linked_shader-Stage != MESA_SHADER_FRAGMENT || prog-Version  150)
+   if (linked_shader-Stage != MESA_SHADER_FRAGMENT ||
+   (prog-Version  150  !prog-ARB_fragment_coord_conventions_enable))
   return;
 
/* From the GLSL 1.50 spec, page 39:
@@ -2175,6 +2176,7 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
ralloc_free(prog-AtomicBuffers);
prog-AtomicBuffers = NULL;
prog-NumAtomicBuffers = 0;
+   prog-ARB_fragment_coord_conventions_enable = false;
 
/* Separate the shaders into groups based on their type.
 */
@@ -2201,6 +2203,9 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
 goto done;
   }
 
+  prog-ARB_fragment_coord_conventions_enable |=
+ prog-Shaders[i]-ARB_fragment_coord_conventions_enable;
+
   gl_shader_stage shader_type = prog-Shaders[i]-Stage;
   shader_list[shader_type][num_shaders[shader_type]] = prog-Shaders[i];
   num_shaders[shader_type]++;
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index dd2ee82..2694d9e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2416,6 +2416,7 @@ struct gl_shader
bool uses_builtin_functions;
bool uses_gl_fragcoord;
bool redeclares_gl_fragcoord;
+   bool ARB_fragment_coord_conventions_enable;
 
/**
 * Fragment shader state from GLSL 1.50 layout qualifiers.
@@ -2754,6 +2755,11 @@ struct gl_shader_program
 * \c NULL.
 */
struct gl_shader *_LinkedShaders[MESA_SHADER_STAGES];
+
+   /* True if any of the fragment shaders attached to this program use:
+* #extension ARB_fragment_coord_conventions: enable
+*/
+   GLboolean ARB_fragment_coord_conventions_enable;
 };   
 
 
-- 
1.8.3.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 74010] mesa-10.0.2: z-buffer issue with opengl 3.3 context on intel

https://bugs.freedesktop.org/show_bug.cgi?id=74010

--- Comment #6 from Tibbo leclercq.thiba...@yahoo.fr ---
I've encountered this segfault before, and i think i can give some useful
informations.
As stated in the file src/mesa/main/varray.c:

   /* Page 407 (page 423 of the PDF) of the OpenGL 3.0 spec says:
*
* Client vertex arrays - all vertex array attribute pointers must
* refer to buffer objects (section 2.9.2). The default vertex array
* object (the name zero) is also deprecated. Calling
* VertexAttribPointer when no buffer object or no vertex array object
* is bound will generate an INVALID_OPERATION error...
*
* The check for VBOs is handled below.
*/

That means you must use a VAO to encapsulate these calls to conform the spec.

Of course this is not a good reason to end up with a segmentation fault,
especially when everyone around keep not using VAO with recent core profiles... 

So, in order to avoid the crash you can just comment the line 390 in varray.c:

   if (ctx-API == API_OPENGL_CORE
(ctx-Array.VAO == ctx-Array.DefaultVAO)) {
  _mesa_error(ctx, GL_INVALID_OPERATION, %s(no array object bound),
  func);
   //   return;
   }

This way the deprecated default VAO 0 will be used, and everything should
work. Maybe some testing later in the process should also be implemented...

Just in case you want know: the segfault happens line 112 in
src/mesa/drivers/dri/i965/intel_upload.c, when memcpy is call with null src and
dest.

Be aware that this workaround is not fully tested, and comes with no warranty.  

For the overlapping triangles problem, i've never seen that before... so maybe
it is a problem in your code.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/7] r600g, radeonsi: use current domain for deciding when to do blit-based transfer

On Die, 2014-02-25 at 00:48 +0100, Marek Olšák wrote:
 
 diff --git a/src/gallium/drivers/radeon/r600_texture.c 
 b/src/gallium/drivers/radeon/r600_texture.c
 index 35ad97b..1966251 100644
 --- a/src/gallium/drivers/radeon/r600_texture.c
 +++ b/src/gallium/drivers/radeon/r600_texture.c
 @@ -910,7 +910,8 @@ static void *r600_texture_transfer_map(struct 
 pipe_context *ctx,
  
   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
   if (!(usage  PIPE_TRANSFER_MAP_DIRECTLY) 
 - (rtex-resource.domains == RADEON_DOMAIN_VRAM)) {
 + (rctx-ws-buffer_get_current_domain(rtex-resource.cs_buf) ==
 +  RADEON_DOMAIN_VRAM)) {
   use_staging_texture = TRUE;
   }

If rtex is already referenced by the command stream being prepared, the
decision needs to be based on that instead. The ioctl just returns where
the BO happens to be when it's called, which is not necessarily where it
will be when this command stream is executed.


-- 
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] R600/SI: Allow SI_KILL for geometry shaders