blog

Want to Learn How to Use Warp3D Nova in Your Software?

Thu, 26 May 2016 11:16:19 +0000

The announcement of Warp3D Nova in late March 2016 caused quite a bit of excitement. It's a new and modern shader-based 3D graphics API, and it opens up new possibilities. However, those possibilities only matter if people (software developers) turn them into reality.

To help developers get started, I've written the first of what should become a series of tutorials about how to use Warp3D Nova. Check the first tutorial out, here:

https://keasigmadelta.co.nz/blog/getting-started-with-warp3d-nova-setting-up-a-render-context/

If you're interested in graphics/games programming on AmigaOS, then this tutorial is for you. Enjoy!

NOTE: There is an OpenGL ES 2 wrapper in the works, and that's an option for developers who need their software to work on other platforms. If you're writing just for AmigaOS, though, then you can also use Warp3D Nova directly. The tutorials will teach you how.

Warp3D Driver Development in Pictures - The W3D_SI Driver

Sat, 08 Aug 2015 16:41:32 +0000

The Warp3D driver for Southern Islands GPUs has been in the hands of users for months now, so this blog post is well overdue. I always intended to give you a glimpse into the development process for this driver, and even saved screenshots regularly during the development process. I just never managed to find the time to publish it. So, I've stolen some time out of my schedule to finally get it online.

Developing software involves taking small steps at a time. Gradually features and functionality get added one by one, until the software is ready for release. Developing the Warp3D driver has given me the unique opportunity to show you this process in pictures. In the slideshow, you'll see the driver grow from a skeleton driver that does almost nothing, through to the first driver that was publicly released.

To start your journey through the development process, go to the gallery page, and click on the first screenshot. It'll open a "lightbox," and you'll be able to step through the slideshow. The captions tell the story.

Click Here to Go to the Gallery Page

NOTE: Occasionally the gallery page's lightbox doesn't open, and you get redirected to the image file instead. When that happens, reload the gallery page, and try again. Usually the javascript is loaded properly the second time round.

Composited Video (Radeon HD driver version 2.x)

Fri, 09 Jan 2015 19:22:25 +0000

Version 2.4 of the driver was announced and released a while ago, so this post is on the late side. In fact, I almost forgot to write it (I did the work for this release a while ago). However, adding composited video is a major milestone so this development log wouldn't be complete without at least mentioning it.

Faster Video Playback Via Composited Video

The key goal for version 2.x was to improve video playback with Radeon HD cards. Video playback is an area in which we have been lacking, which is why A-EON Technology contacted me in early 2014 to commission this project.

Unlike older Radeon cards, Radeon HD graphics cards don't have overlay hardware (to the best of my knowledge). Hardware overlay is an old and rather obsolete method to accelerate video playback by allowing video frames to be displayed directly in their native YUV format.

Rather than try to emulate overlay using the GPU, I opted to add support for YUV formats directly into AmigaOS' CompositeTags() function. I call this "composited video," and it combines the advantages of "textured video" (the overlay replacement on other OSes) with all the power of compositing.

Some key features/advantages of composited video are:

Accelerates video playback by enabling planar YUV video frames to be rendered directly to a screen/window/bitmap
No limit to how many videos can be displayed simultaneously (overlay is restricted to 1-2 hardware surfaces)
Can be rendered anywhere, from full-screen to multiple videos in a webpage (on AmigaOS, overlay is restricted to a window)
Supports both SD and HD YUV video standards, and even custom YUV to RGB transformation matrices (NOTE: you can exploit this to get brightness, contrast & saturation adjustment for free)
Can use alpha blending for combining video with other graphics; this allows subtle anti-aliased blending, unlike overlay's on/off colour-keying
Can use video frames directly with the full power of CompositeTags(); this includes alpha blending, rotation, warping, cross-fades, vertex-arrays, etc.

The last item in the list above introduces a whole set of unique possibilities that previously weren't possible. It could be used for much more than just faster video display; it could be used for real-time video effects, from cross-fades to 3D transitions and more. You could even project video frames into the Composite3DDemo if you wanted to; yes, even wrapped around the ball (although, good luck watching the video that way ;-) ).

How Does it Improve Performance?

Composited video (and overlay) improve performance in two ways:

