Hi,
> Again not really important, we use LLVM and TGSI backends in the radeon drivers now. The gallium drivers currently use GPU specific LLVM IRs produced from specific LLVM backends, but that isn't strictly necessary just leads to better optimising opportunities.
> Because you now have a whole bunch of code that is useless to anyone else. Distro want to ship this sort of thing, we don't want 5 Mesa like implementations for OpenCL, we want one we can actually distribute and manage, and >maybe in 5 years support.
The point is at the current stage, we don't see the necessary of introduce all those complexity and dependencies.
Considering we can share very few code with other part of Mesa(expect some GPU related define in header files).
We want to keep this project tiny and self-contained at this point, focus on make OpenCL really fast and useful on IVB+ GPU.
We can merge or hook the backend into gallium when there are other mature gallium based OpenCL implementations.
That should not be a lot of task, consider the common code are very few.
> Some other questions:
> a) have you got an ivybridge LLVM backend? are you going to upstream this, I heard it isn't even written in LLVM machine description format.
No, we convert llvm IR to Gen IR then to IVB assembly.
There are many choices when implement an execute model of IVB. E.g 8 way or 16 way, SOA mode or AOS mode.
We choose 16 way AOS mode in the driver.
I don't know if it make sense to upstream only this particular combination.
> b) have you looked at pocl, libclc etc? Maybe you guys want to run on CPU as well at GPU at some point, in which case maybe again looking around before jumping into implementing stuff might help.
We do have looked at libclc.
Again, I don't see the necessary to introduce the complexity at this point
Almost all the functions in libclc maps to 1 instructions on IVB. We do not see the necessary of introducing a library to wrap those.
> c) does this use the open source ICD at least?
No, we will check that.
Dave.
