Shaders

[bogglez]

The pre-sort mode makes the TR list behave like ordinary Z-buffered rendering solutions, complete with the usual quirks regarding alpha blending and intersecting polygons. You also can't use translucent modifiers in the pre-sort mode.

Does that mean you can change whether the GPU acts like a tiled renderer, so raytracing and deferred shading renderers would become much more efficient?

[Tvspelsfreak]

It only changes how the TR list deals with translucency. In auto-sort, it sorts the polygons per pixel and renders them back-to-front. In pre-sort, they're rendered in the order they're submitted.

[PH3NOM]

Bit 21 = Region Header Type? ( 0 = TR sort mode set by ISP_FEED_CFG register, 1 = TR sort mode is specified by the pre- sort bit within the Region Array data )
And looking at the "magic value", we can see that Bit 21 is set to 1, so then in KOS ( by default ), TR sort mode is ignored in the ISP_FEED_CFG register.

When bit 21 is set to 1, the auto-sort setting is set per tile in the Region Array data, a.k.a. tile matrix in KOS. It's bit 29 in the first word of each tile (0 = auto-sort, 1 = pre-sort). You can change it in pvr_buffers.c, in "pvr_init_tile_matrix" where the control word is set.

Code: Select all

/* Control word */
vr[0] = (y << 8) | (x << 2);

Change that to this:

Code: Select all

/* Control word */
vr[0] = (y << 8) | (x << 2) | (1 << 29);

I've tested it on real hardware.

The pre-sort mode makes the TR list behave like ordinary Z-buffered rendering solutions, complete with the usual quirks regarding alpha blending and intersecting polygons. You also can't use translucent modifiers in the pre-sort mode.

Aahh, thanks for that info, its all starting to make sense now. The "Region Array data" part started to lose me.

I modified KOS tonight and had a quick test with the 'radial blur' effect.
Disabling Auto-Sort mode and bi-linear filtering is actually quite noticeably faster.
The 'radial blur' effect can handle more full-screen TR polys before the PVR starts to break down.

But, it seems that changing the parameters at compile time is not the best solution here.
I think it would be best to init the PVR in a way that allows the use of the ISP_FEED_CFG register to specify TR sort mode per-frame.
Or is it possible to modify the tile matrix bits after initializing the PVR?
Ideally, it would be awesome to specify TR sort mode per group of vertices, that is switch back and forth each frame.

BlueCrab, Ive noticed that my demo does not run on real hardware when I render the very first frame to texture.
However, If I render the very first frame to screen, then the 2nd frame to texture, things seem ok.
Should this be the case?

[Tvspelsfreak]

But, it seems that changing the parameters at compile time is not the best solution here.
I think it would be best to init the PVR in a way that allows the use of the ISP_FEED_CFG register to specify TR sort mode per-frame.
Or is it possible to modify the tile matrix bits after initializing the PVR?
Ideally, it would be awesome to specify TR sort mode per group of vertices, that is switch back and forth each frame.

I agree, but changing bit 21 of FPU_PARAM_CFG changes the size of the structure expected in the tile matrix from 6*32bit to 5*32bit. The PT list pointer is removed, so you will need to disable that list entirely.

The best way is to implement the multipass rendering supported by the PVR2DC. It's done by rendering each tile multiple times (once per pass) and setting the list continuation register to allow for the same lists to be input again in the same frame. You can change the auto-sort setting and whether or not to clear the Z-buffer on a per pass basis. It would probably take some time to implement it in KOS though.

As a quick fix, you can probably update the tile matrix bits after the PVR has been initialized, as you said.

[BlueCrab]

I'd say 'presort_enabled' is a pretty good candidate for being added to pvr_init_params_t, eh BlueCrab?

I could see adding a 'presort_disabled' to the initialization parameters, which would set it in the tile region array parameters (as you detailed in your post with changing the control word there). I don't see any particular use for doing so in the other manner (with the two "magic" registers), and kinda feel that it would needlessly complicate other parts of the code to do so (I try to stay away from modifying parts of the code that work for fear of breaking them needlessly ), especially since doing so through the configuration registers changes the amount of data in the region array. You allude to this in your latest post before this one in the thread and kinda describe how I'd imagine things being implemented at some point -- allowing per-pass (and thus obviously per-frame) changes to the region array data.

BlueCrab, Ive noticed that my demo does not run on real hardware when I render the very first frame to texture.
However, If I render the very first frame to screen, then the 2nd frame to texture, things seem ok.
Should this be the case?

I don't remember seeing any problems doing the first frame to texture when I tested it, but I'm not entirely sure whether or not I tested that at all, to be honest. I'll take a look when I get a chance.

[Tvspelsfreak]

I could see adding a 'presort_disabled' to the initialization parameters, which would set it in the tile region array parameters (as you detailed in your post with changing the control word there).

Since auto-sort is enabled by default today, wouldn't 'presort_enabled' or 'autosort_disabled' be the way to go to avoid a change in KOS' default behavior?

I don't see any particular use for doing so in the other manner (with the two "magic" registers), and kinda feel that it would needlessly complicate other parts of the code to do so (I try to stay away from modifying parts of the code that work for fear of breaking them needlessly ), especially since doing so through the configuration registers changes the amount of data in the region array.

Yeah, too messy for what it's worth, especially since it drops support for the PT list.

[MisterDave]

Hey there Dave!

Did you have any success with finding an ideal level of performance with the effect?
...
I guess the PVR really struggles with blending overlapped translucent polys?

Hi PH3NOM - just got around to reading this, so I may be a few days behind in the thread. Interesting to hear about your experience as I have found that the DoF effect was a lot faster than the radian blur on real hardware, but that makes sense now as the PVR is only drawing one opaque polygon after rendering to texture rather than multiple full screen transparent ones. I need to play around with the bloom and determine how few full screen transparent polys that I can get away with.

It's been a while since I've really been working on Dreamcast coding, but I'm wanting to get back once I get some upcoming holiday time.

Dave

[BlueCrab]

I could see adding a 'presort_disabled' to the initialization parameters, which would set it in the tile region array parameters (as you detailed in your post with changing the control word there).

Since auto-sort is enabled by default today, wouldn't 'presort_enabled' or 'autosort_disabled' be the way to go to avoid a change in KOS' default behavior?

Yeah, I meant 'autosort_disabled' to make it obvious as to what it does, but I guess I kinda mistyped it there, eh?

[PH3NOM]

You allude to this in your latest post before this one in the thread and kinda describe how I'd imagine things being implemented at some point -- allowing per-pass (and thus obviously per-frame) changes to the region array data.

Wow, that would be awesome to see the PVR's multi-pass abilities exposed in KOS. Good luck BlueCrab!

BlueCrab, Ive noticed that my demo does not run on real hardware when I render the very first frame to texture.
However, If I render the very first frame to screen, then the 2nd frame to texture, things seem ok.
Should this be the case?

I don't remember seeing any problems doing the first frame to texture when I tested it, but I'm not entirely sure whether or not I tested that at all, to be honest. I'll take a look when I get a chance.

Yeah, I had to scratch my head on that one. Thanks for taking a look!