eglStreamConsumerAcquireAttribNV function execution became significantly slower in 470.42.01 driver release

Graphics / Linux Linux
1

Hello,
After upgrading to latest beta driver (470.42.01) there is a significant slowdown of eglStreamConsumerAcquireAttribNV function execution. I forked and added measurements to eglstreams-kms-example: GitHub - danvd/eglstreams-kms-example: Example of using EGLStreams + DRM KMS

Example output with 470.42.01 driver:
eglStreamConsumerAcquireAttribNV exec time: 18 ms
eglStreamConsumerAcquireAttribNV exec time: 13 ms
eglStreamConsumerAcquireAttribNV exec time: 10 ms
eglStreamConsumerAcquireAttribNV exec time: 7 ms
eglStreamConsumerAcquireAttribNV exec time: 4 ms
eglStreamConsumerAcquireAttribNV exec time: 18 ms
eglStreamConsumerAcquireAttribNV exec time: 13 ms
eglStreamConsumerAcquireAttribNV exec time: 10 ms

Example output with 465.31 driver:
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 0 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms

So basically it looks like a bug. This breaks apps relying on old behaviour adding extra latency to an existing pipelines.

Can anything be done to do a fallback? Is it a known issue?

2

We were able to duplicate issue locally and filed a bug 200748592 internally for tracking purpose.

3

Thank you.

4

Hi Andrew, I was able to confirm that prior to the 470 release, calling eglStreamConsumerAcquireAttribNV before the previous frame had been presented would immediately return EGL_RESOURCE_BUSY_EXT, however due to an unintended side-effect of a recent driver change it will now block until the next vblank. We should be able to get a fix out in an upcoming minor release to restore the previous behavior. Thanks for catching the issue!

1 Like
5

Great news! Thank you, Erik.

6

Issue is fixed in 470.63.01. Thank you all!

7

This bug is still occurring in 470.74, but only on Ampere. eglStreamConsumerAcquireAttribNV blocks for almost a whole frame.

8

@ekurzinger, eglStreamConsumerAcquireAttribNV is still blocking for a whole frame interval in 470.74, but only on Ampere it would seem.

9

There wasn’t really anything chip-specific about the cause of the original issue, so that’s somewhat surprising. Thanks for bringing it up, though. It might be a different problem that happens to cause the same symptoms. I’ll try and get a hold of an Ampere card to attempt a repro.

10

@vanvugt-canonical I tried running the example application from the original report with an Ampere GPU, but eglStreamConsumerAcquireAttribNV doesn’t seem to be blocking. This might be specific to mutter, for instance the GitLab issue you linked also suggests KWin runs as the correct refresh rate. If eglStreamConsumerAcquireAttribNV really was blocking I would expect that to affect all compositors.

eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 0 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 0 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms
eglStreamConsumerAcquireAttribNV exec time: 1 ms