No there is nothing that tells each stage of currently running reports. I've never heard of clearing a rendering queue in SSRS - didn't even know there was such a thing.
Subscriptions, scheduled reports are queued in a sense and having a large number of those at the same time can hit your CPU hard due to how they are processed but I don't know anything about the rendering queue or how you came up with that suspicion of the cause of the issues. So I would guess you have identified which reports are causing the most problems and checked the additional info column to eliminate any pagination issues which can cause slow rending. And then the size of the reports is not an issue as well. Scalability time can be high at the end of the month due to the load on the server but I would guess you ruled that out as well and there are no differences in overall execution counts being higher, no reports having higher executions counts, nothing in the log and nothing with the app domains cycling more often, the byte count is appropriate for the output type. Just a general issue with all reports having slow rendering times. How much higher are they now are the rendering times when compared to other times of the month? If you are using the defaults for the execution log you can compare those and even look at the same time frame last month. There are a lot of things to look at which can lead to some issues, especially end of month.
It might be good to look at things other than the rendering queue and that causing CPU issues. Sometimes when we assume what the problem is, we go about to prove how that is the problem. And never end up finding the problem.

Sue