Can´t remeber me to have had crunshed on the AP´s on the GT 640. It will take insane longer, never mind. It must be temporarily used at the end of the wu to crunsh, i have must noticed this....

More and more i think it was only a bad driver behavior.

Before i used 361.82 !? Crawling throught the results -> even a fermi GTX got only about 2000 seconds to crunsh an astropulse...

---

i cannot see a significant gain?

The only gain sofar is, at me, when i drop AP-Tasks and crunsh only cuda 3.2-5.0 tasks , i will be able to run only 1 cpucore to fire up my GTX 670 + HD 6950 at the same time.

But don´t know right now if its "Vulkans" functions who did this possible or simply the drivers version.

---

As I see here there is a 'small' cpu usage reduction in regular Cuda crunching. Whether that's significant will depend on how CPU limited you are. In the case of my dev host, the 18% reduction running 2 tasks at a time (980) being fed with a Core2Duo It's very chocked. Possibly means an extra task in parallel becomes more efficient. (though not likely to test here in the short term with so much changing and going on in development)

So the drivers to me do appear leaner. How much difference that makes, as with any driver release a few after introduction of a new model, I don't get particularly excited about. For me it's more preparation for the development challenges ahead. Trimming fat and reengineering bloat always strikes a chord with the way I'd like to see things go with my own builds, so I like the small hists that things are being cleaned up.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The drivers (AMD) don´t affect anything on the HD 6950 i have. But should it have ?

---

The drivers (AMD) don´t affect anything on the HD 6950 i have. But should it have ?

Don't think so. The way I understand it a lot of the improvements stem from AMD's Mantle, and lean approaches used for game consoles anyway. So for the non vulkan app parts probably you got those in prior updates already.

In the case of Cuda on Windows, somes of the operations underneath were definitely DirectX before (which is pretty bloated). Some systems would see no change, some applications would see no change. It all depends on the CPU+memory dependance of the system itself, and what the app's use. The Cuda multibeam app relies on old fashioned CPU synchronisation where it is more likely to be noticeable on on lesser CPUs with fast GPUs (though will change in future builds to more modern methods that don't matter)

Probably another way to look at it, if the drivers are good and mature you shouldn't be noticing differences other than reliability/functionality. Newer apps however can start to use new features & ways of doing things that will see more improvement.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

How can i find in the results, a person who crunshed with the SAME Gigabyte 1GB HD 6950 like me ? Just to compare the results and find some improvments of the API for the project.

---

How can i find in the results, a person who crunshed with the SAME Gigabyte 1GB HD 6950 like me ? Just to compare the results and find some improvments of the API for the project.

Looks like AMD is only supporting Vulkan on GCN 1.1 and newer GPUs. See Vulkan Product Compatibility

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

How can i find in the results, a person who crunshed with the SAME Gigabyte 1GB HD 6950 like me ? Just to compare the results and find some improvments of the API for the project.

Well not sure what you're lookign for exactly, as the apps won;t be directly using the vulkan API yet (any change would be side effects of leaner driver internals).

Elapsed and CPU times on the results' pages would be the relevant data, along with Angle range from the stderr print If dealing with the multibeam apps. For AP, blanking % and number of signals would be relevant.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I´ve tried the newest nvdia drivers 361.91 WHQL, back to old school. Naw.

I installed the betas again.

Hm, must i allways reinstall the "VulkanRT" librarys again to set the API for nvidia drivers ? (Not tested yet)

Nvidia Expirierence must also installed, else is there a usage lost at 10-15% of the gpu.

---

Question:

Are there any usable console commands or enviromental variables,

what can be used to increase caching etc. ?

Known command list ? I will search google..

https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf

many, but how to use them ?

---

many, but how to use them ?

You have to become a programmer to use an Applications Programming Interface.

soso, write in C++ and compiling, no thanks.

Are there small console commands and windows enviromental (programmed) variables available ?

btw, theres a "Vulkaninfo.exe" , how can i dump the functions again ?
at first start it dumped all functions , at the second usage it worked nomore.

---

If anything, I'd suggest looking in the driver control panel. I suspect those would be all graphics oriented, but some things could come into play if you're CPU limited or using the display you're crunching on.

As for Vulkan itself, well we're not using that api yet, though the OpenCL apps would likely be affected by parts of it. There are documented environment variables you can set to change the way vulkan works, though those are mostly for debudding and verification, and would apply to applications specifically crafted for the Vulkan API (Which don't exist yet)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Seem Ok here so Far (though very early to tell), and also seem to work with actual Vulkan tests as well.

I tried 355.00.26 and it seems to produce a few more invalids with xz41 on V8 MBs than 355.06. It is not a disaster by any means but I have gone back to 355.06 for now.

https://developer.nvidia.com/vulkan-driver

There had been yesterday a new driver release, i think in future on this side will be more updates to download.

Seems to be unbelievable , but yet also crunshing on AP have reduced by 200-300 seconds quicker per workunit.

Here is the workunit:

http://setiathome.berkeley.edu/result.php?resultid=4751673495

---

I also have manualy this installed:

C:\NVIDIA\DisplayDriver\356.43-vkonly\Win8_WinVista_Win7_64\International\Display.Driver

VulkanRT-1.0.2.0-Installer.exe

Think, dont forget to install, if drivers dont do.

---

I just got the intention that, the "furry ones" have read this thread.lol

---

Nobody here to save energy an crunshing time on gpu tasks, its very sad.
Think the amount of electricity could be saved (and money). Thought it did effect more enthusiastiy on crunshing. It will need more advertising ;)

The numbers dont count, i have the drivers and runtime stable running since installed, is it so much risky to use new drivers ?

Ok, iam crunshing on a system there must be 100Kbyte ready to save :D, thats my link-collection, others all on optical datastorage.

What makes u to be convinced by this new drivers ?

---

dont install the drivers when using lunarics (allready optimized).

---

March 2nd, Windows 356.45, Linux 355.00.29

New drivers and API have been released today, see link for features.

https://developer.nvidia.com/vulkan-driver

---