[Mesa-dev] brw_context::upload questions

[Rogovin, Kevin]

Hi all,

  I was poking through the code tracking what is happening to 
brw_context::upload.bo, and it left me scrathing me head. As Paul Berry told 
me, I see that is used to just store client side index and vertex buffers 
(copied to it essentially be copy_array_to_vbo_array() and 
brw_upload_indices()), but the reference counting on it has me royally confused:

I see that intel_upload_data() adds a reference and returns it via  
return_bo. Now,  brw_upload_indices() will remove a reference as well, so the 
effect is that it will not change the reference count. On the other hand,  
copy_array_to_vbo_array() calls intel_upload_data() but does not unreference 
it, so that leaves the reference counted incremented by one [or it can do 
map/unmap which also leave the reference one higher as well].

Finally, I get to my question, in intel_upload_finish(), the reference count is 
decremented after an upload via drm. It looks to me like that then, if an 
application chooses to source from client side for indices but use buffer 
object vertices, then the upload.bo will get killed off on intel_upload(), and 
thus if a command refers to it, it refers to a dead bo.

What am I missing?

Also, why is not this kind of thing handled in the VBO module where the VBO 
module tracks if data is backed by a buffer object or not and use the driver 
interface to manage it? That way any driver could just assume that all index 
and vertex data is backed by a buffer object and potentially simplify the code.

-Kevin

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

Re: [Mesa-dev] [PATCH 1/5] glsl: Move the CSE equality functions to the ir class.

[Pohjolainen, Topi]

