Announcement

Collapse
No announcement yet.

Wiki or status for Evergreen R8xx

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

  • Wiki or status for Evergreen R8xx

    I am considering selling my GTS 250 sli for a single 5850 as soon as there is good open source support.
    I don't really play games in linux but I do want to use dual screen with composite and of course KMS would be nice.
    Is there a wiki or status page for Evergreen R8xx radeonhd support?

  • #2
    Originally posted by dalingrin View Post
    I am considering selling my GTS 250 sli for a single 5850 as soon as there is good open source support.
    I don't really play games in linux but I do want to use dual screen with composite and of course KMS would be nice.
    Is there a wiki or status page for Evergreen R8xx radeonhd support?
    Other than KMS, the radeonhd status should track radeon status pretty closely :



    All it says right now though is "display/modesetting is WIP, everything else is TODO".

    At a more detailed level, Alex has analog VGA outputs working but the digital outputs are still being difficult. He found the problem that was preventing digital outputs from lighting up at all, but the displayed image still isn't right (Alex described it as looking like it had been scaled down to very low res then scaled back up again). We have started taking the initial Evergreen display code through IP review anyways. Not much will happen over the holidays, so as a guess maybe 3rd week of Jan for the first code to go public.

    We'll probably start on acceleration code around the same time.
    Last edited by bridgman; 20 December 2009, 08:41 PM.
    Test signature

    Comment


    • #3
      Originally posted by bridgman View Post
      Other than KMS, the radeonhd status should track radeon status pretty closely :



      All it says right now though is "display/modesetting is WIP, everything else is TODO".

      At a more detailed level, Alex has analog VGA outputs working but the digital outputs are still being difficult. He found the problem that was preventing digital outputs from lighting up at all, but the displayed image still isn't right (Alex described it as looking like it had been scaled down to very low res then scaled back up again). We have started taking the initial Evergreen display code through IP review anyways. Not much will happen over the holidays, so as a guess maybe 3rd week of Jan for the first code to go public.

      We'll probably start on acceleration code around the same time.
      Don't want to flood a topic that is not mine, but I had the same experiment (scale down up effect) with my lenovo t400 (34xx rv620), using the vga is ok but the dvi from the docking station had the same result as described above.

      BTW I'm happy to see that the open source development starts sooner and sooner regarding the hardware availability.
      Last edited by lucky_; 21 December 2009, 06:29 AM.

      Comment


      • #4
        FYI we just released the shader instruction set documentation for Evergreen :



        That is good news because it is a pre-requisite for 2D, Xv and 3D acceleration.
        Test signature

        Comment


        • #5
          Originally posted by bridgman View Post
          FYI we just released the shader instruction set documentation for Evergreen
          I love you.

          Comment


          • #6
            Merry Christmas .

            Comment


            • #7
              Originally posted by bridgman View Post
              FYI we just released the shader instruction set documentation for Evergreen :
              Been looking over it now, and I think there's an omission, CF_INST_CONTINUE is referred to but never defined. I'm trying to figure out the difference between the CF_INST_ALU_CONTINUE and CF_INST_ALU_BREAK call, and it says both are equivalent to "CF_INST_PUSH, CF_INST_ALU, CF_INST_ELSE, CF_INST_CONTINUE, CF_INST_POP" which doesn't make much sense so I'm missing something.

              Still a paper exercise since I need digital out to work first before I'll start work on it, but I'm trying to figure out the language

              Comment


              • #8
                Yeah, I had trouble making sense of that part too. Thought it was just me though.

                Usually someone over at Beyond3D tells us in the first few hours what the doc *should* have said
                Last edited by bridgman; 21 December 2009, 09:38 PM.
                Test signature

                Comment


                • #9
                  Originally posted by Kjella View Post
                  Been looking over it now, and I think there's an omission, CF_INST_CONTINUE is referred to but never defined. I'm trying to figure out the difference between the CF_INST_ALU_CONTINUE and CF_INST_ALU_BREAK call, and it says both are equivalent to "CF_INST_PUSH, CF_INST_ALU, CF_INST_ELSE, CF_INST_CONTINUE, CF_INST_POP" which doesn't make much sense so I'm missing something.

                  Still a paper exercise since I need digital out to work first before I'll start work on it, but I'm trying to figure out the language
                  I think your CF_INST_CONTINUE here is actually supposed to be CF_INST_LOOP_CONTINUE in one and CF_INST_LOOP_BREAK in the other..

                  Hence
                  CF_INST_ALU_CONTINUE = CF_INST_PUSH, CF_INST_ALU, CF_INST_ELSE, CF_INST_LOOP_CONTINUE, CF_INST_POP

                  and
                  CF_INST_ALU_BREAK = CF_INST_PUSH, CF_INST_ALU, CF_INST_ELSE, CF_INST_LOOP_BREAK, CF_INST_POP

                  Just cross-referencing it, these opcodes seem unchanged from r600/700, so there's probably applicable code available to verify this..

                  Comment


                  • #10
                    Nice to see that it's geting shorter and shorter to release doc for the harware.
                    It looks like the process has been ironed out internally .

                    Comment

                    Working...
                    X