Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel Develops Linux 'Software GPU' That's ~29-51x Faster (phoronix.com)

Posted by Soulskill on from the harder-better-faster-stronger dept.

An anonymous reader writes: Intel is open-sourcing their work on creating a high-performance graphics software rasterizer that originally was developed for scientific visualizations. Intel is planning to integrate this new OpenSWR project with Mesa to deploy it on the Linux desktop as a faster software rasterizer than what's currently available (LLVMpipe). OpenSWR should be ideal for cases where there isn't a discrete GPU available or the drivers fail to function. This software rasterizer implements OpenGL 3.2 on Intel/AMD CPUs supporting AVX(2) (Sandy Bridge / Bulldozer and newer) while being 29~51x faster than LLVMpipe and the code is MIT licensed. The code prior to being integrated in Mesa is offered on GitHub.

111 comments

  1. How does it compare to a low-end graphics card? by Anonymous Coward · · Score: 5, Insightful

    That's the really interesting question, since on board graphics just tend to work nowadays and the only real use case of such software for a consumer is as a fall back for when it doesn't and in that case the fancy graphics tend to get turned off anyway.

    1. Re:How does it compare to a low-end graphics card? by edxwelch · · Score: 3, Interesting

      Even more interesting question, how does something like Half-Life run on it? Is it a slide show, or is it playable?

    2. Re:How does it compare to a low-end graphics card? by Lunix+Nutcase · · Score: 2

      Probably not optimally since it's for scientific visualization not gaming.

    3. Re:How does it compare to a low-end graphics card? by Kjella · · Score: 2

      That's the really interesting question, since on board graphics just tend to work nowadays and the only real use case of such software for a consumer is as a fall back for when it doesn't and in that case the fancy graphics tend to get turned off anyway.

      For the scientific visualizations they use it for it's probably quite good, since they're not using a GPU. For gaming and such a consumer might want it's probably bad since it is has high vertex complexity and low shader complexity. So lots of details using primitives, but not all the shader work to make realistic graphics. It seems like a special case though.

      --
      Live today, because you never know what tomorrow brings
    4. Re:How does it compare to a low-end graphics card? by Billly+Gates · · Score: 1

      That's the really interesting question, since on board graphics just tend to work nowadays and the only real use case of such software for a consumer is as a fall back for when it doesn't and in that case the fancy graphics tend to get turned off anyway.

      Not good at all! Boy this older cpu is just not cutting come to think of it.

      I wonder if a nice shiny new i7 extreme edition would be in order for decent performance?

      --
      http://saveie6.com/
    5. Re:How does it compare to a low-end graphics card? by im_thatoneguy · · Score: 1

      There are a lot of applications I can think of:

      1) Virtualization which often doesn't support GPU sharing. I would love this on HyperV guests.
      2) Remote Desktop scenarios where the GPU won't load.
      3) Servers with no on-board GPU at all but rely on OpenGL for specific UI elements.

    6. Re:How does it compare to a low-end graphics card? by TheRaven64 · · Score: 3, Interesting
      I've not tried it, but to give a few data points:

      I have a slow AMD E-350 (1.6GHz, dual core, low power chip) in the machine I use as a media centre. With the original MESA software fallback, I got about 3 frames per second in the UI. It was totally unusable. After FreeBSD gained support for the GPU, I tried it again and got about 20-30fps. This seemed a bit low, and I discovered that I'd misconfigured it and it was still using the software fallback, only now it was using LLVMPipe. I don't know how much faster the GPU actually is, because at 60fps it hits vsync and doesn't try to go faster, though CPU usage drops from 100% to around 10% (of one core). Of course, this CPU doesn't have AVX, so won't benefit from this code.

      The release announcement has a couple more details. This new back end is optimised for workloads with large vertex counts but simple shaders and for machines with a lot of cores. There are a lot of ways that you can make OpenGL shaders faster if you're optimising for the simple case. Half Life 1 works on a fixed-function pipeline, so should be fast on this. Half Life 2 uses a bit more by way of shaders, but possibly not enough to cause it to struggle. Stuff that runs well on a GPU is likely to also run well on multiple cores, if you get the synchronisation right, but the existing LLVM pipe uses a single thread.

      My main interest in this is whether you can turn off the GPU entirely for normal compositing desktop workloads and whether it will make a big difference to the power consumption if you do. Compositing desktops generally do a lot of simple compositing, but have very simple shaders and quite simple geometry. I'd be very interested to see whether doing this on the AVX pipelines is cheaper than having an entire separate core doing the work, especially given that the GPU core is generally optimised for more complex graphical workloads.

      --
      I am TheRaven on Soylent News
    7. Re:How does it compare to a low-end graphics card? by Anonymous Coward · · Score: 0, Flamebait

      I never understood this "mother-fucking" meme. It doesn't make sense and seems to be limited to the US. Who would not want to have a gorgeous, sexually active mother who attracts young guys without problem? And what kind of total loser fucks a sixty year old MILF when he's a twenty- or thirty-something?

    8. Re:How does it compare to a low-end graphics card? by mikael · · Score: 2

      Scientific visualization applications use data sets that are in the Gigabyte range - a volume cube of 1024x1024x1024 representing a supernova and streamed off a supercomputer, or maybe they have a high-resolution grid of an aircraft and jet engines and and want to see where the areas of turbulence are. With all the CPU cores available, it's easier to render on the CPU's that it is to funnel the data into GPU memory just to render one frame.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    9. Re:How does it compare to a low-end graphics card? by WorBlux · · Score: 1

      Couldn't buffers be shared via DMA and PRIME?

    10. Re:How does it compare to a low-end graphics card? by Anonymous Coward · · Score: 0

      I've played HL1 on a Pentium 1, 166 Hz, without a dedicated GPU. Windows 98...

    11. Re:How does it compare to a low-end graphics card? by TheRaven64 · · Score: 1

      HL1 had three renderer back ends. A software one, an OpenGL one, and a Direct3D one. The software one omitted a lot of the effects of the others (and supported lower resolutions). If you still have that P166, you can make it use the default (software) OpenGL implementation. I got about 0.3fps when doing that, though with the software implementation it could manage a playable frame rate quite easily. For Quake 2, AMD also released a custom version of the software renderer that used 3DNow and ran a bit faster than the default one on chips that supported these extensions.

      --
      I am TheRaven on Soylent News
  2. mailing list thread by Anonymous Coward · · Score: 0

    the mailing list thread is fascinating. participants seem to want intel to contribute to llvmpipe even though it is focused on a different use case (desktop and graphics) vs. the intel one of compute.

  3. Up to by itamihn · · Score: 2

    Not 29-51x faster, but _up to_ 29-51x faster (in a specific use case -for which it was developed-)

    1. Re:Up to by Anonymous Coward · · Score: 0

      Then it should have just said "up to 51x faster" ... or more ...

    2. Re:Up to by itamihn · · Score: 1

      Good point.

    3. Re:Up to by ShanghaiBill · · Score: 4, Insightful

      Then it should have just said "up to 51x faster" ... or more ...

      "Up to" is just a weasel word way of saying "less than".

      I have up to a billion dollars in my pocket.

    4. Re:Up to by haruchai · · Score: 1

      Not exactly. It usually means that under some plausible, but very rare scenario, it can & will achieve that level of performance.
      If there's a plausible scenario under which you'll find a billion real (preferably US) dollars in your pocket, I think many of us would love to hear it.

      --
      Pain is merely failure leaving the body
    5. Re:Up to by UnknownSoldier · · Score: 1

      You're comparing Apples and Oranges.

      Either you *do* have a billion dollars OR you *don't*. There is only _one_ use case.

      If this rasterizer is 51x faster at stencil operations, but only 4x then MESA everywhere else, then there it is perfectly fine to say "Up to 51x faster".

      What is the _context_ ? That's the crux of the issue.

    6. Re:Up to by Anonymous Coward · · Score: 0

      A check. Next!

      (Yes, I ignored your "real" part, since that was added by you, arbitrarily.)

    7. Re:Up to by Anonymous Coward · · Score: 0

      It usually means that under some plausible, but very rare scenario, it can & will achieve that level of performance.

      That is not the case in any form of advertisement and even less so with technology. In the general case the mentioned speed increase is in one component of the system and the only way to measure that is by running the component in complete isolation. You will note that while possible nobody will disassemble ( or just rewrite most of the source ) to interact with that specific component of that intel software, rather people will use the software in its completeness and never see the impossible 51x faster.

    8. Re:Up to by hattig · · Score: 1

      In this case, running on a 22-core Xeon chip. You won't get 29x-51x faster on your quad-core Skylake.

      I.e., most of the speed-up is from multi-threading and use of AVX. Which I'm a little surprised that LLVMPipe didn't have - but then again, it probably wasn't too important at the time, and correctness was most important.

    9. Re:Up to by Anonymous Coward · · Score: 0

      Sure, but you could say, "my pocket is so big that it can hold up to a billion dollars", and be completely accurate.

    10. Re:Up to by haruchai · · Score: 1

      The Intel software has a far better chance of achieving its max performance than of that check being cashable.

      --
      Pain is merely failure leaving the body
    11. Re:Up to by Anonymous Coward · · Score: 0

      Like my internet connection is 'up to...'?

    12. Re:Up to by Anonymous Coward · · Score: 0

      Thanks, Captain Obvious.

    13. Re:Up to by ShanghaiBill · · Score: 1

      If there's a plausible scenario under which you'll find a billion real dollars in your pocket, I think many of us would love to hear it.

      Here you go.

    14. Re:Up to by haruchai · · Score: 1

      That's exactly why I'd specified both real and USD in my original comment.
      Spend it wisely.

      --
      Pain is merely failure leaving the body
  4. No, it's not for playing games by CajunArson · · Score: 5, Informative

    Despite the ignorance (or perhaps intentional clickbaityness) of the post, nobody at Intel expects this to replace a GPU to do regular graphics or play games. They haven't been investing big money in going from effectively zero GPU power in 2010 to beating AMD's best solutions in 2015 to replace it with a software gimmick now.

    This renderer is designed to do all kinds of graphical visualization that doesn't make sense to do with a traditional GPU, just like running POVRay or rendering complex images in scientific applications.

    It is NOT going to replace a real GPU for what a real GPU does.
    Nobody at Intel ever said it would replace a GPU.
    The Internet, however, isn't so smart.

    --
    AntiFA: An abbreviation for Anti First Amendment.
    1. Re:No, it's not for playing games by hairyfeet · · Score: 2

      "They haven't been investing big money in going from effectively zero GPU power in 2010 to beating AMD's best solutions in 2015 to replace it with a software gimmick now."...quit bogarting bro, share some of that crazy smoke weed you been puffing. after all if you think Intel graphics are gonna beat Radeons? That be some damned good shit now!

      --
      ACs don't waste your time replying, your posts are never seen by me.
    2. Re:No, it's not for playing games by goarilla · · Score: 1

      He's comparing the Iris Pro 6200 to AMD's offerings. And he is somewhat right: http://www.tomshardware.com/re....

    3. Re:No, it's not for playing games by Anonymous Coward · · Score: 1

      AMD's on-chip offerings are badly obsolete, because AMD has skipped a generation in the jump to Zen (so all its current CPU line-up are basically dinosaurs).

    4. Re:No, it's not for playing games by Narishma · · Score: 1

      The Iris Pro 6200 parts beating AMD's APUs here cost at least twice as much for just the processor.

      --
      Mada mada dane.
    5. Re:No, it's not for playing games by hattig · · Score: 1

      Only because AMD stopped at 512 shaders on their APUs, because of memory bandwidth limitations making it pointless to include more. Additionally, being stuck on 28nm didn't help with scaling or power use (although Carrizo does a very good job to be competitive with 14nm Intel chips).

      Intel bypassed that by including a very large on-die memory so they could expand their GPU further and get more performance. This comes at a cost - price.

    6. Re:No, it's not for playing games by Bengie · · Score: 1

      Intel CPUs is actually quite cheap. I paid less for my CPU than my PSU, GPU, SSD, case, and monitor. Just because AMD is cheaper doesn't mean I'm going to saving much money relative to the whole.

    7. Re:No, it's not for playing games by Anonymous Coward · · Score: 0

      Intel motherboards are like 50$ more expensive and aren't backwards or forwards compatible. Older chips don't get cheaper over time. You must buy an expensive new mobo every time you upgrade your PC.

    8. Re:No, it's not for playing games by thechao · · Score: 2

      One of the original authors, here: this is exactly correct. This thing was a toy that we wrote for our own entertainment that grew rapidly out of scale. As a joke, we'd implemented display-lists on OpenGL 1.2 and began playing Quake III. (This required monstrous multi-socket Xeon workstations, with all the fans going flat-out.) It just happens to turn out that (at the time) regular old top-of-the-line GPUs were crashing under the TACC workloads. Weirdly, our rasterizer was both faster than the GPUs (even the high-end ones) [1], and didn't crash. That's where SWR came from. OpenSWR is the natural outgrowth of dealing with academics.

      My interest was in the compiler, the implementation of an "old skool" high performance GL driver, and the texture-unit. The other two guys wanted to write an interpolator, and a threading/caching model—the stuff we never got to do on the old Larrabee projects.

      [1] The workloads didn't fit into the on-card video-ram, so the GPUs were strongly bandwidth bound—maybe 5GB/s; we had >70GB/s of bandwidth at our disposal.

    9. Re:No, it's not for playing games by Anonymous Coward · · Score: 0

      This renderer is designed to do all kinds of graphical visualization that doesn't make sense to do with a traditional GPU, just like running POVRay or rendering complex images in scientific applications.

      Here I remember my first Povray project as a student, rendering boobies was pretty much the first I could think of.
      (gotta love this captcha, asking me to type immature)

    10. Re:No, it's not for playing games by thechao · · Score: 1

      Apparently, I'm not supposed to call SWR a "toy"; it's all grown up. SWR really shines through in terms of performance due to its (nearly) linear scaling on cores. When other rasterizers begin to suffer from communication overhead, SWR keeps going. Thus, if you've only got a few threads, you're not going to see really seriously awesome number—if you've got 16+ threads, that's where SWR is going to shine.

  5. TempleOS by Anonymous Coward · · Score: 1, Funny

    It's not faster than mine. Mine is optimal. I am the best programmer, given divine intellect. We do not allow different drivers for different people. Everybody uses the same driver. We do not allow hidden logic in the GPU. All logic must be in the CPU.

    1. Re:TempleOS by Anonymous Coward · · Score: 0

      Go home, /g/; adults are talking here.

    2. Re:TempleOS by Anonymous Coward · · Score: 0

      You know that guy posts in the programming sub on reddit.com and he's actually treated with a decent amount of respect for his programming accomplishments (regardless of what anybody thinks of his religious beliefs). Would be nice if Slashdot could be as decent.

  6. Yes but? by deviated_prevert · · Score: 0

    Does it run Windows?

    --
    This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call
  7. Finally by Anonymous Coward · · Score: 0

    Something as competently fast as SGI OpenGL for Windows' rasterizer.

  8. Err - bullshit. by queazocotal · · Score: 1, Troll

    ' On a 36 total core dual E5-2699v3 we see performance 29x to 51x that of llvmpipe. '
    Clearly some improvement happens going from single to multithreaded, but I suspect very few desktops have >4 cores, and a vanishingly small number >16.

    1. Re:Err - bullshit. by markus · · Score: 1

      Have you been buying any new hardware recently? My laptop has four physical cores and eight cores when using hyper threading (4/8). My desktop is 6/12 and my always-on home server has 12/24. The newest one of these devices is about two years old; the oldest one closer to five years.

      Multiple cores are a pretty standard feature for a lot of hardware these days. Heck, even cellphones have between four and eight cores these days. So, no, you won't see many home PCs running on 36 cores. But there clearly is a trend towards a lot more cores. If Intel can figure out a way to make good use of this many cores, then they definitely will. It's good for their CPU business.

    2. Re:Err - bullshit. by Anonymous Coward · · Score: 1

      Wait, wait, wait, woa, hold everything... You're telling me, let me be sure I'm sitting down for this... you're telling me, they ran a highly parallel problem (graphics rendering) on a 36-core machine, and it ran roughly 36 times faster than a single-threaded code?

      As Iago put it, "I think I'm going to fall over and DIE from NOT SURPRISE!"

    3. Re:Err - bullshit. by queazocotal · · Score: 0

      Hyperthreading does not meaningfully improve performance of compute-bound tasks.

    4. Re:Err - bullshit. by Anonymous Coward · · Score: 1
      Just in case you didn't realize, LLVMpipe has been at least partially multi-threaded since, like, 2010...

      The Gallium3D LLVMpipe driver does not touch the GPU, so it can be run with any graphics card. However, for efficient performance, you will want to be running a 64-bit operating system and a CPU that supports SSE2.0 or better. LLVM can take advantage of SSE3 and SSE4 extensions too, which will result in even greater performance. To no surprise, the better the CPU you have, the better LLVMpipe will perform. The more cores that the CPU has, the better the performance will be too, as the rasterizer supports threading and tiling.

    5. Re:Err - bullshit. by fnj · · Score: 0

      My laptop has four physical cores and eight cores when using hyper threading (4/8).

      No it doesn't. It has 4 real cores plus 4 hyperthreads that are sorta kinda like cores but not as good.

    6. Re:Err - bullshit. by Anonymous Coward · · Score: 0

      It's for compute clusters. Not your shitty Pentium 4 'rig'.

    7. Re:Err - bullshit. by Bengie · · Score: 1

      It does enhance performance of compute that is memory bandwidth limited and/or the code is not pipelined well enough to take advantage of OoO.

    8. Re:Err - bullshit. by Anonymous Coward · · Score: 0

      My home PC has 1668 cores, although only 4 of those are in my CPU.

    9. Re:Err - bullshit. by viperidaenz · · Score: 1

      Unless it's a Pentium 4, then a cache miss stalls the entire pipeline for both threads.

    10. Re:Err - bullshit. by viperidaenz · · Score: 1

      Kind of like an AMD core then?

    11. Re:Err - bullshit. by Anonymous Coward · · Score: 0

      As Iago put it, "I think I'm going to fall over and DIE from NOT SURPRISE!"

      That doesn't look like something Shakespeare would've written.

    12. Re:Err - bullshit. by im_thatoneguy · · Score: 1

      Bullshit. Clearly some improvement happens going from single to multithreaded, but I suspect very few desktops have >4 cores, and a vanishingly small number >16.

      Well, for one, it's 36 threads, which means 18 cores. Two, the types of computers which this is useful for (multi-processor renderfarms, virtualized guest OSes and compute clusters) you do often have 40+ threads.

      If you want to play Doom 4, go buy a GPU, llvmpipe isn't useful for you either. So there was a solution for a specific group of people who had one solution (llvmpipe) and now those same people now have a much faster solution.

      This is like an announcement that MRI machines have been made 100% more energy efficient and you whining that it only applies to hospitals and not your home refrigerator. No shit.

    13. Re:Err - bullshit. by Anonymous Coward · · Score: 0

      that's hard to believe as it negates practically all of the value of hyperthreading, reducing it to merely saving the overhead of a context-switch

    14. Re:Err - bullshit. by Anonymous Coward · · Score: 0

      He's talking about the parrot Iago of Disney's Alladin.

    15. Re:Err - bullshit. by queazocotal · · Score: 1

      Err - no.
      http://ark.intel.com/products/... - 18 core.
      " a 36 total core dual E5-2699v3 we see performance 29x to 51x that of llvmpipe"
      Two processors, with 18 cores each.

    16. Re:Err - bullshit. by mikael · · Score: 1

      Just go the gaming PC websites, and you'll see that every OS is 64-bit now, and that even the laptop CPU's have at least 4 cores while desktops CPU's can have as many as 8 or more cores. Intel have some CPU's with 6 cores which are hyperthreaded, so that looks like 12 cores to the OS. AMD have at least 8 core CPU's. Then you have dual-socket Intel XEON servers with at two sockets and supporting 18 cores each.
      Even an old laptop from 2005 is dual-core and hyperthreaded.

      Then there are so many ways you can parallelize an application; put different tasks into separate threads, have a data processing task shared across multiple cores, use distributed processing. That's in addition to vectorization using the AVX2 instruction set.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    17. Re:Err - bullshit. by Bengie · · Score: 1

      From the beginning, one of the benefits of hypertheading is hiding the cost of cache misses. Intel has a proof of concept program that uses one thread to prefetch data, which means it gets hit with a cache miss, and the other thread doesn't get the cache miss because the data is ready just in time. Hyperthreading has a 1 cycle context switch overhead, allowing it to quickly change threads for even the shortest stalls.

      The biggest issue HT has against it is split resources, especially the L1 cache. Many types of server workloads are cache sensitive. As for games, many games don't scale well with thread count because of synchronization overhead. HT only gives 10%-20% average gain, meaning each thread runs at 60% peak. The aggregate is a gain for overall throughput, but for single-threaded performance, it takes a hit.

    18. Re:Err - bullshit. by Bengie · · Score: 1

      Except when your OS sleeps an HT "core", it effectively deactivates HT for that real core. One of the reasons Win7 runs better than XP on HT cpus is better thread scheduling. It will attempt to use only one HT core per physical core, then place the virtual core into a deep sleep mode, allowing the CPU to run as if HT is disabled.

    19. Re:Err - bullshit. by viperidaenz · · Score: 1

      https://en.wikipedia.org/wiki/...
      Hyperthreading in the P4 killed the whole pipeline.

  9. -22 by Tablizer · · Score: 2, Funny

    I did the math, and got -22x faster. I'll pass on it, Thank You.

    --
    Table-ized A.I.
    1. Re:-22 by dfsmith · · Score: 2

      Are you kidding!? Negative 22x faster means it will produce the image before you asked for it! Please excuse me while I go and render the current NYSE prices....

  10. MIT licensed: going nowhere by Anonymous Coward · · Score: 0

    Projects that use the MIT license generally go nowhere because almost no one except the original party ever contributes back to them.

    1. Re:MIT licensed: going nowhere by Anonymous Coward · · Score: 0

      Projects that use GPL tend to turn to shit because wanna-be fanbois will quickly contaminate the original project.

    2. Re:MIT licensed: going nowhere by Anonymous Coward · · Score: 0

      Like X11!

    3. Re:MIT licensed: going nowhere by TheRaven64 · · Score: 1

      You mean, projects like MESA, X.org, and the existing DRI stack? Of which this is a third-party contribution, under the original license?

      --
      I am TheRaven on Soylent News
    4. Re:MIT licensed: going nowhere by KGIII · · Score: 1

      He said most and he's correct. Most OS (of any license) goes nowhere. I'd expect most of it never even gets finished. I don't even license any of the code I release - I just give it away without any license at all. It's not good enough to steal and usually does just one thing that I had to do. Heh. I've not done that in a while.

      Anyhow, no... I'm pretty sure I've read several actual studies (well, extracts) that show an absurdly high number of OS projects go nowhere. You're not reading properly and assuming they said that all of them go nowhere. As for MIT/BSD/GPL? It's the same across the board and the 'point' they made is immaterial concerning that. OS software does, for the most part, go absolutely nowhere. See all the abandoned and unfinished projects on SF/GIT/et all. for examples.

      --
      "So long and thanks for all the fish."
    5. Re:MIT licensed: going nowhere by TheRaven64 · · Score: 1

      I don't even license any of the code I release - I just give it away without any license at all

      These two are contradictory, unless you live in a jurisdiction where you can explicitly place things in the public domain and you are doing so. Without a license, no one who receives the code has the right to do anything with it.

      --
      I am TheRaven on Soylent News
    6. Re:MIT licensed: going nowhere by KGIII · · Score: 1

      I do. I live in the US. We can place things in the public domain at will. All of it includes a "Public Domain" bit of gibberish in it. You can steal it (I guess) and sell it, you can change it, you can throw sticks at it. I don't care. It's not good enough to do anything worth paying for - often it's simply scripts to do something I needed. Hell, not even often, I've not done so in years. I'm a much more passive consumer than I used to be.

      If you're curious about the legality, it's called "dedicating" and there's a little information here:
      http://fairuse.stanford.edu/ov...

      Specifically here:
      http://fairuse.stanford.edu/ov...

      The whole thing's an interesting read, though. I do have, well had, several patents and a bunch of internal code that was protected but that's not the stuff I release to the public. That code wasn't very good, either. That's why I hired professionals.

      --
      "So long and thanks for all the fish."
  11. Holy shit by Anonymous Coward · · Score: 1, Insightful

    the comments on this story pretty much put the nail in the coffin for this website. News for nerds? Not based on the replies of people who think this is for desktops. Seriously, what the fuck?

    1. Re:Holy shit by wonkey_monkey · · Score: 2

      Intel is planning to integrate this new OpenSWR project with Mesa to deploy it on the Linux desktop

      What hardware do I need?

        * Any x86 processor with at least AVX (introduced in the Intel
            SandyBridge and AMD Bulldozer microarchitectures in 2011) will
            work.

        * You don't need a fire-breathing Xeon machine to work on SWR - we do
            day-to-day development with laptops and desktop CPUs.

      TL:DR; it's for whoever wants to use it on whatever hardware they want to use.

      --
      systemd is Roko's Basilisk.
  12. fanbois with a pottymouth by gavron · · Score: 1

    Yes, because you had a valid point to make, I'm sure, but couldn't articulate it without going into the toilet.
    As a result the only one covered in the brown stuff is you, and not those "mysterious GPL fanbois" for fear of whom you wear your aluminum-foil hat.

    Go gently into the night, and bring toilet paper, and don't come back.

    E

    1. Re:fanbois with a pottymouth by Anonymous Coward · · Score: 0

      Most open source projects regardless of license will go to shit because no one but the original party gives a damn about their particular code.

    2. Re:fanbois with a pottymouth by Anonymous Coward · · Score: 0

      To be fair, the original poster did suggest that MIT licenced projects go nowhere. And yes, this one was slightly more juvenile than the parent comment - but there are GPL fanbois. They turn up and do things like complain that something should be GPL, rather than MIT or BSD otherwise TheCodeWillGetStolen. Or complain that Linux is GPL 2 and should be GPL 3 for similar reasons. To be fair, this one didn't *quite* go that far.

    3. Re:fanbois with a pottymouth by WorBlux · · Score: 1

      Low-level software or standard-bearer software like this is a good canidate for MIT, you actually want to able to include it in Windows*, *BSD, and Mac OSX. At one point AMD was considering porting MESA to embedded windows to significantly reduce memory overhead. Why not? there's not a whole lot of incentive to create secret sauce or introduce incompatibilities

  13. Massive Scientific Visualization by friedmud · · Score: 3, Informative

    This is seriously useful for massive scientific visualization... where raw rendering speed isn't always the bottleneck (but of course, faster is better).

    We do simulations on supercomputers that generate terabytes of output. You then have to use a smaller cluster (typically 1000-2000 processors) to read that data and generate visualizations of it (using software like Paraview ( http://www.paraview.org/ ) ). Those smaller clusters often don't have any graphics cards on the compute nodes at all... and we currently fall back to Mesa for rendering frames.

    If you're interested in what some of these visualizations look like... here's a video of some of our stuff: https://www.youtube.com/watch?...

    1. Re:Massive Scientific Visualization by robi5 · · Score: 1

      The simulation part is very performance intensive, but the visualizations themselves look like something you could do with WebGL, or often, just some SVG and CSS. What are the thousands of cores used for? Not even a super-high resolution seems warranted, because of the continuity of material properties etc. Apparently the result is some 3D model which can be interactively rotated and zoomed, likely on a single local machine that takes direct input from the user, i.e. the thousands of cores don't even seem to do the real time part of the rendering.

    2. Re:Massive Scientific Visualization by jabuzz · · Score: 1

      Hum, rather than dicking about with a software render get some GPU's onto your cluster. I find it hard to believe that HPC clusters exist in 2015 with zero GPU nodes, and if they do the solution is to add the GPU nodes.

      Heck our next cluster (in planing stages) is going to have all the login nodes with GPU's (Dell Precision R7910, four GPU's per login node) rather than dedicated visualization login nodes, because life is too short. That is in addition to compute nodes being equipped with GPU's.

    3. Re:Massive Scientific Visualization by Anonymous Coward · · Score: 1

      Classic use of "just" to completely minimize the argument and set up your straw man.

      Hint: if its $$$ to render and they still do so, its probably because they need to.

    4. Re:Massive Scientific Visualization by Anonymous Coward · · Score: 0

      Visualization isn't really about the rendering of the data... Yes, often it's just a 3D model or a vector image.

      Scientific visualization is more about getting that massively huge amount of data into a state that you can view... and often without knowing what it is you're looking for.

    5. Re:Massive Scientific Visualization by friedmud · · Score: 1

      Like I said: raw rasterizing isn't the main bottleneck... reading the data and transforming the data is.... both things better done on the CPU. Drawing frames takes up a very small amount of the overall runtime... but it's always nice to speed it up!

      GPUs wouldn't help much in this scenario... and our CPU clusters are used for many things other than visualization.

      Yes, we do have some dedicated "viz" clusters as well... but we typically don't use them because they are too small for loading many TB of data.

    6. Re:Massive Scientific Visualization by friedmud · · Score: 1

      Like I mentioned... the actual drawing is NOT the bottleneck (but every little bit helps).

      Those images you see on the screens are backed by TB of data that has to be read in and distilled down before being renderable. That's what the thousands of cores are doing.

      Also: those rotateable ones you see in the beginning are small. If you skip forward to the 2:30 mark you can see some of the larger stuff (note that we're not interactively rotating it). That movie at 2:30 took 24 hours to render on about 1,000 cores.

      Again: The bottleneck was NOT rendering time. It was the time to read TB from disk and crunch the data down to the point where you had a renderable image.

    7. Re:Massive Scientific Visualization by friedmud · · Score: 1

      Exactly right.

    8. Re:Massive Scientific Visualization by robi5 · · Score: 1

      Thanks, got it!

    9. Re:Massive Scientific Visualization by Anonymous Coward · · Score: 0

      get some GPU's onto your cluster.

      Easier said than done when it's not "your" cluster. Many of the DoE machines are shared resources across many labs that were designed with certain goals in mind. And then from a cost standpoint, if you've got 2000 nodes and want to add a GPU to the node, $2k each for a Tesla x 2k nodes = $4M, and that's just for parts, not to mention time and labor to actually make it all work. Not exactly a simple purchase order request when it wasn't planned that way from the beginning.

      I find it hard to believe that HPC clusters exist in 2015 with zero GPU nodes.

      It's pretty common when you start talking about flagship-class installations. IBM BlueGene Q, for instance, is all custom PowerPC SOCs. LOTS of Cray systems in active use and planned deployment have no GPUs at all. Trinity, a new machine coming online at Los Alamos, for instance, will have ~10k Haswell nodes and ~ 10k Knight's Landing nodes (next gen Xeon Phi CPUs but used as bootable host CPUs, not accelerators), no GPUs. Many codes are just not well suited to exploit GPUs and / or they come with a significant development cost to do so. Having an enormous number of CPU cores lets you work with MPI and OpenMP instead of also needing to toss CUDA into the mix. You also remove the additional need to mange memory transfers to and from the device. Even with GPUs, you're still limited to what fits in the GPU's memory. For small to medium-sized models, this may be fine, but when your geometry that you're trying to render gets to be 16GB, 32GB, or more on each node, then GPUs, even the beefiest Tesla, really start to fall apart. This is where OpenSWR can really shine.

  14. Any BSD equivalents? by unixisc · · Score: 1

    If Intel is doing this, they might as well do it for BSD versions of this as well, something that might be leveraged across the vanilla UNIX board

    1. Re:Any BSD equivalents? by Anonymous Coward · · Score: 0

      Uh. Mesa software rendering already is supported across all Unices, and a bunch of other OS: Haiku, AROS, etc.

    2. Re:Any BSD equivalents? by TheRaven64 · · Score: 1

      It plugs into MESA in the same place as LLVMPipe and is entirely userspace. It will probably just work on *BSD.

      --
      I am TheRaven on Soylent News
  15. Re: How does it compare to a low-end graphics card by Anonymous Coward · · Score: 0

    Why are you running software with graphical UI elements on a server to begin with?

  16. Re: How does it compare to a low-end graphics card by Anonymous Coward · · Score: 0

    Main reason is lazy developers.
    For example, Ghost recon does not have a standalone console server - although it can be run with command switches to start the server, when run it still loads the game GUI, which requires graphics to be displayed. The was easier for the developers at the time.
    Not my fault, not much I can do about it, just what we were given to work with.

  17. 15 quid gets you this kind of performance by Anonymous Coward · · Score: 0

    If anyone seriously things this is a good idea they need their lumps looking at. A Geforce 4 (£15) has equivalent performance to a ~£3500 Intel chip. So it will be better if it falls back to software rendering. Great. It seems to me fixing it so software is *never* the option is the only answer. And to all those people using massive compute clusters for scientific visualisations you've wasted your grant money building relics. Transform the triangles on your 15 pound accelerator, and read them back out of the frame buffer - seriously. Then give the money saved to the developers of your software who are living in the 90s to fix it.

  18. This isn't Linux... by chaoskitty · · Score: 1

    Come on - people here should know better. It's 2015 and the "Oooh! Linux sounds cool, so let's use that word for everything!" fad should be over now.

    Everything open source is NOT Linux. Linux is a friggin' kernel. This is open source software. It coincidentally gets used with GNU/Linux often. BUT IT'S OPEN SOURCE SOFTWARE.

    Repeat after me: open source does not mean Linux. Linux does not mean open source.

  19. Re: How does it compare to a low-end graphics card by 3.5+stripes · · Score: 1

    Because game engines for automated builds, that's why..

    --


    He tried to kill me with a forklift!
  20. Does this mean by Anonymous Coward · · Score: 0

    I can finally have something akin to hardware acceleration in my KVM Windows guests? The Fedora QXL stable/latest isn't doing much.

  21. Would it help Cygwin X Windows? by 140Mandak262Jamuna · · Score: 1
    I have access to a few linux boxes but my main work desktop is windows 7. I use cygwin Xwindows server to run X clients in linux boxes. The X windows is implemented in software and it does not support anything above OpenGL1.8. I think it uses Mesa as the rasterizer. If it gets faster rasterizer and higher OpenGL support it would help users. This would beat Windows Remote Desktop that too does not support anything about OpenGL1.8, but I am sure someone will port Mesa support for remote desktop too, if it helps.

    The big deal, AFAIC is OpenGL 3 support. There was a big change from 1.8 to 2, where they added rendering based on C code interpreter based shaders. All my simple OpenGL code based on shaders don't work in 1.8. Hoping this would change that.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  22. Will it run Crysis? by Anonymous Coward · · Score: 0

    Well, will it?

  23. Build remote gaming platform and sell out to Sony by tepples · · Score: 1

    Why are you running software with graphical UI elements on a server to begin with?

    Have you ever heard of Remote Desktop? Two companies even did this with games (Gaikai and OnLive), and both ended up acquired by PlayStation.