On Thu, Nov 07, 2013 at 01:58:57PM -0800, Eric Anholt wrote:
 I want to reuse them in opt_algebraic.
 ---
  src/glsl/Makefile.sources |   1 +
  src/glsl/ir.h |  22 ++
  src/glsl/ir_equals.cpp| 196 
 ++
  src/glsl/opt_cse.cpp  | 178 +
  4 files changed, 220 insertions(+), 177 deletions(-)
  create mode 100644 src/glsl/ir_equals.cpp
 
 diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
 index 2aabc05..43f122b 100644
 --- a/src/glsl/Makefile.sources
 +++ b/src/glsl/Makefile.sources
 @@ -33,6 +33,7 @@ LIBGLSL_FILES = \
   $(GLSL_SRCDIR)/ir_clone.cpp \
   $(GLSL_SRCDIR)/ir_constant_expression.cpp \
   $(GLSL_SRCDIR)/ir.cpp \
 + $(GLSL_SRCDIR)/ir_equals.cpp \
   $(GLSL_SRCDIR)/ir_expression_flattening.cpp \
   $(GLSL_SRCDIR)/ir_function_can_inline.cpp \
   $(GLSL_SRCDIR)/ir_function_detect_recursion.cpp \
 diff --git a/src/glsl/ir.h b/src/glsl/ir.h
 index 2f06fb9..7859702 100644
 --- a/src/glsl/ir.h
 +++ b/src/glsl/ir.h
 @@ -139,6 +139,16 @@ public:
 virtual class ir_jump *  as_jump() { return NULL; 
 }
 /*@}*/
  
 +   /**
 +* IR equality method: Return true if the referenced instruction would
 +* return the same value as this one.
 +*
 +* This intended to be used for CSE and algebraic optimizations, on 
 rvalues
 +* in particular.  No support for other instruction types (assignments,
 +* jumps, calls, etc.) is planned.
 +*/
 +   virtual bool equals(ir_instruction *ir);
 +
  protected:
 ir_instruction()
 {
 @@ -1405,6 +1415,8 @@ public:
return this;
 }
  
 +   virtual bool equals(ir_instruction *ir);
 +
 virtual ir_expression *clone(void *mem_ctx, struct hash_table *ht) const;
  
 /**
 @@ -1739,6 +1751,8 @@ public:
  
 virtual ir_visitor_status accept(ir_hierarchical_visitor *);
  
 +   virtual bool equals(ir_instruction *ir);
 +
 /**
  * Return a string representing the ir_texture_opcode.
  */
 @@ -1843,6 +1857,8 @@ public:
  
 virtual ir_visitor_status accept(ir_hierarchical_visitor *);
  
 +   virtual bool equals(ir_instruction *ir);
 +
 bool is_lvalue() const
 {
return val-is_lvalue()  !mask.has_duplicates;
 @@ -1907,6 +1923,8 @@ public:
return this;
 }
  
 +   virtual bool equals(ir_instruction *ir);
 +
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 @@ -1965,6 +1983,8 @@ public:
return this;
 }
  
 +   virtual bool equals(ir_instruction *ir);
 +
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 @@ -2099,6 +2119,8 @@ public:
  
 virtual ir_visitor_status accept(ir_hierarchical_visitor *);
  
 +   virtual bool equals(ir_instruction *ir);
 +
 /**
  * Get a particular component of a constant as a specific type
  *
 diff --git a/src/glsl/ir_equals.cpp b/src/glsl/ir_equals.cpp
 new file mode 100644
 index 000..0b28b39
 --- /dev/null
 +++ b/src/glsl/ir_equals.cpp
 @@ -0,0 +1,196 @@
 +/*
 + * Copyright © 2013 Intel Corporation
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the Software),
 + * to deal in the Software without restriction, including without limitation
 + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice (including the next
 + * paragraph) shall be included in all copies or substantial portions of the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 + * DEALINGS IN THE SOFTWARE.
 + */
 +
 +#include ir.h
 +
 +/**
 + * Helper for checking equality when one instruction might be NULL, since you
 + * can't a's vtable in that case.
   ^
I guess there is a verb missing here?

 + */
 +static bool
 +possibly_null_equals(ir_instruction *a, ir_instruction *b)
 +{
 +   if (!a || !b)
 +  return !a  !b;
 +
 +   return a-equals(b);
 +}
 +
 +/**
 + * The base equality function: Return not equal for anything we don't know
 + * about.
 + */
 +bool
 +ir_instruction::equals(ir_instruction *ir)
 +{
 +   return false;
 +}
 +
 +bool
 +ir_constant::equals(ir_instruction *ir)
 +{
 +   const ir_constant *other = ir-as_constant();
 +   if (!other)
 +  return 

Re: [Mesa-dev] [PATCH 08/18] i965: Wire up initial support for DRI_RENDERER_QUERY extension

[Daniel Vetter]

On Thu, Nov 07, 2013 at 04:23:12PM -0800, Ian Romanick wrote:
 On 11/07/2013 01:33 PM, Daniel Vetter wrote:
  On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
  +  /* Once a batch uses more than 75% of the maximum mappable size, we
  +   * assume that there's some fragmentation, and we start doing extra
  +   * flushing, etc.  That's the big cliff apps will care about.
  +   *
  +   * Can only map 2G onto the GPU through the GTT.
  +   */
  +  const unsigned gpu_mappable_megabytes = 2 * 1024 * 3 / 4;
  
  We have an ioctl to tell you that, since it's not really 2G on really
  old stuff. And will probably change on newer platforms. Also, using
  that ioctl allows the kernel to limit your usage in case the available
  ram is less than the virtual size of the gtt (atm we don't bother with
  that much cleverness, but probably will in the future). See
  DRM_IOCTL_I915_GEM_GET_APERTURE in libdrm (it's unfortunately not
  exposed through any libdrm function afaics.
 
 This only does GEN4+.  i915 and earlier chips are handled in the
 previous patch, which uses drmAgpSize.  Should that be used here too?

Oops, didn't spot that. But still original gen4 has only 512M and if you
look sharply at the bdw code you'll see it currently claims 4G, with
promise for more (64b relocs and all). The ioctl also gives you the size
in u64, so it's future-proof.

Also wrt drmAgpSize for gen2/3 that's the wrong size - it uses the
horribly agp legacy crap we unfortunately still have hanging around due to
XvMC bogosity on gen3. But already on gen2 and some gen3 where we don't
care this won't work and 3.14 has a patch from Ville to disable it
everywhere. So that needs to change to the gem aperture ioctl, too.

That agp layer desperately needs to die, so please don't add new uses to
extend its lifetime for another 5 years ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Request for fedback

[Rogovin, Kevin]

Hello all,

  I have been going through the Mesa source code, generating doxy-text with the 
goal to make getting started in Mesa faster.

 Chad has setup a public site so that anyone can see the doxygen generated 
content at:

http://people.freedesktop.org/~chadversary/mesa/doxygen/kevin-rogovin/

Currently the following modules are documented:
 - src/mesa/main (Mesa main)
 - src/mesa/vbo (VBO)

documentation of i965 is ongoing (there are a lot of files to read), and other 
modules (egl, gbm, glsl, glx, mapi, math, program, tnl and swrast have either 
nothing or just the original doxygen-page file). My eventual goal is to have 
gbm, glsl, mapi and program well documented as well. The math module is mostly 
for compatibility and ES1, so it is on severe back burner (and is more or less 
very straightforward) and the tnl and swrast modules, although small, are also 
at the bottom of priority.

At any rate, I would greatly appreciate feedback for the MesaMain and VBO 
modules. In particular error correction and suggestions for additions. As one 
caveat, I do confess that I am not really going to take a great deal of effort 
documenting code that is for compatibility profile only, or for that matter for 
GLES1.x only.

Best Regards
 -Kevin Rogovin


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

[Mesa-dev] CACHED_BATCH questions

[Rogovin, Kevin]

Hi all,

  I am trying to get my head around CACHED_BATCH() which is just a macro for   
intel_batchbuffer_cached_advance(), and when I dig into that code it leaves me 
some head scratching. I am guessing it checks if the current contents of the 
batch buffer already have command and if so, to skip sending that command. In 
this case, the commands match if essentially all the bytes match. I think the 
mechanics are by setting batch.used to batch.emit to skip sending the command. 
If the item was not found to then save the location in the batch buffer with a 
cached_batch_item object. If the op code was found, but contents different, 
then the command gets emitted anyways and the cache entry updated. So, that 
makes sense, but:

Why bother? the size of the cached batches does not look very big (the biggest 
one I found where 30-something for polygon stipple [upload_polygon_stipple()] 
and something that I guess is no more than 1+2N, where N is the number of 
vertex attributes (I think this is 16) for the vertex sources [ 
brw_emit_vertices() ]. Worse, the looking up of going through the cache looks 
more inefficient time-wise than just adding those bytes. Also, all the uses in 
an atom thing should not happen I'd guess because they check their dirty flags 
to decide weather or not to emit. That essentially leaves what happens in 
brw_emit_vertices(), which I'd think would also be saving the attribute source 
state.

On a related question, I see in brw_emit_vertices(), a BEGIN_BATCH(1 + 
nr_elements * 2) followed by a for-loop of length nr_elements that for each 
iteration does OUT_BATCH twice, but then there are some if's which also do 
OUT_BATCH, without a BEGIN_BATCH before hand, so it looks like that those last 
maybe OUT_BATCHES (two for each if-block) could be naughty. What am I missing?

-Kevin



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

[Mesa-dev] [PATCH 2/2] Check access to vec4_visitor's arrays

[Petri Latvala]

Protect access to vec4_visitor's uniform_size and uniform_vector_size arrays
by asserting the index used.

Signed-off-by: Petri Latvala petri.latv...@intel.com
---
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 +++
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 ++
 src/mesa/drivers/dri/i965/brw_vec4_vp.cpp  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 20fbd45..8912198 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -372,6 +372,7 @@ vec4_visitor::split_uniform_registers()
   }
}
 
+   assert(this-uniforms  MAX_UNIFORMS * 4);
/* Update that everything is now vector-sized. */
for (int i = 0; i  this-uniforms; i++) {
   this-uniform_size[i] = 1;
@@ -409,6 +410,7 @@ vec4_visitor::pack_uniform_registers()
/* Now, figure out a packing of the live uniform vectors into our
 * push constants.
 */
+   assert(uniforms  MAX_UNIFORMS * 4);
for (int src = 0; src  uniforms; src++) {
   int size = this-uniform_vector_size[src];
 
@@ -445,6 +447,7 @@ vec4_visitor::pack_uniform_registers()
}
 
this-uniforms = new_uniform_count;
+   assert(this-uniforms  MAX_UNIFORMS * 4);
 
/* Now, update the instructions for our repacked uniforms. */
foreach_list(node, this-instructions) {
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index a036e2d..46fd8dc 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -663,6 +663,7 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
storage-type-matrix_columns);
 
   for (unsigned s = 0; s  vector_count; s++) {
+ assert(uniforms  MAX_UNIFORMS * 4);
  uniform_vector_size[uniforms] = storage-type-vector_elements;
 
  int i;
@@ -686,6 +687,7 @@ vec4_visitor::setup_uniform_clipplane_values()
gl_clip_plane *clip_planes = brw_select_clip_planes(ctx);
 
for (int i = 0; i  key-nr_userclip_plane_consts; ++i) {
+  assert(this-uniforms  MAX_UNIFORMS * 4);
   this-uniform_vector_size[this-uniforms] = 4;
   this-userplane[i] = dst_reg(UNIFORM, this-uniforms);
   this-userplane[i].type = BRW_REGISTER_TYPE_F;
@@ -716,6 +718,7 @@ vec4_visitor::setup_builtin_uniform_values(ir_variable *ir)
(gl_state_index *)slots[i].tokens);
   float *values = this-prog-Parameters-ParameterValues[index][0].f;
 
+  assert(this-uniforms  MAX_UNIFORMS * 4);
   this-uniform_vector_size[this-uniforms] = 0;
   /* Add each of the unique swizzled channels of the element.
* This will end up matching the size of the glsl_type of this field.
@@ -726,6 +729,7 @@ vec4_visitor::setup_builtin_uniform_values(ir_variable *ir)
 last_swiz = swiz;
 
 prog_data-param[this-uniforms * 4 + j] = values[swiz];
+assert(this-uniforms  MAX_UNIFORMS * 4);
 if (swiz = last_swiz)
this-uniform_vector_size[this-uniforms]++;
   }
@@ -984,6 +988,7 @@ vec4_visitor::visit(ir_variable *ir)
   /* Track how big the whole uniform variable is, in case we need to put a
* copy of its data into pull constants for array access.
*/
+  assert(this-uniforms  MAX_UNIFORMS * 4);
   this-uniform_size[this-uniforms] = type_size(ir-type);
 
   if (!strncmp(ir-name, gl_, 3)) {
@@ -3198,6 +3203,7 @@ 
vec4_visitor::move_uniform_array_access_to_pull_constants()
 
pull_constant_loc[uniform] = prog_data-nr_pull_params / 4;
 
+   assert(uniform  MAX_UNIFORMS * 4);
for (int j = 0; j  uniform_size[uniform] * 4; j++) {
   prog_data-pull_param[prog_data-nr_pull_params++]
   = values[j];
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp
index 1f3d75c..bb31e93 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp
@@ -443,6 +443,7 @@ vec4_vs_visitor::setup_vp_regs()
*/
   assert(components = 4);
 
+  assert(this-uniforms  MAX_UNIFORMS * 4);
   this-uniform_size[this-uniforms] = 1; /* 1 vec4 */
   this-uniform_vector_size[this-uniforms] = components;
   for (unsigned i = 0; i  4; i++) {
-- 
1.8.4.rc3

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

Re: [Mesa-dev] [PATCH 2/2 v3] i965: Enhance tiled_memcpy to support all levels

[gurketsky]

On 07.11.2013 23:01, Courtney Goeltzenleuchter wrote:
 Support all levels of a supported texture format.

 Using 1024x1024, RGBA  source, mipmap
   THIS PATCH
 internal-format   Before (MB/sec) XRGB (MB/sec)   mipmap (MB/sec)
 GL_RGBA   628.15  627.15  615.90
 GL_RGB265.95  456.35  611.53
 512x512
 GL_RGBA   600.23  597.00  619.95
 GL_RGB255.50  440.62  611.28
 256x256
 GL_RGBA   489.08  487.80  587.42
 GL_RGB229.03  376.63  585.00

 Test shows similar pattern for 512x512 and 256x256.

 Benchmark has been sent to mesa-dev list: teximage_enh

 Courtney Goeltzenleuchter (2):
   i965: add XRGB to tiled_memcpy
   i965: Enhance tiled_memcpy to support all levels

  src/mesa/drivers/dri/i965/intel_tex_subimage.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

 --
 1.8.1.2

 Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
 ---
  src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
 b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 index b1826fa..b32af3d 100644
 --- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 +++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 @@ -543,7 +543,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 uint32_t cpp;
 mem_copy_fn mem_copy = NULL;
  
 -   /* This fastpath is restricted to specific texture types: level 0 of
 +   /* This fastpath is restricted to specific texture types:
  * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to support
  * more types.
  *
 @@ -555,7 +555,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 if (!brw-has_llc ||
 type != GL_UNSIGNED_BYTE ||
 texImage-TexObject-Target != GL_TEXTURE_2D ||
 -   texImage-Level != 0 ||
 pixels == NULL ||
 _mesa_is_bufferobj(packing-BufferObj) ||
 packing-Alignment  4 ||
 @@ -572,7 +571,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
cpp = 1;
mem_copy = memcpy;
 } else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
 - || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
 +|| (texImage-TexFormat == MESA_FORMAT_XRGB)) {
This change is not really necessary. If it needs to be fixed, it should
be done correctly in patch 1/2.

cpp = 4;
if (format == GL_BGRA) {
   mem_copy = memcpy;
 @@ -631,6 +630,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 packing-Alignment, packing-RowLength, packing-SkipPixels,
 packing-SkipRows, for_glTexImage);
  
 +   /* Adjust x and y offset based on miplevel
 +*/
 +   xoffset += image-mt-level[texImage-Level].level_x;
 +   yoffset += image-mt-level[texImage-Level].level_y;
 +
 linear_to_tiled(
xoffset * cpp, (xoffset + width) * cpp,
yoffset, yoffset + height,

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

[Mesa-dev] [PATCH 0/2] Fix array overrun on too many uniforms

[Petri Latvala]

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

vec4_visitor has two arrays, uniform_size and
uniform_vector_size. Their size is set to MAX_UNIFORMS, which is the
number of uniform vec4s. The size should be the number of uniform
components instead.

When testing this fix (testcase shader attached in the bug), you'll
need to set the stack limit to bigger than the default 8MB. 16MB was
enough for the testcase shader. I verified that with this fix correct
error message is given with 17000 uniforms, and compiling a shader
with 15000 uniforms works, although it took 5 minutes to compile.

Petri Latvala (2):
  Increase array sizes to what they should be.
  Check access to vec4_visitor's arrays

 src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 +++
 src/mesa/drivers/dri/i965/brw_vec4.h   | 4 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 ++
 src/mesa/drivers/dri/i965/brw_vec4_vp.cpp  | 1 +
 4 files changed, 12 insertions(+), 2 deletions(-)

-- 
1.8.4.rc3

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

[Mesa-dev] Batchbuffer question

[Rogovin, Kevin]

Hi all,

 As I was poking into the magicks for the batchbuffer, I saw the following 
logical bits of code, that make sense by themselves but get me paranoid 
together. Firstly in intel_batchbuffer_begin() [ intel_batchbuffer.h, and this 
is what BEGIN_BATCH maps to] there is a intel_batchbuffer_require_space() call 
that if too much room is needed then calls intel_batchbuffer_begin():

from intel_batchbuffer_require_space():

  115if (intel_batchbuffer_space(brw)  sz)
  116   intel_batchbuffer_flush(brw);

and from intel_batchbuffer_space():

   80 intel_batchbuffer_space(struct brw_context *brw)
   81 {
   82return (brw-batch.state_batch_offset - brw-batch.reserved_space)
   83   - brw-batch.used*4;
   84 }


Now, for allocating space for state, there is brw_state_batch():


  128offset = ROUND_DOWN_TO(batch-state_batch_offset - size, alignment);
  129
  130/* If allocating from the top would wrap below the batchbuffer, or
  131 * if the batch's used space (plus the reserved pad) collides with our
  132 * space, then flush and try again.
  133 */
  134if (batch-state_batch_offset  size ||
  135offset  4*batch-used + batch-reserved_space) {
  136   intel_batchbuffer_flush(brw);
  137   offset = ROUND_DOWN_TO(batch-state_batch_offset - size, alignment);
  138}


These taken together, I interpret as meaning that state and commands try to be 
separated by atleast batch-reserved_space bytes. I guess state could take up 
more than (batch-bo-size - batch-reserved_space) from that second 
ROUND_DOWN_TO, but that would only happen right after a flush and any state or 
command afterwards would flush too.

Now my questions:
  1) it looks like the reserved space is not to be used for either state or 
commands. Is that correct? What is it used for?

  2) if a function first calls brw_state_batch() to place state and it barely 
fits and then calls BEGIN_BATCH that does not fit, then the command will refer 
to an offset on the previous batch buffer, that cannot be good. Or does this 
never happen for other reasons? If so what are those reasons?


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

[Mesa-dev] [PATCH 1/2] Increase array sizes to what they should be.

[Petri Latvala]

vec4_visitor's uniform_size and uniform_vector_size arrays contain
information about uniforms. Their size should be the number of uniform
components (MAX_UNIFORMS * 4) instead of number of uniform vec4s
(MAX_UNIFORMS).

Signed-off-by: Petri Latvala petri.latv...@intel.com
---
 src/mesa/drivers/dri/i965/brw_vec4.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 1f29e57..5b7d4b6 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -325,8 +325,8 @@ public:
 */
dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
-   int uniform_size[MAX_UNIFORMS];
-   int uniform_vector_size[MAX_UNIFORMS];
+   int uniform_size[MAX_UNIFORMS * 4];
+   int uniform_vector_size[MAX_UNIFORMS * 4];
int uniforms;
 
src_reg shader_start_time;
-- 
1.8.4.rc3

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

Re: [Mesa-dev] [PATCH] glx/dri: fix assorted compiler warnings/errors

[Jose Fonseca]

Looks good to me AFAICT.

I had independently pushed a fix similar to the first chunk in your patch.  I 
think it matches your's verbatim so there should be no conflict when you rebase.

Jose

- Original Message -
 From: Brian Paul bri...@vmware.com
 
 To fix fall-out from recent commits.
 ---
  .../state_trackers/dri/common/dri_context.h|1 +
  src/glx/dri2.h |2 ++
  src/glx/glxclient.h|2 +-
  src/glx/query_renderer.c   |2 +-
  src/mesa/drivers/dri/swrast/swrast.c   |1 +
  5 files changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/src/gallium/state_trackers/dri/common/dri_context.h
 b/src/gallium/state_trackers/dri/common/dri_context.h
 index b87ce40..56dfa2c 100644
 --- a/src/gallium/state_trackers/dri/common/dri_context.h
 +++ b/src/gallium/state_trackers/dri/common/dri_context.h
 @@ -89,6 +89,7 @@ dri_create_context(gl_api api,
  unsigned major_version,
  unsigned minor_version,
  uint32_t flags,
 +bool notify_reset,
  unsigned *error,
  void *sharedContextPrivate);
  

 diff --git a/src/glx/dri2.h b/src/glx/dri2.h
 index c404a3a..90efde8 100644
 --- a/src/glx/dri2.h
 +++ b/src/glx/dri2.h
 @@ -45,6 +45,8 @@ typedef struct
 unsigned int flags;
  } DRI2Buffer;
  
 +struct glx_screen;
 +
  extern Bool
  DRI2QueryExtension(Display * display, int *eventBase, int *errorBase);
  
 diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
 index 7363327..257728d 100644
 --- a/src/glx/glxclient.h
 +++ b/src/glx/glxclient.h
 @@ -476,7 +476,7 @@ struct glx_screen_vtable {
unsigned *error);
 int (*query_renderer_integer)(struct glx_screen *psc,
   int attribute,
 - int *value);
 + unsigned int *value);
 int (*query_renderer_string)(struct glx_screen *psc,
  int attribute,
  const char **value);
 diff --git a/src/glx/query_renderer.c b/src/glx/query_renderer.c
 index 981a844..9108ec2 100644
 --- a/src/glx/query_renderer.c
 +++ b/src/glx/query_renderer.c
 @@ -30,7 +30,7 @@ __glXQueryRendererInteger(struct glx_screen *psc, int
 attribute,
unsigned int *value)
  {
 unsigned int values_for_query = 0;
 -   int buffer[32];
 +   unsigned int buffer[32];
 int err;
  
 /* This probably means the caller is trying to use an extension function
 diff --git a/src/mesa/drivers/dri/swrast/swrast.c
 b/src/mesa/drivers/dri/swrast/swrast.c
 index bfa2efd..c062071 100644
 --- a/src/mesa/drivers/dri/swrast/swrast.c
 +++ b/src/mesa/drivers/dri/swrast/swrast.c
 @@ -664,6 +664,7 @@ dri_create_context(gl_api api,
  unsigned major_version,
  unsigned minor_version,
  uint32_t flags,
 +bool notify_reset,
  unsigned *error,
  void *sharedContextPrivate)
  {
 --
 1.7.9.5
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v2 4/6] glsl: ir_deserializer class for the shader cache

[Tapani Pälli]

On 11/05/2013 10:16 PM, Paul Berry wrote:
On 1 November 2013 02:16, Tapani Pälli tapani.pa...@intel.com 
mailto:tapani.pa...@intel.com wrote:


ir_deserializer can create a gl_shader structure out of binary
data from ir_serializer, will be used by OES_get_program_binary
implementation.

Signed-off-by: Tapani Pälli tapani.pa...@intel.com
mailto:tapani.pa...@intel.com
---
 src/glsl/Makefile.sources  |1 +
 src/glsl/ir_cache_deserializer.cpp | 1341

 src/glsl/ir_cache_deserializer.h   |  301 
 3 files changed, 1643 insertions(+)
 create mode 100644 src/glsl/ir_cache_deserializer.cpp
 create mode 100644 src/glsl/ir_cache_deserializer.h


General comment: my attitude about error handling is different when 
reviewing this patch than it was when reviewing the last patch, 
because in the case of deserialization, we're dealing with data passed 
in by the client, so I think it's far more important to be robust in 
the case of malformed input data.  We probably don't need to worry 
about malicious clients, since the client is in process so if they 
wanted to be malicious they could just walk all over memory.  But it 
will make life a lot easier for library clients (and for us when we're 
debugging) if we can avoid having Mesa die in a fire when it receives 
a corrupted shader binary.




Yes, I agree, it makes sense to have some more error checking in 
deserialization, it has to be basic and quick though.


Having said that, I still don't think integer return values are the 
way to go, for the following reasons:

- it's confusing for 0 to mean success.
- we're going to forget to check return values.
- it complicates the signatures of a lot of functions that should be 
able to just return the thing that they read.


What I'd recommend doing instead is adding a failed boolean to 
memory_map.  That way rather than having to check every single return 
value for failure, we just have to check the failed boolean at 
appropriate critical times (such as inside loops and at the end of 
functions like ir_read_variable()), and return early in the event of 
failure.  An additional advantage of this is that it makes it easy to 
add bounds checking to memory_map--the read() and ffwd() functions can 
simply check if the position goes out of bounds, and if so, set 
failed flag to 0 and read zeros.


ok, I'll take a look how this would work out. The current checks have 
actually helped as they catch not just invalid/corrupt data from client 
but possible errors in serialization too, even though they are just 
simple value checks but there's quite a lot of them and they help in 
stopping the parsing immediately. If allowed to go further after error, 
it'll be harder to track when did it start to fail so I think there will 
be still a lot of checks.



+ir_deserializer::read_header(struct gl_shader *shader, memory_map
map,
+   const char *mesa_sha)


Rather than pass the memory_map to all of the ir_deserializer 
functions, I'd prefer to see it just be a member of the 
ir_deserializer class.  It's a closer parallel to what you do with 
memory_writer in ir_serializer, and it makes the code easier to read 
by making all of the function signatures and invocations smaller.


Yep, I think it can be changed, the actual memory_map will come from 
caller of this class. I think read_glsl_type() is the only method which 
will require support to pass a memory_map, this is used when reading 
uniform_storage when deserializing a whole pgoram.


As with the memory_writer::write*() functions, I think the 
memory_map::read() functions should include the type in their name, 
and should use return by value rather than a pointer argument.  E.g.:


int32_t read_int32();
bool read_bool();

and so on.

(Note: I think it's still ok to have a read() function that operates 
on a pointer for reading larger structs).


Yes, will change these.



Although technically the C standard allows locals whose name begin 
with an underscore (provided that what follows is a lower case 
letter), it seems strange--names beginning with underscores typically 
refer to globals that belong to libraries.


Also, it looks like all the callers of read_glsl_type pass this-state 
for this parameter, so I don't understand why the parameter is needed 
at all.


Yes, it is possible that in some of calls it might not be explicitly 
needed parameter, read_glsl_type must support also situation where we 
don't have state, this is used when reading uniform_storage.



+{
+   uint32_t type_size;
+
+   char *name = map.read_string();
+   map.read(type_size);
+
+   const glsl_type *type_exists = NULL;


type_exists sounds like the name of a boolean.  Can we rename this 
to existing_type?


ok


+
+   if (_state  _state-symbols)
+  type_exists = _state-symbols-get_type(name);


I don't see any circumstances where _state or 

Re: [Mesa-dev] dri3proto requirement (Was: Add DRI3+Present loader)

[Brian Paul]

On 11/08/2013 05:25 AM, Jose Fonseca wrote:

This change seems makes dri3proto a hard requirement to build with automake.  
Is that strictly necessary?  I tried to find ubuntu packages for it to install 
on my build slave, but it doesn't seem they exist yet.


There's also a dependency on a new libxshmfence library, which I found 
by googling, but doesn't build on my Mint system (some sort of libtool 
problem - ugh).


Can all the new DRI3 stuff be put behind some sort of config option?

Let's try to fix this ASAP, please.

-Brian






Jose

- Original Message -

Module: Mesa
Branch: master
Commit: 2d94601582e4f0fcaf8c02a15b23cba39dec7bb1
URL:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D2d94601582e4f0fcaf8c02a15b23cba39dec7bb1k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=SO%2B7OlHXbokI6imwepItT9yNpAUWwJbaEKhKb0wNP9w%3D%0As=4954ad78ce9f075774d2527774e6def7bbfad3a42c0f4c9a99319895658448c2

Author: Keith Packard kei...@keithp.com
Date:   Mon Nov  4 18:15:51 2013 -0800

Add DRI3+Present loader

Uses the __DRIimage loader interfaces.

v2: Fix _XIOErrors when DRI3 isn't present (change by anholt).  Apparently
 XCB just terminates your connection if you don't check for extensions
 before using them, instead of returning an error like you'd expect.

Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
Reviewed-by: Eric Anholt e...@anholt.net

---

  configure.ac  |   12 +-
  src/glx/Makefile.am   |2 +
  src/glx/dri3_common.c |  146 
  src/glx/dri3_glx.c| 1831
  +
  src/glx/dri3_priv.h   |  209 ++
  src/glx/glxclient.h   |2 +
  src/glx/glxext.c  |6 +-
  7 files changed, 2204 insertions(+), 4 deletions(-)

Diff:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/diff/?id%3D2d94601582e4f0fcaf8c02a15b23cba39dec7bb1k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=SO%2B7OlHXbokI6imwepItT9yNpAUWwJbaEKhKb0wNP9w%3D%0As=fef0d7d9901b79c9c42049b0570131a0a2eab324c676302f57eb2677998e1dc3
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-commitk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=SO%2B7OlHXbokI6imwepItT9yNpAUWwJbaEKhKb0wNP9w%3D%0As=e3eaebc7aa81154fb9264da77eb272c2eea2cff836c8b8c3ed6c91102bb09065


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=SO%2B7OlHXbokI6imwepItT9yNpAUWwJbaEKhKb0wNP9w%3D%0As=cba62b848b56c0d2b4561775fb7023da0d0880705e6d646735a057805107dc96



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

Re: [Mesa-dev] [PATCH] glx: Fix scons build.

[Brian Paul]

On 11/08/2013 10:55 AM, jfons...@vmware.com wrote:

From: José Fonseca jfons...@vmware.com

By disabling DRI3 support for the time being.

I'll add DRI3 support to scons build when the DRI3 dependencies become
more widely available (as now there is no convenient way of testing it
except building dependencies from source).
---
  src/glx/SConscript | 6 ++
  src/glx/glxext.c   | 2 ++
  2 files changed, 8 insertions(+)

diff --git a/src/glx/SConscript b/src/glx/SConscript
index ef372d0..f581c12 100644
--- a/src/glx/SConscript
+++ b/src/glx/SConscript
@@ -40,6 +40,9 @@ if env['HAVE_XF86VIDMODE']:
  if False: # XXX: SHARED_GLAPI
  env.Append(CPPDEFINES = ['GLX_SHARED_GLAPI'])

+# XXX: Disable DRI3 for now
+env.Append(CPPDEFINES = ['GLX_NO_DRI3'])
+
  sources = [
  'clientattrib.c',
  'clientinfo.c',
@@ -63,6 +66,7 @@ sources = [
  'indirect_vertex_program.c',
  'pixel.c',
  'pixelstore.c',
+'query_renderer.c',
  'render2.c',
  'renderpix.c',
  'single2.c',
@@ -79,6 +83,8 @@ sources = [
  'dri2_glx.c',
  'dri2.c',
  'dri2_query_renderer.c',
+#'dri3_glx.c',
+#'dri3_common.c',
  'applegl_glx.c',
  ]

diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index c6e4d9f..d3c92574 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -865,8 +865,10 @@ __glXInitialize(Display * dpy)
  ** (e.g., those called in AllocAndFetchScreenConfigs).
  */
 if (glx_direct  glx_accel) {
+#if !defined(GLX_NO_DRI3)
if (!getenv(LIBGL_DRI3_DISABLE))
   dpyPriv-dri3Display = dri3_create_display(dpy);
+#endif
dpyPriv-dri2Display = dri2CreateDisplay(dpy);
dpyPriv-driDisplay = driCreateDisplay(dpy);
 }



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

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

Re: [Mesa-dev] [PATCH] glx/dri: fix assorted compiler warnings/errors

[Brian Paul]

On 11/08/2013 07:10 AM, Jose Fonseca wrote:

Looks good to me AFAICT.

I had independently pushed a fix similar to the first chunk in your patch.  I 
think it matches your's verbatim so there should be no conflict when you rebase.



I'll push the swrast dri_create_context() patch.  But for the 
query_renderer_integer() change, I'm honestly not sure if the type is 
supposed to be signed or unsigned.  I'll put that in a separate patch 
for review.


-Brian


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

Re: [Mesa-dev] Batchbuffer question

[Paul Berry]

On 8 November 2013 04:49, Rogovin, Kevin kevin.rogo...@intel.com wrote:

 Hi all,

  As I was poking into the magicks for the batchbuffer, I saw the following
 logical bits of code, that make sense by themselves but get me paranoid
 together. Firstly in intel_batchbuffer_begin() [ intel_batchbuffer.h, and
 this is what BEGIN_BATCH maps to] there is a
 intel_batchbuffer_require_space() call that if too much room is needed then
 calls intel_batchbuffer_begin():

 from intel_batchbuffer_require_space():

   115if (intel_batchbuffer_space(brw)  sz)
   116   intel_batchbuffer_flush(brw);

 and from intel_batchbuffer_space():

80 intel_batchbuffer_space(struct brw_context *brw)
81 {
82return (brw-batch.state_batch_offset - brw-batch.reserved_space)
83   - brw-batch.used*4;
84 }


 Now, for allocating space for state, there is brw_state_batch():


   128offset = ROUND_DOWN_TO(batch-state_batch_offset - size,
 alignment);
   129
   130/* If allocating from the top would wrap below the batchbuffer, or
   131 * if the batch's used space (plus the reserved pad) collides
 with our
   132 * space, then flush and try again.
   133 */
   134if (batch-state_batch_offset  size ||
   135offset  4*batch-used + batch-reserved_space) {
   136   intel_batchbuffer_flush(brw);
   137   offset = ROUND_DOWN_TO(batch-state_batch_offset - size,
 alignment);
   138}


 These taken together, I interpret as meaning that state and commands try
 to be separated by atleast batch-reserved_space bytes. I guess state could
 take up more than (batch-bo-size - batch-reserved_space) from that
 second ROUND_DOWN_TO, but that would only happen right after a flush and
 any state or command afterwards would flush too.

 Now my questions:
   1) it looks like the reserved space is not to be used for either state
 or commands. Is that correct? What is it used for?


It is used by commands that have to go at the end of every batch.  When
we're deciding whether or not to go to a new batch buffer, those commands
haven't been emitted yet, so we have to account for the amount of space
they take up when we determine whether the next command is going to fill up
the batch buffer.  See the documentation for BATCH_RESERVED in
intel_batchbuffer.h.



   2) if a function first calls brw_state_batch() to place state and it
 barely fits and then calls BEGIN_BATCH that does not fit, then the command
 will refer to an offset on the previous batch buffer, that cannot be good.
 Or does this never happen for other reasons? If so what are those reasons?


You are correct that this cannot be good.  It probably would lead to a GPU
hang.  The reason it doesn't happen is that we have an additional mechanism
for flushing the batch at a safe time, before we have started emitting the
state for a draw call.  Near the top of brw_try_draw_prims(), we estimate
how many bytes of batch buffer space will be needed to complete the draw
call (estimated_max_prim_size).  Then we pad it by 512 bytes to be safe,
and then we call intel_batchbuffer_require_space(), which flushes the
batchbuffer if there isn't enough space.  This is safe because we haven't
started emitting state yet.  And it ensures that once we do emit state,
there will be enough batch buffer space available to contain it without
needing to flush at an inopportune time.

There's only one problem.  As we continue to add features to the driver,
the maximum possible amount of batch buffer space needed to hold draw state
increases, and we rarely remember to update estimated_max_prim_size to
reflect that.  So there's a danger of not passing a large enough number to
intel_batchbuffer_require_space(), either now or in the future.

To reduce the risk of that, we have a safety mechanism in debug builds: if
we run out of batch buffer space while emitting draw state, we will assert
rather than flush.  Grep for no_batch_wrap to see the code that does this.

IMHO, we could do even better than this.  What we really should do is keep
track of the amount of batch buffer space used by every draw call and
compare it to estimated_max_prim_size.  If the difference between the
actual space used and the estimate is ever less than the 512 pad bytes in a
debug build, we should assertion fail.  That way the assertion failure
would happen if we're *ever* wrong in our estimate of how much batch space
is needed (rather than only happening if being wrong causes an unsafe
flush).  Kevin, would you be interested in submitting a patch to improve
this?  It might be a nice way for you to continue building up your
familiarity with the codebase.  If not I can add it to my to-do list.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 71363] line rendering with --with-osmesa-bits=32

[bugzilla-daemon]

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

--- Comment #6 from burlen burlen.lor...@gmail.com ---
Comment on attachment 88866
  -- https://bugs.freedesktop.org/attachment.cgi?id=88866
osmesa patch to test

Review of attachment 88866:
-

The patch made no difference. I only tested the affected classes and not all of
VTK.

-- 
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 71397] New: [llvmpipe] configure: error: Package requirements (dri3proto = 1.0) were not met

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 71397
  Keywords: regression
