blog

The RadeonHD_RM.resource

Mon, 24 Oct 2011 23:00:00 -0500

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 -0500

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 -0500

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 -0600

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 -0600

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 -0600

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 -0600

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 -0600

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...

RadeonHD.chip Supports Obtaining Modes Via DDC

Sun, 27 Sep 2009 00:00:00 -0500

A few days ago it was announced at Pianeta Amiga 2009 in Empoli, Italy, that Amiga OS 4.x will soon support obtaining monitor resolutions automatically via the Display Data Channel (DDC) (see this report on the show). Now that this has been made public, I can announce that the RadeonHD.chip driver has DDC support too. In fact, it has been supported since February of this year.

DDC support is a large step forward when it comes to setting up a monitor. It is a separate data channel that allows graphics cards to get information about the connected monitor's capabilities, and then build a list of supported resolutions automatically. Previously the user had to manually enter the monitor timing limits into the monitor icon's tooltypes, and also manually add the desired screenmodes (although the basic modes are automatically generated on OS installation). With the arrival of DVI monitors with their reduced-blanking modes, this situation was complicated further. With DDC support, no more manual entry is required, making setting up monitors much easier and more user-friendly. If a monitor is replaced with a new one, new modes will automatically be added to the list on start up.

A Moving Target - AMD Releases the Radeon HD 5800 Series

Wed, 23 Sep 2009 00:00:00 -0500

I had hoped that AMD would hold off with producing a new generation graphics card but, a few days ago, they released two new cards, the Radeon HD 5850 and 5870. This is based on the next generation RV880 chipset. The Radeon HD 4000 series was based on R7xx chipsets. The 5800 series of cards pushes graphics performance and computational possibilites yet another step forward. AMD have listed OpenCL support as coming in 2010 (for platforms that they write drivers for themselves), which is good news for people like me who do non-3D computationally intensive work.

So, how does this affect the RadeonHD.chip driver for Amiga OS 4.x? Right now, it just means that the newest card that I have - a Radeon HD 4350 - is one generation behind the newest cards. There is no PCI version of any of the Radeon HD 5800, so there is no possibility of me working on support for now. If there were, the AtomBIOS should ensure that the mode-setting would work. I have yet to find out how different the RV880 is from previous chipsets, but I hope that the changes are incremental rather than a radically new design. The R6xx chipset was dramatically different from any of the previous chipsets, whilst the R7xx series was a more incremental improvement. If the RV880 is an incremental improvement, then implementing hardware acceleration for these cards will be relatively easy.

This latest development does make the Radeon X1000 series of cards seem less important. Given that Amiga OS 4.x users will have to buy new cards when the RadeonHD.chip driver is released, most will be buying one of the newer generation cards. Nevertheless, I will be completing compositing support for R5xx chipsets (as soon as possible) before moving on to the newer cards.

RadeonHD.chip - Radeon HD 4350 PCI VGA Output is Working

Fri, 21 Aug 2009 00:00:00 -0500

After days of persistent effort, the VGA output on Radeon HD 4350 that eXec magazine donated to me is finally working on Amiga OS 4.x. This is the first time that a current generation graphics card is working on Amiga OS 4.x. Granted, there is no hardware acceleration yet, but the start is there. The problem was small, but very hard to find. To give people an idea of how frustrating driver development can be, here is the whole saga.

Finding a needle in a Haystack

Everything started when I received the HIS Radeon HD 4350 PCI card in a nice shiny box. Given that the AtomBIOS is supposed to enable initialization of any card regardless of type, I was hopeful that I would get an image immediately. After plugging in the card and starting the driver, the card was recognized, but the monitor gave a "no signal" message. The DVI output also failed to work, but the debug log indicated that the driver did not know how to handle the new output type. Rather disappointing.

With progressively more debug output enabled, the long and arduoud task of debugging began. Eventually I noticed that the SetPixelClock AtomBIOS call was disabling the output, and the driver was calling this after enabling the output; one bug fixed, but still nothing.

