On Nov 15, 2011 the 'OpenCL 1.2' specification was announced by the Khronos Group which added significant functionality over the previous versions in terms of performance and features for parallel programming. Most notable features include:
Device partitioning: the ability to partition a device into sub-devices so that work assignments can be allocated to individual compute units. This is useful for reserving areas of the device in order to reduce latency for time-critical tasks.
DirectX functionality: DX9 media surface sharing allows for efficient sharing between OpenCL and DX9 or DXVA media surfaces. Equally, for DX11 seamless sharing between OpenCL and DX11 surfaces is enabled.
Partitioning may not be exactly the same thing as CPU priorities, but "reduce latency for time-critical tasks" sounds promising. Of course, the OCL 1.2 spec is very new, so it's probably going to take a fairly long time to see it supported by drivers and GPU computing apps, not to mention that existing GPUs might not be OCL 1.2 capable. Anyway, there seems to be something at the end of the tunnel...
It can help but not nearly as much as task priority would.
If the FAH program (or maybe the Donor) could partition the shaders so that FAH used (100-XX)% of them and never used the remaining XX% of them, the operating system could probably manage screen updates with only those XX% and still be quick enough to keep people happy. The real disadvantage is that you'd have to select a fixed percentage.
FAH has no announced plans to upgrade the requirements to OpenCL 1.2, but I'm sure that somebody, somewhere, is thinking about the pros and cons.
Funny coincidence on my part since I haven't followed recent GPU developments much, but barely a week has passed of my initial post, and now there's AMD Radeon HD 7970 Series GPU officially announced on FAH Hardware forum, mentioning it'll be the first to support OCL1.2. Maybe, with proper GPU partitioning support implemented, we will one day see a folding client where the GPU utilization slider works well, and the utilization can even be adjusted mid-WU. One can always hope and wait (patiently).
bruce wrote:It can help but not nearly as much as task priority would.
If the FAH program (or maybe the Donor) could partition the shaders so that FAH used (100-XX)% of them and never used the remaining XX% of them, the operating system could probably manage screen updates with only those XX% and still be quick enough to keep people happy. The real disadvantage is that you'd have to select a fixed percentage.
FAH has no announced plans to upgrade the requirements to OpenCL 1.2, but I'm sure that somebody, somewhere, is thinking about the pros and cons.
I didn't read the full news article just the opening post, so excuse me if I missed something there which makes the following impossible;
If at some level the driver has authority over other applications, it could override the utilization for any task since as I understand it, the parameter doesn't have to be set at compile time. So a method for setting dynamic utilization levels is how the driver can manage task ( process/application? ) priority. With other words: driver ( middle layer for compute assignments ) running 100% when no other tasks need resources, yet will limit utilization for compute assignments when needed ( ofc, this is overly simply stated, as the driver would have to be configurable in which tasks have which priority )
None of the drivers that I've seen have any way to designate which application might have a higher priority than some other application that also wants to use the gpu resources. Maybe that will happen someday.
Ati has designed drivers that use a lot of cpu resources; nvidia has designed drivers that use cpu resources sparingly. this also might change as better drivers are developed.
Well I don't think you seen many drivers for this generation of cards now have you
As you say, it might come. I was only theorizing on what I thought to be a to early exclusion of these hardware and compute layer ability being a base for allowing task priority in the future.
Also, I'm expecting cpu usage to be drastically lower for gpgpu tasks. After all, it is a new architecture ( the first since R600 ) and the cpu usage I bet wasn't only a thorn in the side of folders alone.. Can't find any review which has some relevant data to cpu usage during gpgpu tasks but gpgpu is what this architecture is really made for ( as Fermi was with Nvidia ) and maybe all the added cache's are there so there need to be far less transfers of data outside of the card ( wasn't that the reason the cpu usage was so high? ).
Hardware configuration: Intel i7-4770K @ 4.5 GHz, 16 GB DDR3-2133 Corsair Vengence (black/red), EVGA GTX 760 @ 1200 MHz, on an Asus Maximus VI Hero MB (black/red), in a blacked out Antec P280 Tower, with a Xigmatek Night Hawk (black) HSF, Seasonic 760w Platinum (black case, sleeves, wires), 4 SilenX 120mm Case fans with silicon fan gaskets and silicon mounts (all black), a 512GB Samsung SSD (black), and a 2TB Black Western Digital HD (silver/black).
Drivers are optimized to maximize GPU performance. If that means using a lot of CPU time, it will continue to do that to compete with other vendors (as the GPU architecture dictates). When the GPU architecture changes, and IF that CPU time is no longer needed, or only provides a marginal increase, or allows for partitioning of resources, then the drivers will change. Just that simple...