CC: e...@anholt.net, kei...@keithp.com, k...@bitplanet.net
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [llvmpipe] configure: error: Package requirements
(dri3proto = 1.0) were not met
  Severity: blocker
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

mesa: f41c01c68847a2d3df8f3c8786ef803428a0be13 (master)

$ ./autogen.sh --with-dri-drivers= --with-gallium-drivers=swrast
[...]
checking for DRI2PROTO... yes
checking for DRI3PROTO... no
configure: error: Package requirements (dri3proto = 1.0) were not met:

No package 'dri3proto' found



commit 2d94601582e4f0fcaf8c02a15b23cba39dec7bb1
Author: Keith Packard kei...@keithp.com
Date:   Mon Nov 4 18:15:51 2013 -0800

Add DRI3+Present loader

Uses the __DRIimage loader interfaces.

v2: Fix _XIOErrors when DRI3 isn't present (change by anholt).  Apparently
XCB just terminates your connection if you don't check for extensions
before using them, instead of returning an error like you'd expect.

Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
Reviewed-by: Eric Anholt e...@anholt.net

-- 
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 71363] line rendering with --with-osmesa-bits=32

[bugzilla-daemon]

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

--- Comment #7 from burlen burlen.lor...@gmail.com ---
Created attachment 88901
  -- https://bugs.freedesktop.org/attachment.cgi?id=88901action=edit
