Re: [Bf-committers] GPU computing
Hi! As far as developing for different platforms, I can provide Linux OpenCL coverage, at least participate in it. I am working with ATI Stream in Linux and Windows. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
also, here is a set of great podcasts : http://www.macresearch.org/opencl On Wed, Nov 25, 2009 at 4:07 AM, Damien Plisson wrote: > Hi Ishan, > > That's a great project to look how to leverage the GPU for blender! > > Concerning the mac, only Snow Leopard provides openCL (with other parallel > computing frameworks like grand central). > What's funny is that Apple strongly promotes openCL, but has not yet released > any SW that uses it (Aperture/Final Cut would be good candidates ...) > > I looked at this topic some time ago, and here are the info I gathered (you > may have already got some): > > Apple openCL doc & examples : > http://developer.apple.com/mac/library/documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html > examples: > Julia quaternion raytraced : > http://developer.apple.com/mac/library/samplecode/OpenCL_RayTraced_Quaternion_Julia-Set_Example/ > Procedural grass & terrain: > http://developer.apple.com/mac/library/samplecode/OpenCL_Procedural_Grass_and_Terrain_Example/ > ... > > There is also a paper from a nvidia guy on raytracing optimization through > openCL. It presents well what impacts performance: data transfer bottleneck, > and load balancing among the gpu cores: > http://www.nvidia.com/object/nvidia_research_pub_011.html > > I don't know the internals of blender renderer, but if you need help on the > Mac (and/or ghost topics) parts, feel free to ask ;) > > Good luck with openCL! > Damien > > Le 25 nov. 2009 à 04:28, Ishan Arora a écrit : > >>> That is, unless you're feeling ambitious. ^_^; >> Not very ambitious right now :) >> >>> Btw, let me know if you create a proper SVN fork and I can try to help with >>> Mac compiling, Snow Leopard only. >> Thanks for the offer. Mac would benefit the most from OpenCL. >> I am new here. One the first thing that confused me was the number of >> forks around. I was hoping to be able to submitting patches to the >> trunk. I am not really sure how things move around here. >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi Ishan, That's a great project to look how to leverage the GPU for blender! Concerning the mac, only Snow Leopard provides openCL (with other parallel computing frameworks like grand central). What's funny is that Apple strongly promotes openCL, but has not yet released any SW that uses it (Aperture/Final Cut would be good candidates ...) I looked at this topic some time ago, and here are the info I gathered (you may have already got some): Apple openCL doc & examples : http://developer.apple.com/mac/library/documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html examples: Julia quaternion raytraced : http://developer.apple.com/mac/library/samplecode/OpenCL_RayTraced_Quaternion_Julia-Set_Example/ Procedural grass & terrain: http://developer.apple.com/mac/library/samplecode/OpenCL_Procedural_Grass_and_Terrain_Example/ ... There is also a paper from a nvidia guy on raytracing optimization through openCL. It presents well what impacts performance: data transfer bottleneck, and load balancing among the gpu cores: http://www.nvidia.com/object/nvidia_research_pub_011.html I don't know the internals of blender renderer, but if you need help on the Mac (and/or ghost topics) parts, feel free to ask ;) Good luck with openCL! Damien Le 25 nov. 2009 à 04:28, Ishan Arora a écrit : >> That is, unless you're feeling ambitious. ^_^; > Not very ambitious right now :) > >> Btw, let me know if you create a proper SVN fork and I can try to help with >> Mac compiling, Snow Leopard only. > Thanks for the offer. Mac would benefit the most from OpenCL. > I am new here. One the first thing that confused me was the number of > forks around. I was hoping to be able to submitting patches to the > trunk. I am not really sure how things move around here. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
2009/11/25 Ishan Arora : >> That is, unless you're feeling ambitious. ^_^; > Not very ambitious right now :) > >> Btw, let me know if you create a proper SVN fork and I can try to help with >> Mac compiling, Snow Leopard only. > Thanks for the offer. Mac would benefit the most from OpenCL. > I am new here. One the first thing that confused me was the number of > forks around. I was hoping to be able to submitting patches to the > trunk. I am not really sure how things move around here. There is only a few fork that I know of (DTPBLender/instinctive Blender by Alexander Ewering and command-port by Dietrich Bollman). Branches there are quite a bit of, mainly because of Google Summer of Code. Best is to work against trunk and send patches for that. If possible, do join #blendercoders on Freenode.net - many developers are active there, and are able to help you with issues. Welcome aboard and good luck with your efforts :) /Nathan (jesterKing) > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
> That is, unless you're feeling ambitious. ^_^; Not very ambitious right now :) > Btw, let me know if you create a proper SVN fork and I can try to help with > Mac compiling, Snow Leopard only. Thanks for the offer. Mac would benefit the most from OpenCL. I am new here. One the first thing that confused me was the number of forks around. I was hoping to be able to submitting patches to the trunk. I am not really sure how things move around here. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
> I think it makes sense to start with something small, but CPU > intensive. I guess the most suitable candidate right now is > subdivision. What about point clouds? I think point cloud stuff would be wonderful but since there's nothing in Blender that could use them at the moment, and you'd have to create a data structure to store them as well as a structure for the files on disc, that might be a feature best left until later. That is, unless you're feeling ambitious. ^_^; Btw, let me know if you create a proper SVN fork and I can try to help with Mac compiling, Snow Leopard only. ~ C ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi, It seems we all agree on using OpenCL. Btw, I am on a windows machine. If any of you are on some other platforms then I could use your help in building OpenCL based code on your platforms. I think it makes sense to start with something small, but CPU intensive. I guess the most suitable candidate right now is subdivision. What about point clouds? Like I said before, I am just getting familiar with Blender's code. It would be nice if someone could direct me to where the original code for subdivision is. On Wed, Nov 25, 2009 at 3:00 AM, Matt Ebb wrote: > > On 25/11/2009, at 8:26 AM, Istvan burbank wrote: > >> I know little to nothing about this, but the rendering engine as a >> whole was thrown out there, and deemed not the best area. But what if >> it was more specific? What if only the ray tracing (AO, refl, transp >> etc) were the only part done by the gpu? That might be a smaller task, >> and more feasible a project. Maybe ray tracing isn't the best part, >> but the concept could be any 'part' of the rendering engine. > > Because Blender's renderer (and many offline renderers) don't really > work that way, it's not often easy to just separate out a 'part' > because all those different things are integrated together in the > shading pipeline. Not only does it make it difficult to code, but I > understand you also have issues with speed of data transfer. Not to > mention further refactor work possibly coming down the line which > would make it all worthless too. > > Really, the easiest way to use gpu-assisted rendering is to write a > completely new renderer from scratch utilising gpu hardware fully and > interface blender with it. Now that there's the render API it's a lot > easier too. > > Matt > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
On 25/11/2009, at 8:26 AM, Istvan burbank wrote: > I know little to nothing about this, but the rendering engine as a > whole was thrown out there, and deemed not the best area. But what if > it was more specific? What if only the ray tracing (AO, refl, transp > etc) were the only part done by the gpu? That might be a smaller task, > and more feasible a project. Maybe ray tracing isn't the best part, > but the concept could be any 'part' of the rendering engine. Because Blender's renderer (and many offline renderers) don't really work that way, it's not often easy to just separate out a 'part' because all those different things are integrated together in the shading pipeline. Not only does it make it difficult to code, but I understand you also have issues with speed of data transfer. Not to mention further refactor work possibly coming down the line which would make it all worthless too. Really, the easiest way to use gpu-assisted rendering is to write a completely new renderer from scratch utilising gpu hardware fully and interface blender with it. Now that there's the render API it's a lot easier too. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
I know little to nothing about this, but the rendering engine as a whole was thrown out there, and deemed not the best area. But what if it was more specific? What if only the ray tracing (AO, refl, transp etc) were the only part done by the gpu? That might be a smaller task, and more feasible a project. Maybe ray tracing isn't the best part, but the concept could be any 'part' of the rendering engine. Also, i have heard that Bullet physics will have OpenCL integrated into it, and it would be cool to have particles, *smoke* and fluids working on the GPU as well as the CPU if that is possible. These are all examples of 'small' equations that GPUs are better at doing, however using the GPU in addition to the CPU would be even better so that the GPU is treated just like another thread in that it isn't dependent on CPU vs. GPU speed. For all of these if a library was built that could be used by these simulations it might be easier to test/integrate since taking on the project full on has already been deemed to be too much work. Again, I all of what I just said may be useless and wrong, sorry if that is the case, but I guess what I'm suggesting is be more modular and then as that succeeds add more pieces to those that use this library. ~This will be awesome, I can't wait to see what comes of it, Istvan. PS. I'm not a real 'coder' (working on it - still in high school) but I would love to help in what ever I can. If this attempt fails, please excuse me. On Tue, Nov 24, 2009 at 3:05 PM, Shaul Kedem wrote: > Hi, > I've actually wrote a test to check opencl with post processing > (using nodes to add gamma, for example) and here are my findings: > - Brecht gave me the idea to work on the post pro area, saying that > if we can move a full post pro flow to the GPU we might see > performance gain > - Moving data from memory to the GPU takes time. It can (and in my > case did) take more time than doing the calculation in the CPU to > begin with. This can be lowered with shared memory usage and having > more to do on the CPU, but that's the general idea. > - Writing opencl code mean finding parallel algorithms where there > are none is use in the code right now > - When I asked ton, he said that the first thing is to have work > units in the post pro engine, so multi-CPU work can be done > > Anyway, good luck, opencl looks like its going places :-) > > Shaul > > > On Tue, Nov 24, 2009 at 1:28 PM, Marko Radojcic wrote: >> Hi! I was working on such an idea as well, some time ago, I think that >> Blender would most benefit from GPU raytracing and fluid >> simulations... >> >> I recommend OpenCL, it is a framework that integrates CPU, ATI GPU and >> NVIDIA GPU functionality. >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Knowledge is a measure of how many answers you have, intelligence is a measure of how many questions you have. "Elegance has the disadvantage that hard work is needed to achieve it and a good education to appreciate it." - E. W. Dijkstra "The price of humility doubles each time you have to buy it back" ~ rick dickulous "Intelligence is not enough. Intelligence plus character, that is the goal of true education." ~ Martin Luther King, Jr. "If everybody does it, it must be stupid" ~Ton Roosendaal ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi, I've actually wrote a test to check opencl with post processing (using nodes to add gamma, for example) and here are my findings: - Brecht gave me the idea to work on the post pro area, saying that if we can move a full post pro flow to the GPU we might see performance gain - Moving data from memory to the GPU takes time. It can (and in my case did) take more time than doing the calculation in the CPU to begin with. This can be lowered with shared memory usage and having more to do on the CPU, but that's the general idea. - Writing opencl code mean finding parallel algorithms where there are none is use in the code right now - When I asked ton, he said that the first thing is to have work units in the post pro engine, so multi-CPU work can be done Anyway, good luck, opencl looks like its going places :-) Shaul On Tue, Nov 24, 2009 at 1:28 PM, Marko Radojcic wrote: > Hi! I was working on such an idea as well, some time ago, I think that > Blender would most benefit from GPU raytracing and fluid > simulations... > > I recommend OpenCL, it is a framework that integrates CPU, ATI GPU and > NVIDIA GPU functionality. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi! I was working on such an idea as well, some time ago, I think that Blender would most benefit from GPU raytracing and fluid simulations... I recommend OpenCL, it is a framework that integrates CPU, ATI GPU and NVIDIA GPU functionality. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
On Tue, Nov 24, 2009 at 7:14 PM, joe wrote: > Our render archetecture doesn't lend itself to gpu-type processing. > You might be able to hack in something for e.g. soft shadows or > whatever, but I think that would be a mistake; such an effort should > be coordinated with the other refactors we need to do there, and I > don't know if anyone even knows when those refactors will happen, or > what their final form will be. > > Joe > How about the game render or GUI renderer that uses the game engine like setting (not sure what it is called off the top of my head)? That video I posted would make for a really fun alternate game renderer. It might not be very usable for 5 years but then it would really begin to shine. -- Douglas E Knapp Why do we live? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Our render archetecture doesn't lend itself to gpu-type processing. You might be able to hack in something for e.g. soft shadows or whatever, but I think that would be a mistake; such an effort should be coordinated with the other refactors we need to do there, and I don't know if anyone even knows when those refactors will happen, or what their final form will be. Joe On Tue, Nov 24, 2009 at 7:19 AM, Charles Wardlaw wrote: >> >> Animation is a big part of blender, and faster subsurf/armature >> systems would be very, very helpful. To be honest it'd be far more >> helpful then faster physics or rendering systems, and you'd have a >> much better shot at success. >> > > I would love to see GPGPU-enabled armature calculations... Although, since > many of the best rigs require custom python scripts I wonder if Python > wouldn't be a bottleneck there. > > On the renderer: you wouldn't have to rewrite everything. Not every part of > the rendering process benefits from multiprocessing anyways, just like not > every part benefits from the various data structures. But there've been a > number of nice papers on using GPGPU processing to accelerate the parts of > rendering that tend to be the most heavy -- ray collisions, subdivision (as > you said above), ambient occlusion, or even the generation of point clouds > for other purposes (AO, GI, FG). If Blender could generate point clouds > quickly and that data could be accessed and exported, a lot of studios would > be very interested. > > There's also the idea of accelerating nodes in the compositing or texture > graphs. And now that sculpt is multithreaded, I wonder how hard it would be > to get some of the processing offloaded to OpenCL cores. > > Then again, hardware-accelerated subdivision is a serious boon. At work > we're using Mach Studio, which is a GPU-based real-time rendering system. > It subdivides on the fly, on the card, and even with a few million polys in > a scene you have completely interactive turnarounds. Less so with > full-scene AO, but it's still usable. The last version released something > akin to the DX11 Tessellator functionality on DX10 cards, and watching it > generate a million polygons from a bump map and a plane is something to > behold. > > ~ C > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Don't know if this will help but wanted to point it out. http://www.youtube.com/watch?v=Soyr1sQmro4 On Tue, Nov 24, 2009 at 6:26 PM, Mike Pan wrote: > Definitely OpenCL since that seems to be the (only) emerging standard that > is hardware independent. > > Regarding the renderer, start small, instead of porting the entire renderer > to the GPU, see if you can port the ambient occlusion pass to the GPU, for > example, and slowly build up from there. > > -mike > > > On Tue, Nov 24, 2009 at 9:03 AM, Raul Fernandez Hernandez < > ra...@info.upr.edu.cu> wrote: > >> Hi again Ishan >> >> I recommend you start with a very narrow project, even if you have lot >> of skills in GPU programming, from all of the proposed areas choose >> first the smaller/simpler one and go ahead, then if you succeed go for >> bigger shots. >> >> You will get here all sort of recomendations because virtually every part >> of a 3D app cry for paralellization, from rendering (the most >> representative), animation, nodes/compositor transcoding, to a >> neverending list. >> >> So gather strength in very tiny projects, even if they don't have a big >> user impact, your rate of success will skyrocketed. >> >> Cheers -- Douglas E Knapp Why do we live? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Definitely OpenCL since that seems to be the (only) emerging standard that is hardware independent. Regarding the renderer, start small, instead of porting the entire renderer to the GPU, see if you can port the ambient occlusion pass to the GPU, for example, and slowly build up from there. -mike On Tue, Nov 24, 2009 at 9:03 AM, Raul Fernandez Hernandez < ra...@info.upr.edu.cu> wrote: > Hi again Ishan > > I recommend you start with a very narrow project, even if you have lot > of skills in GPU programming, from all of the proposed areas choose > first the smaller/simpler one and go ahead, then if you succeed go for > bigger shots. > > You will get here all sort of recomendations because virtually every part > of a 3D app cry for paralellization, from rendering (the most > representative), animation, nodes/compositor transcoding, to a > neverending list. > > So gather strength in very tiny projects, even if they don't have a big > user impact, your rate of success will skyrocketed. > > Cheers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi again Ishan I recommend you start with a very narrow project, even if you have lot of skills in GPU programming, from all of the proposed areas choose first the smaller/simpler one and go ahead, then if you succeed go for bigger shots. You will get here all sort of recomendations because virtually every part of a 3D app cry for paralellization, from rendering (the most representative), animation, nodes/compositor transcoding, to a neverending list. So gather strength in very tiny projects, even if they don't have a big user impact, your rate of success will skyrocketed. Cheers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
One more recommendation to go for OpenCL. We are working on accelerating pur Bullet physics sdk using OpenCL, and I recommend it for cross platform/vendor support. Our work is still early stages, but we try to make sure it works on all implementations. Eventually this work should go into Blender too. Although OpenCL supports task parallelism, it works best when dealing with fine grain data parallelism: 1000 to 1 small kernels processing similar work. Some GPU ray tracer for Blender would be cool, perhaps to create soft shadows. How about accelerating screen space post processing? Good luck with the effort! Erwin Sent from my iPhone On Nov 24, 2009, at 7:19, Charles Wardlaw wrote: >> >> Animation is a big part of blender, and faster subsurf/armature >> systems would be very, very helpful. To be honest it'd be far more >> helpful then faster physics or rendering systems, and you'd have a >> much better shot at success. >> > > I would love to see GPGPU-enabled armature calculations... Although, > since > many of the best rigs require custom python scripts I wonder if Python > wouldn't be a bottleneck there. > > On the renderer: you wouldn't have to rewrite everything. Not every > part of > the rendering process benefits from multiprocessing anyways, just > like not > every part benefits from the various data structures. But there've > been a > number of nice papers on using GPGPU processing to accelerate the > parts of > rendering that tend to be the most heavy -- ray collisions, > subdivision (as > you said above), ambient occlusion, or even the generation of point > clouds > for other purposes (AO, GI, FG). If Blender could generate point > clouds > quickly and that data could be accessed and exported, a lot of > studios would > be very interested. > > There's also the idea of accelerating nodes in the compositing or > texture > graphs. And now that sculpt is multithreaded, I wonder how hard it > would be > to get some of the processing offloaded to OpenCL cores. > > Then again, hardware-accelerated subdivision is a serious boon. At > work > we're using Mach Studio, which is a GPU-based real-time rendering > system. > It subdivides on the fly, on the card, and even with a few million > polys in > a scene you have completely interactive turnarounds. Less so with > full-scene AO, but it's still usable. The last version released > something > akin to the DX11 Tessellator functionality on DX10 cards, and > watching it > generate a million polygons from a bump map and a plane is something > to > behold. > > ~ C > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
> > Animation is a big part of blender, and faster subsurf/armature > systems would be very, very helpful. To be honest it'd be far more > helpful then faster physics or rendering systems, and you'd have a > much better shot at success. > I would love to see GPGPU-enabled armature calculations... Although, since many of the best rigs require custom python scripts I wonder if Python wouldn't be a bottleneck there. On the renderer: you wouldn't have to rewrite everything. Not every part of the rendering process benefits from multiprocessing anyways, just like not every part benefits from the various data structures. But there've been a number of nice papers on using GPGPU processing to accelerate the parts of rendering that tend to be the most heavy -- ray collisions, subdivision (as you said above), ambient occlusion, or even the generation of point clouds for other purposes (AO, GI, FG). If Blender could generate point clouds quickly and that data could be accessed and exported, a lot of studios would be very interested. There's also the idea of accelerating nodes in the compositing or texture graphs. And now that sculpt is multithreaded, I wonder how hard it would be to get some of the processing offloaded to OpenCL cores. Then again, hardware-accelerated subdivision is a serious boon. At work we're using Mach Studio, which is a GPU-based real-time rendering system. It subdivides on the fly, on the card, and even with a few million polys in a scene you have completely interactive turnarounds. Less so with full-scene AO, but it's still usable. The last version released something akin to the DX11 Tessellator functionality on DX10 cards, and watching it generate a million polygons from a bump map and a plane is something to behold. ~ C ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Working on the renderer would be infeasible, however. You'd have to essentially rewrite the whole thing. Physics would be the same way. The reason I mentioned subsurf and armature is they're much smaller subsystems, and are much more feasible projects. Animation is a big part of blender, and faster subsurf/armature systems would be very, very helpful. To be honest it'd be far more helpful then faster physics or rendering systems, and you'd have a much better shot at success. Joe On Tue, Nov 24, 2009 at 6:42 AM, Ishan Arora wrote: > @ Farsthary, > >> I would recomend OpenCL, since it aims to be hardware independent, not >> even just GPU but almost every piece of metal out there that could >> perform calculations :) , while CUDA is currently more mature than OpenCL >> is tied to NVIDIA brand :( > I know CUDA is tied to NVIDIA, but I can not figure out where to begin > with OpenCL. There is one available for Mac, one for NVIDIA, and if I > am right one for ATI too. Windows has its own API called > DirectCompute. > However the kernel based programming paradigm is more or less the same > in both CUDA and OpenCL. So even if one does not work out well, > porting to the other wont be difficult. > >> And while is not an easy task what you propose I think the most needed >> are are: Rendering,Modeling,Compositing > I know it wont be easy. Thankfully I have this big dev group to help me out :) > > @Joe > >> I'm not sure how many areas we should be messing with GPU stuff right >> now. . .I'd say ignore the renderer and physics systems, but subsurf >> and the armature modifies might be good candidates to play around >> with. That's just me though. > Okay. But I think the whole point of GPU computing is to aid in the > most CPU intensive tasks. I think rendering would be the top > candidate, and all the computational parts that make UI less > responsive > > Regards, > Ishan > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
@ Farsthary, > I would recomend OpenCL, since it aims to be hardware independent, not > even just GPU but almost every piece of metal out there that could > perform calculations :) , while CUDA is currently more mature than OpenCL > is tied to NVIDIA brand :( I know CUDA is tied to NVIDIA, but I can not figure out where to begin with OpenCL. There is one available for Mac, one for NVIDIA, and if I am right one for ATI too. Windows has its own API called DirectCompute. However the kernel based programming paradigm is more or less the same in both CUDA and OpenCL. So even if one does not work out well, porting to the other wont be difficult. > And while is not an easy task what you propose I think the most needed > are are: Rendering,Modeling,Compositing I know it wont be easy. Thankfully I have this big dev group to help me out :) @Joe > I'm not sure how many areas we should be messing with GPU stuff right > now. . .I'd say ignore the renderer and physics systems, but subsurf > and the armature modifies might be good candidates to play around > with. That's just me though. Okay. But I think the whole point of GPU computing is to aid in the most CPU intensive tasks. I think rendering would be the top candidate, and all the computational parts that make UI less responsive Regards, Ishan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
I'm not sure how many areas we should be messing with GPU stuff right now. . .I'd say ignore the renderer and physics systems, but subsurf and the armature modifies might be good candidates to play around with. That's just me though. Joe On Tue, Nov 24, 2009 at 5:11 AM, Raul Fernandez Hernandez wrote: > Hi Ishan > >> Hi all, >> >> Let me start by thanking you all for the development of such a great >> software. Blender has been a life saver for me many a time. Having said >> that, I think Blender has a lot of scope for improvement, mainly on the >> performance side. A lot of commercial software in 3D modeling, rendering, >> video editing etc are starting to take advantage of GPU's computing >> ability. >> I think it is a great feature to add to Blender, and I would like to >> contribute to it. > > Thanks for your words and thanks also for your attitude :) > >> However I am new to Blender source code. So I am looking for some >> guidance. >> Please give me suggestion on what API to use (CUDA/OpenCL), where do you >> think GPU computing most (rendering, video processing, etc.) and any other >> suggestions you may have. Thank you. >> >> Regards, >> Ishan > > I would recomend OpenCL, since it aims to be hardware independent, not > even just GPU but almost every piece of metal out there that could > perform calculations :) , while CUDA is currently more mature than OpenCL > is tied to NVIDIA brand :( > And while is not an easy task what you propose I think the most needed > are are: Rendering,Modeling,Compositing > > Regards Farsthary > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi Ishan > Hi all, > > Let me start by thanking you all for the development of such a great > software. Blender has been a life saver for me many a time. Having said > that, I think Blender has a lot of scope for improvement, mainly on the > performance side. A lot of commercial software in 3D modeling, rendering, > video editing etc are starting to take advantage of GPU's computing > ability. > I think it is a great feature to add to Blender, and I would like to > contribute to it. Thanks for your words and thanks also for your attitude :) > However I am new to Blender source code. So I am looking for some > guidance. > Please give me suggestion on what API to use (CUDA/OpenCL), where do you > think GPU computing most (rendering, video processing, etc.) and any other > suggestions you may have. Thank you. > > Regards, > Ishan I would recomend OpenCL, since it aims to be hardware independent, not even just GPU but almost every piece of metal out there that could perform calculations :) , while CUDA is currently more mature than OpenCL is tied to NVIDIA brand :( And while is not an easy task what you propose I think the most needed are are: Rendering,Modeling,Compositing Regards Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GPU computing
Hi all, Let me start by thanking you all for the development of such a great software. Blender has been a life saver for me many a time. Having said that, I think Blender has a lot of scope for improvement, mainly on the performance side. A lot of commercial software in 3D modeling, rendering, video editing etc are starting to take advantage of GPU's computing ability. I think it is a great feature to add to Blender, and I would like to contribute to it. However I am new to Blender source code. So I am looking for some guidance. Please give me suggestion on what API to use (CUDA/OpenCL), where do you think GPU computing most (rendering, video processing, etc.) and any other suggestions you may have. Thank you. Regards, Ishan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
