I like to report again on the issue of video problems with my AMD Radeon HD8970M @jeff could you update on the status of the issue?
After trying all sorts of settings and tweaks I cannot get Rhino to display correct.
The issue is reported before and people have suggested disabling switchable graphics.
Unfortunately that is apparently not possible on my system.
I have tried, updating all drivers (Both AMD and the INTEL HD Graphics 4600)
Installing AMD beta drivers
Disable the Intel GPU (disabled the AMD as well)
The problems I encouter and these:
When window selecting, the viewport is not updated .
The other issue that is harder to duplicate, is the viewports switching places as shown in this video by @djnelson75
The issues make it tedious to work with Rhino. I’d like to get any tip or trick to have it (temporarily) fixed.
I can use the INTEL card for Rhino but for many projects that is no true option.
My specs:
Version 5 SR7 64-bit
(5.7.31213.18395, 12/13/2013)
Commercial
SN: 4-1502-0101-100-0000577-28694
Win 8.1 Pro 64b
( I see there is a SR candidate available and try to get that installed now)
I also an curious if there is any progress. All of my tricks to get things to work have ended in a dead end. While in my last post I stated that forcing Rhino to use the intel card made things more stable, it did expect caused Rhino to crash when importing dwg blocks, so I am back a square one.
Unfortunately the SR candidate isn’t going to fix the problem. Why? Because it’s not a problem with Rhino. We managed to put together a small, simple OpenGL example program that demonstrates and details the issue for AMD, and they have it in their possession. So far we have not heard anything from them on this matter, but I will ping them again today.
The “apparent” underlying issue has to do with some kind of caching going on under the covers with frame buffers of the same size (guessing here). Meaning, the problem only shows itself if ALL frame buffers being used in the system (i.e. Process or thread) are the same size… For example: Rhino’s 4View system creates 4 viewports (frame buffers) all the same size…and thus, the problem rears its head. So when users claim that the problem goes away when only using 3 or 5 (or ?) viewports, it’s because that causes Rhino to size the viewports (at least one of them) differently than the others, and the bug hides itself.
Try this, in your 4View layout, position the mouse over the center where all 4 viewports intersect (you’ll get a Cross cursor). No left-click and hold, and drag the sizing bar one click to the left or right. This will cause 2 viewports to be larger than the other 2, and you should no longer see the problem (as bad). There will still be other issues related to the problem, but viewports showing up in the wrong place should no longer occur.
I apologize this is taking so long to fix, but as I said, AMD has something they can use to reproduce the problem so hopefully there will be a fix within the next driver release cycle.
If you enable your Intel GPU, please also make sure Rhino knows it should allow its usage by using the test command:
Hmmm…it appears that my entire post did not make it… Here it is again (hopefully) in its entirety…
Unfortunately the SR candidate isn’t going to fix the problem. Why? Because it’s not a problem with Rhino. We managed to put together a small, simple OpenGL example program that demonstrates and details the issue for AMD, and they have it in their possession. So far we have not heard anything from them on this matter, but I will ping them again today.
The “apparent” underlying issue has to do with some kind of caching going on under the covers with frame buffers of the same size (guessing here). Meaning, the problem only shows itself if ALL frame buffers being used in the system (i.e. Process or thread) are the same size… For example: Rhino’s 4View system creates 4 viewports (frame buffers) all the same size…and thus, the problem rears its head. So when users claim that the problem goes away when only using 3 or 5 (or ?) viewports, it’s because that causes Rhino to size the viewports (at least one of them) differently than the others, and the bug hides itself.
Try this, in your 4View layout, position the mouse over the center where all 4 viewports intersect (you’ll get a Cross cursor). Now left-click and hold, and drag the sizing bar one click to the left or right. This will cause 2 viewports to be larger than the other 2, and you should no longer see the problem (as bad). There will still be other issues related to the problem, but viewports showing up in the wrong place should no longer occur.
I apologize this is taking so long to fix, but as I said, AMD has something they can use to reproduce the problem so hopefully there will be a fix within the next driver release cycle.
If you enable your Intel GPU, please also make sure Rhino knows it should allow its usage by using the test command:
-_TestVendorGLSupport Intel=Yes Enter
…for now, you might want to put that in your startup command list so that you don’t have to do it every time you start rhino…or so you don’t forget to do it.
Thanks again for everyone’s patience on this.
-Jeff
