Neither render layers or passes are supported at the moment. The viewport compositor currently gives you whatever was drawn on the screen. So, in fact, if you change the viewport pass to Normal, the Combined output will give you the normal pass. That’s why I wrote “Multi-pass compositing”, because you can only access one pass at a time.
I don’t want to give estimates on when multiple passes will come, as I don’t know exactly myself. I will make sure to let you know once things are in motion.
Ahh I see. Ok, thanks for the quick replies and I really appreciate your work on this!
Thanks for the reply!
Would be cool to activate and use the Real-time Compositor in solid mode too. 
since viewport compositor result is a shader is there a way to acces that shader through
blender api or through shader editor?
Need your help: unrelated topic
I created an addon for strip compositing in python. the workflow is the same with geometry node. THE PROBLEM IS THAT IS IMPOSSIBLE to assign a node_tree (path) to space_node_editor through python.
i did this doesn’t work:
space.edit_tree = bpy.data.node_groups[‘node_group’] .id_data
please help me on how to assign a node_tree to a node space_editor.
I guess that’s technical possible, but it is unclear if this should be allowed design wise.
It is not just a single shader, but many shader invocations with many used resources. So that’s not feasible.
I am not sure about your question, maybe ask in one of the python support communities.
@OmarEmaraDev before actually having multi pass rendering could be great just to enable all render passes in the viewport, but still working on single pass, one of the great benefits of this would be to access light groupdirectly in the viewport and being able to adjust its exposure in comp in real time.
Not a simple thing I think.
I’m pretty sure you already know this but I wanted to get it out of my chest 
Do you mean being able to choose one of the light group passes to view in the viewport for Cycles?
Exactly that, no need to check the full compositing, but being able to see one of the light group passes would already be very helpful.
Seems like this is an existing TODO in the Cycles module.
https://developer.blender.org/T78008
I could pick it up, but it would be better if I concentrate on the porting effort for now. Light group compositing would be one of the highlights of multi-pass compositing, so if it is not implemented by then, I will pick it up while at it.
is Z-depth going to be exposed soon? (I use this for outlines and for getting screen position vector using math)
plans for AOV?
camera matrix / vector math?
AOV is just like normals passes, so it will be supported when multi-pass compositing is supported.
Camera matrix and vector math are new features, so it is out of the scope of the viewport compositor for now.
As for Z-Depth, I did look into it last week and this week I implemented some necessary functionalities to make it useful, like the Z Normalize node. So I am hoping to add some limited support for the Z Depth pass as an exception soon.
Just an idea and this may need more design but I think viewport shader can be used for more than just realtime compositing. Like making your own viewport overlay and share them as custom assets (when compositor nodes supports them in the future).
What about not touching the glare node and instead adding an “EEVEE BLOOM NODE” that works in both regular compositing and viewport?
Legacy files and people who need/love it will still have the old glare node available.
Almost everyone else will happily use the eevee bloom node 99.7% of the time.
This is planned, but we will likely add this as another mode for the glare node as opposed to a new node.
Why? If there’s one node that I feel contains an awkward amount of content, it’s the glare.
I agree with that, bloom can be differentiated as new node like replica of eevee’s bloom to make it more generalized all over blender, not just for eevee, so someone who used bloom in eevee can easily use the same bloom in cycles with same values or cycles and eevee can have same look that user desire
Also, Many softwares differntiate glare from bloom and it can facilitate many things, maybe if there is new node only for bloom, it can have different bloom types like other software ( I dont wanna give name but its something unreal) has fast simple bloom with less accuracy like eevee maybe and more realistic bloom that is heavier to run and more accurate.
I thought adding it as a new mode would make sense because there already exist a bloom option in the Glare node, the Fog Glow method. Anyways, my statement above was just an initial thought, not a decision by any means, so we can consider adding stuff as new nodes instead when the time comes.
Yes, I agree adding eevee bloom as a new mode for glare is also nice idea at least its tidy way of doing it
but I also just thought if its also time for seperating bloom and glare from each other while adding new bloom type of eevee and maybe putting fog glow method and eevee bloom in same new node so it will be more lightweight and will be more future proof to add more modes of bloom if someone make new modes about bloom.
But if ‘‘fog glow’’ need to stay in glare node for backward compability then it might be better to put evee bloom in glare node. as a mode
So I was just brainstorming to find best way as well, so I also respect your approach of putting eevee bloom inside glare because glare also include mode of fog glow which is actually a kind of bloom
I ran into an odd viewport behavior with the current build. I have a simple composite that overlays an image over the 3D render layer image. I added a Scale node to set the scale to Absolute, and set the output image size to 960x540. However, when I adjust the viewport, the composite stretches.
The packed blend file is at Dropbox - test_green_scale.blend - Simplify your life
