> This might depend on the target: R600+, for example, is quite
> scalar-oriented anyway (modulo a lot of subtle limitations), so just
> pretending that everything is scalar could work well there since
> revectorizing is almost unnecessary.
Interesting, nv50 is also almost fully scalar, and based
On Sun, Apr 4, 2010 at 10:42 PM, Luca Barbieri wrote:
>> Way back I actually looked into LLVM for R300. I was totally
>> unconvinced by their vector support back then, but that may well have
>> changed. In particular, I'm curious about how LLVM deals with
>> writemasks. Writing to only a select su
> Way back I actually looked into LLVM for R300. I was totally
> unconvinced by their vector support back then, but that may well have
> changed. In particular, I'm curious about how LLVM deals with
> writemasks. Writing to only a select subsets of components of a vector
> is something I've seen in
On Sat, Apr 3, 2010 at 2:37 PM, Luca Barbieri wrote:
> Note all "X compiler is bad for VLIW or whatever GPU architecture"
> objections are irrelevant, since almost all optimizations are totally
> architecture independent.
Way back I actually looked into LLVM for R300. I was totally
unconvinced by
Hi,
On Sat, Apr 3, 2010 at 3:31 AM, Tom Stellard wrote:
> 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 pr
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 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
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
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
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
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
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
23 matches
Mail list logo
