Announcement

Collapse
No announcement yet.

New Heterogeneous Memory Management For Linux, Will Be Supported By NVIDIA/Nouveau

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

  • #11
    Originally posted by quaz0r View Post
    opencl 3 he says...lol. as if. we'd be lucky to see these dirtbags support 2.x within our lifetimes. maybe if they are lucky future generations will be able to utilize opencl 3.x ... on their quantum computers in their lab on mars.
    He talks of OpenCL 3 on Noveau, probably. The evil overlord at NVIDIA will laugh his evil mustache off by knowing the newer GPUs support OpenCL 3.0 in Noveau but he is negating it any kind of performance for years by not giving any info to help devs figure out the reclocking.

    Comment


    • #12
      Originally posted by pal666 View Post
      only in inferior languages
      I C , REPENT and thou shall be saved....

      http://www.dirtcellar.net

      Comment


      • #13
        Originally posted by waxhead View Post
        Who casts the result of malloc uuuurgh. it returns a void* so no need to cast!
        The world is not black and white. It has its use cases.: https://en.wikipedia.org/wiki/C_dyna...on#Type_safety

        Comment


        • #14
          Originally posted by boxie View Post

          Yeah but don't let the facts get in the way of a good rant!
          fair 'nuf :-P

          to c117152:
          There is a time and a place for optimizing sw explicitly for a single purpose on a single hw platform. And yeah, you can extract out that last bit of perf by pinning all your pages and explicitly controlling what data lives in what memory when, using hand written asm, etc.

          But there are a lot of cases where you want some sw to run on a lot of different hw platforms but not economically feasible to hand-tune for each one, yet you still want to get the benefit of gpu offload when possible, since while that might be 10% slower (made up number) than something specifically tuned for some particular hw, it is still a lot faster than the alternative ;-)

          Comment


          • #15
            Originally posted by robclark View Post

            fair 'nuf :-P

            to c117152:
            There is a time and a place for optimizing sw explicitly for a single purpose on a single hw platform. And yeah, you can extract out that last bit of perf by pinning all your pages and explicitly controlling what data lives in what memory when, using hand written asm, etc.

            But there are a lot of cases where you want some sw to run on a lot of different hw platforms but not economically feasible to hand-tune for each one, yet you still want to get the benefit of gpu offload when possible, since while that might be 10% slower (made up number) than something specifically tuned for some particular hw, it is still a lot faster than the alternative ;-)
            and now if you explain how you fit this into his "This madness is why people still get paid for writing assembly." you get a cookie from me!

            Comment


            • #16
              Originally posted by droste View Post

              The world is not black and white. It has its use cases.: https://en.wikipedia.org/wiki/C_dyna...on#Type_safety
              The world may not be black and white, but it's for sure binary. As a C programmer I know that casting malloc is a very bad idea. You have yourself linked to the reasons for it. if you compare for and against I think you will find that the disadvantages are far worse than the advantages. But then again, you may be programming in C++ for all I know

              http://www.dirtcellar.net

              Comment


              • #17
                Originally posted by karolherbst View Post

                and now if you explain how you fit this into his "This madness is why people still get paid for writing assembly." you get a cookie from me!
                umm, high frequency trading?

                (not that I'm an advocate of that.. just that is an example of where the economics are highly skewed to optimizing for a highly specific problem + hw.. I'm sure those folks are getting paid a lot of $$$ for writing asm and doing whatever else possible to squeeze out a few percent better perf.. to the benefit of a very few..)

                Comment


                • #18
                  Originally posted by robclark View Post

                  umm, high frequency trading?

                  (not that I'm an advocate of that.. just that is an example of where the economics are highly skewed to optimizing for a highly specific problem + hw.. I'm sure those folks are getting paid a lot of $$$ for writing asm and doing whatever else possible to squeeze out a few percent better perf.. to the benefit of a very few..)
                  uhh, I meant more like ... I forgot anyway, so it doesn't matter.

                  Comment


                  • #19
                    Originally posted by karolherbst View Post

                    uhh, I meant more like ... I forgot anyway, so it doesn't matter.
                    do I still get a cookie? j/k :-P

                    anyways, original point I was trying to make is that there is a lot of value in unlocking gpu perf for a whole new class of problems.. the fact that you could hypothetically extract slightly more perf by optimizing for a particular problem + hw combo doesn't change that.. that was only point I was trying to make to original original (original? I lost track..) poster :-)

                    Comment


                    • #20
                      Originally posted by robclark View Post

                      do I still get a cookie? j/k :-P
                      sure, next time we meet

                      Comment

                      Working...
                      X