Am 14.12.20 um 16:46 schrieb Darren Salt:
I demand that Christian König may or may not have written...
Am 11.12.20 um 18:31 schrieb Darren Salt:
< [SNIP]
If that isn't the case use fls() to get the highest set bit < 13.
That suggests that it'll be easiest to clear each bit after the
corresponding size is checked, I think.
Ok, well you don't seem to understand my constrain here: Never check
more than one size!
Checking context: it appeared to be the for() statement itself rather than
the whole loop. It didn't help that “try and error” looks like “try to error”
to me; I now think that you meant “trial and error”.
I'm not a native speaker of English, so bear with me if I get such stuff
wrong.
Find the first valid size which is good for you and then try to resize
to that one, if this doesn't work abort.
So, basically, stop even when the next size down would be fine, e.g. 16GB →
8GB. Just as well that size limiting is done in a later patch, though I
wonder whether that should allow per-GPU configuration (not something for
this patch series, though).
Yes, just try the whole dance with exactly one size and not multiple times.
Also, this looks like it's adding complexity to try to make
rarely-executed code slightly faster in some cases (I can't see it
helping where available_sizes == 0x3F00, for example).
The intention here is not to make the code faster, but to prevent issues on
system where we probe multiple GPUs at once.
Presumably simultaneous probes and random ordering…
Exactly.
Good news is that I think I've figured out why that happens and our
hardware/VBIOS engineers are investigating now what's the best approach
to make thinks work as it should :)
We most likely will end up with a static quirk for this
PCI-ID/revision/board/manufacturer.
Regards,
Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
