why no graphics/screensaver for v7 7.03 (opencl_intel_gpu_sah) files?

Message boards : Number crunching : why no graphics/screensaver for v7 7.03 (opencl_intel_gpu_sah) files?
Message board moderation

To post messages, you must log in.

AuthorMessage
BJM

Send message
Joined: 5 Nov 14
Posts: 1
Credit: 104,788
RAC: 0
United States
Message 1599088 - Posted: 9 Nov 2014, 20:53:27 UTC

Why do these particular files NOT have graphics or screensaver to show while they are processing? All the other SETI tasks other than this (that I have seen so far) have them.
ID: 1599088 · Report as offensive
Profile arkayn
Volunteer tester
Avatar

Send message
Joined: 14 May 99
Posts: 4438
Credit: 55,006,323
RAC: 0
United States
Message 1599121 - Posted: 9 Nov 2014, 22:10:22 UTC - in response to Message 1599088.  

Why do these particular files NOT have graphics or screensaver to show while they are processing? All the other SETI tasks other than this (that I have seen so far) have them.


Because they are already using your GPU to process the work, showing the screensaver would slow down the processing on the GPU.

ID: 1599121 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1599339 - Posted: 10 Nov 2014, 8:11:48 UTC - in response to Message 1599121.  
Last modified: 10 Nov 2014, 8:12:40 UTC

Other than claims on these forums (and for the moment still in my BOINC FAQs - but those are being rewritten) there is no one out there who says that running 2D or 3D graphics together with CUDA and OpenCL slows down the calculations being done.

When looking at the CUDA page at Nvidia, they have a lot of applications that use CUDA to do all kinds of things, including Folding@Home which does the calculations plus real time rendering output of what it is being calculating. Nvidia even has some CUDA screen savers.

Then there's this thing where people here run stock applications on their CPU, which do have the graphics application and they run the screen saver with that, while then doing work on their GPU without that work slowing down too much. Since BOINC is still set by default to only use the processors available when the system is idle, I don't see why a project would mind if their work came in a bit later when people also used a screen saver. Added to that, it does not explain why an application running on the stock GPU doesn't have the graphics app. One won't be forced to run with the graphics or screen saver, but if one wants to one should be able to.

On an optimized application you might not want a screen saver because of the credit hunger. But on the stock application it should just be available.
Otherwise, also tell people not to use their system when they run work, for rendering the desktop and anything that is being done on it will then slow down the processing. If you're worried about a couple of polygons in OpenGL taking up some cycles, you should be extremely worried about DirectX 3D rendering a full Aero desktop while moving around full open windows.
ID: 1599339 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1599359 - Posted: 10 Nov 2014, 9:20:22 UTC

I asked why the original CUDA apps didn't come with a graphics app, and here's what David answered me:
At one point the main app updated the shared-mem structures used by the graphics app even if no graphics app is running. This imposed a small but significant overhead.
I believe this is fixed, and it should be possible to release a version that includes a graphics app without impacting performance if the graphics app doesn't run.

ID: 1599359 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1599361 - Posted: 10 Nov 2014, 9:48:16 UTC - in response to Message 1599359.  

I asked why the original CUDA apps didn't come with a graphics app, and here's what David answered me:
At one point the main app updated the shared-mem structures used by the graphics app even if no graphics app is running. This imposed a small but significant overhead.
I believe this is fixed, and it should be possible to release a version that includes a graphics app without impacting performance if the graphics app doesn't run.

That makes a lot of sense.

It also has to be remembered that the SETI@Home project itself has never had sufficient staff resources to develop any GPU application in-house. The very first GPU applications (CUDA multibeam for Windows) were developed by NVidia staff and students, and were donated to SETI as - presumably - a technology demonstrator.

Nvidia maintained their application for ~18 months, but haven't contributed any new version since 2010. ATI never provided a SETI application for the project, and none of the industry players ever supported SETI with Astropulse applications or applications for any platform except Windows.

