Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: LLVMpipe Still Doesn't Work For Linux Gaming

  1. #1
    Join Date
    Jan 2007
    Posts
    15,653

    Default LLVMpipe Still Doesn't Work For Linux Gaming

    Phoronix: LLVMpipe Still Doesn't Work For Linux Gaming

    For those curious what OpenGL gaming frame-rates are like if trying to run LLVMpipe on the latest Intel Ivy Bridge processors, here are some numbers...

    http://www.phoronix.com/vr.php?view=MTEwODM

  2. #2

    Default

    Quake 2 will be playable, but it works without llvm. Btw. what's the point of this? If someone has old PC without graphic acceleration he has slow CPU as well and with llvm his desktop will be slow as crap.
    Last edited by kraftman; 05-28-2012 at 04:54 AM.

  3. #3
    Join Date
    Jun 2006
    Location
    Portugal
    Posts
    543

    Default

    Quote Originally Posted by kraftman View Post
    Quake 2 will be playable, but it works without llvm. Btw. what's the point of this? If someone has old PC without graphic acceleration he has slow CPU as well and with llvm his desktop will be slow as crap.
    Virtual machines, servers, working desktop before you install the newest drivers for new hardware, working desktop if there are no newest drivers, fallback for bugs, ...

  4. #4
    Join Date
    Dec 2011
    Posts
    2,195

    Default Roadmap?

    Is there any roadmap for LLVMpipe?
    What does the future hold for LLVMpipe?

    How can LLVMpipe be improved?
    Can new functionality be added? If so, what?
    Can it be speed up? If so, how?

  5. #5
    Join Date
    Oct 2008
    Posts
    3,247

    Default

    Quote Originally Posted by uid313 View Post
    Is there any roadmap for LLVMpipe?
    Not really, no.
    What does the future hold for LLVMpipe?
    Well, the next major milestone is GL 3 support. It seems like it's pretty close, so hopefully it makes it as part of the Mesa 8.1 release, but no one has actually committed to making sure that happens.

    How can LLVMpipe be improved?
    Can new functionality be added? If so, what?
    I think the main thing is just adding new features, like GL3. I'm not sure anyone has thought about the best way to bring OpenCL support to it yet.
    Can it be speed up? If so, how?
    There was that one project to add a kernel side to the driver, which would let it avoid making a bunch of memory copies that it currently has to do. I'm not sure what the status of that was, if it's in with some of the DMA-BUF work or what. Beyond that, I don't think anyone is particularly focused on the performance of the driver. Just adding new features seems to be what most people are looking at.

  6. #6
    Join Date
    Dec 2011
    Posts
    2,195

    Default Features?

    Does LLVMpipe use GEM? TTM? KMS? video acceleration?

  7. #7
    Join Date
    Jul 2011
    Posts
    76

    Default Is OpenMP used?

    Are multiple threads being used or only a single thread?

  8. #8
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by uid313 View Post
    Does LLVMpipe use GEM? TTM? KMS? video acceleration?
    KMS is something that would be used by your DDX, not really by LLVMpipe. LLVMpipe just uses LLVM's optimizing compiler (although how much optimization it does is debatable, considering the poor performance of its generated code at least for x86 binaries) to back OpenGL calls and produce "efficient" native code to run on the CPU for these calls. It could probably support other state trackers, but right not there's no point.

    It doesn't use/support GEM or TTM because that would require an LLVMpipe kernel module which doesn't exist (yet?).

    Video acceleration would be pointless, since you could write an equally-fast (or faster) software decoder for the formats you want, or just use ffmpeg's, which are probably going to be the fastest software decoders available.

    Again, the whole point of llvmpipe is that there's no GPU hardware being used, so any features you can think of that are obviated by existing software solutions (such as video decoding) are probably not going to be worked on.

  9. #9
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    597

    Default

    Quote Originally Posted by allquixotic View Post
    Video acceleration would be pointless, since you could write an equally-fast (or faster) software decoder for the formats you want, or just use ffmpeg's, which are probably going to be the fastest software decoders available.

    Again, the whole point of llvmpipe is that there's no GPU hardware being used, so any features you can think of that are obviated by existing software solutions (such as video decoding) are probably not going to be worked on.
    I'd say it's quite the opposite - support gets added to llvmpipe to compare and debug the hardware drivers. That's llvmpipes real purpose - not games

  10. #10
    Join Date
    Oct 2009
    Location
    Brisbane, Queensland, Australia
    Posts
    154

    Default

    And now for a repeat of these LLVMpipe benchmarks with LLVM 3.1?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •