[Mesa-dev] [PATCH 1/6] trace: Don't dump texture transfers.

[jfonseca]

From: José Fonseca 

Huge trace files with little value.
---
 src/gallium/drivers/trace/tr_context.c |  4 ++--
 src/gallium/drivers/trace/tr_dump.c| 23 ---
 src/gallium/drivers/trace/tr_dump.h|  2 +-
 3 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/trace/tr_context.c 
b/src/gallium/drivers/trace/tr_context.c
index d78dd3e..5514f62 100644
--- a/src/gallium/drivers/trace/tr_context.c
+++ b/src/gallium/drivers/trace/tr_context.c
@@ -1418,7 +1418,7 @@ trace_context_transfer_unmap(struct pipe_context 
*_context,
 
   trace_dump_arg_begin("data");
   trace_dump_box_bytes(tr_trans->map,
-   resource->format,
+   resource,
box,
stride,
layer_stride);
@@ -1464,7 +1464,7 @@ trace_context_transfer_inline_write(struct pipe_context 
*_context,
 
trace_dump_arg_begin("data");
trace_dump_box_bytes(data,
-resource->format,
+resource,
 box,
 stride,
 layer_stride);
diff --git a/src/gallium/drivers/trace/tr_dump.c 
b/src/gallium/drivers/trace/tr_dump.c
index 7111e0d..b6ab503 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -495,19 +495,28 @@ void trace_dump_bytes(const void *data,
 }
 
 void trace_dump_box_bytes(const void *data,
- enum pipe_format format,
+  struct pipe_resource *resource,
  const struct pipe_box *box,
  unsigned stride,
  unsigned slice_stride)
 {
size_t size;
 
-   if (slice_stride)
-  size = box->depth * slice_stride;
-   else if (stride)
-  size = util_format_get_nblocksy(format, box->height) * stride;
-   else {
-  size = util_format_get_nblocksx(format, box->width) * 
util_format_get_blocksize(format);
+   /*
+* Only dump buffer transfers to avoid huge files.
+* TODO: Make this run-time configurable
+*/
+   if (resource->target != PIPE_BUFFER) {
+  size = 0;
+   } else {
+  enum pipe_format format = resource->format;
+  if (slice_stride)
+ size = box->depth * slice_stride;
+  else if (stride)
+ size = util_format_get_nblocksy(format, box->height) * stride;
+  else {
+ size = util_format_get_nblocksx(format, box->width) * 
util_format_get_blocksize(format);
+  }
}
 
trace_dump_bytes(data, size);
diff --git a/src/gallium/drivers/trace/tr_dump.h 
b/src/gallium/drivers/trace/tr_dump.h
index 4737a93..4758755 100644
--- a/src/gallium/drivers/trace/tr_dump.h
+++ b/src/gallium/drivers/trace/tr_dump.h
@@ -88,7 +88,7 @@ void trace_dump_uint(long long unsigned value);
 void trace_dump_float(double value);
 void trace_dump_bytes(const void *data, size_t size);
 void trace_dump_box_bytes(const void *data,
- enum pipe_format format,
+  struct pipe_resource *resource,
  const struct pipe_box *box,
  unsigned stride,
  unsigned slice_stride);
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 3/6] tools/trace: Tool to dump gallium state at any draw call.

[jfonseca]

From: José Fonseca 

Based from the code from the good old python state tracker.

Extremely handy to diagnose regressions in state trackers.
---
 src/gallium/tools/trace/dump_state.py | 633 ++
 src/gallium/tools/trace/parse.py  |   4 +-
 2 files changed, 635 insertions(+), 2 deletions(-)
 create mode 100755 src/gallium/tools/trace/dump_state.py

diff --git a/src/gallium/tools/trace/dump_state.py 
b/src/gallium/tools/trace/dump_state.py
new file mode 100755
index 000..cad23bd
--- /dev/null
+++ b/src/gallium/tools/trace/dump_state.py
@@ -0,0 +1,633 @@
+#!/usr/bin/env python
+##
+# 
+# Copyright 2008-2013, VMware, Inc.
+# All Rights Reserved.
+# 
+# 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, sub license, 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 NON-INFRINGEMENT.
+# IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS 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.
+# 
+##
+
+
+import sys
+import struct
+import json
+import binascii
+import re
+
+import model
+import parse as parser
+
+
+try:
+from struct import unpack_from
+except ImportError:
+def unpack_from(fmt, buf, offset=0):
+size = struct.calcsize(fmt)
+return struct.unpack(fmt, buf[offset:offset + size])
+
+#
+# Some constants
+#
+PIPE_BUFFER = 0
+
+
+def serialize(obj):
+'''JSON serializer function for non-standard Python objects.'''
+
+# Don't dump full blobs, but merely a description of their size and
+# CRC32 hash.
+if isinstance(obj, bytearray):
+crc32 = binascii.crc32(obj)
+if crc32 < 0:
+crc32 += 0x1
+return 'blob(size=%u,crc32=0x%08x)' % (len(obj), crc32)
+
+# If the object has a __json__ method, use it.
+try:
+method = obj.__json__
+except AttributeError:
+raise TypeError(obj)
+else:
+return method()
+
+
+class Struct:
+"""C-like struct.
+
+Python doesn't have C structs, but do its dynamic nature, any object is
+pretty close.
+"""
+
+def __json__(self):
+'''Convert the structure to a standard Python dict, so it can be
+serialized.'''
+
+obj = {}
+for name, value in self.__dict__.items():
+if not name.startswith('_'):
+obj[name] = value
+return obj
+
+
+class Translator(model.Visitor):
+"""Translate model arguments into regular Python objects"""
+
+def __init__(self, interpreter):
+self.interpreter = interpreter
+self.result = None
+
+def visit(self, node):
+self.result = None
+node.visit(self)
+return self.result
+
+def visit_literal(self, node):
+self.result = node.value
+
+def visit_blob(self, node):
+self.result = node
+
+def visit_named_constant(self, node):
+self.result = node.name
+
+def visit_array(self, node):
+array = []
+for element in node.elements:
+array.append(self.visit(element))
+self.result = array
+
+def visit_struct(self, node):
+struct = Struct()
+for member_name, member_node in node.members:
+member_value = self.visit(member_node)
+setattr(struct, member_name, member_value)
+self.result = struct
+
+def visit_pointer(self, node):
+self.result = self.interpreter.lookup_object(node.address)
+
+
+class Dispatcher:
+'''Base class for classes whose methods can dispatch Gallium calls.'''
+
+def __init__(self, interpreter):
+self.interpreter = interpreter
+
+
+class Global(Dispatcher):
+'''Global name space.
+
+For calls that are not associated with objects, i.e, functions and not
+methods.
+'''
+
+def pipe_screen_create(self):
+return Screen(self.interpreter)
+
+def pipe_context_create(self, screen):
+return screen.context_create()
+
+
+class Transfer:
+'''pipe_transfer'''

[Mesa-dev] [PATCH 2/6] tools/trace: Defer blob hex-decoding.

[jfonseca]

From: José Fonseca 

To speed up parsing.
---
 src/gallium/tools/trace/model.py | 31 +--
 src/gallium/tools/trace/parse.py |  5 ++---
 2 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/src/gallium/tools/trace/model.py b/src/gallium/tools/trace/model.py
index 8276a8f..82aca69 100755
--- a/src/gallium/tools/trace/model.py
+++ b/src/gallium/tools/trace/model.py
@@ -32,13 +32,15 @@
 
 import sys
 import string
-import format
+import binascii
 
 try:
 from cStringIO import StringIO
 except ImportError:
 from StringIO import StringIO
 
+import format
+
 
 class Node:
 
@@ -62,6 +64,22 @@ class Literal(Node):
 visitor.visit_literal(self)
 
 
+class Blob(Node):
+
+def __init__(self, value):
+self._rawValue = None
+self._hexValue = value
+
+def getValue(self):
+if self._rawValue is None:
+self._rawValue = binascii.a2b_hex(self._hexValue)
+self._hexValue = None
+return self._rawValue
+
+def visit(self, visitor):
+visitor.visit_blob(self)
+
+
 class NamedConstant(Node):
 
 def __init__(self, name):
@@ -127,6 +145,9 @@ class Visitor:
 def visit_literal(self, node):
 raise NotImplementedError
 
+def visit_blob(self, node):
+raise NotImplementedError
+
 def visit_named_constant(self, node):
 raise NotImplementedError
 
@@ -157,16 +178,14 @@ class PrettyPrinter:
 return
 
 if isinstance(node.value, basestring):
-if len(node.value) >= 4096 or node.value.strip(string.printable):
-self.formatter.address('blob(%u)' % len(node.value))
-#self.formatter.text('...')
-return
-
 self.formatter.literal('"' + node.value + '"')
 return
 
 self.formatter.literal(repr(node.value))
 
+def visit_blob(self, node):
+self.formatter.address('blob()')
+
 def visit_named_constant(self, node):
 self.formatter.literal(node.name)
 
diff --git a/src/gallium/tools/trace/parse.py b/src/gallium/tools/trace/parse.py
index 07f2d6c..d8dce26 100755
--- a/src/gallium/tools/trace/parse.py
+++ b/src/gallium/tools/trace/parse.py
@@ -29,7 +29,6 @@
 
 import sys
 import xml.parsers.expat
-import binascii
 import optparse
 
 from model import *
@@ -305,9 +304,9 @@ class TraceParser(XmlParser):
 
 def parse_bytes(self):
 self.element_start('bytes')
-value = binascii.a2b_hex(self.character_data())
+value = self.character_data()
 self.element_end('bytes')
-return Literal(value)
+return Blob(value)
 
 def parse_array(self):
 self.element_start('array')
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 4/6] tools/trace: Tool to compare json state dumps.

[jfonseca]

From: José Fonseca 

Copied verbatim from apitrace's scripts/jsondiff.py
---
 src/gallium/tools/trace/diff_state.py | 324 ++
 1 file changed, 324 insertions(+)
 create mode 100755 src/gallium/tools/trace/diff_state.py

diff --git a/src/gallium/tools/trace/diff_state.py 
b/src/gallium/tools/trace/diff_state.py
new file mode 100755
index 000..470aeda
--- /dev/null
+++ b/src/gallium/tools/trace/diff_state.py
@@ -0,0 +1,324 @@
+#!/usr/bin/env python
+##
+#
+# Copyright 2011 Jose Fonseca
+# All Rights Reserved.
+#
+# 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 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.
+#
+##/
+
+
+import json
+import optparse
+import re
+import sys
+
+
+def strip_object_hook(obj):
+if '__class__' in obj:
+return None
+for name in obj.keys():
+if name.startswith('__') and name.endswith('__'):
+del obj[name]
+return obj
+
+
+class Visitor:
+
+def visit(self, node, *args, **kwargs):
+if isinstance(node, dict):
+return self.visitObject(node, *args, **kwargs)
+elif isinstance(node, list):
+return self.visitArray(node, *args, **kwargs)
+else:
+return self.visitValue(node, *args, **kwargs)
+
+def visitObject(self, node, *args, **kwargs):
+pass
+
+def visitArray(self, node, *args, **kwargs):
+pass
+
+def visitValue(self, node, *args, **kwargs):
+pass
+
+
+class Dumper(Visitor):
+
+def __init__(self, stream = sys.stdout):
+self.stream = stream
+self.level = 0
+
+def _write(self, s):
+self.stream.write(s)
+
+def _indent(self):
+self._write('  '*self.level)
+
+def _newline(self):
+self._write('\n')
+
+def visitObject(self, node):
+self.enter_object()
+
+members = node.keys()
+members.sort()
+for i in range(len(members)):
+name = members[i]
+value = node[name]
+self.enter_member(name)
+self.visit(value)
+self.leave_member(i == len(members) - 1)
+self.leave_object()
+
+def enter_object(self):
+self._write('{')
+self._newline()
+self.level += 1
+
+def enter_member(self, name):
+self._indent()
+self._write('%s: ' % name)
+
+def leave_member(self, last):
+if not last:
+self._write(',')
+self._newline()
+
+def leave_object(self):
+self.level -= 1
+self._indent()
+self._write('}')
+if self.level <= 0:
+self._newline()
+
+def visitArray(self, node):
+self.enter_array()
+for i in range(len(node)):
+value = node[i]
+self._indent()
+self.visit(value)
+if i != len(node) - 1:
+self._write(',')
+self._newline()
+self.leave_array()
+
+def enter_array(self):
+self._write('[')
+self._newline()
+self.level += 1
+
+def leave_array(self):
+self.level -= 1
+self._indent()
+self._write(']')
+
+def visitValue(self, node):
+self._write(json.dumps(node))
+
+
+
+class Comparer(Visitor):
+
+def __init__(self, ignore_added = False, tolerance = 2.0 ** -24):
+self.ignore_added = ignore_added
+self.tolerance = tolerance
+
+def visitObject(self, a, b):
+if not isinstance(b, dict):
+return False
+if len(a) != len(b) and not self.ignore_added:
+return False
+ak = a.keys()
+bk = b.keys()
+ak.sort()
+bk.sort()
+if ak != bk and not self.ignore_added:
+return False
+for k in ak:
+ae = a[k]
+try:
+be = b[k]
+except KeyError:
+

[Mesa-dev] [PATCH 5/6] tools/trace: Do a better job at comparing multi line strings.

[jfonseca]

From: José Fonseca 

For TGSI diffing.
---
 src/gallium/tools/trace/diff_state.py | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/src/gallium/tools/trace/diff_state.py 
b/src/gallium/tools/trace/diff_state.py
index 470aeda..00853ba 100755
--- a/src/gallium/tools/trace/diff_state.py
+++ b/src/gallium/tools/trace/diff_state.py
@@ -28,6 +28,7 @@
 import json
 import optparse
 import re
+import difflib
 import sys
 
 
@@ -131,7 +132,7 @@ class Dumper(Visitor):
 self._write(']')
 
 def visitValue(self, node):
-self._write(json.dumps(node))
+self._write(json.dumps(node, allow_nan=True))
 
 
 
@@ -246,6 +247,38 @@ class Differ(Visitor):
 self.replace(a, b)
 
 def replace(self, a, b):
+if isinstance(a, basestring) and isinstance(b, basestring):
+if '\n' in a or '\n' in b:
+a = a.splitlines()
+b = b.splitlines()
+differ = difflib.Differ()
+result = differ.compare(a, b)
+self.dumper.level += 1
+for entry in result:
+self.dumper._newline()
+self.dumper._indent()
+tag = entry[:2]
+text = entry[2:]
+if tag == '? ':
+tag = '  '
+prefix = ' '
+text = text.rstrip()
+suffix = ''
+else:
+prefix = '"'
+suffix = '\\n"'
+line = tag + prefix + text + suffix
+self.dumper._write(line)
+self.dumper.level -= 1
+return
+self.dumper.visit(a)
+self.dumper._write(' -> ')
+self.dumper.visit(b)
+
+def isMultilineString(self, value):
+return isinstance(value, basestring) and '\n' in value
+
+def replaceMultilineString(self, a, b):
 self.dumper.visit(a)
 self.dumper._write(' -> ')
 self.dumper.visit(b)
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 6/6] tools/trace: Quick instructions/notes.

[jfonseca]

From: José Fonseca 

---
 src/gallium/tools/trace/README.txt | 39 ++
 src/gallium/tools/trace/TODO.txt   |  9 +
 2 files changed, 48 insertions(+)
 create mode 100644 src/gallium/tools/trace/README.txt
 create mode 100644 src/gallium/tools/trace/TODO.txt

diff --git a/src/gallium/tools/trace/README.txt 
b/src/gallium/tools/trace/README.txt
new file mode 100644
index 000..830cd15
--- /dev/null
+++ b/src/gallium/tools/trace/README.txt
@@ -0,0 +1,39 @@
+These directory contains tools for manipulating traces produced by the trace
+pipe driver.
+
+
+Most debug builds of state trackers already load the trace driver by default.
+To produce a trace do
+
+  export GALLIUM_TRACE=foo.gtrace
+
+and run the application.  You can choose any name, but the .gtrace is
+recommended to avoid confusion with the .trace produced by apitrace.
+
+
+You can dump a trace by doing
+
+  ./dump.py foo.gtrace | less
+
+
+You can dump a JSON file describing the static state at any given draw call
+(e.g., 12345) by
+doing
+
+  ./dump_state.py -v -c 12345 foo.gtrace > foo.json
+
+or by specifying the n-th (e.g, 1st) draw call by doing
+
+  ./dump_state.py -v -d 1 foo.gtrace > foo.json
+
+The state is derived from the call sequence in the trace file, so no dynamic
+(eg. rendered textures) is included.
+
+
+You can compare two JSON files by doing
+
+  ./diff_state.py foo.json boo.json | less
+
+If you're investigating a regression in a state tracker, you can obtain a good
+and bad trace, dump respective state in JSON, and then compare the states to
+identify the problem.
diff --git a/src/gallium/tools/trace/TODO.txt b/src/gallium/tools/trace/TODO.txt
new file mode 100644
index 000..8bb8cfd
--- /dev/null
+++ b/src/gallium/tools/trace/TODO.txt
@@ -0,0 +1,9 @@
+* track more state
+
+  * constant buffers
+
+* organize state better (e.g., group stuff according to the place in the
+  pipeline)
+
+* write an utility that generated a simple graw C code that matches a
+  state dump.
-- 
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] llvmpipe: fix wrong results for queries not in a scene

[Jose Fonseca]

Yes, that's definetely wrong with the newer query types.

And I agree that for most query types, the situation of nothing being drawned 
inside the query is too rare to be of concern.

Though I wonder if we should do better in a follow on patch for time queries -- 
which applications might emit indiscriminately and in huge quantity.  Maybe a 
shortcut to avoid the overhead of setting up a scene, switch to the rasterizer 
threads, wait, etc, will help getting better values. I'm not really sure it is 
relevant -- I suppose that a quick experiment with glretrace -pgpu might tell 
you whether it makes a difference or not.

Eitherway, should get this in as is for now. 

Jose

- Original Message -
> From: Roland Scheidegger 
> 
> The result isn't always 0 in this case (depends on query type),
> so instead of special casing this just use the ordinary path (should result
> in correct values thanks to initialization in query_begin/end), just
> skipping the fence wait.
> ---
>  src/gallium/drivers/llvmpipe/lp_query.c |   21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
> b/src/gallium/drivers/llvmpipe/lp_query.c
> index 386639e..1d3edff 100644
> --- a/src/gallium/drivers/llvmpipe/lp_query.c
> +++ b/src/gallium/drivers/llvmpipe/lp_query.c
> @@ -100,20 +100,17 @@ llvmpipe_get_query_result(struct pipe_context *pipe,
> uint64_t *result = (uint64_t *)vresult;
> int i;
>  
> -   if (!pq->fence) {
> -  /* no fence because there was no scene, so results is zero */
> -  *result = 0;
> -  return TRUE;
> -   }
> -
> -   if (!lp_fence_signalled(pq->fence)) {
> -  if (!lp_fence_issued(pq->fence))
> - llvmpipe_flush(pipe, NULL, __FUNCTION__);
> +   if (pq->fence) {
> +  /* only have a fence if there was a scene */
> +  if (!lp_fence_signalled(pq->fence)) {
> + if (!lp_fence_issued(pq->fence))
> +llvmpipe_flush(pipe, NULL, __FUNCTION__);
>  
> -  if (!wait)
> - return FALSE;
> + if (!wait)
> +return FALSE;
>  
> -  lp_fence_wait(pq->fence);
> + lp_fence_wait(pq->fence);
> +  }
> }
>  
> /* Sum the results from each of the threads:
> --
> 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] [PATCH 1/6] trace: Don't dump texture transfers.

[Brian Paul]

On 06/21/2013 05:53 AM, jfons...@vmware.com wrote:

From: José Fonseca 

Huge trace files with little value.
---
  src/gallium/drivers/trace/tr_context.c |  4 ++--
  src/gallium/drivers/trace/tr_dump.c| 23 ---
  src/gallium/drivers/trace/tr_dump.h|  2 +-
  3 files changed, 19 insertions(+), 10 deletions(-)


The series LGTM.

Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH 02/11] mesa: Remove the Initialized field from framebuffers.

[Brian Paul]

On 06/21/2013 12:07 AM, Eric Anholt wrote:

This existed to tell the core not to call GetBufferSize, except that even
if you didn't set it nothing happened because nobody had a GetBufferSize.
---
  src/mesa/drivers/dri/intel/intel_fbo.c  | 2 --
  src/mesa/drivers/dri/radeon/radeon_common.c | 2 --
  src/mesa/drivers/dri/radeon/radeon_fbo.c| 2 --
  src/mesa/main/mtypes.h  | 2 --
  src/mesa/state_tracker/st_manager.c | 2 --
  5 files changed, 10 deletions(-)



You missed a couple other occurrences of this field:


diff --git a/src/mesa/drivers/osmesa/osmesa.c 
b/src/mesa/drivers/osmesa/osmesa.c

index 241e74f..deb0b93 100644
--- a/src/mesa/drivers/osmesa/osmesa.c
+++ b/src/mesa/drivers/osmesa/osmesa.c
@@ -916,7 +916,6 @@ OSMesaMakeCurrent( OSMesaContext osmesa, void 
*buffer, GLenu

 * osmesa_renderbuffer_storage() function to get called.
 */
_mesa_resize_framebuffer(&osmesa->mesa, osmesa->gl_buffer, width, 
height);

-   osmesa->gl_buffer->Initialized = GL_TRUE; /* XXX TEMPORARY? */

_mesa_make_current( &osmesa->mesa, osmesa->gl_buffer, 
osmesa->gl_buffer );


diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 6455889..b7c94aa 100644
--- a/src/mesa/drivers/x11/xm_api.c
+++ b/src/mesa/drivers/x11/xm_api.c
@@ -1193,7 +1193,6 @@ xmesa_check_and_update_buffer_size(XMesaContext 
xmctx, XMe

   struct gl_context *ctx = xmctx ? &xmctx->mesa : NULL;
   _mesa_resize_framebuffer(ctx, &(drawBuffer->mesa_buffer), width, 
height);

}
-   drawBuffer->mesa_buffer.Initialized = GL_TRUE; /* XXX TEMPORARY? */
 }


With those fixes,
Reviewed-by: Brian Paul 


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

Re: [Mesa-dev] [PATCH 01/11] mesa: Remove Driver.GetBufferSize and its callers.

[Brian Paul]

On 06/21/2013 12:07 AM, Eric Anholt wrote:

Only the GDI driver set it to non-NULL any more, and that driver has a
Viewport hook that should keep it limping along as well as it ever has.
---
  src/mesa/drivers/common/driverfuncs.c|  1 -
  src/mesa/drivers/dri/r200/r200_context.c |  1 -
  src/mesa/drivers/dri/swrast/swrast.c |  1 -
  src/mesa/drivers/osmesa/osmesa.c |  1 -
  src/mesa/drivers/windows/gdi/wmesa.c |  1 -
  src/mesa/drivers/x11/xm_dd.c |  1 -
  src/mesa/main/context.c  | 45 -
  src/mesa/main/dd.h   |  9 -
  src/mesa/main/framebuffer.c  | 69 
  9 files changed, 129 deletions(-)



Tested with llvmpipe, softpipe and swrast.

Tested-by: Brian Paul 
Reviewed-by: Brian Paul 


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

Re: [Mesa-dev] New Device Driver Help‏

[Brian Paul]

On 06/20/2013 06:58 PM, Li Andy wrote:

Hello everyone,

My name is Andy. I am a university student from Canada.
I am currently working on a project which I am trying to port the mesa
library to another device. (the Altera DE2)
I am wondering if anyone can give me some suggestions to get started.
Any information would be great! My email address is lilap...@gmail.com
 / lilap...@hotmail.com
Thank you for your time.


Normally, if someone wanted to write a new driver for a GPU you'd write 
a gallium driver (plus associated winsys code and kernel module).


AFAICT, the Altera DE2 doesn't have a GPU but an FPGA.  Do you want to 
program the FPGA for 3D rendering?  That would be a fun project but a 
big one.  I doubt you'd be able to implement everything needed for a 
full Gallium driver (shaders, texture mapping, etc).


What is your end goal?  Some version of OpenGL or OpenGL ES, or ??

-Brian

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

[Mesa-dev] [PATCH] R600: Improve vector constant loading for EG/SI

[Aaron Watry]

Add some constant load v2i32/v4i32 tests for both EG and SI.

Tested on: Pitcairn (7850) and Cedar (54xx)

Signed-off-by: Aaron Watry 
---
 lib/Target/R600/R600Instructions.td |  3 +++
 lib/Target/R600/SIInstructions.td   | 10 ++
 test/CodeGen/R600/load.vec.ll   | 27 +++
 3 files changed, 40 insertions(+)

diff --git a/lib/Target/R600/R600Instructions.td 
b/lib/Target/R600/R600Instructions.td
index 803f597..219358c 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -1421,6 +1421,9 @@ def CONSTANT_LOAD_eg : VTX_READ_32_eg <1,
   [(set i32:$dst_gpr, (constant_load ADDRVTX_READ:$src_gpr))]
 >;
 
+def CONSTANT_LOAD_128_eg : VTX_READ_128_eg <1,
+  [(set v4i32:$dst_gpr, (constant_load ADDRVTX_READ:$src_gpr))]
+>;
 
 } // End Predicates = [isEG]
 
diff --git a/lib/Target/R600/SIInstructions.td 
b/lib/Target/R600/SIInstructions.td
index 9c96c08..0058c0d 100644
--- a/lib/Target/R600/SIInstructions.td
+++ b/lib/Target/R600/SIInstructions.td
@@ -1629,6 +1629,16 @@ multiclass MUBUFLoad_Pattern ;
 
   def : Pat <