It reduces the bandwidth required to copy video frames to the graphics card (YUV420p bitmaps are 37.5% the size of an equivalent 32-bit RGBA bitmap)
It shifts the task of converting from YUV to RGB (the graphics card's native format) from the CPU to the GPU. The GPU is better suited to this task, and it frees the CPU up to work on other things, like decoding the next frame

The net result is that it takes less processing power and bus bandwidth to display the same video.

What is YUV? And why do video files use that format? Basically, the Y channel stores a pixel's brightness/luminance, while the U & V channels store the colour information. Video files use this format instead of RGB, because humans see brightness differences at a higher resolution than grayscale. So, we can get away with storing the colour channels at a lower resolution than the brightness without people noticing it. Effectively, we've compressed the video frame while maintaining high visual quality.

AmigaOS 4.1 Final Edition & DMA

This has nothing to do with the RadeonHD driver, but it's still part of the project to improve video playback. Since the video is still being decoded by the CPU, the speed at which video frames are copied to the graphics card directly affects performance. With the A1-X1000 (as at 10 January 2015, the most powerful AmigaOS machine), this was still being done by the CPU.

So, A-EON asked me to add DMA support to the graphics library for the A1-X1000. This had been done previously for ACube's Sam4x0 series. The results speak for themselves:

Comparing DMA accelerated WritePixelArray and ReadPixelArray with CPU based coping algorithms (hardware: A1-X1000 and Radeon HD R9 270).

As part of this project I optimized the process of copying full bitmaps to/from VRAM. Sam460ex users also benefit from this change.

Results & Final Comments

The net result of composited video and the DMA enhancements in AmigaOS 4.1 Final Edition, is faster video playback. In particular, A1-X1000 users can now play HD videos. Full 1080p video playback performance depends on the video codec. I had almost 50% CPU power to spare when playing a 1080p DIVX of Big Buck Bunny (see the screenshot below). H.264 encoded videos are a bit more hit and miss. Some 1080p H.264 videos play fine, while others are encoded with computationally intensive settings that are too much. Still, it's a big step up from what we used to have.

I'd like to quickly thank Kjetil, Stephen, and other developers who have worked hard (and are still doing so) to add composited video support to their software. Driver features only benefit users when applications make use of them.

What's next? Well, it would be great if we could use the video decoder that's built in to all Radeon HD cards. That would allow full HD playback of even the most demanding H.264 video. Yes, even with a lowly Sam440. That's quite a project, though. In the meantime, enjoy the improved video playback!

A 1080p video being played in real-time on an A1-X1000 using composited video, with plenty of processing power to spare.

The AmigaOS 4.x Radeon HD Driver Reaches Version 1.0

Tue, 01 Apr 2014 19:02:54 +0000

Yes, it's official; the AmigaOS 4.x Radeon HD driver is no longer in beta. As announced in A-EON Technology's press release, version 1.0 has been released. This milestone marks the end of years of hard work and extensive testing.

Version 1.0 incorporates some bug fixes and enhancements that were made since the last public release, which was 1.0 RC2 (0.57). These changes span two internal release candidates that beta testers have put through their paces over the last few months. The most serious of these bugs was one that could cause a deadlock when the RadeonHD_RM.resource's memory management system was in use (by 3D drivers, or the RHDRMTest2 test program).** While this bug was largely irrelevant until 3D drivers arrive (and the system runs out of VRAM), I felt that it had to be fixed before version 1.0 could be released.

Here are the list of changes since the last public release:

Resolved an issue which could cause a deadlock when the RadeonHD_RM.resource's memory management was used (locked up RHDRMTest2)
WaitIdle() now locks the command processor to ensure that it really is idle on exit, and prevents a very rare infinite loop from occurring
Now lower Evergreen+ clocks down to initial values for initialisation after a soft-reset (helps with some tricky RadeonHD cards)
Fixed a bug in the code to get the graphics card's ROM
Disabled compositing for 16-bit target bitmaps/screens with Radeon HD 7xxx series cards (did not work correctly due to a hardware limitation of these cards)

It has been a long journey to get to this point, and it's feels great to have reached this milestone. I hope that users have fun using their systems, even while they wait for 3D drivers to arrive. The journey's not over yet, so be sure to enjoy the ride.

** The RadeonHD_RM.resource provides external 3D drivers with shared access to the Radeon HD's GPU and VRAM.

1.0

Radeon HD 6450 vs Radeon 9250 - The Compositing Showdown

Mon, 19 Nov 2012 13:29:11 +0000

Occasionally I see comments on AmigaOS related forums asking what advantage Radeon HD cards have right now (NOTE: When writing this, 3D drivers were still not available). While this question will soon be irrelevant when the Warp3D drivers arrive, it is a legitimate question. Well, today I was sent a link to a youtube video that gives a pretty clear answer to that question:

Direct link to youtube video. NOTE: It is worth watching this video in HD.

This video comes courtesy of Frank Menzel, one of the talented individuals behind AmiBoing. AmiBoing (or Entwickler-X) have produced a number of games that are well polished audiovisually, and take advantage of AmigaOS 4.1's compositing feature.

This video shows the performance of a parallax scroller on a Radeon 9250, and a Radeon HD 6450 on a Sam440-flex machine. There are multiple parallax layers, and plenty of high resolution bitmaps/textures. It looks like this is the beginnings of a new game... but, I digress.

The results are very conclusive:

Test Conditions	Radeon 9250	Radeon HD 6450	Performance Increase **
Windowed mode (800x600 on a 1920x1080 screen)	22 fps (39 fps at end with fewer objects)	74 fps (96 fps at end)	236%
Full-screen 1920x1080 (i.e., full HD)	1-3 fps (14 fps at end)	31 fps (50 fps at end)	1450%

** NOTE: The performance increase column measures the change in fps, not the absolute fps difference. For example, The Radeon HD 6450's fps is actually 336% of the Radeon 9250's fps, but the change in fps is 236%.

Clearly, there is no contest; the Radeon HD 6450 leaves the Radeon 9250 in the dust. The Radeon HD 6450 can render the scroller at full HD at smooth framerates whereas, it bumbles along at ~1-3 fps on a Radeon 9250. If this were a game, then it would only be playable in full HD using the 6450.

One thing that I must stress is that both of the test cards are low-end in their respective families. Added to that, the Radeon HD 6450 was further hampered by a PCI-to-PCIe bridge (it was tested on a lowly Sam440-flex, which doesn't have PCI-Express slots). Mid to high-end Radeon HD cards are much more powerful than the 6450, so imagine what these are capable of.

What these results show, is that the Radeon HD cards really are a game changer. The extra performance opens up new possibilities for developers. Plus, the game will change yet again when full OpenGL support unlocks the full potential of their GPUs.

I'm very much looking forward to not only 3D drivers for these cards, but what developers will do with the new possibilities.

Full Acceleration Support for Radeon HD 7000 series

Thu, 04 Oct 2012 17:20:58 +0000

I'm pleased to announce (together with A-EON Technology) that the RadeonHD driver for AmigaOS 4.x now fully supports the Radeon HD 7000 series (Southern Islands chipsets). Full 2D acceleration including compositing has been implemented. This is another major milestone as the driver now supports the very latest graphics cards in the Radeon HD range. You can't get newer or more cutting edge than that. The RadeonHD_RM.resource also supports the 7000 series (a necessity for 2D acceleration too), which means that this latest series is also ready for its 3D drivers. This completes everything that was planned for version 1 of the driver.

Registered users will be able to download the update soon, while others can purchase the driver from A-EON.

It's Tough Without Documentation

Implementing Southern Islands GPU (Radeon HD 7000 series) support was a long and, at times, difficult endeavour. To begin with, this was the first of their Graphic Core Next (GCN) architecture, which mark some large-scale changes. The GPU's Instruction Set Architecture (ISA) was completely changed from previous Radeon HD generations. Complicating matter further was AMD's slowness in releasing the documentation for this new architecture.

With no documentation I had no choice but to fall back to using AMD's own code (in the Linux drivers) as documentation. Unfortunately, AMD decided that the EXA driver was obsolete, and all acceleration - both 2D and 3D - was going to go via Gallium 3D. From their viewpoint this was a completely logical decision, and I truly wish that I could have followed suit. However, the Gallium3D port for AmigaOS was still a work-in-progress, and, the Gallium3D driver for Southern Islands GPUs (radeonsi) was (and still is, as at 5 October 2012) not yet usable. As a result, I couldn't follow their lead, and neither did I have example 2D acceleration code to use as a reference. 2D acceleration code is much simpler and easier to follow than 3D driver code.

As you can see, the situation was rather difficult, but that wasn't going to stop me. I managed to decipher parts of the Southern Islands ISA via what I could glean from AMD's GCN presentations, and from the LLVM descriptor files in the radeonsi driver. From this I created a (very large) set of C macros, so that I could hand-assemble Southern Islands shader code. At this point things became a little easier, because the Southern Islands ISA is much easier to use than the ISA for previous generations. Eventually, I got the solid fill shader working, and then the other blitter shaders. Good progress.

Baffling Behaviour

Getting the blitter acceleration working was great, but that success soured quickly when the time came to implement compositing. The power of AmigaOS' compositing feature comes at the cost of greater driver complexity when compared to simple blitter functions. This means both more complicated driver code, and more complicated shaders. That, however, wasn't the biggest problem. After a while the compositing code eventually passed all of the basic tests; but, there were ugly vertical green and blue lines all over the place. Even worse, my Radeon HD 7770 would lock up within a few seconds when compositing was being used a lot unless it was underclocked by about 5%.

Try as I might, after weeks of effort I still could not find a solution to these two problems. After some email discussion with AMD software developers, I discovered that their radeonsi (Gallium3D) driver also suffered from the same vertical line problem. This only occurred if alpha blending was being used. So, the decision was made to put aside Southern Islands GPU support for a while. I asked the guys at AMD to let me know if they found a solution. In the meantime, I switched back to working on the memory management part of the RadeonHD_RM.resource, which was the last task needed to get the driver ready for 3D.

Eventually, I got an email from an AMD software developer who had discovered what was going wrong, and had found a solution. As it turned out, the shader export format that we had both used in our drivers was incompatible with 32-bit ARGB pixel formats. After changing the shader export format, compositing worked as it should. Well, almost. All blitter functions had to be updated to use the correct shader export format, as using the wrong format was corrupting the alpha channels of bitmaps. With that done, compositing worked as it should.

Power Problems

Alas, the battle was won, but the war was not quite over. Solving the compositing problem did not eliminate the GPU lockup problem as was hoped. My Radeon HD 7770 worked just fine in an x86 PC, so it was definitely a driver bug. The problem was eventually traced to a bug in the power table parsing code, which failed to transform a voltage tag to an actual voltage. As a result, when the driver ramped up the GPU' clock to full speed, the voltage was left at a minimal value. Running at high frequency but low voltage is a recipe for instability.

NOTE: Radeon HD 6000 and 7000 series cards initially start at minimal frequencies (GPU: 300 MHz, VRAM: 150 MHz) and voltages, because the BIOS/firmware does not have the microcode needed to set up the memory controllers. So, leaving the settings at their default is not an option.

Victory!

With the power table parsing bug fixed Radeon HD 7000 series was finally done. Everything worked as it should and there were no more lockups. Victory at last!

Implementing 7000 series support has been quite the (long) rollercoaster ride, but the effort was definitely worth it in the end. AmigaOS can now use the very latest in graphic card technology.

RadeonHD_RM.resource Test 2 (VRAM paging)

Tue, 11 Sep 2012 02:28:06 +0000

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.

&amp;amp;amp;amp;amp;nbsp;

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.

&amp;amp;amp;amp;amp;amp;amp;nbsp;

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!

Updating the RadeonHD Driver Compatibility List

Wed, 05 Sep 2012 20:15:54 +0000

I hope that people are enjoying the updated RadeonHD driver with Radeon HD 5000 and 6000 series support. While most of the feedback has been good, there have been a few reports of problems with a few specific graphics card models. Given that the driver supports such a wide range of cards (from the Radeon X1000 series through to the Radeon HD 6000 series), it is inevitable that some specific models will have trouble.

While the problems with specific models should be solved eventually, it would be much easier for people to simply buy a model that is known to work. The RadeonHD driver hardware compatibility list exists exactly for this purpose. It lists the cards that have been tested, indicating if they work properly or not. If you are planning to buy a Radeon HD card for use with AmigaOS, please check out this list first.

NOTE: Please also look at the motherboards section of the compatibility list, as not all motherboards are able to handle Radeon HD cards properly.

Help Needed

The compatibility list is only as good as the information provided. Since there is no way that I could ever test all available hardware, I need your help. If you have a card that is not on this list, or whose entry is incorrect, then please post the full details to this thread, or send them via email.

The details required are:

Manufacture;
Model name;
The manufacturer's ID (if available;
The newest version of the driver that it was tested with; and
If it works, and any pertinent notes (e.g., if it partially works, describe what works and doesn't).

Thanks in advance for your help in keeping this list up-to-date.

RadeonHD 5000 and 6000 Support

Sun, 24 Jun 2012 17:34:50 +0000

The news is already all over the AmigaOS community; with funding from A-Eon Technology, I'm pleased to deliver 2D support for Radeon HD 5000 and 6000 series cards. Support for the Radeon HD 7000 series is also in the works. This is probably the biggest milestone yet in the RadeonHD driver project.

A few months ago I got an email from Trevor (A-Eon Technology) letting me know that supply of Radeon HD 4000 series cards was getting so scarce that supply could no longer be guaranteed. This made adding support for newer series urgent, and so an agreement was made in order to deliver this As Soon As Possible (ASAP). I was initially disappointed when supply of Radeon HD 4000 series became scarce but now I'm proud of what has been achieved. The RadeonHD driver once again supports some of the latest cards available.

As part of the agreement, A-Eon Technology has gained exclusive distribution rights for the AmigaOS 4 driver. A1-X1000 customers, who have already paid for a license to the upcoming AmigaOS 4.2 update will receive these updates automatically. Sam460ex customers wanting to upgrade their driver so that they can use newer cards can purchase a license online.

I know that paying for drivers will be unpopular with some people, as everyone is used to getting drivers for free. Indeed, I gave this some thought before entering into agreements, as i have received donations to support the driver early on. However, I firmly believe that all those who donated, want to see the RadeonHD driver completed and available ASAP. Unfortunately, while the donations helped with motivation and the purchase of equipment, it was like a drop in the ocean next to the true development cost (measured in how much you'd have to pay a full-time developer). This meant that the driver remained a hobby project, and captive to my ever shrinking "spare time." ACube supported the project as much as they could, and that did help with a few bursts of accelerated development. Nevertheless, that alone couldn't deliver the results that everyone would like. The driver development continued slowly, and the supported cards that were once brand new, were eventually no longer available. All along, the AmigaOS community continued waiting as patiently as possible. Pace was too slow for you, the community, and too slow for me. The project urgently needed me to work on it for more days per week, but that was just not possible. This was as true a year ago as it was now. We need to regain some momentum, and a donation funded effort was never going to deliver the results that we all want.

To make matters even more difficult, my own personal situation has changed. I have gone from a university student, to an entrepreneur who is working very hard to start and build a company. This is a major undertaking that is still very much a work-in progress. I was seriously considering having to make the very uncomfortable and disappointing decision to temporarily put the whole RadeonHD driver project on ice, so that I could focus all of my energies on my company. Needless to say, this would not have been good. All AmigaOS 4.x enthusiasts including myself want AmigaOS 4.2 with full OpenGL support ASAP; it's what we've been waiting for.

So, we have a driver that urgently needs some accelerated development, and ever shrinking spare time to work on it. With major OSes, those "free drivers" are actually paid for by the millions of graphics card purchasers, who fund the manufacturer's own driver development costs. If you purchased a Radeon HD card for your Amiga, you too, paid for Windows, Mac, and Linux drivers, even though you're probably not using them.

Enter the agreements with A-Eon Technology. These provided funding far beyond what donations or a small bounty ever could. It allowed me to work on the driver several days per week, making real progress. The unavailability of the Radeon HD 4000 series was an added complication and expense, but one that has been overcome. This meant real progress, and support for currently available now instead of in a year's time at the earliest.

A-Eon Technology naturally needs to recoup their costs, and hence the driver is available for a fee to AmigaOS 4.1 owners. Those with an AmigaOS 4.2 license (i.e., A1-X1000 owners) naturally have already paid for their updates. From my perspective, this was and is the best way forward. In fact, it was pretty much the only way to get the driver finished in an acceptable time-frame. It provided the RadeonHD driver project with a much needed shot in the arm, real progress, real momentum, and most importantly, better drivers for current cards much sooner.

What has been achieved so far is definitely an achievement, and a huge milestone. I sincerely hope that we can build upon this momentum. Please continue to support all of the AmigaOS 4.x developers and companies involved. We are all hard at work to deliver the best AmigaOS possible.

Roll on AmigaOS 4.2!

Radeon HD Vertical Blanking Interrupt Support is Done

Mon, 27 Feb 2012 21:29:30 +0000

Thanks to accelerated development, Vertical Blanking (VBlank) interrupt support for Radeon HD 2000-4000 cards (R600/R700 chipsets) is now done. If development pace had continued at the old "spare-time project" rate, then this would still be a work-in-progress. VBlank interrupts are used to achieve smooth double-buffered animation. According to one beta tester, "the 3DCompositeDemo runs a lot more smoothly now with interrupts enabled."

Apart from providing smoother animation, this also eliminates the wasting of CPU cycles while waiting for the VBlank period. RadeonHD.chip driver users may have noticed that certain programs (including the Composite3DDemo) caused CPU usage to go up to 100%. Well, lack of interrupt support in the driver is the reason why. Without interrupts, waiting for the VBlank period means polling the graphics card, wasting a lot of CPU cycles in the process. With interrupt support implemented, CPU usage with the Composite3DDemo drops down to 25-75%, depending on the hardware and resolution.

A Complex Interrupt Controller

With Radeon X1000 series cards, VBlank interrupt support was so easy to implement that they weren't even worth mentioning. However, Radeon HD cards are a completely different design. They have a complex interrupt controller that even has its own microcode (which the driver must upload to the controller). Interrupt events are written to a ring-buffer, which the driver must then read and interpret in the interrupt handler. While this setup has its advantages, it is quite a bit more complicated than simple interrupt status registers (which it also has). Additionally, the details of this controller are missing from the documentation. This is why this feature had not yet been implemented.

Fortunately, AMD provides not only the all-important microcode, but also code to program the interrupt controller (via the open-source Linux drivers). Using this code as a starting point, adding interrupt support proved to be relatively plain sailing. In fact, once all of the code adaptation had been done, it almost worked on the first test. The one mistake that I had made was forgetting to pass on the VBlank interrupt to Picasso96, meaning that programs were left waiting forever. There was also an issue with waiting for interrupts while switching screen-modes (during which time Radeon HD cards don't send VBlank interrupts), but that was solved fairly quickly.

What are VBlank Interrupts and how do they Help?

The VBlank period is the small period between outputting the last line of one frame, and starting on the next frame. Back when computer monitors and televisions were Cathode Ray Tubes (CRTs), this was the brief period during which the electron beam that drew the image onto the screen would quickly be moved up to the top of the screen for the next frame (or field for interlaced displays). Today, this VBlank period is still there. More importantly, this corresponds to the start of a new frame.

Programs that display animations need to swap one frame (image) for the next during the VBlank period. Failing to perform the swap during that time can result in part of the screen showing an old frame, and the other showing the new one. This is visible as ugly "tearing" artifacts. Thus, the program needs to know when the VBlank period occurs.

This is where the VBlank interrupt comes in. The graphics card sends an interrupt to the CPU, letting it know that the VBlank period is now. Next, the OS performs double-buffering and/or lets any program that is waiting for the VBlank period resume execution. The result is smooth and tear-free animation.

Without VBlank interrupts, the CPU has to poll the graphics card's VBlank state. This wastes CPU cycles, and instantly brings CPU usage to 100% (as mentioned earlier). Apart from being inefficient, it is also less accurate. It's easy to see why VBlank interrupts are superior to polling the hardware (as are interrupts in general).

What's Next?

As I said in the previous development log post, the next task is implementing Video RAM (VRAM) management for the RadeonHD_RM.resource (intelligent VRAM buffer paging). This is essential for stable 3D operation. At present, if a 3D application were to run out of VRAM, bad things might happen. By paging out textures/buffers that are least likely to be needed soon, the drivers will be able to handle "out of VRAM" situations with ease.

NOTE: This development log gives a "behind the scenes look" at the progress of the RadeonHD driver's development. As such, its contents reflect the state of the development version of the driver, and not the state of the publicly released version.

RadeonHD: Accelerated Development

Sat, 25 Feb 2012 00:27:34 +0000

I am pleased to announce that Trevor Dickinson (A-EON Technology) and I have concluded an agreement for continued development of the RadeonHD driver for AmigaOS. I am currently working to get the driver fully ready for 3D, and to release quality (i.e., to version 1). Thanks to the support of Trevor Dickinson (A-EON Technology), I will be able to devote more time to RadeonHD driver development over the next few months, and achieve this goal much sooner than would otherwise have been the case.

The features being worked on are:

Vertical blanking interrupt support for Radeon HD cards (no more wasting CPU cycles when double-buffering); and

Video RAM (VRAM) management for the RadeonHD_RM.resource (intelligent VRAM buffer paging).

The last feature is essential for stable 3D operation. At present, if a 3D application were to run out of VRAM, bad things might happen. By paging out textures/buffers that are least likely to be needed soon, the drivers will be able to handle "out of VRAM" situations with ease.

I look forward to delivering RadeonHD.chip version 1.x and, of course, to be able to run modern 3D applications using Radeon HD cards and AmigaOS.

View the press release on amigans.net.

RadeonHD.chip 0.32 - Bug-Fixes and Fully Working 2D

Mon, 06 Feb 2012 23:56:56 +0000

If you've been keeping up-to-date with AmigaOS news, you have no doubt heard that AmigaONE X1000 First Contact machines are now shipping to customers, and that Sam460ex owners (including people with AmigaOne 500s) have received an updated RadeonHD driver. Both groups are using version 0.32 of the RadeonHD.chip driver. This marks another milestone; one that I like to call, fully working 2D.

This release provides users with full 2D support for all cards from the Radeon X1300 through to the Radeon HD 4890. Previously, Sam460ex users with Radeon HD cards had to make do without hardware accelerated compositing. Now, compositing is available for all supported cards. At this point, 2D support for all chipsets is roughly on par. I say roughly, because a few minor acceleration functions (e.g., line drawing) are still Radeon X1000 series only. However, you are unlikely to notice this, as all of the most important functions are implemented.

What's New?

I'm sure that some people will be thinking, "but wasn't compositing for Radeon HD cards done, April 2011?" Well, yes and no. Compositing was indeed operational, but one of the more advanced compositing features - using homogeneous texture coordinates - was missing for all chipsets. In fact, the primary focus of recent development has been fixing bugs. The complete list of changes since the first release is:

DVI/HDMI output is now supported on Radeon HD 4000 series graphics cards (R700 series chipsets);

Compositing supported on Radeon HD graphics cards (R600/R700 chipsets);

RV770 (Radeon HD 4850) and mobility Radeon HD chipsets are now supported (fixed the GPU initialisation);

Compositing now supports homogeneous texture coordinates with vertex arrays on all supported chipsets (useful for image warping);

Eliminated the intermittent graphics glitches that could occur with R600/R700 chipsets (e.g., yellow screens, fill-rect failure on 8-bit screens;

Fixed a bug that could cause some screens misalignement;

With interrupts disabled, could get multiple "vertical syncs" in one VBlank period (could cause havoc with timing). FIXED;

Fixed a number of R500 (Radeon X1000 series) compositing bugs that caused various things to be rendered incorrectly (e.g., the intermittent dark/black separators and backgrounds in AmiDock);

The mouse pointer now disappears when it's supposed to (i.e., MouseBlanker works, and SDL games no longer have two pointers);

Some R700 GPUs were locking up when compositing "large" vertex arrays. FIXED;

Screens that were larger than the display resolution were garbled. FIXED;

R500 vertex array clipping was one pixel larger than it was supposed to be (could cause the right-hand edge to spill over to the left most column of pixels). FIXED;

Fixed an R500 compositing bug that could cause corruption if one compositing operation rapidly draws directly over the previous one; and,

WaitTOF() and similar functions could cause the machine to lockup when called from a task with a priority >= 1. FIXED.

By far the biggest problem was the driver's inability to use homogeneous texture coordinates with vertex arrays. What can homogeneous texture coordinates be used for? Well, check out another of my test programs turned demo: Composite3DDemo. This shows what can be done with Amiga OS 4.1's compositing feature, a little creative thinking, and some mathematics. Incidentally, this demo was instrumental in me discovering the R700 GPU lockup issue before anyone else did (version 0.27 had that bug). Phew!

All in all, I'm quite happy with the updated driver that I have delivered.

What's Next?

I could almost copy and paste what I wrote in the previous entry to this log. Basically, the focus moves back to working on the RadeonHD_RM.resource (important for 3D drivers), and implementing missing features such as interrupt support for Radeon HD cards.

The RadeonHD_RM.resource

Mon, 24 Oct 2011 23:00:00 +0000

A while ago I mentioned the RadeonHD_RM.resource, and said that I'd give more details later. Several posts to this development log have come since, without a mention about this resource. Today, I'm going to deliver those details, and provide a glimpse of what is still to come.

The RadeonHD_RM.resource is a "render manager," hence the "RM" part of the name. It provides multiple separate drivers with access to the GPU and Video RAM (VRAM). This resource is part of the RadeonHD.chip 2D driver, and the 2D acceleration code for R600/700 chipsets (RadeonHD 2000-4000 series) has already been using it to send render commands to the GPU since the end of 2010. Since then, there have been bug-fixes, R600/R700 compositing has been implemented, and DVI output for Radeon HD 3000-4000. I have also been working on getting the RadeonHD_RM.resource ready for external drivers.

In addition to working on the driver, I also worked on a proof-of-concept test application (app). The test program allows me to test the RadeonHD_RM.resource in isolation of any 3D drivers. It has already helped me to find and eliminate several bugs, including an annoying vsync problem (fixed a few days ago).

I am pleased to announce that the RadeonHD_RM.resource has now progressed to the point where an external driver can render 3D graphics on a Radeon HD 2000-4000 card. Screenshots are at the bottom of this page, but this really is best seen in video form (hint, best viewed in HD at 720p):

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.

Except for the Workbench screen, all of the graphics that you see in the video was rendered via the RadeonHD_RM.resource on a Radeon HD 4650. In fact, the test app doesn't even open the Picasso96API.library; it doesn't even know that Picasso96 exists. No, it's not a driver, but it demonstrates that the RadeonHD.chip driver is ready for 3D.

Features

Some of the features in the proof-of-concept are:

GPU based 3D transformation and lighting

Per-pixel lighting (8 lights, each rendered in its own render pass, and one controlled by the mouse)

Bump-mapping

All of these are things that MiniGL/Warp3D cannot do. The test-app may be primarily for testing the RadeonHD_RM.resource, but it also gives you a glimpse of what will be possible when OpenGL 2+ support is finally available on AmigaOS. These new capabilities are why I embarked on the RadeonHD driver project in the first place.

What's next

Obviously, getting the Gallium3D drivers working is next, but not by me personally. Hans-Joerg Frieden has been working on porting and integrating MESA into the OS, and will continue to do so. There is still much work for me to do on the RadeonHD.chip driver itself. There are bugs to fix, and RadeonHD_RM.resource may be ready for 3D, but it's not yet ready for release.

What's most important is that an external 3D driver is now possible. We're almost there.

DVI output for Radeon HD 4000 series cards

Fri, 06 May 2011 18:26:10 +0000

I am pleased to announce that the RadeonHD driver for AmigaOS 4.x can now also output to DVI on Radeon HD 4000 series cards. Apart from being another item ticked off the driver development to-do list, from a personal perspective this means that I can now use my 4-port DVI KVM switch fully. Previously, switching to my Sam460ex would mean the monitor switching to the VGA output, and then manually switching to DVI again when switching back to another machine. The button on my monitor for switching inputs has already lost its "click" sensation due to the large amount of switching, so I am glad to hand that task over to the KVM.

My hopes that adding DVI output would be a "quick fix" were quickly dashed when fixing what I thought was the cause resulted in no change. The task quickly became a needle-in-a-haystack hunt; nay, multiple needle-in-a-haystack hunts for what AtomBIOS functions had been added or changed, and where to get the additional data that was needed (the AtomBIOS is undocumented). The AtomBIOS' API is tightly coupled to the hardware, meaning that new functions are added, and old ones get new versions (functions have version numbers so that they can be changed at will) with new inputs and outputs. One by one, changes were tracked down and added to the driver, most often without any noticeable change. As you can imagine, working hard and getting seemingly no result is very frustrating. At one stage I even lost VGA output, thanks to an introduced bug that was later tracked down and fixed. Eventually, the behaviour of the DVI output started changing/improving, giving a much needed motivation boost to fix the remaining problems and get it working properly. With one final compile and reset, the DVI output showed the AmigaOS 4.1 boot picture, and just worked.

Radeon HD 2000-4000 Compositing is Operational

Sun, 03 Apr 2011 12:11:03 +0000

The title of this post says it all; compositing for Radeon HD 2000-4000 graphics cards (R6xx-R7xx chipsets) is done. This is another milestone for the RadeonHD driver AmigaOS 4.x. Completion of this major feature puts the support for Radeon HD cards (R6xx-R7xx chipsets) almost on par with the support for the Radeon X1000 series (R5xx chipsets). I say almost because a few of the minor blitter acceleration functions,and DVI and VBlank interrupts are are still to do. As always, there is more work to do. Nevertheless, a composited Workbench performs well with these cards.

So, what's next? Well, apart from the aforementioned DVI and interrupt support, I am eager to get 3D drivers up and running. DVI is something that I'd like to get working soon as I use a 4 port DVI KVM, and so would like to be able to stop switching to VGA.

RadeonHD: Mobility Chipsets now Supported

Mon, 28 Feb 2011 15:16:35 +0000

With the Sam460ex recently going on sale and including the RadeonHD driver, the driver has inevitably been tested on a wider range of hardware. While most hardware is working just fine, two people with a Sapphire Radeon HD 4350 reported (see here and here) that it didn't work with their cards. Most of their screens were filled with garbage. This surprised me as all Radeon HD 4350s tested previously worked just fine. So, suppressing my desire to grumble about people ignoring my recommendations (hey, it wouldn't have happened if you had got a Radeon HD 4650/4670 like I suggested ;-) ), I got to work tracking down the problem.

A quick look at the offending card's PCI product ID revealed that it was actually a Mobility Radeon M92 chipset on the board, and not an RV710, which is what Radeon HD 4350s should have. This explained why all Radeon HD 4350s tested to date worked just fine, while these failed miserably. While this was a clear differentiating factor, it did not explain why it failed.

These cards highlighted two problems, not one. First, there was the obvious problem of the cards not working. However, the driver should have detected the problem, and disabled hardware graphics acceleration, so that the display was readable at least. The cause of both problems lay in the GPU initialisation code. This code checks which chipset the card has, and then uploads the correct microcode and executes the appropriate initialisation. As it turns out, some chipsets - most notably all of the mobility chipsets - were missing, and so no microcode or initialisation was done. A small bug prevented this failure from being detected, and so hardware acceleration was not disabled.

The good news is that I have fixed these issues, and future versions will be able to use these cards. In the mean-time, I strongly encourage people to not buy Sapphire Radeon HD 4350 cards, as some of them will not work with the publicly released driver. Likewise, I discovered that the current driver will not initialise RV740 and RV790 chipsets, so avoid the Radeon HD 4770 and 4890 cards too. I do not expect people to buy these cards for their Sam460ex's, as they will block the PCI port. Nevertheless, you have been warned.

Radeon HD 2000-4000 Series 2D Hardware Acceleration

Thu, 23 Dec 2010 15:41:15 +0000

It has been almost a year since I last posted an update to this driver development log. This was never intended, and my apologies to anyone who was hoping for more regular updates. Things have been rather hectic, and I had decided early on to only post updates when there is something concrete to show. Updates about how many lines of code have been written are boring. That's not to say that there have not been any milestones reached along the way; just that they have been "internal" milestones, which are less interesting to users. Anyway, an update is long overdue, so here it is.

I am pleased to announce another major milestone has been reached. 2D blitter acceleration is now operational on R600/R700 chipsets (Radeon HD 2000-4000 series cards). A few 2D blitter functions are still to-do, but the most critical functions have been implemented, and R600/R700 cards are now finally usable (albeit minus compositing). In fact, my primary Amiga OS development system is now a Sam 460ex with a Sapphire Radeon HD 4650 Ultimate Edition (passively cooled, which is nice), with the old A1-XE now only used for additional testing, and the odd 3D stuff. I'll write more about the new system later; what is key here is that the R600/R700 driver has reached a stage that I now use it every day, rather than only for testing.

There is more good news. Many have asked if the driver will be on the Sam460ex AmigaOS 4.1 CD, and the answer is yes. I have reached an agreement with ACube Systems, and the driver will be included. Having used a Sam 460ex with a Radeon HD 4650, I can say that it is definitely a step up from my A1-XE. Having a real PCI-Express bus (4x) instead of using a PCI version definitely makes a difference. With both the Sam 460ex, and the upcoming A1-X1000, I am quite excited about 2011, and the possibilities that all this new hardware brings. I am eager to help bring 3D support to the new Radeon HD cards, which will be a giant leap forward in graphics capabilities.

The Long Road to Here

Getting R600/R700 acceleration up and running proved to be more effort than I had anticipated (surprise, surprise). Unlike the R500 and previous chipsets, its command processor has no "push" mode, in which commands can be sent by writing to a set of registers. The command processor is responsible for executing rendering commands sent to it by the CPU. To make matters worse, the command processor registers are missing from the documentation, so the code that AMD released (see the Linux drivers), was the documentation. So, with only source-code for documentation, I had to implement "pull" mode command submission. In "pull" mode, the CPU writes commands to a ring-buffer in memory, and then tells the GPU's command processor that there are more command packets to read. The command processor then reads the commands in directly from that memory. To avoid individual Tasks (or Threads/Processes) from blocking each other, Tasks generally do not write to the ring-buffer directly, but to indirect buffers. The driver writes an entry to the ring-buffer telling the GPU to execute the submitted buffer, which the GPU once again reads directly from memory. Using GART, it can read the commands directly from main memory which, thanks to it using DMA, is faster than individual CPU writes.

The down side to "pull" mode is that it requires a lot more support code. It isn't just the ring-buffer code, there is also the indirect buffer management code, and then the 2D blitter acceleration running on top of that. To save time later, the R600/R700 command processor code has been implemented directly into the RadeonHD_RM.resource, which the 3D drivers (and anything else that needs it) will use. Internally, the 2D blitter acceleration also uses the RadeonHD_RM.resource to access the GPU. I will write more about the resource and technical details at a later date.

Rather than try to implement GART and the command processor code at the same time, I opted to put the ring buffer and indirect buffers in VRAM on the graphics card. Performing one step at a time is good Engineering practise, and helps isolate problems. For example, if there were a problem, was it caused by the GART code? The ring-buffer code? Or even both? It turned out that putting the command buffers in VRAM brought its own problems related to data coherency. In some cases the data had not made it to VRAM before the command processor tried to read it. This was just one of the many technical issues that got in the way and were overcome.

Possibly the biggest technical problem that I encountered was a direct result of using PCI versions of what is actually a PCI-Express graphics card. To get it connected to a PCI bus, manufacturers put a PCI-to-PCIe bridge on the board (a PEX 8111 or 8112, to be precise). The performance of the PCI cards was on the slow side. When I benchmarked the CPU's VRAM write and read speed, I got a shocking 0.7 MiB/s! Since not everything is HW accelerated, this read speed really hurts. Fortunately, there was a solution. The PEX 8111 and 8112 bridge chips have a "blind" prefetch feature, that allows the bridge to prefetch blocks of data, thereby decreasing the large latencies of individual reads from the PCI side of the bridge. Setting those up correctly helped boost the read speed back into an acceptable range. I have also made some changes to Picasso96 that improve performance. Having said that, I do hope that the A1's UBoot will be updated so that the Radeon HD card can be used in the 66 MHz slot rather than the 33 MHz slot. Any increase in bandwidth to the graphics card will help; particularly with R600+ cards, as their command packet sequences are longer for 2D acceleration than previous Radeon cards.

The Road Ahead

I am sure that many are asking, "what's next?" Well, in no particular order, here are some of the things still to come:

DVI output on Radeon HD 4000 series cards (it partially works, but it is still to do)

Support for R600/R700 VBlank interrupts

R600/R700 compositing (and HW acceleration of the last few blitter functions)

3D drivers using Gallium 3D (requires finishing off the RadeonHD_RM.resource)

It has already been mentioned that Gallium 3D drivers for these cards will be coming, and I am looking forward to getting those up and running. This is no longer only a 2D driver project.

I wish you all a Merry Christmas, and a Happy New Year.

R5xx Compositing is Done

Mon, 28 Dec 2009 00:00:00 +0000

I am pleased to announce that compositing for R5xx based cards (Radeon X1000 series) is now done. This marks a major milestone in the development of the RadeonHD.chip driver. Namely, full 2D graphics acceleration is implemented for an entire series of graphics cards. The screenshot below shows Workbench with compositing effects enabled being displayed by a Radeon X1550 graphics card. As you can see, the errors that were present in the previous screenshot are now gone (the development log entry containing the previous screenshot is included in the image below for comparison).

Implementing compositing proved to be a major undertaking. As I said earlier, Amiga OS 4.x's compositing contains a powerful array of features, all of which must be implemented correctly by the driver. Added to this, a slight eror in the data sent to the graphics card could cause a freeze, requiring a hard reset. This makes debugging rather time consuming. Needless to say, I am glad that it is done, and working correctly.

With full 2D acceleration implemented for R5xx chipsets, it is now time to turn my attention to hardware accelerated blitter for R6xx/R7xx based cards.

R5xx Compositing - Partially Done

Sun, 06 Dec 2009 00:00:00 +0000

It has been a while since I posted an update about this RadeonHD driver for Amiga OS 4.x project. At present I am still working on implementing compositing for R5xx chipsets (Radeon X1000 series cards) but, there is progress. The screenshot shown below (and the thumbnail image to the left) was captured from a Radeon X1550 PCI card when running Amiga OS 4.1 with compositing enabled. As you can see, basic compositing is operational.

Compositing support is still incomplete, however, and some errors are visible in the screenshot. The drop shadows and window transparencies are not working yet. and there are several use cases that are not fully operational. Nevertheless, the hardest task of getting anything working at all has been done.

Compositing on Amiga OS 4.1 is considerably more powerful than that which is available on Linux via EXA. While this is great for application developers, it places more burden on the graphics driver developer. This is why there have been few updates to this development log over the last few months. I cannot say how much longer it will be until R5xx compositing is fully implemented, but it is mostly done.

Radeon HD Cards Now Work with the SAM 440ep Motherboard

Fri, 27 Nov 2009 00:00:00 +0000

This morning ACube Systems released UBoot updates for their SAM 440ep and SAM 440-flex motherboards. These updates include fixes that allow Radeon X1000 series and higher (e.g., Radeon HD 2400) cards to work with the SAM 440ep. Previously, the SAM 440ep's UBoot failed to detect the card properly, meaning that SAM 440ep owners could not use the RadeonHD graphics card driver for Amiga OS 4.x that I am developing.

The problem with the SAM 440ep board was that the Radeon HD PCI cards are actually PCI-Express graphics cards with a buiilt-in PCI-Express-to-PCI bridge. As a result, the card appears as a device behind a bridge to the system. This is the same issue that seems to be preventing Pegasos II users from using the same graphics cards on their system.

With this UBoot update, a large number of Amiga OS 4.x users are now able to use more modern graphics cards. All that remains to be done, is for me to finish the drivers...