Real3D Geometry Processor

[Bart]

Real3D released a PCI accelerator card called R3D/100. Not much is known about this device and it is definitely different than the Pro-1000 but likely an evolution of it. This architectural overview contains a very interesting blurb about the geometry engine, which is claimed to be a RAM and ROM microcode-programmable numerical processor. Figure 2 suggests this was not an off-the-shelf part because of the integrated raster, texture, memory, and PCI blocks. I'm not sure whether it was possible to purchase "IP cores" in the mid 90's.

The Pro-1000 SDK contains two ROM images to program the device with. One is clearly for the PowerPC CPU. The other is called the "loop ROM" and contains what looks to me like mostly meaningless tables of repetitive values. There is some other data in there but it is sparse and does not look like code to me.

Given that Real3D is known to have used Fujitsu and Analog Devices DSPs in their previous designs, I would expect them to use an existing design for the Pro-1000 rather than rolling their own custom processor. A good candidate would have been the TMS320C80 Media Video Processor which was a 5-core design introduced in the early 90's. (Her'es a manual for the main core). From a cursory glance at the loop ROM, this doesn't seem to be it, though.

If it was truly a custom part, there isn't anything we can do to reverse engineer it. At some point, I would like to try one last experiment: checking VROM usage (by marking used addresses) to determine if there is any untouched data there that may be a DSP program.

[Ian]

I would imagine memory and chips to be off the shelf parts, but honestly I'd be surprised if the geometry processor was not a custom part.

[Bart]

I would imagine memory and chips to be off the shelf parts, but honestly I'd be surprised if the geometry processor was not a custom part.

Question is whether DSP cores were available for integration in custom designs at the time. Theoretically, HDL tools were plenty capable back then. ElSemi points out that the Model 2 DSPs were all marked as Sega custom parts (although they might have just stamped Sega on the chips to obscure their origin). One of the Fujitsu-supplied DSPs may have been customized for Model 2. So if Real3D could license a Fujitsu DSP engine, maybe they did just that for Model 3's geometry processor.

It would be interesting to see if the SDK PowerPC ROM contains any code to read out the microcode. Model 3 games perform some sort of VROM test using JTAG but it clearly does not involve reading all VROM data out.

[Ian]

What are you looking out for?
I am guessing IRQ's and the communication to the actual hardware?

[Bart]

What are you looking out for?
I am guessing IRQ's and the communication to the actual hardware?

Well, I was thinking more about the actual scene graph processing, T&L, frustum set up, etc. All that would be explained if we had the underlying DSP code. There would probably also be an interface to trigger interrupts on the main CPU, yes.

I'm not going to spend much time looking for the DSP code because I think it's a waste of time for now. But I'll keep an eye open. One thing I've wanted to do is create a coverage map for VROM usage to determine if there is any chunk of VROM not being used for textures or models. That could reveal whether there are any color/gamma tables in VROM or even (very unlikely) DSP code.

I definitely want to spend some time again looking at CPU/Real3D/IRQ timing again but I might have to push that back beyond the next release. I think we're pretty close to having something releasable.

[Ian]

Scene graph traversal would be useful. What I am doing currently works, but i know it's not quite the same as what the hardware is doing because I still see some transparency errors.
But I think I basically know how culling works, or is supposed to work.
The distance part in the culling nodes, you can use it to build a bounding box for each node. It would be simple then to clip against the view frustum. Whatever bounding boxes are left inside the view frustum it would be trivial to work out a near/far value pair for them.

[Bart]

Scene graph traversal would be useful. What I am doing currently works, but i know it's not quite the same as what the hardware is doing because I still see some transparency errors.

Are any caused by alpha textures? If the transparency issues are all due to translucent polygons, stipple is the probable cause.

But I think I basically know how culling works, or is supposed to work.
The distance part in the culling nodes, you can use it to build a bounding box for each node. It would be simple then to clip against the view frustum. Whatever bounding boxes are left inside the view frustum it would be trivial to work out a near/far value pair for them.

Do you think this might be useful for Z near/far? I thought that the nearest bounding boxes could theoretically be behind the view plane, making them somewhat useless, but you would know better having looked at them.

[Ian]

You would clip the bounding boxes to the view frustum. Any anything outside (including behind) would also automatically be culled. Right now when rendering, we are actually rendering as far backwards (ie behind the player) as we are forwards.

[Bart]

You would clip the bounding boxes to the view frustum. Any anything outside (including behind) would also automatically be culled. Right now when rendering, we are actually rendering as far backwards (ie behind the player) as we are forwards.

Ah, so it sounds like this wouldn't help us estimate a near Z plane.

I wouldn't worry about implementing clipping tests to reject nodes. If you examine games in Nik's 3D debugger, you'll notice that the PowerPC is already very good at disabling most geometry outside of the view frustum. In a typical scene, there should not be all that much geometry outside the camera view. And as you point out, Model 3 geometry counts are pretty low and rendering isn't the bottle neck anyway.

[Ian]

Well,
From a performance point of view it really makes no odds. But to actually extract usable near/far values you might actually have to do the math on each node. The maths is quite simple from what I recall, off the top of my head you would just do a dot product against the frustum planes, subtracting the plane distance, with the bounding box min/max values.