[Mesa-dev] [Bug 64649] [r600g] Anomaly 2 (Steam) crashes with GLX_EXT_swap_control not supported, unable to set vertical sync

[bugzilla-daemon]

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

romula...@gmail.com changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/r600|GLX

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

[Mesa-dev] [PATCH] intel: Don't spam "intelReadPixels: fallback to swrast" in non-PBO case.

[Kenneth Graunke]

When an application is using PBOs, we attempt to use the BLT engine to
perform ReadPixels.  If that fails due to some restrictions, it's useful
to raise a performance warning.

In the non-PBO case, we always use a CPU mapping since getting the data
into client memory requires a CPU-side copy.  This is a very common case,
so raising a performance warning is annoying.  In particular, apitrace's
image dumping code hits this path, causing it to print hundreds of
thousands of performance warnings via ARB_debug_output.  This tends to
obscure actual errors or other important messages.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/intel/intel_pixel_read.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_read.c 
b/src/mesa/drivers/dri/intel/intel_pixel_read.c
index 6b715d0..ebdc528 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_read.c
@@ -89,12 +89,7 @@ do_blit_readpixels(struct gl_context * ctx,
if (!src)
   return false;
 
-   if (!_mesa_is_bufferobj(pack->BufferObj)) {
-  /* PBO only for now:
-   */
-  DBG("%s - not PBO\n", __FUNCTION__);
-  return false;
-   }
+   assert(_mesa_is_bufferobj(pack->BufferObj));
 
struct gl_renderbuffer *rb = ctx->ReadBuffer->_ColorReadBuffer;
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
@@ -178,9 +173,15 @@ intelReadPixels(struct gl_context * ctx,
 
DBG("%s\n", __FUNCTION__);
 
-   if (do_blit_readpixels
-   (ctx, x, y, width, height, format, type, pack, pixels))
-  return;
+   if (_mesa_is_bufferobj(pack->BufferObj)) {
+  /* Using PBOs, so try the BLT based path. */
+  if (do_blit_readpixels(ctx, x, y, width, height, format, type, pack,
+ pixels)) {
+ return;
+  }
+
+  perf_debug("%s: fallback to CPU mapping in PBO case\n", __FUNCTION__);
+   }
 
/* glReadPixels() wont dirty the front buffer, so reset the dirty
 * flag after calling intel_prepare_render(). */
@@ -188,8 +189,6 @@ intelReadPixels(struct gl_context * ctx,
intel_prepare_render(intel);
intel->front_buffer_dirty = dirty;
 
-   perf_debug("%s: fallback to swrast\n", __FUNCTION__);
-
/* Update Mesa state before calling _mesa_readpixels().
 * XXX this may not be needed since ReadPixels no longer uses the
 * span code.
-- 
1.8.2.3

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

[Mesa-dev] [PATCH] r600g: fixup for MSAA texture support checking

[Niels Ole Salscheider]

Signed-off-by: Niels Ole Salscheider 
---
 src/gallium/drivers/r600/r600_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 4e5af70..4d74db0 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -305,7 +305,7 @@ int r600_compute_shader_create(struct pipe_context * ctx,
 
shader_ctx.bc = bytecode;
r600_bytecode_init(shader_ctx.bc, r600_ctx->chip_class, 
r600_ctx->family,
-  r600_ctx->screen->msaa_texture_support);
+  r600_ctx->screen->has_compressed_msaa_texturing);
shader_ctx.bc->type = TGSI_PROCESSOR_COMPUTE;
shader_ctx.bc->isa = r600_ctx->isa;
r600_llvm_compile(mod, r600_ctx->family,
-- 
1.8.2.3

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

Re: [Mesa-dev] [PATCH] util/gl: Change default waffle platform

[Chad Versace]

This was intended for the Piglit list.

Please ignore, (or better yet, go review it on the proper list).

On 05/15/2013 01:27 PM, Chad Versace wrote:

Change default waffle platform from GLX to XEGL for GLES tests.

The default platform was GLX for all GL tests (GL and GLES).  But not all
GLX implementations support creation of ES1 and ES2 contexts. Unless the
user explicitly set PIGLIT_PLATFORM to some EGL platform, this problem
caused GLES tests to skip.

Enables 76 GLES tests on my system.

CC: Eric Anholt 
Signed-off-by: Chad Versace 


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

[Mesa-dev] R600/SI Patches: A few cleanups for compute

[Tom Stellard]

Hi,

The attached patches add some new patterns and instructions for SI and
are a prerequisite for more invasive compute shader changes that I'm
working on.

Please Review.

-Tom
>From 5b87402d1290df5ec8bdbe1333cadb5739a8c8bd Mon Sep 17 00:00:00 2001
From: Tom Stellard 
Date: Mon, 13 May 2013 21:50:35 -0400
Subject: [PATCH 1/7] R600/SI: Make fitsRegClass() operands const

---
 lib/Target/R600/SIISelLowering.cpp | 2 +-
 lib/Target/R600/SIISelLowering.h   | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/Target/R600/SIISelLowering.cpp 
b/lib/Target/R600/SIISelLowering.cpp
index 6bd82a5..d7e2981 100644
--- a/lib/Target/R600/SIISelLowering.cpp
+++ b/lib/Target/R600/SIISelLowering.cpp
@@ -513,7 +513,7 @@ bool SITargetLowering::foldImm(SDValue &Operand, int32_t 
&Immediate,
 }
 
 /// \brief Does "Op" fit into register class "RegClass" ?
-bool SITargetLowering::fitsRegClass(SelectionDAG &DAG, SDValue &Op,
+bool SITargetLowering::fitsRegClass(SelectionDAG &DAG, const SDValue &Op,
 unsigned RegClass) const {
 
   MachineRegisterInfo &MRI = DAG.getMachineFunction().getRegInfo(); 
diff --git a/lib/Target/R600/SIISelLowering.h b/lib/Target/R600/SIISelLowering.h
index de637be..e9ea68a 100644
--- a/lib/Target/R600/SIISelLowering.h
+++ b/lib/Target/R600/SIISelLowering.h
@@ -30,7 +30,8 @@ class SITargetLowering : public AMDGPUTargetLowering {
 
   bool foldImm(SDValue &Operand, int32_t &Immediate,
bool &ScalarSlotUsed) const;
-  bool fitsRegClass(SelectionDAG &DAG, SDValue &Op, unsigned RegClass) const;
+  bool fitsRegClass(SelectionDAG &DAG, const SDValue &Op,
+unsigned RegClass) const;
   void ensureSRegLimit(SelectionDAG &DAG, SDValue &Operand, 
unsigned RegClass, bool &ScalarSlotUsed) const;
 
-- 
1.8.1.5

>From a2d4b16a0022110c6198ed330966911b2bad3361 Mon Sep 17 00:00:00 2001
From: Tom Stellard 
Date: Thu, 9 May 2013 16:44:22 -0400
Subject: [PATCH 2/7] R600/SI: Use the same names for VOP3 operands and
 encoding fields

This makes it possible to reorder the operands without breaking the
encoding.
---
 lib/Target/R600/SIInstrFormats.td | 62 +++
 lib/Target/R600/SIInstrInfo.td| 12 
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/lib/Target/R600/SIInstrFormats.td 
b/lib/Target/R600/SIInstrFormats.td
index f737ddd..51f323d 100644
--- a/lib/Target/R600/SIInstrFormats.td
+++ b/lib/Target/R600/SIInstrFormats.td
@@ -185,25 +185,25 @@ class VOP2  op, dag outs, dag ins, string asm, 
list pattern> :
 class VOP3  op, dag outs, dag ins, string asm, list pattern> :
 Enc64  {
 
-  bits<8> VDST;
-  bits<9> SRC0;
-  bits<9> SRC1;
-  bits<9> SRC2;
-  bits<3> ABS; 
-  bits<1> CLAMP;
-  bits<2> OMOD;
-  bits<3> NEG;
-
-  let Inst{7-0} = VDST;
-  let Inst{10-8} = ABS;
-  let Inst{11} = CLAMP;
+  bits<8> dst;
+  bits<9> src0;
+  bits<9> src1;
+  bits<9> src2;
+  bits<3> abs;
+  bits<1> clamp;
+  bits<2> omod;
+  bits<3> neg;
+
+  let Inst{7-0} = dst;
+  let Inst{10-8} = abs;
+  let Inst{11} = clamp;
   let Inst{25-17} = op;
   let Inst{31-26} = 0x34; //encoding
-  let Inst{40-32} = SRC0;
-  let Inst{49-41} = SRC1;
-  let Inst{58-50} = SRC2;
-  let Inst{60-59} = OMOD;
-  let Inst{63-61} = NEG;
+  let Inst{40-32} = src0;
+  let Inst{49-41} = src1;
+  let Inst{58-50} = src2;
+  let Inst{60-59} = omod;
+  let Inst{63-61} = neg;
   
   let mayLoad = 0;
   let mayStore = 0;
@@ -213,23 +213,23 @@ class VOP3  op, dag outs, dag ins, string asm, 
list pattern> :
 class VOP3b  op, dag outs, dag ins, string asm, list pattern> :
 Enc64  {
 
-  bits<8> VDST;
-  bits<9> SRC0;
-  bits<9> SRC1;
-  bits<9> SRC2;
-  bits<7> SDST;
-  bits<2> OMOD;
-  bits<3> NEG;
+  bits<8> dst;
+  bits<9> src0;
+  bits<9> src1;
+  bits<9> src2;
+  bits<7> sdst;
+  bits<2> omod;
+  bits<3> neg;
 
-  let Inst{7-0} = VDST;
-  let Inst{14-8} = SDST;
+  let Inst{7-0} = dst;
+  let Inst{14-8} = sdst;
   let Inst{25-17} = op;
   let Inst{31-26} = 0x34; //encoding
-  let Inst{40-32} = SRC0;
-  let Inst{49-41} = SRC1;
-  let Inst{58-50} = SRC2;
-  let Inst{60-59} = OMOD;
-  let Inst{63-61} = NEG;
+  let Inst{40-32} = src0;
+  let Inst{49-41} = src1;
+  let Inst{58-50} = src2;
+  let Inst{60-59} = omod;
+  let Inst{63-61} = neg;
 
   let mayLoad = 0;
   let mayStore = 0;
diff --git a/lib/Target/R600/SIInstrInfo.td b/lib/Target/R600/SIInstrInfo.td
index c8aecb7..11c8f9d 100644
--- a/lib/Target/R600/SIInstrInfo.td
+++ b/lib/Target/R600/SIInstrInfo.td
@@ -163,8 +163,8 @@ multiclass VOP1_Helper  op, RegisterClass drc, 
RegisterClass src,
  i32imm:$omod, i32imm:$neg),
 opName#"_e64 $dst, $src0, $abs, $clamp, $omod, $neg", []
   >, VOP  {
-let SRC1 = SIOperand.ZERO;
-let SRC2 = SIOperand.ZERO;
+let src1 = SIOperand.ZERO;
+let src2 = SIOperand.ZERO;
   }
 }
 
@@ -189,7 +189,7 @@ multiclass VOP2_Helper  op, RegisterClass vrc, 
RegisterClass arc,
  i32imm:$omod, i32

[Mesa-dev] [PATCH] util/gl: Change default waffle platform

[Chad Versace]

Change default waffle platform from GLX to XEGL for GLES tests.

The default platform was GLX for all GL tests (GL and GLES).  But not all
GLX implementations support creation of ES1 and ES2 contexts. Unless the
user explicitly set PIGLIT_PLATFORM to some EGL platform, this problem
caused GLES tests to skip.

Enables 76 GLES tests on my system.

CC: Eric Anholt 
Signed-off-by: Chad Versace 
---
 tests/util/piglit-framework-gl/piglit_fbo_framework.c|  2 +-
 tests/util/piglit-framework-gl/piglit_wfl_framework.c| 10 +-
 tests/util/piglit-framework-gl/piglit_wfl_framework.h|  2 +-
 tests/util/piglit-framework-gl/piglit_winsys_framework.c |  2 +-
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/tests/util/piglit-framework-gl/piglit_fbo_framework.c 
b/tests/util/piglit-framework-gl/piglit_fbo_framework.c
index da2c601..1b844bb 100644
--- a/tests/util/piglit-framework-gl/piglit_fbo_framework.c
+++ b/tests/util/piglit-framework-gl/piglit_fbo_framework.c
@@ -136,7 +136,7 @@ piglit_fbo_framework_create(const struct 
piglit_gl_test_config *test_config)
struct piglit_wfl_framework *wfl_fw;
struct piglit_gl_framework *gl_fw;
 
-   int32_t platform = piglit_wfl_framework_choose_platform();
+   int32_t platform = piglit_wfl_framework_choose_platform(test_config);
bool ok = true;
 
wfl_fw = calloc(1, sizeof(*wfl_fw));
diff --git a/tests/util/piglit-framework-gl/piglit_wfl_framework.c 
b/tests/util/piglit-framework-gl/piglit_wfl_framework.c
index 5c24f7c..801a258 100644
--- a/tests/util/piglit-framework-gl/piglit_wfl_framework.c
+++ b/tests/util/piglit-framework-gl/piglit_wfl_framework.c
@@ -41,11 +41,19 @@ piglit_wfl_framework(struct piglit_gl_framework *gl_fw)
 }
 
 int32_t
-piglit_wfl_framework_choose_platform(void)
+piglit_wfl_framework_choose_platform(const struct piglit_gl_test_config 
*test_config)
 {
const char *env = getenv("PIGLIT_PLATFORM");
 
if (env == NULL) {
+#if defined(PIGLIT_HAS_X11) && defined(PIGLIT_HAS_EGL)
+   if (test_config->supports_gl_es_version) {
+   /* Some GLX implementations don't support creation of
+* ES1 and ES2 contexts, so use XEGL instead.
+*/
+   return WAFFLE_PLATFORM_X11_EGL;
+   }
+#endif
 #ifdef PIGLIT_HAS_GLX
return WAFFLE_PLATFORM_GLX;
 #else
diff --git a/tests/util/piglit-framework-gl/piglit_wfl_framework.h 
b/tests/util/piglit-framework-gl/piglit_wfl_framework.h
index fe14991..d7506f1 100644
--- a/tests/util/piglit-framework-gl/piglit_wfl_framework.h
+++ b/tests/util/piglit-framework-gl/piglit_wfl_framework.h
@@ -64,4 +64,4 @@ piglit_wfl_framework_teardown(struct piglit_wfl_framework 
*wfl_fw);
  * WAFFLE_PLATFORM_*.
  */
 int32_t
-piglit_wfl_framework_choose_platform(void);
+piglit_wfl_framework_choose_platform(const struct piglit_gl_test_config 
*test_config);
diff --git a/tests/util/piglit-framework-gl/piglit_winsys_framework.c 
b/tests/util/piglit-framework-gl/piglit_winsys_framework.c
index df74542..971f183 100644
--- a/tests/util/piglit-framework-gl/piglit_winsys_framework.c
+++ b/tests/util/piglit-framework-gl/piglit_winsys_framework.c
@@ -136,7 +136,7 @@ choose_config_attribs(const struct piglit_gl_test_config 
*test_config)
 struct piglit_gl_framework*
 piglit_winsys_framework_factory(const struct piglit_gl_test_config 
*test_config)
 {
-   int32_t platform = piglit_wfl_framework_choose_platform();
+   int32_t platform = piglit_wfl_framework_choose_platform(test_config);
 
switch (platform) {
 #ifdef PIGLIT_HAS_X11
-- 
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] intel: Don't spam "intelReadPixels: fallback to swrast" all the time.

[Eric Anholt]

Kenneth Graunke  writes:

> Unless the application is using PBOs, any call to glReadPixels will hit
> this message.  Hitting this does mean mapping the buffer and accessing
> it via the CPU, but that isn't necessarily the worst thing in the world.
>
> apitrace's image dumping code hits this path, causing it to spam
> hundreds of thousands of performance warnings via ARB_debug_output,
> which makes it difficult to see actual errors.

Maybe only do so when dumping out of the PBO path?  It seems like this
is something useful to know about in that case.


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

Re: [Mesa-dev] Mesa 9.1.3 soon?

[Ian Romanick]

On 05/14/2013 11:51 AM, Paul Berry wrote:

On 13 May 2013 12:02, Ian Romanick mailto:i...@freedesktop.org>> wrote:

I've just picked over a bunch of commits to the 9.1 branch.  There
are a few commits (some fairly old) that wouldn't pick cleanly.
  Hopefully someone that knows that code can either resolve the
conflicts or add the commit IDs to bin/.cherry-ignore.

I'd like to release this as 9.1.3 either later this week or early
next week.  Does that work for people?


Any interest in trying to squeeze Chris Forbes' Portal fix
(https://bugs.freedesktop.org/show_bug.cgi?id=64253) into this release?
If so, we might want to delay a little, since I don't think that fix has
landed in master quite yet.


I think that will have to wait for 9.1.4.  It looks like we're finally 
doing releases at a reasonable rate, so this shouldn't be so bad.



Here are the commits that had conflicts that I didn't feel
comfortable trying to resolve:

c07c18081e3b21070c7db3aea0c7a3__1a31ff20ce wayland: fix segfault
when using software rendering
49c1fc7044eaaa5c2dca05ff4a709b__e8e3636871 r600g: don't emit
SQ_DYN_GPR_RESOURCE_LIMIT_1 on cayman
aa391976dfa12479185d9eeed1f2a0__b4dce6c49b intel: Allocate hiz in
intel_renderbuffer_move_to___temp()


This one turned out to be a fairly trivial merge conflict.  I'll verify
it on Gen6 and try to get it pushed to the 9.1 branch in an hour or two.

a8246927e35a49097f70cffb7fa8dd__05ec1365e1 r600g: Fix UMAD on Cayman
4c3ed795662974a1c2ad2326fc74be__f608a34f31 r600g: Workaround for a
harware bug with nested loops on Cayman

This series caused a few regressions in uniform array piglit tests:

740350c982bd2735b9eb9063c2b918__56b6f1ad31 i965: Make the fragment
shader pull constants index by dwords, not vec4s.
dca5fc14358a8b267b3854c39c976a__822885898f i965/fs: Improve
performance of varying-index uniform loads on IVB.
3cf69b228404791cf15231321b6a18__b5701be0a6 i965/fs: Bake
regs_written into the IR instead of recomputing it later.
70b27e0e4b5d15e575ea477d63c0f6__cb19d645c2 i965/fs: Use LD messages
for pre-gen7 varying-index uniform loads
62501c3af85089b423218a41a2e243__3ac849c2d3 i965/fs: Allow CSE on
pre-gen7 varying-index uniform loads
_
mesa-dev mailing list
mesa-dev@lists.freedesktop.org 
http://lists.freedesktop.org/__mailman/listinfo/mesa-dev





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

Re: [Mesa-dev] [PATCH] mesa: declare UniformBufferBindings as an array with a static size

[Ian Romanick]

On 05/14/2013 03:50 PM, Dave Airlie wrote:

On Wed, May 15, 2013 at 2:03 AM, Marek Olšák  wrote:

Some Gallium drivers were crashing, because the array was not large enough.

NOTE: This is a candidate for the stable branches.
---
  src/mesa/main/bufferobj.c  |   10 ++
  src/mesa/main/config.h |2 ++
  src/mesa/main/mtypes.h |3 ++-
  src/mesa/state_tracker/st_extensions.c |7 ---
  4 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 1566cb4..ffb67b9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -619,13 +619,10 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
 _mesa_reference_buffer_object(ctx, &ctx->CopyWriteBuffer,
   ctx->Shared->NullBufferObj);

-   ctx->UniformBufferBindings = calloc(ctx->Const.MaxUniformBufferBindings,
- sizeof(*ctx->UniformBufferBindings));
-
 _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
  ctx->Shared->NullBufferObj);

-   for (i = 0; i < ctx->Const.MaxUniformBufferBindings; i++) {
+   for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
_mesa_reference_buffer_object(ctx,
 
&ctx->UniformBufferBindings[i].BufferObject,
 ctx->Shared->NullBufferObj);
@@ -647,14 +644,11 @@ _mesa_free_buffer_objects( struct gl_context *ctx )

 _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);

-   for (i = 0; i < ctx->Const.MaxUniformBufferBindings; i++) {
+   for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
_mesa_reference_buffer_object(ctx,
 
&ctx->UniformBufferBindings[i].BufferObject,
 NULL);
 }
-
-   free(ctx->UniformBufferBindings);
-   ctx->UniformBufferBindings = NULL;
  }

  static bool
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index ea87b75..134c88a 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -168,6 +168,8 @@
  /*@{*/
  #define MAX_PROGRAM_LOCAL_PARAMS   4096
  #define MAX_UNIFORMS   4096
+/* 6 is for vertex, hull, domain, geometry, fragment, and compute shader. */
+#define MAX_COMBINED_UNIFORM_BUFFERS   (16 * 6)


Hmm softpipe currently says it has 32 per stage, so this won't scale
long term. How would it work if we report 32 per stage but limit the
max combined to 16*6, is some other code going to do the wrong thing


I'm not 100% sure that's okay.  I have some recollection (but I'll have 
to do spec archaeology) that MAX_COMBINED is eventually required to be 
the sum of all the other maximums... basically making it a useless 
query.  This was done because that's what everyone was already doing, 
and it's what apps were implicitly expecting.



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

Re: [Mesa-dev] [PATCH] mesa: declare UniformBufferBindings as an array with a static size

[Marek Olšák]

I think it would be better to change PIPE_MAX_CONSTANT_BUFFERS to 16,
because no API has more than 16 constant buffers to my knowledge.

Marek

On Wed, May 15, 2013 at 12:50 AM, Dave Airlie  wrote:
> On Wed, May 15, 2013 at 2:03 AM, Marek Olšák  wrote:
>> Some Gallium drivers were crashing, because the array was not large enough.
>>
>> NOTE: This is a candidate for the stable branches.
>> ---
>>  src/mesa/main/bufferobj.c  |   10 ++
>>  src/mesa/main/config.h |2 ++
>>  src/mesa/main/mtypes.h |3 ++-
>>  src/mesa/state_tracker/st_extensions.c |7 ---
>>  4 files changed, 10 insertions(+), 12 deletions(-)
>>
>> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
>> index 1566cb4..ffb67b9 100644
>> --- a/src/mesa/main/bufferobj.c
>> +++ b/src/mesa/main/bufferobj.c
>> @@ -619,13 +619,10 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
>> _mesa_reference_buffer_object(ctx, &ctx->CopyWriteBuffer,
>>   ctx->Shared->NullBufferObj);
>>
>> -   ctx->UniformBufferBindings = calloc(ctx->Const.MaxUniformBufferBindings,
>> - sizeof(*ctx->UniformBufferBindings));
>> -
>> _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
>>  ctx->Shared->NullBufferObj);
>>
>> -   for (i = 0; i < ctx->Const.MaxUniformBufferBindings; i++) {
>> +   for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
>>_mesa_reference_buffer_object(ctx,
>> 
>> &ctx->UniformBufferBindings[i].BufferObject,
>> ctx->Shared->NullBufferObj);
>> @@ -647,14 +644,11 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
>>
>> _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
>>
>> -   for (i = 0; i < ctx->Const.MaxUniformBufferBindings; i++) {
>> +   for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
>>_mesa_reference_buffer_object(ctx,
>> 
>> &ctx->UniformBufferBindings[i].BufferObject,
>> NULL);
>> }
>> -
>> -   free(ctx->UniformBufferBindings);
>> -   ctx->UniformBufferBindings = NULL;
>>  }
>>
>>  static bool
>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>> index ea87b75..134c88a 100644
>> --- a/src/mesa/main/config.h
>> +++ b/src/mesa/main/config.h
>> @@ -168,6 +168,8 @@
>>  /*@{*/
>>  #define MAX_PROGRAM_LOCAL_PARAMS   4096
>>  #define MAX_UNIFORMS   4096
>> +/* 6 is for vertex, hull, domain, geometry, fragment, and compute shader. */
>> +#define MAX_COMBINED_UNIFORM_BUFFERS   (16 * 6)
>
> Hmm softpipe currently says it has 32 per stage, so this won't scale
> long term. How would it work if we report 32 per stage but limit the
> max combined to 16*6, is some other code going to do the wrong thing
>
> Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: Don't spam "intelReadPixels: fallback to swrast" all the time.

[Kenneth Graunke]

Unless the application is using PBOs, any call to glReadPixels will hit
this message.  Hitting this does mean mapping the buffer and accessing
it via the CPU, but that isn't necessarily the worst thing in the world.

apitrace's image dumping code hits this path, causing it to spam
hundreds of thousands of performance warnings via ARB_debug_output,
which makes it difficult to see actual errors.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/intel/intel_pixel_read.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_read.c 
b/src/mesa/drivers/dri/intel/intel_pixel_read.c
index 6b715d0..dd482af 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_read.c
@@ -188,8 +188,6 @@ intelReadPixels(struct gl_context * ctx,
intel_prepare_render(intel);
intel->front_buffer_dirty = dirty;
 
-   perf_debug("%s: fallback to swrast\n", __FUNCTION__);
-
/* Update Mesa state before calling _mesa_readpixels().
 * XXX this may not be needed since ReadPixels no longer uses the
 * span code.
-- 
1.8.2.3

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

Re: [Mesa-dev] Mesa 9.1.3 soon?

[Armin K.]

On 05/15/2013 10:47 AM, EoD wrote:

On 13/05/13 21:02, Ian Romanick wrote:

I've just picked over a bunch of commits to the 9.1 branch.  There are a
few commits (some fairly old) that wouldn't pick cleanly.  Hopefully
someone that knows that code can either resolve the conflicts or add the
commit IDs to bin/.cherry-ignore.

I'd like to release this as 9.1.3 either later this week or early next
week.  Does that work for people?

Here are the commits that had conflicts that I didn't feel comfortable
trying to resolve:

c07c18081e3b21070c7db3aea0c7a31a31ff20ce wayland: fix segfault when
using software rendering
49c1fc7044eaaa5c2dca05ff4a709be8e3636871 r600g: don't emit
SQ_DYN_GPR_RESOURCE_LIMIT_1 on cayman
aa391976dfa12479185d9eeed1f2a0b4dce6c49b intel: Allocate hiz in
intel_renderbuffer_move_to_temp()
a8246927e35a49097f70cffb7fa8dd05ec1365e1 r600g: Fix UMAD on Cayman
4c3ed795662974a1c2ad2326fc74bef608a34f31 r600g: Workaround for a harware
bug with nested loops on Cayman

This series caused a few regressions in uniform array piglit tests:

740350c982bd2735b9eb9063c2b91856b6f1ad31 i965: Make the fragment shader
pull constants index by dwords, not vec4s.
dca5fc14358a8b267b3854c39c976a822885898f i965/fs: Improve performance of
varying-index uniform loads on IVB.
3cf69b228404791cf15231321b6a18b5701be0a6 i965/fs: Bake regs_written into
the IR instead of recomputing it later.
70b27e0e4b5d15e575ea477d63c0f6cb19d645c2 i965/fs: Use LD messages for
pre-gen7 varying-index uniform loads
62501c3af85089b423218a41a2e2433ac849c2d3 i965/fs: Allow CSE on pre-gen7
varying-index uniform loads
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Could those "Fix build with LLVM >= r180063" also go into the 9.1 branch?

ead4db420e9e5408f41c70768a290592a384aedb gallivm: Fix build with LLVM >=
r180063

a0c8942bb4742b4bd22f494cea4dcd59d9ca99ab radeon/llvm: Fix build with
LLVM >= r180063
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev



You need all of these to fix Mesa 9.1 build with LLVM 3.3 snapshot. And 
that's without r600 LLVM compiler and Clover state tracker. I guess 
they'd need even more.


http://cgit.freedesktop.org/mesa/mesa/patch/?id=ead4db420e9e5408f41c70768a290592a384aedb
http://cgit.freedesktop.org/mesa/mesa/patch/?id=4742f9b00b804dd01eb9955dd386a2373cd8eb36
http://cgit.freedesktop.org/mesa/mesa/patch/?id=6249db73ea580e6a54874235ffb3a7d42ac63bb4
http://cgit.freedesktop.org/mesa/mesa/patch/?id=7cd248aa7938a068663fcd605169b7d4e21636bf
http://cgit.freedesktop.org/mesa/mesa/patch/?id=a0c8942bb4742b4bd22f494cea4dcd59d9ca99ab
http://cgit.freedesktop.org/mesa/mesa/patch/?id=cd84353d576246273d1c6ae8e96b65217be15ebc

Given that none of them applies cleanly, and I've only build tested 
them, I don't think it's a good idea to support LLVM 3.3 in 9.1 branch.

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

Re: [Mesa-dev] [PATCH] clover: Support multiple devices in clCreateContextFromType()

[Francisco Jerez]

Tom Stellard  writes:

> From: Tom Stellard 
>
Hi Tom.  This should probably leave out any devices that don't match the
type argument.  To avoid duplicating the type-matching logic I think the
best would be to keep it implemented in terms of clGetDeviceIDs, just
call it twice to get the number of vector elements you need to allocate.

> ---
>  src/gallium/state_trackers/clover/api/context.cpp | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/context.cpp 
> b/src/gallium/state_trackers/clover/api/context.cpp
> index 3717441..e0fed31 100644
> --- a/src/gallium/state_trackers/clover/api/context.cpp
> +++ b/src/gallium/state_trackers/clover/api/context.cpp
> @@ -22,6 +22,7 @@
>  
>  #include "api/util.hpp"
>  #include "core/context.hpp"
> +#include "core/platform.hpp"
>  
>  using namespace clover;
>  
> @@ -63,18 +64,22 @@ clCreateContextFromType(const cl_context_properties 
> *props,
>  void *user_data, cl_int *errcode_ret) try {
> cl_platform_id platform;
> cl_uint num_platforms;
> -   cl_device_id dev;
> cl_int ret;
> +   std::vector devs;
>  
> ret = clGetPlatformIDs(1, &platform, &num_platforms);
> if (ret || !num_platforms)
>throw error(CL_INVALID_PLATFORM);
>  
> -   ret = clGetDeviceIDs(platform, type, 1, &dev, 0);
> -   if (ret)
> +   if (platform->begin() == platform->end())
>throw error(CL_DEVICE_NOT_FOUND);
>  
> -   return clCreateContext(props, 1, &dev, pfn_notify, user_data, 
> errcode_ret);
> +   for (clover::platform::iterator i = platform->begin(), e = 
> platform->end();
> + i != e; ++i) {
> +  devs.push_back(&*i);
> +   }
> +
> +   return clCreateContext(props, devs.size(), devs.data(), pfn_notify, 
> user_data, errcode_ret);
>  
>  } catch(error &e) {
> ret_error(errcode_ret, e);


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

Re: [Mesa-dev] Mesa 9.1.3 soon?

[EoD]

On 13/05/13 21:02, Ian Romanick wrote:
> I've just picked over a bunch of commits to the 9.1 branch.  There are a
> few commits (some fairly old) that wouldn't pick cleanly.  Hopefully
> someone that knows that code can either resolve the conflicts or add the
> commit IDs to bin/.cherry-ignore.
> 
> I'd like to release this as 9.1.3 either later this week or early next
> week.  Does that work for people?
> 
> Here are the commits that had conflicts that I didn't feel comfortable
> trying to resolve:
> 
> c07c18081e3b21070c7db3aea0c7a31a31ff20ce wayland: fix segfault when
> using software rendering
> 49c1fc7044eaaa5c2dca05ff4a709be8e3636871 r600g: don't emit
> SQ_DYN_GPR_RESOURCE_LIMIT_1 on cayman
> aa391976dfa12479185d9eeed1f2a0b4dce6c49b intel: Allocate hiz in
> intel_renderbuffer_move_to_temp()
> a8246927e35a49097f70cffb7fa8dd05ec1365e1 r600g: Fix UMAD on Cayman
> 4c3ed795662974a1c2ad2326fc74bef608a34f31 r600g: Workaround for a harware
> bug with nested loops on Cayman
> 
> This series caused a few regressions in uniform array piglit tests:
> 
> 740350c982bd2735b9eb9063c2b91856b6f1ad31 i965: Make the fragment shader
> pull constants index by dwords, not vec4s.
> dca5fc14358a8b267b3854c39c976a822885898f i965/fs: Improve performance of
> varying-index uniform loads on IVB.
> 3cf69b228404791cf15231321b6a18b5701be0a6 i965/fs: Bake regs_written into
> the IR instead of recomputing it later.
> 70b27e0e4b5d15e575ea477d63c0f6cb19d645c2 i965/fs: Use LD messages for
> pre-gen7 varying-index uniform loads
> 62501c3af85089b423218a41a2e2433ac849c2d3 i965/fs: Allow CSE on pre-gen7
> varying-index uniform loads
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Could those "Fix build with LLVM >= r180063" also go into the 9.1 branch?

ead4db420e9e5408f41c70768a290592a384aedb gallivm: Fix build with LLVM >=
r180063

a0c8942bb4742b4bd22f494cea4dcd59d9ca99ab radeon/llvm: Fix build with
LLVM >= r180063
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev