Possible solution to OpenCL problems

Can't figure out how to solve an issue? Here is where to ask for help.
User avatar
s1rmunchalot
Posts: 8
Joined: Wed Nov 23, 2016 2:43 am
Location: UK

Possible solution to OpenCL problems

Postby s1rmunchalot » Wed Nov 23, 2016 3:28 am

Hi All!!

Bought this neat little program yesterday from Renderosity and couldn't wait to get started!!

"Works on any GPU/CPU... 21 times faster!!" Well you can imagine.. With a tidy little discount coupon, I was in! :lol:
Reality plugin® version 4.3.1.16203
LuxRender version 1.6.0 Build 16132

Opened it up and thought, hmm.. doesn't look too daunting. Selected the OpenCl GPU/CPU's it told me it had found. Clicked "Render Frame" with baited breath. Oh dear.. nothing but a little warning in the error log. ....'expected 3 got 2'.. sound familiar? It seems a few have this problem. I read a few posts in here and decided to go and look around for myself. It occurred the problem might be with Lux, but I checked my OpenCL capability anyway here:
https://developer.nvidia.com/opencl - All fine, working well.

I then went here: http://www.luxrender.net/wiki/GPU#Nvidia - where I found this little tidbit of info:

Q: LuxRender's log does not show my GPU as being found, even though I have a supported card
A: By default, LuxRender will target OpenCL platform "0". While this is probably the platform that contains your graphics card, it may not be. You can try increasing the OpenCL Platform setting in the exporter/scene file by 1 until the graphics card is used.

I figured that the exporter/scene file was the "reality_scene.lxs" - and sure enough I found that there appeared to be an error in the device enumerator setting here:
"opencl.devices.select = 11" - Looks like a typo made in the output code. Should be a 3 figure number. ( ..'expected 3 got 2'.. )

I first tried "opencl.devices.select = 001" -AND IT WORKED!!!! It started to render the scene.. but damn.. with only 1 thread.. still fast and pretty though.

I then tried "opencl.devices.select = 011" -AND IT WORKED!!!! - This time with 2 threads and twice as fast.. just as pretty.

Since I have an i7-4770K @3.5Ghz, 32 GB RAM, and a MSI GTX 780 Ti (Windows 10 and 2x 40" monitors) I'm used to reasonably fast speeds rendering on simple scenes in DAZ3D I was hoping that Reality could make use of it all... Hopefully the wizards in the back room will find my info helpful. Since the problem is being reported by several users with a variety of hardware, it seems very unlikely to be a driver problem, especially when you consider my experience above.

In the meantime perhaps some of you brave chaps could have a go at editing your scene file and checking the results?
Make a copy and save the original.

Open your scene file in notepad find "opencl.devices.select = xx" and change it to a 3 figure number incrementing by 1 at a time. Note - exporting from Reality will just export the same problem again.

Start Lux by running "luxrender.exe" (probably in "C:\Program Files\Reality_DS\lux" ) and open your edited scene file.

Hope it works for you too.

I look forward to chatting in the future... and picking your brains.

[Edit] - More info - Only '0' and '1' seem acceptable values. With '011' Lux says 2 threads, but all CPU cores are maxed, but only about 1/3 of available memory used. It is just a single character and few lights. Choosing CPU-Accelerated, even with boost, it is reeeeaaallllyyy slow and the output is bad. It takes ages for big blocks to appear, then it starts again with big blocks lighter saying 'Tone mapping'. I stopped it after 2.5 hrs and went looking for answers.
Setting '111' didn't work.

[Edit] setting OpenCL Rendering and selecting Graphics card produces '"opencl.devices.select = 10" Lux won't run - Changed to '010' Lux render runs and all CPU cores maxed. Graphic card idling. Lux reports 1 thread.

The only working choices seem to be:
001 GPU only
010 CPU's only.
011 GPU and CPU.

It seems clear the compiler for the last build of Reality had a typo and missed the first '0'. Going to sleep now, have been at this for 10 hrs.
I'm not a complete idiot.......... Some parts are definitely missing.

User avatar
sigstan
Posts: 437
Joined: Sat Jan 24, 2015 3:59 pm
Location: Denmark

Re: Possible solution to OpenCL problems

Postby sigstan » Wed Nov 23, 2016 2:46 pm

What is listed in the OpenCL devices block of the Reality Scene Configuration tab? - Note that screen shot would be nice :)

