RadeonHD_RM.resource Test 2 (VRAM paging)

Posted by Hans de Ruiter

A-EON Technology has just released version 0.53 of the RadeonHD driver for AmigaOS 4.x to registered users. This version adds the following:

• VRAM buffer paging;
• Partial Radeon HD 7000 series (Southern Islands chipsets) graphics acceleration; and
• The RadeonHD_RM.resource is enabled for outside use (i.e., enabled for 3D driver use).

In short, this version is ready for 3D drivers. This almost brings the driver up to what was planned for version 1. I say almost, because compositing support for Radeon HD 7000 series cards is still missing.

Also released are two test programs. The first is the original RadeonHD_RM.resource test program, which I presented back in October 2011. The second is called RHDRMTest2, which is a new test program that was written specifically to test the new VRAM buffer paging feature.

Registered users of the RadeonHD driver can try these programs out for themselves, provided that they have a Radeon HD 4000 series graphics card (they might work on Radeon HD 2000-3000 series cards). Everyone else can see what it looks like in the video below.

VRAM Buffer Paging

VRAM buffer paging is a feature that allows more VRAM to be allocated than physically exists. When this happens, the driver will store the least used buffers in RAM, and intelligently page buffers into VRAM when the graphics card needs them. Buffers can be textures, shaders, vertex buffers, or other data that the graphics card uses. You can think of it as a form of virtual memory for graphics cards. It allows the system to continue to work even when there isn't enough physical VRAM available for demands, albeit with reduced performance (copying to/from VRAM takes time away from other tasks).

RHDRMTest2 - Confirming that VRAM Buffer Paging Works 

RHDRMTest2 is an updated version of the original RadeonHD_RM.resource test program, that includes z-buffer and hardware clipping support. This renders a 3D scene with more texture and vertex data than can fit into VRAM, thus putting the VRAM buffer paging system through its paces. In theory I could have created a boring artificial test, but I wanted something that at behaved closer to how a real 3D engine would. This meant creating a proper mini 3D graphics engine; one with the following features.

• GPU based 3D Transformation, Clipping, and Lighting;
• Single-layer transparency rendering;
• Hardware Z-buffer support;
• Per-pixel lighting (3 lights, each rendered in its own render pass, and one controlled by the mouse)
  Bump-mapping;
• Wavefront .obj model loading; and
• Bounding sphere based visibility culling.

The result is a 3D animation with real 3D objects (as opposed to the original test program's simple cube and rectangles):

HINT: Best viewed fullscreen in HD. 

You can also view the video on youtube.

NOTE: A big thank you to hostcove for helping to deliver a high quality video that was not made by pointing a camera at the screen.

As you can see, it renders the animation pretty smoothly, with the exception of hiccups when a fair amount of VRAM buffer paging is going on. More importantly, the test/demo keeps on going. There is no crash, no "out of VRAM" error, or any other failure. This is exactly what was expected.

When one object is removed from RHDRMTest2's virtual world then all of the data fits into VRAM, and the animation is rendered smoothly:

HINT: Best viewed fullscreen in HD.

As with the first video, you can also view this video on youtube.

The 3D scene in this test/demo contains round 100,000 triangles, of which up to 50,000 or so can be visible on-screen at any one time. However, it renders the entire scene 4 times; once for ambient lighting, and once for each light (not the most efficient method, but it works). So, it's actually rendering up to 200,000 triangles per frame. That is far beyond anything that any Warp3D program has ever achieved.

Despite all of this, the renderer is actually still very primitive. Bounding-box based visibility culling is the only optimization that is implemented. It has no mip-mapping, no level of detail control, no advanced lighting (e.g., deferred lighting), or any of the other techniques that allow modern game engines to render huge worlds in stunning detail at good grame-rates. I'm looking forward to seeing what developers can/will do once Gallium3D + OpenGL 2+ is available for AmigaOS 4.x.

Bring on the 3D drivers!

Comments (4) | 11 September 2012