We have a 32 bit application and we already calling a chromium embedded framework 32 bit from it.
We now want to call to CEF3 64 bit process because, we can't upgrade our application to 64 bit.
Are there any examples how to implement it ( I read that there is an IPC architecture ) , I must say that I was able to create The sub process But, I don't see any rendering (I guess the Main UI thread is not responding).
The application model you're trying to accomplish isn't currently supported by cef3. Even if you somehow got a 64-bit cef helper executable linked to a 64-bit libcef.dll you would still need quite a lot of cef application code on your main executable.
So in principle your 32-bit main code would still need a 32-bit libcef.dll and I suspect they couldn't talk to cef's helper process because their internal IPC probably isn't platform-agnostic, in other words, it probably uses shared memory with native integers, etc and they will be incompatible, and AFAIK there's no full-feature IPC code for leveraging that.
As per your folllow up, the problem being memory consuption, here are the paths I would take if I were you:
a) Attempt to link the 32-bit executable by passing /LARGEADDRESSAWARE to the linker (assuming you're using msvc). This allows the 32-bit process to map up to 3GB of RAM, and if you search in the cef forum you'll find quite a lof of users facing problems when using 32-bit and linking without it, e.g. http://magpcss.org/ceforum/search.php?keywords=large+address ). I myself have a deployed product with 32-bit executables and haven't faced memory issues so far, and I'm using this option.
b) If that isn't enough, your best bet would be to move the browser application logic to a separate 64-bit executable and cook your own form of IPC between that and your application. Depending on what your application requires, it could be as simple as attaching the cef main window to a widget on your application and doing something as described in https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md, but I suspect it could get way more complicated than that.
Only after having a working scenario with either of above solutions I would consider having a separate cef helper executable (because getting it to work can get in your way). It's main use is to provide faster loading, because it's common to your application to link to several (sometimes huge) DLLs while the helper can be reduced to link only to libcef.dll (and c/c++ runtimes).
Should you decide to use the helper on the 32-bit scenario, don't forget to link it with /LARGEADDRESSAWARE as well.