RV350, compositing and horrible performance.

[timothyja]

First try a newer kernel and version of mesa. There have been a lot of performance improvements in 9.1 for example.

I have already tried a new kernal/build of Mesa as I wanted to see if Vadim's shader optimizations would help my issue but they didnt seem to help at all.

Also try adjusting the CPU governor as per other comments in this thread.

I will try this out later today.

For the ttm defragmentor, see drivers/gpu/drm/ttm/ in the kernel source.

Thanks.

[agd5f]

I seem to have the same issue on my RV620 not with the desktop but with games that dont seem to be all that graphically intense.
Are you able to gives some more details on where exactly one would look to start inplementing a ttm de-fragmenter? I'm not sure if I'm up to the task but it does sound interesting and I would be keen to at least have a look around.

Thanks for your time.

First try a newer kernel and version of mesa. There have been a lot of performance improvements in 9.1 for example. Also try adjusting the CPU governor as per other comments in this thread. For the ttm defragmentor, see drivers/gpu/drm/ttm/ in the kernel source.

[agd5f]

It likely uses some cpu fallback. How to check that, I have no idea

Gallium doesn't support software fallbacks. The driver may still be doing something inefficiently however.

[timothyja]

What is your question? vram has much better bandwidth compared to system memory from the GPU's perspective so in most cases it's preferred to store buffers in vram. If we don't have enough vram to cover all the requirements, we may end up with thrashing. There's probably room for improvement with respect to the heuristics used to decide which pools we allocate from and whether we migrate or not. A ttm de-fragmenter would probably also be helpful. Either of these are good projects that don't require low level GPU specific knowledge and could provide nice performance improvements.

I seem to have the same issue on my RV620 not with the desktop but with games that dont seem to be all that graphically intense.
Are you able to gives some more details on where exactly one would look to start inplementing a ttm de-fragmenter? I'm not sure if I'm up to the task but it does sound interesting and I would be keen to at least have a look around.

Thanks for your time.

[Ray7brian2]

It likely uses some cpu fallback. How to check that, I have no idea

[smitty3268]

I remember when the first PCIe cards were released just about every review I read said the bandwidth was orders of magnitude overkill. That much bandwidth simply could not be utilized.

It depends on the card - newer ones will show improvements even going from PCIe2 to PCIe3, at least in certain tests. At the time, I don't think anything was maxing out AGP8x, but manufacturers knew that those cards were coming.

[agd5f]

Well, ideally, you want to minimize the amount of traffic going across the bus. If you have to migrate a lot of data back and forth, you've already lost.

[duby229]

I remember when the first PCIe cards were released just about every review I read said the bandwidth was orders of magnitude overkill. That much bandwidth simply could not be utilized.

[agd5f]

I did figure as much, but just wanted to double check.

AGPmode=4 does FEEL faster Won't AGPmode affect memory bandwith from/to the card? E.g. when swapping via gart?

In theory yes, in practice it doesn't really make a lot of difference.

[oliver]

I did figure as much, but just wanted to double check.

AGPmode=4 does FEEL faster Won't AGPmode affect memory bandwith from/to the card? E.g. when swapping via gart?