On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter daniel@ffwll.ch wrote:
ret = set_proto_ctx_param(file_priv, pc, args);I think we should have a FIXME here of not allowing this on some future platforms because just use CTX_CREATE_EXT.
Done.
if (ret == -ENOTSUPP) {/* Some params, specifically SSEU, can only be set on fullyI think this needs a FIXME: that this only holds during the conversion? Otherwise we kinda have a bit a problem me thinks ...
I'm not sure what you mean by that.
Well I'm at least assuming that we wont have this case anymore, i.e. there's only two kinds of parameters:
- those which are valid only on proto context
- those which are valid on both (like priority)
This SSEU thing looks like a 3rd parameter, which is only valid on finalized context. That feels all kinds of wrong. Will it stay? If yes *ugh* and why?
Because I was being lazy. The SSEU stuff is a fairly complex param to parse and it's always set live. I can factor out the SSEU parsing code if you want and it shouldn't be too bad in the end.
Yeah I think the special case here is a bit too jarring.
I rolled a v5 that allows you to set SSEU as a create param. I'm not a huge fan of that much code duplication for the SSEU set but I guess that's what we get for deciding to "unify" our context creation parameter path with our on-the-fly parameter path....
You can look at it here:
https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405...
I'm also going to send it to trybot.
--Jason