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.
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:
Hi Dave,
On Mon, 3 Nov 2014 08:29:24 +1000 Dave Airlie airlied@gmail.com wrote:
What do you mean by "precursor patches" ?
If by precursor patches you mean the dependencies of the DRM driver, here is a quick status:
- The atmel-hlcdc [1] MFD driver has been taken by Lee Jones - My series reworking the flip-work infrastructure [2] has been acked by Rob and is waiting for you (I guess I should rebase it on 3.18-rcX or drm-next) ;-) - My series sharing video bus format definitions between the V4L2 and DRM subsystems [3] is still being discussed. AFAICT, the only blocking point is that we need a documentation describing the available formats and we don't know which format to use (DocBook or txt) and where this documentation should be stored.
Regarding the driver itself, I still have to address Nicolas' (Ferre) comments, and Thierry (Reding) was concerned by the proposed DT binding (don't know if it's still the case).
Anyway, I really expect this driver to merged in 3.19 so let me know if you see other blocking issues...
Best Regards,
Boris
[1]https://patchwork.ozlabs.org/patch/396808/ [2]http://thread.gmane.org/gmane.comp.video.dri.devel/110016 [3]https://lkml.org/lkml/2014/9/29/330
On Sun, Nov 2, 2014 at 5:29 PM, Dave Airlie airlied@gmail.com wrote:
No plans to merge amdgpu for 3.19.
Alex
On Mon, Nov 03, 2014 at 08:29:24AM +1000, Dave Airlie wrote:
Daniel briefly looked at this and was somewhat disgusted with how little safety this framework has built in. The infrastructure was copied from DRM panel which therefore suffers from the same shortcomings. I've been working on a small set of patches to implement some generic mechanism to add reference counting and such for this type of infrastructure.
Until those patches are ready I think we either can't merge the patches or we take the risk that drivers will actually use the current fragile infrastructure in a safe way and then supply the safer infrastructure later on.
Thierry
dri-devel@lists.freedesktop.org