Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cycles X

code.blender.org

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Cycles X

#131

Post by jollybean »

capableweb wrote: post #113
jollybean wrote: post #86

Earlier quoted context omitted.

Autodesk and Adobe have become a problem, the lack of competition and incumbency mean they are basically milking the same cow ad nauseam. To be a little bit fair - those systems are in fact very complex, and it is quite a big deal to do anything in them. But literally as I speak Photoshop will not go 'fullscreen' on my Mac, and Adobe blames this utterly ridiculous bug on Apple. Which may very well be the case but who…

> things are retrograding a little bit Sure thing, but it seems even you are acknowledging that this specific issue seems to belong to Apple rather than Autodesk, so you're saying things are retrograding in the Apple ecosystem here, not Autodesk. Disclaimer: I'm biased against Autodesk and love Blender, but even I see the fault in your argument here.

I said it may belong to Apple, not that it does, and frankly, I don't see this bug with any other software so really it seems iffy, moreover, Apple is still part of the 'old guard monopoly retrograde cash-cow' which is my point.

Re: Cycles X

#132

Post by weeboid »

All I know is, this better bypass the dumb AF "MAc OS can't use CUDA drivers with the discrete GPU"

Like, why tf did i buy the macbook pro with expensive discrete GPU and can't even use it to render GPU accelerated 3D. Seems like a primary use case

Re: Cycles X

#133

Post by nuclearsugar »

lattalayta wrote: post #38
ravenstine wrote: post #22

Earlier quoted context omitted.

I'm not in the field myself, though animation was my original career and I know people who work in feature animation. To answer your question, the field has been sloooowly diversifying in some ways, as you say with Unreal (particularly since Unreal's engine is fast and good for real-time previews), but I don't see a huge push for moving away from does-it-all packages like Maya or 3DS Max. The economic incentive isn't…

In my opinion, most of the 3D software and renderers are starting to align in their workflows and set up. If you've spent enough time in a 3D package and have your fundamentals down, then a reasonably experienced 3D artist could make something look good in Maya, Blender, Cinema 4D, UE4, 3ds Max, Modo, or slightly more specialized programs like Katana, Mari, Nuke, etc. Most of the "learning curve" is just finding out…

Every CGI toolset has its strengths and weaknesses depending on the project. Also while the knowledge transfers between each software, they each have their own unique implementations for just about everything. It's hell to learn a new CGI toolset.

For work and also hobby I create 3D animations and experiment with all sorts of things in Maya. A recent turning point was using Redshift to render everything and suddenly I can do overnight GPU renders at high quality. Here are some of my projects released using a CC license -

https://www.jasonfletcher.info/vjloops

Re: Cycles X

#134

Post by thomastjeffery »

random5634 wrote: post #118
thomastjeffery wrote: post #57

Earlier quoted context omitted.

> Blenders licensing is a deterrent. Very few people want to deal with GPL. I see this claim taken seriously all over the place, and I just don't get it. How in the world is the GPL actually an issue? The GPL does not apply to anything made with Blender; only changes made to Blender. You can very trivially use Blender without ever dealing with the GPL. Do studios really think they need to make changes/extensions to B…

Current version of GPL is an absolute no go, especially if you need to import an api / sdk style interface into your extensions and tooling - the GPL is viral. You import a GPL library to interface and your stuff is now GPl. and latest version requires release of encryption keys etc etc - all major studios WANT content protection to work and the GPL is explicit in its attacks on that

> all major studios WANT content protection to work and the GPL is explicit in its attacks on that

They want content protection on what? Their tooling? They want DRM on the plugins they write for the tools they use? How or why?

Re: Cycles X

#135

Post by random5634 »

thomastjeffery wrote: post #134
random5634 wrote: post #118

Earlier quoted context omitted.

Current version of GPL is an absolute no go, especially if you need to import an api / sdk style interface into your extensions and tooling - the GPL is viral. You import a GPL library to interface and your stuff is now GPl. and latest version requires release of encryption keys etc etc - all major studios WANT content protection to work and the GPL is explicit in its attacks on that

> all major studios WANT content protection to work and the GPL is explicit in its attacks on that They want content protection on what? Their tooling? They want DRM on the plugins they write for the tools they use? How or why?

If you import a GPL library into your plugin your plug-in / add on is now GPL. They don’t want that.

GPL has what is called anti-tivoisation / DRM. This license was designed to specifically target the entertainment industry.

Even Ubuntu had to get a different license for boot loader to avoid risks here

Re: Cycles X

#136

Post by thomastjeffery »

