Bugs report (MiniGL, Compositing R200, Warp3D)

[Daytona675x]

Hi all,

I'd like to report a few bugs (hope this is the right place) I encountered while developing our games. Those are the ones I explicitely wrote done or remember right now, there is more to come but not today. Also remember that I can only speak for my setup, so all those bugs appear at least on my sam460ex and Radeon 9250 with the latest official OS updates.

MiniGL:

1.1. triangles are being clipped at the viewport edges, apparently if 2 vertices fall out of the viewport. Looks like somebody tried a smart optimization and failed Easy to see if you run VoxelBird.

EDIT: no, it's something different: the triangles don't vanish, they are colored falsely - which at first glance made me think I'd see what's behind them (I should have known better - there are no other triangles behind, the mesh is optimized, only the skymap should have been visible if the triangles would actually vanish)... But in reality we got interpolation-madness. Only tested with flat-shading / no texturing.
Probably MiniGL tries to work-around bug 2.1 internally by creating vertices / triangles that are inside the view and fails?! Smells like that. Although that would imply that bug 2.1 is known for years and was not fixed nevertheless.

1.2. when using flat-shading the vertex-color from the 1st vertex of a triangle is used. This is not OpenGL compliant, the 3rd vertex' color should be used.

1.3. same thing with normals.

1.4. when lighting and color-material are enabled vertex-colors are not interpreted correctly. All faces end up with the same color - apparently being the one of the last primitive of a draw-array-call (happens at least with DrawElements, only tested with texturing disabled).
EDIT: also happens with DrawArrays, of course. Only tested with flat-shading.

Warp3D:

2.1. triangles are not drawn at all under certain circumstances. Apparently if one or two vertices fall out of the viewport by a certain amount. This is NOT the same bug as the one I mentioned for MiniGL (1.1)! It also should not be a guard-band-effect (and if it is then it is not implemented properly in the driver, don't know if the hardware does it itself or if it is programmable via driver), we are not talking about vertices that are thousands of pixels outside the viewport. This looks like somebody tried to implement some additional early-clipping-optimization and failed
It can be reproduced easily by drawing a viewport-centered triangle and by zooming it's x/y coords more and more. At a certain point (won't take long) it will simply vanish - although it should still contribute to the image.
As a workaround for our upcoming game - where this bug makes the playfield disappear when zoomed in - I increased the playfield's tesselation, so the triangles don't get that "large". Of course this workaround is no general solution.

2.2. disabling W3D_TEXMAPPING is not enough, I have to disable the respective texture-unit too. Maybe that is the desired behaviour, but if it is that way, then please document it (please also note my still unanswered question regarding docs in the SDK support section). There is more similar weird / undocumented behaviour, I will extend this list from time to time.

2.3. sometimes my textures are drawn with blueish rectangular artefact-areas inside (sam460ex, Radeon 9250) although the texture-data is 100% correct and aligned and inside valid ranges (happens randomly, apparently only on larger textures).
EDIT: Happens regardless of texture-size; especially annoying if it's a small black texture used for background fading for example


Compositing on R200:

3.1. same effect as 2.1. (this is the reason why the cut-scenes before game-play-start are missing in my "Battle Squadron" port for AOS4 on non-RadeonHD machines; back then I did not investigate further - I simply saw that the zoom planet background vanished on R200 systems and therefore disabled the game-start-animation completely When developing Ace Of Hearts this issue became really problematic, because those in-game-transition-effects like the rolling chip or the zooming heart/spade were affected by this; so I extended my engine by a workaround, essentially patching coordinates and UVs of marked-as-critical triangle-lists so at the end a nice list of inside-viewport-triangles is sent to the compositing-engine. Of course this is no general solution neither, but the best I could do. )

3.2. when using blending on a 16bit hicolor target then fully transparent texels of the source bitmap are not drawn fully transparent but there is a slightly visible "halo", so you can see the rectangular shape of your COBs (composition objects). You can spot that on Ace Of Hearts (tooltype FIX16BIT=0) and M.A.C.E (although it's harder to see here because of the overall darker appearance) if you run it on a 16bit Workbench-Screen.


Cheers,
Daniel

[Hans]

Could you provide a small test example for each bug (where appropriate)? Small test code makes debugging much easier.

[Daytona675x]

Of course, be my guest and enjoy the mess

Here's a link to an archive containing pre-compiled small binaries to reproduce the bugs and a tiny cpp-file, containing all the source (just uncomment the "define"-line matching the bug you'd like to observe).
Note that 2.2. will most likely crash your machine, at least it locks up mine...
The only bug that's missing here is 2.3., as being said it happens randomly. But there's a screenshot inside showing it.

Also note the edited bug report 1.1 above!
All bugs can be reproduced on sam460ex, Radeon 9250, latest official OS, all updates.

Happy fixing

[Karlos]

I expect the non rendering of triangles in Warp3D with vertices a certain distance outside the viewport may be down to guardband clipping.

Unfortunately I no longer have a functioning system to confirm it.

There are numerous issues with texture mapping in the R200 driver when multitexturing is not enabled. I fixed many of them but I'm sure plenty more exist.

[ggw]

(snip)
Unfortunately I no longer have a functioning system to confirm it.
(snip)

Anything we can do to help restore you to a functioning system? $ maybe? Spare parts, maybe?

[Daytona675x]

@Karlos
Thanks for checking it out.

I expect the non rendering of triangles in Warp3D with vertices a certain distance outside the viewport may be down to guardband clipping.

As being said above that should not be the case. The values are way too small for that.