+(vt (constant_ld (add i64:$ptr, (i64 IMM12bit:$offset,
+(Instr_ADDR64 (SI_ADDR64_RSRC (i64 0)), $ptr, (as_i16imm $offset))
+  >;
+
+  def : Pat <
+(vt (constant_ld i64:$ptr)),
+(Instr_ADDR64 (SI_ADDR64_RSRC (i64 0)), $ptr, 0)
+  >;
+
+  def : Pat <
  (vt (constant_ld (add i64:$ptr, i64:$offset))),
  (Instr_ADDR64 (SI_ADDR64_RSRC $ptr), $offset, 0)
   >;
diff --git a/test/CodeGen/R600/load.vec.ll b/test/CodeGen/R600/load.vec.ll
index da1149a..b450b47 100644
--- a/test/CodeGen/R600/load.vec.ll
+++ b/test/CodeGen/R600/load.vec.ll
@@ -23,3 +23,30 @@ define void @load_v4i32(<4 x i32> addrspace(1)* %out, <4 x 
i32> addrspace(1)* %i
   store <4 x i32> %a, <4 x i32> addrspace(1)* %out
   ret void
 }
+
+; Load a v2i32 value from the constant address space.
+; EG-CHECK: @load_const_addrspace_v2i32
+; EG-CHECK: VTX_READ_32 T{{[0-9]+}}.X, T{{[0-9]+}}.X, 4
+; EG-CHECK: VTX_READ_32 T{{[0-9]+}}.X, T{{[0-9]+}}.X, 0
+; SI-CHECK: @load_const_addrspace_v2i32
+; SI-CHECK: BUFFER_LOAD_DWORDX2 VGPR{{[0-9]+}}
+
+define void @load_const_addrspace_v2i32(<2 x i32> addrspace(1)* %out, <2 x 
i32> addrspace(2)* %in) {
+entry:
+  %0 = load <2 x i32> addrspace(2)* %in
+  store <2 x i32> %0, <2 x i32> addrspace(1)* %out
+  ret void
+}
+
+; Load a v4i32 value from the constant address space.
+; EG-CHECK: @load_const_addrspace_v4i32
+; EG-CHECK: VTX_READ_128 T{{[0-9]+}}.XYZW, T{{[0-9]+}}.X, 0
+; SI-CHECK: @load_const_addrspace_v4i32
+; SI-CHECK: BUFFER_LOAD_DWORDX4 VGPR{{[0-9]+}}
+
+define void @load_const_addrspace_v4i32(<4 x i32> addrspace(1)* %out, <4 x 
i32> addrspace(2)* %in) {
+entry:
+  %0 = load <4 x i32> addrspace(2)* %in
+  store <4 x i32> %0, <4 x i32> addrspace(1)* %out
+  ret void
+}
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 1/8] i965: Add debug to INTEL_DEBUG=blorp describing hiz/blit/clear ops.

[Eric Anholt]

I think we've all added instrumentation at one point or another to see
what's being called in blorp.  Now you can quickly get output like:

Testing glCopyPixels(depth).
intel_hiz_exec depth clear to mt 0x16d9160 level 0 layer 0
intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0
intel_hiz_exec hiz ambiguate to mt 0x16d9160 level 0 layer 0
intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp   | 22 ++
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp  | 10 ++
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp |  7 +++
 3 files changed, 39 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 9c9a4a7..c7e7cd2 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -29,6 +29,8 @@
 #include "gen6_blorp.h"
 #include "gen7_blorp.h"
 
+#define FILE_DEBUG_FLAG DEBUG_BLORP
+
 brw_blorp_mip_info::brw_blorp_mip_info()
: mt(NULL),
  level(0),
@@ -160,6 +162,26 @@ void
 intel_hiz_exec(struct intel_context *intel, struct intel_mipmap_tree *mt,
   unsigned int level, unsigned int layer, gen6_hiz_op op)
 {
+   const char *opname = NULL;
+
+   switch (op) {
+   case GEN6_HIZ_OP_DEPTH_RESOLVE:
+  opname = "depth resolve";
+  break;
+   case GEN6_HIZ_OP_HIZ_RESOLVE:
+  opname = "hiz ambiguate";
+  break;
+   case GEN6_HIZ_OP_DEPTH_CLEAR:
+  opname = "depth clear";
+  break;
+   case GEN6_HIZ_OP_NONE:
+  opname = "noop?";
+  break;
+   }
+
+   DBG("%s %s to mt %p level %d layer %d\n",
+   __FUNCTION__, opname, mt, level, layer);
+
brw_hiz_op_params params(mt, level, layer, op);
brw_blorp_exec(intel, ¶ms);
 }
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 8694128..6140345 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -34,6 +34,7 @@
 #include "brw_eu.h"
 #include "brw_state.h"
 
+#define FILE_DEBUG_FLAG DEBUG_BLORP
 
 /**
  * Helper function for handling mirror image blits.
@@ -144,6 +145,15 @@ brw_blorp_blit_miptrees(struct intel_context *intel,
intel_miptree_slice_resolve_depth(intel, src_mt, src_level, src_layer);
intel_miptree_slice_resolve_depth(intel, dst_mt, dst_level, dst_layer);
 
+   DBG("%s from %s mt %p %d %d (%f,%f) (%f,%f)"
+   "to %s mt %p %d %d (%f,%f) (%f,%f) (flip %d,%d)\n",
+   __FUNCTION__,
+   _mesa_get_format_name(src_mt->format), src_mt,
+   src_level, src_layer, src_x0, src_y0, src_x1, src_y1,
+   _mesa_get_format_name(dst_mt->format), dst_mt,
+   dst_level, dst_layer, dst_x0, dst_y0, dst_x1, dst_y1,
+   mirror_x, mirror_y);
+
brw_blorp_blit_params params(brw_context(&intel->ctx),
 src_mt, src_level, src_layer,
 dst_mt, dst_level, dst_layer,
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 85449bd..f925ab3 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -37,6 +37,8 @@ extern "C" {
 #include "brw_eu.h"
 #include "brw_state.h"
 
+#define FILE_DEBUG_FLAG DEBUG_BLORP
+
 struct brw_blorp_const_color_prog_key
 {
bool use_simd16_replicated_data;
@@ -489,6 +491,9 @@ brw_blorp_clear_color(struct intel_context *intel, struct 
gl_framebuffer *fb,
  }
   }
 
+  DBG("%s to mt %p level %d layer %d\n", __FUNCTION__,
+  irb->mt, irb->mt_level, irb->mt_layer);
+
   brw_blorp_exec(intel, ¶ms);
 
   if (is_fast_clear) {
@@ -508,6 +513,8 @@ brw_blorp_resolve_color(struct intel_context *intel, struct 
intel_mipmap_tree *m
 {
struct brw_context *brw = brw_context(&intel->ctx);
 
+   DBG("%s to mt %p\n", __FUNCTION__, mt);
+
brw_blorp_rt_resolve_params params(brw, mt);
brw_blorp_exec(intel, ¶ms);
mt->mcs_state = INTEL_MCS_STATE_RESOLVED;
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 3/8] i915: Use the current drawbuffer's depth for polygon offset scale.

[Eric Anholt]

There's no reason to care about the window system visual's depth for
handling polygon offset in an FBO, and it could only lead to pain.
---
 src/mesa/drivers/dri/i915/intel_tris.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i915/intel_tris.c 
b/src/mesa/drivers/dri/i915/intel_tris.c
index 7c60d84..126094b 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -640,7 +640,7 @@ do {
\
 } while (0)
 
 
-#define DEPTH_SCALE intel->polygon_offset_scale
+#define DEPTH_SCALE (ctx->DrawBuffer->Visual.depthBits == 16 ? 1.0 : 2.0)
 #define UNFILLED_TRI unfilled_tri
 #define UNFILLED_QUAD unfilled_quad
 #define VERT_X(_v) _v->v.x
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 2/8] intel: Add perf debug for glCopyPixels() fallback checks.

[Eric Anholt]

The separate function for the fallback checks wasn't particularly
clarifying things, so I put the improved checks in the caller.
---
 src/mesa/drivers/dri/intel/intel_pixel_copy.c | 72 +++
 1 file changed, 39 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c 
b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
index ac625a6..ba8e06f 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
@@ -44,34 +44,6 @@
 #define FILE_DEBUG_FLAG DEBUG_PIXEL
 
 /**
- * Check if any fragment operations are in effect which might effect
- * glCopyPixels.  Differs from intel_check_blit_fragment_ops in that
- * we allow Scissor.
- */
-static bool
-intel_check_copypixel_blit_fragment_ops(struct gl_context * ctx)
-{
-   if (ctx->NewState)
-  _mesa_update_state(ctx);
-
-   /* Could do logicop with the blitter: 
-*/
-   return !(ctx->_ImageTransferState ||
-ctx->Color.AlphaEnabled ||
-ctx->Depth.Test ||
-ctx->Fog.Enabled ||
-ctx->Stencil._Enabled ||
-!ctx->Color.ColorMask[0][0] ||
-!ctx->Color.ColorMask[0][1] ||
-!ctx->Color.ColorMask[0][2] ||
-!ctx->Color.ColorMask[0][3] ||
-ctx->Texture._EnabledUnits ||
-   ctx->FragmentProgram._Enabled ||
-   ctx->Color.BlendEnabled);
-}
-
-
-/**
  * CopyPixels with the blitter.  Don't support zooming, pixel transfer, etc.
  */
 static bool
@@ -129,12 +101,46 @@ do_blit_copypixels(struct gl_context * ctx,
   return false;
}
 
-   /* Copypixels can be more than a straight copy.  Ensure all the
-* extra operations are disabled:
-*/
-   if (!intel_check_copypixel_blit_fragment_ops(ctx) ||
-   ctx->Pixel.ZoomX != 1.0F || ctx->Pixel.ZoomY != 1.0F)
+   if (ctx->_ImageTransferState) {
+  perf_debug("glCopyPixels(): Unsupported image transfer state\n");
+  return false;
+   }
+
+   if (ctx->Depth.Test) {
+  perf_debug("glCopyPixels(): Unsupported depth test state\n");
+  return false;
+   }
+
+   if (ctx->Stencil._Enabled) {
+  perf_debug("glCopyPixels(): Unsupported stencil test state\n");
   return false;
+   }
+
+   if (ctx->Fog.Enabled ||
+   ctx->Texture._EnabledUnits ||
+   ctx->FragmentProgram._Enabled) {
+  perf_debug("glCopyPixels(): Unsupported fragment shader state\n");
+  return false;
+   }
+
+   if (ctx->Color.AlphaEnabled ||
+   ctx->Color.BlendEnabled) {
+  perf_debug("glCopyPixels(): Unsupported blend state\n");
+  return false;
+   }
+
+   if (!ctx->Color.ColorMask[0][0] ||
+   !ctx->Color.ColorMask[0][1] ||
+   !ctx->Color.ColorMask[0][2] ||
+   !ctx->Color.ColorMask[0][3]) {
+  perf_debug("glCopyPixels(): Unsupported color mask state\n");
+  return false;
+   }
+
+   if (ctx->Pixel.ZoomX != 1.0F || ctx->Pixel.ZoomY != 1.0F) {
+  perf_debug("glCopyPixles(): Unsupported pixel zoom\n");
+  return false;
+   }
 
intel_prepare_render(intel);
 
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 4/8] i965/gen4-5: Stop using bogus polygon_offset_scale field.

[Eric Anholt]

The polygon offset math used for triangles by the WM is "OffsetUnits * 2 *
MRD + OffsetFactor * m" where 'MRD' is the minimum resolvable difference
for the depth buffer (~1/(1<<16) or ~1/(1<<24)), 'm' is the approximated
slope from the GL spec, and '2' is this magic number from the original
i965 code dump that we deviate from the GL spec by because "it makes glean
work" (except that it doesn't, because of some hilarity with 0.5 *
approximately 2.0 != 1.0.  go glean!).

This clipper code for unfilled polygons, on the other hand, was doing
"OffsetUnits * garbage + OffsetFactor * m", where garbage was MRD in the
case of 16-bit depth visual (regardless the FBO's depth resolution), or
128 * MRD for 24-bit depth visual.

This change just makes the unfilled polygons behavior match the WM's
filled polygons behavior.
---
 src/mesa/drivers/dri/i965/brw_clip.c   |  2 +-
 src/mesa/drivers/dri/intel/intel_context.c | 17 -
 src/mesa/drivers/dri/intel/intel_context.h |  2 --
 3 files changed, 1 insertion(+), 20 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip.c 
b/src/mesa/drivers/dri/i965/brw_clip.c
index 3baad86..74d7e7e 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -216,7 +216,7 @@ brw_upload_clip_prog(struct brw_context *brw)
 
if (offset_back || offset_front) {
   /* _NEW_POLYGON, _NEW_BUFFERS */
-  key.offset_units = ctx->Polygon.OffsetUnits * 
brw->intel.polygon_offset_scale;
+  key.offset_units = ctx->Polygon.OffsetUnits * 
ctx->DrawBuffer->_MRD * 2;
   key.offset_factor = ctx->Polygon.OffsetFactor * 
ctx->DrawBuffer->_MRD;
}
 
diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
b/src/mesa/drivers/dri/intel/intel_context.c
index f669ae0..23d8281 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -639,23 +639,6 @@ intelInitContext(struct intel_context *intel,
intel->hw_stencil = mesaVis->stencilBits && mesaVis->depthBits == 24;
intel->hw_stipple = 1;
 
-   /* XXX FBO: this doesn't seem to be used anywhere */
-   switch (mesaVis->depthBits) {
-   case 0: /* what to do in this case? */
-   case 16:
-  intel->polygon_offset_scale = 1.0;
-  break;
-   case 24:
-  intel->polygon_offset_scale = 2.0; /* req'd to pass glean */
-  break;
-   default:
-  assert(0);
-  break;
-   }
-
-   if (intel->gen >= 4)
-  intel->polygon_offset_scale /= 0x;
-
intel->RenderIndex = ~0;
 
intelInitExtensions(ctx);
diff --git a/src/mesa/drivers/dri/intel/intel_context.h 
b/src/mesa/drivers/dri/intel/intel_context.h
index eac65ba..0f1a0c7 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -298,8 +298,6 @@ struct intel_context
struct tnl_attr_map vertex_attrs[VERT_ATTRIB_MAX];
GLuint vertex_attr_count;
 
-   GLfloat polygon_offset_scale;/* dependent on depth_scale, bpp */
-
bool hw_stencil;
bool hw_stipple;
bool no_rast;
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 5/8] i965: Drop unused argument to translate_tex_format().

[Eric Anholt]

---
 src/mesa/drivers/dri/i965/brw_state.h | 1 -
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c  | 2 --
 src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 1 -
 3 files changed, 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index 60b81dc..3ac65cf 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -180,7 +180,6 @@ GLuint translate_tex_target(GLenum target);
 
 GLuint translate_tex_format(struct intel_context *intel,
 gl_format mesa_format,
-   GLenum internal_format,
GLenum depth_mode,
GLenum srgb_decode);
 
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index ceabedb..1642a58 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -735,7 +735,6 @@ brw_render_target_supported(struct intel_context *intel,
 GLuint
 translate_tex_format(struct intel_context *intel,
  gl_format mesa_format,
-GLenum internal_format,
 GLenum depth_mode,
 GLenum srgb_decode)
 {
@@ -980,7 +979,6 @@ brw_update_texture_surface(struct gl_context *ctx,
  BRW_SURFACE_CUBEFACE_ENABLES |
  (translate_tex_format(intel,
 mt->format,
-   firstImage->InternalFormat,
tObj->DepthMode,
sampler->sRGBDecode) <<
   BRW_SURFACE_FORMAT_SHIFT));
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index c2699ab..6d61b1f 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -311,7 +311,6 @@ gen7_update_texture_surface(struct gl_context *ctx,
 
uint32_t tex_format = translate_tex_format(intel,
   mt->format,
-  firstImage->InternalFormat,
   tObj->DepthMode,
   sampler->sRGBDecode);
 
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 6/8] i965: Stop recomputing the miptree's size from the texture image.

[Eric Anholt]

We've already computed what the dimensions of the miptree are, and stored
it in the miptree.
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c  |  9 +++--
 src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 11 ---
 2 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 1642a58..bfa2953 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -961,7 +961,6 @@ brw_update_texture_surface(struct gl_context *ctx,
struct gl_texture_image *firstImage = tObj->Image[0][tObj->BaseLevel];
struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, unit);
uint32_t *surf;
-   int width, height, depth;
uint32_t tile_x, tile_y;
 
if (tObj->Target == GL_TEXTURE_BUFFER) {
@@ -969,8 +968,6 @@ brw_update_texture_surface(struct gl_context *ctx,
   return;
}
 
-   intel_miptree_get_dimensions_for_image(firstImage, &width, &height, &depth);
-
surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
  6 * 4, 32, &binding_table[surf_index]);
 
@@ -988,11 +985,11 @@ brw_update_texture_surface(struct gl_context *ctx,
  &tile_x, &tile_y);
 
surf[2] = ((intelObj->_MaxLevel - tObj->BaseLevel) << BRW_SURFACE_LOD_SHIFT 
|
- (width - 1) << BRW_SURFACE_WIDTH_SHIFT |
- (height - 1) << BRW_SURFACE_HEIGHT_SHIFT);
+ (mt->logical_width0 - 1) << BRW_SURFACE_WIDTH_SHIFT |
+ (mt->logical_height0 - 1) << BRW_SURFACE_HEIGHT_SHIFT);
 
surf[3] = (brw_get_surface_tiling_bits(intelObj->mt->region->tiling) |
- (depth - 1) << BRW_SURFACE_DEPTH_SHIFT |
+ (mt->logical_depth0 - 1) << BRW_SURFACE_DEPTH_SHIFT |
  (intelObj->mt->region->pitch - 1) <<
  BRW_SURFACE_PITCH_SHIFT);
 
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index 6d61b1f..99b00e3 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -295,7 +295,6 @@ gen7_update_texture_surface(struct gl_context *ctx,
struct intel_mipmap_tree *mt = intelObj->mt;
struct gl_texture_image *firstImage = tObj->Image[0][tObj->BaseLevel];
struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, unit);
-   int width, height, depth;
uint32_t tile_x, tile_y;
 
if (tObj->Target == GL_TEXTURE_BUFFER) {
@@ -303,8 +302,6 @@ gen7_update_texture_surface(struct gl_context *ctx,
   return;
}
 
-   intel_miptree_get_dimensions_for_image(firstImage, &width, &height, &depth);
-
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
 8 * 4, 32, &binding_table[surf_index]);
memset(surf, 0, 8 * 4);
@@ -324,7 +321,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
if (mt->align_w == 8)
   surf[0] |= GEN7_SURFACE_HALIGN_8;
 
-   if (depth > 1 && tObj->Target != GL_TEXTURE_3D)
+   if (mt->logical_depth0 > 1 && tObj->Target != GL_TEXTURE_3D)
   surf[0] |= GEN7_SURFACE_IS_ARRAY;
 
if (mt->array_spacing_lod0)
@@ -334,9 +331,9 @@ gen7_update_texture_surface(struct gl_context *ctx,
surf[1] += intel_miptree_get_tile_offsets(intelObj->mt, firstImage->Level, 
0,
  &tile_x, &tile_y);
 
-   surf[2] = SET_FIELD(width - 1, GEN7_SURFACE_WIDTH) |
- SET_FIELD(height - 1, GEN7_SURFACE_HEIGHT);
-   surf[3] = SET_FIELD(depth - 1, BRW_SURFACE_DEPTH) |
+   surf[2] = SET_FIELD(mt->logical_width0 - 1, GEN7_SURFACE_WIDTH) |
+ SET_FIELD(mt->logical_height0 - 1, GEN7_SURFACE_HEIGHT);
+   surf[3] = SET_FIELD(mt->logical_depth0 - 1, BRW_SURFACE_DEPTH) |
  ((intelObj->mt->region->pitch) - 1);
 
surf[4] = gen7_surface_msaa_bits(mt->num_samples, mt->msaa_layout);
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 7/8] intel: Drop little bits of dead code.

[Eric Anholt]

I noticed these while building the fork-i915 branch.
---
 src/mesa/drivers/dri/i915/intel_tris.c | 2 --
 src/mesa/drivers/dri/intel/intel_context.h | 3 ---
 src/mesa/drivers/dri/intel/intel_fbo.h | 1 -
 src/mesa/drivers/dri/intel/intel_screen.h  | 5 -
 src/mesa/drivers/dri/intel/intel_tex_obj.h | 4 
 5 files changed, 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_tris.c 
b/src/mesa/drivers/dri/i915/intel_tris.c
index 126094b..02b225b 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -94,8 +94,6 @@ static void intel_start_inline(struct intel_context *intel, 
uint32_t prim)
 
intel->no_batch_wrap = true;
 
-   /*printf("%s *", __progname);*/
-
/* Emit a slot which will be filled with the inline primitive
 * command later.
 */
diff --git a/src/mesa/drivers/dri/intel/intel_context.h 
b/src/mesa/drivers/dri/intel/intel_context.h
index 0f1a0c7..84452b9 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -359,9 +359,6 @@ struct intel_context
driOptionCache optionCache;
 };
 
-extern char *__progname;
-
-
 #define SUBPIXEL_X 0.125
 #define SUBPIXEL_Y 0.125
 
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.h 
b/src/mesa/drivers/dri/intel/intel_fbo.h
index e1b4df5..5f40d35 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.h
+++ b/src/mesa/drivers/dri/intel/intel_fbo.h
@@ -51,7 +51,6 @@ struct intel_renderbuffer
 {
struct swrast_renderbuffer Base;
struct intel_mipmap_tree *mt; /**< The renderbuffer storage. */
-   drm_intel_bo *map_bo;
 
/**
 * \name Miptree view
diff --git a/src/mesa/drivers/dri/intel/intel_screen.h 
b/src/mesa/drivers/dri/intel/intel_screen.h
index 4833937..188e2c0 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.h
+++ b/src/mesa/drivers/dri/intel/intel_screen.h
@@ -45,12 +45,9 @@ struct intel_screen
int max_gl_es1_version;
int max_gl_es2_version;
 
-   int logTextureGranularity;
-
__DRIscreen *driScrnPriv;
 
bool no_hw;
-   GLuint relaxed_relocations;
 
/*
 * The hardware hiz and separate stencil fields are needed in intel_screen,
@@ -77,8 +74,6 @@ struct intel_screen
driOptionCache optionCache;
 };
 
-extern bool intelMapScreenRegions(__DRIscreen * sPriv);
-
 extern void intelDestroyContext(__DRIcontext * driContextPriv);
 
 extern GLboolean intelUnbindContext(__DRIcontext * driContextPriv);
diff --git a/src/mesa/drivers/dri/intel/intel_tex_obj.h 
b/src/mesa/drivers/dri/intel/intel_tex_obj.h
index 8c166b4..e30dd8a 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_obj.h
+++ b/src/mesa/drivers/dri/intel/intel_tex_obj.h
@@ -41,10 +41,6 @@ struct intel_texture_object
 */
unsigned int _MaxLevel;
 
-   /* Offset for firstLevel image:
-*/
-   GLuint textureOffset;
-
/* On validation any active images held in main memory or in other
 * regions will be copied to this region and the old storage freed.
 */
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH 8/8] i915: Drop dead batch dumping code.

[Eric Anholt]

Batch dumping is now handled by shared code in libdrm.
---
 src/mesa/drivers/dri/i915/Makefile.sources |   1 -
 src/mesa/drivers/dri/i915/i915_debug.c | 843 -
 src/mesa/drivers/dri/i915/i915_debug.h |  16 -
 3 files changed, 860 deletions(-)
 delete mode 100644 src/mesa/drivers/dri/i915/i915_debug.c

diff --git a/src/mesa/drivers/dri/i915/Makefile.sources 
b/src/mesa/drivers/dri/i915/Makefile.sources
index fff27b7..350683b 100644
--- a/src/mesa/drivers/dri/i915/Makefile.sources
+++ b/src/mesa/drivers/dri/i915/Makefile.sources
@@ -32,7 +32,6 @@ i915_FILES = \
i915_tex_layout.c \
i915_texstate.c \
i915_context.c \
-   i915_debug.c \
i915_debug_fp.c \
i915_fragprog.c \
i915_program.c \
diff --git a/src/mesa/drivers/dri/i915/i915_debug.c 
b/src/mesa/drivers/dri/i915/i915_debug.c
deleted file mode 100644
index 53f9c1a..000
--- a/src/mesa/drivers/dri/i915/i915_debug.c
+++ /dev/null
@@ -1,843 +0,0 @@
-/**
- * 
- * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
- * All Rights Reserved.
- * 
- * 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, sub license, 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 NON-INFRINGEMENT.
- * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS 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 "main/imports.h"
-
-#include "i915_reg.h"
-#include "i915_context.h"
-#include "i915_debug.h"
-
-static bool
-debug(struct debug_stream *stream, const char *name, GLuint len)
-{
-   GLuint i;
-   GLuint *ptr = (GLuint *)(stream->ptr + stream->offset);
-   
-   if (len == 0) {
-  printf("Error - zero length packet (0x%08x)\n", stream->ptr[0]);
-  assert(0);
-  return false;
-   }
-
-   if (stream->print_addresses)
-  printf("%08x:  ", stream->offset);
-
-
-   printf("%s (%d dwords):\n", name, len);
-   for (i = 0; i < len; i++)
-  printf("\t0x%08x\n",  ptr[i]);   
-   printf("\n");
-
-   stream->offset += len * sizeof(GLuint);
-   
-   return true;
-}
-
-
-static const char *get_prim_name( GLuint val )
-{
-   switch (val & PRIM3D_MASK) {
-   case PRIM3D_TRILIST: return "TRILIST"; break;
-   case PRIM3D_TRISTRIP: return "TRISTRIP"; break;
-   case PRIM3D_TRISTRIP_RVRSE: return "TRISTRIP_RVRSE"; break;
-   case PRIM3D_TRIFAN: return "TRIFAN"; break;
-   case PRIM3D_POLY: return "POLY"; break;
-   case PRIM3D_LINELIST: return "LINELIST"; break;
-   case PRIM3D_LINESTRIP: return "LINESTRIP"; break;
-   case PRIM3D_RECTLIST: return "RECTLIST"; break;
-   case PRIM3D_POINTLIST: return "POINTLIST"; break;
-   case PRIM3D_DIB: return "DIB"; break;
-   case PRIM3D_CLEAR_RECT: return "CLEAR_RECT"; break;
-   case PRIM3D_ZONE_INIT: return "ZONE_INIT"; break;
-   default: return ""; break;
-   }
-}
-
-static bool
-debug_prim(struct debug_stream *stream, const char *name,
-  bool dump_floats, GLuint len)
-{
-   GLuint *ptr = (GLuint *)(stream->ptr + stream->offset);
-   const char *prim = get_prim_name( ptr[0] );
-   GLuint i;
-   
-
-
-   printf("%s %s (%d dwords):\n", name, prim, len);
-   printf("\t0x%08x\n",  ptr[0]);   
-   for (i = 1; i < len; i++) {
-  if (dump_floats)
-printf("\t0x%08x // %f\n",  ptr[i], *(GLfloat *)&ptr[i]);   
-  else
-printf("\t0x%08x\n",  ptr[i]);   
-   }
-
-  
-   printf("\n");
-
-   stream->offset += len * sizeof(GLuint);
-   
-   return true;
-}
-   
-
-
-
-static bool
-debug_program(struct debug_stream *stream, const char *name, GLuint len)
-{
-   GLuint *ptr = (GLuint *)(stream->ptr + stream->offset);
-
-   if (len == 0) {
-  printf("Error - zero length packet (0x%08x)\n", stream->ptr[0]);
-  assert(0);
-  return false;
-   }
-
-   if (stream->print_addresses)
-  printf("%08x:  ", stream->offset);
-
-   printf("%s (%d dwords):\n", name, len);
-   i915_disassemble_program( ptr, len );
-
-   stream->offset += len * sizeof(GLuint);
-   return true;
-}
-

[Mesa-dev] forking shared intel directory?

[Eric Anholt]

Long ago, when porting FBO and memory management support to i965, I
merged a bunch of code between the i915 and i965 drivers and put it in
the intel directory.  I think it served us well for a long time, as both
drivers got improvements from shared work on that code.  But since then,
we've talked several times about splitting things back apart (since we
break i915 much more often than we improve it), so I spent yesterday and
today looking at what the impact would be.

LOC counts (wc -l):

intel/ i915/   i965/ total
master: 14751  13458   61109 89318
fork-i915:  0  24322   74978 99300

We duplicate ~1 lines of code, but i915 drops ~4000 lines of code
From its build and i965 drops ~1000.

context size:
   i915i965
master:99512   101456
fork-i915: 99384   100824

There's a bunch of cleanup I haven't done in the branch, like moving
brw_vtbl.c contents to sensible places, or nuking the intel vs brw split
that doesn't make any sense any more.

I'm ambivalent about the change.  If the code growth from splitting was
<7000 lines or so, I'd be happy, but this feels pretty big.  On the
other hand, the cleanups feel good to me.  I don't know how other
developers feel.  There's a branch up at fork-i915 of my tree.  If
people are excited about doing this and I get a bunch of acks for the
two "copy the code to my directory" commits, I'll do those two then
start sending out the non-copying changes for review.  If people don't
like it, I won't be hurt.


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

Re: [Mesa-dev] [PATCH 03/11] intel: Remove gratuitous custom framebuffer resize code.

[Anuj Phogat]

On Thu, Jun 20, 2013 at 11:07 PM, Eric Anholt  wrote:
> _mesa_resize_framebuffer(), the default value of the ResizeBuffers hook,
> already checks for a window system framebuffer and walks the renderbuffers
> calling AllocStorage().
> ---
>  src/mesa/drivers/dri/intel/intel_fbo.c | 36 
> ++
>  1 file changed, 6 insertions(+), 30 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c 
> b/src/mesa/drivers/dri/intel/intel_fbo.c
> index 32d1797..d16523b 100644
> --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> @@ -314,9 +314,12 @@ intel_image_target_renderbuffer_storage(struct 
> gl_context *ctx,
>  }
>
>  /**
> - * Called for each hardware renderbuffer when a _window_ is resized.
> - * Just update fields.
> - * Not used for user-created renderbuffers!
> + * Called by _mesa_resize_framebuffer() for each hardware renderbuffer when a
> + * window system framebuffer is resized.
> + *
> + * Any actual buffer reallocations for hardware renderbuffers (which would
> + * have triggered _mesa_resize_framebuffer()) were done by
> + * intel_process_dri2_buffer().
>   */
>  static GLboolean
>  intel_alloc_window_storage(struct gl_context * ctx, struct gl_renderbuffer 
> *rb,
> @@ -330,32 +333,6 @@ intel_alloc_window_storage(struct gl_context * ctx, 
> struct gl_renderbuffer *rb,
> return true;
>  }
>
> -
> -static void
> -intel_resize_buffers(struct gl_context *ctx, struct gl_framebuffer *fb,
> -GLuint width, GLuint height)
> -{
> -   int i;
> -
> -   _mesa_resize_framebuffer(ctx, fb, width, height);
> -
> -   if (_mesa_is_user_fbo(fb)) {
> -  return;
> -   }
> -
> -
> -   /* Make sure all window system renderbuffers are up to date */
> -   for (i = BUFFER_FRONT_LEFT; i <= BUFFER_BACK_RIGHT; i++) {
> -  struct gl_renderbuffer *rb = fb->Attachment[i].Renderbuffer;
> -
> -  /* only resize if size is changing */
> -  if (rb && (rb->Width != width || rb->Height != height)) {
> -rb->AllocStorage(ctx, rb, rb->InternalFormat, width, height);
> -  }
> -   }
> -}
> -
> -
>  /** Dummy function for gl_renderbuffer::AllocStorage() */
>  static GLboolean
>  intel_nop_alloc_storage(struct gl_context * ctx, struct gl_renderbuffer *rb,
> @@ -965,7 +942,6 @@ intel_fbo_init(struct intel_context *intel)
> intel->ctx.Driver.FramebufferRenderbuffer = 
> intel_framebuffer_renderbuffer;
> intel->ctx.Driver.RenderTexture = intel_render_texture;
> intel->ctx.Driver.FinishRenderTexture = intel_finish_render_texture;
> -   intel->ctx.Driver.ResizeBuffers = intel_resize_buffers;
> intel->ctx.Driver.ValidateFramebuffer = intel_validate_framebuffer;
> intel->ctx.Driver.BlitFramebuffer = intel_blit_framebuffer;
> intel->ctx.Driver.EGLImageTargetRenderbufferStorage =
> --
> 1.8.3.rc0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Patches 3, 4-11 are Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] forking shared intel directory?

[Patrick Baggett]

On Fri, Jun 21, 2013 at 1:29 PM, Eric Anholt  wrote:

> Long ago, when porting FBO and memory management support to i965, I
> merged a bunch of code between the i915 and i965 drivers and put it in
> the intel directory.  I think it served us well for a long time, as both
> drivers got improvements from shared work on that code.  But since then,
> we've talked several times about splitting things back apart (since we
> break i915 much more often than we improve it), so I spent yesterday and
> today looking at what the impact would be.
>
>
I'm not a developer, but I like to keep up with the drivers that I have
hardware for. Please take my opinions with a grain of salt.

When you say you break i915 more than you improve it, do you mean to say
that it is difficult to improve !i915 without breaking i915 and therefore
to improve development speed, it should be forked OR that i915 doesn't
receive enough testing / have maintainers who can resolve the issues and so
it burdens other developers to fix i915 and hence slows development?

The reason I ask if because if it is #2, then it sounds like you should be
looking for someone to volunteer as the official i915 maintainer [and if
none, then fork], but if it is #1, then maintainer or not, it will slow
down your efforts.




> LOC counts (wc -l):
>
> intel/ i915/   i965/ total
> master: 14751  13458   61109 89318
> fork-i915:  0  24322   74978 99300
>
> We duplicate ~1 lines of code, but i915 drops ~4000 lines of code
> From its build and i965 drops ~1000.
>
> context size:
>i915i965
> master:99512   101456
> fork-i915: 99384   100824
>
> There's a bunch of cleanup I haven't done in the branch, like moving
> brw_vtbl.c contents to sensible places, or nuking the intel vs brw split
> that doesn't make any sense any more.
>
> I'm ambivalent about the change.  If the code growth from splitting was
> <7000 lines or so, I'd be happy, but this feels pretty big.  On the
> other hand, the cleanups feel good to me.  I don't know how other
> developers feel.  There's a branch up at fork-i915 of my tree.  If
> people are excited about doing this and I get a bunch of acks for the
> two "copy the code to my directory" commits, I'll do those two then
> start sending out the non-copying changes for review.  If people don't
> like it, I won't be hurt.
>
> ___
> 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] intel_draw_buffers overhead reduction (with mesa core changes)

[Kenneth Graunke]

On 06/20/2013 11:07 PM, Eric Anholt wrote:

With some of our new platforms, CPU overhead is becoming a major issue, so
I started poking around the profile of cairo-gl again.  I noticed some
comedy in the FBO statechange path, where i965 was recomputing state
multiple times up front instead of delaying it until draw time.  Most it
originally came from the merge of FBO support to i965, where I flagged
extra state because we didn't have all the required state flags sorted out
at the time.

In the process, I noticed some silly duplicated code between drivers and
Mesa core, and ripped that out.  Should you want to test it, the code is
at the i965-drawbuffers-reduction branch of my Mesa tree.  The end result
for cairo-gl is a 2.2964% +/- 0.459116% improvement in test runtime
(n=31/30).  I didn't analyze which particular patches gave the biggest
wins, though patch 10/11 was big on the profile.


Nice!  Looks good to me.

For the series:
Reviewed-by: Kenneth Graunke 

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

Re: [Mesa-dev] forking shared intel directory?

[Kenneth Graunke]

On 06/21/2013 01:25 PM, Patrick Baggett wrote:

I'm not a developer, but I like to keep up with the drivers that I have
hardware for. Please take my opinions with a grain of salt.

When you say you break i915 more than you improve it, do you mean to say
that it is difficult to improve !i915 without breaking i915 and
therefore to improve development speed, it should be forked OR that i915
doesn't receive enough testing / have maintainers who can resolve the
issues and so it burdens other developers to fix i915 and hence slows
development?

The reason I ask if because if it is #2, then it sounds like you should
be looking for someone to volunteer as the official i915 maintainer [and
if none, then fork], but if it is #1, then maintainer or not, it will
slow down your efforts.


Mostly the former...i915c already supports everything the hardware can 
do, while we're continually adding new features to i965+ (well, mostly 
gen6+).  Things like HiZ, fast color clears, and ETC texture compression 
support affect the common miptree code, but they do nothing for i915 
class hardware...there's only a potential downside of accidental breakage.


