08:01 mripard: rodrigovivi: if you merged it... fine. But I'm really not happy about the double-standard it creates
08:01 mripard: and it's explicitly documented that it's not ok to do what's been done there
08:02 mripard: so at the very least, it should be documented why it deviates from the policy
11:23 karolherbst: okay.. I found shaders where nir_opt_move_discards_to_top if it would be able to move control flow (there is a shader with discards after a huge loop, but it doesn't depend on anything in the loop, the pass also moves other discards in front of it) I'd be able to get ~8% more perf in this one shader... *sigh* that's going to be a fun one
11:24 karolherbst: ehh wait.. I meant 20% more perf in the shader, 8% overall (I have a renderdoc)
13:34 rodrigovivi: mripard: would an IGT based tool with the right process solve this? Because this was the drm-ras-netlink link plan since the very beginning... the planned solution for the open source usage of it... I decided to move to ynl since that is less of a toy then the igt tool honestly... But if the consensus is to get back to the original idea as when the netlink api for ras was envisioned in the past then we can get that faster
14:11 mripard: rodrigovivi: IGT isn't considered enough to meet that requirement either
15:31 rodrigovivi: mripard: well, I was not part of the original ras-netlink discussions on Plumbers, but when I jumped in I got that the consensus was that for this case the IGT/tool would be okay for now to unblock the API development while we don't have any real common layer.... but like we use kernel perf to unlock the perf APIs, using a in-kernel tool as the reference would be better then the IGT tool agreed there... I really don't believe that
15:31 rodrigovivi: this is a double standard...