ui lag in pathtrace

A forum where development builds are posted for testing by the community.
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
Post Reply
kuba
Licensed Customer
Posts: 15
Joined: Mon Jan 11, 2010 5:45 pm

Hi there,

Since MTL implementation has been abandoned I'm interested if the new improvments of the pathtrace mode also address the UI lag issue with one card setup. Also rendering hires images in pathtrace mode use to hance Octane to crash, is that going to be (or maybe already is) resolved in the upcoming release?

Cheers,
Kuba
User avatar
matej
Licensed Customer
Posts: 2083
Joined: Fri Jun 25, 2010 7:54 pm
Location: Slovenia

I doubt that pathtracing improvements will address lag issues with single cards.

Although in my experience pathtracing is more laggy than DL for the same scene / resolution. Which is kinda strange - I thought Octane uses all your GPU no matter what.
SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
User avatar
pixelrush
Licensed Customer
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

The lag issue occurs when asking one GPU to do both display duty and run the cuda code.
Running cuda code is a full on, intensive use of the card in itself.
Unfortunately with one card the processes disrupt each other and to complicate things Windows can time out waiting on the UI to update.
This wont be resolved by any change or addition to Octane code.
The user has a much better experience with another card for the UI and a grunt one doing the rendering. It doesnt need to be anything fancy at all - a GT240 or something.
Having a v large film does make the viewport considerably less responsive as well even with 4x4 subsampling enabled and a second card for the UI. Pathtracing is more demanding and therefore the navigation is less responsive than even the case of directlighting. This could be quite noticeable or a problem with using just one card, perhaps even the lag and the time out combining to end up with the Octane session hanging or crashing.
I would suggest something like a GTX460 for rendering would be the min performance level if you were wanting to do v large renders, along with the UI card, and also you should consider having 2 render cards.

Octane currently renders at 4kx4k max with 8kx8k due.
With pre2.3v4 4k is working fine with both PT and DL.
You are a customer so its available for you to use/try for yourself.
The only thing to be wary of is that 4k film takes up about 300mb of vram space in itself so if you are presently using a card with say 512mb vram that doesnt leave a lot of space for polys, textures or hdr. In fact I think its about 150mb cos cuda needs dome space for itself. This would be say 500k polys + some textures.
Something like a 9800GT/512mb on its own would be fairly frustrating if not futile esp with a v large render size.
HTH
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
User avatar
Nostromo
Posts: 261
Joined: Thu Feb 18, 2010 5:13 pm
Location: Brussels
Contact:

for the sake of exactness pre_23v4 allows up to 8kx8k. there's not preset but you can up it manually :)

/M
User avatar
pixelrush
Licensed Customer
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

:shock: woot! you guys shouldnt keep secrets ;)

have to try this out... :geek:

7937x5612 = full coverage of A1@240dpi = 853mb film size

6614x4677 = full coverage of A1@200dpi = 597mb

7015x4960 = full coverage of A0@150dpi or A2@300dpi = 668mb

max size of 8192x8192 = 693mm x 693mm @300dpi = ~1300mb?? (too big for my card)

7200x7200 = 8'x8' billboard @75dpi ~ 1000mb


Changing the custom size later even by one px crashes here - probably related to vram space.
Seems to need space of old film + new film?
People doing these either need to pick the right size to begin with or make sure there is enough empty space for the change
Small note that when you dble click to type into the size field of the Custom size the lettering is black on v dark grey and v .hard to read. It would be better to use white on grey as elsewhere

A1 @ 240dpi of the chess set made a 57mb png. I was pleased to be able to open this in Windows Photo Viewer see it 'actual' size and pan around. Be nice to have a screen 2.1m x 1.5m for it :D

Navigation in the viewport with the chess set @A1/240 was *very* slow even at 4x4 subsampling using direct lighting with my GTS250 ie *just* useable. Pathtracing wouldnt be.
Possibly we need an 8x8 too? or a special v large mode - more like grab, drag and drop (with an image blackout during the drag) than continuous movement?? The GTS250 is far too wimpy for this but I think even for a single GTX460 4x4 would lag too much. Definitely need the power of a 480 or two for res this size atm.

Just for posterity a 3gb vram card would be handy:
6m polys (1120mb) + A1@240dpi (855mb) + textures space/hdr background (700mb) + reserve space (385mb) = ~3gb
An extra 1.5gb wouldnt hurt though if there was such a thing as a 4.5gb card :)
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
User avatar
pixelrush
Licensed Customer
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

I've been playing with this today with a scene of 350,000 tris, changing materials properties and camera view etc.
Even @ 5000x3500 with a GTS 250 its just too slow to be useful. It needs something about 10x faster not to be frustrating I think. Its taking 10-15s each step to pick a mat, update the colour picker and again to refresh the view.
Pathtracing with texture environment floattex was running pretty slow at about 75s/p/hr on the 250 so thats 54hrs to render to 4000s/p or 6hrs with 2xGTX480 :roll:
The best strategy I think would be to set up your scene at say 1000x700 where everything is zippy and then when you are ready switch to the big res final (with the initial zoom set to match the 1000x700 as per my previous suggestion) and just leave it to render.
I have wondered if the viewport was set to only update every 5-10s for v large res whether it would help performance? Perhaps a user setting/slider 5-500s??
If the UI settings only updated every say 5-10 secs as well in 'big mode' then you could also make several changes if you had to without it prompting continuous refreshes...it would still be fairly immediate but not disruptive. Of course if its going to render for 6 hrs you dont want to touch it once its been going for 2 hours already...
Should it autosave every 30 mins for safety?
dunno ...just giving some feedback :)

Octane certainly can render these images but perhaps the UI and user strategy should be slightly different from a practical viewpoint. :geek:
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
User avatar
pixelrush
Licensed Customer
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

Actually...I think there is something rather odd about the scene I was using that made it run extra slowly...its slow even at a small size. Might be a bug hidden in there. :o
Will check it out :ugeek:

Edit: well I removed quite a few doubles and some stray verts and edges in Blender and it seemed to help but its still running slow at about 60s/hr now @7000x5000 with sun and direct... :roll:
With pathtracing its about 30s/hr... :cry:

Dunno why will have to come back to this tomorrow.
My new 460/2gb also comes tomorrow I hope ;)
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
Post Reply

Return to “Development Build Releases”