WIP: MRT Proof of concept

[Zyko0]

What issue is this addressing?

#2930

What this PR does | solves

This is a proof of concept of MRT (multiple render target), to investigate if the concept could be integrated to ebitengine, this is not a merge candidate for now.

go run ./examples/mrt

dsts = [4]*ebiten.Image{
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
}
shaderSrc = []byte(`
//kage:units pixels

package main

func Fragment(dst vec4, src vec2, color vec4) (vec4, vec4, vec4, vec4) {
	return vec4(1,0,0,1), vec4(0,1,0,1), vec4(0,0,1,1), vec4(1,0,1,1)
}
`

{
      ebiten.DrawTrianglesShaderMRT(dsts, vertices, indices, s, nil)
      // screen.Draw all 4 images to assess that they've been written to with the same geometry / draw call
}

• OpenGL
• DirectX 11
• DirectX 12
• WebGL => A bit more problematic due to the glsl compatibility between desktop
• Metal

Notes:

• It only seems to make sense with unmanaged *ebiten.Image (as in different internal textures).
  • dst images could be moved to separate atlases if they're not ebiten.unmanaged: Support Multiple render target (MRT) #2930 (comment)
  • dst images, if moved to new textures or existing (available) ones should share the same region (rectangle) as they originally do, because of scissor, viewport definition but mostly because the triangles define the logical destination position, moving to an arbitrary region would make the triangles target the wrong rectangle
  • dst images should have the same sizes probably, since the triangles, scissor and viewport should target the same region for all destination textures
• I set the max dst images count to 8, since 8 seems to be the guaranteed minimum by all drivers
• The example found in examples/mrt is probably to be removed and changed for a more relevant example, I put it there so that we can see a minimal reproduction of the feature temporarily

[hajimehoshi]

Please update your PR for the latest main branch, thanks!

[hajimehoshi]

Why not unifying DrawTriangles with this?

[Zyko0]

I originally thought I might have a lot of additional things to write and wanted to make it distinct, but I can merge them now!
Another point is that I was afraid of the cost of the copy of an extra array of 8 pointers in all paths with (5-6x layer depth, ebiten,ui,buffered,mipmap,atlas, etc..) which would apply to all other standard two-triangles DrawImage call.

[hajimehoshi]

Another point is that I was afraid of the cost of the copy of an extra array of 8 pointers in all paths with (5-6x layer depth, ebiten,ui,buffered,mipmap,atlas, etc..) which would apply to all other standard two-triangles DrawImage call.

I don't think this would be problematic in terms of performance. Also, I'm not sure we really want 8 images (4 would be enough for example?).

[hajimehoshi]

We should be able to share most of implementations with DrawTriangles

[hajimehoshi]

Why not unifying DrawTriangles with this?

[hajimehoshi]

Why not unifying DrawTriangles with this?

[Zyko0]

Let's close this PR, since we require more 2D use cases and user requests regarding this feature: #2930 (comment)