OpenGL Pixel Shader: how to create a random matrix of 0 and 1 (on each pixel)?

Question

So what I need is simple: every time we execute our shader (which means every pixel), I need to calculate a random matrix of 1 and 0 using resolution == originalImageResolution . How to do it?

At the moment, I created one for shadertoy, the random resolution of the matrix is ​​set to 15 by 15, because gpu does a chrome drop often when I try things like 200 by 200, while I really need the full size of the image resolution

 #ifdef GL_ES precision highp float; #endif uniform vec2 resolution; uniform float time; uniform sampler2D tex0; float rand(vec2 co){ return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * (43758.5453+ time)); } vec3 getOne(){ vec2 p = gl_FragCoord.xy / resolution.xy; vec3 one; for(int i=0;i<15;i++){ for(int j=0;j<15;j++){ if(rand(p)<=0.5) one = (one.xyz + texture2D(tex0,vec2(j,i)).xyz)/2.0; } } return one; } void main(void) { gl_FragColor = vec4(getOne(),1.0); } 

And one for Adobe pixels:

 <languageVersion: 1.0;> kernel random < namespace : "Random"; vendor : "Kabumbus"; version : 3; description : "not as random as needed, not as fast as needed"; > { input image4 src; output float4 outputColor; float rand(float2 co, float2 co2){ return fract(sin(dot(co.xy ,float2(12.9898,78.233))) * (43758.5453 + (co2.x + co2.y ))); } float4 getOne(){ float4 one; float2 r = outCoord(); for(int i=0;i<200;i++){ for(int j=0;j<200;j++){ if(rand(r, float2(i,j))>=1.0) one = (one + sampleLinear(src,float2(j,i)))/2.0; } } return one; } void evaluatePixel() { float4 oc = getOne(); outputColor = oc; } } 

So, my real problem is that my shaders are causing my GPU device to crash. How to use GLSL for the same purpose as now, but with an error and, if possible, faster?

Update: What I want to create is called Single-Pixel Camera (Google Compressive Imaging or Compressive Sensing), I want to create a gpu-based software implementation.

The idea is simple:

• we have an image - NxM .
• for each pixel in the image, we want the GPU to perform the following operations:
  • to generate NxM matrix of random values ​​- 0 and 1 s.
  • calculate the arithmetic mean of all pixels of the original image whose coordinates correspond to coordinates 1 in our random matrix NxM
  • The result of outputting an arithmetic value as the color of a pixel.

What I was trying to implement in my shaders was to simulate this cautious process.

Which is really stupid in trying to do this on gpu:

• Compressive Sensing does not allow us to calculate the NxM matrix for such averages, it requires only peace (for example, 1/3 ). Therefore, I put pressure that I do not need on the GPU. However, testing for more data is not always bad ideas.

Answer 1

Thank you for adding more details to clarify your question. My comments are too long, so I'm going to reply. Moving comments here to save them together:

Sorry I'm slow, but I'm trying to understand the problem and purpose. In your GLSL example, I do not see the generated matrix. I can see that one vec3 is generated by summing a random selection (changing over time) of cells from 15 x 15 textures (matrices). And this vec3 is recalculated for each pixel. Then vec3 is used as the color of the pixel.

So, I don’t understand if you really want to create a matrix or just want to calculate the value for each pixel. The latter is, in a sense, a “matrix”, but calculating a simple random value for 200 x 200 pixels will not strain your graphics driver. You also said that you want to use the matrix. Therefore, I do not think what you mean.

I'm trying to understand why you want to get a matrix - to keep a consistent random basis for all pixels? If so, you can either precompile the random texture, or use a sequential pseudo-random function, like you did in rand (), except for using time without using it. You clearly know about this, so I think I still do not understand the purpose. Why are you summing up a random selection of cells from the texture for each pixel?

I believe that the reason your shader crashes is because your main() function exceeds its time limits - either for a single pixel or for the entire set of pixels. Calling rand() 40,000 times per pixel (in a nested loop 200 * 200) can certainly explain this! If you had 200 x 200 pixels and you called sin () 40k times for each of them, then 160,000,000 calls per frame. Bad GPU!

I hope that if we understand the goal better, we can recommend a more effective way to get the desired effect.

Refresh.

(This part has been removed because it was mistakenly accepted. Although many cells in the original matrix may contribute less than the result of the visually detectable color to the result, the total number of many cells may contribute the visually detectable amount of color.)

New update based on an updated question.

OK, (thinking out loud here so you can check if I understand correctly ...) Since you need each of the random NxM values ​​only once, there is no actual requirement to store them in a matrix; values ​​can simply be calculated on demand and then thrown away. This is why your sample code above does not create a matrix.

This means that we cannot avoid generating (NxM) ^ 2 random values ​​for each frame, that is, NxM random values ​​per pixel, and there are NxM pixels. Thus, for N = M = 200, this is 160 million random values ​​per frame.

However, we can still optimize some things.

• First, since your random values ​​should only be one bit at a time (you only need a logical answer to decide whether to include each cell from the original texture in the mix), you can probably use a cheaper pseudo random number generator. The one you use outputs much more random data per call than one bit. For example, you could call the same PRNG function as you do now, but save the value and extract 32 random bits from it. Or at least a few, depending on how many of them are random enough. Also, instead of using the sin () function, if you have the GL_EXT_gpu_shader4 extension (for bitwise operators), you can use something like this :

.

 int LFSR_Rand_Gen(in int n) { // <<, ^ and & require GL_EXT_gpu_shader4. n = (n << 13) ^ n; return (n * (n*n*15731+789221) + 1376312589) & 0x7fffffff; } 

• Secondly, you are currently doing one division action for each cell included ( /2.0 ), which is probably relatively expensive if the compiler and GPU cannot optimize it for bit-shift (is this possible with a floating point?) ., It also will not give the arithmetic mean of the input values, as discussed above ... it will bring much more weight to the later values ​​and very little to the earlier ones. As a solution, consider how many values ​​are included, and divide by that number once, after the loop ends.

Whether this optimization will be sufficient so that your GPU driver can control 200x200 * 200x200 pixels per frame, I do not know. They should definitely allow you to significantly increase resolution.

These are ideas that arise from my head. Although I am far from being an expert on the GPU. It would be great if someone more qualified could hear suggestions.

PS In your comment, you jokingly (?) Mentioned the option to pre-calculate N * M NxM random matrices. Maybe this is not a bad idea? 40,000x40,000 is a great texture (at least 40 MB), but if you store 32 bits of random data per cell, it will decrease to 1250 x 40,000 cells. Too bad the vanilla GLSL does not help you with bitwise operators to extract data, but even if you do not have the GL_EXT_gpu_shader4 extension, you can still fake it. (Maybe you also need a special extension for non-square textures?)