apitrace from the failing bar chart test

The apitrace developers shared a patch that allows the tool to work with
OSMesa.

-- 
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 demos 2/3] Perf: Add test to measure texture upload

[Brian Paul]

On 11/08/2013 08:49 AM, Courtney Goeltzenleuchter wrote:

enh = enhanced

Suggestions on something more descriptive?
teximage2?
bench_teximage?
teximage_perf?

Thanks for the feedback.


Does the existing teximage test do anything that your new test doesn't 
do?  If the old teximage test is obsoleted by your's then let's just 
replace the old one.


-Brian


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

Re: [Mesa-dev] [PATCH] i965/fs: Don't perform CSE on inst HW_REG dests (unless it's null)

[Eric Anholt]

Matt Turner matts...@gmail.com writes:

 Commit b16b3c87 began performing CSE on CMP instructions with null
 destinations. I relaxed the restrictions a bit too much, thereby
 allowing CSE to be performed on instructions with, for instance, an
 explicit accumulator destination.

 This broke the arb_gpu_shader5/fs-imulExtended shader tests because
 they emit MUL instructions with the accumulator as the destination. CSE
 would instead cause the MUL to write to a GRF, which is lower precision
 than the accumulator.

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

(mark as 10.0 candidate)


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

[Mesa-dev] [PATCH 2/2] i965: Enhance tiled_memcpy to support all levels

[Courtney Goeltzenleuchter]

Support all levels of a supported texture format.

Using 1024x1024, RGBA  source, mipmap
THIS PATCH
internal-format Before (MB/sec) XRGB (MB/sec)   mipmap (MB/sec)
GL_RGBA 628.15  627.15  615.90
GL_RGB  265.95  456.35  611.53
512x512
GL_RGBA 600.23  597.00  619.95
GL_RGB  255.50  440.62  611.28
256x256
GL_RGBA 489.08  487.80  587.42
GL_RGB  229.03  376.63  585.00

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

Courtney Goeltzenleuchter (2):
  i965: add XRGB to tiled_memcpy
  i965: Enhance tiled_memcpy to support all levels

 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index b1826fa..50f802f 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -543,7 +543,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
uint32_t cpp;
mem_copy_fn mem_copy = NULL;
 
-   /* This fastpath is restricted to specific texture types: level 0 of
+   /* This fastpath is restricted to specific texture types:
 * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to support
 * more types.
 *
@@ -555,7 +555,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
if (!brw-has_llc ||
type != GL_UNSIGNED_BYTE ||
texImage-TexObject-Target != GL_TEXTURE_2D ||
-   texImage-Level != 0 ||
pixels == NULL ||
_mesa_is_bufferobj(packing-BufferObj) ||
packing-Alignment  4 ||
@@ -631,6 +630,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Alignment, packing-RowLength, packing-SkipPixels,
packing-SkipRows, for_glTexImage);
 
+   /* Adjust x and y offset based on miplevel
+*/
+   xoffset += image-mt-level[texImage-Level].level_x;
+   yoffset += image-mt-level[texImage-Level].level_y;
+
linear_to_tiled(
   xoffset * cpp, (xoffset + width) * cpp,
   yoffset, yoffset + height,
-- 
1.8.1.2

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

Re: [Mesa-dev] [PATCH demos 3/3] Perf: teximage_enh Add command line options

[Courtney Goeltzenleuchter]

Hi Brian,

Oops, I meant to get rid of that. Is unnecessary now that the perf
framework has command line arguments.

Courtney


On Thu, Nov 7, 2013 at 5:49 PM, Brian Paul bri...@vmware.com wrote:

 On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:

 texture_enh allows the user to specify source, internal formats
 and mipmap or not. This provides a quick way to get feedback
 on texture upload related performance tuning.
 Texture image data is initialized and aligned to 64 byte bounary.
 Uses Mesa demos Perf library to do the measurements.



 It looks like the previous patch in the series added the shell script
 which passes command line params.  Shouldn't this patch come before that
 feature?

 I'm not too concerned though.

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


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




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

[Mesa-dev] [PATCH] glx: change query_renderer_integer() value param to unsigned

[Brian Paul]

From: Brian Paul bri...@vmware.com

Not sure if this is supposed to be signed or unsigned.  It's not
consistent as-is.
---
 src/glx/glxclient.h  |2 +-
 src/glx/query_renderer.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index e26a83e..e33dba6 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -477,7 +477,7 @@ struct glx_screen_vtable {
 unsigned *error);
int (*query_renderer_integer)(struct glx_screen *psc,
  int attribute,
- int *value);
+ unsigned int *value);
int (*query_renderer_string)(struct glx_screen *psc,
 int attribute,
 const char **value);