So, all the GPU applications you see running on SETI have been contributed by volunteers external to the core SETI team. Those volunteers cut their teeth in the various optimisation exercises, and one of the very first optimisations they did (even before GPUs were first used) was to cut out or disable that shared memory overhead that David mentions. In the specific case of GPUs, transferring data back from a separate graphics card into the shared segment of main memory, so that it can be processed by the separate graphics application (which ironically runs on the CPU only) and sending it back to the GPU for display is a known bottleneck in current PC designs.

So the main reason for no screensavers being available in the GPU applications is that they would take significant development effort to produce in any efficient form, and the priority for the developers concerned has been to focus on the primary search for ET.
ID: 1599361 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1599386 - Posted: 10 Nov 2014, 11:17:28 UTC - in response to Message 1599361.  

So the main reason for no screensavers being available in the GPU applications is that they would take significant development effort to produce in any efficient form, and the priority for the developers concerned has been to focus on the primary search for ET.

Development effort on code that's already freely available in the source code? Seeing how the stock CPU apps have the graphics application (and thus screen saver), and that these apps have the same source code as the GPU apps, that's a bold thing to state. Do you want to claim next it's difficult to add? :P
ID: 1599386 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1599387 - Posted: 10 Nov 2014, 11:25:29 UTC - in response to Message 1599386.  

So the main reason for no screensavers being available in the GPU applications is that they would take significant development effort to produce in any efficient form, and the priority for the developers concerned has been to focus on the primary search for ET.

Development effort on code that's already freely available in the source code? Seeing how the stock CPU apps have the graphics application (and thus screen saver), and that these apps have the same source code as the GPU apps, that's a bold thing to state. Do you want to claim next it's difficult to add? :P

I think I'd better leave that question to Jason, Raistmer and Urs - now that they are the stock developers for SETI. I was just passing on what I've seen over the years.
ID: 1599387 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1599397 - Posted: 10 Nov 2014, 12:00:47 UTC

As Richard already stated to show something in screen saver that something should be copied into separate process address space.

1) I'm not aware about easy ways to share GPU device memory buffer between different processes. OpenCL - OpenGL interoperability may come into play, but it's separate field to study, not connected with computations at all. And definitely such interoperability (even if possible between 2 separate processes at all) has nothing to do with described (by cited link) on BOINC Graphics API page. Hence, as already was absolutely correctly stated, efficiently enough way to add graphics screen saver incorporates additional development efforts completely disconnected with main task.

