Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shaders: How to draw high fidelity graphics with just x and y coordinates

makingsoftware.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#51

Post by anikom15 »

namuol wrote: post #38

Programming in general is about converting something you understand into something a computer understands, and making sure the computer can execute it fast enough. This is already hard enough as it is, but GPU programming (at least in its current state) is an order of magnitude worse in my experience. Tons of ways to get tripped up, endless trivial/arbitrary things you need to know or do, a seemingly bottomless pit o…

OpenGL and pre-12 DirectX were the attempt at unifying video programming in an abstract way. It turned out that trying to abstract away what the low-level hardware was doing was more harmful than beneficial.

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#52

Post by spiralcoaster »

GuB-42 wrote: post #16

That, I think, is the most unintuitive part about writing fragment shaders. The idea that you take a couple of coordinates and output a color. Compared to traditional drawing, as with a pen and paper, you have to think in reverse. For example if you want to draw a square with a pen, you put your pen where the square is, draw the outlines, than fill it up, with a shader, for each pixel, you look at where you are, calc…

If you are using fragment shaders to draw squares you're doing something wrong.

Shaders would be more for something like _shading_ the square.

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#53

Post by spiralcoaster »

immibis wrote: post #2

You can do some pretty impressive things: https://shadertoy.com/ I skimmed it but didn't see any mention of "ray marching", which is raytracing done in a shader. GPUs are pretty fast now. You can just do that. However you do have to encode the scene geometry analytically in the shader - if you try to raytrace a big bag of triangles, it's still too slow. There's more info on this and other techniques at https://iquile…

Why were you expecting this article to specifically mention ray marching? It looks like a comprehensive beginner article on what shaders are, not an exhaustive list of what you can do with them.

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#55

Post by adastra22 »

spiralcoaster wrote: post #52
GuB-42 wrote: post #16

That, I think, is the most unintuitive part about writing fragment shaders. The idea that you take a couple of coordinates and output a color. Compared to traditional drawing, as with a pen and paper, you have to think in reverse. For example if you want to draw a square with a pen, you put your pen where the square is, draw the outlines, than fill it up, with a shader, for each pixel, you look at where you are, calc…

If you are using fragment shaders to draw squares you're doing something wrong. Shaders would be more for something like _shading_ the square.

Ray casting shaders are a thing. A very performant thing too.

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#56

Post by dahart »

Kiro wrote: post #50
dahart wrote: post #39

Earlier quoted context omitted.

Figuring out if a pixel is within a shape, or is on the A-B intersection line, is part of the rasterizing step, not the shading. At least in the parent’s analogy. There are quite a few different ways to draw a red line between two points. Also using CPU and GPU here isn’t correct. There is no difference in the way CPUs and GPUs draw things unless you choose different drawing algorithms.

While (I presume) technically correct I don't think your clarifications are helpful for someone trying to understand shaders. The only thing that made me understand (fragment) shaders was something similar to the parent's explanation. Do you have anything better? It's not about the correct way to draw a square or a line but using something simple to illustrate the difference. How would you make a shader drawing a 10x…

You’re asking a strange question that doesn’t get at why shaders exist. If you actually want to understand them, you must understand the bigger picture of how they fit into the pipeline, and what they are designed to do.

You can do line drawing on a CPU or GPU, and you don’t need to reach for shaders to do that. Shaders are not necessarily the right tool for that job, which is why comparing shaders to pen drawing makes it seems like someone is confused about what they want.

ShaderToy is fun and awesome, but it’s fundamentally a confusing abuse of what shaders were intended for. When you ask how to make a 10x10 pixel square, you’re asking how to make a procedural texture with a red square, you’re imposing a non-standard method of rendering on your question, and failing to talk about the way shaders work normally. To draw a red square the easy way, you render a quad (pair of triangles) and you assign a shader that returns red unconditionally. You tell the rasterizer the pixel coordinate corners of your square, and it figures out which pixels are in between the corners, before the shader is ever called.

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#57

Post by kaoD »

dahart wrote: post #42
kaoD wrote: post #11

Earlier quoted context omitted.

Nitpick: "raymarching" is not "raytracing done in a shader" and it's not polygon-based. Raymarching is a raytracing technique that takes advantage of Signed Distance Functions to have a minimum bound on the ray's distance to complex surfaces, letting you march rays by discrete amounts using this distance[0]. If the distance is still large after a set number of steps the ray is assumed to have escaped the scene. This…

