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 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 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 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
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 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
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 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 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: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: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 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
https://bugs.freedesktop.org/show_bug.cgi?id=66029
Klemens Baum changed:
What|Removed |Added
Attachment #81187|0 |1
is obsolete|
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
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
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
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
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.
___
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
> 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
>>
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
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 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 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 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
> ++-
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
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
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
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
---
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
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
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/
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/
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_
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 +++
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.
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/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 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
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
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
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
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
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
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
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
47 matches
Mail list logo