It also seems to depend on the view-port size, the larger the earlier. If you have a 1920-width viewport this effect already happens when a vertex is just a few pixels outside.
Just increase the window-size (line 48,49 to 1800x1000 for example). You will notice that now the triangle vanishs earlier.

And now, to let it vanish almost INSTANTLY also add an offset to its x-coords (line 601,602, just type +1500 in both lines to move it to the right).
Now it vanishs as soon as the rightmost vertex is just a few more pixels outside.

As mentioned the very same is happening with Compositing on R200.

There are numerous issues with texture mapping in the R200 driver when multitexturing is not enabled.

Multitexturing is enabled (line 271). All texture units but the first are disabled (lines 265-270) - at least I hope so, because I may only guess how it is supposed to work since so far nobody was able to explain it...

[Karlos]

Note that both compositing and Warp3D make use of the same RadeonCP resource on R200 (and AFAIK also on R100). It's possible that bugs may exist there or that some command packets aren't quite configured correctly.

As for poor documentation for Warp3D, its true. Unfortunately that affects driver developers as much as it does users as were often in the same boat in terms of understanding the expected behaviour of a function, the implementation of which may be broken for some use cases and only the original author is in a position to tell. Much of the V5 code was implemented to support specific features in minigl. As Warp3D is deprecated I don't expect there to be much incentive to fix issues with these features in particular as long as they function well enough for minigl.

[Hans]

@Karlos
Thanks for checking it out.

I expect the non rendering of triangles in Warp3D with vertices a certain distance outside the viewport may be down to guardband clipping.

As being said above that should not be the case. The values are way too small for that.

It also seems to depend on the view-port size, the larger the earlier. If you have a 1920-width viewport this effect already happens when a vertex is just a few pixels outside.
Just increase the window-size (line 48,49 to 1800x1000 for example). You will notice that now the triangle vanishs earlier.

And now, to let it vanish almost INSTANTLY also add an offset to its x-coords (line 601,602, just type +1500 in both lines to move it to the right).
Now it vanishs as soon as the rightmost vertex is just a few more pixels outside.

This sounds exactly like the guardband problem. Have a look here here.

Note that both compositing and Warp3D make use of the same RadeonCP resource on R200 (and AFAIK also on R100). It's possible that bugs may exist there or that some command packets aren't quite configured correctly.

You can rule that out. The RadeonCP.resource only provides a method for drivers to submit command packets to the GPU. So, the Warp3D driver is 100% in control of what is rendered. In the link that I posted above, Hans-Joerg suggests that the only "fix" would be to rewrite the driver's render pipeline to use the GPU's TCL engine (despite TCL being done on the CPU). That sounds like a lot of work.

I think that fixing MiniGL's flat shading problems would be a better place to start. I kind of suspected that MiniGL might be screwing up the colouring when clipping, due to there being no per-vertex color data.

Hans

[Daytona675x]

@Karlos

Note that both compositing and Warp3D make use of the same RadeonCP resource on R200 (and AFAIK also on R100). It's possible that bugs may exist there or that some command packets aren't quite configured correctly.

Which probably means that fixing one fixes both

As for poor documentation for Warp3D, its true. Unfortunately that affects driver developers as much as it does users

As Warp3D is deprecated I don't expect there to be much incentive to fix issues with these features in particular as long as they function well enough for minigl.

Too bad, especially considering that MiniGL is really slow and therefore not too useful if drawing serious amounts of triangles.

@Hans

This sounds exactly like the guardband problem. Have a look here here.

Have to say it again: it should not be the guard-band. The coordinates are way too small, the guard-band should kick in for coordinates that are +/- really huge!
HJF actually says so too: "The reason for this is to avoid infinite loops in the rasterizer hardware in case the polygon is extremely degenerate (like +/-inf coordinate)."
We are talking about a situation where this does not apply, not even remotely. We are talking about triangles with one vertex outside the view-port by just a few pixels!

You can rule that out.

Considering that the triangle-vanish-effect happens with exactly the same values on Warp3D and Compositing you should probably not rule that out too quickly.
Or somebody made a lot of copy'n'paste

The RadeonCP.resource only provides a method for drivers to submit command packets to the GPU. So, the Warp3D driver is 100% in control of what is rendered.

Superb! If it is 100% in control, then it should be fixable
If this bug is due to the guard-band then there's a simple fix: turn it off or make it as large as it should be. There should be some registers for horiz. and vert. guard-band to adjust/disable it.

In the link that I posted above, Hans-Joerg suggests that the only "fix" would be to rewrite the driver's render pipeline to use the GPU's TCL engine (despite TCL being done on the CPU).

Sounds rather unlogical.
The guard-band-check is applied after transforming, before other HW-clipping and before rasterization. It should not matter wheter the coordinates were transformed by the GPU or by the CPU.
But anyway: it should not be the guard-band in the first place (unless configured to unreasonable small values). And if it is... well, then something in the driver is seriously broken - but it should be fixable without any big render-pipeline-rewrite (although we all would appreciate that ), see above.

[joerg]

It also seems to depend on the view-port size, the larger the earlier. If you have a 1920-width viewport this effect already happens when a vertex is just a few pixels outside.
Just increase the window-size (line 48,49 to 1800x1000 for example). You will notice that now the triangle vanishs earlier.

And now, to let it vanish almost INSTANTLY also add an offset to its x-coords (line 601,602, just type +1500 in both lines to move it to the right).
Now it vanishs as soon as the rightmost vertex is just a few more pixels outside.

This sounds exactly like the guardband problem. Have a look here here.

I don't know anything about Warp3D, but if it isn't the guardband problem and just looking at the width the problems start at: Could it be related to the 2048x2048 3D limit of the the Radeon cards? Or does that only matter for the sources and not the destination window size?