diff --git a/src/glx/query_renderer.c b/src/glx/query_renderer.c
index 981a844..9108ec2 100644
--- a/src/glx/query_renderer.c
+++ b/src/glx/query_renderer.c
@@ -30,7 +30,7 @@ __glXQueryRendererInteger(struct glx_screen *psc, int 
attribute,
   unsigned int *value)
 {
unsigned int values_for_query = 0;
-   int buffer[32];
+   unsigned int buffer[32];
int err;
 
/* This probably means the caller is trying to use an extension function
-- 
1.7.9.5

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

[Mesa-dev] [Bug 71363] line rendering with --with-osmesa-bits=32

[bugzilla-daemon]

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

--- Comment #8 from burlen burlen.lor...@gmail.com ---
The bug can be reproduced using VTK built against OSMesa. The following shows
how I configured Mesa and VTK.


# Mesa config
./configure CXXFLAGS=-O2 -g CFLAGS=-O2 -g --disable-xvmc --disable-glx
--disable-dri --with-dri-drivers= --with-gallium-drivers=
--enable-texture-float --disable-shared-glapi --disable-egl
--with-egl-platforms= --enable-osmesa --with-osmesa-bits=32
--enable-gallium-llvm=no --prefix=/work/apps/mesa/devel/classic



#!/bin/bash
# VTK config
MESA=$1
shift

BITS=$1
shift

cmake \
  -DCMAKE_BUILD_TYPE=Debug \
  -DVTK_DEBUG_LEAKS=ON \
  -DBUILD_SHARED_LIBS=ON \
  -DBUILD_TESTING=ON \
  -DVTK_USE_X=OFF \
  -DVTK_OPENGL_HAS_OSMESA=ON \
  -DOPENGL_INCLUDE_DIR=$MESA/include \
  -DOPENGL_gl_LIBRARY=$MESA/lib/libOSMesa$BITS\.so \
  -DOPENGL_xmesa_INCLUDE_DIR=$MESA/include \
  -DOSMESA_INCLUDE_DIR=$MESA/include \
  -DOSMESA_LIBRARY=$MESA/lib/libOSMesa$BITS\.so \
  -DVTK_DATA_STORE=/work/VTK/VTKExternalData \
  $*

-- 
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] i965: Make the driver compile until a proper libdrm can be released.

[Eric Anholt]

No depending on unreleased code.
---
 src/mesa/drivers/dri/i965/brw_context.c | 8 +++-
 src/mesa/drivers/dri/i965/brw_reset.c   | 7 +++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index a33e993..bee98e3 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -714,12 +714,10 @@ brwCreateContext(gl_api api,
}
 
/* Notification of GPU resets requires hardware contexts and a kernel new
-* enough to support DRM_IOCTL_I915_GET_RESET_STATS.
+* enough to support DRM_IOCTL_I915_GET_RESET_STATS, which isn't upstream
+* yet.
 */
-   if (notify_reset 
-   (brw-hw_ctx == NULL
-|| drm_intel_get_reset_stats(brw-hw_ctx, brw-reset_count, NULL,
- NULL))) {
+   if (notify_reset) {
   /* This is the wrong error code, but the correct error code (one that
* will cause EGL to generate EGL_BAD_MATCH) doesn't seem to exist.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_reset.c 
b/src/mesa/drivers/dri/i965/brw_reset.c
index 7eca1bc..e93b2e2 100644
--- a/src/mesa/drivers/dri/i965/brw_reset.c
+++ b/src/mesa/drivers/dri/i965/brw_reset.c
@@ -42,10 +42,17 @@ brw_get_graphics_reset_status(struct gl_context *ctx)
 */
assert(brw-hw_ctx != NULL);
 
+#if 0
+   /* This is waiting until the kernel code can be merged and a new libdrm
+* actually released.
+*/
err = drm_intel_get_reset_stats(brw-hw_ctx, reset_count, active,
pending);
if (err)
   return GL_NO_ERROR;
+#else
+   return GL_NO_ERROR;
+#endif
 
/* A reset was observed while a batch from this context was executing.
 * Assume that this context was at fault.
-- 
1.8.4.rc3

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

Re: [Mesa-dev] [PATCH demos 2/3] Perf: Add test to measure texture upload

[Courtney Goeltzenleuchter]

enh = enhanced

Suggestions on something more descriptive?
teximage2?
bench_teximage?
teximage_perf?

Thanks for the feedback.


On Thu, Nov 7, 2013 at 5:49 PM, Brian Paul bri...@vmware.com wrote:

 On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:

 Needed test to measure texture upload speed under a variety
 of modes (mipmap, source format, internal format, size, etc.)
 This new test has an interactive run mode like the other Mesa
 Perf tests but also includes command line options to make
 it automatable.
 Fix up code formatting.

 Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
 ---
   src/perf/CMakeLists.txt|   1 +
   src/perf/Makefile.am   |   1 +
   src/perf/bench_glTexImage2D.sh |  13 ++
   src/perf/teximage_enh.README   |  10 ++
   src/perf/teximage_enh.c| 391 ++
 +++


 What does enh mean?  Maybe you could find something a bit more obvious?



5 files changed, 416 insertions(+)
   create mode 100755 src/perf/bench_glTexImage2D.sh
   create mode 100644 src/perf/teximage_enh.README
   create mode 100644 src/perf/teximage_enh.c

 diff --git a/src/perf/CMakeLists.txt b/src/perf/CMakeLists.txt
 index 68b6875..ded 100644
 --- a/src/perf/CMakeLists.txt
 +++ b/src/perf/CMakeLists.txt
 @@ -28,6 +28,7 @@ set (targets
 readpixels
 swapbuffers
 teximage
 +   teximage_enh
 vbo
 vertexrate
   )
 diff --git a/src/perf/Makefile.am b/src/perf/Makefile.am
 index 5363c58..1cc5c43 100644
 --- a/src/perf/Makefile.am
 +++ b/src/perf/Makefile.am
 @@ -51,6 +51,7 @@ bin_PROGRAMS = \
 readpixels \
 swapbuffers \
 teximage \
 +   teximage_enh \
 vbo \
 vertexrate \
 glslstateschange
 diff --git a/src/perf/bench_glTexImage2D.sh
 b/src/perf/bench_glTexImage2D.sh
 new file mode 100755
 index 000..c63a251
 --- /dev/null
 +++ b/src/perf/bench_glTexImage2D.sh
 @@ -0,0 +1,13 @@
 +#!/bin/bash
 +./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle full
 --test TexImage
 +./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data
 --test TexImage
 +./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data
 --test TexImage
 +./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data
 --test TexImage
 +./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data
 --test TexImage
 +./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data
 --test TexImage
 +./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data
 --test TexImage_Mipmap
 +./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data
 --test TexImage_Mipmap
 +./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data
 --test TexImage_Mipmap
 +./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data
 --test TexImage_Mipmap
 +./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data
 --test TexImage_Mipmap
 +./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE
 --format GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data
 --test TexImage_Mipmap
 diff --git a/src/perf/teximage_enh.README b/src/perf/teximage_enh.README
 new file mode 100644
 index 000..44e8aea
 --- /dev/null
 +++ b/src/perf/teximage_enh.README
 @@ -0,0 +1,10 @@
 +glTexImage2D benchmark
 +  - executable name:  teximage_enh
 +  - modified files:  CMakeLists.txt  Makefile.am
 +  - new files:
 + teximage_enh.c - code
 + bench_glTexImage2D.sh
 +direct run command:  ./teximage_enh
 +
 +script usage:./test_glTexImage2D.sh
 +
 diff --git a/src/perf/teximage_enh.c b/src/perf/teximage_enh.c
 new file mode 100644
 index 000..9bb3944
 --- /dev/null
 +++ b/src/perf/teximage_enh.c
 @@ -0,0 +1,391 @@
 +/*
 + * Copyright (C) 2009  VMware, Inc.  All Rights Reserved.


 Maybe add your own LunarG copyright line.



  + *
 + * Permission is hereby granted, free of charge, to any person obtaining
 a
 + * copy of this software and associated documentation files (the
 Software),
 + * to deal in the Software without restriction, including without
 limitation
 + * the rights to use, copy, modify, merge, publish, distribute,
 sublicense,
 + 

[Mesa-dev] [PATCH] glx: Fix scons build.

[jfonseca]

From: José Fonseca jfons...@vmware.com

By disabling DRI3 support for the time being.

I'll add DRI3 support to scons build when the DRI3 dependencies become
more widely available (as now there is no convenient way of testing it
except building dependencies from source).
---
 src/glx/SConscript | 6 ++
 src/glx/glxext.c   | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/src/glx/SConscript b/src/glx/SConscript
index ef372d0..f581c12 100644
--- a/src/glx/SConscript
+++ b/src/glx/SConscript
@@ -40,6 +40,9 @@ if env['HAVE_XF86VIDMODE']:
 if False: # XXX: SHARED_GLAPI
 env.Append(CPPDEFINES = ['GLX_SHARED_GLAPI'])
 
+# XXX: Disable DRI3 for now
+env.Append(CPPDEFINES = ['GLX_NO_DRI3'])
+
 sources = [
 'clientattrib.c',
 'clientinfo.c',
@@ -63,6 +66,7 @@ sources = [
 'indirect_vertex_program.c',
 'pixel.c',
 'pixelstore.c',
+'query_renderer.c',
 'render2.c',
 'renderpix.c',
 'single2.c',
@@ -79,6 +83,8 @@ sources = [
 'dri2_glx.c',
 'dri2.c',
 'dri2_query_renderer.c',
+#'dri3_glx.c',
+#'dri3_common.c',
 'applegl_glx.c',
 ]
 
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index c6e4d9f..d3c92574 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -865,8 +865,10 @@ __glXInitialize(Display * dpy)
 ** (e.g., those called in AllocAndFetchScreenConfigs).
 */
if (glx_direct  glx_accel) {
+#if !defined(GLX_NO_DRI3)
   if (!getenv(LIBGL_DRI3_DISABLE))
  dpyPriv-dri3Display = dri3_create_display(dpy);
+#endif
   dpyPriv-dri2Display = dri2CreateDisplay(dpy);
   dpyPriv-driDisplay = driCreateDisplay(dpy);
}
-- 
1.8.3.2

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

Re: [Mesa-dev] Batchbuffer question

[Kenneth Graunke]

On 11/08/2013 04:49 AM, Rogovin, Kevin wrote:
 Hi all,
 
 As I was poking into the magicks for the batchbuffer, I saw the
 following logical bits of code, that make sense by themselves but get
 me paranoid together. Firstly in intel_batchbuffer_begin() [
 intel_batchbuffer.h, and this is what BEGIN_BATCH maps to] there is a
 intel_batchbuffer_require_space() call that if too much room is
 needed then calls intel_batchbuffer_begin():
 
 from intel_batchbuffer_require_space():
 
   115if (intel_batchbuffer_space(brw)  sz)
   116   intel_batchbuffer_flush(brw);
 
 and from intel_batchbuffer_space():
 
80 intel_batchbuffer_space(struct brw_context *brw)
81 {
82return (brw-batch.state_batch_offset - brw-batch.reserved_space)
83   - brw-batch.used*4;
84 }
 
 
 Now, for allocating space for state, there is brw_state_batch():
 
 
   128offset = ROUND_DOWN_TO(batch-state_batch_offset - size, alignment);
   129
   130/* If allocating from the top would wrap below the batchbuffer, or
   131 * if the batch's used space (plus the reserved pad) collides with 
 our
   132 * space, then flush and try again.
   133 */
   134if (batch-state_batch_offset  size ||
   135offset  4*batch-used + batch-reserved_space) {
   136   intel_batchbuffer_flush(brw);
   137   offset = ROUND_DOWN_TO(batch-state_batch_offset - size, 
 alignment);
   138}
 
 
 These taken together, I interpret as meaning that state and commands
 try to be separated by atleast batch-reserved_space bytes. I guess
 state could take up more than (batch-bo-size -
 batch-reserved_space) from that second ROUND_DOWN_TO, but that would
 only happen right after a flush and any state or command afterwards
 would flush too.
 
 Now my questions: 1) it looks like the reserved space is not to be
 used for either state or commands. Is that correct? What is it used
 for?

To explain a bit more...we store commands (like 3DSTATE_VS) and indirect
state (like BLEND_STATE) in the same buffer (the batchbuffer).

We emit commands starting at the top of the buffer, since they need to
be in order.  Indirect state is always pointed to by a command (i.e.
3DSTATE_BLEND_STATE_POINTERS), so it can be in any order.  We fill
indirect state backwards, starting from the end of the buffer.

Should they meet in the middle, we flush the batch and start a new one.

It's sort of like how the stack and heap start at opposite sides and
grow towards each other.

When we finish a batch, we need to append a few final commands.  These
use the reserved space.  From intel_batchbuffer.c:

   brw-batch.reserved_space = 0;

   brw_finish_batch(brw);

   /* Mark the end of the buffer. */
   intel_batchbuffer_emit_dword(brw, MI_BATCH_BUFFER_END);
   if (brw-batch.used  1) {
  /* Round batchbuffer usage to 2 DWORDs. */
  intel_batchbuffer_emit_dword(brw, MI_NOOP);
   }

MI_BATCH_BUFFER_END is fairly self-explanatory, but there are others.
On Gen4-5, we need to take a snapshot of the PS_DEPTH_COUNT register in
order to make occlusion queries, so there's a PIPE_CONTROL.  With my
upcoming performance monitor changes, we also need to take snapshots of
the observability architecture counters as well, so there will be an
MI_REPORT_PERF_COUNT.

See the comments above the BATCH_RESERVED #define, which list all the
things we might emit.

Note that, prior to emitting this state, we set
brw-batch.reserved_space to 0, which makes that space available for
these final commands.  So we'll always have space and never try to flush
in the middle of flushing.

 2) if a function first calls brw_state_batch() to place state and it
 barely fits and then calls BEGIN_BATCH that does not fit, then the
 command will refer to an offset on the previous batch buffer, that
 cannot be good. Or does this never happen for other reasons? If so
 what are those reasons?

Leaving additional indirect state in the buffer is harmless.  We do need
to remove commands.

OpenGL draw calls involve emitting a bunch of commands, finishing with a
3DPRIMITIVE command.  Prior to emitting anything, we call:

  intel_batchbuffer_save_state(brw);

which saves batch-used and the current number of relocations.  If we
run out of space before emitting the 3DPRIMITIVE, we call:

intel_batchbuffer_reset_to_saved(brw);

which resets the batch-used to the saved value, effectively throwing
away those commands.  It also calls into libdrm to throw away the extra
relocations.

Hope this helps!

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

[Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader

[Armin K]

This patch makes it possible to disable dri3 if desired.

I am not sure if first set of changes for src/glx/glxext.c
was necessary. Feel free to modify it as you may please.

Tested with:

./configure --disable-dri3 --with-dri-drivers=i965 \
--with-gallium-drivers= --disable-vdpau --disable-egl \
--disable-gbm --disable-xvmc
---
 configure.ac| 21 ++---
 src/glx/Makefile.am |  8 ++--
 src/glx/glxclient.h |  4 
 src/glx/glxext.c|  6 ++
 4 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 8fb5e0d..7ed9507 100644
--- a/configure.ac
+++ b/configure.ac
@@ -536,6 +536,11 @@ AC_ARG_ENABLE([dri],
 [enable DRI modules @:@default=enabled@:@])],
 [enable_dri=$enableval],
 [enable_dri=yes])
+AC_ARG_ENABLE([dri3],
+[AS_HELP_STRING([--enable-dri3],
+[enable DRI3 @:@default=enabled@:@])],
+[enable_dri3=$enableval],
+[enable_dri3=yes])
 AC_ARG_ENABLE([glx],
 [AS_HELP_STRING([--enable-glx],
 [enable GLX library @:@default=enabled@:@])],
@@ -702,6 +707,7 @@ fi
 AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
   x$enable_dri = xyes)
 AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
+AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -811,13 +817,19 @@ xyesno)
 fi
 PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
 GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
-PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
-PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
$PRESENTPROTO_REQUIRED])
 PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED])
+if test x$enable_dri3 = xyes; then
+PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
+PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
$PRESENTPROTO_REQUIRED])
+fi
 fi
 
 # find the DRI deps for libGL
-dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 
1.8 xcb-dri3 xcb-present xcb-sync xshmfence
+dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 
1.8 xcb-dri3 xcb-present xcb-sync
+
+if test x$enable_dri3 = xyes; then
+dri_modules=$dri_modules xshmfence
+fi
 
 # add xf86vidmode if available
 PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
HAVE_XF86VIDMODE=no)
@@ -947,6 +959,9 @@ if test x$enable_dri = xyes; then
 linux*)
 DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1
 DEFINES=$DEFINES -DHAVE_ALIAS
+if test x$enable_dri3 = xyes; then
+DEFINES=$DEFINES -DHAVE_DRI3
+fi
 
 case $host_cpu in
 x86_64|amd64)
diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index ae296b9..0aec2aa 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -94,10 +94,14 @@ libglx_la_SOURCES = \
  dri2_glx.c \
  dri2.c \
  dri2_query_renderer.c \
-  dri3_glx.c \
-  dri3_common.c \
  applegl_glx.c
 
+if HAVE_DRI3
+libglx_la_SOURCES += \
+  dri3_glx.c \
+  dri3_common.c
+endif
+
 GL_LIBS = \
libglx.la \
$(SHARED_GLAPI_LIBS) \
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index e26a83e..8ccc843 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -150,7 +150,9 @@ extern __GLXDRIdisplay *dri2CreateDisplay(Display * dpy);
 extern void dri2InvalidateBuffers(Display *dpy, XID drawable);
 extern unsigned dri2GetSwapEventType(Display *dpy, XID drawable);
 
+#if defined(HAVE_DRI3)
 extern __GLXDRIdisplay *dri3_create_display(Display * dpy);
+#endif
 
 /*
 ** Functions to obtain driver configuration information from a direct
@@ -588,8 +590,10 @@ struct glx_display
__GLXDRIdisplay *driswDisplay;
__GLXDRIdisplay *driDisplay;
__GLXDRIdisplay *dri2Display;
+#if defined(HAVE_DRI3)
__GLXDRIdisplay *dri3Display;
 #endif
+#endif
 };
 
 struct glx_drawable {
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index c6e4d9f..bcf3e9c 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -770,9 +770,13 @@ AllocAndFetchScreenConfigs(Display * dpy, struct 
glx_display * priv)
for (i = 0; i  screens; i++, psc++) {
   psc = NULL;
 #if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
+#if defined(HAVE_DRI3)
   if (priv-dri3Display)
  psc = (*priv-dri3Display-createScreen) (i, priv);
   if (psc == NULL  priv-dri2Display)
+#else
+  if (priv-dri2Display)
+#endif
 psc = (*priv-dri2Display-createScreen) (i, priv);
   if (psc == NULL  priv-driDisplay)
 psc = (*priv-driDisplay-createScreen) (i, priv);
@@ -865,8 +869,10 @@ __glXInitialize(Display * dpy)
 ** (e.g., those called in AllocAndFetchScreenConfigs).
 */
if (glx_direct  glx_accel) {
+#if defined(HAVE_DRI3)
   if 

[Mesa-dev] [Bug 71397] [llvmpipe] configure: error: Package requirements (dri3proto = 1.0) were not met

[bugzilla-daemon]

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

--- Comment #1 from Armin K kre...@email.com ---
Does http://lists.freedesktop.org/archives/mesa-dev/2013-November/048072.html
fix your issue? Note that you have to use --disable-dri3

-- 
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] i965: Make the driver compile until a proper libdrm can be released.

[Armin K.]

