Graphics corruption

[trevordick]

OK sorry, I'm referring to the latest beta RadeonHD drivers which appear to remove the graphics corruption problem seen on your card.

Trevor

[xenic]

OK sorry, I'm referring to the latest beta RadeonHD drivers which appear to remove the graphics corruption problem seen on your card.
Trevor

I'll wait and see if the new RadeonHD driver helps when it's released to the public. However, my recent tests seem to indicate that the problem goes deeper than a graphics card or driver. I removed the Radeon 9250 graphics card from my SAM Flex and tested it in my X1000. I get the exact same graphics corruption with the Radeon 9250 as I do with the Radeon 5450. When I replaced the Radeon 9250 in my SAM Flex there is no graphics corruption. Here is a list of the graphics corruption that occurs with both the Radeon 9250 and Radeon 5450:

1. The OS4 Dopus4 config window has small vertical bars in some of the checkmark gadgets in 8 and 16 bit screenmodes. The corruption doesn't seem to occur in 32 bit screenmodes.

2 In the Amiga Early Startup Control "Boot Options" window the Up and Down arrows at the bottom right of the "Select Boot Device" lister are missing and replaced with plain gray or black background.

3. Moving the pointer horizontally on the PPaint drawing area produces small lines of various colors. There should be nothing showing in the drawing area unless the left mouse button is pressed while moving the pointer. EDIT: I've discovered that lowering the available colors from 256 to 128 elimintates the corruption and and is a viable workaround for PPaint.

4. The main SuperJam window is extremely corrupted when the program is run on an 8 bit screen. The corruption doesn't seem to occur when I use the "Screens" utility to force SuperJam to open on a 16 bit screen.

5. The OS4 BarsnPipes window and toolbar are corrupted when opened on an 8 bit screen.

6. Warpview (OS4Depot) displays corrupted images on 16 bit screens when run with "software" display. Several users have confirmed my results and also that Warpview displays images properly in 16 bit screens on SAM Flex and SAM 460 with Radeon 4650 graphics card.

I've seen other minor corruption in some old programs but didn't write them down. I'll add them to my list if I notice them again.

None of the above corruption occurs with the Radeon 9250 on my SAM Flex. That leads me to believe that the problem might be bugs in the X1000 system software or a flaw in the X1000 hardware. I'm somewhat disappointed that only one person has actually tested as I requested so I can determine if the graphics issues are only occurring in some X1000 systems or all of them. I hope AmigaKit has spare X1000 motherboards because I'd rather not wait another year to get my X1000 fixed if the new RadeonHD driver doesn't solve my problem.

Since I can use SGrab to grab the corrupted screens or windows, I would suspect that the corruption is occurring before the images are processed and displayed by the graphics cards. I don't know how the OS4 display works so my suspicion may easily be wrong.

[cha05e90]

It might still be a software problem, because our X1000s are still *not* on par with the non-beta systems. While my Pegasos II and Sam440ep feature a full Update 6 + following, the X1000 still has some older OS components here and there (somewhere in between Update 5 and 6).

[xenic]

@cha05e90
True, there may be something different about the X1000 that will require some special software changes to get the graphics output right. Since the my Radeon 9250 has the same problem on my X1000, I won't need to waste money on a new graphics card.

[xenic]

@cha05e90

I've been able to confirm graphics issues with WarpView. WarpView is available on OS4Depot and there is a free keyfile recently added to OS4Depot. Warp3D doesn't appear to work yet on X1000 so you need to run it in "Software" mode. On the X1000 (in software mode) Warpview displays corrupted pictures when opened on 16 bit screens. It works properly on 16 bit screens (in software mode) on my SAM Flex. Several other users have confirmed my results and Warpview also works for them on SAM Flex with Radeon 9250. One user confirmed that WarpView works on SAM460 with Radeon 4650. So far Warpview doesn't work properly with 16 bit screens on any on any tested graphics cards on X1000.

[xenic]

OK sorry, I'm referring to the latest beta RadeonHD drivers which appear to remove the graphics corruption problem seen on your card.
Trevor

Unfortunately, no beta testers have posted test results to confirm that the above listed problems are solved with the beta RadeonHD driver. I'll mark this topic solved if they do report that above listed problems are resolved.

[Hans]

@xenic

For PersonalPaint, one workaround is to do the following:
- Enable "fakenativemodes" in ScreenMode Prefs. It's on the "monitors" tab. You can also enable it by editing the monitor tooltypes for your graphics card in DEVS:Monitors/
- In GUI prefs => Controls, enable "Planar screens on RTG"
- Use one of the fakenative modes for PersonalPaint.

I think that the problem is programs like PersonalPaint doing non-aligned accesses to VRAM. That would explain why it only happens on 8-bit/16-bit screens, as all pixels are 32-bit aligned on 32-bit screens.

Strange things can happen with transfers across PCIe buses if you're not careful, and the PA6T chip doesn't like non-aligned accesses across the PCIe bus (AFAICT). IIRC, this is what caused the A1-X1000 specific window drop-shadow graphics corruption back before the rtg.library's RAM<=>VRAM transfer routines were overhauled. This is one of the reasons why I recommend that developers use ReadPixelArray(), modify in RAM, and then WritePixelArray() for CPU-based rendering instead of locking bitmaps and writing to them directly.

I've asked beta testers to be on the lookout for any cases where OS components are at fault. While we can fix any OS components, any application developer that uses p96LockBitMap() to access bitmaps directly, will have to fix their own code. As a bonus, aligned accesses to VRAM are faster.**

Hans



** NOTE: I strongly recommend using ReadPixelArray()/WritePixelArray() instead of writing your own transfer routines. ReadPixelArray()/WritePixelArray() are optimised for each machine, and use DMA where available (currently on Sam4x0 machines, but that will likely be expanded to more hardware in future).

[xenic]

@Hans
Thanks for the workaround for PersonalPaint. I would prefer to use it at a higher resolution but it works. Since my original post I discovered that FInalWriter and FinalCalc also display some graphics corruption in 8 bit screenmodes. I wondered why nobody was seeing graphics corruption in programs run with UAE emulation but discovered that UAE is emulating old screenmodes of a 16 bit screen.

The main reason I think that the graphics corruption is being caused by something other than your drivers is the fact that there IS NO graphics corruption in 8 bit screenmodes when my 9250 graphics card is installed in my SAM Flex but there IS graphics corruption in 8 bit screenmodes when my 9250 graphics card is installed in my X1000.

The graphics corruption I experience in 8 bit screenmodes is almost always in gadgets, not the window background or window borders. If you would like some screen grabs showing the corruption just post an email address here or PM me with an email address and I will attach some grabs to an email and send them to you.

[Hans]

The main reason I think that the graphics corruption is being caused by something other than your drivers is the fact that there IS NO graphics corruption in 8 bit screenmodes when my 9250 graphics card is installed in my SAM Flex but there IS graphics corruption in 8 bit screenmodes when my 9250 graphics card is installed in my X1000.

Agreed, it isn't a driver issue. Like I said, care needs to be taken when transferring data across PCI/PCIe buses. In particular, non-aligned accesses are risky, will likely be slow even on hardware that can handle it.

The graphics corruption I experience in 8 bit screenmodes is almost always in gadgets, not the window background or window borders. If you would like some screen grabs showing the corruption just post an email address here or PM me with an email address and I will attach some grabs to an email and send them to you.

I'll skip the screen grabs for now. Instead, just continue to post which programs have corruption in 8-/16-bit modes, with details such as which gadgets are affected. Beta testers should be able to confirm issues, and create bug reports for anything that is caused by OS components.

Hans