r4m0n changed the topic of #kspmodders to: Technical discussion ONLY (KSP related or not), for random shit-talking, join #shitshow (seriously)
mkv has joined #kspmodders
m4v has quit [Ping timeout: 190 seconds]
mkv is now known as m4v
mkv has joined #kspmodders
m4v has quit [Ping timeout: 182 seconds]
mkv is now known as m4v
Orum has joined #kspmodders
GlsFrg|phone has joined #kspmodders
Glass|phone has quit [Read error: Connection reset by peer]
Glass|phone has joined #kspmodders
GlsFrg|phone has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
GlsFrg|phone has joined #kspmodders
Glass|phone has quit [Ping timeout: 198 seconds]
<Orum>
integer promotion rules are platform-dependent in OCL, that's fun :|
<r4m0n>
you should be explicit with your types in compute languages anyway, too much to go wrong
<Orum>
fair enough, but the idea of heterogenious platforms running the same kernel is lost when the rules are different for each platform... hell, I probably wouldn't have even spotted the issue if I didn't happen to have an AMD CPU
<Orum>
not sure what happens on the intel platform yet, but hopefully the changes I made should make it work everywhere
<r4m0n>
nowadays, you're better off writing in some intermediary language and letting it handle the details
<Orum>
such as?
<r4m0n>
will depend on application, what are you trying to accomplish?
<r4m0n>
some examples: tensorflow, CG, plain shader languages like Unity's
<Orum>
really anything that's meant for high performance processing on common hardware, but that kind of necessitates both CPU & GPU support as I still want it to run on platforms without GPUs
<Orum>
even if it is fuckslow in those situations
<r4m0n>
C++AMP might be a good option there
<r4m0n>
truth is, when people bother with GPU acceleration, they usually go with CUDA
<Orum>
well I certainly don't want to marry myself to nVIDIA
<r4m0n>
sadly it's where the performance is XD
<Orum>
not to mention it took them 3 years to even get OCL 2.0 support... in beta...
<Orum>
meh, I'm willing to sac that for portability
<r4m0n>
if you don't care about the performance over portability, you'll have to stick to the less performing ones
<Orum>
I remember AMD beating nVidia in several compute benchmarks last time I looked at cards too, but who knows how biased the benchmarks are
<Orum>
yeah, I don't think the performance is /that/ different between CUDA and OCL
<r4m0n>
the top Vega can beat a 1080 I think
<r4m0n>
there's a loss of performance on OCL vs CUDA in Nvidia, though (it's small, yeah)
<r4m0n>
what about tensorflow?
<Orum>
haven't looked at it, does it run on platforms without GPUs?
<r4m0n>
yes
* Orum
wikis
<r4m0n>
it's mostly focused on machine learning, but it's a general tensor library. you write your code in high-level python code, it generates CUDA/OCL or just runs the thing as needed
<Orum>
> pyhon
<Orum>
oh dear god no
<r4m0n>
I like it as much as you. go where the state of the art is, or keep fighting your platform incompatibilities
<Orum>
I think for now I'll just suffer through the idiosyncrasies of each platform for now
<r4m0n>
you want top performance and platform compatibility? make a version in CUDA, one in OCL for AMD and good vectorized code for intel
<Orum>
fuck that, too much to maintain
<r4m0n>
then write the 20 lines of python instead :-P
<Orum>
T_T
<r4m0n>
there are tensor libraries in lua and java if you prefer </troll>
<Orum>
lua's not bad
<r4m0n>
I think there were, anyway. java for sure, though
<Orum>
well, some of the implementations are shit, but the actual specs are good
<r4m0n>
I find the language a bit too floaty, but hell, I used it in MJ before
<Orum>
well I'll see if that's still supported, I may just do that instead
<r4m0n>
there's a tensorflow API in C++ if you prefer
<Orum>
that'd be best of all
<r4m0n>
the tensor code probably won't be the hottest...