Compute Shaders, current support by companies

Hello,

I would like to know, from someone that had used extensively, or at least in some degree, the Compute Shaders, what's the current state of the drivers.
During the past two years I was using OpenCL, and some companies still support it in a ridiculous state. Critical bugs in the compiler and in the execution environment and without real intentions of improving it (I understand, they have their propietary solutions, like CUDA, which are better supported) To put something in production that uses OpenCL, the code must be flooded of workarounds.

What I would want to know, from someone with experience, if the current support of Compute Shaders is enough good for production, or if hardware vendors only included a bare and buggy implementation in their drivers.

If and only if you can afford it, why not simply implement what you need, test it and report bugs you find to the respective companies? If you need compute shaders but wait for someone to test their reliability ... well ...

I detected, insolated and reproduced some bugs, and then I reported them to those companies, even providing with minimal repro applications, and the state of those bug reports after a year is still: "on progress". I dont know why (and I really dont care) you supposed I didn't did that.

I dont want nobody do my work. I want to know if anybod already did that work and would share it. I thought these forums was intended for people helping each others and knowledge sharing. Sorry if my question offended you.

What I need to know is to know which is the best gpgpu solution for a multiplatform production environment, in the long term. I lost two years with OpenCL, I dont want lose other two with Compute Shaders.

At least for the AMD Linux bugtracker it seems to vary. I recently reported a bug on glUniform*v calls not handling incorrect numbers of array elements as specified, which was tended to almost immediately. Just this monday, I reported a bug on draw calls not generating any errors whatsoever when there is no VAO bound with a core context and even if someone looked at it, there's no reaction in the form of assignment or anything.

I still suggest you keep reporting and hope for the best - even if you have to invest a little time. At least with GL 4.4, vendors finally have to be at lot more in the game regarding compliance.

My main problems where with NVidia. I reported the bugs in their developer section->report bugs. My reports soon passed from "in queue" to "reproduced, work in progress"

I never say a problem is a bug in the driver if I can't isolate and reproduce it (then, it takes 0 effort for me to report it)
NV's OpenCL drivers had problems like, if you declare a structure, just declaration, not even use it, the kernel crashed at runtime (but compilation ok), or the optimized being killing the half of my kernel (writting lines after one certain line, did not affect the output buffer, even with simple sums)

I had to compile some kernels with random compilation flags to make them work (in AMD and Intel worked correctly) like no fast math for some kernels, no optimization for others, or having to force optimizations to make the kernel work. All was bugs recognised and reproduced by NV, but we didn't see progress in the drivers or in the report.

What I want to know, is if someone already used in production Compute Shaders, and if they are enough reliable to be seriously used. If not I'll have to code the propietary version for each vendor and have to maintain many different things for the same purpose, and I really want to avoid that.

if you declare a structure, just declaration, not even use it, the kernel crashed at runtime (but compilation ok), or the optimized being killing the half of my kernel (writting lines after one certain line, did not affect the output buffer, even with simple sums

How long ago was that? Just recently? I wrote a simple raytracer in OpenCL not too long ago and ran it on a GTX280 on Linux. Didn't have any problem so far. Maybe I used all my structs, though.

is if someone already used in production Compute Shaders, and if they are enough reliable to be seriously used. If not I'll have to code the propietary version for each vendor and have to maintain many different things for the same purpose, and I really want to avoid that.

Unfortunately I can't speak to that. What you could do, if possible, is write your proprietary stuff and write a single compute shader version (in sync) for a vendor that gives you the least trouble (if any ). Once implementations have stabilized, use the compute shader and throw away the proprietary stuff.

That was about one year ago. The report still says "in progress" so I didn't checked if the problem was solved because I workarounded it (a nasty choice but the only available one) and I won't go back now only to check if it was fixed despite what the issue tracker says, mainly because I'm not in that company anymore.

The problem is not that simple like creating a kernel and declaring an structure to check if all was ok. That problem happened in a complex kernel with a complex environment, not in a simple one.
All what I was able to figure was use plain variables rather than that structure made the kernel work, but if I tried that structure, it crashed in runtime (the problem was recognised by NV, so it was not a bad memory layout management by my side)
What I mean is that I really don't know what was causing the problem. I only was able to isolate the sympthims.

Of course, if I could be sure of CS reliability by simply writting some shaders, I won't asked anything. One can't predict from where these kind of problems will appear, so I can't search for them.

But, if a guy that already spent some months working with CS could say some words, that would help A LOT

I've been working with CS on NVIDIA GeForce (driver 326.84) and on Intel Haswell (driver 15.33.0.3262). I am quite happy with the state of the drivers. There are small GLSL bugs here and there but nothing major.