If OpenCl has detected an on-board GPU (which many motherboards have), then that would be the third device. Often on-board GPUs will not work in the OpenCL setup, so disabling them in BIOS is usually the best option.

You can find more information about setting up your system for OpenCL in the Reality Rendering Options guide ():

If you run CPU accelerated, then I believe your i7-4770K should result in a total of 8 threads (4 cores * 2) being listed in Luxrender stats. try the CPU non-accelerated mode for confirmation of number of threads. In OpenCL mode make sure you have installed Intel OpenCL drivers (see previous mentioned guide).
/Sigstan

User avatar
Fram1963
Posts: 229
Joined: Tue Mar 01, 2016 1:52 pm
Location: Ottawa, Ontario, Canada

Re: Possible solution to OpenCL problems

Postby Fram1963 » Wed Nov 23, 2016 3:05 pm

@s1rmunchalot

I just recently upgraded my video card and had the same error message ...'expected 3 got 2'... I remembered from another post way back that multi-monitor setting in BIOS / UEFI can cause this error. In my case, I have an ASRock motherboard with UEFI. I entered the UEFI and found the setting under 'North Bridge Configuration'. I set the "IGPU Multi-monitor' to 'Disabled' and that solved the error for me.

Hope this might help your dilemna,

Cheers,
Lyne
:D

User avatar
s1rmunchalot
Posts: 8
Joined: Wed Nov 23, 2016 2:43 am
Location: UK

Re: Possible solution to OpenCL problems

Postby s1rmunchalot » Wed Nov 23, 2016 8:00 pm

Thanks for the replies guys. i must admit you have me a bit confused. I did say that LuxRender worked perfectly once a '0' was put into the text of the Reality scene file. How would that suggest missing/bad drivers or motherboard settings?

Others are reporting that Reality has 'suddenly' stopped working. Again, why would that be a driver or settings issue? It suggests that either Lux or Reality have released a new version and now there is a syntax mis-match.

It works perfectly with an added zero in the scene file. Those having problems have likely either just purchased, or just updated.

Reality tells me my CPU and GPU both have OpenCL versions 1.2
I'm not a complete idiot.......... Some parts are definitely missing.

User avatar
s1rmunchalot
Posts: 8
Joined: Wed Nov 23, 2016 2:43 am
Location: UK

Re: Possible solution to OpenCL problems

Postby s1rmunchalot » Wed Nov 23, 2016 11:07 pm

Ok. I've gone through the process again.. this time taking screenshots to illustrate at each stage.



Loading Reality and changing settings. http://i.imgur.com/fvHzXsd.png

LuxRender launching. http://i.imgur.com/aWJwigT.png

LuxRender aborts with the following message: http://i.imgur.com/okzbCUy.png