On 11/08/2013 07:49 PM, Eric Anholt wrote:
 No depending on unreleased code.

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

 ---
  src/mesa/drivers/dri/i965/brw_context.c | 8 +++-
  src/mesa/drivers/dri/i965/brw_reset.c   | 7 +++
  2 files changed, 10 insertions(+), 5 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
 b/src/mesa/drivers/dri/i965/brw_context.c
 index a33e993..bee98e3 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -714,12 +714,10 @@ brwCreateContext(gl_api api,
 }
  
 /* Notification of GPU resets requires hardware contexts and a kernel new
 -* enough to support DRM_IOCTL_I915_GET_RESET_STATS.
 +* enough to support DRM_IOCTL_I915_GET_RESET_STATS, which isn't upstream
 +* yet.
  */
 -   if (notify_reset 
 -   (brw-hw_ctx == NULL
 -|| drm_intel_get_reset_stats(brw-hw_ctx, brw-reset_count, NULL,
 - NULL))) {
 +   if (notify_reset) {
/* This is the wrong error code, but the correct error code (one that
 * will cause EGL to generate EGL_BAD_MATCH) doesn't seem to exist.
 */
 diff --git a/src/mesa/drivers/dri/i965/brw_reset.c 
 b/src/mesa/drivers/dri/i965/brw_reset.c
 index 7eca1bc..e93b2e2 100644
 --- a/src/mesa/drivers/dri/i965/brw_reset.c
 +++ b/src/mesa/drivers/dri/i965/brw_reset.c
 @@ -42,10 +42,17 @@ brw_get_graphics_reset_status(struct gl_context *ctx)
  */
 assert(brw-hw_ctx != NULL);
  
 +#if 0
 +   /* This is waiting until the kernel code can be merged and a new libdrm
 +* actually released.
 +*/
 err = drm_intel_get_reset_stats(brw-hw_ctx, reset_count, active,
 pending);
 if (err)
return GL_NO_ERROR;
 +#else
 +   return GL_NO_ERROR;
 +#endif
  
 /* A reset was observed while a batch from this context was executing.
  * Assume that this context was at fault.
 

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

Re: [Mesa-dev] [PATCH] i965: Make the driver compile until a proper libdrm can be released.

[Kenneth Graunke]

On 11/08/2013 10:49 AM, Eric Anholt wrote:
 No depending on unreleased code.
 ---
  src/mesa/drivers/dri/i965/brw_context.c | 8 +++-
  src/mesa/drivers/dri/i965/brw_reset.c   | 7 +++
  2 files changed, 10 insertions(+), 5 deletions(-)

Reviewed-by: Kenneth Graunke kenn...@whitecape.org

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

[Mesa-dev] [PATCH] i965: Remove some tiny dead code from intel_miptree_map_movntdqa

[Chad Versace]

CC: Matt Turner matts...@gmail.com
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 3f56086..bb986bd 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1891,9 +1891,6 @@ intel_miptree_map_movntdqa(struct brw_context *brw,
   void *src_ptr = src + y * mt-region-pitch;
 
   _mesa_streaming_load_memcpy(dst_ptr, src_ptr, width_bytes);
-
-  dst_ptr += width_bytes;
-  src_ptr += width_bytes;
}
 
intel_miptree_unmap_raw(brw, mt);
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH] glx/dri: fix assorted compiler warnings/errors

[Ian Romanick]

On 11/07/2013 07:04 PM, Brian Paul wrote:
 From: Brian Paul bri...@vmware.com
 
 To fix fall-out from recent commits.

/me puts a paper bag on his head

I only built i915 and i965 before pushing.  Sorry about that.

With the issue below fixed,

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

I'll pick the fixes over to the 10.0 branch if you or Jose don't beat me
to it.

 ---
  .../state_trackers/dri/common/dri_context.h|1 +
  src/glx/dri2.h |2 ++
  src/glx/glxclient.h|2 +-
  src/glx/query_renderer.c   |2 +-
  src/mesa/drivers/dri/swrast/swrast.c   |1 +
  5 files changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/src/gallium/state_trackers/dri/common/dri_context.h 
 b/src/gallium/state_trackers/dri/common/dri_context.h
 index b87ce40..56dfa2c 100644
 --- a/src/gallium/state_trackers/dri/common/dri_context.h
 +++ b/src/gallium/state_trackers/dri/common/dri_context.h
 @@ -89,6 +89,7 @@ dri_create_context(gl_api api,
  unsigned major_version,
  unsigned minor_version,
  uint32_t flags,
 +bool notify_reset,
  unsigned *error,
  void *sharedContextPrivate);
  
 diff --git a/src/glx/dri2.h b/src/glx/dri2.h
 index c404a3a..90efde8 100644
 --- a/src/glx/dri2.h
 +++ b/src/glx/dri2.h
 @@ -45,6 +45,8 @@ typedef struct
 unsigned int flags;
  } DRI2Buffer;
  
 +struct glx_screen;
 +
  extern Bool
  DRI2QueryExtension(Display * display, int *eventBase, int *errorBase);
  
 diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
 index 7363327..257728d 100644
 --- a/src/glx/glxclient.h
 +++ b/src/glx/glxclient.h
 @@ -476,7 +476,7 @@ struct glx_screen_vtable {
unsigned *error);
 int (*query_renderer_integer)(struct glx_screen *psc,
   int attribute,
 - int *value);
 + unsigned int *value);

This breaks 'make check'.  I've attached a patch.

 int (*query_renderer_string)(struct glx_screen *psc,
  int attribute,
  const char **value);
 diff --git a/src/glx/query_renderer.c b/src/glx/query_renderer.c
 index 981a844..9108ec2 100644
 --- a/src/glx/query_renderer.c
 +++ b/src/glx/query_renderer.c
 @@ -30,7 +30,7 @@ __glXQueryRendererInteger(struct glx_screen *psc, int 
 attribute,
unsigned int *value)
  {
 unsigned int values_for_query = 0;
 -   int buffer[32];
 +   unsigned int buffer[32];
 int err;
  
 /* This probably means the caller is trying to use an extension function
 diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
 b/src/mesa/drivers/dri/swrast/swrast.c
 index bfa2efd..c062071 100644
 --- a/src/mesa/drivers/dri/swrast/swrast.c
 +++ b/src/mesa/drivers/dri/swrast/swrast.c
 @@ -664,6 +664,7 @@ dri_create_context(gl_api api,
  unsigned major_version,
  unsigned minor_version,
  uint32_t flags,
 +bool notify_reset,
  unsigned *error,
  void *sharedContextPrivate)
  {
 



query_renderer_unittest.patch
Description: application/pgp-keys
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Remove some tiny dead code from intel_miptree_map_movntdqa

[Matt Turner]

On Fri, Nov 8, 2013 at 1:55 PM, Chad Versace
chad.vers...@linux.intel.com wrote:
 CC: Matt Turner matts...@gmail.com
 Signed-off-by: Chad Versace chad.vers...@linux.intel.com
 ---
  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 ---
  1 file changed, 3 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
 b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
 index 3f56086..bb986bd 100644
 --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
 +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
 @@ -1891,9 +1891,6 @@ intel_miptree_map_movntdqa(struct brw_context *brw,
void *src_ptr = src + y * mt-region-pitch;

_mesa_streaming_load_memcpy(dst_ptr, src_ptr, width_bytes);
 -
 -  dst_ptr += width_bytes;
 -  src_ptr += width_bytes;
 }

 intel_miptree_unmap_raw(brw, mt);
 --

Oh yeah, that is bogus.

Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader

[Ian Romanick]

On 11/08/2013 01:38 PM, Armin K wrote:
 This patch makes it possible to disable dri3 if desired.
 
 I am not sure if first set of changes for src/glx/glxext.c
 was necessary. Feel free to modify it as you may please.
 
 Tested with:
 
 ./configure --disable-dri3 --with-dri-drivers=i965 \
 --with-gallium-drivers= --disable-vdpau --disable-egl \
 --disable-gbm --disable-xvmc

I'm generally not thrilled about conditional support for features like
this.  The problem is that we end up with a bunch of combinations of
builds, and very few of them actually get tested.

In spite of the great efforts by Matt and others, Mesa's build system is
still... rough around the edges.  It's easy to get into a situation
where libGL is built one way and drivers are built another.  This often
leads to hours wasted debugging non-problems.

As I point out in a couple places below, it also adds clutter to the code.

 ---
  configure.ac| 21 ++---
  src/glx/Makefile.am |  8 ++--
  src/glx/glxclient.h |  4 
  src/glx/glxext.c|  6 ++
  4 files changed, 34 insertions(+), 5 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index 8fb5e0d..7ed9507 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -536,6 +536,11 @@ AC_ARG_ENABLE([dri],
  [enable DRI modules @:@default=enabled@:@])],
  [enable_dri=$enableval],
  [enable_dri=yes])
 +AC_ARG_ENABLE([dri3],
 +[AS_HELP_STRING([--enable-dri3],
 +[enable DRI3 @:@default=enabled@:@])],
 +[enable_dri3=$enableval],
 +[enable_dri3=yes])
  AC_ARG_ENABLE([glx],
  [AS_HELP_STRING([--enable-glx],
  [enable GLX library @:@default=enabled@:@])],
 @@ -702,6 +707,7 @@ fi
  AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
x$enable_dri = xyes)
  AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
 +AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
  
  AC_ARG_ENABLE([shared-glapi],
  [AS_HELP_STRING([--enable-shared-glapi],
 @@ -811,13 +817,19 @@ xyesno)
  fi
  PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
  GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
 -PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
 -PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
  PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED])
 +if test x$enable_dri3 = xyes; then
 +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = 
 $DRI3PROTO_REQUIRED])
 +PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 +fi
  fi
  
  # find the DRI deps for libGL
 -dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 
 = 1.8 xcb-dri3 xcb-present xcb-sync xshmfence
 +dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 
 = 1.8 xcb-dri3 xcb-present xcb-sync
 +
 +if test x$enable_dri3 = xyes; then
 +dri_modules=$dri_modules xshmfence
 +fi
  
  # add xf86vidmode if available
  PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
 HAVE_XF86VIDMODE=no)
 @@ -947,6 +959,9 @@ if test x$enable_dri = xyes; then
  linux*)
  DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1
  DEFINES=$DEFINES -DHAVE_ALIAS
 +if test x$enable_dri3 = xyes; then
 +DEFINES=$DEFINES -DHAVE_DRI3
 +fi
  
  case $host_cpu in
  x86_64|amd64)
 diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
 index ae296b9..0aec2aa 100644
 --- a/src/glx/Makefile.am
 +++ b/src/glx/Makefile.am
 @@ -94,10 +94,14 @@ libglx_la_SOURCES = \
 dri2_glx.c \
 dri2.c \
 dri2_query_renderer.c \
 -  dri3_glx.c \
 -  dri3_common.c \
 applegl_glx.c
  
 +if HAVE_DRI3
 +libglx_la_SOURCES += \
 +  dri3_glx.c \
 +  dri3_common.c
 +endif
 +
  GL_LIBS = \
   libglx.la \
   $(SHARED_GLAPI_LIBS) \
 diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
 index e26a83e..8ccc843 100644
 --- a/src/glx/glxclient.h
 +++ b/src/glx/glxclient.h
 @@ -150,7 +150,9 @@ extern __GLXDRIdisplay *dri2CreateDisplay(Display * dpy);
  extern void dri2InvalidateBuffers(Display *dpy, XID drawable);
  extern unsigned dri2GetSwapEventType(Display *dpy, XID drawable);
  
 +#if defined(HAVE_DRI3)
  extern __GLXDRIdisplay *dri3_create_display(Display * dpy);
 +#endif

I don't think this change is strictly necessary, is it?  The extra
prototype should be harmless.  If code accidentally calls
dri3_create_display, we'll get a link failure instead of a compile
failure.  Right?

  /*
  ** Functions to obtain driver configuration information from a direct
 @@ -588,8 +590,10 @@ struct glx_display
 __GLXDRIdisplay *driswDisplay;
 __GLXDRIdisplay *driDisplay;
 __GLXDRIdisplay *dri2Display;
 +#if defined(HAVE_DRI3)
 __GLXDRIdisplay *dri3Display;
  #endif
 +#endif

I don't think this change is strictly necessary 

[Mesa-dev] [Bug 71397] [llvmpipe] configure: error: Package requirements (dri3proto = 1.0) were not met

[bugzilla-daemon]

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

--- Comment #2 from Aaron Watry awa...@gmail.com ---
Created attachment 88912
  -- https://bugs.freedesktop.org/attachment.cgi?id=88912action=edit
v2 --disable-dri3 Patch

I had to use the modified version of the original that I attached here.

-- 
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] i965: Make the driver compile until a proper libdrm can be released.

[Ian Romanick]

On 11/08/2013 10:49 AM, Eric Anholt wrote:
 No depending on unreleased code.
 ---
  src/mesa/drivers/dri/i965/brw_context.c | 8 +++-
  src/mesa/drivers/dri/i965/brw_reset.c   | 7 +++
  2 files changed, 10 insertions(+), 5 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
 b/src/mesa/drivers/dri/i965/brw_context.c
 index a33e993..bee98e3 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -714,12 +714,10 @@ brwCreateContext(gl_api api,
 }
  
 /* Notification of GPU resets requires hardware contexts and a kernel new
 -* enough to support DRM_IOCTL_I915_GET_RESET_STATS.
 +* enough to support DRM_IOCTL_I915_GET_RESET_STATS, which isn't upstream
 +* yet.
  */
 -   if (notify_reset 
 -   (brw-hw_ctx == NULL
 -|| drm_intel_get_reset_stats(brw-hw_ctx, brw-reset_count, NULL,
 - NULL))) {
 +   if (notify_reset) {

If anything, this should #if around DRM_IOCTL_I915_GET_RESET_STATS being
defined.  If that's not defined, then the DRI extension shouldn't be
enabled.

  if (notify_reset
#ifdef DRM_IOCTL_I915_GET_RESET_STATS
(brw-hw_ctx == NULL
   || drm_intel_get_reset_stats(brw-hw_ctx,
brw-reset_count, NULL,
NULL))
#endif
 ) {

Then we don't have to revert this patch when libdrm bits (re-)land.

And add #ifdef DRM_IOCTL_I915_GET_RESET_STATS around the dri2Robustness
stuff in intel_screen.c.

/* This is the wrong error code, but the correct error code (one that
 * will cause EGL to generate EGL_BAD_MATCH) doesn't seem to exist.
 */
 diff --git a/src/mesa/drivers/dri/i965/brw_reset.c 
 b/src/mesa/drivers/dri/i965/brw_reset.c
 index 7eca1bc..e93b2e2 100644
 --- a/src/mesa/drivers/dri/i965/brw_reset.c
 +++ b/src/mesa/drivers/dri/i965/brw_reset.c
 @@ -42,10 +42,17 @@ brw_get_graphics_reset_status(struct gl_context *ctx)
  */
 assert(brw-hw_ctx != NULL);
  
 +#if 0

#ifdef DRM_IOCTL_I915_GET_RESET_STATS

 +   /* This is waiting until the kernel code can be merged and a new libdrm
 +* actually released.
 +*/
 err = drm_intel_get_reset_stats(brw-hw_ctx, reset_count, active,
 pending);
 if (err)
return GL_NO_ERROR;
 +#else
 +   return GL_NO_ERROR;
 +#endif
  
 /* A reset was observed while a batch from this context was executing.
  * Assume that this context was at fault.
 

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

Re: [Mesa-dev] rules for merging patches to libdrm

[Matt Turner]

On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie airl...@gmail.com wrote:
 Since we seemed to have some confusion over this I'll state it clearly here.

 You should not merge kernel interface and ioctls to libdrm until they
 have appeared in a git commit upstream with a stable id, this
 generally means drm-next, but can also mean drm-intel-next.

How does this interact with the rule that kernel interfaces require an
open source userspace? Is here are the mesa/libdrm patches that use
it sufficient to get the kernel interface merged?

libdrm is easy to change and its releases are cheap. What problem does
committing code that uses an in-progress kernel interface to libdrm
cause? I guess I'm not understanding something.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] rules for merging patches to libdrm

[Kenneth Graunke]

On 11/08/2013 02:32 PM, Matt Turner wrote:
 On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie airl...@gmail.com wrote:
 Since we seemed to have some confusion over this I'll state it clearly here.

 You should not merge kernel interface and ioctls to libdrm until they
 have appeared in a git commit upstream with a stable id, this
 generally means drm-next, but can also mean drm-intel-next.
 
 How does this interact with the rule that kernel interfaces require an
 open source userspace? Is here are the mesa/libdrm patches that use
 it sufficient to get the kernel interface merged?

That's my understanding: open source userspace needs to exist, but it
doesn't need to be merged upstream yet.

 libdrm is easy to change and its releases are cheap. What problem does
 committing code that uses an in-progress kernel interface to libdrm
 cause? I guess I'm not understanding something.

Introducing new kernel API usually involves assigning numbers for things
- a new ioctl number, new #defines for bitfield members, and so on.

Multiple patches can be in flight at the same time.  For example, Abdiel
and I both defined execbuf2 flags:

#define I915_EXEC_RS (1  13) (Abdiel's code)
#define I915_EXEC_OA (1  13) (my code)

These obviously conflict.  One of the two will land, and the second
patch author will need to switch to (1  14) and resubmit.

If we both decide to push to libdrm, we might get the order backwards,
or maybe one series won't get pushed at all (in this case, I'm planning
to drop my patch).  Waiting until one lands in the kernel avoids that
problem.  Normally, I believe we copy the kernel headers to userspace
and fix them up a bit.

Dave may have other reasons; this is just the one I thought of.

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

[Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader (v2)

[Armin K]

This patch makes it possible to disable DRI3 if desired.

v2:

Incorporated changes from Ian Rommnick and Aaron Watry
Unified libudev check and made libGL link to it only
when DRI3 was enabled.

Adding Brian Paul to CC since he asked if DRI3 stuff
can be put behind some sort of config option.

Tested with:

./configure --disable-dri3 --with-dri-drivers=i965 \
--with-gallium-drivers= --disable-vdpau --disable-egl \
--disable-gbm --disable-xvmc

CC: Ian Romanick i...@freedesktop.org
CC: Aaron Watry awa...@gmail.com
CC: Brian Paul bri...@vmware.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71397
---
 configure.ac| 44 ++--
 src/glx/Makefile.am |  8 ++--
 src/glx/glxext.c|  4 
 3 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 8fb5e0d..f756b73 100644
--- a/configure.ac
+++ b/configure.ac
@@ -536,6 +536,11 @@ AC_ARG_ENABLE([dri],
 [enable DRI modules @:@default=enabled@:@])],
 [enable_dri=$enableval],
 [enable_dri=yes])
+AC_ARG_ENABLE([dri3],
+[AS_HELP_STRING([--enable-dri3],
+[enable DRI3 @:@default=enabled@:@])],
+[enable_dri3=$enableval],
+[enable_dri3=yes])
 AC_ARG_ENABLE([glx],
 [AS_HELP_STRING([--enable-glx],
 [enable GLX library @:@default=enabled@:@])],
@@ -702,6 +707,7 @@ fi
 AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
   x$enable_dri = xyes)
 AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
+AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -756,6 +762,9 @@ AC_SUBST([MESA_LLVM])
 PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED],
   [have_libdrm=yes], [have_libdrm=no])
 
+PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
+  have_libudev=yes, have_libudev=no)
+
 if test x$enable_dri = xyes; then
 # DRI must be shared, I think
 if test $enable_static = yes; then
@@ -811,13 +820,21 @@ xyesno)
 fi
 PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
 GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
-PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
-PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
$PRESENTPROTO_REQUIRED])
-PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED])
+if test x$enable_dri3 = xyes; then
+if test x$have_libudev != xyes; then
+  AC_MSG_ERROR([DRI3 requires libudev = $LIBUDEV_REQUIRED])
+fi
+PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
+PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
$PRESENTPROTO_REQUIRED])
+fi
 fi
 
 # find the DRI deps for libGL
-dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 
1.8 xcb-dri3 xcb-present xcb-sync xshmfence
+dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 
1.8
+
+if test x$enable_dri3 = xyes; then
+dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence
+fi
 
 # add xf86vidmode if available
 PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
HAVE_XF86VIDMODE=no)
@@ -827,8 +844,13 @@ xyesno)
 
 PKG_CHECK_MODULES([DRIGL], [$dri_modules])
 GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV $dri_modules
-X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS
-GL_LIB_DEPS=$DRIGL_LIBS $LIBUDEV_LIBS
+X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS
+GL_LIB_DEPS=$DRIGL_LIBS
+
+if test x$enable_dri3$have_libudev = xyesyes; then
+X11_INCLUDES=$X11_INCLUDES $LIBUDEV_CFLAGS
+GL_LIB_DEPS=$GL_LIB_DEPS $LIBUDEV_LIBS
+fi
 
 # need DRM libs, $PTHREAD_LIBS, etc.
 GL_LIB_DEPS=$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS
@@ -947,6 +969,9 @@ if test x$enable_dri = xyes; then
 linux*)
 DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1
 DEFINES=$DEFINES -DHAVE_ALIAS
+if test x$enable_dri3 = xyes; then
+DEFINES=$DEFINES -DHAVE_DRI3
+fi
 
 case $host_cpu in
 x86_64|amd64)
@@ -1142,8 +1167,9 @@ if test x$enable_gbm = xauto; then
 esac
 fi
 if test x$enable_gbm = xyes; then
-PKG_CHECK_MODULES([LIBUDEV], [libudev], [],
-  AC_MSG_ERROR([gbm needs udev]))
+if test x$have_libudev != xyes; then
+AC_MSG_ERROR([gbm needs udev])
+fi
 
 if test x$enable_dri = xyes; then
 GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
@@ -1170,8 +1196,6 @@ if test x$enable_egl = xyes; then
 
 if test $enable_static != yes; then
 # build egl_glx when libGL is built
-PKG_CHECK_MODULES([LIBUDEV], [libudev  150],
-  [have_libudev=yes],[have_libudev=no])
 if test $have_libudev = yes; then
 DEFINES=$DEFINES -DHAVE_LIBUDEV
 fi
diff --git 

[Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader (v3)

[Armin K]

This patch makes it possible to disable DRI3 if desired.

v2:

Incorporated changes from Ian Romanick and Aaron Watry
Unified libudev check and made libGL link to it only
when DRI3 was enabled.

v3:

Correct misspelled Ian's last name in commit message.

Adding Brian Paul to CC since he asked if DRI3 stuff
can be put behind some sort of config option.

Tested with:

./configure --disable-dri3 --with-dri-drivers=i965 \
--with-gallium-drivers= --disable-vdpau --disable-egl \
--disable-gbm --disable-xvmc

CC: Ian Romanick i...@freedesktop.org
CC: Aaron Watry awa...@gmail.com
CC: Brian Paul bri...@vmware.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71397
---
 configure.ac| 44 ++--
 src/glx/Makefile.am |  8 ++--
 src/glx/glxext.c|  4 
 3 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 8fb5e0d..f756b73 100644
--- a/configure.ac
+++ b/configure.ac
@@ -536,6 +536,11 @@ AC_ARG_ENABLE([dri],
 [enable DRI modules @:@default=enabled@:@])],
 [enable_dri=$enableval],
 [enable_dri=yes])
+AC_ARG_ENABLE([dri3],
+[AS_HELP_STRING([--enable-dri3],
+[enable DRI3 @:@default=enabled@:@])],
+[enable_dri3=$enableval],
+[enable_dri3=yes])
 AC_ARG_ENABLE([glx],
 [AS_HELP_STRING([--enable-glx],
 [enable GLX library @:@default=enabled@:@])],
@@ -702,6 +707,7 @@ fi
 AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
   x$enable_dri = xyes)
 AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
+AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -756,6 +762,9 @@ AC_SUBST([MESA_LLVM])
 PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED],
   [have_libdrm=yes], [have_libdrm=no])
 
+PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
+  have_libudev=yes, have_libudev=no)
+
 if test x$enable_dri = xyes; then
 # DRI must be shared, I think
 if test $enable_static = yes; then
@@ -811,13 +820,21 @@ xyesno)
 fi
 PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
 GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
-PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
-PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
$PRESENTPROTO_REQUIRED])
-PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED])
+if test x$enable_dri3 = xyes; then
+if test x$have_libudev != xyes; then
+  AC_MSG_ERROR([DRI3 requires libudev = $LIBUDEV_REQUIRED])
+fi
+PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
+PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
$PRESENTPROTO_REQUIRED])
+fi
 fi
 
 # find the DRI deps for libGL
-dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 
1.8 xcb-dri3 xcb-present xcb-sync xshmfence
+dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 
1.8
+
+if test x$enable_dri3 = xyes; then
+dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence
+fi
 
 # add xf86vidmode if available
 PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
HAVE_XF86VIDMODE=no)
@@ -827,8 +844,13 @@ xyesno)
 
 PKG_CHECK_MODULES([DRIGL], [$dri_modules])
 GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV $dri_modules
-X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS
-GL_LIB_DEPS=$DRIGL_LIBS $LIBUDEV_LIBS
+X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS
+GL_LIB_DEPS=$DRIGL_LIBS
+
+if test x$enable_dri3$have_libudev = xyesyes; then
+X11_INCLUDES=$X11_INCLUDES $LIBUDEV_CFLAGS
+GL_LIB_DEPS=$GL_LIB_DEPS $LIBUDEV_LIBS
+fi
 
 # need DRM libs, $PTHREAD_LIBS, etc.
 GL_LIB_DEPS=$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS
@@ -947,6 +969,9 @@ if test x$enable_dri = xyes; then
 linux*)
 DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1
 DEFINES=$DEFINES -DHAVE_ALIAS
+if test x$enable_dri3 = xyes; then
+DEFINES=$DEFINES -DHAVE_DRI3
+fi
 
 case $host_cpu in
 x86_64|amd64)
@@ -1142,8 +1167,9 @@ if test x$enable_gbm = xauto; then
 esac
 fi
 if test x$enable_gbm = xyes; then
-PKG_CHECK_MODULES([LIBUDEV], [libudev], [],
-  AC_MSG_ERROR([gbm needs udev]))
+if test x$have_libudev != xyes; then
+AC_MSG_ERROR([gbm needs udev])
+fi
 
 if test x$enable_dri = xyes; then
 GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
@@ -1170,8 +1196,6 @@ if test x$enable_egl = xyes; then
 
 if test $enable_static != yes; then
 # build egl_glx when libGL is built
-PKG_CHECK_MODULES([LIBUDEV], [libudev  150],
-  [have_libudev=yes],[have_libudev=no])
 if test $have_libudev = yes; then
 

Re: [Mesa-dev] [PATCH] glx: Fix scons build.

[Matt Turner]

On Fri, Nov 8, 2013 at 9:55 AM,  jfons...@vmware.com wrote:
 From: José Fonseca jfons...@vmware.com

 By disabling DRI3 support for the time being.

 I'll add DRI3 support to scons build when the DRI3 dependencies become
 more widely available (as now there is no convenient way of testing it
 except building dependencies from source).
 ---
  src/glx/SConscript | 6 ++
  src/glx/glxext.c   | 2 ++
  2 files changed, 8 insertions(+)

 diff --git a/src/glx/SConscript b/src/glx/SConscript
 index ef372d0..f581c12 100644
 --- a/src/glx/SConscript
 +++ b/src/glx/SConscript
 @@ -40,6 +40,9 @@ if env['HAVE_XF86VIDMODE']:
  if False: # XXX: SHARED_GLAPI
  env.Append(CPPDEFINES = ['GLX_SHARED_GLAPI'])

 +# XXX: Disable DRI3 for now
 +env.Append(CPPDEFINES = ['GLX_NO_DRI3'])
 +
  sources = [
  'clientattrib.c',
  'clientinfo.c',
 @@ -63,6 +66,7 @@ sources = [
  'indirect_vertex_program.c',
  'pixel.c',
  'pixelstore.c',
 +'query_renderer.c',
  'render2.c',
  'renderpix.c',
  'single2.c',
 @@ -79,6 +83,8 @@ sources = [
  'dri2_glx.c',
  'dri2.c',
  'dri2_query_renderer.c',
 +#'dri3_glx.c',
 +#'dri3_common.c',
  'applegl_glx.c',
  ]

 diff --git a/src/glx/glxext.c b/src/glx/glxext.c
 index c6e4d9f..d3c92574 100644
 --- a/src/glx/glxext.c
 +++ b/src/glx/glxext.c
 @@ -865,8 +865,10 @@ __glXInitialize(Display * dpy)
  ** (e.g., those called in AllocAndFetchScreenConfigs).
  */
 if (glx_direct  glx_accel) {
 +#if !defined(GLX_NO_DRI3)

Please name this HAVE_DRI3 instead. That's what the associated
autotools patch calls it and I kind of dislike thinking about the
meaning of double negatives.

if (!getenv(LIBGL_DRI3_DISABLE))
   dpyPriv-dri3Display = dri3_create_display(dpy);
 +#endif
dpyPriv-dri2Display = dri2CreateDisplay(dpy);
dpyPriv-driDisplay = driCreateDisplay(dpy);
 }
 --
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader (v3)

[Matt Turner]

On Fri, Nov 8, 2013 at 3:06 PM, Armin K kre...@email.com wrote:
 This patch makes it possible to disable DRI3 if desired.

Reviewed-by: Matt Turner matts...@gmail.com

Unless non-Linux users still need to be able to disable DRI3, by the
time Mesa 10.0 is released I think we want to require these bits for
DRI builds. I'll plan to revert most of this commit before the
release.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader (v3)

[Ian Romanick]

On 11/08/2013 03:06 PM, Armin K wrote:
 This patch makes it possible to disable DRI3 if desired.

Should we squash this with Jose's patch?

 v2:
 
 Incorporated changes from Ian Romanick and Aaron Watry
 Unified libudev check and made libGL link to it only
 when DRI3 was enabled.
 
 v3:
 
 Correct misspelled Ian's last name in commit message.
 
 Adding Brian Paul to CC since he asked if DRI3 stuff
 can be put behind some sort of config option.
 
 Tested with:
 
 ./configure --disable-dri3 --with-dri-drivers=i965 \
 --with-gallium-drivers= --disable-vdpau --disable-egl \
 --disable-gbm --disable-xvmc
 
 CC: Ian Romanick i...@freedesktop.org

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

 CC: Aaron Watry awa...@gmail.com
 CC: Brian Paul bri...@vmware.com
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71397
 ---
  configure.ac| 44 ++--
  src/glx/Makefile.am |  8 ++--
  src/glx/glxext.c|  4 
  3 files changed, 44 insertions(+), 12 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index 8fb5e0d..f756b73 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -536,6 +536,11 @@ AC_ARG_ENABLE([dri],
  [enable DRI modules @:@default=enabled@:@])],
  [enable_dri=$enableval],
  [enable_dri=yes])
 +AC_ARG_ENABLE([dri3],
 +[AS_HELP_STRING([--enable-dri3],
 +[enable DRI3 @:@default=enabled@:@])],
 +[enable_dri3=$enableval],
 +[enable_dri3=yes])
  AC_ARG_ENABLE([glx],
  [AS_HELP_STRING([--enable-glx],
  [enable GLX library @:@default=enabled@:@])],
 @@ -702,6 +707,7 @@ fi
  AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
x$enable_dri = xyes)
  AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
 +AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
  
  AC_ARG_ENABLE([shared-glapi],
  [AS_HELP_STRING([--enable-shared-glapi],
 @@ -756,6 +762,9 @@ AC_SUBST([MESA_LLVM])
  PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED],
[have_libdrm=yes], [have_libdrm=no])
  
 +PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
 +  have_libudev=yes, have_libudev=no)
 +
  if test x$enable_dri = xyes; then
  # DRI must be shared, I think
  if test $enable_static = yes; then
 @@ -811,13 +820,21 @@ xyesno)
  fi
  PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
  GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
 -PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
 -PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 -PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED])
 +if test x$enable_dri3 = xyes; then
 +if test x$have_libudev != xyes; then
 +  AC_MSG_ERROR([DRI3 requires libudev = $LIBUDEV_REQUIRED])
 +fi
 +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = 
 $DRI3PROTO_REQUIRED])
 +PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 +fi
  fi
  
  # find the DRI deps for libGL
 -dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 
 = 1.8 xcb-dri3 xcb-present xcb-sync xshmfence
 +dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 
 = 1.8
 +
 +if test x$enable_dri3 = xyes; then
 +dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence
 +fi
  
  # add xf86vidmode if available
  PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
 HAVE_XF86VIDMODE=no)
 @@ -827,8 +844,13 @@ xyesno)
  
  PKG_CHECK_MODULES([DRIGL], [$dri_modules])
  GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV $dri_modules
 -X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS
 -GL_LIB_DEPS=$DRIGL_LIBS $LIBUDEV_LIBS
 +X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS
 +GL_LIB_DEPS=$DRIGL_LIBS
 +
 +if test x$enable_dri3$have_libudev = xyesyes; then
 +X11_INCLUDES=$X11_INCLUDES $LIBUDEV_CFLAGS
 +GL_LIB_DEPS=$GL_LIB_DEPS $LIBUDEV_LIBS
 +fi
  
  # need DRM libs, $PTHREAD_LIBS, etc.
  GL_LIB_DEPS=$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS
 @@ -947,6 +969,9 @@ if test x$enable_dri = xyes; then
  linux*)
  DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1
  DEFINES=$DEFINES -DHAVE_ALIAS
 +if test x$enable_dri3 = xyes; then
 +DEFINES=$DEFINES -DHAVE_DRI3
 +fi
  
  case $host_cpu in
  x86_64|amd64)
 @@ -1142,8 +1167,9 @@ if test x$enable_gbm = xauto; then
  esac
  fi
  if test x$enable_gbm = xyes; then
 -PKG_CHECK_MODULES([LIBUDEV], [libudev], [],
 -  AC_MSG_ERROR([gbm needs udev]))
 +if test x$have_libudev != xyes; then
 +AC_MSG_ERROR([gbm needs udev])
 +fi
  
  if test x$enable_dri = xyes; then
  GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
 @@ -1170,8 +1196,6 @@ if test x$enable_egl = 

