Yes… with the displacement modifier set to RGB>XYZ, midlevel to 0.5, strength to 1. In the texture panel, where you choose the displacement texture, in the ‘Color’ panel, uncheck clamp.
(I’m using OpenEXR to store the displacements as it allows negative values)
Looks like Brecht fixed the issue with the Mac OS X builds. Haven’t tried it yet:
https://developer.blender.org/rB48c4a5a4ddb760532440bec91618ab7feda55c79
that only works for static objects so its quite useless (why midlevel 0.5? i guess thats wrong?) just wait a little bit longer vector displacement will come in the future 
Does anyone know if the weird result of which I talked using checker texture is related to something like this Lukas patch for bricks?
https://developer.blender.org/D2230
So checker texture also would need that smoothing feature?
Anyway, it seems that it is always difficult to obtain good results in the edges transition (Not exactly always talking about geometry, but also white and black transition in texture). Here my experiments:
In layer 10: the model I used to get displacement map with blender internal.
In layer 2: using new experimental True displacement with checker texture.
In layer 3: using new experimental True displacement but with the map obtained from layer 10
In layer 4: using classic displacement modifier
So I do not know what should be the correct expected result since I get different results in all cases.
As far as I know, perfectly sharp edges can be a problem because you need an incredible amount of polygons to make the surface appear vertical (especially if said texture isn’t aligned with the topology).
I think this would be alleviated once Mai gets around to coding the geometry cache (as it would allow you to bump dicing levels to the needed amount without running out of memory). Ideally, there should be a way to dynamically tweak the topology of the mesh so it aligns with texture features, but I’m not sure if that’s possible to do with OpenSubDiv (perhaps vector-displacement + a secondary texture generated at render time)?
you’re right, midlevel should be set to 0 if we are using negative vectors. (i did a quick test, and thought the result was ok, I didn’t notice the whole object was a bit moved)
About waiting… I’ve been waiting for so long, that I had to sort out some way to still keep be able to do my job. Of course, when everything is working good (with vector displacement, viewport updates, and OSL supported), I’ll discard this and others workarounds. 
It would indeed be nice if the displacement shader output could be fed back into the modifier stack anyhow, I’m not sure how that would work best with shaders only being evaluated at render time. However I like the idea not only for micro displacement but in general, because at the moment I have to setup displacements in two completely different ways just to have it visible in viewport and rendering at the same time. That’s not only cumbersome und counter-intuitive but sometimes it’s even not possible as the modifier stack has only limited capabilities.
@Ace Dragon, Thanks for the reply.
Also in my example in layer 2 (using checker texture) I’m getting very different results in Rendered image and rendered preview from camera (Numpad 0), compared to rendered preview when the view is not from the camera (exit Numpad 0 by orbit with mouse wheel button, and you need to change to solid view and then rendered view again to see the difference). Does that’s because something has already been discussed here?
Edit:
In other words, is this a known issue/limitation or is something I should report?
Edit 2:
Ok, reported:
https://developer.blender.org/T49364
sorry if this was a known issue or some mistake I’ve made.
Getting some odd behaviour with large-scale objects. Specifically the weird flat spot appearing on the object in this clip.
Same thing happens with procedurally generated inputs and it buggers off if the object is scaled up or down just a little.
File attached for good measure.
Attachments
Weird flat spot.blend (674 KB)
Looks like a bounds padding issue. BVH is getting cut off before the object is done displacing.
Please, forgive my ignorance. Is that a setting somewhere I can change?
/Disregard my last- the build from friday seems to have fixed the issue.
Here is a quick view on my poor man’s camera based occlusion culling useful to render large micro displacement stuctures like planets.
This is genius Kai!
@Kai Kostack, That is really cool!
Could you tell me some link for tutorials or you give me some clue about how to configure this?
yes really cool stuff Kai Kostack! If you are willing to share, I am also interested in knowing how you can generate the vertex group to mask the mesh
Great Kai!
This is one those things that comes naturally as a view/camera property… :yes:
sorry, double 
Thank you, I have described how to accomplish this in the video description:
I show how my camera based occlusion culling works for the new micro displacement feature which by default subdivides everything within a certain distance of the camera. To avoid that I basically made a cone-shaped array of planes parented to the camera which masks out geometry not touched by the cone by using a Vertex Weight Proximity modifier and a Mask modifier. I have added also an extra mask object for the backside of the asteroid. It’s not exactly rocket science but saves huge amounts of memory and render time without a noticeable difference for the render result.
