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

141–150 of 151 posts

Re: Cycles X

#141

Post by dagmx »

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?

I'm not sure why you're talking about DRM...but software licensing absolutely applies.

Studios work together and with outsourcers. Sometimes that means sharing plugins. Under GPL that would mean they'd have to share their code which is strong IP.

Re: Cycles X

#142

Post by account42 »

random5634 wrote: post #117
packetslave wrote: post #75

Earlier quoted context omitted.

Studios write a LOT of custom code for their pipeline and tools. If you were to go to ILM or Dreamworks or WDAS and watch someone use Maya there, it would look COMPLETELY different from what you see at home. Given that, I'm not surprised that the (not-always-technical) lawyers are worried about GPL.

Current version of GPL is an absolute no go for many larger places - even Ubuntu ended up dropping it for parts of stack - risks are way too high

> even Ubuntu ended up dropping it for parts of stack

"even" Ubuntu? Are you implying that Canonical are some kind of champion of free software?

Re: Cycles X

#143

Post by account42 »

RaisingSpear wrote: post #111
raphlinus wrote: post #98

Earlier quoted context omitted.

Vulkan supports integer operations just fine, but tool support for just about everything is extremely primitive. Sizes other than 32 bits are available, but generally as an option. You can check https://vulkan.gpuinfo.org/listfeaturescore10.php to see the fraction of drivers that support the various integer sizes (and lots other optional features).

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…

> 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

That thread is talking about SPIR (the OpenCL binary shader format) in the OpenCL implementation, not SPIR-V (the Vulkan binary shader format, which has also been adopted by other APIs) in the Vulkan implementation.

Re: Cycles X

#144

Post by random5634 »

thomastjeffery wrote: post #136
random5634 wrote: post #135

Earlier quoted context omitted.

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 th…

They don’t want to open source the tools and programs they develop as part of their pipelines that tie into GPl or each other - GPl is viral and a library import triggers it.

In terms of the tivoization / drm provisions - the GPL is viral - it only takes one screw up or chain of viral connection to blow their business up. Apple fought the govt to avoid unlocking a terrorists phone, that’s how hard they protect signing keys .

The issue is they don’t know who will use what where, and the viral aspect adds insane risk. Minecraft / roblox and other games may decide to add design pipelines or render chains. Or they may want to run the software on golden image VDI pools that are locked down.

Even Ubuntu was so worried about the chain risk they changed bootloader license away from latest GPl

Re: Cycles X

#145

Post by thomastjeffery »

random5634 wrote: post #144
thomastjeffery wrote: post #136

Earlier quoted context omitted.

> 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 th…

They don’t want to open source the tools and programs they develop as part of their pipelines that tie into GPl or each other - GPl is viral and a library import triggers it. In terms of the tivoization / drm provisions - the GPL is viral - it only takes one screw up or chain of viral connection to blow their business up. Apple fought the govt to avoid unlocking a terrorists phone, that’s how hard they protect signin…

> In terms of the tivoization / drm provisions - the GPL is viral - it only takes one screw up or chain of viral connection to blow their business up.

Did I not just finish explaining how that is not true?

The GPL is only "viral" to software that it is licensed with, and extensions to that share meaningful data structures with that software.

The GPL does not cover content created by GPL licensed software.

> The issue is they don’t know who will use what where, and the viral aspect adds insane risk.

Except it's trivial to understand the "viral" aspect of the GPL. It's clearly explained in many places. Therefore, there is no risk at all.

> Minecraft / roblox and other games

Games? We're talking about motion picture and television studios. Then again, plenty of game devs use Blender in their asset creation pipeline without getting the GPL involved in their codebase.

> Or they may want to run the software on golden image VDI pools that are locked down.

So? What does that have to do with anything?

> Even Ubuntu was so worried about the chain risk they changed bootloader license away from latest GPl

I don't know anything about that, but I sincerely doubt the context for that decision is in any way similar there...

All I'm seeing here is FUD. Not one of your examples actually brought up a reason - outside irrational fear - to avoid using Blender to make movies.