2) BOINC Graphics API assumes data to show in system memory. Hence one need to bring that data to system memory (of another process need to add). To do so one needs to just copy corresponding data buffer (and form it first from real data buffers used in app) from one address space to another. Or, even not copy but just map it (system shared memory). Mapping is relatively cheap operation so main processing load on CPU is to get frame buffer from real data buffer (non-scientific load on CPU, can be big or not for particular apps).
That's how things are in CPU-based apps.
For GPU app the single way (on modern non-APU or non-HSA, discrete GPUs) to compute efficiently is to keep all data in device memory, not in system memory.
Hence, to present some data to screen saver one needs to bring some data from GPU device memory back to system memory, then to form frame buffer to show, then to pass/map it to another process address space and only then to use BOINC API to "simply show" buffer inside graphics app process( maybe BOINC API includes mapping too but this doesn't change the picture). Link between system memory and GPU is highly assymetrical. Even CPU-> GPU path slow enough comparing with CPU-CPU memory transfers. But GPU->CPU one even slower. Hence, to show something really interesting connected with calculations done by app and not just static picture inside screen saver one should considerably hinder real processing (with "easy way to accomplish") or put additional efforts in developing adequate memory transfers overlapping with real computations, that again constitutes separate development effort not in slightest degree covered by provided BOINC Graphics API link.

Interesting in implementation - welcome to team. As was noted, sources are openly available.
ID: 1599397 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1599431 - Posted: 10 Nov 2014, 15:50:05 UTC - in response to Message 1599397.  

OpenCL - OpenGL interoperability may come into play, but it's separate field to study, not connected with computations at all.

OpenCL uses the same hardware device components as OpenGL, it's just a different language for programming. So there will be a small hit on the calculation speed of the GPU when it also shows graphics. But then that's up to the user to decide if he minds that or not.

CUDA and OpenGL can interact with each other. An example of that: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch31.html (take a night off to read that, it doesn't read easily).
ID: 1599431 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1599437 - Posted: 10 Nov 2014, 16:09:27 UTC

I had an idea after the conversation this morning - why don't I ask Jord (who probably knows more BOINC projects than the rest of us put together) if there are any other projects which have a screensaver associated with a GPU application? And then I had a better idea - why don't I do my own research before asking a silly question?

It turns out that the very first project I looked at fills the bill. Einstein@Home has graphics available for both the GPU applications I run. Although I don't have the BOINC screensaver enabled, I'm pretty sure that the graphics application you can invoke via BOINC Manager is the same engine as drives the screensaver.

I can view graphics from an OpenCL application running on an Intel GPU (matching the question which opened this thread), from a CUDA application running on an NVidia card, and I can view the iGPU graphics on a monitor connected to an NVidia graphics card - so it's all device-independent.

I don't know exactly how it's been implemented (there may be some clues buried deep in Write your own Einstein@home screensaver), but the Einstein code is open-source, so it can be examined for clues and borrowed as a framework.

So, the technical hurdles can be overcome (which isn't to say it would be easy). The remaining questions are resourcing (Einstein is certainly better placed than most projects to supply the programming effort required) and priority: I didn't measure the reduction in productivity while the Einstein graphics are displayed, but there will undoubtedly be some trade-off between science and eye-candy, and the current set of SETI GPU developers have always given priority to the science.

I did have a quick click through the other applications I'm running, and none of the others supply a graphics app, whether the science runs on CPU or GPU.
ID: 1599437 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1599553 - Posted: 10 Nov 2014, 21:16:24 UTC - in response to Message 1599431.  

OpenCL - OpenGL interoperability may come into play, but it's separate field to study, not connected with computations at all.

OpenCL uses the same hardware device components as OpenGL, it's just a different language for programming.


It was not about hardware, it's about possibility to pass GPU memory buffer handle from OpenCL to OpenGL... running in another process adress space.
ID: 1599553 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1599565 - Posted: 10 Nov 2014, 21:55:00 UTC - in response to Message 1599437.  


I can view graphics from an OpenCL application running on an Intel GPU (matching the question which opened this thread), from a CUDA application running on an NVidia card, and I can view the iGPU graphics on a monitor connected to an NVidia graphics card - so it's all device-independent.

1)Does it show something depending on current dataset in progress?
2)What performance impact?
ID: 1599565 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 1599567 - Posted: 10 Nov 2014, 21:57:43 UTC - in response to Message 1599386.  

So the main reason for no screensavers being available in the GPU applications is that they would take significant development effort to produce in any efficient form, and the priority for the developers concerned has been to focus on the primary search for ET.

Development effort on code that's already freely available in the source code? Seeing how the stock CPU apps have the graphics application (and thus screen saver), and that these apps have the same source code as the GPU apps, that's a bold thing to state. Do you want to claim next it's difficult to add? :P

Raistmer has already pointed out the primary difficulty for GPU apps, to populate the data as shown by the SETI graphics displays would require transferring more data from the GPU back to CPU. Basically, the lower 3/5 of both SETI@home v7 and Astropulse graphics are showing data which is not now available to a graphics app written to BOINC's graphics api standard. One alternative would be a new graphics app written to use only information which is already available on CPU, such as progress and any signals found so far. That kind of approach would mean less volatility in the display, too.

Jord, the old tarball you referenced doesn't apply to the GPU applications, which are in subdirectories of branches/sah_v7_opt/. For the AKv8 subdirectory, building with BOINC_APP_GRAPHICS to support a graphics app may add code 66 different places. Each is probably small impact if the graphics aren't being shown, but in combination would probably have a noticeable effect. The added code hasn't been maintained, so can be expected to need fixing too.

More generally, perhaps the issue should be considered in terms of the relative importance of efficient crunching versus graphics. Suppose a project is planning a new release version and the developer has 4 weeks to work on it. That's a budget of 160 developer hours. How much of that time should be budgeted to ensuring graphics are also updated? That's a serious question, the answer depends on how many participants have been initially attracted to the project by seeing the graphics on someone else's screen, and how many would like to at least occasionally view the graphics. The answer may also be "none" on a basis like medical triage in emergency situations. IOW the developer may know in advance that the needed changes to the main application have to come first and only if that goes extremely well will there be any time available for the graphics app.

Note that the transition from SETI@home Enhanced to SETI@home v7 did not add any graphics display for the Autocorr search. I've not seen any complaints about that, perhaps those who like to watch the graphics are less interested in what the program is finding than the raw display of the output of the FFTs in the lower part. Anyhow, that meant minimal time needed to rebuild the graphics application and check that it worked. The transition from Astropulse v6 to Astropulse v7 has dropped the graphics app. Although one could be built to work with the generic non-SIMD CPU application, very nearly 100% of host systems capable of doing CPU AP tasks within deadline should be getting tasks for the sse or sse2 versions if BOINC's score based scheduling doesn't totally contradict common sense.
                                                                  Joe
ID: 1599567 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1599578 - Posted: 10 Nov 2014, 22:19:44 UTC - in response to Message 1599567.  

Note that the transition from SETI@home Enhanced to SETI@home v7 did not add any graphics display for the Autocorr search. I've not seen any complaints about that, perhaps those who like to watch the graphics are less interested in what the program is finding than the raw display of the output of the FFTs in the lower part.

Funny that, you're posting in a thread in which the OP asks why there is no screensaver/graphics for 7.03 on the Intel GPU. There are still plenty of people asking every now and then why they do have work but their screen saver is showing only BOINC images. It's not like they went away since v7 of everything was released.

Something comes to mind by the way, I see that the OP is specifically asking about the graphics/screen saver on an Intel GPU. These do tend to lose the bottom part of the graphics, because of what appears to be a problem with the OpenGL module in the drivers that Intel have released. Perhaps that that was his question and we've now totally gone off topic without answering him on that.
ID: 1599578 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1599580 - Posted: 10 Nov 2014, 22:24:13 UTC - in response to Message 1599578.  
Last modified: 10 Nov 2014, 22:24:33 UTC


Something comes to mind by the way, I see that the OP is specifically asking about the graphics/screen saver on an Intel GPU. These do tend to lose the bottom part of the graphics, because of what appears to be a problem with the OpenGL module in the drivers that Intel have released. Perhaps that that was his question and we've now totally gone off topic without answering him on that.


You missed this word in thread title: opencl_intel_gpu_sah
That means OpenCL iGPU MultiBeam app in question and we totally on topic explaining why graphics not implemented for such type of applications in whole and for this particular as example.
ID: 1599580 · Report as offensive
tbret
Volunteer tester
Avatar

Send message
Joined: 28 May 99
Posts: 3380
Credit: 296,162,071
RAC: 40
United States
Message 1599582 - Posted: 10 Nov 2014, 22:32:26 UTC - in response to Message 1599437.  
Last modified: 10 Nov 2014, 22:33:29 UTC



I didn't measure the reduction in productivity while the Einstein graphics are displayed, but there will undoubtedly be some trade-off between science and eye-candy, and the current set of SETI GPU developers have always given priority to the science.



I can't quantify it, Richard, but the answer is "not very much at all," and the amount of resources consumed is somewhat controlled by an option to set the screen saver resolution from the Preferences page.

And I quote:

Graphics setting: frames per second (FPS)
Warning: affects CPU consumption! Default value: 20

Graphics setting: render quality
Warning: requires hardware 3D acceleration! Default value: low

Graphics setting: window width (pixels)
Default value: 800

Graphics setting: window height (pixels)
Default value: 600

End Quote.

You could probably force it to consume significant resources, but the defaults really don't.
ID: 1599582 · Report as offensive

Message boards : Number crunching : why no graphics/screensaver for v7 7.03 (opencl_intel_gpu_sah) files?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.