Announcement

Collapse
No announcement yet.

Using OpenCL with the radeon driver to print Bitcoins ? is this posible?

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

  • #11
    Originally posted by chithanh View Post
    The cheapest card to deliver good bitcoin performance (with the proprietary driver) is the 5830. The relative lack of ROPs doesn't affect mining. The most efficient dual-GPU card for mining is the 5970, and single-GPU card is the 7970, especially after undervolting the core and downclocking the memory.
    LOL ERROR(with the proprietary driver)ERROR
    FAIL-
    just watch the forum: Forum --> Linux Graphics / X.Org Drivers -->Open-Source AMD/ATI Linux


    or do you think the people should buy the 5830 for the radeon driver?

    Comment


    • #12
      If a card gives relatively good bitcoin performance with the proprietary driver it seems reasonable to assume that it will behave similarly with the radeon driver once it supports OpenGL. I thought that was obivious.

      Comment


      • #13
        Originally posted by chithanh View Post
        If a card gives relatively good bitcoin performance with the proprietary driver it seems reasonable to assume that it will behave similarly with the radeon driver once it supports OpenGL. I thought that was obivious.
        ERROR"good bitcoin performance with the proprietary driver it seems reasonable to assume that it will behave similarly with the radeon driver"ERROR

        Not really this way to think is just naive!

        Comment


        • #14
          Apart from a few exceptions (e.g. BFI_INT opcode) it is possible to use the full capability of the hardware with the proprietary driver for bitcoin mining. ALU performance is almost exclusively the determining factor for resulting Mhash/s. I expect that if the open driver can generate code that performs within N% within proprietary driver on hardware A, it will also run within ~N% on hardware B.

          Comment


          • #15
            In this case Q might have a point... the open drivers probably won't have the same level of shader compiler sophistication as the Catalyst drivers for a while, so my guess is that GCN-architecture parts will be able to make relatively better use of their potential hardware performance with the open compute stack than will comparable VLIW parts. Then again, IIRC the bitcoin code has already been partially vectorized to work well on VLIW hardware so maybe in the case of bitcoin mining he doesn't have a point after all

            If you ignore the VLIW/GCN transition, however, I imagine relative performance with the Catalyst driver will be a decent predictor of relative performance with the open stack.

            Comment


            • #16
              Originally posted by 89c51 View Post
              @agd5f
              thanks

              a bit off topic but which card works well with FOSS drivers and will support OpenCL??. in other words what would you buy now
              I don't know what he would buy now, but I have a Radeon 6850 in my home machine which I've used with Catalyst + OpenCL and which also runs nicely with the OSS drivers under Ubuntu 11.10 and Gnome Shell. I'm just waiting for the Gallium OpenCL support to land so that I can have the best of both worlds with regards to my home development projects.

              Comment


              • #17
                Originally posted by bridgman View Post
                In this case Q might have a point... the open drivers probably won't have the same level of shader compiler sophistication as the Catalyst drivers for a while, so my guess is that GCN-architecture parts will be able to make relatively better use of their potential hardware performance with the open compute stack than will comparable VLIW parts.
                thank you very much this is my point if someone buy a new card to get opensource OpenCL support he maybe should jump to a hd7750 or higher card.

                Bet on a Death Horse is always wrong. and VLIW is death.

                Originally posted by bridgman View Post
                Then again, IIRC the bitcoin code has already been partially vectorized to work well on VLIW hardware so maybe in the case of bitcoin mining he doesn't have a point after all
                show me the benchmarks

                Originally posted by bridgman View Post
                If you ignore the VLIW/GCN transition, however, I imagine relative performance with the Catalyst driver will be a decent predictor of relative performance with the open stack.
                show me the benchmarks

                Comment


                • #18
                  Originally posted by Qaridarium View Post
                  show me the benchmarks
                  Originally posted by Qaridarium View Post
                  show me the benchmarks
                  The implicit original question was "(without waiting for the code to be finished and benchmarks to be available) what do you think I should get ?".

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    The implicit original question was "(without waiting for the code to be finished and benchmarks to be available) what do you think I should get ?".
                    sure but its like speculating and waiting for a better Linux driver for your windows-only-modem or waiting for better linux drivers for the Xbox360 ATI XENOS graphic card.

                    don't get me wrong I'm happy about the ATI-XENOS-Xbox360 based hardware with the name R600 but i think its a Death Horse from the MIcrosoft Bill Gates Death hand from the start one.

                    in fact if you buy a R600 based graphic card you are just fucked by bill gates AGAIN! and AGAIN AND AGAIN AND AGAIN!

                    i don't count on that!

                    Comment


                    • #20
                      Originally posted by chithanh View Post
                      Apart from a few exceptions (e.g. BFI_INT opcode) it is possible to use the full capability of the hardware with the proprietary driver for bitcoin mining. ALU performance is almost exclusively the determining factor for resulting Mhash/s. I expect that if the open driver can generate code that performs within N% within proprietary driver on hardware A, it will also run within ~N% on hardware B.
                      I suspect tricks like these will be available on the OSS stack. But then you'll need to write whatever low-level code is used.

                      Comment

                      Working...
                      X