Radeon RX cards on X1000

sailor wrote:
Quote:

BEST definition EVER

@sailor

Yes, after all these years we somehow still love our Amigas. But that doesn't mean that she has to look like a grandma with a hip replacement.

Honestly, since I got my RX560, I initially bemoaned the loss of soft-reboot, but now I don't really notice. I prefer to be able to watch full HD videos on my X5000.

As I understand it, soft reboot is only an Amiga thing anyway. It's not that Hans has removed the code, its just that it doesn't work with more modern cards, because they were never designed with this feature in the first place. So bemoaning that we can't drag ourselves forward into the 21st century like Windows seems illogical in this instance.

Hope I don't offend anyone - this ain't AW so don't want to flame.

I am afraid I have to agree with Hans and daveyw, although I love having soft reset. If the way moving forward is to lose some "features, " so be it. Having all the new stuff is much more important than having a soft reset and maybe RAD.

The problem is not that we are losing the soft reboot, but that we shouldn't need to reboot. But unfortunately, we are in a situation where the system is not protective of problematic software.

As Hans mentioned we are missing a lot of stuff that should be there. And I do not blame anyone for that. Everyone did their best, but we need more active dev teams.

On the other hand, if you want these features you can use a Gfx card that still supports them. But you might lose the new features.

@Raziel

So, the card is stable with interrupts off. Display seems slightly sluggish though.
I'll try with the Compositing setting "sync with vert refresh" off and see how that goes with interrupts on.

However, I don't think I have any use for this card because the primary reason was to get a card with DP output and HDMI 1.4, not just the old bulky and now obsolete DVI to support high resolutions.

With my new job I needed a new monitor for my home office with USB-C. And you cannot get USB-C + DVI. Doesn't exist. You typically get HDMI + DP on all monitors together with *either* DVI *or* USB-C. Since HDMI worked find with the HD6750 and DP being the same as DVI, signal-wise, I didn't even bother checking that the RX-driver can do HDMI or DP. That was a hard assumption, that it could do at least one of them.

Did I flush my money down the wrong toilett here, or how to enable DP or HDMI output from an RX560??

I kind of have to choose: Amiga (DVI) or work (USB-C)?
(a silly alternative would be to run the new screen with USB-C using the old HD6570 and HDMI on suboptimal resolution...)

Please tell me DP or HDMI can also work with the RadeonRX driver!

@Deniil

HDMI works on both the 560 and 590 here

@Deniil
Quote:
HDMI is basically DVI with a few extensions such as the ability to stream audio. DisplayPort (DP) uses different signalling and is incompatible with DVI & HDMI. Those DP to HDMI adaptors are basically a trick. The graphics card routes HDMI/DVI signals to the DP connector, and the adaptor just connect the signals through to the correct HDMI pins.

Yes, the RadeonRX driver can output HDMI, including UHD resolutions (which, IIRC< requires minimum HDMI v1.4).

Hans

@Hans

Thanks.
Actually after fiddling around a lot, HDMI suddenly started to work when I selected DDC, even if I had the "correct" resolution plus my old ones in the list. It also worked without DDC on DVI to my old monitor, but no output on HDMI (or DP). Strange.

With DDC enabled I got picture on HDMI, if DVI was not connected.

So HDMI and DVI are related, but not DP. I assumed DP and DVI were the similar ones. So does that mean we cannot get output on DP at all?

So a DP to HDMI adapter requires code in the driver then, and knowledge about such adapters? What I would have needed was a DVI to DP adapter I suppose. I have a DP to DVI but that doesn't help at all obviosuly...

Anyway, using interrupts=on and Composition "sync with vert"=off now. Seems to work.

@Hans

About the interrupts problem: I now have interrupts=on and it seems like the function WaitTOF() never returns, until there is a change in resolution.

So with the compositing setting not using this function itself, most things run fine, but MUI popdown menus seem to call this, or a similar, function and will hang that app, until there is a change in screen resolution.

I use PPaint to cause resolution changes. Just having it open and switch to its screen "unhangs" those apps.

Annotate, the text editor uses WaitTOF() to limit the speed when scrolling the text by dragging with the mouse above or below the window. I actually have a comment in the code: "//stopped working in OS4-upd3.. :(", but it is since long activated again. So when clicking the text, a waitTOF()-limited loop starts which immediately hangs the program, until PPaint is reveiled again.

Thougths on that?

@Deniil

Quote:
Not at present. The code to support DisplayPort is more complex than I think it should be, and the need for DP is rather low vs other functionality. There's always been other GPU features that are higher value and therefore take priority.

Quote:
Rather strange that the interrupts are unreliable on the X1000. They're working perfectly fine elsewhere.

Could you add your findings to the bug report here?

Hans

@Hans

Bug filed. Hope it helps.
I also notice some gfx corruption in GUIs. Both MUI and ReAction. I wrote that too in case it's related somehow. Forgot to write it affects both ReAction and MUI though. But now you know.

With that said, I have not use EH2.2 before, so many updates at the same time here. That stuff could potentially be something different, but probably not.

@Deniil

I added all of your info to my bugreport http://www.amiga.org/developer/bugreports/view.php?id=950

You can add any more findings to this item, so it won't get lost

@RazielQuote:

how can get one a user there?
i *think* i have one. but don't know my password. i cannot send a "password lost" mail. response:


(maximum # of queries in progress reached...)

trying to create a new user i get:


(email address already in use)

i tried to contact the admin several months ago. but no chance so far.

thanks and regards
Michael

@MichaelMerkel

The mail server (and settings) on that bugtracker is severely broken.

I never receive *any* updates to my items, though I opted in in all of the options.

Maybe @broadblues can help, he seems to be an administrator there?

@MichaelMerkelQuote:

Yeah, I once tried to set up an account there too. I literally received the confirmation email months after I applied, by which time the link had long expired. And no, I don't mean I checked my spam folder months later and found it, it didn't get sent to my inbox until months later.

@Raziel

Thanks for putting the info. I think it will make debugging a lot more focused that "random freezes" which was the first impression.

I found out becuase I wanted to test my new monitor's screen switching abilities, using PPaint, and at the same time noticed that frozen programs "unfroze" when I had switched to PPaint and back.

But it should also be noted that I got wierd gfx glitches with PPaint, or rather when switching to its screen. Different things, like wrong pen colors sometimes, mouse pointer "painting" over the screen (although I occasionally saw that with my RadeonHD too). The mouse pointer is sometimes incompletely drawn (on all screens) and sometimes gets stuck in sleep-pointer mode on WB.

Now, I did install the EH2.2 at the same time as the new gfx card, so can't exactly blame everything on the RX560 or the RX driver, but gfx glitches does lean towards it.

@Deniil

You have one weird machine. I've never seen or heard of mouse pointer glitches with either the RadeonHD or RX drivers. I don't use PPaint, and don't remember hearing any complaints.

It almosts sounds like there's a problem with memory coherency on your machine...

The RadeonRX driver is the first one with GART support, and we did discover a very old bug in the radio gadget used by the old installer utility. The bug made it impossible to select anything, and would go away if I slowed down the driver (i.e., undid any speed gains we got). Needless to say, I wasn't keen to deliberately cripple the driver just to work around old bugs. There may be other such bugs lurking, where it used to work with slower graphics cards/drivers.

Of course, it could just as easily be a driver bug...

Hans

@Hans

Hehe, well. I've never seen that mouse pointer glitch until now with the RX560.

It seems like if the mouse pointer changes during some other major draw operation, such as creating windows, it simply doesn't change, but remain a sleepy pointer f.ex. as was set during selection of a file to load, which triggers opening of a new window f.ex.
I still see this with interrupts=off.

The popdown menus (and popdown-style cycle gadgets) work fine when I disable interrupts. (Seems like they use WaitTOF() to render cleanly..?) Never had any problems with radio gadgets.
This problem disappears with interrupts=off.

I don't see the rendering issues with interrupts=off either. Can't repro the missing line or text drawings or scrambled logos.

PPaint has always had some issues and glitches with OS4 I think. Sometimes there are stray gfx left after the mouse pointer/cursor. Just a refresh of the drawing area cleans that. Didn't/doesn't happen every time. Sometimes the mouse pointer disappeared in magnifying mode, or it forgot the pen style used. This all happened with the HD card, and I believe there were some issues also on the old A1-XE with R7000 card as well. It simply has some bugs in the planar emulation or something.

A shame it can't work with true chunky screens, just simulating limited pens etc. Would have been much simpler to code that way, and not requiring a monitor resync when switching to its screen etc.

So to conclude: WIth interrupts=off everything works normally on the RX560 (including PPaint), except for the mouse pointer that sometimes doesn't change as it should. I can make a video of that rather strange behaviour if you like.

I have a reproducible case:
Program has a main window and a settings window.
When opening settings, the main window gets a busy pointer.
When clicking back and forth between the main and settings window the pointer should change, but it doesn't. Only it's point position moves (sleepy has pointAt at the middle-bottom while the normal mouse arrow has pointAt at top-left). Looks wierd. So pointAt changes, but not the actual sprite gfx. Never seen that behaviour before.

Continuing on the subject of interrupts.

Now I have been using my RX560 card in my X1000 with "Interrupts=No" for some time. Things have appeared to have been working fine. Only a few strange gfx glitches.

However, after starting to sort pictures from the year so far, using PicShow by Thomas Rapp on its own screen (as the last 20 years), I noticed massive gfx corruption on random images when flipping through. Going back and forward again, the pic shows fine again.

But when exiting PicShow and the screen closes it seems like the RX560 without interrupts copy and blitt data randomly creating massive garbage on the parent screen (DOpus). Sometimes containing parts of the last viewed picture, sometimes a distorted piece of the Workbench screen rendered randomly over the DOpus screen. It just seems like the blitts are not synchronized with whatever they need to be synchronized to, copying from random places at the wrong time.

It also destroys font glyphs so menus and requesters render garbage text afterwards, also on WB.

Tried switching off Composition on the DOpus screen to no avail.
Setting Interrupts=Yes seems to completely fix this problem, but then every program calling WaitTOF or similar will hang, so MPlayer doesn't work, dropdown in-GUI menues (cycle gadgets) don't work etc.

So interrupts are clearly working on the card, they just don't trigger WaitTOF.

/me eagerly awaits an update
PS. I can beta-test if necessary.

@Deniil
@Hans

Quote:
Me too