Re: [Mesa-dev] [PATCH] glx: conditionaly build dri3 and present loader (v3)

[Armin K.]

On 11/09/2013 01:15 AM, Ian Romanick wrote:
 On 11/08/2013 03:06 PM, Armin K wrote:
 This patch makes it possible to disable DRI3 if desired.
 
 Should we squash this with Jose's patch?
 

Yes, that would be nice. They do the same thing but for different build
systems.

 v2:

 Incorporated changes from Ian Romanick and Aaron Watry
 Unified libudev check and made libGL link to it only
 when DRI3 was enabled.

 v3:

 Correct misspelled Ian's last name in commit message.

 Adding Brian Paul to CC since he asked if DRI3 stuff
 can be put behind some sort of config option.

 Tested with:

 ./configure --disable-dri3 --with-dri-drivers=i965 \
 --with-gallium-drivers= --disable-vdpau --disable-egl \
 --disable-gbm --disable-xvmc

 CC: Ian Romanick i...@freedesktop.org
 
 Reviewed-by: Ian Romanick ian.d.roman...@intel.com
 
 CC: Aaron Watry awa...@gmail.com
 CC: Brian Paul bri...@vmware.com
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71397
 ---
  configure.ac| 44 ++--
  src/glx/Makefile.am |  8 ++--
  src/glx/glxext.c|  4 
  3 files changed, 44 insertions(+), 12 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 8fb5e0d..f756b73 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -536,6 +536,11 @@ AC_ARG_ENABLE([dri],
  [enable DRI modules @:@default=enabled@:@])],
  [enable_dri=$enableval],
  [enable_dri=yes])
 +AC_ARG_ENABLE([dri3],
 +[AS_HELP_STRING([--enable-dri3],
 +[enable DRI3 @:@default=enabled@:@])],
 +[enable_dri3=$enableval],
 +[enable_dri3=yes])
  AC_ARG_ENABLE([glx],
  [AS_HELP_STRING([--enable-glx],
  [enable GLX library @:@default=enabled@:@])],
 @@ -702,6 +707,7 @@ fi
  AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
x$enable_dri = xyes)
  AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
 +AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
  
  AC_ARG_ENABLE([shared-glapi],
  [AS_HELP_STRING([--enable-shared-glapi],
 @@ -756,6 +762,9 @@ AC_SUBST([MESA_LLVM])
  PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED],
[have_libdrm=yes], [have_libdrm=no])
  
 +PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
 +  have_libudev=yes, have_libudev=no)
 +
  if test x$enable_dri = xyes; then
  # DRI must be shared, I think
  if test $enable_static = yes; then
 @@ -811,13 +820,21 @@ xyesno)
  fi
  PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
  GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
 -PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED])
 -PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 -PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED])
 +if test x$enable_dri3 = xyes; then
 +if test x$have_libudev != xyes; then
 +  AC_MSG_ERROR([DRI3 requires libudev = $LIBUDEV_REQUIRED])
 +fi
 +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = 
 $DRI3PROTO_REQUIRED])
 +PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 +fi
  fi
  
  # find the DRI deps for libGL
 -dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 
 = 1.8 xcb-dri3 xcb-present xcb-sync xshmfence
 +dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = 1.8.1 xcb-dri2 
 = 1.8
 +
 +if test x$enable_dri3 = xyes; then
 +dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence
 +fi
  
  # add xf86vidmode if available
  PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
 HAVE_XF86VIDMODE=no)
 @@ -827,8 +844,13 @@ xyesno)
  
  PKG_CHECK_MODULES([DRIGL], [$dri_modules])
  GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV $dri_modules
 -X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS
 -GL_LIB_DEPS=$DRIGL_LIBS $LIBUDEV_LIBS
 +X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS
 +GL_LIB_DEPS=$DRIGL_LIBS
 +
 +if test x$enable_dri3$have_libudev = xyesyes; then
 +X11_INCLUDES=$X11_INCLUDES $LIBUDEV_CFLAGS
 +GL_LIB_DEPS=$GL_LIB_DEPS $LIBUDEV_LIBS
 +fi
  
  # need DRM libs, $PTHREAD_LIBS, etc.
  GL_LIB_DEPS=$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS
 @@ -947,6 +969,9 @@ if test x$enable_dri = xyes; then
  linux*)
  DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1
  DEFINES=$DEFINES -DHAVE_ALIAS
 +if test x$enable_dri3 = xyes; then
 +DEFINES=$DEFINES -DHAVE_DRI3
 +fi
  
  case $host_cpu in
  x86_64|amd64)
 @@ -1142,8 +1167,9 @@ if test x$enable_gbm = xauto; then
  esac
  fi
  if test x$enable_gbm = xyes; then
 -PKG_CHECK_MODULES([LIBUDEV], [libudev], [],
 -  AC_MSG_ERROR([gbm needs udev]))
 +if test x$have_libudev != xyes; then
 +AC_MSG_ERROR([gbm needs udev])
 +fi
  
  if test