checkerboard. rectangle vs shader

[Relazy]

Long story short:
What is more efficient when rendering a checkerboard is it a shader or a love.graphics.rectangle + love.graphics.setColor? (assuming its animated.)

Long story:
Judging from the way the shader works (performing a function per pixel.) the shader would immediately seem to be the most expensive since we are performing a function per pixel involving a range calculation.
However:
When we render squares (pseudo-code):
Or at least how I think love.graphics.rectangle is rendered internally.

For each frame:

Code: Select all

setShader(default)
    uploadOrthoViewport()
    bindRectangleBuffer()
	for height and width do
		sendColorToShader(default,color1 or color2)
		drawBuffer()
	end
    bindBuffer()
setShader()

There are a few costly functions here:

sendColorToShader
We are sending data to the GPU here (shader) which acts like a server with our application as the client, this transmission of data is quite expensive however we are only sending vec4 of color.

drawBuffer
I assume this is not instanced so this counts as an OpenGL draw call which is quite expensive once again since we need to tell the GPU to draw a shape.

Does the cost of sending the data to the shaders (color and draw calls) for width x height cost more than switching the shader minus the cost of switching back (uploading viewport)?

I know that this perhaps fits more on a OpenGL forum but I think its necessary to ask here as I am not 100% sure if love2d does or doesn't do a few things... Things like instancing love.graphics.rectangle and such.

Thank you

Edit: Oh whoops! Forgot to add a love file (Oh and this is a quick mockup, don't run it for too long.):

[Tjakka5]

In this case, neither would be best.
I'd suggest rendering the checkerboard to a canvas that is slightly bigger than your screen once.
Then you can offset the canvas to make it seem animated like in your example file.

[raidho36]

Pretty sure shader checkerboard would beat "software" checkerboard by a huge margin on any system. Also yes you can simply use a checkerboard texture, but that probably wouldn't fly so well if it's to be used as actual graphics.

[zorg]

Judging from the way the shader works (performing a function per pixel.) the shader would immediately seem to be the most expensive since we are performing a function per pixel involving a range calculation.

Yes, except all of that runs parallel, since you have a GPU designed to do just this, crunch data; technically even an "empty" shader that löve loads at the start, if no shader is defined, runs per-pixel each frame; it's not that big of an issue even if you're just doing something simple like a checkerboard pattern.

[Relazy]

Judging from the way the shader works (performing a function per pixel.) the shader would immediately seem to be the most expensive since we are performing a function per pixel involving a range calculation.

Yes, except all of that runs parallel, since you have a GPU designed to do just this, crunch data; technically even an "empty" shader that löve loads at the start, if no shader is defined, runs per-pixel each frame; it's not that big of an issue even if you're just doing something simple like a checkerboard pattern.

Yeah true but the data can be a bit scary haha. Assume we have 1920 x 1080 resolution thats 2073600 pixels and for each of these we have to perform a few extra calculations, lets say 4 that would then bring it to about 8294400 calculations per frame! The GPU is exceptionally good at this as you have already mentioned so this should be like a cake walk. However what I was worried about more is the CPU -> GPU communication.

(this may be incorrect if it is please correct me)
But when we switch the shader, a matrix needs to be uploaded to the shader, so the code would look more like this:

Code: Select all

start -->
setShader(myCostumShader)
uploadMatrix()
bindBuffers()

draw...

setShader(default)
uploadMatrix()
bindBuffers() -- for opengl es probably (if we only have VBO)

draw....
--> start

My concern is that Matrices need to be sent twice, not to mention the calls to setColor which sends a vec4 to the shader for each box...
so if we have a 1920x1080 grid then thats 8294400 floats sent to the shader per frame or 2073600 vec4's

I actually built two examples with this which I plan to use depending on my needs, the reason being that without shader it is more flexible, I can have underlying patterns and other things easily without having to do much maths this isn't always true however.
On the other hand when the rectangle is about 10x10 and width/height is 1920x1080... its cheaper to use a shader.

I plan to have blurs and other things applied to individual rectangles and other cool things so I guess I will keep both.

[Positive07]

Doesn't LÖVE do that anyways? I mean, LÖVE uses a default shader. The worst part of using a shader is compilation, if you are compiling shaders every frame then yeah you will se a performance hickup.

Also you could use an [wiki]Image[/wiki] or a [wiki]Canvas[/wiki], and a [wiki]Quad[/wiki], if you make the quad bigger than the image then you can use the "repeat" [wiki]WrapMode[/wiki] in [wiki](Image):setWrap[/wiki]/[wiki]Canvas:setWrap[/wiki], to move it around just make the quad bigger than the screen and move the coordinates (x,y) around in [wiki]love.graphics.draw[/wiki].

If you need to dinamically change the colors of the squares then I would go with a Shader or something else

[Relazy]

Also you could use an [wiki]Image[/wiki] or a [wiki]Canvas[/wiki], and a [wiki]Quad[/wiki], if you make the quad bigger than the image then you can use the "repeat" [wiki]WrapMode[/wiki] in [wiki](Image):setWrap[/wiki]/[wiki]Canvas:setWrap[/wiki], to move it around just make the quad bigger than the screen and move the coordinates (x,y) around in [wiki]love.graphics.draw[/wiki].

If you need to dynamically change the colors of the squares then I would go with a Shader or something else

I am building a general function for building a grid, which may or may not contain animated graphics. As such I cannot optimize it based on quads as there might be a relationship between the iterations further than just 2 x 2 pattern.

Plus this wasn't meant to be used just on a screen but in a wide variety of applications, I just want a flexible use grid, for which either a pure canvas solution or a shader based solution was viable. This removes my ability to use the screen as a stencil for the quad too as it may be smaller than the screen or bigger or rotated etc. Using a mesh along with transforms solved this when using the shader.

The worst part of using a shader is compilation, if you are compiling shaders every frame then yeah you will se a performance hickup

That would be a huge hiccup haha, I was more worried about rendering 200 checker maps on different canvases and doing other crazy things.