I think a version of Larrabee will be released soon -- though it's not likely to be a graphics chip, it's most likely to be a mini-supercomputer on a card.
The margins in that arena are much better than the margins in CPU's right now, so you can bet that Intel's going to go after it with some gusto. OpenMCL and DirectX are our best bets for "standardized" API's. OpenGL will always be playing catchup, and DirectX will always be leading the way, because Microsoft makes too much money from games to stop pushing DirectX as much as it can, and OpenGL is a standard that requires a committee to agree on. The same committee that ensures that OpenGL is OpenGL also slows it down -- it's the tradeoff for standardization. Threading in Python is a joke. I've done it, it's a waste of effort. The language is suitable only for embarrassingly parallel applications, and that's it. C++0x won't be usable by very many people -- especially the newer programmers. It will be a fine language, but the people using it will be limited to supercomputer models, games, and the better 3D animation and rendering software. There are several modern programming languages that are placing a strong emphasis on parallel, multi-threaded, distributed, and functional programming. In "mainstream" programming, applications will just get buggier and more bloated. In the smaller space of 3D software and games, we'll see some amazing stuff, probably in the next couple of years. They're going to have no choice as far as standards -- there will be a small number of languages (my guess is OpenMCL + whatever Microsoft calls theirs) that will end up becoming pervasive, and anyone who wants to play will have to support them or be kicked to the curb. Thanks -- I'm trying to get out of programming so that I can do more with 3D and photography. I've been out of 3D for too long, because I haven't had the time to keep it up. ----------------------------- Rakesh Malik http://www.whitecranephotography.com http://www.flickr.com/baratheon On Tue, Jul 20, 2010 at 6:22 AM, Jean-Sebastien Perron <j...@neuroworld.ws>wrote: > Wow really interesting Rakesh. > > Larrabee won't be released soon, if released at all. > > I hope you are right, I am eager for theses new features to be open > standard. > As a programmer, it's even difficult to use good old OpenGl/DirectX mess. > > Thankyou for that long response, If you know more tell us. > I will do further reading about the new GPU. > > The new c++ standard ( C++0x <http://en.wikipedia.org/wiki/C%2B%2B0x>) > that will be revealed the next year, will support multi threading. > Like Python, most languages are now supporting parallel execution directly > in the language. > > OpenGL, DirectX, Larrabee, ATI, Nvidia, Mac, Linux, Win ... They will never > merge to any standard. > > I really like your landscape pictures. > > > Jean-Sebastien Perron > www.CombadZ.com > > On 10-07-20 02:34 AM, Rakesh Malik wrote: > > GPU based renderers are most likely the future. > > The Cell isn't it -- it's only somewhat parallel, and it's not > well-suited to double precision arithmetic. It's a better suited to > rendering than to gaming, but it's definitely nowhere near to being all that > it's cracked up to be. > > The latest generation of GPU's from nVidia and AMD/ATI are, however, > exactly what you're describing -- massively parallel, with extremely fast > buses, and with general-purpose computing engines rather than dedicated > hardware to run shaders. The latest nVidia GPU's do double-precision > arithmetic well, which is specifically for high-performance computing. > > The consistency isn't due to the GPU's being GPU's, it's because > general-purpose GPU's are relatively new, and there aren't any standards for > them yet. It will change, especially with programming languages for them > becoming standardized. > > Intel's Larabee processor is specifically geared toward general-purpose > computing -- it's a collection of small, fast processors with very fast > interconnects and it's well-suited to applications such as rendering. > > And lastly... the reason that the industry is being so conservative about > parallelism is that most programmers don't understand even the simplest > issues in parallel programming -- how to partition and re-assemble data, > handle node failures, mutual exclusion, resource contention, that sort of > thing. > > > ---------------------------- > Rakesh Malik > http://www.whitecranephotography.com > http://www.flickr.com/baratheon > > > On Mon, Jul 19, 2010 at 6:46 PM, Jean-Sebastien Perron > <j...@neuroworld.ws>wrote: > >> GPU based renderer are doomed unless there is a open and documented >> standard. >> Like any hardware-dependent renderer they will fade over time. >> >> It's sad that the the Cell processor was ignored by the industry. >> The Cell in the hand of good old programmers (Assembler and c++) not >> (scripters) could do so much. >> >> I hate AMD and Intel and Arm and Motorolla, >> The secret to faster computing is parallel work. >> Like the hundreds of "Blitters" in the old arcade motherboard of the 80's. >> Programming in parallel require thinking, and the industry is playing it >> safe. >> >> We don't need 4 core we need 32 or 64 and more. >> Simple core that only do floating point math vectoring. >> Not all purpose crap like intel(int tel) like in integer. >> >> GPU are useless in generating images, no 2 videocard produce the same >> result. >> What is important is math math math .... Vector and matrix nothing else >> And still to this day, only one processor in the world deliver that : The >> Cell >> >> If I had the money of Bill Gate, In a year I would completely change the >> computer world. >> Company are behaving like the petrol industry : holding technology, and >> improving slowly to make more money. >> I would have thought that buy now we would not need to think about >> computing speed. >> >> The solution is so simple : (a really really simple RISC processor * 64) >> + a lot of memory inside the processor) in a single chip. >> A computer in a chip, everything in a chip. No dedicated hardware or >> instructions. >> >> Actually not all of the above is true, but mostly true >> >> Jean-Sebastien Perron >> www.CombadZ.com >> >> >> On 10-07-19 04:00 PM, aidan o driscoll wrote: >> >>> OR http://www.refractivesoftware.com/ >>> >>> Octane Render is the world's first GPU based, un-biased, physically >>> based renderer. €99 >>> >>> Bought this recently on offer - €49. Very nice renderer too. Use it with >>> Modo! >>> >>> Plugs for other apps being developed for this also .... >>> >>> Aidan >>> >>> On 19 July 2010 20:42, Neil Cooke<ne...@xtra.co.nz> wrote: >>> >>> >>>> Nice Archviz there Arfo!!! >>>> Thanks >>>> Neil Cooke >>>> PS: I dont know enough about renderers to comment and RS does it Ok for >>>> me >>>> ... in my ignorance perhaps. >>>> ________________________________ >>>> From: Arjo Rozendaal<arjo.rozend...@xs4all.nl> >>>> To: user-list@light.realsoft3d.com >>>> Sent: Tue, 20 July, 2010 6:36:03 AM >>>> Subject: RE: Fryrender plugin support >>>> >>>> Hi Jason, >>>> >>>> >>>> >>>> I think Realsoft really needs a better render engine. But rendering with >>>> third party plugins would mean some serious changes. Solid objects won't >>>> be >>>> possible, everything will have to be turned into SDS/polygonal objects. >>>> VSL >>>> will be of no use anymore. All the materials will have to be created to >>>> work >>>> with the render engine. I doubt if this is what most Realsoft users >>>> like. I >>>> always liked the special things of Realsoft like the VSL and solid >>>> objects. >>>> I'm afraid the mainstream production market is quite covered by the >>>> other >>>> apps. So I guess Realsoft is more for the users that like the special >>>> options. >>>> >>>> However I must admit that these specialties have some severe >>>> limitations. In >>>> terms of production, VSL is far too technical and time consuming to >>>> create >>>> nice materials. Solids have limitations if you want to add bevels, >>>> deform >>>> them or things like that. >>>> >>>> But if Vesa and Juha find some solution that could bring the high >>>> quality >>>> rendering to Realsoft without losing VSL and solids it would be very >>>> impressive. >>>> >>>> >>>> >>>> Anyway, I'm even not sure if Fryrender is the best choise. I chose Vray, >>>> which is not an unbiased renderer lik Fry or Maxwell. But it's a lot >>>> faster. >>>> >>>> And IMHO it renders very nice images too. But as always there are a lot >>>> of >>>> different opinions when it comes to choosing a render app. And all the >>>> software galeries show the nicest results of their users. Here are some >>>> results of myself: >>>> >>>> Two different interior projects I did this year (rendered with Vray): >>>> http://www.xs4all.nl/~joly/show/kantoor.html<http://www.xs4all.nl/%7Ejoly/show/kantoor.html>and >>>> http://www..xs4all.nl/~joly/show/wrobel.html<http://xs4all.nl/%7Ejoly/show/wrobel.html> >>>> >>>> Both completely different atmosphere in terms of style. Modern/clean >>>> office; >>>> the other an private flat in Paris. >>>> >>>> >>>> >>>> Arjo. >>>> >>>> >>>> >>>> Van: owner-l...@light.realsoft3d.com >>>> [mailto:owner-l...@light.realsoft3d.com] Namens Jason Saunders >>>> Verzonden: maandag 19 juli 2010 17:03 >>>> Aan: user-list@light.realsoft3d.com >>>> Onderwerp: Fryrender plugin support >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> Any votes for development starting on a plug-in for using this render >>>> engine >>>> in Realsoft ? >>>> >>>> >>>> >>>> Seeing as all the other major and not so major 3D apps have it >>>> supported, >>>> makes sense to try and catch up me thinks. >>>> >>>> >>>> >>>> www.randomcontrol.com/fryrender-gallery >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> Jason >>>> >>>> >>>> >>>> >>> >>> >>> >> >