The latter is true as well.  Unfortunately, community work is hampered 
by the fact that Intel hasn't released public documentation for i915 
class hardware.  From time to time we've tried to find and motivate the 
right people to make that happen, but it hasn't yet.  Most people in the 
community are also more interested in working on the i915g driver.


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

Re: [Mesa-dev] forking shared intel directory?

[Patrick Baggett]

On Fri, Jun 21, 2013 at 3:53 PM, Kenneth Graunke wrote:

> On 06/21/2013 01:25 PM, Patrick Baggett wrote:
>
>> I'm not a developer, but I like to keep up with the drivers that I have
>> hardware for. Please take my opinions with a grain of salt.
>>
>> When you say you break i915 more than you improve it, do you mean to say
>> that it is difficult to improve !i915 without breaking i915 and
>> therefore to improve development speed, it should be forked OR that i915
>> doesn't receive enough testing / have maintainers who can resolve the
>> issues and so it burdens other developers to fix i915 and hence slows
>> development?
>>
>> The reason I ask if because if it is #2, then it sounds like you should
>> be looking for someone to volunteer as the official i915 maintainer [and
>> if none, then fork], but if it is #1, then maintainer or not, it will
>> slow down your efforts.
>>
>
> Mostly the former...i915c already supports everything the hardware can do,
> while we're continually adding new features to i965+ (well, mostly gen6+).
>  Things like HiZ, fast color clears, and ETC texture compression support
> affect the common miptree code, but they do nothing for i915 class
> hardware...there's only a potential downside of accidental breakage.
>
> The latter is true as well.  Unfortunately, community work is hampered by
> the fact that Intel hasn't released public documentation for i915 class
> hardware.  From time to time we've tried to find and motivate the right
> people to make that happen, but it hasn't yet.  Most people in the
> community are also more interested in working on the i915g driver.
>
>
Ah, thanks for the explanation, though I guess it doesn't do a whole, whole
lot to answer Eric's question.

