I think this might be caused by how enderIO renders tile entities as covers, however it would be useful to see what they think. Can you open an enderIO issue as well?

No problem, I will post a new EnderIO issue.
Sorry I thought it was a problem with BC...

You start drawing in a FastTESR, that is just wrong. FastTESRs must render into the supplied buffer. This doesn't crash "in the world" because Forge uses a different buffer but the global one for the FastTESRs.

Ah ok I'll make a workaround. I'm not sure if it would be better to make pipes not a fasttesr and grab the main forge fasttesr buffer or just grab a new buffer if the main tessellator is in use.

(As although fasttesr' are meant to only use the buffer and nothing else it doesn't seem to break anything other then embedded rendering - and even then this is the first timen I've heard of it breaking another mod).

@EvoWebFrance sorry for the confusion, this is definitely a BC bug.

@AlexIIL : no problem for me, I really love both mods and only want to make them interroperable !!!

As the FastTESR runs in an environment where (a) the GL state for the TESR's render pass is not set up and and (b) the draw order is not z-sorted, I wouldn't use workarounds to render in there anyway.

Note that you can switch between fast and normal at runtime as tileEntityIn.hasFastRenderer() is the determining factor. So if you know you only have static stuff that can be batched, return true there. That way you you are fast if you can be. (In this case please prepare for the case of being rendered normally even if you could do fast---e.g. when rendered by other mods that don't do fast at all.)