Announcement

Collapse
No announcement yet.

Zink Can Now Run On Lavapipe But You Really Want To Avoid It

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

  • coder
    replied
    Originally posted by pal666 View Post
    it should support openmp and there are many library solutions in c++
    What I really care about is good scalar -> SIMD conversion, effective loop-unrolling, and software pipelining. I need good efficiency as much or more than absolute performance.

    Originally posted by pal666 View Post
    i meant optimizing code at runtime as llvmpipe would do
    Given that I already have a decent familiarity with GLSL, it's automatically more appealing. It has relaxed memory-consistency constraints that eliminate some performance pitfalls of C++ and it's automatically portable to GPUs. Those things make it very attractive to me.

    OpenCL is also a potentially viable option, but the software situation seems more messy. Also, I prefer to have image support, which I believe isn't universally-available.

    Leave a comment:


  • pal666
    replied
    Originally posted by coder View Post
    Does llvm auto-vectorize and loop-optimize C++ as effectively as llvmpipe does for GLSL? Somehow, I really doubt that.
    it should support openmp and there are many library solutions in c++
    Originally posted by coder View Post
    Also, llvmpipe gets me off the hook from creating & managing multiple builds for each different CPU capability level I need to support (everything from baseline x86-64 to AVX-512), since it compiles & optimizes for the native architecture at runtime.
    i meant optimizing code at runtime as llvmpipe would do

    Leave a comment:


  • coder
    replied
    Originally posted by pal666 View Post
    you don't need glsl for that: if you have llvmpipe, you have llvm, i.e. you could write your code in c++.
    Does llvm auto-vectorize and loop-optimize C++ as effectively as llvmpipe does for GLSL? Somehow, I really doubt that.

    Also, llvmpipe gets me off the hook from creating & managing multiple builds for each different CPU capability level I need to support (everything from baseline x86-64 to AVX-512), since it compiles & optimizes for the native architecture at runtime.

    Leave a comment:


  • coder
    replied
    Originally posted by pal666 View Post
    that's my hobby too.
    It's less of a hobby, but something I care enough about that bad buildsystems really bother me. I see how they impact productivity and product quality, and I believe it's worth doing right. It's also a slight departure from what I do for most of my time, so that helps.

    A side-benefit I've gotten is a tour of many dark corners, in our codebase. So, there are some cleanup tasks and policies coming out of the effort, as well.

    Originally posted by pal666 View Post
    still a lot of time for builds sounds wrong. do you use ccache?
    Indeed, but when one of the things I'm fixing is the dependencies of all the targets, then ccache doesn't help. I'm fairly conservative in the configuration I use, since I need to be careful not to break things. But our buildsystem does more than just compiling and linking.

    It is almost magical, when I hit a case that ccache handles.

    Leave a comment:


  • pal666
    replied
    Originally posted by coder View Post
    I had an idea to use it as a portable alternative for hand-coding variations of a some compute-intensive operations using a bunch of different SIMD ISA extensions for each different CPU ISA level. Just write it as GLSL compute shaders and let llvmpipe optimize it for whatever CPU you happen to be running it on.
    you don't need glsl for that: if you have llvmpipe, you have llvm, i.e. you could write your code in c++.

    Leave a comment:


  • pal666
    replied
    Originally posted by coder View Post
    The reason I've been spending a lot of time building is precisely because I've been rewriting it!
    that's my hobby too. still a lot of time for builds sounds wrong. do you use ccache?

    Leave a comment:


  • baryluk
    replied
    The article is not quite correct. zink on lavapipe was working for almost 2 months.

    The issue was that support got disabled, because it was causing problems to users with no accelerated GPU, as loader often will load zink on lavapipe before plain llvmpipe (which is slightly faster and more future complete).

    The new patch, adds ability to use zink on lavapipe anyway, if you dare so. This is mostly for use in automated testing (CI) of the Mesa zink itself, but you can use it too.

    It is not new, just gives more control and better defaults for average user.

    Leave a comment:


  • coder
    replied
    Originally posted by curfew View Post
    I fail to see how decoding video over an emulated graphics pipeline would be faster than using plain old regular CPU-based decoding... It isn't magic, after all.
    I had an idea to use it as a portable alternative for hand-coding variations of a some compute-intensive operations using a bunch of different SIMD ISA extensions for each different CPU ISA level. Just write it as GLSL compute shaders and let llvmpipe optimize it for whatever CPU you happen to be running it on.

    Leave a comment:


  • coder
    replied
    Originally posted by pal666 View Post
    sounds like your build system is in a need for improvement
    Lol. The reason I've been spending a lot of time building is precisely because I've been rewriting it!

    A word of advice: don't give the buildsystem to the most junior guy, especially with no oversight. Or anyone reluctant to do it, really. Both are going to be a recipe for a rewrite. Or, in my case, a re-rewrite. Ideally, you want it done by someone who will take the time to get all the details right, but also make it as easy as possible to use and extend.

    Sadly, many developers seem not to have a lot of patience for learning the ins and outs of the buildsysem and will copy the first (usually bad) example they find. People seem to have a knack for finding bad examples. If there's one bad example of how to do something, someone will find and copy it. And now you have two, making it even more likely that the next person finds one.

    Leave a comment:


  • pal666
    replied
    Originally posted by coder View Post
    I spend a lot of time building
    sounds like your build system is in a need for improvement

    Leave a comment:

Working...
X