Hi, is this problem still an issue 2.78c ?

Thanks for the report, but please keep in mind that 2.8 is still totally WIP, reporting known TODOs does not help us really, especially when we even took the care to add a message stating this is not working currently…

Here I mention some other examples where I encounter problems with volumetrics. I am not good with nodes, so I apologize if this is due to my mistakes with configuration.
In the following example there are differences between GPU and CPU render:

solved by latest commit :D

Good that we cached that before release, thanks!

This append (lol) to me some times...
In fact, if the geometry you're appending is already linked in the .blend file , chances are that it will re-link it into the scene instead of appending...
You can try to append the musket ball in a fresh new scene and see if it's linked.

Do you still have the problem if experimental is not selected? Its experimental for a reason.

We need a .blend and exacts steps to reproduce this problem. Append in general is working I think, there must be something specific about the case you found. It might also be worth trying the latest daily build: https://builder.blender.org/download/

There is now D2702 to improve this, it's more of a To Do anyway so we can leave the discussion there.

It does actually align to the center of the bounding box, but for text objects it works differently, while meshes and curves seem to be ok.

Fixed now. D2613 only affects Cycles side persistent data, so would not have made any difference here.

I had no issues getting a stacktrace, seems to be caused by rB880e96dd667aedea17353803bcc5721f3cc34d50 , ID_IS_LINKED_DATABLOCK(ob->data) derefs a null pointer, @Bastien Montagne (mont29) can you take a peek?

another thing is, when I render on 2 GPUs a scene that takes more then dedicated memory, the system memory will be used. If those generated textures are kept around, we have 3 times the textures. The cache Blender silently creates and the 2 versions created by the OpenCL driver. As the time needed to initialize rendering is not much faster the second time compared to using the cache, but many GB memory are away, making it more certain that swapping will be triggered, the cache may greatly slow down render for a benefit which is pretty low, at least in my tests.

ok, then it's not a bug, but wouldn't it make sens to only have this behavior when "persistent data" is checked and free it otherwise?

This .blend file is using generated images as textures. When Cycles renders generated / packed images, Blender will create / load the image buffers and keep them around in memory. For regular images on disk this is not a problem.

I'm not sure if it is float precision issue, but one can see pretty quickly (after 4000 or 8000 samples) that it will converge to a different result.

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.