On a side note: I was interested in the i915g driver, but I couldn't find
any documentation for it other than some architectural information about
the GPU's pipeline. I'm glad I wasn't just lacking the Google-foo. :\
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] forking shared intel directory?

[Patrick Baggett]

> The latter is true as well.  Unfortunately, community work is hampered by
>> the fact that Intel hasn't released public documentation for i915 class
>> hardware.  From time to time we've tried to find and motivate the right
>> people to make that happen, but it hasn't yet.  Most people in the
>> community are also more interested in working on the i915g driver.
>>
>>
> Ah, thanks for the explanation, though I guess it doesn't do a whole,
> whole lot to answer Eric's question.
>
>
That is to say, hearing that there isn't just a lack of maintainer or just
lack of ease for new development doesn't make either option seem better to
me, but you all know what's best here. Thanks for the info!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 63435] [Regression since 9.0] Flickering in EGL OpenGL full-screen window with swap interval 1

[bugzilla-daemon]

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

--- Comment #6 from Eric Anholt  ---
Patch incoming to list (mostly a revert)

-- 
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 63435] [Regression since 9.0] Flickering in EGL OpenGL full-screen window with swap interval 1

[bugzilla-daemon]

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

--- Comment #7 from Eric Anholt  ---
(Oh, and re: "why doesn't anyone care", it was mostly that it wasn't in my
regular bug search that just covers the intel drivers.)

-- 
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] egl: Restore "bogus" DRI2 invalidate event code.

[Eric Anholt]

I had removed it in commit 1e7776ca2bc59a6978d9b933d23852d47078dfa8
because it was obviously wrong -- why do we care whether the server is a
version that emits events, if we're not watching for the server's events,
anyway?  And why would you only invalidate on a server that emits
invalidate events, when the comment said to emit invalidates if the server
*doesn't*?  Only, I missed that we otherwise don't flag that our buffers
might have changed at swap time at all, so the driver was only checking
for new buffers when triggered by the Viewport hack.  Of course you don't
expect Viewport to be called after a swap.

So, this is effectively a revert of the previous commit, except that I
dropped the check for only emitting invalidates on a new server -- we
*always* need to invalidate if we're doing a SwapBuffers.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63435
---
 src/egl/drivers/dri2/platform_x11.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index ccb097f..ec76aec 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -743,6 +743,20 @@ dri2_swap_buffers_msc(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw,
   free(reply);
}
 
+   /* Since we aren't watching for the server's invalidate events like we're
+* supposed to (due to XCB providing no mechanism for filtering the events
+* the way xlib does), and SwapBuffers is a common cause of invalidate
+* events, just shove one down to the driver, even though we haven't told
+* the driver that we're the kind of loader that provides reliable
+* invalidate events.  This causes the driver to request buffers again at
+* its next draw, so that we get the correct buffers if a pageflip
+* happened.  The driver should still be using the viewport hack to catch
+* window resizes.
+*/
+   if (dri2_dpy->flush &&
+   dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
+  (*dri2_dpy->flush->invalidate)(dri2_surf->dri_drawable);
+
return swap_count;
 }
 
-- 
1.8.3.rc0

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

[Mesa-dev] [PATCH] gallium/docs: more documentation for pipe_resource::array_size

[Brian Paul]

It should never be zero and for cube/cube_arrays it should be a
multiple of six.
---
 src/gallium/docs/source/resources.rst |6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/docs/source/resources.rst 
b/src/gallium/docs/source/resources.rst
index 553e335..56a86d6 100644
--- a/src/gallium/docs/source/resources.rst
+++ b/src/gallium/docs/source/resources.rst
@@ -85,6 +85,7 @@ PIPE_TEXTURE_1D / PIPE_TEXTURE_1D_ARRAY
   width must be a power of two
 - height0 must be 1
 - depth0 must be 1
+- array_size must be 1 for PIPE_TEXTURE_1D
 - Mipmaps can be used
 - Must use normalized coordinates
 
@@ -99,6 +100,7 @@ PIPE_TEXTURE_RECT
 2D surface with OpenGL GL_TEXTURE_RECTANGLE semantics.
 
 - depth0 must be 1
+- array_size must be 1
 - last_level must be 0
 - Must use unnormalized coordinates
 - Must use a clamp wrap mode
