This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU/SI: Pass whether to use the SI scheduler via Target Attribute
ClosedPublic

Authored by axeldavy on Jan 14 2016, 8:54 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

axeldavy updated this revision to Diff 44890.Jan 14 2016, 8:54 AM
axeldavy retitled this revision from to AMDGPU/SI: Pass whether to use the SI scheduler via Target Attribute.
axeldavy updated this object.
axeldavy added a reviewer: tstellarAMD.
tstellarAMD accepted this revision.Jan 14 2016, 8:56 AM
tstellarAMD edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Jan 14 2016, 8:56 AM

I thought @echristo wanted to move away from doing things like this

The way with the command line argument had some issues with Mesa.
There can be several llvm users at the same time.

For example, d3d apps can use both sw rendering and hw rendering. We'd want the command line
option to apply only to the radeonsi backend, and not to llvmpipe.

Even with that put aside, setting the command line option in a call_once function didn't work reliably
(crash complaining the command line option is set twice):
Several d3d apps were failing. I suspect these apps do create gl contexts in addition to d3d context,
and Mesa does duplicate all the drivers for the d3d lib binary, thus resulting in two call_once functions ...

I guess if app is using clover + gl there would be similar issue.

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

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

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.

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

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

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.

tstellarAMD requested changes to this revision.Jan 18 2016, 8:53 AM
tstellarAMD edited edge metadata.
This revision now requires changes to proceed.Jan 18 2016, 8:53 AM
echristo accepted this revision.Jan 19 2016, 3:03 PM
echristo added a reviewer: echristo.

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

This revision was automatically updated to reflect the committed changes.