[Mesa-dev] intel_draw_buffers overhead reduction (with mesa core changes)

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

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

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 -

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

_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

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

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

[Mesa-dev] [PATCH 04/11] radeon: Remove gratuitous custom framebuffer resize code.

_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/radeon/radeon_fbo.c | 31 --- 1 file changed, 31 deletions(-) diff

[Mesa-dev] [PATCH 05/11] i965: Stop flagging _NEW_POLYGON on drawbuffers change.

Things like brw_sf.c that need to know about orientation are already recomputing on _NEW_BUFFERS. --- src/mesa/drivers/dri/i965/brw_vtbl.c | 5 - 1 file changed, 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c b/src/mesa/drivers/dri/i965/brw_vtbl.c index 96a6cd5..ba5fadf

[Mesa-dev] [PATCH 06/11] i965: Stop flagging viewport/scissor change on drawbuffers change.

The viewport (ctx-Viewport._WindowMap) doesn't change with drawable size changes, and we update scissor (ctx-DrawBuffer-_Xmin and friends) on _NEW_BUFFERS in things like brw_sf_state.c. --- src/mesa/drivers/dri/i965/brw_vtbl.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[Mesa-dev] [PATCH 09/11] i965: Stop recomputing drawbuffer bounds on drawbuffer change.

For winsys FBOs, the bounds are appropriately updated immediately upon _mesa_resize_framebuffer(). For user FBOs, they're updated as part of the normal draw path state update due to _NEW_BUFFERS having been flagged. --- src/mesa/drivers/dri/i965/brw_vtbl.c | 2 -- 1 file changed, 2 deletions(-)

[Mesa-dev] [PATCH 11/11] i965: Remove the rest of brw_update_draw_buffer().

The last piece of code with an effect was flagging _NEW_BUFFERS. Only, that is already flagged from everything that calls this function: Mesa GL state updates flag it before even calling down into the driver, and the calls from the DRI2 window system framebuffer update path end up flagging it as

[Mesa-dev] [PATCH 08/11] i965: Remove _NEW_DEPTH state flagging on drawbuffers change.

Of the places noting a _NEW_DEPTH dependency, all were already checking for _NEW_BUFFERS if appropriate. --- src/mesa/drivers/dri/i965/brw_vtbl.c| 2 -- src/mesa/drivers/dri/i965/gen7_misc_state.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git

[Mesa-dev] [PATCH 10/11] i965: Stop updating FBO state on drawbuffers change.

The computed fields are updated appropriately as part of the normal draw call path due to _NEW_BUFFERS being set. --- src/mesa/drivers/dri/i965/brw_vtbl.c | 8 1 file changed, 8 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c b/src/mesa/drivers/dri/i965/brw_vtbl.c index

[Mesa-dev] [PATCH 07/11] intel: Stop doing special _NEW_STENCIL state flagging on drawbuffers.

2/3 packets depending on Stencil._Enabled already checked for _NEW_BUFFERS, so just add _NEW_BUFFERS to the remaining one. --- src/mesa/drivers/dri/i965/brw_cc.c| 4 ++-- src/mesa/drivers/dri/i965/brw_vtbl.c | 7 +-- src/mesa/drivers/dri/i965/brw_wm.c| 2 +-

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

From: José Fonseca jfons...@vmware.com 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(-)

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

From: José Fonseca jfons...@vmware.com 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

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

From: José Fonseca jfons...@vmware.com 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

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

From: José Fonseca jfons...@vmware.com 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

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

From: José Fonseca jfons...@vmware.com 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

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

From: José Fonseca jfons...@vmware.com --- 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

Re: [Mesa-dev] [PATCH] llvmpipe: fix wrong results for queries not in a scene

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

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

On 06/21/2013 05:53 AM, jfons...@vmware.com wrote: From: José Fonseca jfons...@vmware.com 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|

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

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 |

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

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 -

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

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.

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

Add some constant load v2i32/v4i32 tests for both EG and SI. Tested on: Pitcairn (7850) and Cedar (54xx) Signed-off-by: Aaron Watry awa...@gmail.com --- lib/Target/R600/R600Instructions.td | 3 +++ lib/Target/R600/SIInstructions.td | 10 ++ test/CodeGen/R600/load.vec.ll | 27

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

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

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

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

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

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

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

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/(116) or ~1/(124)), 'm' is the approximated slope from the GL spec, and '2' is this magic number from the original i965 code

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

--- 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

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

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

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

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 -

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

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

[Mesa-dev] forking shared intel directory?

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

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

On Thu, Jun 20, 2013 at 11:07 PM, Eric Anholt e...@anholt.net 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

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

On Fri, Jun 21, 2013 at 1:29 PM, Eric Anholt e...@anholt.net 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

Re: [Mesa-dev] intel_draw_buffers overhead reduction (with mesa core changes)

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

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

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

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

On Fri, Jun 21, 2013 at 3:53 PM, Kenneth Graunke kenn...@whitecape.orgwrote: 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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=63435 --- Comment #6 from Eric Anholt e...@anholt.net --- 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] [Bug 63435] [Regression since 9.0] Flickering in EGL OpenGL full-screen window with swap interval 1

https://bugs.freedesktop.org/show_bug.cgi?id=63435 --- Comment #7 from Eric Anholt e...@anholt.net --- (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

[Mesa-dev] [PATCH] egl: Restore bogus DRI2 invalidate event code.

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

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

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 ---

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

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=66029 Klemens Baum klemensb...@gmail.com changed: What|Removed |Added Attachment #81187|0 |1 is

Re: [Mesa-dev] Mesa driver for VirtualBox

On 20/06/13 23:37, Dave Airlie wrote: On Fri, Jun 21, 2013 at 12:47 AM, Michael Thayer michael.tha...@oracle.com 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

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

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

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

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,

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

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 awa...@gmail.com --- lib/Target/R600/R600Instructions.td | 3 +++

Re: [Mesa-dev] [PATCH] R600: Expand SUB for v2i32/v4i32

On Wed, May 08, 2013 at 06:19:11PM -0500, Aaron Watry wrote: Signed-off-by: Aaron Watry awa...@gmail.com I'm afraid I overlooked this patch, sorry. Reviewed-by: Tom Stellard thomas.stell...@amd.com --- lib/Target/R600/R600ISelLowering.cpp |2 ++ test/CodeGen/R600/sub.ll |

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

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 t...@stellard.net wrote: On Thu, Jun 20, 2013 at 06:43:42PM -0500, Aaron Watry wrote: Also add lit test for both cases on SI,

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

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

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

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

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

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/(116) or ~1/(124)), 'm' is the approximated slope from the GL spec, and '2' is

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

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