Re: Cycles X

#146

Post by random5634 »

thomastjeffery wrote: post #145
random5634 wrote: post #144

Earlier quoted context omitted.

They don’t want to open source the tools and programs they develop as part of their pipelines that tie into GPl or each other - GPl is viral and a library import triggers it. In terms of the tivoization / drm provisions - the GPL is viral - it only takes one screw up or chain of viral connection to blow their business up. Apple fought the govt to avoid unlocking a terrorists phone, that’s how hard they protect signin…

> In terms of the tivoization / drm provisions - the GPL is viral - it only takes one screw up or chain of viral connection to blow their business up. Did I not just finish explaining how that is not true? The GPL is only "viral" to software that it is licensed with, and extensions to that share meaningful data structures with that software. The GPL does not cover content created by GPL licensed software. > The issue…

Dude - let me make this super simple. These rendering pipelines import the SDKs and APIs they connect with. The pipelines have tons have high value custom code. Under the GPL, they have to be open sourced if they use blender - this is 101 stuff. And under GPL it is viral, if stage 1 is now forced open, the next big set of stuff that integrates with stage 1 is also forced open and so on.

Pixar is not open sourcing their pipeline - period. Do you not understand that these companies build giant and high value software around the various engines?

Listen - I didn't realize how little you understood. This is actually covered in the Blender FAQ's because it can really bite you (even if a small player) if you build an add-on to blender.

"Blender’s Python API is an integral part of the software, used to define the user interface or develop tools for example. The GNU GPL license therefore requires that such scripts (if published) are being shared under a GPL compatible license."

This is cool if you want to use stuff - they make that clear too. "Sharing Blender or Blender add-ons or scripts is always OK and not considered piracy." But for commercial players this is an absolute no go.

This is not FUD, this is hard reality, and no commercial player is going to tie into something like this.

Re: Cycles X

#147

Post by random5634 »

account42 wrote: post #142
random5634 wrote: post #117

Earlier quoted context omitted.

Current version of GPL is an absolute no go for many larger places - even Ubuntu ended up dropping it for parts of stack - risks are way too high

> even Ubuntu ended up dropping it for parts of stack "even" Ubuntu? Are you implying that Canonical are some kind of champion of free software?

Yes - they ship open source and are generally more comfortable with open source licensing because they have much more experience with it.

Expecting an entertainment industry org (which were specially attacked in latest version of GPL around DRM) to be comfortable seems far fetched.

Re: Cycles X

#148

Post by mkaic »

barneyrubble wrote: post #109
mkaic wrote: post #65

Earlier quoted context omitted.

Viewport performance is one of the several major improvements demoed in the linked video by Brecht!

Brecht’s videos show off improved rendering. I think the person you’re replying to is instead referring to viewport performance in general: scene complexity and size, undo performance, framerate, responsiveness, that sort of thing.

Oh, makes sense. I do know improved dense mesh editing performance is on the roadmap for 3.1 - 3.3 era, so at least there's that :)

Re: Cycles X

#149

Post by weeboid »

rguetzkow wrote: post #137
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-rel…

This is a really weird response.

1. Nowhere did I mention Blender, although yes, this is a primary gripe

2. Even if I had, where does the inference that Blender somehow drove this come from?

3. Why leave out Metal2 and AMD frome the discussion?

Re: Cycles X

#150

Post by rguetzkow »

weeboid wrote: post #149
rguetzkow wrote: post #137

Earlier quoted context omitted.

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-rel…

This is a really weird response. 1. Nowhere did I mention Blender, although yes, this is a primary gripe 2. Even if I had, where does the inference that Blender somehow drove this come from? 3. Why leave out Metal2 and AMD frome the discussion?

Sorry for the late reply. I assumed that your comment was about Blender given that you've commented on a post about it. I also assumed that the comment was directed at Blender because there have been plenty similar comments/questions w.r.t. CUDA support on Blender's Stack Exchange in the past. Since you were addressing CUDA in particular, that's what I did in my reply as well.
Post reply on HN