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/g
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 inse
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
inde
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.
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
---
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
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 ind
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 chang
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
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/m
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.
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 +++
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_
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/
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/
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 co
---
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
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
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_t
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 s
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 s
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
> ++-
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
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 dela
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 withou
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 impro
> 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
>>
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.freedesk
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.
___
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,
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
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
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
Classificatio
https://bugs.freedesktop.org/show_bug.cgi?id=66029
Klemens Baum changed:
What|Removed |Added
Attachment #81187|0 |1
is patch|
https://bugs.freedesktop.org/show_bug.cgi?id=66029
Klemens Baum changed:
What|Removed |Added
Attachment #81187|0 |1
is obsolete|
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/cl
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
> ++
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.
>
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::DAGTypeL
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,
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
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 chang
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 e
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 d
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 file
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' i
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
47 matches
Mail list logo