@@ -117,6 +119,7 @@ PIPE_TEXTURE_2D / PIPE_TEXTURE_2D_ARRAY
 - If PIPE_CAP_NPOT_TEXTURES is not supported,
   width and height must be powers of two
 - depth0 must be 1
+- array_size must be 1 for PIPE_TEXTURE_2D
 - Mipmaps can be used
 - Must use normalized coordinates
 - No special restrictions on wrap modes
@@ -139,6 +142,7 @@ Mipmap dimensions are reduced in all 3 coordinates.
 
 - If PIPE_CAP_NPOT_TEXTURES is not supported,
   width, height and depth must be powers of two
+- array_size must be 1
 - Must use normalized coordinates
 
 OpenGL: GL_TEXTURE_3D in GL 1.2 or GL_EXT_texture3D
@@ -161,6 +165,8 @@ Sampling may be optionally seamless if a driver supports it 
(PIPE_CAP_SEAMLESS_C
 resulting in filtering taking samples from multiple surfaces near to the edge.
 
 - Width and height must be equal
+- depth0 must be 1
+- array_size must be a multiple of 6
 - If PIPE_CAP_NPOT_TEXTURES is not supported,
   width and height must be powers of two
 - Must use normalized coordinates
-- 
1.7.10.4

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

Re: [Mesa-dev] [PATCH] gallium/docs: more documentation for pipe_resource::array_size

[Roland Scheidegger]

Am 22.06.2013 00:26, schrieb Brian Paul:
> It should never be zero and for cube/cube_arrays it should be a
> multiple of six.
> ---
>  src/gallium/docs/source/resources.rst |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/gallium/docs/source/resources.rst 
> b/src/gallium/docs/source/resources.rst
> index 553e335..56a86d6 100644
> --- a/src/gallium/docs/source/resources.rst
> +++ b/src/gallium/docs/source/resources.rst
> @@ -85,6 +85,7 @@ PIPE_TEXTURE_1D / PIPE_TEXTURE_1D_ARRAY
>width must be a power of two
>  - height0 must be 1
>  - depth0 must be 1
> +- array_size must be 1 for PIPE_TEXTURE_1D
>  - Mipmaps can be used
>  - Must use normalized coordinates
>  
> @@ -99,6 +100,7 @@ PIPE_TEXTURE_RECT
>  2D surface with OpenGL GL_TEXTURE_RECTANGLE semantics.
>  
>  - depth0 must be 1
> +- array_size must be 1
>  - last_level must be 0
>  - Must use unnormalized coordinates
>  - Must use a clamp wrap mode
> @@ -117,6 +119,7 @@ PIPE_TEXTURE_2D / PIPE_TEXTURE_2D_ARRAY
>  - If PIPE_CAP_NPOT_TEXTURES is not supported,
>width and height must be powers of two
>  - depth0 must be 1
> +- array_size must be 1 for PIPE_TEXTURE_2D
>  - Mipmaps can be used
>  - Must use normalized coordinates
>  - No special restrictions on wrap modes
> @@ -139,6 +142,7 @@ Mipmap dimensions are reduced in all 3 coordinates.
>  
>  - If PIPE_CAP_NPOT_TEXTURES is not supported,
>width, height and depth must be powers of two
> +- array_size must be 1
>  - Must use normalized coordinates
>  
>  OpenGL: GL_TEXTURE_3D in GL 1.2 or GL_EXT_texture3D
> @@ -161,6 +165,8 @@ Sampling may be optionally seamless if a driver supports 
> it (PIPE_CAP_SEAMLESS_C
>  resulting in filtering taking samples from multiple surfaces near to the 
> edge.
>  
>  - Width and height must be equal
> +- depth0 must be 1
> +- array_size must be a multiple of 6
>  - If PIPE_CAP_NPOT_TEXTURES is not supported,
>width and height must be powers of two
>  - Must use normalized coordinates
> 

LGTM.

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

[Mesa-dev] [Bug 66029] New: More robust way of detecting LLVM major and minor versions

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 66029
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: More robust way of detecting LLVM major and minor
versions
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: klemensb...@gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

Created attachment 81187
  --> https://bugs.freedesktop.org/attachment.cgi?id=81187&action=edit
Use the new version defines if available

LLVM added LLVM_VERSION_MAJOR and LLVM_VERSION_MINOR defines in r150405 (see
http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/107277).

For better compatibility and to avoid breaking in the future, these should be
used instead of the current sed hack that deletes the "svn.*" part from the
`llvm-config --version' output.

The attached patch uses the new defines if available, and falls back to the sed
hack otherwise.

-- 
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 66029] More robust way of detecting LLVM major and minor versions

[bugzilla-daemon]

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

Klemens Baum  changed:

   What|Removed |Added

  Attachment #81187|0   |1
   is patch||

--- Comment #1 from Klemens Baum  ---
Comment on attachment 81187
  --> https://bugs.freedesktop.org/attachment.cgi?id=81187
Use the new version defines if available

>diff --git a/configure.ac b/configure.ac
>index 6832b0d..3cabfe8 100644
>--- a/configure.ac
>+++ b/configure.ac
>@@ -1577,8 +1577,26 @@ if test "x$enable_gallium_llvm" = xyes; then
> fi
>
> if test "x$LLVM_CONFIG" != xno; then
>-  LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
>-  LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e 
>'s/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
>+LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
>+LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
>+LLVM_BINDIR=`$LLVM_CONFIG --bindir`
>+LLVM_CPPFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cppflags"`
>+LLVM_CFLAGS=$LLVM_CPPFLAGS   # CPPFLAGS seem to be sufficient
>+LLVM_CXXFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cxxflags"`
>+LLVM_INCLUDEDIR=`$LLVM_CONFIG --includedir`
>+LLVM_LIBDIR=`$LLVM_CONFIG --libdir`
>+
>+AC_COMPUTE_INT([LLVM_VERSION_MAJOR], [LLVM_VERSION_MAJOR],
>+[#include "${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h"])
>+AC_COMPUTE_INT([LLVM_VERSION_MINOR], [LLVM_VERSION_MINOR],
>+[#include "${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h"])
>+
>+if test "x${LLVM_VERSION_MAJOR}" != x; then
>+LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}"
>+else
>+LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e 
>'s/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
>+fi
>+
> LLVM_COMPONENTS="engine bitwriter"
> if $LLVM_CONFIG --components | grep -q '\'; then
> LLVM_COMPONENTS="${LLVM_COMPONENTS} mcjit"
>@@ -1591,17 +1609,10 @@ if test "x$enable_gallium_llvm" = xyes; then
> LLVM_COMPONENTS="${LLVM_COMPONENTS} irreader"
> fi
> fi
>-  LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
>-  LLVM_BINDIR=`$LLVM_CONFIG --bindir`
>-  LLVM_CPPFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cppflags"`
>-  LLVM_CFLAGS=$LLVM_CPPFLAGS   # CPPFLAGS seem to be sufficient
>-  LLVM_CXXFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cxxflags"`
>-  LLVM_INCLUDEDIR=`$LLVM_CONFIG --includedir`
>-  LLVM_LIBDIR=`$LLVM_CONFIG --libdir`
>-  DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT"
>-  MESA_LLVM=1
>-
>-  dnl Check for Clang interanl headers
>+DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT"
>+MESA_LLVM=1
>+
>+dnl Check for Clang internal headers
> if test "x$enable_opencl" = xyes; then
> if test "x$CLANG_LIBDIR" = x; then
> CLANG_LIBDIR=${LLVM_LIBDIR}
>@@ -1611,8 +1622,8 @@ if test "x$enable_gallium_llvm" = xyes; then
> AC_MSG_ERROR([Could not find clang internal header stddef.h 
> in $CLANG_RESOURCE_DIR Use --with-clang-libdir to specify the correct path to 
> the clang libraries.]))
> fi
> else
>-  MESA_LLVM=0
>-  LLVM_VERSION_INT=0
>+MESA_LLVM=0
>+LLVM_VERSION_INT=0
> fi
> else
> MESA_LLVM=0

-- 
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 66029] More robust way of detecting LLVM major and minor versions

[bugzilla-daemon]

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

Klemens Baum  changed:

   What|Removed |Added

  Attachment #81187|0   |1
is obsolete||

--- Comment #2 from Klemens Baum  ---
Created attachment 81188
  --> https://bugs.freedesktop.org/attachment.cgi?id=81188&action=edit
Use the new version defines if available

Sorry for the previous comment, didn't mark as patch.

-- 
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] Mesa driver for VirtualBox

[Michael Thayer]

On 20/06/13 23:37, Dave Airlie wrote:

On Fri, Jun 21, 2013 at 12:47 AM, Michael Thayer
 wrote:

Hello,

I am looking at the possibility of writing a driver for VirtualBox (ahem,
yes) which could partly live inside of the Mesa tree.  My initial idea was
to have the driver in two parts, a driver/client part in the Mesa tree and a
server part in the VirtualBox tree which would communicate using an
agreed-on protocol through a local socket.  The reasons for wanting to split
the driver this way are on the one hand that we still don't feel quite ready
to commit our host-guest 3D interface to eternity, and on the other that the
driver part on the Mesa side might well be useful in other contexts -
controlled 3D access (insofar as such a thing is possible) out of a sand box
comes to mind.

I was considering a textual protocol between client and server which would
more or less model the Gallium3D API, with (texture and other) buffers
passed using shared memory via file descriptors.  [...]  [The]
fact that we can't directly access the GLSL shader source which applications
on a guest system are presumably trying to send us, and which we need to
pass through to the host, disturbs me somewhat.  [...]


I can't really speak to how good an idea or not this is, however I
have written some code to do something similiar, pushing all the
internal gallium API over a pipe to a GL renderer on the other side of
the pipe. It isn't complete, it was only a stepping stone on my
research to qemu 3D work.


Thank you, that looks very interesting.  I will need a bit of time to 
get into the code, but for a start the shader conversion code looks very 
understandably written.  If I turn it into a driver like I described, is 
it something you would be interested in interfacing to? By the way, is 
the code under the usual Mesa licence?



The biggest issue I see with doing something like that is how to make
final display of things to the X server and making things like texture
from pixmap work efficiently.


We already have code to push OpenGL calls to the graphics card on the 
host system, so this would just be an additional layer of indirection. 
Regarding texture to pixmap, I was thinking of making our DDX use this 
interface too for creating and manipulating pixmaps.  All buffers 
created by a VirtualBox guest with accelerated 3D are just buffers 
created on the host by the VirtualBox process, and DDX pixmaps would 
then also be host buffers, so interchangeable with textures.  (Hope that 
makes sense.  It is getting rather late here...)


Regards,

Michael


The stuff I've done is on the renderer-1 branch of my mesa repo
http://cgit.freedesktop.org/~airlied/mesa/log/?h=renderer-1
but its moved on a lot from that point, and I doubt the pipe code I
wrote even builds anymore, since I've mostly moved to testing it as
part of qemu now. But it currently just passes TGSI shaders through
and converts them into GLSL using an assembler that will look
something like the one in wine I suspect.

Dave.




--
ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24 VirtualBox engineering
71384 Weinstadt, Germany   mailto:michael.tha...@oracle.com

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/12] R600/SI: Expand shl of v2i32/v4i32 for SI

[Tom Stellard]

On Thu, Jun 20, 2013 at 06:43:42PM -0500, Aaron Watry wrote:
> Also add lit test for both cases on SI, and v2i32 for evergreen.
> 
> Signed-off-by: Aaron Watry 
> ---
>  lib/Target/R600/SIISelLowering.cpp |  3 +++
>  test/CodeGen/R600/shl.ll   | 47 
> ++
>  2 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/Target/R600/SIISelLowering.cpp 
> b/lib/Target/R600/SIISelLowering.cpp
> index 30a7de5..515c7a4 100644
> --- a/lib/Target/R600/SIISelLowering.cpp
> +++ b/lib/Target/R600/SIISelLowering.cpp
> @@ -77,6 +77,9 @@ SITargetLowering::SITargetLowering(TargetMachine &TM) :
>setOperationAction(ISD::OR, MVT::v2i32, Expand);
>setOperationAction(ISD::OR, MVT::v4i32, Expand);
>  
> +  setOperationAction(ISD::SHL, MVT::v2i32, Expand);
> +  setOperationAction(ISD::SHL, MVT::v4i32, Expand);
> +
>setOperationAction(ISD::SUB, MVT::v2i32, Expand);
>setOperationAction(ISD::SUB, MVT::v4i32, Expand);
>  
> diff --git a/test/CodeGen/R600/shl.ll b/test/CodeGen/R600/shl.ll
> index db970e9..d68730a 100644
> --- a/test/CodeGen/R600/shl.ll
> +++ b/test/CodeGen/R600/shl.ll
> @@ -1,16 +1,43 @@
> -; RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
> +;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck --check-prefix=EG-CHECK 
> %s
> +;RUN: llc < %s -march=r600 -mcpu=verde | FileCheck --check-prefix=SI-CHECK %s
>  
> -; CHECK: @shl_v4i32
> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> +; XXX: Add SI test for i64 shl once i64 stores and i64 function arguments are
> +; supported.
> +
> +;EG-CHECK: @shl_v2i32
> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +
> +;SI-CHECK: @shl_v2i32
> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
> +
> +define void @shl_v2i32(<2 x i32> addrspace(1)* %out, <2 x i32> addrspace(1)* 
> %in) {
> +  %b_ptr = getelementptr <2 x i32> addrspace(1)* %in, i32 1
> +  %a = load <2 x i32> addrspace(1) * %in
> +  %b = load <2 x i32> addrspace(1) * %b_ptr
> +  %result = shl <2 x i32> %a, %b
> +  store <2 x i32> %result, <2 x i32> addrspace(1)* %out
> +  ret void
> +}
> +
> +;EG-CHECK: @shl_v4i32
> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +
> +;SI-CHECK: @shl_v4i32
> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>  
> -define void @shl_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> %a, <4 x i32> 
> %b) {
> +define void @shl_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> addrspace(1)* 
> %in) {
> +  %b_ptr = getelementptr <4 x i32> addrspace(1)* %in, i32 1
> +  %a = load <4 x i32> addrspace(1) * %in
> +  %b = load <4 x i32> addrspace(1) * %b_ptr
>%result = shl <4 x i32> %a, %b
>store <4 x i32> %result, <4 x i32> addrspace(1)* %out
>ret void
>  }
> -
> -; XXX: Add SI test for i64 shl once i64 stores and i64 function arguments are
> -; supported.

