[Mesa-dev] shader-db, and justifying an i965 compiler optimization.

One of the pain points of working on compiler optimizations has been justifying them -- sometimes I come up with something I think is useful and spend a day or two on it, but the value doesn't show up as fps in the application that suggested the optimization to me. Then I wonder if this transforma

[Mesa-dev] [PATCH 3/3] i965: Avoid generating MOVs for assignments of expressions.

The theory in the codegen was that register coalescing and copy propagation would eliminate these extra moves. However, with our ad-hoc dataflow analysis, we end up missing out on some of those opportunities inside of control flow. It's particularly embarassing when those uneliminated MOVs end up

[Mesa-dev] [PATCH 1/3] i965/fs: Do a FS compile up front at link time to produce link errors.

At glLinkShaders time, a fail() call in FS compile in 8-wide (the one that's required to succeed, though we may relax that at some point for pre-Ironlake performance) will now report out as a link error. --- src/mesa/drivers/dri/i965/brw_fs.cpp | 130 +- src/mesa/d

[Mesa-dev] [PATCH 2/3] mesa: Include shader target in dumps of GLSL source.

This makes automatic parsing of MESA_GLSL=dump output easier. --- src/mesa/program/ir_to_mesa.cpp |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp index 510aeab..0086997 100644 --- a/src/mesa/program/ir_to_

Re: [Mesa-dev] mesa-dev Digest, Vol 14, Issue 83

> I built mesa with g3dvl support and I'd like to do some test. Please correct > me > if I am wrong. I found the following files: > > libr600_drv_video.so > libr600_drv_video.so.0 > libr600_drv_video.so.0.3 > libvdpau_g3dvl.so > libvdpau_g3dvl.so.1 > libvdpau_g3dvl.so.1.0 > libXvMCnouveau.so > l

Re: [Mesa-dev] [PATCH] i965: Convert BRW_NEW_* dirty bits to use an enum.

On Mon, 16 May 2011 15:36:14 -0700, Kenneth Graunke wrote: > This will make it much easier to add new dirty bits. > > Signed-off-by: Kenneth Graunke > --- > src/mesa/drivers/dri/i965/brw_context.h | 66 > +-- > 1 files changed, 45 insertions(+), 21 deletions(-)

Re: [Mesa-dev] shared LLVM library causes program abortion

On 5/17/11 3:24 PM, Jose Fonseca wrote: I believe the best alternative here is to build *_dri.so with -z nodelete when linking against a shared libLLVM*. That should work, even though it's incredibly unpleasant. I would think LLVM would want to be robust against multiple users within the sa

[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm > 2.8

https://bugs.freedesktop.org/show_bug.cgi?id=36738 José Fonseca changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |jfons...@vmware.com |or

Re: [Mesa-dev] shared LLVM library causes program abortion

- Original Message - > Dave, > > This is a problem that popped up on our testing with Fedora 15 and > swrast_dri.so, but I believe it can happen with any > /usr/lib/dri/*_dri.so , and will like happen with any other distro > that tries to dynamically link DRI drivers against LLVM 2.8. W

[Mesa-dev] shared LLVM library causes program abortion

Dave, This is a problem that popped up on our testing with Fedora 15 and swrast_dri.so, but I believe it can happen with any /usr/lib/dri/*_dri.so , and will like happen with any other distro that tries to dynamically link DRI drivers against LLVM 2.8. Which is why I'm bring it up here instead

[Mesa-dev] Using Gallium3D video drivers

I built mesa with g3dvl support and I'd like to do some test. Please correct me if I am wrong. I found the following files: libr600_drv_video.so libr600_drv_video.so.0 libr600_drv_video.so.0.3 libvdpau_g3dvl.so libvdpau_g3dvl.so.1 libvdpau_g3dvl.so.1.0 libXvMCnouveau.so libXvMCnouveau.so.1 libXvM

[Mesa-dev] [PATCH] Anisotropic filtering extension for swrast

Hi, this patch makes it possible to have high quality texture filtering with the pure software renderer. The main purpose is to use it with osmesa. The anisotropic filtering is based on Elliptical Weighted Avarage (EWA). The patch was designed to make as little changes to the existing codebase

[Mesa-dev] [PATCH] Anisotropic filtering extension for swrast

Anisotropic filtering extension for swrast intended to be used by osmesato create high quality renderings. Based on Higher Quality Elliptical Weighted Avarage Filter (EWA). A 2nd implementation using footprint assembly is also provided. --- src/mesa/main/extensions.c |3 + src/mesa/swras

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Die, 2011-05-17 at 19:37 +0200, Marcin Slusarz wrote: > On Tue, May 17, 2011 at 07:15:50PM +0200, Michel Dänzer wrote: > > On Die, 2011-05-17 at 18:59 +0200, Marcin Slusarz wrote: > > > On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > > > > On Die, 2011-05-17 at 18:30 +0200, Ma

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Tue, May 17, 2011 at 07:15:50PM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 18:59 +0200, Marcin Slusarz wrote: > > On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > > > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > > > > On Tue, May 17, 2011 at 09:27:45AM +0

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Die, 2011-05-17 at 18:59 +0200, Marcin Slusarz wrote: > On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > > > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > > > > On Die, 2011-05-17 at 00:12 +0200, Ma

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > > > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > > > On Mon, May 16, 2011 at 10:51:58PM +0

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > > > Otherwise, doesn't really look h

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > > Otherwise, doesn't really look hacky to me - unless we could get other > > > channel ordering or s

Re: [Mesa-dev] [PATCH 1/4] i965/gs: Move generation check for bailing earlier.

On Mon, 16 May 2011 22:28:52 -0700, Kenneth Graunke wrote: > On 05/16/2011 09:15 PM, Eric Anholt wrote: > > On Mon, 16 May 2011 15:09:43 -0700, Kenneth Graunke > > wrote: > >> On Sandybridge, we don't need to break down primitives. There's no need > >> to bother setting up brw_compile and such

Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > Otherwise, doesn't really look hacky to me - unless we could get other > > channel ordering or something similar... > > It makes assumptions about how color component

[Mesa-dev] [Bug 30290] [i965g] undefined symbol: softpipe_create_screen

https://bugs.freedesktop.org/show_bug.cgi?id=30290 --- Comment #1 from Tapani Pälli 2011-05-17 00:14:10 PDT --- Created an attachment (id=46790) View: https://bugs.freedesktop.org/attachment.cgi?id=46790 Review: https://bugs.freedesktop.org/review?bug=30290&attachment=46790 gallium dri-i965 :