Quoting Antonio Argenziano (2017-10-12 23:10:37) > When a client gets a fixed amount of its contexts banned, will be > blocked from creating any new contexts itself. This patch adds a test > for this feature. Fixed by whom? The "feature" is a primitive DoS prevention. Atm it is purely implementation defined as we don't have a "service level agreement" to describe exactly what can be expected. It is certainly not an ABI one client can rely on for itself, more a general effect about how much interruption a client can expect from any other. So how do you define such behaviour? Do we want to carve the "three strikes" rule into stone? How about when the malicious client creates new contexts to avoid the strikes? How about when a malicious client decides to try and DoS its common parent (e.g firefox and multiple webgl, with one bad apple trying to upset the barrel)? At the end of the day, limits will be imposed in exactly the same way as for traditional processes, and gpu resources will be managed and scheduled under the same umbrella. From that viewpoint, everything we do today will have to undergo radical change. So consider careful what you want to record as user ABI. Atm, userspace requires support for ARB_context_robustness and we have not been asked for anything more. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
