Results 1 to 6 of 6

Thread: acronyms and more

  1. #1
    Join Date
    Dec 2008
    Posts
    166

    Default 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. #2
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote 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

    Quote 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.

    Quote 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.

  3. #3
    Join Date
    Dec 2008
    Posts
    166

    Smile

    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!

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote 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)

  5. #5
    Join Date
    Dec 2008
    Posts
    166

    Cool

    A big thx!

  6. #6
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •