shader: Split Kage into another package

[hajimehoshi]

CC @Noofbiz

The priority is not determined yet.

[Splizard]

Hey @hajimehoshi

I'm currently working on a gpu package in Go, it's designed to take advantage of modern rendering features to get the most performance out of the GPU (tries to minimize C calls & heavy use of command lists). It's still in the early stages of design and usage but performance is very good. I am currently only targeting OpenGL 4.6 but I want to include other drivers in the future.
As an API for Go developers the most difficult aspect of supporting multiple drivers is shader support. Since currently, the developer would need to rewrite their shader for each driver backend (or even OpenGL version).

I noticed that you have been working on Kage and I saw this issue and I was wondering if it is worth putting Kage into another repo as its own project? I've been taking a look at it, and I think it's a great idea and something I could see myself contributing to. I like the idea of Go for GPUs and I think it would be a solution for supporting shaders targeting multiple drivers. I think my only concern with Kage is how far it has strayed from the core Go specification, it does make things convenient to have vec2, vec3 constructors and swizzling. However, on the other hand, it makes it more obscure for developers who are mostly familiar with Go. What are your thoughts on this? Would you be interested at all in collaborating on this issue?

[Splizard]

I may as well post an example, so you get an idea of where things could go. If Kage sticks to a subset of Go, then we get full Go tooling support, we get Godoc, we can run tests against the shaders and even use the shaders for software rendering using a derivative of https://github.com/fogleman/fauxgl

The question is, what would a pure Go shader look like?
Going by the example on https://ebiten.org/documents/shader.html, I designed something that could work.
It's a bit more verbose but also more flexible, potentially supporting more of what modern shading languages can do.

package shaders

//semi-virtual packages like syscall/js
//these could all be real packages and provide native implementations so that the
//shader can be compiled and/or tested as usual.
import "path/to/gpu"
import "path/to/vec3"
import "path/to/vec4"
import "path/to/float"
import _ "embed"

//go:embed this_file.go
var Source []byte //embedded so that shader can be compiled at runtime

//attributes
type Vertex struct {
	Position gpu.Vec4
	TexCoord gpu.Vec2

	Color gpu.Vec4
}

//fragment shader inputs
type Fragment struct {
	Position gpu.Vec4
	TexCoord gpu.Vec2
	Color gpu.Vec4
}

//uniforms and shader buffers
type Shader struct{
	Time float32  
	Cursor gpu.Vec2
	ScreenSize gpu.Vec2

	ImageSrc0 gpu.Sampler
	ImageSrc1 gpu.Sampler 
}

//vertex shader
func (Shader) Vertex(v Vertex, out *Fragment) gpu.Vec4 {
	out.Position = v.Position
	out.TexCoord = v.TexCoord
	out.Color = v.Color
	return v.Position
}

//fragment shader
func (s Shader) Fragment(f Fragment) gpu.Vec4 {
	lightpos := gpu.Vec3{s.Cursor.X, s.Cursor.Y, 50}
	lightdir := vec3.Normalize(vec3.Sub(lightpos, f.Position.XYZ()))
	normal := vec4.Normalize(gpu.Sample(s.ImageSrc1, f.TexCoord))
	ambient := float32(0.25)
	diffuse := 0.75 * float.Max(0, vec3.Dot(normal, lightdir))

	return vec4.Scale(gpu.Sample(s.ImageSrc0, f.TexCoord), ambient + diffuse)
}

Again, be great to hear your thoughts and if this isn't the right place to have this discussion, do let me know.

[hajimehoshi]

Hi,

Let me leave a quick reply. For a discussion about the specification of Kage, please use Discussion

I'll read your proposal carefully later.

Thanks,

[hajimehoshi]

I think my only concern with Kage is how far it has strayed from the core Go specification, it does make things convenient to have vec2, vec3 constructors and swizzling.

I think the specification difference from the original Go doesn't matter here. Another incompatible thing is e.g., precision of floats (the keyword float doesn't exist in Go anyway). So I already gave up making Kage 100% compatible with Go.