Very basic problem with interface - AMD RYZEN incompatibility ?

@bcolyn @vincent-mod @@mabula-admin

I will try running with -Dsun.java2d.d3d=false as @bcolyn suggested.  I will follow up regarding this workaround.  It's funny to see how many of us share similar interests and professions 😀 This setting disables the Java 2D Direct3D pipeline, so I wonder if that will result in significant performance degradation for large stacking and integration jobs.  But if it works, that's still better than not being able to use the software.

I tried searching for other posts about this problem and could not find any.  Given how easy it is to trigger it, and how often I have seen it, I'm wondering why more users have not experienced it.

So it has something to do with the latest gfx cards, Mabula (@mabula-admin) knows about it and hopes to fix it.

Hi @stephent, @tiku, @mohman, @millo007, @bcolyn,

This evening i had a look an Ray's computer with the same problem, mentioned in this thread:

https://www.astropixelprocessor.com/community/windows/windows-64-bit-app-glitchy/

His problem seems to be caused by a driver conflict:

I just had a look on Ray's computer where the error was happening. I think we managed to find the cause of the problem.

I will be happy to check on your computer's as well to see if we can solve this 100%.

On Ray's computer, an intel graphical chip driver+ control center was installed. But there actually was no intel graphical chip in the computer. So that caused a driver conflict when the existing graphical chip is used. Both the intel and the nvidia driver are sending instructions to the single graphical chip/hardware and that seems to be the issue, at least on Ray's system.

Please let me know if you want me to check your pc's as well for such a driver problem. We can do this with Zoom and Teamviewer combined.

To be clear, the problem seems to be a driver conflict on the Operating System level, and nothing inside APP. But to be 100% sure, access to your machines would really help 

If you want me to have a look, please contact me directly using email : support@astropixelprocessor.com

Please let me know if you want me to check on your systems as well to solve this nasty bug 100% 😉

Cheers,

Mabula

Hey @mabula-admin, you're welcome to have peek here, but there's no Intel graphics driver whatsoever on the system.

It's a AMD Ryzen CPU, AMD motherboard, single GPU (nvidia) - and there's never been another GPU in the system (fresh install in jan 2020, when I build the system)

Hi,

Checked too my machine, and no Intel references found. Nowdays issue seems to be pretty rare though. I have seen it once in last few months, and machine had been running for three weeks without reboots and windows crashed maybe hour later.

Anyways I'm going to experiment with _JAVA_OPTIONS=-Dsun.java2d.xxx options if issue starts to resurface. I have a faint recollection that they helped a long time ago with issue similiar to this.

@mabula-admin

Hi Mabula,

