tag:blogger.com,1999:blog-27901662.post505978709461836579..comments2024-03-08T10:08:22.607+00:00Comments on Zack Rusin: The software rendererZackhttp://www.blogger.com/profile/16222054590923441165noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-27901662.post-33049516301967050482011-01-17T07:43:29.825+00:002011-01-17T07:43:29.825+00:00Swiftshader started as open source, called swShade...Swiftshader started as open source, called swShader. Although the project was removed from sourceforge, you can still download it from<br />ftp://ftp.funet.fi/pub/graphics/packages/swshader-softwireAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-61465144004161105632010-10-21T21:31:33.075+01:002010-10-21T21:31:33.075+01:00Hi. I have a multicore software renderer (opengl b...Hi. I have a multicore software renderer (opengl based). It can utilize up to 4 cpu cores, has linux and windows support. It can run quake3 playable (with some glitches) on a modern computer. <br /><br />Its unreleased since ~2 year now. I made several polls and votes on big linux community sites about the stuff. <br /><br />-on some sites, i got only 10-15 reply.<br />-on some sites, i got 20-30 reply, half of them saying: ITS SHIT, EVEN A GEFORCE2 IS MUTCH BETTER, GO TO THE FUCK! YOU SUCK!<br /><br />but mostly: no interest. Peoples just dont care. Sad.<br /><br />-GeriAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-16312589344967586512010-10-18T05:39:09.272+01:002010-10-18T05:39:09.272+01:00Hey Zack,
What is the status of the vertex llvm pi...Hey Zack,<br />What is the status of the vertex llvm pipe? <br />I think that right now it generates only the fetch vertex shader and emit parts. Any plans to extend it to also generate clipping and viewport? How about rasterization?Unknownhttps://www.blogger.com/profile/01547515845874865918noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-18165797968557866222010-04-01T12:16:48.434+01:002010-04-01T12:16:48.434+01:00Will this stuff run on chrome native client?Will this stuff run on chrome native client?JDhttps://www.blogger.com/profile/01210560990799975020noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-84940384998902609352010-03-14T11:51:31.102+00:002010-03-14T11:51:31.102+00:00@Zack
This is better than I expected. Making infr...@Zack<br /><br />This is better than I expected. Making infrastructure for multithreaded rendering is really not easy. I tried to write multithreaded 2d renderer in <a href="http://code.google.com/p/fog/" rel="nofollow">Fog-Framework</a> and it works, but it can be really better. I designed rendering to be asynchronous, but performance is degraded when painting very small objects.<br /><br />Thanks for your work, it's really interesting.Petr Kobalíčekhttps://www.blogger.com/profile/15634384573845850706noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-24856217816759853182010-03-13T21:14:23.112+00:002010-03-13T21:14:23.112+00:00@Petr Kobalíček: Not quite. There's a number o...@Petr Kobalíček: Not quite. There's a number of things that are important here. Whether an algorithm is suited for parallelization is not a matter of just running it in a separate thread, so comparing an algorithm that was designed with parallelization in mind versus an algorithm that was not, based on how they perform when they're not parallelized is a bit silly. Second of all the number of threads vs performance doesn't scale linearly. The current algo scales very well, but obviously not linearly. And third of all currently only the rasterizer is threaded meaning that the rest of the pipeline runs in a single thread. So all in all the difference will be a lot bigger than 2x (and that magnitude will only be relevant to this particular benchmark). Having said that, one can force llvmpipe to run everything in a single thread (by exporting LP_NUM_THREADS variable) for a more detailed analysis.Zackhttps://www.blogger.com/profile/16222054590923441165noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-62729482940528065192010-03-13T16:06:11.256+00:002010-03-13T16:06:11.256+00:00Hi Zack,
You said that MESA renders the scene at ...Hi Zack,<br /><br />You said that MESA renders the scene at 3.5 fps. I think that MESA is not multithreaded so if we compare performance per cpu core, we get 6.25 (25 / 4). This means that the presented backend is about twice as fast as MESA per cpu core, is that assumption correct?Petr Kobalíčekhttps://www.blogger.com/profile/15634384573845850706noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-75857180941203949162010-03-12T21:33:51.925+00:002010-03-12T21:33:51.925+00:00Is any of this newfangled Gallium stuff in use in ...Is any of this newfangled Gallium stuff in use in Linux distros, or is it still in the TomorrowLand of dev blog posts?<br /><br />The <a href="http://www.mesa3d.org/faq.html" rel="nofollow">Mesa FAQ</a> doesn't say (no mention of Gallium in any of the obvious places). The Mesa OpenGL library has incorporated "Gallium3D infrastructure" since <a href="http://www.mesa3d.org/relnotes-7.5.html" rel="nofollow">Mesa 7.5</a>, but says nothing about when it's actually used.<br /><br />AFAICT Gallium <i>might</i> be used in software OpenGL rendering, but as of October 2009 the Gallium ATI driver (different from my r300_dri.so driver?) was <a href="http://www.phoronix.com/scan.php?page=news_item&px=NzYwMA" rel="nofollow">not ready for primetime</a>. But damn it's hard to figure out. Does <b>glxgears -info</b> print "ZOMG I'm using Gallium!!" to a terminal?<br /><br />(I've heard a lot about Borat in a man thong, but I've never seen that in real life either.)skierpagehttps://www.blogger.com/profile/04480517078252023572noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-29567342446279537662010-03-12T10:59:51.898+00:002010-03-12T10:59:51.898+00:00@Yolande: AFAIK yes. Look at git://anongit.freedes...@Yolande: AFAIK yes. Look at git://anongit.freedesktop.org/git/mesa/mesaAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-81415017658726848702010-03-12T10:28:59.742+00:002010-03-12T10:28:59.742+00:00Wonderful! Is this work open source, btw?Wonderful! Is this work open source, btw?3nachtegaaltjeshttps://www.blogger.com/profile/10407941612010261926noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-22542736005181248902010-03-12T01:47:13.118+00:002010-03-12T01:47:13.118+00:00@Anonymous: No, not yet at least. It's just VM...@Anonymous: No, not yet at least. It's just VMware folks right now. It's a good point though, we have been discussing the fact that besides the purely software based options llvmpipe would be an almost perfect bare-bone Larrabee driver (would have to adjust vector width and sampling) so there certainly would be enough incentives in it for Intel to take an active role in llvmpipe.<br /><br />@Lars: Actually I'm not even sure. Whatever the default is when running that anholt.dm_68 demo on a stock openarena install. I think it's 640x480.<br /><br />@Brice Goglin: it's the Gallium thread lib which uses pthreads on GNU/Linux.<br /><br />@Anonymous: We are using vectors which are a native type in LLVM and as TechMage89 pointed out SIMD is very much part of what LLVM does (but in some critical paths we are resorting to calling the SSE intrinsics through LLVM). And yes we are code-generating, recompiling and caching (within reason) the entire rendering pipeline when relevant state changes.Zackhttps://www.blogger.com/profile/16222054590923441165noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-10046676279146017122010-03-11T23:27:10.779+00:002010-03-11T23:27:10.779+00:00llvm does take advantage of SIMD processing... tha...llvm does take advantage of SIMD processing... that's a fundamental part of its design.<br /><br />Having a decent software OpenGL implementation will really nice for two reasons:<br /><br />-Machines that don't have working hardware support for some reason will be a *lot* more usable.<br /><br />-Potentially, machines that have only partial hw acceleration (eg. my tablet with an Intel GMA950, which doesn't have hw t&l) will be a lot faster if llvmpipe can be hooked in to existing drivers.Unknownhttps://www.blogger.com/profile/05252120825812650706noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-80151403234765761862010-03-11T22:32:53.945+00:002010-03-11T22:32:53.945+00:00Are LLVM is trying to vectorize things? Or are you...Are LLVM is trying to vectorize things? Or are you working on vectorization (SSE) from the start?<br /><br />Question about pthreads is also interesting? Are threading everything manually?<br /><br />I have question about compilation strategy. Are you recompiling on the fly whole rasterize for example when game/application changes rendering options (i.e. fullscreen antialiasing or other global options? This will generally make much smaller codebase, make optimalisaion/inlineing more aggressive and save some memory and branch mispredictions.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-49569946176501875642010-03-11T21:58:47.964+00:002010-03-11T21:58:47.964+00:00What kind of thread model do they use ? OpenMP ? p...What kind of thread model do they use ? OpenMP ? pthread ?Brice Goglinhttps://www.blogger.com/profile/02284122214286518824noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-5944140952910000102010-03-11T17:51:29.148+00:002010-03-11T17:51:29.148+00:00Great news!
At what resoulution did you run your O...Great news!<br />At what resoulution did you run your OpenArena test?Larsnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-59473796891413602702010-03-11T17:51:17.521+00:002010-03-11T17:51:17.521+00:00Very cool!
Has Intel given you any support since ...Very cool!<br /><br />Has Intel given you any support since they've tried for years to get effective CPU based rendering?Anonymousnoreply@blogger.com