Reloading the scene file unedited into LuxRender gives the following message: http://i.imgur.com/DAlaXH3.png
(Very nice of the Luxrender dev's to give such helpful error advice coding.. eh?)

Finding the scene file output by Reality referred to by LuxRenders' first error message. http://i.imgur.com/DIZq7Kf.png

Checking the syntax of the scene file: http://i.imgur.com/V0FYGle.png

Manually editing the scene file: http://i.imgur.com/dTKBymb.png

Saved and closed: http://i.imgur.com/tadOz3l.png


Opening the edited scene file in LuxRender: http://i.imgur.com/IEdlMaG.png

No error message. Render begins. http://i.imgur.com/mqI0K0v.png

Checking resource usage. CPU and GPU at full capacity. No problem with drivers. No problem with settings. Just works. http://i.imgur.com/KNnopcR.png

confirming LuxRender build. http://i.imgur.com/j7bpoN1.png

Reality and LuxRender closed.



Reality re-launched and new setting applied. CPU only selected. http://i.imgur.com/kIi5r0j.png

LuxRender response 'Loading aborted'. http://i.imgur.com/LXGUzP8.png

Checking output syntax in scene file: http://i.imgur.com/919Lyok.png

Scene file manually edited. http://i.imgur.com/yv2cs6O.png

LuxRender loading with no errors: http://i.imgur.com/8QkkbYy.png

Render begins: http://i.imgur.com/gMId4fC.png

Checking resource usage. CPU's at full. GPU idling. http://i.imgur.com/QUCUgpV.png

LuxRender and Reality closed again.



Re-launced Reality and changed settings. GPU only selected. http://i.imgur.com/cv3Wmzz.png

Checking Reality output scene file syntax. http://i.imgur.com/Oi7Hv12.png

LuxRender error message: http://i.imgur.com/fk2IGoz.png

Manual edit of scene file: http://i.imgur.com/pSwevrD.png

Reloading LuxRender with edited scene file. No errors. http://i.imgur.com/9MqNVNc.png

Render begins on GPU only. http://i.imgur.com/Xezdg2Z.png

Checking resources to confirm. http://i.imgur.com/OTHhavS.png



As I stated in my original comment above I did read the log files for Reality (attached), they contain no information that is relevant or helpful since in my first post I did say that LuxRender worked perfectly once it had the proper syntax applied

Before even buying Reality I had read all the information on the website and watched all the Youtube videos. Nice music by the way. Paolo has a pleasant voice it was no hardship.

I knew that I had just updated my NVidia drivers that day, but since I use OpenCL for another applications (GIMP, ImageMagick, FFMpeg and Blender) I already knew it was working on my set up. However to demonstrate it once I detected the problem I did visit the OpenCL page at Nvidia and downloaded and ran the SDK inclusions to check it was working. As I said above. it was fine.

Finding no solution there I simply followed the advice of the LuxRender log and went to find the syntax it was having a problem with, by opening the scene file in notepad. It was obvious from the moment I opened it. I edited the scene file and it ran.. perfectly.

I then came to these forums. Read all the posts on OpenCl errors. Noted that the standard 'check your drivers', 'check your settings', 'read all these threads and PDF's' did not seem to resolve anyones' issue. Because I had managed to get LuxRender to run using the scene file once edited I decided to post the information in the hope that it would help others and let those doing the coding of Reality know that a syntax error was occurring in the output scene file. Since it runs perfectly once the Zero is added I highly doubt that it is a hardware or driver issue. Hopefully the pictures and log files can help strengthen the case. To be sure it would take a few of those having the same problem to recreate my steps above to check if it works for them, and report back.
Attachments
RealityInstaller_Log.txt
(146.02 KiB) Downloaded 253 times
Reality_plugin_Log.txt
(51.22 KiB) Downloaded 231 times

rattletat
Posts: 57
Joined: Wed Mar 02, 2016 5:54 am

Re: Possible solution to OpenCL problems

Postby rattletat » Thu Nov 24, 2016 7:15 am

Welcome to the wonderful world of Reality, I love the music that plays in the background too haha.

I remember having this OpenCL 001/010 etc problem with my AMD card too. But that was a while ago.

User avatar
s1rmunchalot
Posts: 8
Joined: Wed Nov 23, 2016 2:43 am
Location: UK

Re: Possible solution to OpenCL problems

Postby s1rmunchalot » Thu Nov 24, 2016 8:23 am

Thanks for the welcome @rattletat.

Do you remember how the syntax problem was solved? I can't see any other way than a bug fix release.
I'm not a complete idiot.......... Some parts are definitely missing.

User avatar
sigstan
Posts: 437
Joined: Sat Jan 24, 2015 3:59 pm
Location: Denmark

Re: Possible solution to OpenCL problems

Postby sigstan » Thu Nov 24, 2016 2:42 pm

Hey, I just asked for a single screenshot of the Reality Scene Configuration tab, which usually means a lot less questions asked :)

