On Sun, Apr 4, 2010 at 6:14 AM, Tom Stellard wrote:
> On Sun, Apr 04, 2010 at 01:09:51AM +0200, Marek Olšák wrote:
> >
> > Since Nicolai has already implemented the branch emulation and some other
> > optimizations, it would be nice to take over his work. I tried to use the
> > branch emulation o
On Apr 3, 2010, at 12:34, tom fogal wrote:
> Vinson Lee writes:
>> Leopard uses gcc-4.0, which didn't have built-in support for atomic
>> variables.
>
> u_atomic.h should probably check for a supported compiler; Jeremy, does
> the attached patch produce an understandable error instead of a link
On Sun, Apr 04, 2010 at 01:09:51AM +0200, Marek Olšák wrote:
>
> Since Nicolai has already implemented the branch emulation and some other
> optimizations, it would be nice to take over his work. I tried to use the
> branch emulation on vertex shaders and it did not work correctly, I guess it
> ne
On Saturday 03 April 2010 19:07:59 Luca Barbieri wrote:
> > Gallium. Obviously a code-generator that can handle control-flow (to be
> > honest I'm really not sure why you want to restrict it to something
> > without control- flow in the first place).
>
> The no-control-flow was just for the first
On Saturday 03 April 2010 18:58:36 Marek Olšák wrote:
> On Sun, Apr 4, 2010 at 12:10 AM, Zack Rusin
> mailto:za...@vmware.com>> wrote: I thought the initial
> proposal was likely a lot more feasible for a GSOC (of course there one
> has to point out that Mesa's GLSL compiler already does unroll
>> So basically the r300 optimization work looks doomed from the
>> beginning to be eventually obsoleted.
>
> Please consider there are hw-specific optimizations in place which I think
> no other compiler framework provides, and I believe this SSA thing will do
Sure, but it seemed to me that all t
On Sun, Apr 4, 2010 at 1:07 AM, Luca Barbieri wrote:
> So basically the r300 optimization work looks doomed from the
> beginning to be eventually obsoleted.
>
Please consider there are hw-specific optimizations in place which I think
no other compiler framework provides, and I believe this SSA th
On Sat, Apr 3, 2010 at 9:31 AM, Tom Stellard wrote:
> 1. Enable branch emulation for Gallium drivers:
> The goal of this task will be to create an optional "optimization" pass
> over the TGSI code to translate branch instructions into instructions
> that are supported by cards without hardware br
> Gallium. Obviously a code-generator that can handle control-flow (to be honest
> I'm really not sure why you want to restrict it to something without control-
> flow in the first place).
The no-control-flow was just for the first step, with a second step
supporting everything.
> Having said tha
On Sun, Apr 4, 2010 at 12:10 AM, Zack Rusin wrote:
> I thought the initial proposal was likely a lot more feasible for a GSOC
> (of
> course there one has to point out that Mesa's GLSL compiler already does
> unroll loops and in general simplifies control-flow so the points #1 and #2
> are
> larg
On Sat, Apr 3, 2010 at 3:10 PM, Zack Rusin wrote:
> On Saturday 03 April 2010 17:17:46 Luca Barbieri wrote:
>>
>
> From the compute support LLVM->TGSI translation isn't even about
> optimizations, it's about "working". Writing a full C/C++ compiler that
> generates TGSI is a lot less realistic th
On Saturday 03 April 2010 17:17:46 Luca Barbieri wrote:
> >> (2) Write a LLVM->TGSI backend, restricted to programs without any
> >> control flow
> >
> > I think (2) is probably the closest to what I am proposing, and it is
> > something I can take a look at.
> By the way, it would be interesting
> I agree with you that doing these kinds of optimizations is a difficult
> task, but I am trying to focus my proposal on emulating branches and
> loops for older hardware that don't have branching instructions rather
> than performing global optimizations on the TGSI code. I don't think
> most of
> I don't agree with this. Making the format description table mutable when the
> only formats that are potentially unsupported due to patent issues are s3tc
> variants makes no sense. S3TC formats *are* special. There is nothing to
> generalize here.
Yes, I don't like this very much either.
Th
On Sat, Apr 03, 2010 at 08:37:39PM +0200, Luca Barbieri wrote:
> This is somewhat nice, but without using a real compiler, the result
> will still be just a toy, unless you employ hundreds of compiler
> experts working full time on the project.
>
>
> Good luck doing all this on TGSI (especially i
By the way, if you want a simple, limited and temporary, but very
effective, way to optimize shaders, here it is:
1. Trivially convert TGSI to GLSL
2. Feed the GLSL to the nVidia Cg compiler, telling it to produce
optimized output in ARB_fragment_program format
3. Ask the Mesa frontend/state tracke
Vinson Lee writes:
> Leopard uses gcc-4.0, which didn't have built-in support for atomic
> variables.
u_atomic.h should probably check for a supported compiler; Jeremy, does
the attached patch produce an understandable error instead of a link
error?
In terms of a solution, Jeremy, you could impl
> commit 5126683e3b971ccfb51e50e560750ce44e86bae8
> Author: Luca Barbieri
> Date: Fri Apr 2 05:23:32 2010 +0200
>
> gallium/util: add util_format_is_supported to check for pack/unpack
>
> This improves the code by making it more readable, and removes
> special knowledge of S3TC
As a further example that just came to mind, nv40 (GeForce 6-7 and PS3
RSX) supports control flow in fragment shaders, but does not
apparently support the "continue" keyword (since NV_fragment_program2,
which maps almost directly to the hardware, does not have it either).
I implemented TGSI contro
Leopard uses gcc-4.0, which didn't have built-in support for atomic variables.
From: Jeremy Huddleston [jerem...@freedesktop.org]
Sent: Saturday, April 03, 2010 11:22 AM
To: mesa3d-...@lists.sf.net
Subject: [Mesa3d-dev] gallium failing to build on darwin/pp
This is somewhat nice, but without using a real compiler, the result
will still be just a toy, unless you employ hundreds of compiler
experts working full time on the project.
For instance, Wikipedia lists the following loop optimizations:
# loop interchange : These optimizations exchange inner lo
Is there any known reason why gallium would fail to build on darwin/ppc? I
haven't looked into it myself since I figured there might be an easy answer
already
http://trac.macports.org/ticket/24345
--
Download Intel® P
Collect the maximum error for fetch/unpack tests, and ratio of flipped
to total bits for pack tests.
Add lenient thresholds for S3TC tests.
---
progs/gallium/unit/u_format_test.c | 163 +++-
1 files changed, 86 insertions(+), 77 deletions(-)
diff --git a/progs/ga
On Sun, Mar 28, 2010 at 6:13 PM, Chia-I Wu wrote:
> Hi Jakob,
>
> This patch series adds support for GL_OES_EGL_image to st/mesa. The first
> patch implements st_manager::get_egl_image in st/egl. The hook is used to
> check and return an st_egl_image, which describes an EGLImageKHR. The second
For instance, the DXT1 test is wrong.
The red values used are:
33
93
153
214
99 - 33 = 60
153 - 93 = 60
214 - 153 = 61
213 should be used instead (i.e. 0xd5 instead 0xd6)
--
Download Intel® Parallel Studio Eval
Try the
They are not passing for me with current master and a 32-bit system:
Here are the failures:
Testing util_format_dxt1_rgb_pack_8unorm ...
FAILED: f2 d7 90 20 ae 2c 6f 97 obtained
f2 d7 b0 20 ae 2c 6f 97 expected
Testing util_format_dxt5_rgba_pack_8unorm ...
FAILED: f7 10 c5 0c 9a 73 b4 9c
On Sat, Apr 3, 2010 at 3:11 PM, Dave Airlie wrote:
> The piglit read-front.c test is failing and the rabbits warren that is
> front buffer rendering in mesa st + dri st isn't helping me solve it.
> One thing I noticed was check_create_front_buffers is called in a
> number of places in the st, howe
Thanks Luca.
Concerning u_format_test.c, I'm not sure the problem is lossiness or
ambivalence in the format or a bug in the compressor, but there was logic in
u_format_test.c to skip the DXT1_RGBA packing -- all other tests were passing.
Lossiness by itself doesn't explain the test failure beca
On Sat, Apr 3, 2010 at 3:31 PM, Tom Stellard wrote:
> Hi,
>
> I have completed a first draft of my Google Summer of Code
> proposal, and I would appreciate feedback from some of the
> Mesa developers. I have included the project plan from my
> proposal in this email, and you can also view my full
https://bugs.freedesktop.org/show_bug.cgi?id=2
Ruslan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hi,
I have completed a first draft of my Google Summer of Code
proposal, and I would appreciate feedback from some of the
Mesa developers. I have included the project plan from my
proposal in this email, and you can also view my full proposal here:
http://socghop.appspot.com/gsoc/student_proposal
The piglit read-front.c test is failing and the rabbits warren that is
front buffer rendering in mesa st + dri st isn't helping me solve it.
One thing I noticed was check_create_front_buffers is called in a
number of places in the st, however it seems to never be used, as we
call st_manager_add_co
32 matches
Mail list logo