Having made the change to D3D config as suggested by @bcolyn above ( https://www.astropixelprocessor.com/community/main-forum/very-basic-problem-with-interface/paged/2/#post-11729 ) I have not experienced any further problems with the interface.

My PC also was a new build. AMD motherboard & CPU, NVIDIA RTX graphics.

Best regards,

Stephen 

Hi @bcolyn, @tiku, @stephent

Thanks for all of your reactions. It would help me if you can all provide me access to your computer using both zoom and teamviewer so I can get a clear view of which problems lead to the messed up interface of APP.

If you would ask me, from a technical point of view, the

-Dsun.java2d.d3d=false

setting is a workaround and definitely not the solution. If you need that setting to have app work without the glitches, you should be aware that your graphical subsystem on windows is likely not configured properly/optimally for some reason.

I can however prepare a separate installer for windows with this setting activated, so users don't need to set this themselves. Maybe I can even make it possible to set this as a setting in the configuration CFG menu. I will check ;-). And... I will test on my windows machines if disabling D3D actually harms performance in any way. If it doesn't, then I could even provide the windows installer always with the setting activated to not use D3D.

I am very happy to hear that by using this setting as Benny proposed, the problem is gone on affected systems. Thank you very much @bcolyn.

Now, I have 3 windows computers,

• an AMD Threadripper workstation with 1 graphical chip: Nvidia GTX 1060 6GB
• a Lenovo X1 carbon laptop with 1 graphical chip: Intel chipset on the motherboard.
• a very new Alienware Area 51-m laptop with 2 graphical chips: Intel chipset on motherboard + Nvidia RTX 2080

On all of these 3 computers, the glitches never happen. On the Alienware laptop, I frequently process different image sets all day (without ever restarting APP) for testing and the problem never occurs. So for me that is clear proof that the problem is NOT related to the new Nvidia hardware/cards or caused by something in APP's code. It is much more likely that the problem is on the Operating System's driver level, which I will be happy to confirm (or not) if you can all provide me access to your pc in a joint Zoom + teamviewer sesssion in the course of the coming days.

Anyway, I am very happy that we are getting to the bottom of this issue now. It is a nasty one for sure 😉

Cheers,

Mabula

Hi @mabula-admin

Yes, I agree, disabling hw rendering should be the last option.

I managed to create a test case which I can use to produce the issue every time. https://1drv.ms/v/s!AqHMTwHaH7IRgppSwdanjVgc6JwTCA?e=OmtHof

Basically this means that if you resize the file selector fast enough, it will break the rendering pipeline.

This will not happen if you use software rendering, or if you use opengl rendering. Both of them are clearly not double buffered and flash annoyingly, but this distortion does not start. My feeling is that it is JDK issue (maybe some event comes too fast/unpredictable order and breaks the pipeline) and not graphics driver issue.

Maybe it could be reproduced with simple app with file selector alone.

Hi,

I also managed to test this on my very old Nvidia-based laptop, and it did not show any symptoms, but according to trace log, the d3d pipeline turns off completely around the same time issue should manifest itself. Odd.

Hi @mabula-admin

Thought it worth repeating that with D3D enabled it took about a second to draw all the loading buttons in the left hand pane, in kind of a "ripple". With D3D disabled these draw instantly after the working directory is selected.

If this slow drawing of the buttons does not happen on your RTX laptops I'd suggest you won't be able to reproduce the issue. Not sure if relevant but I don't think desktop RTX and laptop RTX are the same GPUs.

Is everyone experiencing the issue using a desktop GPU?

I am happy to continue using the workaround if it can be demonstrated that integration time doesn't suffer with D3D disabled. Am sure you have more important things to be working on for the wider APP community.

Best regards

Stephen

Hey @mabula-admin, did some further digging - hope this helps:

To rule out driver issues and to make sure:

• I booted into safe mode and used DDU (Display Driver Uninstaller - a well-known tool for completely removing "leftover" drivers) to remove all display drivers from the system. Also disabled installing drivers from Windows Update.
• rebooted into a display-driver-less and single monitor system. Still glitches (attach)
• clean install of the latest nvidia driver. No joy 

Focussing again on the Java2D side and referencing this: https://docs.oracle.com/javase/10/troubleshoot/java-2d-pipeline-rendering-and-properties.htm#JSTGD438

• I set environment variable J2D_D3D_RASTERIZER=ref, which gave me the Microsoft reference (software) renderer for direct3D - incredibly slow but it still glitched out when using the tooltip on the file open dialog to trigger it. 
• Other suggested settings for J2D_D3D_RASTERIZER showed less of a performance impact, but still had the problem. To me, this indicates the problem is somewhere above the Direct3D layer (JDK, libraries or application)
• I set -Dsun.java2d.opengl=true to force the opengl Java2D pipeline, with interesting results. The embedded image viewport had rendering artefacts when there was no image loaded but the rest of the UI didn't and worked fine. With an image loaded the UI behaved and performed well, but the top left button showed "CPU" indicating that the opengl rendering of the image viewer was somehow inhibited.

As intriguing as this problem is, I'd gladly live with the workaround if it gets us a "load/save files and settings" feature sooner 😉 

Posted by: @stephent

Hi @mabula-admin

Thought it worth repeating that with D3D enabled it took about a second to draw all the loading buttons in the left hand pane, in kind of a "ripple". With D3D disabled these draw instantly after the working directory is selected.

If this slow drawing of the buttons does not happen on your RTX laptops I'd suggest you won't be able to reproduce the issue. Not sure if relevant but I don't think desktop RTX and laptop RTX are the same GPUs.

Is everyone experiencing the issue using a desktop GPU?

I am happy to continue using the workaround if it can be demonstrated that integration time doesn't suffer with D3D disabled. Am sure you have more important things to be working on for the wider APP community.

Best regards

Stephen

@stephent all button-drawing is faster than I can see on my (desktop) 1070 GTX regardless of using the Direct3D pipeline or not. 

Most laptops have an integrated and a discrete GPU, with the discrete GPU rendering indirectly (via the IGP). On my laptop (which does not glitch btw, Intel CPU and 1060 GTX) APP uses the integrated graphics by default unless explicitly overridden in the Nvidia control panel to force the dGPU (the default IGPu works fine btw).

Disabling GPU acceleration for the UI (Java2D) does not impact the actual image processing speed, that happens purely on the CPU anyway.

Posted by: @bcolyn

Posted by: @stephent

Hi @mabula-admin

Thought it worth repeating that with D3D enabled it took about a second to draw all the loading buttons in the left hand pane, in kind of a "ripple". With D3D disabled these draw instantly after the working directory is selected.

If this slow drawing of the buttons does not happen on your RTX laptops I'd suggest you won't be able to reproduce the issue. Not sure if relevant but I don't think desktop RTX and laptop RTX are the same GPUs.

Is everyone experiencing the issue using a desktop GPU?

I am happy to continue using the workaround if it can be demonstrated that integration time doesn't suffer with D3D disabled. Am sure you have more important things to be working on for the wider APP community.

Best regards

Stephen

@stephent all button-drawing is faster than I can see on my (desktop) 1070 GTX regardless of using the Direct3D pipeline or not. 

Most laptops have an integrated and a discrete GPU, with the discrete GPU rendering indirectly (via the IGP). On my laptop (which does not glitch btw, Intel CPU and 1060 GTX) APP uses the integrated graphics by default unless explicitly overridden in the Nvidia control panel to force the dGPU (the default IGPu works fine btw).

Disabling GPU acceleration for the UI (Java2D) does not impact the actual image processing speed, that happens purely on the CPU anyway.

 

OK, apologies; my mistake... I thought this issue was limited to systems running NVIDIA RTX cards.

Hi,

Curiously enough, my GTX 1050 Ti laptop will not even start d3d mode and defaults always to software rendering (and has no issues, unsurprisingly).

@mabula-admin does your laptop actually run d3d renderer all the time and still work? Or does it silently drop to software renderer?

Just wanted to say, thank you all for being patient about this and giving such good detail in your own troubleshooting. This helps us a lot!

Hi,

After some testing, I think I'm perfectly happy with -Dsun.java2d.d3d=false .. no ill effects, everything working just fine and smooth. 

Mabula and Vincent

Guys after a week of processing and creating masters I am sad to report that the glitch does still occur. It only has been happening about every 5th use but always at the file load (Tab 1) and I have noticed that it does not seem to happen if I don't move my mouse fast or try to rush to add files. That may not be anything but it just seems that to get it to happen now I need to be adding files as fast as possible. If the "-Dsun.java2d.d3d=false " does work possibly I may need some information on how and where to enter that command. The glitch is nowhere near as bad but as I said I am sad to report it has returned. 

Ray

Dang I had to keep reading being nosy. One poster said that if while loading file he hit the details button in the upper right that he could replicate the error. Loe and behold I hit that button and the duplicate screens started again. Maybe that command line that Bcolyn found may be the answer for me as it was for him even though I do not have a Ryzen in my laptop. I would add it myself but don't know where to put it. A zoom or teamviewer use of my laptop would certainly be ok with me. 

Thanks

Ray

@rayschilkecomcast-net
https://www.astropixelprocessor.com/community/postid/13637/

Hi all @bcolyn, @rayschilkecomcast-net, @tiku, @vincent-mod, @stephent, @mohman, @millo007, @aaronbass, @bluknght, @zaph

Within several hours, APP 1083-beta2 will be released and I have included bcolyn's fix in the installer to disable direct3d hardware accelaration on the Java JDK native components. And I have also set to disable OpenGL on the Java JDK native components to make sure that does not conflict with our own developed OpenGL image viewer.

@bcolyn, thank you very much for solving this issue. I have tested it and it does seem to completely solve the issue, so I agree that it is a Java 8 JDK issue which manifests itself on newer systems. My guess is the lack of older D3D files on those systems which the JDK 8 needs somehow. And yes, on my new Alienware laptop with Nvidia RTX2080 chip, i did have those old D3D versions installed which explains then why the issue never happened on my system.

So I think another solution is to install those older D3D versions on these new systems.

Anyway, the fix is burnt in, in the new installer, so you won't need to have to change the AstroPixelProcessor.cfg file like you did before 😉 to have it work correctly.

Thanks a lot !

Mabula

@mabula-admin good to hear, looking forward to trying the beta.