-next plans/status

[Oded Gabbay]

Hi Dave,

I would like to add one more thing to your radar - amdkfd ;)

We are going to release AMD's HSA Runtime library as Open Source in the next few 
days, and coupled with the modification that Thomas Stellard did for the r600 
LLVM back-end, we are effectively releasing a _complete_ userspace Open Source 
stack/solution for running OpenCL applications on top of amdkfd.

The method for building & running kernel programs involves offline compilation 
of a .cl source file, using clang plus a version of the r600 LLVM back end which 
Tom has modified so that a HW ISA binary file is generated. That binary file 
will then be imported into the HSAIL RT using the hsa_code_unit_load() API 
function in the HSA RT, and can then be used in compute operations initiated via 
calls to the HSAIL RT API and writes to userspace queues.

The HSA RT communicates with the amdkfd through the libhsakmt userspace library 
(equivalent of libdrm). That library is already open sourced.

We will supply a fully working application (port of the MatrixMultiplication 
application), both .cl file and .c file. The .cl file can be compiled with the 
above mentioned method and the application will load it and submit it through 
the HSA RT queues.

I'm going to publish a v5 of the amdkfd patch-set together with the HSA RT. The 
major changed are:

1. Move driver to new /drm/amd/amdkfd location (As /drm/amd will contain all 
AMD's code in the future).
2. Add support for AQL packets because the HSA RT is now defaulting to work now 
with AQL packets and not PM4 packets.

Of course, I will send a more detailed cover letter with that version.

I know my v3 and v4 patch-set weren't reviewed (except for Alex who r-b my 
radeon patches), but I hope you/Jerome can review my v5 and coupled with the 
full stack open source, we won't have any show-stoppers from merging amdkfd to 
your 3.19 pull request to Linus.

We are of course committed and working on providing Open Source solution to 
other HSA enabled languages (e.g. Java, C++AMP) but that would require some more 
time.

Please tell me if you think this is an appropriate plan.

Thanks,

	Oded


On 11/03/2014 12:29 AM, Dave Airlie wrote:
> So since -rc5/6 cutoff last merge windows was so successful from my
> POV, I think I'll keep trucking with the idea.
>
> Things I have on my radar for this window, outside normal driver pull requests:
>
> a) rockchip drm - this needs IOMMU driver merged first so I can even
> compile it, on hold but shouldn't be a problem if the iommu driver
> gets merged somewhere first.
>
> b) atmel hlcdc - where are we on the precursor patches for this?
>
> c) atomic - Daniel seems to have done a good job pulling the helpers
> in line, Rob, Sean, Collabora - please jump on board and get this
> thing over the line.
>
> d) Exynos/bridge/make my chromebook work upstream patches, where are
> we on these, Ajay/Thierry I believe you are in the know.
>
> e) AMD new driver, if this was aiming for next merge window you are
> probably late, since it will require review at a guess.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>