> Raymarching is a raytracing technique… Did you mean ‘raymarching is a technique…’? Otherwise you’re somewhat contradicting the first sentence, and also ray marching and ray tracing are two different techniques, which is what you’re trying to say, right? Raymarching can be polygon based, if you want. It’s not usually on ShaderToy, but there’s no technical reason or rule against raymarching polygons. And use of Monte…

Sorry, let me clarify, the terms are used imprecisely.

Some people use "raytracing" only for the ray intersection technique, but some people (me included, in the post above) consider it an umbrella term and raymarching, path tracing, etc. only as specific techniques of raytracing.

So what I meant is "'raymarching' is not 'raytracing in shaders' but just a technique of raytracing, in shaders or not".

I was not correcting OP, just adding clarifications on top.

> Raymarching can be polygon based, if you want

But not polygon-intersection-based, it'd still be a SDF (to an implicit polygon).

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#58

Post by CrimsonCape »

I see lots of shader related videos but to me the worst part of GPU code is that the setup is archaic and hard to understand.

Does anyone have a good resource for the stages such as:

- What kind of data formats do I design to pipe into the GPU? Describe like i'm five texcels, arrays, buffers, etc.

- describe the difference between the data formats of traditional 3D workflow and more modern compute shader data formats

- Now that I supplied data, obviously I want to supply transformations as well. Transforms are not commutative, so it implies there is sequential state in which transforms are applied which seems to contradict this whole article

- The above point is more abstractly part of "supplying data into the GPU at a later stage". Am I crossing the CPU-GPU boundary multiple times before a frame is complete? If so describe the process and how/why.

- There is some kind of global variable system in GPUs. explain it. List every variable reachable from a shader fragment program

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#59

Post by namuol »

anikom15 wrote: post #51
namuol wrote: post #38

Programming in general is about converting something you understand into something a computer understands, and making sure the computer can execute it fast enough. This is already hard enough as it is, but GPU programming (at least in its current state) is an order of magnitude worse in my experience. Tons of ways to get tripped up, endless trivial/arbitrary things you need to know or do, a seemingly bottomless pit o…

OpenGL and pre-12 DirectX were the attempt at unifying video programming in an abstract way. It turned out that trying to abstract away what the low-level hardware was doing was more harmful than beneficial.

> It turned out that trying to abstract away what the low-level hardware was doing was more harmful than beneficial.

Abstraction isn’t inherently problematic, but the _wrong_ abstraction is. Just because abstraction is hard to do well, doesn’t mean we shouldn’t try. Just because abstraction gets in the way of certain applications, doesn’t mean it’s not useful in others.

Not to say nobody is trying, but there’s a bit of a catch-22 where those most qualified to do something about it don’t see a problem with the status quo. This sort of thing happens in many technical fields, but I just have to pick on GPU programming because I’ve felt this pain for decades now and it hasn’t really budged.

Part of the problem is probably that the applications for GPUs have broadened and changed dramatically in the last decade or so, so it’s understandable that this moves slowly. I just want more people on the inside to acknowledge the problem.

Re: Shaders: How to draw high fidelity graphics with just x and y coordinates

#60

Post by dahart »

CrimsonCape wrote: post #58

I see lots of shader related videos but to me the worst part of GPU code is that the setup is archaic and hard to understand. Does anyone have a good resource for the stages such as: - What kind of data formats do I design to pipe into the GPU? Describe like i'm five texcels, arrays, buffers, etc. - describe the difference between the data formats of traditional 3D workflow and more modern compute shader data formats…

You’re partly asking questions about APIs rather than questions about GPUs. It might help to identify any specific goals you have and any specific tools or APIs you intend to use.

In general, you can use just about any data format you want. Since GPUs are SIMT, it’s good to try to keep data access coherent in thread groups, that’s the high level summary. There are various APIs that come with formats ready for you. Depends on whether you’re talking textures, geometry, audio, fields, NN weights, etc., etc.

I’m not sure I understand what you mean about sequential state contradicting the article. Shaders don’t necessarily need to deal with transforms (though they can). Transforms in shaders are applied sequentially within each thread, and are still parallel across threads.

Crossing the CPU GPU boundary is an application specific question. You can do that as many times as you have the budget for. Crossing that boundary might imply synchronization, which can affect performance.

For global variables, you might be thinking of shader uniforms, but I can’t tell. Uniforms are not globals, they are constants passed separately to each thread, even when the value is the same for each thread. You can use globals in CUDA with atomic instructions that causes threads to block when another thread is accessing the global. That costs performance, so people will avoid it when possible.

I hope that helps. Answering these is a bigger question than just shaders, it’s more like understanding the pipeline and how GPUs work and knowing what APIs are available. An intro course to WebGL might be a good starting point.

Post reply on HN