Currently the SI scheduler can be selected via command line option,
but it turned out it would be better if it was selectable via a Target Attribute.
This patch adds "si-scheduler" attribute to the backend.
Differential D16192
AMDGPU/SI: Pass whether to use the SI scheduler via Target Attribute axeldavy on Jan 14 2016, 8:54 AM. Authored by
Details Currently the SI scheduler can be selected via command line option, This patch adds "si-scheduler" attribute to the backend.
Diff Detail Event TimelineComment Actions The way with the command line argument had some issues with Mesa. For example, d3d apps can use both sw rendering and hw rendering. We'd want the command line Even with that put aside, setting the command line option in a call_once function didn't work reliably I guess if app is using clover + gl there would be similar issue. Comment Actions Getting away from this would be a good thing, i.e. you just added more cleanup now. What are you trying to do here? -eric Comment Actions This attribute is for enabling an alternative machine scheduler in the AMDGPU backend. I had originally asked Axel not to add the subtarget feature and instead have Mesa enable the scheduler by passing a command line argument to the C API function LLVMParseCommandLineOptions(), but he ran into some problems as described in his comment. Comment Actions For your target in particular you only have a single subtarget and so the command line option should be valid at any time you're instantiating a JIT for the gpu yes? The comment wasn't enough for me to piece together what's happening here. -eric Comment Actions The problem is that the command line parser is global, so you can only call it once with a particular option. An application can possibly load multiple drivers which both need to set the command line option: e.g. OpenGL and OpenCL. These drivers have no knowledge of each other and are completely separate. When this happens the second driver to call LLVMParseCommandLine() assertion fails, because this fucntion does not allow a command line option to be set twice. Comment Actions The way this is set up isn't going to work in general the same as other subtarget features, but as we discussed on IRC if you're willing to keep a separate TargetMachine for each set of subtarget feature changes that you might want to do that affect the pass and code generation pipeline it should be fine. As a note, this is the sort of thing that the other targets handle in their TargetMachine where it does the caching etc and the subtarget features are set on the function. -eric |