Folding Forum

Neklor wrote:Thanks, this works with the CPU slot.
When I switch to the GPU slot the viewer freezes and I have to restart it.

Hi there, thank you for responding.

We are currently having great difficulty supporting GPU specifically core 0x22.
For that reason it has been my very intention to disable 0x22, which in this case is your "GPU" slot.
With so many people nowadays connecting to F@H, it is my estimate that most people do not necessarily attempt to switch slots.
They just want to see what their computer is doing.

Therefore this version will work flawlessly on CPU tasks and older GPU cores but not this current 0x22.
This version is therefore a temporary substitute until we get 0x22 working.
To exactly that extent, I am wondering *if it's working*.
Thanks again for testing as I can certainly not do this alone.

Please let me know of this info changes anything for you.

Thanks for the update. Is a particular 32-bit freetype.dll or freetype6.dll also needed?

I used the compiled binary on Win7 64bit, with 32bit FAH client v7.5.1 installed, and the 'freetype6.dll' from FAH v7.4.4.
I see everything except the protein atoms. It stays in: 'Connected' | 'Loading' state, and does not go to 'Live' state. I let the viewer run for at least 20 minutes or more. I tried a few FAH restarts with no difference.

I normally only run a FAH GPU slot, so I also tried (1) GPU (Nvidia 1080) + (1) CPU (4 threads of 8 core CPU) slots. It was the same, but cycling slots every 10 seconds. I think the cycling only happens when viewing the slot fails, then the Viewer tries the other slot. (Or, it does not have enough time to load in 10 seconds)

Normally, the viewer v7.4.4 (on Windows) or v7.5.1 (on Linux) does not cycle automatically, and it takes 15-30 seconds to load the slot. '[' and ']' should switch slots, or selecting the slot you want to view, and clicking the Viewer button in the GUI.

Thank you so much for testing.

Found something suspicious in the code.
You can reDL the updated binary and it *should* be fixed now.

No DLL is required.

Cycling happens when the client figures the core is incompatible or the slot has no WU.
In which case it will not even attempt requesting trajectory data and should state "Awaiting" instead of "Loading".

If there is no simulatable slot, it will still show project information including progress, while no protein will be rendered.
While counterintuitive, I thought it'd be better than showing absolutely nothing.

This worked flawlessly for me.
Thanks Quantize!

That is really good to hear, thank you for testing with us.

Hi everyone,

@Quantize:
On my W10 64b, your FAHViewer gives same display as dfgirl12. I mean only the regular FAHViewer window app with its cornered texts but center is empty (no protein display).

Also I've checked the FAHViewer + its freetype.dll proposed by str4d on github issue 1283
--> It gives me the FAHViewer regular display + protein in pink cube mass.

Still, I am not able to display protein without surrouding water.
Please let me know. I am available for tests.

Thank you for this FIX !!!!
It works flawless for CPU projects!!!

To see the GPU projects is still not possible...

LaPeche35 wrote:Hi everyone,

@Quantize:
On my W10 64b, your FAHViewer gives same display as dfgirl12. I mean only the regular FAHViewer window app with its cornered texts but center is empty (no protein display).

Hi! Thank you for your report.
Are you 100% positive that you are actually running a WU in your CPU slot?
WU's are somewhat hard to get these days.

Duffbro wrote:Thank you for this FIX !!!!
It works flawless for CPU projects!!!

To see the GPU projects is still not possible...

As to getting GPU to work in the viewer: ofcourse we all want that, me too.

Thing is.. if the problem is not in the viewer but in the core itself that's feeding the viewer malformed data, then we're possibly going to be stuck here for a while.
Because in this crucial time I don't think we can just roll out new core versions hoping that they'll work.

So for such scenario it is my intention to release something for inbetween that works flawlessly with CPU and doesn't show a purple cube and crash the viewer.
Hundreds of thousands of people are connecting nowadays and many of them would greatly appreciate what their CPU is actually doing.

This would certainly result in a significantly reduced churn rate, now and in the future.

Am going to try work out Jorgeminator's idea now, to drop the water molecules fed from that core.
Perhaps that leaves us with a decent protein simulation that we can work with.

If successful, it would not be necessary to disable GPU 0x22.

Quantize wrote:

LaPeche35 wrote:Hi everyone,

@Quantize:
On my W10 64b, your FAHViewer gives same display as dfgirl12. I mean only the regular FAHViewer window app with its cornered texts but center is empty (no protein display).

Hi! Thank you for your report.
Are you 100% positive that you are actually running a WU in your CPU slot?
WU's are somewhat hard to get these days.

Here is all you may need:
W10 1909 64b up-to-date + nVidia GeForce 1060 6Gb driver 442.59 + FAH 7.5.1 (GPU slot only) + WU 11766 (clone 11719 gen 3)
- genuine Viewer: see demo only
- str4d's Viewer + freetype.dll : see protein + water
- Quantize's Viewer: no protein and no water
NB: I suspend WU calculation between tests as long as FAH server are not sure to give other WU. That is not good for researchers but maybe someone can send factice WU to me?
NB: FAH set for GPU slot only
NB: despiste I wrote in 1rst post, I did test with str4d version thentest Quantize version. Should be important to know (maybe corruption of any file that will still only usable by str4d's)?
I restarted my PC before rechecking.

LaPeche35 wrote: (GPU slot only)
- Quantize's Viewer: no protein and no water

So that's working as intended.
If you're not going to CPU-fold you're not going to get a visual right now. Until we fix the GPU part, that is.

Unless ofcourse you prefer looking at a purple cube of water with some kind of vague semblance of a proteine inside which may or may not crash the viewer.
On the contrary, "my" version will guarantee a flawless, stable CPU-slot visualization.

Quantize wrote:

LaPeche35 wrote: (GPU slot only)
- Quantize's Viewer: no protein and no water

So that's working as intended.
If you're not going to CPU-fold you're not going to get a visual right now. Until we fix the GPU part, that is.

Unless ofcourse you prefer looking at a purple cube of water with some kind of vague semblance of a proteine inside which may or may not crash the viewer.
On the contrary, "my" version will guarantee a flawless, stable CPU-slot visualization.

May you please get in touch with str4d? He may to not display water molecules? That would be good to be a trigger option fom keyboard. I mean, the W key still available. This may show/hide Water?

The water molecules are not the only problem when viewing GPU projects. Only carbon, oxygen and sulphur atoms are shown properly at the moment. Hydrogen and nitrogen atoms in the protein are not recognized. We must wait for an updated core for these to work.

.