We should leave this comment here.

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

Re: [Mesa-dev] [PATCH 09/12] R600: Add v2i32 test for setcc on evergreen

[Tom Stellard]

On Thu, Jun 20, 2013 at 06:43:47PM -0500, Aaron Watry wrote:
> No test/expansion for SI has been added yet. Attempts to expand this
> operation for SI resulted in a stacktrace in (IIRC) LegalizeIntegerTypes
> which was complaining about vector comparisons being required to return
> a vector type.
>

Could you file a bug for this?

Thanks,
Tom

> Signed-off-by: Aaron Watry 
> ---
>  test/CodeGen/R600/setcc.ll | 25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/test/CodeGen/R600/setcc.ll b/test/CodeGen/R600/setcc.ll
> index 0752f2e..e3f77b1 100644
> --- a/test/CodeGen/R600/setcc.ll
> +++ b/test/CodeGen/R600/setcc.ll
> @@ -1,7 +1,26 @@
> -;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
> -;CHECK: SETE_INT T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> +;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck --check-prefix=EG-CHECK 
> %s
>  
> -define void @test(<4 x i32> addrspace(1)* %out, <4 x i32> addrspace(1)* %in) 
> {
> +;EG-CHECK: @test2
> +;EG-CHECK: SETE_INT {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: SETE_INT {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +
> +define void @test2(<2 x i32> addrspace(1)* %out, <2 x i32> addrspace(1)* 
> %in) {
> +  %b_ptr = getelementptr <2 x i32> addrspace(1)* %in, i32 1
> +  %a = load <2 x i32> addrspace(1) * %in
> +  %b = load <2 x i32> addrspace(1) * %b_ptr
> +  %result = icmp eq <2 x i32> %a, %b
> +  %sext = sext <2 x i1> %result to <2 x i32>
> +  store <2 x i32> %sext, <2 x i32> addrspace(1)* %out
> +  ret void
> +}
> +
> +;EG-CHECK: @test4
> +;EG-CHECK: SETE_INT {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: SETE_INT {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: SETE_INT {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: SETE_INT {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +
> +define void @test4(<4 x i32> addrspace(1)* %out, <4 x i32> addrspace(1)* 
> %in) {
>%b_ptr = getelementptr <4 x i32> addrspace(1)* %in, i32 1
>%a = load <4 x i32> addrspace(1) * %in
>%b = load <4 x i32> addrspace(1) * %b_ptr
> -- 
> 1.8.1.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/12] R600: Add v2i32 test for vselect

[Tom Stellard]

On Thu, Jun 20, 2013 at 06:43:49PM -0500, Aaron Watry wrote:
> Note: Only adding test for evergreen, not SI yet.
> 
> When I attempted to expand vselect for SI, I got the following:
> llc: 
> /home/awatry/src/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:522:
> llvm::SDValue llvm::DAGTypeLegalizer::PromoteIntRes_SETCC(llvm::SDNode*):
> Assertion `SVT.isVector() == N->getOperand(0).getValueType().isVector() &&
> "Vector compare must return a vector result!"' failed.
>

Can you file a bug for this one too?

Thanks,
Tom

> Signed-off-by: Aaron Watry 
> ---
>  test/CodeGen/R600/vselect.ll | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/test/CodeGen/R600/vselect.ll b/test/CodeGen/R600/vselect.ll
> index edd7ba0..3f08cec 100644
> --- a/test/CodeGen/R600/vselect.ll
> +++ b/test/CodeGen/R600/vselect.ll
> @@ -1,10 +1,24 @@
> -;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
> +;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck --check-prefix=EG-CHECK 
> %s
>  
> -; CHECK: @test_select_v4i32
> -; CHECK: CNDE_INT T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> -; CHECK: CNDE_INT * T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> -; CHECK: CNDE_INT T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> -; CHECK: CNDE_INT * T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: @test_select_v2i32
> +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +
> +define void @test_select_v2i32(<2 x i32> addrspace(1)* %out, <2 x i32> 
> addrspace(1)* %in0, <2 x i32> addrspace(1)* %in1) {
> +entry:
> +  %0 = load <2 x i32> addrspace(1)* %in0
> +  %1 = load <2 x i32> addrspace(1)* %in1
> +  %cmp = icmp ne <2 x i32> %0, %1
> +  %result = select <2 x i1> %cmp, <2 x i32> %0, <2 x i32> %1
> +  store <2 x i32> %result, <2 x i32> addrspace(1)* %out
> +  ret void
> +}
> +
> +;EG-CHECK: @test_select_v4i32
> +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
> +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW], T[0-9]+\.[XYZW], 
> T[0-9]+\.[XYZW]}}
>  
>  define void @test_select_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> 
> addrspace(1)* %in0, <4 x i32> addrspace(1)* %in1) {
>  entry:
> -- 
> 1.8.1.2
> 
> ___
> llvm-commits mailing list
> llvm-comm...@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] R600: Expand integer operations for SI and consolidate code with EG

[Tom Stellard]

On Thu, Jun 20, 2013 at 06:43:38PM -0500, Aaron Watry wrote:
> This series is intended to bring SI closer to evergreen when it comes to
> support for v2i32/v4i32 integer operations.
> 
> It adds support for expanding the following v2i32/v4i32 operations on SI:
> AND, MUL, OR, SHL, SRL, ASHR, UDIV, UREM, XOR
> 
> Once that's done, the setOperationAction(op,type,Expand) calls that appear in
> both R600ISelLowering.cpp and SIISelLowering.cpp are all moved to
> AMDGPUISelLowering.cpp.  If we decide to implement these ops through native
> instructions for either target in the future, we can override that in the
> individual targets.
> 
> Signed-off-by: Aaron Watry 

Just one small comment on the SHL patch, but with that fixed these
patches are:

Reviewed-by: Tom Stellard 

> 
> R600/SI: Expand and of v2i32/v4i32 for SI
> R600/SI: Expand mul of v2i32/v4i32 for SI
> R600/SI: Expand or of v2i32/v4i32 for SI
> R600/SI: Expand shl of v2i32/v4i32 for SI
> R600/SI: Expand srl of v2i32/v4i32 for SI
> R600/SI: Expand ashr of v2i32/v4i32 for SI
> R600/SI: Expand udiv v[24]i32 for SI and v2i32 for EG
> R600/SI: Expand urem of v2i32/v4i32 for SI
> R600: Add v2i32 test for setcc on evergreen
> R600/SI: Expand xor v2i32/v4i32
> R600: Add v2i32 test for vselect
> R600: Consolidate expansion of v2i32/v4i32 ops for SI/EG
> 
>  lib/Target/R600/AMDGPUISelLowering.cpp | 22 
>  lib/Target/R600/R600ISelLowering.cpp   | 18 -
>  lib/Target/R600/SIISelLowering.cpp |  5 
>  test/CodeGen/R600/and.ll   | 37 +-
>  test/CodeGen/R600/mul.ll   | 38 ++-
>  test/CodeGen/R600/or.ll| 41 -
>  test/CodeGen/R600/setcc.ll | 25 +++---
>  test/CodeGen/R600/shl.ll   | 47 
> ++
>  test/CodeGen/R600/sra.ll   | 41 -
>  test/CodeGen/R600/srl.ll   | 42 +-
>  test/CodeGen/R600/udiv.ll  | 25 +++---
>  test/CodeGen/R600/urem.ll  | 27 ---
>  test/CodeGen/R600/vselect.ll   | 26 ++-
>  test/CodeGen/R600/xor.ll   | 40 -
>  14 files changed, 345 insertions(+), 89 deletions(-)
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] R600: Improve vector constant loading for EG/SI

[Tom Stellard]

On Fri, Jun 21, 2013 at 09:44:29AM -0500, Aaron Watry wrote:
> Add some constant load v2i32/v4i32 tests for both EG and SI.
> 
> Tested on: Pitcairn (7850) and Cedar (54xx)
> 
> Signed-off-by: Aaron Watry 
> ---
>  lib/Target/R600/R600Instructions.td |  3 +++
>  lib/Target/R600/SIInstructions.td   | 10 ++
>  test/CodeGen/R600/load.vec.ll   | 27 +++
>  3 files changed, 40 insertions(+)
> 
> diff --git a/lib/Target/R600/R600Instructions.td 
> b/lib/Target/R600/R600Instructions.td
> index 803f597..219358c 100644
> --- a/lib/Target/R600/R600Instructions.td
> +++ b/lib/Target/R600/R600Instructions.td
> @@ -1421,6 +1421,9 @@ def CONSTANT_LOAD_eg : VTX_READ_32_eg <1,
>[(set i32:$dst_gpr, (constant_load ADDRVTX_READ:$src_gpr))]
>  >;
>  
> +def CONSTANT_LOAD_128_eg : VTX_READ_128_eg <1,
> +  [(set v4i32:$dst_gpr, (constant_load ADDRVTX_READ:$src_gpr))]
> +>;
>  

It would be nice if you could add the equivalent instruction for Cayman
too.

>  } // End Predicates = [isEG]
>  
> diff --git a/lib/Target/R600/SIInstructions.td 
> b/lib/Target/R600/SIInstructions.td
> index 9c96c08..0058c0d 100644
> --- a/lib/Target/R600/SIInstructions.td
> +++ b/lib/Target/R600/SIInstructions.td
> @@ -1629,6 +1629,16 @@ multiclass MUBUFLoad_Pattern  ValueType vt,
>>;
>  
>def : Pat <
> +(vt (constant_ld (add i64:$ptr, (i64 IMM12bit:$offset,
> +(Instr_ADDR64 (SI_ADDR64_RSRC (i64 0)), $ptr, (as_i16imm $offset))
> +  >;
> +
> +  def : Pat <
> +(vt (constant_ld i64:$ptr)),
> +(Instr_ADDR64 (SI_ADDR64_RSRC (i64 0)), $ptr, 0)
> +  >;
> +
> +  def : Pat <
>   (vt (constant_ld (add i64:$ptr, i64:$offset))),
>   (Instr_ADDR64 (SI_ADDR64_RSRC $ptr), $offset, 0)
>>;
> diff --git a/test/CodeGen/R600/load.vec.ll b/test/CodeGen/R600/load.vec.ll
> index da1149a..b450b47 100644
> --- a/test/CodeGen/R600/load.vec.ll
> +++ b/test/CodeGen/R600/load.vec.ll
> @@ -23,3 +23,30 @@ define void @load_v4i32(<4 x i32> addrspace(1)* %out, <4 x 
> i32> addrspace(1)* %i
>store <4 x i32> %a, <4 x i32> addrspace(1)* %out
>ret void
>  }
> +
> +; Load a v2i32 value from the constant address space.
> +; EG-CHECK: @load_const_addrspace_v2i32
> +; EG-CHECK: VTX_READ_32 T{{[0-9]+}}.X, T{{[0-9]+}}.X, 4
> +; EG-CHECK: VTX_READ_32 T{{[0-9]+}}.X, T{{[0-9]+}}.X, 0

Since these two VTX_READ instructions could appear in any order, you
should use the EG-CHECK-DAG directive.

-Tom

> +; SI-CHECK: @load_const_addrspace_v2i32
> +; SI-CHECK: BUFFER_LOAD_DWORDX2 VGPR{{[0-9]+}}
> +
> +define void @load_const_addrspace_v2i32(<2 x i32> addrspace(1)* %out, <2 x 
> i32> addrspace(2)* %in) {
> +entry:
> +  %0 = load <2 x i32> addrspace(2)* %in
> +  store <2 x i32> %0, <2 x i32> addrspace(1)* %out
> +  ret void
> +}
> +
> +; Load a v4i32 value from the constant address space.
> +; EG-CHECK: @load_const_addrspace_v4i32
> +; EG-CHECK: VTX_READ_128 T{{[0-9]+}}.XYZW, T{{[0-9]+}}.X, 0
> +; SI-CHECK: @load_const_addrspace_v4i32
> +; SI-CHECK: BUFFER_LOAD_DWORDX4 VGPR{{[0-9]+}}
> +
> +define void @load_const_addrspace_v4i32(<4 x i32> addrspace(1)* %out, <4 x 
> i32> addrspace(2)* %in) {
> +entry:
> +  %0 = load <4 x i32> addrspace(2)* %in
> +  store <4 x i32> %0, <4 x i32> addrspace(1)* %out
> +  ret void
> +}
> -- 
> 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] R600: Expand SUB for v2i32/v4i32

[Tom Stellard]

On Wed, May 08, 2013 at 06:19:11PM -0500, Aaron Watry wrote:
> Signed-off-by: Aaron Watry 

I'm afraid I overlooked this patch, sorry.

Reviewed-by: Tom Stellard 

> ---
>  lib/Target/R600/R600ISelLowering.cpp |2 ++
>  test/CodeGen/R600/sub.ll |   15 +++
>  2 files changed, 17 insertions(+)
>  create mode 100644 test/CodeGen/R600/sub.ll
> 
> diff --git a/lib/Target/R600/R600ISelLowering.cpp 
> b/lib/Target/R600/R600ISelLowering.cpp
> index b982279..7252235 100644
> --- a/lib/Target/R600/R600ISelLowering.cpp
> +++ b/lib/Target/R600/R600ISelLowering.cpp
> @@ -54,6 +54,8 @@ R600TargetLowering::R600TargetLowering(TargetMachine &TM) :
>setOperationAction(ISD::SRL, MVT::v2i32, Expand);
>setOperationAction(ISD::SRA, MVT::v4i32, Expand);
>setOperationAction(ISD::SRA, MVT::v2i32, Expand);
> +  setOperationAction(ISD::SUB, MVT::v4i32, Expand);
> +  setOperationAction(ISD::SUB, MVT::v2i32, Expand);
>setOperationAction(ISD::UINT_TO_FP, MVT::v4i32, Expand);
>setOperationAction(ISD::UDIV, MVT::v4i32, Expand);
>setOperationAction(ISD::UREM, MVT::v4i32, Expand);
> diff --git a/test/CodeGen/R600/sub.ll b/test/CodeGen/R600/sub.ll
> new file mode 100644
> index 000..12bfba3
> --- /dev/null
> +++ b/test/CodeGen/R600/sub.ll
> @@ -0,0 +1,15 @@
> +;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
> +
> +;CHECK: SUB_INT T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> +;CHECK: SUB_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> +;CHECK: SUB_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> +;CHECK: SUB_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> +
> +define void @test(<4 x i32> addrspace(1)* %out, <4 x i32> addrspace(1)* %in) 
> {
> +  %b_ptr = getelementptr <4 x i32> addrspace(1)* %in, i32 1
> +  %a = load <4 x i32> addrspace(1) * %in
> +  %b = load <4 x i32> addrspace(1) * %b_ptr
> +  %result = sub <4 x i32> %a, %b
> +  store <4 x i32> %result, <4 x i32> addrspace(1)* %out
> +  ret void
> +}
> -- 
> 1.7.10.4
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/12] R600/SI: Expand shl of v2i32/v4i32 for SI

[Aaron Watry]

I moved it to the top of the file, if that's ok...  although I guess I
could leave it at the bottom if you want..

--Aaron

On Fri, Jun 21, 2013 at 9:05 PM, Tom Stellard  wrote:
> On Thu, Jun 20, 2013 at 06:43:42PM -0500, Aaron Watry wrote:
>> Also add lit test for both cases on SI, and v2i32 for evergreen.
>>
>> Signed-off-by: Aaron Watry 
>> ---
>>  lib/Target/R600/SIISelLowering.cpp |  3 +++
>>  test/CodeGen/R600/shl.ll   | 47 
>> ++
>>  2 files changed, 40 insertions(+), 10 deletions(-)
>>
>> diff --git a/lib/Target/R600/SIISelLowering.cpp 
>> b/lib/Target/R600/SIISelLowering.cpp
>> index 30a7de5..515c7a4 100644
>> --- a/lib/Target/R600/SIISelLowering.cpp
>> +++ b/lib/Target/R600/SIISelLowering.cpp
>> @@ -77,6 +77,9 @@ SITargetLowering::SITargetLowering(TargetMachine &TM) :
>>setOperationAction(ISD::OR, MVT::v2i32, Expand);
>>setOperationAction(ISD::OR, MVT::v4i32, Expand);
>>
>> +  setOperationAction(ISD::SHL, MVT::v2i32, Expand);
>> +  setOperationAction(ISD::SHL, MVT::v4i32, Expand);
>> +
>>setOperationAction(ISD::SUB, MVT::v2i32, Expand);
>>setOperationAction(ISD::SUB, MVT::v4i32, Expand);
>>
>> diff --git a/test/CodeGen/R600/shl.ll b/test/CodeGen/R600/shl.ll
>> index db970e9..d68730a 100644
>> --- a/test/CodeGen/R600/shl.ll
>> +++ b/test/CodeGen/R600/shl.ll
>> @@ -1,16 +1,43 @@
>> -; RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
>> +;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck 
>> --check-prefix=EG-CHECK %s
>> +;RUN: llc < %s -march=r600 -mcpu=verde | FileCheck --check-prefix=SI-CHECK 
>> %s
>>
>> -; CHECK: @shl_v4i32
>> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
>> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
>> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
>> -; CHECK: LSHL * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
>> +; XXX: Add SI test for i64 shl once i64 stores and i64 function arguments 
>> are
>> +; supported.
>> +
>> +;EG-CHECK: @shl_v2i32
>> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
>> T[0-9]+\.[XYZW]}}
>> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
>> T[0-9]+\.[XYZW]}}
>> +
>> +;SI-CHECK: @shl_v2i32
>> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>> +
>> +define void @shl_v2i32(<2 x i32> addrspace(1)* %out, <2 x i32> 
>> addrspace(1)* %in) {
>> +  %b_ptr = getelementptr <2 x i32> addrspace(1)* %in, i32 1
>> +  %a = load <2 x i32> addrspace(1) * %in
>> +  %b = load <2 x i32> addrspace(1) * %b_ptr
>> +  %result = shl <2 x i32> %a, %b
>> +  store <2 x i32> %result, <2 x i32> addrspace(1)* %out
>> +  ret void
>> +}
>> +
>> +;EG-CHECK: @shl_v4i32
>> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
>> T[0-9]+\.[XYZW]}}
>> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
>> T[0-9]+\.[XYZW]}}
>> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
>> T[0-9]+\.[XYZW]}}
>> +;EG-CHECK: LSHL {{\*? *}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
>> T[0-9]+\.[XYZW]}}
>> +
>> +;SI-CHECK: @shl_v4i32
>> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>> +;SI-CHECK: V_LSHL_B32_e32 VGPR{{[0-9]+, VGPR[0-9]+, VGPR[0-9]+}}
>>
>> -define void @shl_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> %a, <4 x 
>> i32> %b) {
>> +define void @shl_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> 
>> addrspace(1)* %in) {
>> +  %b_ptr = getelementptr <4 x i32> addrspace(1)* %in, i32 1
>> +  %a = load <4 x i32> addrspace(1) * %in
>> +  %b = load <4 x i32> addrspace(1) * %b_ptr
>>%result = shl <4 x i32> %a, %b
>>store <4 x i32> %result, <4 x i32> addrspace(1)* %out
>>ret void
>>  }
>> -
>> -; XXX: Add SI test for i64 shl once i64 stores and i64 function arguments 
>> are
>> -; supported.
>
> We should leave this comment here.
>
> -Tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/8] intel: Add perf debug for glCopyPixels() fallback checks.

[Kenneth Graunke]

On 06/21/2013 10:57 AM, Eric Anholt wrote:

The separate function for the fallback checks wasn't particularly
clarifying things, so I put the improved checks in the caller.
---
  src/mesa/drivers/dri/intel/intel_pixel_copy.c | 72 +++
  1 file changed, 39 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c 
b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
index ac625a6..ba8e06f 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
@@ -44,34 +44,6 @@
  #define FILE_DEBUG_FLAG DEBUG_PIXEL

  /**
- * Check if any fragment operations are in effect which might effect
- * glCopyPixels.  Differs from intel_check_blit_fragment_ops in that
- * we allow Scissor.
- */
-static bool
-intel_check_copypixel_blit_fragment_ops(struct gl_context * ctx)
-{
-   if (ctx->NewState)
-  _mesa_update_state(ctx);


You didn't fold this hunk into the caller.  Care to explain why it's 
safe to not call _mesa_update_state(ctx) in your commit message?  (Or 
remove it as a separate patch just before this?)


Otherwise, I like this change!


-   /* Could do logicop with the blitter:
-*/
-   return !(ctx->_ImageTransferState ||
-ctx->Color.AlphaEnabled ||
-ctx->Depth.Test ||
-ctx->Fog.Enabled ||
-ctx->Stencil._Enabled ||
-!ctx->Color.ColorMask[0][0] ||
-!ctx->Color.ColorMask[0][1] ||
-!ctx->Color.ColorMask[0][2] ||
-!ctx->Color.ColorMask[0][3] ||
-ctx->Texture._EnabledUnits ||
-   ctx->FragmentProgram._Enabled ||
-   ctx->Color.BlendEnabled);
-}
-
-
-/**
   * CopyPixels with the blitter.  Don't support zooming, pixel transfer, etc.
   */
  static bool
@@ -129,12 +101,46 @@ do_blit_copypixels(struct gl_context * ctx,
return false;
 }

-   /* Copypixels can be more than a straight copy.  Ensure all the
-* extra operations are disabled:
-*/
-   if (!intel_check_copypixel_blit_fragment_ops(ctx) ||
-   ctx->Pixel.ZoomX != 1.0F || ctx->Pixel.ZoomY != 1.0F)
+   if (ctx->_ImageTransferState) {
+  perf_debug("glCopyPixels(): Unsupported image transfer state\n");
+  return false;
+   }
+
+   if (ctx->Depth.Test) {
+  perf_debug("glCopyPixels(): Unsupported depth test state\n");
+  return false;
+   }
+
+   if (ctx->Stencil._Enabled) {
+  perf_debug("glCopyPixels(): Unsupported stencil test state\n");
return false;
+   }
+
+   if (ctx->Fog.Enabled ||
+   ctx->Texture._EnabledUnits ||
+   ctx->FragmentProgram._Enabled) {
+  perf_debug("glCopyPixels(): Unsupported fragment shader state\n");
+  return false;
+   }
+
+   if (ctx->Color.AlphaEnabled ||
+   ctx->Color.BlendEnabled) {
+  perf_debug("glCopyPixels(): Unsupported blend state\n");
+  return false;
+   }
+
+   if (!ctx->Color.ColorMask[0][0] ||
+   !ctx->Color.ColorMask[0][1] ||
+   !ctx->Color.ColorMask[0][2] ||
+   !ctx->Color.ColorMask[0][3]) {
+  perf_debug("glCopyPixels(): Unsupported color mask state\n");
+  return false;
+   }
+
+   if (ctx->Pixel.ZoomX != 1.0F || ctx->Pixel.ZoomY != 1.0F) {
+  perf_debug("glCopyPixles(): Unsupported pixel zoom\n");
+  return false;
+   }

 intel_prepare_render(intel);




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

Re: [Mesa-dev] [PATCH 8/8] i915: Drop dead batch dumping code.

[Kenneth Graunke]

On 06/21/2013 10:57 AM, Eric Anholt wrote:

Batch dumping is now handled by shared code in libdrm.
---
  src/mesa/drivers/dri/i915/Makefile.sources |   1 -
  src/mesa/drivers/dri/i915/i915_debug.c | 843 -
  src/mesa/drivers/dri/i915/i915_debug.h |  16 -
  3 files changed, 860 deletions(-)
  delete mode 100644 src/mesa/drivers/dri/i915/i915_debug.c


For some reason I thought that only worked on Gen4+.  If it works on 
Gen3, then I'm okay with removing this.  Acked-by.


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

Re: [Mesa-dev] [PATCH 4/8] i965/gen4-5: Stop using bogus polygon_offset_scale field.

[Kenneth Graunke]

On 06/21/2013 10:57 AM, Eric Anholt wrote:

The polygon offset math used for triangles by the WM is "OffsetUnits * 2 *
MRD + OffsetFactor * m" where 'MRD' is the minimum resolvable difference
for the depth buffer (~1/(1<<16) or ~1/(1<<24)), 'm' is the approximated
slope from the GL spec, and '2' is this magic number from the original
i965 code dump that we deviate from the GL spec by because "it makes glean
work" (except that it doesn't, because of some hilarity with 0.5 *
approximately 2.0 != 1.0.  go glean!).

This clipper code for unfilled polygons, on the other hand, was doing
"OffsetUnits * garbage + OffsetFactor * m", where garbage was MRD in the
case of 16-bit depth visual (regardless the FBO's depth resolution), or
128 * MRD for 24-bit depth visual.

This change just makes the unfilled polygons behavior match the WM's
filled polygons behavior.


Thanks!  I was just looking at this code earlier today and got very 
confused.  Nice to see it go.  This passes Keith's polygon-offset test 
on Ivybridge.


Patches 1-7 are:
Reviewed-by: Kenneth Graunke 
(assuming the _mesa_update_state() removed in patch 2 really isn't 
necessary)


Patch 8 is:
Acked-by: Kenneth Graunke 

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

Re: [Mesa-dev] forking shared intel directory?

[Kenneth Graunke]

On 06/21/2013 11:29 AM, Eric Anholt wrote:

Long ago, when porting FBO and memory management support to i965, I
merged a bunch of code between the i915 and i965 drivers and put it in
the intel directory.  I think it served us well for a long time, as both
drivers got improvements from shared work on that code.  But since then,
we've talked several times about splitting things back apart (since we
break i915 much more often than we improve it), so I spent yesterday and
today looking at what the impact would be.

LOC counts (wc -l):

 intel/ i915/   i965/ total
master: 14751  13458   61109 89318
fork-i915:  0  24322   74978 99300

We duplicate ~1 lines of code, but i915 drops ~4000 lines of code
 From its build and i965 drops ~1000.

context size:
i915i965
master:99512   101456
fork-i915: 99384   100824

There's a bunch of cleanup I haven't done in the branch, like moving
brw_vtbl.c contents to sensible places, or nuking the intel vs brw split
that doesn't make any sense any more.

I'm ambivalent about the change.  If the code growth from splitting was
<7000 lines or so, I'd be happy, but this feels pretty big.  On the
other hand, the cleanups feel good to me.


I'm still in favor of this - you've already embarked on some good 
tidying, and there's much more that can be done.  I think in the end, 
both drivers will be better off.  I'd also feel better if it were < 
7000, but at some point it makes sense anyway.


I do think the duplicated code may diverge further in the future (say, 
due to new Gen4+ only acceleration paths or improved implementations of 
things), and that there's a bit more that could be cut/coalesced.



I don't know how other
developers feel.  There's a branch up at fork-i915 of my tree.  If
people are excited about doing this and I get a bunch of acks for the
two "copy the code to my directory" commits, I'll do those two then
start sending out the non-copying changes for review.  If people don't
like it, I won't be hurt.


That sounds like a good plan to me.  I'd be happy to do some post-fork 
tidying, but I'd much rather get your code landed before embarking too 
far on that path.


What do others think?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev