Show HN: Vertexshaderart.com
vertexshaderart.com
vertexshaderart.com
On the other hand it's a little disappointing to see WebGL completely peg the CPU running stuff that wouldn't cause it to break a sweat running native.
So far I haven't seen anything useful other than a quick way to prototype ES2 shaders or doing cool demos.
The fact is that access to OpenGL is basic functionality that any platform needs.
(Also, the state of graphics drivers is extremely bad; even if your GPU claims to be capable of OpenGL 3+, it may crash the entire OS when you attempt to use it. Rollout of new GL features in a secure, sandboxed environment is quite tough and takes time.)
And on mobile, I am yet to have WebGL working properly without transforming it into a cook plate, when I don't get a black screen.
Meanwhile they do OpenGL ES 3.x without any issues while keeping a reasonable temperature.
And when WebGL 2.0 finally gets out across all devices, we will be doing Metal, Vulkan and DX12 already.
Most modern OSes monitor the GPU and if it doesn't return in a few seconds they reboot the GPU. Windows started doing that in Windows 7. OSX not until recently. Not sure if Linux does it.
The only real solution is someone making preemptable GPUs
However, it's already possible to have fairly granular control over compute resources with CUDA for example, and also to run streams of commands concurrently, so that would solve part of the problem.
The other part of the problem that could be solved by vulkan is the browser taking control of compilation, which allows for more static checking and refusal of possibly unterminated loops.
It's not easily solvable by a super-powered compiler either. Sure, you could write your own compute-driven preemptive graphics pipeline and break execution after every X billion simulated instructions & random memory accesses. You'd have to do reanalysis on every frame too, due to changing shader inputs.
The computation done is roughly (number of vertices * vertex shader compute time) + (number of pixels falling under the vertex primitives * fragment shader compute time). The shader compute times are the sums of instruction execution times + data fetch times. Then take into account early exits, data access patterns and cache sizes (otherwise the compiler'll think that e.g. a simple greyscaling fragment shader is going to cause a random memory access for every pixel and take forever to run, causing the compiler to spread the shader execution across multiple frames and kill performance dead.)
I recall people discussing Bitcoin miners implemented in Javascript and executed on the machines of unsuspecting visitors of a web page. Maybe WebGL could be used for something similar?
And of course there's the fact that suddendly GPU drivers are exposed to untrusted input from the internet via GLSL shaders.
As for GPU drivers being exposed WebGL is designed to cover that. Every input is checked, every bounds checked, shaders are re-written and drivers with bugs either worked around or banned.
But there is: Lulz.
>Every input is checked, every bounds checked
That would require solving the Halting Problem. The WebGL spec even says: https://www.khronos.org/registry/webgl/specs/latest/1.0/#4.4
>In the general case it is not possible to impose limits on the structure of incoming shaders to guard against this problem. Experimentation has shown that even very strict structural limits are insufficient to prevent long rendering times, and such limits would prevent shader authors from implementing common algorithms.
http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons...
They chose to support it in ie11 though.
The ability to hang your machine only requires the ability to ask the GPU to do lots of work. No shaders required. Even given an API that only allowed you to submit meshes you'd just build a mesh of layered polygons and zoom in to fill the screen. There's no way to limit such an API and still have it be useful.
Fortunately as pointed out then and above there's no incentive to crash your machine. Baddies get no info, no access, all they get is no one coming back to their site.
Would it be possible to add a sound icon to the front page thumbnail of the ones with audio? Then people who are e.g. at work or listening to music can skip them if they prefer - and people who actively want something with music can seek them out too.
I think that's fixed now .. for some definition of fixed
I really wanna see, but I'm scared to try again...
It would be nice if it was possible to select the point shape, e.g. to get a circle instead of the default square.
This is some sort of magic. Just 755 lines! Wow.
Does anyone know about text/vector rendering in webgl? Would I have to construct a 2d mesh manually? Ideally I'd like a logo in vector form to make some kind of "mask layer" inside the thing. What would I search to find out how to do that?
There's three commonly used methods for this:
1) Tesselate your vector shapes to triangles. This is quite tricky to get right if you have concave polygons with holes in them. You can try to find the old GLU tesselator source and port that.
2) Use the stencil-then-cover trick, which is somewhat similar to stencil shadow volumes but in 2D. This is what the nanovg [0] library does (also NV_path_rendering).
3) Use signed distance fields, which is the best way to get good looking text/vector art if you project that into a 3d surface. You either need to pre-process your vector shapes into 2d distance field textures off-line or build a custom tesselator w/ a pixel shader that does this.
WebGL is not special in this, the same tricks apply as normal OpenGL (ES).
(Also, I did open this with Safari on OS X and I did not get the issues others are talking about. However, my fans were definitely working when I loaded the tab.)
This: You write a program that is executed once for every vertex (the number of which you specify) and produces the vertex's position and color. Vertices are then drawn to the screen using the primitive type you specify: With points, each vertex results in a point (a small square, really); with triangles, three vertexes result in a triangle and so on.
Cool site, otherwise.