Keith Whitwell wrote:
Brian Paul wrote:
Keith Whitwell wrote:
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.
My thinking wasn't necessarily motivated by a desire to unify the
executable backends. This might pan out as well, but there are benefits
that go beyond this - namely that a single, well-written and well
understood optimization engine can be used on both types of programs,
and by all drivers whether or not the code finally ends up being
executed on the CPU or on hardware.
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.
At a certain point in the compilation, the program will be handed over
to a backend which will map the higher level concepts onto real
hardware. Ultimately the best the higher levels can do is avoid
restricting the freedom of the backend to deal with the low-level
constraints it is faced with.
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.
Don't forget the hardware backends and the (partial) x86/SSE codegen
backend in t_vb_arbprogram_sse.c. That brings it to 7 so far. Ian
mentions three more above, for a total of 10. I think we have to live
with multiple backends, what's important is unifying as much of the
handling above the backends - compiled, interpreted or hardware, as
possible.
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.
Sometimes you have a choice, sometimes the hardware forces a choice. If
we were to write an SSE backend for any of these languages, SoA would
seem to be the better choice, I can say this especially after my
attempts at AoS in t_vb_arbprogram_sse.c.
I think we're on the same page. One of the points I was trying to
make is that we already have a quite a bit of very similar, if not
duplicated code for vertex/fragment programs. I've experienced the
hassle of fixing the same bug in multiple places enough already. I
really want to try to minimize that going forward.
In some area, such as having a unified parameter/temporary register
file or a convention for accessing software-based input/outputs
registers, we could hopefully reduce the amount of different code
paths that do the same thing. A concrete example is the input/ouput
register staging that's done in t_vb_program.c vs. t_vb_arbprogram.c
They effectively do the same thing in two different ways. I'd rather
not have an SEE code generator do it in yet another way.
Incidentally, I found a bug in the output register mapping in
t_vb_arbprogram.c that needs some attention when I find the time.
-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
