[PATCH v2 4/4] drm/mgag200: Use DMA to copy the framebuffer to the VRAM

Jocelyn Falempe jfalempe at redhat.com
Mon Jul 3 10:22:34 UTC 2023


On 16/06/2023 10:08, Thomas Zimmermann wrote:
> Hi
> 
> Am 15.06.23 um 19:15 schrieb Jocelyn Falempe:
>> On 15/06/2023 16:24, Thomas Zimmermann wrote:
>>> Hi Jocelyn
>>>
>>> Am 31.05.23 um 11:21 schrieb Jocelyn Falempe:
>>>> Even if the transfer is not faster, it brings significant
>>>> improvement in latencies and CPU usage.
>>>>
>>>> CPU usage drops from 100% of one core to 3% when continuously
>>>> refreshing the screen.
>>>
>>> I tried your patchset on a HP Proliant server with a G200EH. I can 
>>> see that the CPU usage goes down, but the time until the screen 
>>> update reaches the hardware's video memory has increased significantly.
>>
>> Thanks for taking time to test it.
>> Can you check if there is something in the dmesg ?
>>
>> The 1s looks suspicious, if the IRQ is not working, there is a 1s 
>> timeout, which can explain why it will display only one frame per 
>> second. (logs should be filled with "DMA transfer timed out")
> 
> No, I don't see that error. I also verified that the IRQ handler is 
> running. It runs on each update AFAICT.
> 
> When I'm doing full-screen scrolling on the kernel console I can see the 
> scanlines being updated from top to bottom. This indicates to me that 
> the actual copying takes time or interferes with the scanout.
> 
> Best regards
> Thomas
> 
>>
>> I will see if I can get access to a G200EH, and if I can reproduce this.
>>
>> Best regards,
>>
> 

I reproduced the issue on G200EH, and there is the same problem on 
G200eR2 [102b:0534], G200eW3 [102b:0536], G200eH3 [102b:0538]
On these severs, DMA is between 2x and 10x slower than memcpy().
I didn't find a setting in Matrox register, that has an effect on this.
At this point, I think the problem may lie in the PCIe <-> PCI bridge.

I also tested on a MGA G200e [102b:0522] where the IRQ is not working at 
all.

So it looks like I've done the development on one of the few models, 
where the DMA is not completely broken.

So let's abandon this, as most hardware can't handle DMA with acceptable 
performance, and some have even broken IRQ.

Here is my complete test results:

Dell T310 G200WB [102b:0532]:
MGA memcpy: x 1280, y 1024, time: 124832 us
MGA iload: x 1280, y 1024, time: 123794 us
With PCI burst enabled (OPTION enhmemacc set to 1 and HEADER cacheline 
set to 0x08)
MGA iload: x 1280, y 1024, time : 51880 us

HP dl160 Gen8 G200EH [102b:0533]:
MGA memcpy: x 1024, y 768, time: 31542 us
MGA iload: x 1024, y 768, time: 312638 us

Dell pem520  G200eR2 [102b:0534]:
MGA memcpy: x 1280, y 1024, time : 30156 us
IRQ not working

Dell per640 G200eW3 [102b:0536]:
MGA memcpy: x 1024, y 768, time : 15586 us
MGA iload: x 1024, y 768, time : 60900 us

HP dl120 gen10 G200eH3 [102b:0538] (rev 02):
MGA memcpy: x 1024, y 768, time : 22539 us
MGA iload: x 1024, y 768, time : 38324 us

HP dl180 G200e [102b:0522] (rev 02)
MGA memcpy: x 1024, y 768, time : 35749 us
MGA iload busywait: x 1024, y 768, time : 137079 us
IRQ not working

Best regards,

-- 

Jocelyn




More information about the dri-devel mailing list