random5634 wrote: post #135
thomastjeffery wrote: post #134

Earlier quoted context omitted.

> all major studios WANT content protection to work and the GPL is explicit in its attacks on that They want content protection on what? Their tooling? They want DRM on the plugins they write for the tools they use? How or why?

If you import a GPL library into your plugin your plug-in / add on is now GPL. They don’t want that. GPL has what is called anti-tivoisation / DRM. This license was designed to specifically target the entertainment industry. Even Ubuntu had to get a different license for boot loader to avoid risks here

> They don’t want that.

Again: why? Because they have a grudge against the GPL's anti-DRM?

That's still FUD. There is nothing that a studio would be doing with Blender where they would want to implement DRM.

Sure, they will want DRM to be used in the distribution of the content they make with Blender; but that is totally separate from Blender itself and the GPL. It's not like the film itself will contain a copy of their asset creation or rendering pipeline!

Re: Cycles X

#137

Post by rguetzkow »

weeboid wrote: post #132

All I know is, this better bypass the dumb AF "MAc OS can't use CUDA drivers with the discrete GPU" Like, why tf did i buy the macbook pro with expensive discrete GPU and can't even use it to render GPU accelerated 3D. Seems like a primary use case

This isn't Blender's fault, Nvidia discontinued the development of the CUDA Toolkit for macOS. Version 10.2. was the last version released for macOS [0].

> CUDA 10.2 (Toolkit and NVIDIA driver) is the last release to support macOS for developing and running CUDA applications. Support for macOS will not be available starting with the next release of CUDA.

[0]: https://docs.nvidia.com/cuda/archive/10.2/cuda-toolkit-relea...

Re: Cycles X

#138

Post by RaisingSpear »

raphlinus wrote: post #125
RaisingSpear wrote: post #111

Earlier quoted context omitted.

Thanks! I guess I got confused with the information out there. Most examples seem to be using GLSL shaders for the kernel, but posts seem to indicate it uses SPIR-V as input [ https://community.khronos.org/t/is-a-vulkan-compute-shader-d... ]. And then you have threads like this [ https://community.amd.com/t5/drivers-software/amd-dropped-sp... ] saying that SPIR-V isn't supported on the AMD's Windows driver (I had sim…

There's a lot here, let me try to clarify a bit. Most of the time, when people say OpenCL, they mean that an OpenCL driver is provided by the GPU vendor. That's what's in a particularly sorry state. Many vendors ship OpenCL but have deprecated it. AMD's ROCm is based on OpenCL, but they don't support it on all cards and there are problems. The other thing that's picking up steam lately is using a lower level API such…

I see, thanks for explaining all that!

Re: Cycles X

#139

Post by RaisingSpear »

raphlinus wrote: post #124
RaisingSpear wrote: post #110

Earlier quoted context omitted.

Thanks. According to this post [ https://community.khronos.org/t/opencl-vs-vulkan-compute/713... ], Vulkan Compute seems to be mostly focused on rendering over general compute. This is probably fine for Blender's renderer, but may not be suitable for some compute loads. Unless something has changed since then, or the post is inaccurate?

That post is 4 years old. Since then, Vulkan compute has made enormous strides forward, while OpenCL has stagnated. Examples of the things Vulkan has now are subgroup size control, explicit float16 and int8, pointers (previously you had to fake them with arrays), and a memory model. The memory model alone is a pretty big advance. What is still a mess is the tool situation. You have to write your shaders in GLSL or HL…

I see, thanks. I presume the end-user running the application will need to have up-to-date drivers to take advantage of these changes in the past 4 years?

Re: Cycles X

#140

Post by raphlinus »

RaisingSpear wrote: post #139
raphlinus wrote: post #124

Earlier quoted context omitted.

That post is 4 years old. Since then, Vulkan compute has made enormous strides forward, while OpenCL has stagnated. Examples of the things Vulkan has now are subgroup size control, explicit float16 and int8, pointers (previously you had to fake them with arrays), and a memory model. The memory model alone is a pretty big advance. What is still a mess is the tool situation. You have to write your shaders in GLSL or HL…

I see, thanks. I presume the end-user running the application will need to have up-to-date drivers to take advantage of these changes in the past 4 years?

For the most part, yes. It is possible to do runtime detection of these features and have compatibility paths, but that further adds to the burden of what's required of tooling and infrastructure. Depending on exactly what you're doing, it's probably best to assume recent drivers. For this type of application (a renderer for a creative app on desktop), I think it's a perfectly reasonable requirement.
Post reply on HN