@Spectre660

Ok, Then I'm going to try it in a sam440.

It's going to be a Frankenstein machine but that is how all amigas end up eventually

pci -> PCIe x1 slot -> PCIe adapter -> usb3 cable -> PCIe x16 slot+power inserter -> rx550

@Spectre660 @Helloworld

That card works in a sam460cr with hardware video decoding?

Is there an external molex power connector?

@kas1e

I have been able to reproduce the issue with my sam440 flex + PCI->PCIe adapter. Turned out to be a cache handling difference between the e5500 and ppc440. The issue has been solved and the next version of the driver should also work on a sam460.


To those with a sam440: I've used this adapter to make a hd audio card work in my sam440 flex.

@amig_os

Can you ensure that if I do as you suggest that all my issues with the RadeonRX disappear?

@Spectre660

My installions is basically clean. It exist since januari of this year.

FE Upd 1 -> enhancer 1.5 -> update 2 -> hotfix -> Enhancer 2.0

As Hans suggested, I've replaced my power supply with a new 750W PSU (Corsair RM750 ; 80 plus gold). And I have replaced my memory with a new set of 2x4GB 1600MT/s dimms (Corsair vengeance).

But as expected, this made no difference.

The three issues remain:
1. Warm reset will always result in a cache cohency message and a system halt.- > Annoying but apparently normal behaviour

2. Playing movies, even the ones that were used with testing the driver, result in a random crash of the GFX driver. I have seen four different debug outputs so far for the same movie.

3. 3440x1440 simply doesn't work reliable. Switching to another screenmode will result in no output signal. Manual screenmodes with 3440x1440 doesn't work at all. No matter the update rate.

At this point I will not spend more money on an RX solution. For now I'll stay with my R9 270X and might give it another try when a solution is found or the RX570 and above cards are fully supported.

@m3x

Debug version in PM.

@m3x

Unfortunately I have no sam460 to test this myself.

But I will send you a version with debug output tomorrow (monday) morning through amigans.net pm.

Maybe I can try reproduce it with a pci to pcie bridge on my sam440. But I don't have one either so this takes a while.

@geennaam

Another quote from MantisBT thread about the RadeonRX UVD crash issue:

NOTE: Soft-resets usually don't work with Polaris cards. Only a hard-reset does.

Didn't know that until now. So that should explain the issue with monitor prefs/soft reset versus the cache coherency message and system halt.

The UVD crash seems related to GART/DMA.

So only the screenmode change from 3440x1440@60Hz to something else issue remains unexplained. That issue will result in a permanent loss of signal and system freeze. No matter if this is done by a program or if I just use the test button in the ScreenMode pref. Cycling through screens doesn't work either to bring back workbench.

@kas1e

Well done!! Thanks for the Video.

I'll look into the sound prefs issue if I can reproduce that. I normally use the individual speaker buttons in order to test each individual channel.
But I did notice that between 3:02 and 3:16 the output volume was muted in Sound prefs. And in that case it is normal that you don't hear sound when you press the test sound button. Between 3:16 and 3:32, the output volume was set to 0.0dB. But there seems to be a lag of about two seconds before you can hear the beep the first time.

I do not know if sound prefs generates the sound or if it plays an audio file. In the first case I can imagine that this lag is caused by generating the 7.1 beep.

@SinanSam460

Ok, I managed to login to MantisBT and can see the bug report with answers from Hans.

I can swap cards again and test those video files. But the link suggests that those files are MP4 files. At the same time I read this comment on MantisBT:

Did *all* of them fail? MP4's shouldn't even use HW video decoding, because the libva MPEG4 code for UVD is buggy.

Ok, MP4 is not a compression standard but a container format. It can, among others, contain regular MPEG4 part 2 and MPEG4 part 10 (h.264) compressed data. But still, if libva also handles the container and not only the video data then I am a bit confused about that comment.

@geennaam

Ok, there is definitly something weird going on with my system. I use the RadeonRX V1.17 driver (latest one without GART/DMA). I can see that the CPU load peaks to 100% every second or so. But this can be normal behaviour without DMA.

I've just installed my HD audio soundcard again. Sound is playing at the correct speed but I noticed that the stereo sound is off. Music is audible without any stuttering or hissing but still you can hear that it is not entirely how it is supposed to sound. Like a "Hall" effect.

When I pan the volume in amigaamp I can confirm that it is not real stereo because I cannot completely mute the other channel anymore. Although possible, panning is not handled inside the sound hardware. It could be done by AmigaAmp or the AHI mixing routine. The only explaition that I have is that someting is going wrong with the DMA transfer, the DDR3 memory controller or os memory handling in general.

Sound is playing at the correct speed means in this case that the soundcard is fetching the expected amount of data with DMA from memory at the correct rate. So somehow the order of samples is mixed up. I doubt that it would get to this stage if wrong setup information was send to the soundcard.

Playing sound is nothing more than:
1. Wait for a DMA complete interrupt
2. Calling the AHI mixing routine to request a new block of samples. (AHI CPU routine; no dma involved)
3. Run a "for" loop to fetch, byteswap and write those samples to the DMA buffer location with the CPU. (again no DMA involved)
4. Repeat

So something goes wrong such that those samples arrive in the wrong sequence at the soundcard. But the error is subtile because music is audible. Maybe 1 failed write every x samples. This would swap left and right every x samples because the left and right samples are interleaved in memory.

A memory handling issue would also explain the cache coherency output on a warm reset. Afterall, the wrong CPU information is fetched from memory.

Anyways, like all the other issues. This issue disappears too when I go back to my R9 270x.

@SinanSam460

Ok. I've already ordered a new PSU. (Modular 750W 80 plus gold).

Let me try this one first to rule out any PSU problems.

My cache coherency crash is not related to the ScreenMode prefs program but to the amigaos reset. If I boot into workbench and perform a warm reset (only amigaos) then I get the same cache coherency error output and system halt.

@Spectre660

Did a quick test with DVI and a 1280x1024 monitor. This setup works fine. Screenmode change is solved in that setup.

Unfortunately my uwqhd monitor only supports hdmi and dp.

Edit: Correction, screenmode change is fine. No loss of output signal anymore. But the issue when changing the monitor settings in the screenmode pref still result in that weird cache coherency error output.


FYI:
The RX560 consumes less than 75W under load.
The R9 270X consumes up to 240W under load.


Todo: This error occurs after a warm reset. I have to check if a warm reset always results in this cache coherency error.

@Spectre660

Ok, i'll order a new PSU (current one is 630W). But that must be a power surge than when I switch screenmode. Because the RX560 only draws power from the PCIe slot. 3D games like HCRAFT plays fine in uwqhd. Without GART, 1080p movies play fine as well.

The R9 270X draws also power from 2x6 pin molex headers. This implies a much more power hungry card. (have to check the specs)

I'll also try if it makes a difference when I connect a DVI display.

@kas1e

Back on the RX560. (todo: check how many times I can do that before the PCIe connector wears out )

Removed the audio card and removed the driver.

Issue is the same. So it is clearly not the audio card or my HD audio driver.

@Spectre660

Back on the R9 270X again. No issue with changing screenmode. So the issue moves with the gfxcard.

@SinanSam460

I have the same version.

@Spectre660

Screenmode issues remain with the V1.4 and V1.17 driver. And they have no active Gart.