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 nhaeh...@gmail.comwrote:
Note that my Git repository already contains an implementation of
branch emulation and some additional optimizations, see here:
On Tue, Mar 30, 2010 at 6:26 PM, Nicolai Haehnle nhaeh...@gmail.com wrote:
Reply to all this time...
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com wrote:
1) Branching and looping
This is the most important one and there are 3 things which need to be
done.
* Unrolling
On Tue, Mar 30, 2010 at 7:09 AM, Tom Stellard tstel...@gmail.com 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
Reply to all this time...
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com 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 for
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 optimization
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
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 are
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
On Tue, Mar 30, 2010 at 8:37 AM, Luca Barbieri luca.barbi...@gmail.com 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
On Tue, Mar 30, 2010 at 10:05 AM, Luca Barbieri luca.barbi...@gmail.com 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
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 simple TGSI
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 TGSI
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 simple TGSI
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 simple TGSI
On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle nhaeh...@gmail.comwrote:
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com 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
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
On Mon, Mar 29, 2010 at 10:09 PM, Tom Stellard tstel...@gmail.com 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
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
On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard tstel...@gmail.com 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 tstel...@gmail.com
wrote:
Thanks for the information.
After spending some time learning about the
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 interest
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard tstel...@gmail.com 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,
On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson
mostawesomed...@gmail.com 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
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
mostawesomed...@gmail.comwrote:
On Tue, Mar 23, 2010 at 12:13
On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard tstel...@gmail.com 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
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
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
Tom Stellard tstel...@gmail.com 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,
27 matches
Mail list logo
