OTOY Forums

Thanks for the update Goldorak. We appreciate getting some info.

Goldorak wrote:

milanm wrote:@Goldorak

Thank you for the info. Just to clarify because i think some users here got the wrong impression, AMD drivers are not holding down development of other features and the rest of 3.1, right?

Regards
Milan

Correct - the currently working AMD build we showed in the spring was cross compiled from a snapshot of the 3.0 source code (by the Brigade devs), and this didn't take any time away from Octane development.

At some point that would change for final release, as there is work to be done to tune and optimize the AMD branch for performance, just as we did recently for Pascal. That would take dev time away from features, but we are pushing that off until AMD drivers are fixed. They promised this would be done in two months and it is now past that point, so we are moving onto other parts of the 3.x roadmap for now.

i think AMD drivers will never be fixed. lol

coilbook wrote:

Goldorak wrote:

milanm wrote:@Goldorak

Thank you for the info. Just to clarify because i think some users here got the wrong impression, AMD drivers are not holding down development of other features and the rest of 3.1, right?

Regards
Milan

Correct - the currently working AMD build we showed in the spring was cross compiled from a snapshot of the 3.0 source code (by the Brigade devs), and this didn't take any time away from Octane development.

At some point that would change for final release, as there is work to be done to tune and optimize the AMD branch for performance, just as we did recently for Pascal. That would take dev time away from features, but we are pushing that off until AMD drivers are fixed. They promised this would be done in two months and it is now past that point, so we are moving onto other parts of the 3.x roadmap for now.

i think AMD drivers will never be fixed. lol

I think they have to, and they know it, which is why they agreed to fix it. Otherwise, they are by default ceding the high end commercial GPGPU market to NVIDI. OpenCL 2 doesn't exists (Linux and MacOS are still on 1.2, and apple is only support Metal, so even 1.2 is not a sure thing in the future). We did all this crazy work to cross compile CUDA to AMD IL. We had AMD Octane 3 running at a demo machine at siggraph and would have done a first test release around them if they had addressed this when they were supposed to.

In any case at least headless rendering will bring some relief to fustated Mac users. We can still use the local GPU for OctaneImager or the host app raserized viewport.

Goldorak wrote:
I think they have to, and they know it, which is why they agreed to fix it. Otherwise, they are by default ceding the high end commercial GPGPU market to NVIDI. OpenCL 2 doesn't exists (Linux and MacOS are still on 1.2, and apple is only support Metal, so even 1.2 is not a sure thing in the future). We did all this crazy work to cross compile CUDA to AMD IL. We had AMD Octane 3 running at a demo machine at siggraph and would have done a first test release around them if they had addressed this when they were supposed to.

In any case at least headless rendering will bring some relief to fustated Mac users. We can still use the local GPU for OctaneImager or the host app raserized viewport.

Thank you Goldorak on dev update, do you have some more informations about OctaneImager? Maybe something about release date, is it related to OSL or 3.1?

Goldorak wrote:In any case at least headless rendering will bring some relief to fustated Mac users. We can still use the local GPU for OctaneImager or the host app raserized viewport.

Could you elaborate in more detail on how Headless rendering would work? Isn't that the same thing as network rendering, and which requires a second Octane license?

Very good info Goldorak, thank you for your time to explain us all that.

Looking forward to RenderSlave system (Headless version as you call it) and Adaptive sampling.
As for more Pascal optimizations, is that released yet (my current plugin version is 3.0.5.0) or still in progress to be released soon ?

Thanks

Lewis wrote:Very good info Goldorak, thank you for your time to explain us all that.

Looking forward to RenderSlave system (Headless version as you call it) and Adaptive sampling.
As for more Pascal optimizations, is that released yet (my current plugin version is 3.0.5.0) or still in progress to be released soon ?

Thanks

Last I checked Pascal work is looking like it may be wrapping up in 3.06 which is not too far off. If that goes as planned then a new OctaneBench based on 3.06 will go out as well.

Headless rendering is a high priority feature, as is adaptive sampling, and we'd like to get both out as soon as we can (even before OSL if they are done sooner). Due to changes in the rendering framework needed to implement HR across all plug-ins (not just blender and Max/Maya as we originally planned earlier in 3.x), doing adaptive sampling following the completion of solid HR is what makes the most sense on the roadmap.

pegot wrote:

Goldorak wrote:In any case at least headless rendering will bring some relief to fustated Mac users. We can still use the local GPU for OctaneImager or the host app raserized viewport.

Could you elaborate in more detail on how Headless rendering would work? Isn't that the same thing as network rendering, and which requires a second Octane license?

Good question. If you are not using any local GPUs, then in all fairness pure headless rendering should not require a full second standlone license on Mac, where users have no other good options right now. There is a bunch of technical backend work in the SSO system we will need to do to get this going once it is out of beta.

In any case, we are also exploring inexpensive slave only licenses via subscriptions or bundles you can tack on to your existing master license, assuming you would be OK locking the slave to your master node SSO account (e.g. as if it were attached exclusively to the computer and not used as a master node itself).

.. yeah I just realised that network rendering is far worse then local, works, but very laggy, so instead of building another pc, it's better to buy extenders, and you'd have cheaper licencing as well..

- and it should have been made inexpensive for that reason alone..