[Bf-cycles] Multi-GPU tiling support? (Brecht Van Lommel)
Andrew Price
andrew at blenderguru.com
Thu Oct 11 10:07:52 CEST 2012
Thanks for explanation Brecht. I'll pass this on to the renderfarm and see
what they can do.
Cheers!
On Tue, Oct 9, 2012 at 7:00 PM, <bf-cycles-request at blender.org> wrote:
> Send Bf-cycles mailing list submissions to
> bf-cycles at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.blender.org/mailman/listinfo/bf-cycles
> or, via email, send a message with subject or body 'help' to
> bf-cycles-request at blender.org
>
> You can reach the person managing the list at
> bf-cycles-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-cycles digest..."
>
>
> Today's Topics:
>
> 1. Re: Multi-GPU tiling support? (Brecht Van Lommel)
> 2. UV, not working well in OSL Script node (Dalai Felinto)
> 3. Re: UV, not working well in OSL Script node (Brecht Van Lommel)
> 4. Re: UV, not working well in OSL Script node (Lukas T?nne)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 8 Oct 2012 12:49:12 +0200
> From: Brecht Van Lommel <brechtvanlommel at pandora.be>
> Subject: Re: [Bf-cycles] Multi-GPU tiling support?
> To: bf-cycles at blender.org
> Message-ID:
> <CAKFUgC35A0qT+zkLftyALvh=
> HGMZ5bn31gsWr0-EtzuEjPGJEQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Yes, 6x6 tiles should allow 36 GPU's to work on the same image. But
> even before the tiling multi GPU was already working. So more likely
> it has something to do with the configuration or Cycles not
> recognizing the GPU's. Cycles should by default use all GPU's except
> for the one used for display in case of multi GPU. So if this is a
> dual GPU system that might be the problem that causes only one of the
> two to be used.
>
> This script can be used to print which GPU devices is used and which
> settings are available, if you have some way to run.
> http://www.pasteall.org/36025/python
>
> Ideally the render farm should set things up such that the user
> preferences are already saved with the right configuration.
>
> Brecht.
>
> On Mon, Oct 8, 2012 at 3:54 AM, Andrew Price <redbytex at gmail.com> wrote:
> > Hey all, I sent this yesterday but I'm not sure it went through, so I'm
> > sending it again (sorry if you get it twice).
> >
> > Does tile rendering allow for multiple GPUs to work on the same image?
> Eg. 6
> > x 6 tiles, allow for 36 GPUs to work on the frame simultaneously.
> >
> > I'm creating a few animations with Cycles and have been using the
> renderfarm
> > RenderFlow to render them. So far we have only been able to get one GPU
> to
> > work on one frame at a time, but we're not sure if this is normal.
> >
> > Thanks for your help.
> >
> >
> > --
> > Regards,
> > Andrew Price
> > www.blenderguru.com
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 8 Oct 2012 23:19:09 -0700
> From: Dalai Felinto <dfelinto at gmail.com>
> Subject: [Bf-cycles] UV, not working well in OSL Script node
> To: bf-cycles at blender.org
> Message-ID:
> <
> CAGjvzG3XN8EpNWgmpkMr7jCe7by1txPBczKsDqU8P0Lnt1JE9w at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi there,
>
> I'm testing the OSL node (in lukas' branch) and I noticed that u,v is
> not getting the information from Blender.
> See file http://www.pasteall.org/blend/16845 or image:
> http://www.pasteall.org/pic/38655
>
> The test shader source is very simple:
> ####
> surface
> example_shader_1
> (
> output closure color fora = 0
> )
> {
> fora = color(u, v, 1.0) * emission();
> }
> ####
>
> Any clues on whether it's a todo in cycles, or something in the "OSL
> script" node implementation?
> Thanks,
> Dalai
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 9 Oct 2012 08:41:23 +0200
> From: Brecht Van Lommel <brechtvanlommel at pandora.be>
> Subject: Re: [Bf-cycles] UV, not working well in OSL Script node
> To: bf-cycles at blender.org
> Message-ID:
> <CAKFUgC0nCji9-dh0wB8a+JvyTLMLyF=
> 1tTZ8wvWidM2-esOkcA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The sphere looks correct to me. The u,v values here are like the
> Parametric output in the Geometry node (barycentric coordinates in the
> triangle), not a UV layer. If the plane has that material assigned too
> that would be a problem, but otherwise don't see the bug.
>
> For the UV layer though, there is a bit of a design issue here. Cycles
> only exports mesh data layers when they are requested by the shader
> (to save memory and export time). However for an arbitrary OSL shader
> I don't know how to determine automatically if they need such
> attributes.
>
> Brecht.
>
> On Tue, Oct 9, 2012 at 8:19 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> > Hi there,
> >
> > I'm testing the OSL node (in lukas' branch) and I noticed that u,v is
> > not getting the information from Blender.
> > See file http://www.pasteall.org/blend/16845 or image:
> > http://www.pasteall.org/pic/38655
> >
> > The test shader source is very simple:
> > ####
> > surface
> > example_shader_1
> > (
> > output closure color fora = 0
> > )
> > {
> > fora = color(u, v, 1.0) * emission();
> > }
> > ####
> >
> > Any clues on whether it's a todo in cycles, or something in the "OSL
> > script" node implementation?
> > Thanks,
> > Dalai
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 9 Oct 2012 09:17:12 +0200
> From: Lukas T?nne <lukas.toenne at gmail.com>
> Subject: Re: [Bf-cycles] UV, not working well in OSL Script node
> To: bf-cycles at blender.org
> Message-ID:
> <CANhmeOi5Bxvd=3a8dN7gyR-9r7B5v2V4vZeA2=
> 48FRPx6BcA8Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Had a little discussion with Dalai about how to make sure such shaders
> are still portable to non-cycles renderers. Apart from the brute-force
> solution (always request UV in the OSL script node), we came up with
> two options:
>
> 1) Use a generic "Vector" input, like other nodes. This has the
> advantage of being flexible, but is not as simple as using u/v globals
> directly.
>
> 2) Use shader metadata to encode cycles attribute requests:
>
> surface
> example_shader_1
> [[ string attributes = "UV,SomeCustomAttribute" ]]
> (
> output closure color fora = 0
> )
> {
> fora = color(u, v, 1.0) * emission();
> }
>
> Still this second approach would only work when actually writing the
> node *for cycles*. Using a shader from other render engines which
> doesn't have this request feature/limitation would still not work
> without manual fixing ...
>
> Maybe it should be added as an option on user level: Simple checkbox
> list in advanced options (sidebar) to enable UV and other requests.
> Not very elegant though.
>
> On Tue, Oct 9, 2012 at 8:41 AM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
> > The sphere looks correct to me. The u,v values here are like the
> > Parametric output in the Geometry node (barycentric coordinates in the
> > triangle), not a UV layer. If the plane has that material assigned too
> > that would be a problem, but otherwise don't see the bug.
> >
> > For the UV layer though, there is a bit of a design issue here. Cycles
> > only exports mesh data layers when they are requested by the shader
> > (to save memory and export time). However for an arbitrary OSL shader
> > I don't know how to determine automatically if they need such
> > attributes.
> >
> > Brecht.
> >
> > On Tue, Oct 9, 2012 at 8:19 AM, Dalai Felinto <dfelinto at gmail.com>
> wrote:
> >> Hi there,
> >>
> >> I'm testing the OSL node (in lukas' branch) and I noticed that u,v is
> >> not getting the information from Blender.
> >> See file http://www.pasteall.org/blend/16845 or image:
> >> http://www.pasteall.org/pic/38655
> >>
> >> The test shader source is very simple:
> >> ####
> >> surface
> >> example_shader_1
> >> (
> >> output closure color fora = 0
> >> )
> >> {
> >> fora = color(u, v, 1.0) * emission();
> >> }
> >> ####
> >>
> >> Any clues on whether it's a todo in cycles, or something in the "OSL
> >> script" node implementation?
> >> Thanks,
> >> Dalai
> >> _______________________________________________
> >> Bf-cycles mailing list
> >> Bf-cycles at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-cycles
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> ------------------------------
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> End of Bf-cycles Digest, Vol 18, Issue 4
> ****************************************
>
--
Regards,
Andrew Price
http://www.blenderguru.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20121011/718ec072/attachment.htm
More information about the Bf-cycles
mailing list