What I can see is that Reality has found two OpenCL devices (your CPU and GPU) and if both are selected (ticked) this will result in:
"opencl.devices.select = 11"

Each "1" represents a OpenCL device, which means both OpenCL devices are turned on.

I have a similar set-up to yours (Intel CPUs + GTX 970) and when using OpenCL a line with "opencl.devices.select = 11" is written into the *.lxs file. This works fine and no error is reported by Luxrender. So Reality syntax is fine (one flag per device).

What happens sometimes, is that Luxrender detect more devices than Reality. In your case Luxrender have detected 3 OpenCL devices (three flags). This could be an on-board GPU or something else. Preventing Luxrender from seeing this third device by disabling it or similar (assuming you don't use it) will fix the issue, so if you want to avoid manual edits that is the cure.

If you run Luxrender with log level Debug (see Reality's Renderer tab), then you can actually see what Luxrender finds. In the Luxrender log tab, there should be entries in the beginning similar to this:
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.906] OpenCL Platform 0: NVIDIA Corporation
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] OpenCL Platform 1: Intel(R) Corporation

[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 0 name: NativeThread
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 0 type: NATIVE_THREAD
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 0 compute units: 1
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 0 preferred float vector width: 4
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 0 max allocable memory: 0MBytes
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 0 max allocable memory block size: 0MBytes
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 1 name: GeForce GTX 970
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 1 type: OPENCL_GPU
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 1 compute units: 13
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 1 preferred float vector width: 1
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 1 max allocable memory: 4096MBytes
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 1 max allocable memory block size: 1024MBytes
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 2 name: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 2 type: OPENCL_CPU
[2016-11-24 19:57:17 Debug: 0] [LuxRays][0.922] Device 2 compute units: 24

You could argue that Reality seems to be missing OpenCL devices, but in almost all cases I have seen, it is devices that will not work in OpenCL anyway. Luxrender does not seem to be very discriminating when detecting devices, so therefore I do not expect that Paolo will be inclined to change Reality in this area, because it will lead to even more issues.

Hope this clarifies your issue and our responses.
/Sigstan

User avatar
s1rmunchalot
Posts: 8
Joined: Wed Nov 23, 2016 2:43 am
Location: UK

Re: Possible solution to OpenCL problems

Postby s1rmunchalot » Thu Nov 24, 2016 8:42 pm

Hi @Sigstan. Thank you for the reply. I certainly do note that you are trying to help and I appreciate that.

I have been looking on the LuxRender website and catching up with all the info I could find there. I note that Mr Paolo Ciccone is active in the development of LuxRender. I downloaded and ran LuxMark 3.1 and found as I suspected, and you correctly assumed, that I have 3 OpenCL capable devices, all running OpenCL 1.2.

http://i.imgur.com/HIB4J6V.png

I tested each individually and in combination on the most complex scene and they all worked. I was actually quite impressed by what the 'little' on-board GPU achieved by itself :)

I'm surprised that a knowledgeable chap such as you appear to be wouldn't simply advise someone to go and get LuxMark.. run it.. and confirm their system capabilities, rather than advising to chase around for drivers, motherboard settings etc. Indeed why not sticky such advice at the very top of the forums?

Questions:
1. Why would someone who is intimately aware of how LuxRender works disable selection of an OpenCL device, and then not take account of that deselection in the output syntax to avoid the presumably possible 'expected' error?

2. Why not include all OpenCL capable devices in the Reality selection window and give advice on which to use, letting the user decide?