Digging deeper, I discovered that SetPixelClock was overwriting parameters before using them. This turned out to be a n endianness bug in the AtomBIOS interpreter (lesson, C bitfields can be problematic). With this bug fixed, the monitor finally indicated that it had a signal with the right resolution, but the display was black.

After many more hours of trying to track down the issue, I fired off an email to AMD's Open GPU email address that explained my problem, and asking what order the AtomBIOS calls should be made in; maybe there was a similar issue to SetPixelClock disabliing the output. The response from AMD was surprisingly fast; within a day I had the call order, and debugging proceeded. Eventually I noticed that the screen was still blanked; I could change the screen colour by changing the blanking colour.

At this point I was running out of ideas. So I decided to plug in my Radeon 2400 pro card and record register settings. Hopefully the framevuffer registers were similar enough that I could compare the registers and look for anomalies. To my horror, I was greeted with a black screen. After looking back at previous revisions, I eventually found out that I had introduced a bug over the course of trying to get the new card running. This bug left the first output in a blanked state.

With the blanking bug fixed, the Radeon HD 4350 was reinserted, and, produced a black screen. This time the blanking was not to blame. I decided that it was time to test the card out on a PC, and perform a register dump for comparison. So, the card was inserted into a machine and the Windows drivers were installed. Unfortunately the register dump tool (hws_script) refused to work on Windows. Next a Mythbuntu CD was inserted, the fglrx driver (i.e., AMD's driver) was installed and a register dump made. This register dump turned out to be bogus due to the radeon_dump tool not recognizing the card, and dumping the zero page. After fixing radeon_dump, a real register dump was made. Comparing this to a register dump from the RadeonHD.chip driver showed nothing wrong.

By this stage many days had passed, and most possibilities had already been tried. Using the AtomBIOS disassembler and poring over the code drew a blank. I wrote a small tool that would allow me to copy portions of the fglrx register dump into the card's registers; perhaps I had missed something, and this would show me which registers were wrong. This was a bit dangerous, since one shouldn't be poking values into registers without knowing what they do, but I could think of nothing else to try. Still nothing. Copying the fglrx register values - almost all of them - into the graphics card's registers still resulted in a synced but black screen.

Clearly the final register values were correct, but there was still something preventing the card from working. I suspected that the memory controller was frozen somehow, but how should this be solved? Well, this morning I remembered an issue with a different card freezing, which was related to the memory controller initialization, and that the AtomBIOS' ASICInit call also initialized the memory controller, I modified the driver to disable the VGA output, and wait for the memory controller to be idle before executing ASIC Init. A recompile later, and I was greeted with the screen-mode test image. Finally.

This bug also exists in the open source Linux drivers, so I have sent an email to the Linux driver developers to let them know about this issue. That way they won't have to spend so many frustrating hours tracking it down. It's always nice to be able to contribute back to the open-source project that has helped me get this far.

Thank You Once Again to eXec Magazine and All Those Who Donated

Once again a big thank you to the eXec magazine and all those generous people who have donated to this project. Thanks to these donations it is now possible to use the Radeon 4350 with Amiga OS, albeit minus hardware accelation at present. Tracking down the bug has been time consuming and frustrating, but it has improved the driver, and paves the way for using the latest generation Radeon HD cards.

Where to Now?

Now that the VGA output on this card works, I am gooing to return to adding compositing support for R500 based cards. DVI output for the Radeon HD 4350 can wait. After that, work on hardware acceleration for R600+ cards will begin. Those with an eye for detail may notice a change for R600+ cards in the screen-shots above (hint, look at screen shots in previous entries to this development log).

RadeonHD - Status Update and Thank You for Your Generosity

Mon, 17 Aug 2009 00:00:00 -0500

I would like to thank everyone who have donated generously to the RadeonHD driver for Amiga OS 4.x project over the last few weeks. All donations small and large were most appreciated, and shows the level of interest in this project. Some people even donated over $100 NZ ($50). Rest assured that I will work hard (time permitting) toward developing a releasable driver. A special thank you to the eXec magazine in Poland for their donation of a Radeon HD 4350 PCI card, and for their campaign to support this project.

The Current Status

Thanks to eXec, I now have a Radeon HD 4350 PCI card. I had hoped to have it up and running before posting a status update, but this is proving to be more difficult than anticipated. I had expected that the DVI output would require changes to the driver since the hardware and AtomBIOS calls have changed significantly. However, the VGA output also does not work. I have made some progress, though. The VGA output does output a signal, but the screen remains blanked. A very subtle endianness bug (stupid C bitfields) was also exposed by this card, and has been fixed. What remains to do is to discover why the screen remains blanked. DVI output for this card will be added later, most likely after compositing for R500 series chipsets has been completed.

Several people have taken on the role of beta testers, and have been providing me with valuable bug reports. Thus, development over the last several weeks has focused primarily on tracking down and fixing the various bugs. All major show-stoppers have been fixed (although I'm still waiting for confirmation of this regarding one particular card), and a compatibility list will be posted on this website in the near future. This will list both which motherboards can use these cards, and which cards have been tested.

Pegasos II owners are still out of luck. I have tried contacting Genesi regarding Openfirmware failing to cope with the on-board PCI-to-PCI bridge, but have had zero response. Micro-Amigaone users cannot use a second graphics card, and will therefore be unable to use these cards. I am still hopeful that ACube will fix the UBoot issue with the SAM 440 ep (the flex variant works fine).

With the major issues that beta testers experienced being fixed, focus can once again shift to compositing for R500 series chipsets. I will also be working on getting VGA output from the Radeon HD 4350 card, although that may be put aside temporarily if it takes too long.

RadeonHD - A Call for Beta Testers

Sat, 30 May 2009 00:00:00 -0500

The driver has progressed to the stage at which it is ready for testing by a wider group of users. Amiga OS 4.x beta testers have already had access to an early beta. However, very few people have RadeonHD graphics cards, and more testers are needed. To that end, I am accepting applications to beta test the RadeonHD.chip driver.

Some may wonder why a public beta is not being released. The simple truth is that a public beta will be greeted with an expectation that it should just work. Given that it has only been tested with a few cards so far, these expectations are wholly unrealistic. By requiring people to apply, those testing are conscious of the fact that the software being tested is a work in progress. A public beta may be released later, when the driver s more mature.

People who have the right hardware and are interested in beta testing the driver, can register their interest here.

R5xx Compositing or R6xx Blitter Acceleration Poll Closed

Fri, 15 May 2009 00:00:00 -0500

The poll that was run asking for input as to what should be developed next has now been closed. 151 votes were cast, of which 85 (56%) were for R5xx compositing and 66 (44%) were for R6xx blitter hardware acceleration. Given these results, R5xx compositing will be developed next.

This does surprise me a little, as I had expected the majority to want the best cards possible supported. My reasoning was that almost everyone would be buying one of these cards, since very few will have PCI Radeon HD (or X1000 series) cards lying around. Nevertheless, the smallish majority would like to see 2D support for one set of cards to be finished off fully. Whilst some would argue that the compositing is only used for eye candy; in future, I expect more software to take advantage of the alpha blending capabilities that compositing offers.

I would like to thank all those who took the time to vote. 151 voters shows that there is interest in this driver project. The next time that I create a poll, I will add a "don't know/don't care" so that those who are sitting on the fence can also vote.

RadeonHD - Help Decide What is Developed Next

Sat, 02 May 2009 00:00:00 -0500

This is just a quick post to the RadeonHD development log in order to point people to the poll regarding what should be developed next. Basically the choice is between finishing off 2D support for R5xx based cards (i.e., Radeon X1000 series) in the form of hardware compositing, or starting on 2D blitter support for R6xx based cards (i.e., Radeon HD 2000 and 3000 series). This is your chance to have a direct input on what happens next. Please note that R5xx chipset compositing will be completed eventually regardless of which option is chosen; the results of the poll will change what order things are implemented.

The advantage of continuing with R5xx chipsets, is that implementing compositing would take less time than starting on hardware acceleration for the R6xx chipsets. It would also mean that one set of graphics cards is fully supported. On the other hand, this would mean that users of R6xx based cards would have to wait even longer. Also, AMD have recently dropped support for R5xx based cards from their drivers, indicating that they already see them as obsolete.

While the poll is active, work will be performed on implementing uploading of the command processor microcode, to the graphics card. This is required by all chipsets. R5xx chipsets require the command processor's microcode for 3D operations, whilst R6xx chipsets require the microcode for all GPU operations.

EDIT (2009/05/16): This poll is now closed. Thank you to the 151 voters for participating. Hardware compositing for R5xx chipsets will be developed next based on a majority vote.

2D Blitter Acceleration for R5xx Chipsets is Done

Fri, 01 May 2009 00:00:00 -0500

Hardware acceleration of 2D blitter operations for R5xx chipsets (Radeon X1000 series cards) was completed last with the exception of blitting patterns. This is another milestone in the development of the RadeonHD for Amiga OS 4.x graphics driver. Blitting patterns was left out because it is a less frequently used operation that cannot be performed efficiently by the R5xx's 2D acceleration hardware. Instead, it would require using the R5xx's 3D capabilities. This will be added later, after hardware compositing is added (which also uses the 3D capabilities).

The performance of the 2D hardware-accelerated blitter can be seen in the following table:

Operation	Radeon 9000 (operations/s)	Radeon X1550 no hardware acceleration (operations/s)	Radeon X1550 with hardware acceleration (operations/s)
RectFill()	3567	58	4477
RectFill() pattern	174	53	59
WritePixel()	404601	428043	82235
WriteChunkyPixels()	4026	1192	1201
WritePixelArray8()	4027	1196	1206
WritePixelLine8()	179666	123706	55925
DrawEllipse()	79010	22213	18371
DrawCircle()	83256	23857	19450
Draw()	11142	2848	28989
Draw() Hor/Ver	63881	7395	30679
ScrollRaster() X	191	1	265
ScrollRaster() Y	185	1	264
PutText()	38518	9167	26192
BltBitMap()	32704	33	20615
BltBitMapRastPort()	32137	33	20245
BltMapScale()	884	11	304

These results were obtained using P96Speed. All tests were performed using a 1920x1080 RGBA screen. The Radeon X1550 tests were performed with the Radeon X1550 as secondary graphics card, so it is possible that the Radeon 9000 was still involved in some of the operations.

Some operations were performed faster by the Radeon X1550, others were faster on the Radeon 9000. Confusingly, there are some operations (e.g., WritePixel()) which were faster on the Radeon X1550 without hardware acceleration. My suspicions are that these operations are still rendered by the CPU, and the bitmap was in main memory during these operations for the non hardware accelerated version; that way, the slow 33 MHz PCI bus would not be the bottleneck.

The speed of operation depends on the speed of the bus to the graphics card as well as the speed of the GPU performing the operation, and how big an area is covered by the operation. In the tests above, a faster card that is constrained by a 33 MHz PCI bus (I can't use the faster 66 PCI MHz slot simultaneously with the AGP slot) is compared to a slower card on a bus with four times the theoretical upload speed (via a 2xs AGP port). This is probably why some operations are faster on the Radeon X1550 while others are faster on the older Radeon 9000 pro. For example, RectFill() fills both large and small rectangles, and the Radeon X1550 comes out on top. BltBitMap(), on the other hand, blits small uniformly sized squares, meaning that the time taken to upload the commands is much more significant when compared to the time taken by the GPU to perform the operation.

What is clear from the above results, is the huge difference that hardware accelerated blitter makes. It transforms the graphics from being slow and sluggish, to being fast and responsive. There is also a possibility that the speed could be improved further later, since the commands are currently transferred in PIO mode, instead of using DMA.

Hardware Accelerated Solid Rectangles for R5xx Based Cards

Mon, 06 Apr 2009 00:00:00 -0500

Solid rectangles are now rendered by the graphics card, instead of by the CPU. This is the first hardware accelerated operation implemented in the RadeonHD driver (for Amiga OS 4.x). The increase in speed can be seen in benchmarks made using the P96Speed utility (specifically, the RectFill() benchmark):

RectFill() Speed Benchmark

Graphics Card	Operations/second
Radeon 9000 pro AGP	3567
Radeon X1550 PCI (unaccelerated)	34
Radeon X1550 PCI	4479

That's a speed increase of almost 132 times. The performance of my Radeon 9000 card is provided for reference, and it is clear which GPU has more power; the Radeon X1550 beats the Radeon 9000 at this task by 26%. These benchmarks were performed using an AmigaOne-XE at 933 MHz, and the screen resolution was set to 1920x1080 at 60 Hz in all cases.

Please note that this acceleration is for R5xx chipsets only (i.e., Radeon X1000 series cards). The R5xx chipset differs significantly from the newer R6xx (Radeon HD 2000 and 3000 series) and R7xx (Radeon HD 4000 series) chipsets. Thus, acceleration for newer chipsets will come later. In the meantime, work will progress on 2D acceleration for the R5xx series. Now that the groundwork has been laid, implementing the remaining blitter operations should take less time.

Big-Endian Display Modes for R5xx Cards

Sat, 04 Apr 2009 00:00:00 -0500

Hardware acceleration for R5xx cards is still a work in progress. In the meantime I have discovered how to switch the card to performing byte-swapping in order to convert from big-endian to little-endian modes for R5xx cards (Radeon X1000 series). Previously, all modes were simply defined as being little-endian, thus byte-swapping had to be performed in software by Picasso96. This is now handled automatically by the R5xx chipset.

As yet, I do not have the details for performing the same task on R6xx series cards (Radeon HD 2000 and 3000 series). Hopefully this will change at some point. However, the graphics cards can operate fine without automated byte-swapping.

Updates and Installers

Sun, 15 Mar 2009 00:00:00 -0500

It has been several weeks since I posted an update on this project. Right now hardware accelerated blitter is still a work in progress. In the meantime I have written an installer and AmiUpdate script for the driver. I personally dislike software that requires manual installation, and so took the time to write the necessary scripts for installation and updates. This was done now rather than later since I knew that it would take some time to write an installer (which is something that I had not done before), and it would have been very tempting to skip it if the driver were ready for release, and no installer was written. Along with the installer and update script, a "build-release" script has also been written. Thus, making a release now simply requires running a single script.

I am sure that readers are now wondering if they will see a release soon. Not yet. I do plan to release a public beta at some stage, but not before hardware accelerated blitter is working.

Hardware Accelerated Mouse Pointer (a.k.a. Sprite)

Sun, 08 Feb 2009 15:19:31 -0600

The mouse pointer now uses the Radeon card's sprite hardware. The graphics card documentation calls it "Cursor," which matches the X-windows terminology. This was a fairly straightforward task, with just a few issues such as ARGB vs. RGBA pixel formats, and alpha-channel blending modes.

Previously Picasso96 (Amiga OS 4.x's retargetable graphics system) used a "soft-sprite," which is another way of saying that it had to render the mouse pointer over the top of the main image itself. Moving a hardware sprite, on the other hand only requires telling the hardware where to put it; compositing is handled by the graphics card.

Now that the mouse pointer is hardware accelerated, my eyes are firmly set upon hardware accelerated BLock Image Transfer (BLIT) operations, a.k.a. blitter operations. At this point the code will become chipset specific, since the command processors that handles any rendering operations is unique to each chipset series (i.e., R5xx chipsets work differently from the R6xx series). Up to now, the AtomBIOS hid most of the differences between chipsets, but this is for framebuffer operations only. The sprite hardware is also common between the chipsets.