Announcement

Collapse
No announcement yet.

acronyms and more

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

  • acronyms and more

    Hi,
    I'm into the kernel code (regs) and I'm puzzled by some acronyms:
    GRBM?
    SRBM?
    TA? (it's a silicium block in the soft grbm reset register, Texture something?)
    CF_RQ_PENDING (Control Flow ReQuest?)?
    PF_RQ_PENDING (PF? ReQuest?)?
    GRBM_EE_BUSY (EE?)
    GRBM_STATUS_SE{0,1} (SE?)

    Moreover I was told on IRC that the first page (4kB) of regs where not behind the rbbm and then reset registers would be there. But the GRDBM soft reset register is at 0x8020 (for evergreen). Then what's the story about rbbm and reset registers?

    I do presume that the ATOMBIOS does work 100% in little-endian even with a big-endian cpu? Is that right?

  • #2
    Originally posted by sylware View Post
    Hi,
    I'm into the kernel code (regs) and I'm puzzled by some acronyms:
    GRBM?
    SRBM?
    TA? (it's a silicium block in the soft grbm reset register, Texture something?)
    CF_RQ_PENDING (Control Flow ReQuest?)?
    PF_RQ_PENDING (PF? ReQuest?)?
    GRBM_EE_BUSY (EE?)
    GRBM_STATUS_SE{0,1} (SE?)
    GRBM = Graphics Register Backbone Manager
    SRBM = System Register Backbone Manager
    TA = Texture Addresser
    CF_RQ_PENDING (Should be CP_RQ_PENDING) = CP request
    PF_RQ_PENDING = PFP (PreFetch Parser) request (PFP is part of the CP)
    EE = Event Engine
    SE = Shader Engine

    Originally posted by sylware View Post
    Moreover I was told on IRC that the first page (4kB) of regs where not behind the rbbm and then reset registers would be there. But the GRDBM soft reset register is at 0x8020 (for evergreen). Then what's the story about rbbm and reset registers?
    It depends on the register; there is no particular range that is fifoed vs not. Most graphics/3D registers sit behind a fifo, while other (display/asic setup/config) registers do not.

    Originally posted by sylware View Post
    I do presume that the ATOMBIOS does work 100% in little-endian even with a big-endian cpu? Is that right?
    Correct. the atombios parsers in the kernel and xf86-video-ati ddx are both endian safe.

    Comment


    • #3
      Then we have the GRBM/SRBM/RBBM(which should be RBM). They are that different?

      Oh! And ME acronym stands for what in CP_ME_CONTROL and CP_ME_HALT? (Memory Engine?)

      Thx for all that info and help!

      Comment


      • #4
        Originally posted by sylware View Post
        Then we have the GRBM/SRBM/RBBM(which should be RBM). They are that different?

        Oh! And ME acronym stands for what in CP_ME_CONTROL and CP_ME_HALT? (Memory Engine?)

        Thx for all that info and help!
        ... or GRBM should be GRBBM etc

        The split is mostly between 3D engine and everything else - register writes to the 3D engine need to be synchronized with the data flowing through the engine so the register logic is *really* complicated. The rest of the registers don't need to be pipelined and so are managed by a separate block.

        I think ME is just "Micro Engine" (the things that run the CP/PFP microcode)
        Test signature

        Comment


        • #5
          A big thx!

          Comment


          • #6
            actually, slight correction:
            CF_RQ_PENDING = CP Fetch request
            PF_RQ_PENDING = PFP (PreFetch Parser) Fetch request (PFP is part of the CP)
            and ME is Micro Engine as John said.

            Comment


            • #7
              SRBM = System Register Bus Manager
              GRBM = Graphics Register Bus Manager

              Comment

              Working...
              X