Keith Whitwell wrote:
Ian Romanick wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just a heads-up. For the next 10 weeks I'm going to be working with a
group of students at Portland State University to create a *real*
compiler back-end for vertex programs. It's their university "capstone"
project. My current guess is that they will target x86+SSE.
My primary goal for this project is to have them create a framework that
can be reused to create code generators for other platforms (e.g.,
x86-64, PowerPC, r300, etc.). The focus will be on re-usability and
correctness over performance.
My current thinking is to have them implement a layer that converts the
current vp_instruction array generated by the front-end to a more
generic intermediate representation (IR). The majority of the code they
write will operate on this IR. I'd like to see a layer that is capable
of doing platform independent optimizations (e.g., common subexpression
elimination, dead code removal, etc.). There will also (obviously) be a
platform dependent layer that generates the code and does additional
optimization.
Since the vp_instruction interface is well defined, I think I'll have
them work outside Mesa initially. They'll have some framework code that
generates the vp_instruction array, and they'll generate x86 assembly
code that will be assembled with GAS.
As part of that effort, I'm going to extend the vp_instruction interface
to support GL_NV_vertex_program2_option and GL_NV_vertex_program3. My
belief is that if the back-end they create can support those extensions,
then the same back-end can be used for GLSL vertex shaders.
Once they get to the point where working within Mesa makes sense, I'll
create a branch for them to work in. I the mean time they'll be working
in some other CVS repository. The details are still TBD.
Sounds cool. I'll send you some mail offline about this as well.
FWIW, I think the distinction between fragment programs and vertex
programs isn't particularly helpful for us - analysis and optimization
tools should probably be written to the union of the two languages. I'd
like to see the type-distinction between them disappear inside Mesa.
I've been looking into that a little as well. I may be checking in
some code changes to gradually steer toward that.
One thing that needs some consideration is the manner in which program
inputs, results and parameters are all managed.
1. Where does a vertex/fragment program get the input attributes from?
We want to execute the program on batches of vertices/fragments at a
time so a base/stride pair for each attribute would be most flexible.
2. Same thing for program outputs/results.
3. There are local program parameters, global program parameters, GL
state reference parameters, named user parameters, constants and
temporaries. In a software environment, we could keep all those in
one contiguous array to simplify things. But for some hardware, that
might not be practical. If would be nice to accomodate both h/w and
s/w needs at once.
Right now, we've unfortunately got three different software program
executors: the original vertex program executor
(shader/nvvertexec.c), the newer TNL executor (tnl/t_vb_arbprogram.c)
and the fragment executor (swrast/s_nvfragprog.c). It sure would be
nice to merge them into one coherent system.
Finally, we should also spend some time considering the OpenGL shading
language and if/how that might impact the features needed in a new,
unified program executor.
A bigger determinant is the characteristics of the backend - in
particular whether data will be stored as AoS or SoA, ie as {XYZW, XYZW,
XYZW, XYZW} or as { XXXX, YYYY, ZZZZ, WWWW }. With the latter, all
swizzling and writemasks can be removed at an early stage and don't need
to be considered in the back-end.
>
Doing this early in the optimization process makes sense if the backend
supports it, but would just be wishful thinking if it didn't... So you
effectively end up with two different optimization strategies for the
two different styles of backend.
The fragment/pixel code in Mesa is pretty much AoS oriented. Going
the other way would be pretty disruptive.
-Brian
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
