On Tue, Mar 30, 2010 at 6:26 PM, Nicolai Haehnle wrote:
> Reply to all this time...
>
> On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote:
>>> > 1) Branching and looping
>>> >
>>> > This is the most important one and there are 3 things which need to be
>>> > done.
>>> > * Unrolling loops and con
On Wed, Mar 31, 2010 at 04:34:48AM +0200, Marek Olšák wrote:
> On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle wrote:
> >
> > Note that my Git repository already contains an implementation of
> > branch emulation and some additional optimizations, see here:
> > http://cgit.freedesktop.org/~nh/mes
On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle wrote:
> On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote:
> > Another idea was to convert TGSI to a SSA form. That would make unrolling
> > branches much easier as the Phi function would basically become a linear
> > interpolation, loops and su
> On Tue, 2010-03-30 at 09:52 -0700, Luca Barbieri wrote:
>> > There are several deep challenges in making TGSI <-> LLVM IR translation
>> > lossless -- I'm sure we'll get around to overcome them -- but I don't
>> > think that using LLVM is a requirement for this module. Having a shared
>> > IR for
On Tue, 2010-03-30 at 09:52 -0700, Luca Barbieri wrote:
> > There are several deep challenges in making TGSI <-> LLVM IR translation
> > lossless -- I'm sure we'll get around to overcome them -- but I don't
> > think that using LLVM is a requirement for this module. Having a shared
> > IR for simpl
On Tuesday 30 March 2010 12:52:54 Luca Barbieri wrote:
> > There are several deep challenges in making TGSI <-> LLVM IR translation
> > lossless -- I'm sure we'll get around to overcome them -- but I don't
> > think that using LLVM is a requirement for this module. Having a shared
> > IR for simple
This is getting off-topic, but anyway...
Luca Barbieri wrote:
>> There are several deep challenges in making TGSI <-> LLVM IR translation
>> lossless -- I'm sure we'll get around to overcome them -- but I don't
>> think that using LLVM is a requirement for this module. Having a shared
>> IR for si
On Tue, Mar 30, 2010 at 10:05 AM, Luca Barbieri wrote:
> DDX/DDY could cause miscompilation, but I think that only happens if
> LLVM clones or causes some paths to net execute them.
>
> Someone proposed some time ago on llvmdev to add a flag to tell llvm
> to never duplicate an intrinsic, not sure
On Tue, Mar 30, 2010 at 8:37 AM, Luca Barbieri wrote:
>> Another idea was to convert TGSI to a SSA form. That would make unrolling
>> branches much easier as the Phi function would basically become a linear
>> interpolation, loops and subroutines with conditional return statements
>> might be tric
DDX/DDY could cause miscompilation, but I think that only happens if
LLVM clones or causes some paths to net execute them.
Someone proposed some time ago on llvmdev to add a flag to tell llvm
to never duplicate an intrinsic, not sure if that went through (iirc,
it was for a barrier instruction tha
> There are several deep challenges in making TGSI <-> LLVM IR translation
> lossless -- I'm sure we'll get around to overcome them -- but I don't
> think that using LLVM is a requirement for this module. Having a shared
> IR for simple TGSI optimization module would go a long way by itself.
What
On Tue, 2010-03-30 at 08:37 -0700, Luca Barbieri wrote:
> > Another idea was to convert TGSI to a SSA form. That would make unrolling
> > branches much easier as the Phi function would basically become a linear
> > interpolation, loops and subroutines with conditional return statements
> > might be
> Another idea was to convert TGSI to a SSA form. That would make unrolling
> branches much easier as the Phi function would basically become a linear
> interpolation, loops and subroutines with conditional return statements
> might be trickier. The r300 compiler already uses SSA for its optimizati
Reply to all this time...
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote:
>> > 1) Branching and looping
>> >
>> > This is the most important one and there are 3 things which need to be
>> > done.
>> > * Unrolling loops and converting conditionals to multiplications. This
>> > is
>> > crucial
On Tue, Mar 30, 2010 at 7:09 AM, Tom Stellard wrote:
> On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
> >
> > From the driver point of view, we don't have to work on the GLSL compiler
> > itself. The Mesa state tracker compiles GLSL to an assembler-like
> language
> > called TGSI wh
On Mon, Mar 29, 2010 at 10:09 PM, Tom Stellard wrote:
> On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
>>
>> From the driver point of view, we don't have to work on the GLSL compiler
>> itself. The Mesa state tracker compiles GLSL to an assembler-like language
>> called TGSI which is
On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
>
> From the driver point of view, we don't have to work on the GLSL compiler
> itself. The Mesa state tracker compiles GLSL to an assembler-like language
> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
> r
On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
>
> From the driver point of view, we don't have to work on the GLSL compiler
> itself. The Mesa state tracker compiles GLSL to an assembler-like language
> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
> r
On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard wrote:
> On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
> > On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard
> wrote:
> > >
> > > Thanks for the information.
> > >
> > > After spending some time learning about the Gallium driver
> arch
On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
> On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard wrote:
> >
> > Thanks for the information.
> >
> > After spending some time learning about the Gallium driver architecture, I
> > think it might be better to set a goal to implement or
I've updated the TODO list with the stuff from my private one, in case you
guys think there are too few things to do. ;)
http://dri.freedesktop.org/wiki/R300ToDo?action=diff
-Marek
On Tue, Mar 23, 2010 at 8:16 AM, Corbin Simpson
wrote:
> On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson
> wrote
On Tue, Mar 23, 2010 at 00:13, Corbin Simpson wrote:
> On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard wrote:
>> On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
>>>
>>> Nifty. Well, there's a few places to look for information.
>>>
>>> If you're not sure how the actual video card w
On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson
wrote:
> Good question. There's a handful of things. Passing piglit might be a
> good goal. Bumping the GL version further up, or solidifying the GLSL
> support, might be good too.
Oh, and how could I forget this? We have a sizeable todo list:
http
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard wrote:
> On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
>>
>> Nifty. Well, there's a few places to look for information.
>>
>> If you're not sure how the actual video card works,
>> http://www.x.org/wiki/Development/Documentation/HowV
On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
>
> Nifty. Well, there's a few places to look for information.
>
> If you're not sure how the actual video card works,
> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
> great starting point. Of particular int
On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
>
> If you're not sure how the actual video card works,
> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
> great starting point. Of particular interest is the 3D engine; r300g
> only talks to the 3D part of the
On Thu, Mar 18, 2010 at 12:30 PM, Tom Stellard wrote:
> Hi,
>
> I am interested in working on the Gallium R300 driver as a part of
> Google Summer of Code. I would like to try and target a specific game,
> probably Civilization 4, and get it working as well as possible. I am
> interested in gett
Tom Stellard writes:
> Where is a good place for me to start looking through the code? Is
> there a reference Gallium driver I can look at to get a good idea of
> how the drivers are structured?
I'm sure one of the actual gallium developers can give you more
detail/correct me, but: src/gallium/d
Hi,
I am interested in working on the Gallium R300 driver as a part of
Google Summer of Code. I would like to try and target a specific game,
probably Civilization 4, and get it working as well as possible. I am
interested in getting some feedback on whether or not this is a good
goal for the su
29 matches
Mail list logo
