aboutsummaryrefslogtreecommitdiffstats
path: root/tests
diff options
context:
space:
mode:
authorRob Clark2018-01-24 14:08:46 -0600
committerRob Clark2018-01-26 14:29:10 -0600
commit6f0f6cee5e9be1dcf816c144e05d26352c85a9e8 (patch)
tree8326e8b234c44da67b35444a4f4977f0d84b66cd /tests
parent82aef5f0cbeb5145408f8c5979dc826937d51b7b (diff)
downloadexternal-libgbm-6f0f6cee5e9be1dcf816c144e05d26352c85a9e8.tar.gz
external-libgbm-6f0f6cee5e9be1dcf816c144e05d26352c85a9e8.tar.xz
external-libgbm-6f0f6cee5e9be1dcf816c144e05d26352c85a9e8.zip
freedreno: clamp priority based on # of rings
In case of a kernel that is new enough to support multiple submit- queues, but with an adreno generation which doesn't support multiple prioritized ringbuffers, we'd attempt to open a submit-queue with prio=1 (medium), which is rejected by the kernel. This could happen either w/ an older mesa (which uses fd_pipe_new()) or a newer mesa which defaults to prio=1 if no pipe context priority flags are set. The simple answer to fix both cases is to clamp the requested priority according to the number of rings. This might not do exactly what you want, if we hypothetically had 2 rings (it would result in requested medium priority being high priority instead of low priority). But the number of rings (for hw gen's that support this) is purely a software construct, so the easy answer there is to have the kernel advertise at least 3 rings if it supports more than one. There isn't really any reason to do otherwise. Signed-off-by: Rob Clark <robclark@freedesktop.org>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions