Pipeline separation preview

[Stefan Dösinger]

Hi,
I'm sending a preview of my vertex-fragment-misc pipeline separation patches
as discussed a few weeks ago. The patch comments have more descriptions. The
relevant patches start at patch 5, the other patches are other junk in my
tree.

Any comments?

Stefan

[Stefan Dösinger]

Oops, sorry, I did not intend to send it 4 times. I had some disagreements
with my glourious Outlook 2007 "mail client".
> -----Original Message-----
> From: [e-mail] [mailto:wine-devel-
> [e-mail]] On Behalf Of Stefan Dösinger
> Sent: Wednesday, July 02, 2008 10:48 AM
> To: [e-mail]
> Subject: Pipeline separation preview
>
> Hi,
> I'm sending a preview of my vertex-fragment-misc pipeline separation
> patches as discussed a few weeks ago. The patch comments have more
> descriptions. The relevant patches start at patch 5, the other patches
> are other junk in my tree.
>
> Any comments?
>
> Stefan

[Stefan Dösinger]

Hi,
Here is an updated patchset. I have CC'ed Henri and Ivan, since they were
the main critics of the old design. Ivan, this should get rid of the
inheritance thunks the old way of munging everything into the shader backend
had. I've discussed things with Henri on IRC. Henri, can you take a quick
look and see if your vertex pipeline stuff can be integrated into this
concept?

A few remarks:
-> The whole pipeline is split up into a vertex, fragment and misc part.
-> It is no problem if multiple parts of the pipeline read the same D3D
state. See for example sampler()
-> However, the representative states in all pipeline parts have to be the
same, otherwise bad things will happen. This imposes some problems around
stream sources, vdecl and vertex shaders. However it is no problem if
different implemetations of the same pipeline part have different state
groupings.
-> It is possible that not all states are grouped correctly yet, or some
more states may need splitup. This will surface once we have a vertex
pipeline replacement.
-> Private data for the fragment pipeline is stored in a separate pointer in
the device. This can of course be the same as the shader private storage,
but doesn't have to.

For the next days I'll be bugfixing for another CrossOver Games release, so
I'll probably send this stuff in a week or two. Further plans are:
-> reorder the patches slightly since in the current form atifs is
temporarily broken, making regression tests harder
-> Find a r250 card to test the atifs stuff. I am currently not at home, and
it turns out that fglrx has a broken atifs implementation.
-> Generally more testing. Right now I've only tested our regression tests
-> Add extension information to the state templates. That way the pipeline
compiler can select different functions from the same template depending on
the available extensions. That way we can move a few more if(GL_SUPPORTED())
checks out of the rendering loop, saving a few CPU cycles and making the
code cleaner.

In the long d3d10 run, those things could be considered:
-> Using different templates for d3d10, thus getting rid of a few
if(!shader) checks. It's a minimal optimization though, everything in the
fixed function code except the if(!shader) tests will never be touched in
d3d10 anyway since the states are never dirty
-> Create an additional geometry pipeline template
> -----Original Message-----
> From: [e-mail] [mailto:wine-devel-
> [e-mail]] On Behalf Of Stefan Dösinger
> Sent: Wednesday, July 02, 2008 10:48 AM
> To: [e-mail]
> Subject: Pipeline separation preview
>
> Hi,
> I'm sending a preview of my vertex-fragment-misc pipeline separation
> patches as discussed a few weeks ago. The patch comments have more
> descriptions. The relevant patches start at patch 5, the other patches
> are other junk in my tree.
>
> Any comments?
>
> Stefan

[Stefan Dösinger]

Oops, forgot to attach the archive

[Ivan Gyurdiev]

Stefan Dösinger wrote:
> Oops, forgot to attach the archive

I like it, especially these parts:

- Interface decoupling - Moves FFP replacement code to using the FFP 
state table interface, instead of touching the unrelated shader interface
- Code separation - Code unrelated to shaders is moved out of the shader 
interface as a result (0020, 0021, 0022, 0048, 0049)
- Code separation - NV shader code pushed out into its own file, like 
ARBFS, ATIFS, GLSL - 0054, 0057, 0058, 0059 (if statements gone)
- Increased modularity - breaks up single state table into multiple 
parts, which can be individually manipulated w/o performance impact
- Moves towards OOP approach - state table structure is wrapped by a 
"fragment_pipeline" object with method vtable (0048)

I think it's moving in the right direction. It's also important that 
you've tried this on the NV extension, since now you have two pipeline 
replacements to test if the framework is sufficient or not.

Ivan

[Stefan Dösinger]

> -----Original Message-----
> From: [e-mail] [mailto:wine-devel-
> [e-mail]] On Behalf Of Ivan Gyurdiev

Thanks for the review!
> I think it's moving in the right direction. It's also important that
> you've tried this on the NV extension, since now you have two pipeline
> replacements to test if the framework is sufficient or not.

Is there anything in particular you do not like? Since usually the broken
parts cause issues when sending it to wine-patches, not the working ones :-)

I might look into an ARB or GLSL fragment pipeline replacement later today
or tomorrow, lacking any cxgames bugs I can fix on my nv-linux
machine(stupid macs), and pretty hot weather outside...

[H. Verbeet]

Looks good to me. You should probably start submitting it bit by bit,
see if any regression come up, although it looks pretty safe to me.

[Stefan Dösinger]

> Looks good to me. You should probably start submitting it bit by bit,
> see if any regression come up, although it looks pretty safe to me.

Sure, that's the plan. I don't think submitting 50+ patches at once will
work well.

I have found 2 minor regressions, but fixed them already in my tree. (Mostly
incorrect calls in some state handler, like calling across pipeline parts
into a specific implementation of another pipeline part)