Technical reason for no R300-500 support?

[bralston7]

Is there a technical reason why the r300-500 series aren't supported? Is the documentation for the appropriate registers just not available? I ask because I have an embedded system with an r500 and I wish to measure GPU usage, but I'm having a tough time finding anybody that has implemented this.

[clbr]

Two reasons: 1) r500 had much more limited info, r400 even more limited, and so on for r300. They all do have a "total GPU usage" bit IIRC, but not much more. IIRC it's also different for each of those.

2) I do not have any such hw.

So the docs do exist, it's merely a matter of someone doing the work. With the info being really limited, a separate app might be better, as adding r500 support to radeontop would mean rather big if-blocks for minimal benefit. If you create a radeontop-r500 fork for example, I'll link it from the readme.

[bralston7]

Thanks for your reply. The system I'm writing for is non-linux embedded system so this wouldn't end up being a fork.

I've taken a look at the Mesa drivers and the registers file doesn't have names that line up with what you're pulling (I'm assuming from your code that I'm looking for something with gui in the name for the overall usage). I did find a bunch of defines like R500_GA_IDLE_XXX in r300_reg.h that seem like they are probably what I'm looking for, but I can't tell which one is the overall bit. Would you mind helping me out by looking at this file and giving your opinion on which is the register I should be looking at?

https://searchcode.com/codesearch/view/19125645/

After finding the correct register, I should just have to poll it [ticks] number of times, counting up how may times it is 1, and then divide by [ticks] to get percentage? That looks like what you are doing...I think.

[bralston7]

I think I may have found the correct registers on page 154 of R5xx_Acceleration_v1.5.pdf:

CP:CP_STAT · [R] · 32 bits · Access: 8/16/32 · MMReg:0x7c0 DESCRIPTION: (RO) Busy Status Signals Field Name Bits Default Description MRU_BUSY 0 none Memory Read Unit Busy. MWU_BUSY 1 none Memory Write Unit Busy. RSIU_BUSY 2 none Register Backbone Input Interface Busy. RCIU_BUSY 3 none RBBM Output Interface Busy. CSF_PRIMARY_BUSY 9 none Primary Command Stream Fetcher Busy. CSF_INDIRECT_BUSY 10 none Indirect #1 Command Stream Fetcher Busy. CSQ_PRIMARY_BUSY 11 none Data in Command Queue for Primary Stream. CSQ_INDIRECT_BUSY 12 none Data in Command Queue for Indirect #1 Stream. CSI_BUSY 13 none Command Stream Interpreter Busy. CSF_INDIRECT2_BUSY 14 none Indirect #2 Command Stream Fetcher Busy. CSQ_INDIRECT2_BUSY 15 none Data in Command Queue for Indirect #2 Stream. GUIDMA_BUSY 28 none GUI DMA Engine Busy. VIDDMA_BUSY 29 none VID DMA Engine Busy. CMDSTRM_BUSY 30 none Command Stream Busy. CP_BUSY 31 none CP Busy.

What do you think?

[clbr]

You're correct about the percentage calculation, and that register looks like the right one. There doesn't seem to be a general bit for r500 then (CP aka command processor would be closest, but still off), so you should check for any of the busy bits in that register.

Checking the 32-bit uint as a whole would work, but remember to filter out the undefined bits, as they may have spurious values.

[clbr]

Oh, let's leave this open, so other users with r300-r500 can see it easily.

[bralston7]

So I decided for my own benefit to go ahead and get radeontop working with my RV515 and I actually have it mostly working. I've got a couple of questions though. First, why do the calls to get register values (RADEON_INFO_READ_REG) through the drm not work (I always fall into the use_ioctl=false)? Second, when you are setting the 'area' global from memory region 2, how do you know to offset by 0x8000?? This works for reading the CP_STAT register (0x7c0) on the RV515, but I would really like to know why. When I try to read other registers some seem to work and some don't.

Thanks, Ben

[clbr]

The new kernel-code doesn't have anything for R500. Another point where nobody has both hw and interest.

The offset is because of mmap limitations and due to trying to map the smallest window possible. mmap requires alignment by 4kb, so 0x8000 was the best alignment to get to 0x8010.