Announcement

Collapse
No announcement yet.

LLVMpipe Now Exposes OpenGL 4.2 For GL On CPUs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pal666
    replied
    Originally posted by starshipeleven View Post
    Since for GPUs the "muh singlethred puhfomance" argument never applied, even when CPUs hit a brick wall and Moore's Law died (somewhere in the Sandy/Ivybridge era) GPUs have kept increasing their performance each generation at more or less the same speed.
    i didn't check it, but i expect llvmpipe to be multithreaded just like gpus

    Leave a comment:


  • LinAGKar
    replied
    Originally posted by LinAGKar View Post
    Except there are 11 items required for OpenGL ES 3.1.
    Sorry, nevermind, I was looking at the wrong column.

    Leave a comment:


  • airlied
    replied
    Originally posted by dragon321 View Post
    It's funny how llvmpipe is conformant with OpenGL 4.4 but not 4.3 because one extension is missing. Well, I suppose it won't be very long until llvmpipe catch OpenGL 4.5 or even 4.6.

    Zink also achieves new milestones pretty quick. It's two extensions away from OpenGL 3.1. A lot of "modern OpenGL" applications are targeting at least 3.3 so it will be nice when Zink achieve this milestone.
    a) it's not anything conformant, you can only be conformant once you pass the conformance tests and are listed on the official OpenGL site.

    b) it has implemented all the individual features that we wrapped up into GL 4.4, it doesn't mean it can advertise GL 4.4 until it has all the prior features done as well.

    It's likely GL 4.3 will be all it advertises once I've completed all the GL 4.5 features until it passes conformance.

    Dave.

    Leave a comment:


  • airlied
    replied
    Originally posted by AsuMagic View Post

    Anecdotally, I can run simple 2D games in 1440p near 60fps with my 3900X. Considering this is a fairly high resolution, that isn't quite terrible for an OpenGL game.
    Also anecdotally, llvmpipe doesn't seem to be able to parallelize very well. I usually get ~50% CPU usage on that machine. Unless that has to do with SMT?
    https://gitlab.freedesktop.org/mesa/..._requests/4385
    might help, I can saturate my CPU quite a bit more with that. (not sure it merges clean)

    Leave a comment:


  • dragon321
    replied
    It's funny how llvmpipe is conformant with OpenGL 4.4 but not 4.3 because one extension is missing. Well, I suppose it won't be very long until llvmpipe catch OpenGL 4.5 or even 4.6.

    Zink also achieves new milestones pretty quick. It's two extensions away from OpenGL 3.1. A lot of "modern OpenGL" applications are targeting at least 3.3 so it will be nice when Zink achieve this milestone.

    Leave a comment:


  • Lucretia
    replied
    It would be nice to benchmark Tomb Raider on a many-core Threadripper once LLVMpipe is mature enough. An AMD EPYC CPU with twice the memory channels of Threadripper might be better suited for this task, unless there are thread scheduling issues.

    Leave a comment:


  • AsuMagic
    replied
    Originally posted by kpedersen View Post

    This obviously makes sense. However I would actually love to see a graph showing where a CPU does start to overtake GPU.

    For example which generation CPU started to yield better performance than the GMA 945? We are surely able to see some crossover now. It would also be useful to see how far away we are from reaching modern GPU performance via a CPU.
    Anecdotally, I can run simple 2D games in 1440p near 60fps with my 3900X. Considering this is a fairly high resolution, that isn't quite terrible for an OpenGL game.
    Also anecdotally, llvmpipe doesn't seem to be able to parallelize very well. I usually get ~50% CPU usage on that machine. Unless that has to do with SMT?

    Leave a comment:


  • airlied
    replied
    GL 4.5 and GLES 3.1 are pretty much complete and close to passing the conformance tests. I have maybe 10 more patches left. As for 4.6/3.2 they need one feature each but they are messy features, anisotropic texture and framebuffer fetching.

    Another use for swrast is CI increasing CI coverage for all of the Mesa GL and virgl is useful for mesa.

    Leave a comment:


  • Xaero_Vincent
    replied
    While not an accurate benchmark or LLVMpipe, you can kind of get a sense of how impractical software rendering is with 3D games. This is good for a fallback if the GPU driver isn't running.

    Linus Tech Tips recently tested the performance of the original Crysis game rendering purely on the CPU. The 2007 game in windowed mode can run at what appears to be 10 to 15 FPS on a Threadripper 3990X. So you can imagine any lesser CPU will be worse, along with any newer, graphically intensive workload.

    https://youtu.be/1LaKH5etJoE?t=556

    Leave a comment:


  • Terrablit
    replied
    I'm actually kind of excited for software rendering for testing than for a viable execution path. Having CPU-rendered tests with saved, comparable output should be useful in testing and comparing future drivers. Using it in production would either be for really low-resolution targets or for far in the future when hardware improvements make it viable. Or for unusual renderfarm needs.

    Leave a comment:

Working...
X