This week on the blender podcast, We discuss some of the things going on recently, especially 2.61 release and related projects (Cycles, Tiling Compositor & BMesh).
- Campbell
Length: 28:38.
Recorded: 14th of December 2011
Download: OGG MP3
Links (General Discussion)
- Tiles Compositor now has an svn branch, details
- Why OpenGL select is slow (thread)
- BMesh Branch Merge (proposal)
totally agree with campbell, if your card doesn’t support CUDA and can’t HW acc. render with Cycles.
CPU mode will always work until you buy a new card.
Maybe some of you guys could jump in and release an updated “guide to the perfect blender computer” right before christmas. Just like the one Andrew Price did ages ago, but this time considering the new cycles render engine. Thanx in advance. Thomas and Campbell, you´re doing a great job for the community!
Hi Dan, the problem with this is it changes all the time and unless you do comparisons with recent hardware, its hard to know exactly whats best value for money.
It also depends on what you want to do.
So I’d suggest sites like http://www.phoronix.com & http://www.tomshardware.com, if you really want details.
Personally, I put together my systems from parts, sticking to NVidia GFX, AMD CPU on 64bit Linux.
Since in Australia you can get parts quite cheap at computer markets.
Intel / AMD both make pretty good processors at the moment so really the most important thing is to go with NVidia GFX – since they run both Cuda and OpenCL a lot better – if your interested in using Cycles eventually.
thanx, campbell.
Hi Thomas (and Campbell), no you didn’t pronounce my name right. But that’s okey
Great podcast. Keep it up
Sorry then.
And thanks for listening to our podcast, much appreciated.
Hello.
I was just wondering.
(I’ll talk about nVidia because that is the brand I know, but AMD users should know the equivalent of what I am saying)
Everybody always choose a gaming GPU because it has more Stream Proccesors (CUDA cores [SP from now on]) so they can render faster with GPU accelerated renderers such as Luxrender or Cycles. I have a Quadro FX, they have less SP but they say it is better for 3D applications. In your opinion, What is better, a gaming GPU with more SP, or a Workstation GPU with less SP but “optimized” for 3D applications such as Blender?
The problem with respect towards blender, is, that there aren’t any specialized drivers for blender, except afaik one lonely quadro fx 5xx(or some such old card) driver.
For Cycles, it’s definitely a Gaming GPU.
These “optimized” cards are often faster in the OpenGL context (3D View), but for rendering I doubt they are faster. What counts for Cycles and any other GPU accelerated engine, is the speed of the card and the amount of SP/Cuda Cores.
Workstation GPUs on the other hand often have more GPU memory than the gamer cards, which is important for GPU rendering too. But there are gamer cards with 3GB ram as well already today.
Dropping Cycles support for the Geforce 200 series is a HUGE mistake, and we need to get that in front of Brecht. All of the NVidia consumer cards after that line (the 400′s and 500′s) were CRIPPLED for 3D applications via intentional bugs in openGL support- viewport display is widely reported to be slower than cards 3-4 generations earlier (and AMD/ATI cards are likewise crippled, and buggy as hell). I was going to build a new system with a 200 series card in it, but now I don’t know what to do. I’m a hobbyist, and I’m afraid Nvidia and ATI have simply priced me out of doing 3D any more.
Well… Something for everyone. Yeah. The viewport performance with the fermi cards is terrible if doing hi-res sculpting still.
Though you can get a simple GT430 fermi card with CUDA for around 60€ at cheapest. Not really meaning it will be too fast though. I think it just might be cost effective but I wouldn’t recommend those before seeing some benchmarks.
And then there’s OpenCL which I think works with older cards too. I did some testing. Test scene with GTX580 CUDA ~16 seconds. OpenCL ~22 seconds so it’s not entirely terrible performance with openCL either. Still not as fast though.
I’m also housing a GTX260 in my PC for occasions where I need to sculpt something bigger… Have to change the screen cable manually between the cards and restart blender… Is a pain in the arse really.
One time I managed to get pretty high performance out of my 580 with sculpthing… Yeah it’s 20 million vertices allright with 20 frames per second. XD Haven’t been able to reproduce that effect yet though. You need to force out verticel sync on Nvidia control panel and fiddle with the settings on blender. With VBO and draw modes and… I’m not really sure how to redo that…
Have you tested OpenCL performance with the 260? Does it even work, and if so, how long does it take in that test scene?
I can’t speak for exact card models, but assume this is because 1.0 – 1.2 cuda versions are unsupported?
See:
http://markmail.org/message/npidmsqxtfixqyer
Since cycles is new and probably wont be a fit replacement for blender-internal in some years, Think its reasonable to focus on getting it feature complete before spending time to support a lot of different hardware.
Regarding new drivers being buggy/crippled – this sucks but is really out of our control, its also a bad move to make design decisions in blender based on bugs in specific driver versions, since next week they may fix the bug and we lost time trying to support something which is now fixed.
New drivers often _do_ fix bugs so this isn’t some weak excuse.
Other times it may be worth supporting driver bugs – if it annoys many users, or few drivers correctly implement that part of the OpenGL spec – but its not clear cut.
Let me rephrase- it’s not a bug. It’s an intentional limitation that Nvidia built in to force 3d content creators to buy their Quadro cards. (I’m not a programmer, but from what I’ve been reading it has to do with improper implementation of the glReadPixel function.) Nvidia representatives have acknowledged the problem exists in their own support forums, but have been utterly silent about fixing it, despite widespread outcry. And they’ve gotten away with it because the software makers (mainly Autodesk) are too deeply in bed with them to raise a fuss. They keep building their software so that it is useless on all but the most expensive cards, and in return, Nvidia gives them preferential treatment in driver optimization.
Blender is really the only place that hobbyists and low-end freelancers can turn anymore, and if you developers play along with Nvdia’s game, we won’t even have that. If you start building the software so that it will only run (or only run at a useful speed) on Fermi-based Quadros, we’ll all just have to pack up and go home. While Cycles may not be ready to replace the default Blender renderer for a while, it seems that’s where all the effort is going as far as rendering. For the time being, those of us who can’t afford a decent Quadro (I understand the low end ones are a joke) are stuck choosing between being able to use cycles (by getting a Geforce 4xx or 5xx), and being able to do ANYTHING else (by keeping or getting an older card). But as those older cards disappear from the market, that won’t be an option anymore. For now, you need to support cycles on the 200 series (as it was before). For the future, you need to figure out a way around this openGL problem in the viewports.
I’ve heard of companies intentionally disabling features on low end cards before and while I don’t have evidence its fairly clear companies aren’t interested in features perceived as `high end`.
Though I think you might be reading too much into this (regarding autodesk). – probably its as simple as AMD/NVidia wanting to have some reason for people to buy their high end cards.
As for Blender Devs “playing along with this” – we’ll we don’t have much choice – hardware vendors do their thing, blender devs are not all OpenGL experts, but anyone is free to work on improvements – at some point I think its good for people to scratch their own itch (get angry/annoyed enough to find a solution).
However I have a hard time believing this is such a common issue – I gave had 5 – 6 low end NVidia cards dating back to when 128mb or ram was a lot, and all ran fine on Linux with nvidia’s drivers – currently using GeForce 450 on 64 bit linux.
I’m sure this will be resolved, but you have to appreciate we just don’t have that many people to allocate time to various hardware configuration issues.
Thanks for doing this podcast! very informative of the development insights
Great podcast, really enjoy these, thanks!
I agree that BMesh should be a complete release unto itself. I can imagine it’s could cause a cascade of potential bugs and it’s also going to cause a whole slew of tools work differently. I think the community as a whole will need the time between releases to get up to speed on it’s awesomeness.
I know I will!