3. If this is a known problem, and it certainly appears to be so, then why is there no advice regarding it in the documentation, or a sticky on the forums, or something to explain what is happening, and why? What the reasoning behind the choices were? Having read the documentation and seen Mr Ciccones Youtube videos, part of the attraction was that he seemed very in tune with what 'new users' would need in the way of information and help. I have now spent a good proportion of 2 days looking for a viable answer to this problem. Surely he would not consider this a satisfactory experience of his work? He seems far too nice and helpful a guy to not care.

4. Again, if it is a known problem, why is there no advice for work-arounds? To simply suggest that someone 'disable' part of their system to accommodate what could presumably be achieved in the coding seems to me, not the most satisfactory approach.

5. If I persevere and resign myself to manually editing the scene file, does this mean that I lose the ability to make changes on the fly?

6. If the LuxRender development team are aware of device selection issues why do they not include a device selection option in the LuxRender GUI as they have in LuxMark? This seems a very odd choice to me. The scene file can then be coded to open LuxRender in paused mode awaiting device selection.. no?

I am hoping there is a simple, less draconanian answer out there than ..'disable your hardware to make allowance for one missing character from a text file' which will make all the above questions moot. My suspicion (and hope) is that there is.

In my case I wouldn't want to disable the Intel 4600 because it is part of my multi-monitor setup which works very well for all the other products and services that I use. As it stands now, I would prefer to manually edit the scene file rather than change my hardware configuration. I do note that Reality.exe comes with an associated config file. 'RealityConfig.txt'. Is there anywhere I can find information on whether that would be a possible route to explore?

I came looking for an alternative to IRay via DAZ3D mostly because of the option to render outside DAZ and the ability to change settings on the fly without DAZ freezing up for periods. That Reality offered a speed boost by using all available hardware didn't really occur as a major advantage since DAZ can use both CPU and GPU and I only do it for fun... not work. If Reality is faster, as it seems to be, then great, but the main aim was to simplify what I was doing, not complicate things. In my defense I would point out that I did figure out what the problem was, and a workaround, even though I'm just a simple retired Registered Nurse pursuing a hobby.
I'm not a complete idiot.......... Some parts are definitely missing.

User avatar
sigstan
Posts: 437
Joined: Sat Jan 24, 2015 3:59 pm
Location: Denmark

Re: Possible solution to OpenCL problems

Postby sigstan » Fri Nov 25, 2016 3:21 am

Well, I'm hardly all knowable :)

It has been a long time since I used Luxmark and I don't recall it listing the devices like that. But thank you for pointing it out. That is indeed valuable information. As I said in my previous post, the same information could probably also be taken from the debug log. Regarding drivers etc. that has in my experience historically accounted for more than 75% of the OpenCL issues, so it will eliminate a lot. Often there is simply not enough information in the first posts to make an informed answer, hence the requests for screen shots. Regarding stickies, these are done by Paolo and his team..

Answer 1)
Because a lot of people don't actually use the on-board GPU and therefore it is often a quite acceptable solution. It is also currently the only solution that I know of. I believe Paolo is aware of the problem, but I have no information about what plans (if any) he has in this area.
Out of curiosity what does Luxrender do, if you enable all 3 devices in your manual edit ?

Answer 2)
I'll leave this one for Paolo to answer :)

Answer 3)
A lot of this knowledge is only available in these forums, and since we moved some time ago from RDNA, it is not even the entire body of knowledge you can find here. A lot is still found only in the RDNA Reality forum archives. These are still online at RDNA, but probably only until the end of the year. Paolo has hinted that he might restore the archives here at some point. The rest of the question I'll leave for Paolo to answer.

Answer 4)
Partly answered in 1, but a valid question that I have no answer for.

Answer 5)
You can change on the fly in Luxrender. If you change anything in Reality, then you will have to export and make your edit again.

Answer 6)
I don't know. It is probably better to raise this in the Luxrender forum.
/Sigstan


Return to “Troubleshooting”

Who is online

Users browsing this forum: No registered users and 4 guests