An unbiased* global illumination ray tracer running in your web browser, 
with a max_trace_depth of 8 and support for shiny, diffuse, transparent 
and checkered spheres. What more do you want!

Just run the attached html on a PC with a fast GPU, you can drag around 
the scene with your pointer. Inside the html file you can change the 
size of the image (right at the end of the file you'll see width and 
height tags), using non-power-of-two values may not work on your 
graphics card.

You can get some pretty cool effects by looking through the glass ball 
into the mirrored ball.

Disclaimer: It works on my machine (Chrome, Win7, nVidia GTX970) but 
I've not tested it on any other machine. Particularly if you have a much 
slower graphics card it may run so slowly that it crashes, or it may not 
run at all. Also make sure you have the latest graphics drivers, no I'm 
not just saying this it often makes a difference. The output should look 
similar to the attached image after a few seconds.

...

After creating the standalone html5 page for blobs thread above, I 
realised it would allow me to do something shadertoy doesn't - that is, 
reuse results from a previous calculation in the next frame. I already 
had an attempt at a path-tracer in C# (which was in turn translated from 
some C++ code I found somewhere) but it was pretty slow. The main 
sticking point I had was learning how to render to texture using webGL. 
So it renders one "frame" at a time, which actually consists of 10 
samples per pixel, it then averages this with all the previous results. 
It then repeats until you move the viewpoint. The result is that once 
you stop dragging the scene around the noise should disappear eventually.

Your browser will probably limit the speed of updates to 60 frames per 
second, so that equals 600 samples per second. You can increase the 
number of samples per frame on line 39. But I found if you make it too 
high that a single frame takes longer than a second or so the video 
driver crashes.

* One of the hardest bits is to get a random number generator running on 
the GPU that is random enough to not show any patterns after a while. 
There is still some subtle non-randomness visible, but it's way better 
than it was originally. That's why there's random bits of code like 
rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.

Post a reply to this message

Attachments:
Download 'rtpt.html.htm' (19 KB) Download 'image.png' (355 KB)

Preview of image 'image.png'

On 24/07/2015 04:05 PM, scott wrote:
> An unbiased* global illumination ray tracer running in your web browser,
> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
> and checkered spheres. What more do you want!

Damn, that sounds nice...

> Disclaimer: It works on my machine (Chrome, Win7, nVidia GTX970) but
> I've not tested it on any other machine.

Ah well. I just get a JavaScript alert telling me that it can't 
initialise shader1, then a couple that say "null", and then a message 
that it can't initialise shader2.

Ironically, I have a nearly identical setup: Opera (so, the Chrome 
rendering engine), Windows 7, and an nVidia 600-series GPU.

> * One of the hardest bits is to get a random number generator running on
> the GPU that is random enough to not show any patterns after a while.
> There is still some subtle non-randomness visible, but it's way better
> than it was originally. That's why there's random bits of code like
> rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.

Ah yes - it's not like you can just run the Mersenne Twister on a GPU... ;-)

Post a reply to this message

On Fri, 24 Jul 2015 19:00:19 +0200, Orchid Win7 v1 <voi### [at] devnull> wrote:

> On 24/07/2015 04:05 PM, scott wrote:
>> An unbiased* global illumination ray tracer running in your web browser,
>> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
>> and checkered spheres. What more do you want!
>
> Damn, that sounds nice...
>
>> Disclaimer: It works on my machine (Chrome, Win7, nVidia GTX970) but
>> I've not tested it on any other machine.
>
> Ah well. I just get a JavaScript alert telling me that it can't  
> initialise shader1, then a couple that say "null", and then a message  
> that it can't initialise shader2.
>
> Ironically, I have a nearly identical setup: Opera (so, the Chrome  
> rendering engine), Windows 7, and an nVidia 600-series GPU.
>
>> * One of the hardest bits is to get a random number generator running on
>> the GPU that is random enough to not show any patterns after a while.
>> There is still some subtle non-randomness visible, but it's way better
>> than it was originally. That's why there's random bits of code like
>> rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.
>
> Ah yes - it's not like you can just run the Mersenne Twister on a GPU...  
> ;-)

Same here. But that was on Chrome. My graphics card is only an Ati 5770

-- 
-Nekar Xenos-

Post a reply to this message

>> Ah well. I just get a JavaScript alert telling me that it can't
>> initialise shader1, then a couple that say "null", and then a message
>> that it can't initialise shader2.
>>
>> Ironically, I have a nearly identical setup: Opera (so, the Chrome
>> rendering engine), Windows 7, and an nVidia 600-series GPU.

>> Ah yes - it's not like you can just run the Mersenne Twister on a
>> GPU... ;-)
>
> Same here. But that was on Chrome. My graphics card is only an Ati 5770

Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia 
Quadro something) and it worked ok.

Maybe it's something to do with the length of the shader? You could try 
reducing the number of samples down to 1 (line 39) and the trace depth 
down to 2 or something (line 118), that should make the shader much shorter.

Post a reply to this message

On 24/07/2015 04:05 PM, scott wrote:
> An unbiased* global illumination ray tracer running in your web browser,
> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
> and checkered spheres. What more do you want!

In other news, I just found this:

http://madebyevan.com/webgl-water/

Now I'm wondering why this thing that runs in a web browser and barely 
taxes the system looks 500x better than the water in any computer game, 
ever...

Post a reply to this message

On Fri, 24 Jul 2015 20:27:08 +0200, Orchid Win7 v1 <voi### [at] devnull> wrote:

> On 24/07/2015 04:05 PM, scott wrote:
>> An unbiased* global illumination ray tracer running in your web browser,
>> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
>> and checkered spheres. What more do you want!
>
> In other news, I just found this:
>
> http://madebyevan.com/webgl-water/
>
> Now I'm wondering why this thing that runs in a web browser and barely  
> taxes the system looks 500x better than the water in any computer game,  
> ever...
>

Good question. Looks awesome.

-- 
-Nekar Xenos-

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> An unbiased* global illumination ray tracer running in your web browser,
> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
> and checkered spheres.
>
Excellent!

> What more do you want!
>
Um... how about full support for POV-Ray's SDL? jk ;D

> Disclaimer: It works on my machine (Chrome, Win7, nVidia GTX970) but
> I've not tested it on any other machine.
>
It works on my laptop (hardware is two AMD A6-4400M APU 2.7 GHz processors w/
integrated Radeon HD 7520G GPUs [not particularly bragworthy]) using Firefox
(see attachment). IE couldn't initialize shader1, but it did display the samples
counter.

> After creating the standalone html5 page for blobs thread above, I
> realised it would allow me to do something shadertoy doesn't - that is,
> reuse results from a previous calculation in the next frame.
>
I'll have to look into reusing samples again. My sole attempt used a 32 bit RGBA
texture (unsigned 8 bpp), but it never converged into an acceptably noise-free
result. I figured if I used a higher bit depth I might get better results.

Post a reply to this message

Attachments:
Download 'ffss-cropped.png' (154 KB)

Preview of image 'ffss-cropped.png'

On Fri, 24 Jul 2015 19:57:47 +0200, scott <sco### [at] scottcom> wrote:

>>> Ah well. I just get a JavaScript alert telling me that it can't
>>> initialise shader1, then a couple that say "null", and then a message
>>> that it can't initialise shader2.
>>>
>>> Ironically, I have a nearly identical setup: Opera (so, the Chrome
>>> rendering engine), Windows 7, and an nVidia 600-series GPU.
>
>>> Ah yes - it's not like you can just run the Mersenne Twister on a
>>> GPU... ;-)
>>
>> Same here. But that was on Chrome. My graphics card is only an Ati 5770
>
> Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia  
> Quadro something) and it worked ok.
>
> Maybe it's something to do with the length of the shader? You could try  
> reducing the number of samples down to 1 (line 39) and the trace depth  
> down to 2 or something (line 118), that should make the shader much  
> shorter.
>

Great stuff!!
It works with samples 1, trace depth 6. If I try samples 2, I can only go  
up to trace depth 3.


-- 
-Nekar Xenos-

Post a reply to this message

On Fri, 24 Jul 2015 20:27:08 +0200, Orchid Win7 v1 <voi### [at] devnull> wrote:

> On 24/07/2015 04:05 PM, scott wrote:
>> An unbiased* global illumination ray tracer running in your web browser,
>> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
>> and checkered spheres. What more do you want!
>
> In other news, I just found this:
>
> http://madebyevan.com/webgl-water/
>
> Now I'm wondering why this thing that runs in a web browser and barely  
> taxes the system looks 500x better than the water in any computer game,  
> ever...
>

Wow! It even runs on my cell-phone!

-- 
-Nekar Xenos-

Post a reply to this message

On 24/07/2015 06:57 PM, scott wrote:
> Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia
> Quadro something) and it worked ok.
>
> Maybe it's something to do with the length of the shader? You could try
> reducing the number of samples down to 1 (line 39) and the trace depth
> down to 2 or something (line 118), that should make the shader much
> shorter.

I too was able to get this working by turning down the number of samples 
and the trace depth.

I also doubled the size of the image, so I can see what I'm looking at. 
(It seems to not like any size that isn't a power of 2. Then again, I 
have no idea how this stuff works, so...)

Post a reply to this message

On 26/07/2015 01:47 PM, Orchid Win7 v1 wrote:
> On 24/07/2015 06:57 PM, scott wrote:
>> Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia
>> Quadro something) and it worked ok.
>>
>> Maybe it's something to do with the length of the shader? You could try
>> reducing the number of samples down to 1 (line 39) and the trace depth
>> down to 2 or something (line 118), that should make the shader much
>> shorter.
>
> I too was able to get this working by turning down the number of samples
> and the trace depth.

I presume it looks weird due to the limited trace depth. (?)

Post a reply to this message

Attachments:
Download 'webgl.jpg' (108 KB)

Preview of image 'webgl.jpg'

On 24/07/2015 06:00 PM, Orchid Win7 v1 wrote:
> On 24/07/2015 04:05 PM, scott wrote:
>> * One of the hardest bits is to get a random number generator running on
>> the GPU that is random enough to not show any patterns after a while.
>> There is still some subtle non-randomness visible, but it's way better
>> than it was originally. That's why there's random bits of code like
>> rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.
>
> Ah yes - it's not like you can just run the Mersenne Twister on a GPU...
> ;-)

...actually, apparently you *can* run MT on a GPU. o_O

Trouble is, it's laughably slow.

Have you seen this? The accepted answer looks simplish...

http://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu

Post a reply to this message

On 26/07/2015 14:19, Orchid Win7 v1 wrote:
> On 26/07/2015 01:47 PM, Orchid Win7 v1 wrote:
>> On 24/07/2015 06:57 PM, scott wrote:
>>> Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia
>>> Quadro something) and it worked ok.
>>>
>>> Maybe it's something to do with the length of the shader? You could try
>>> reducing the number of samples down to 1 (line 39) and the trace depth
>>> down to 2 or something (line 118), that should make the shader much
>>> shorter.
>>
>> I too was able to get this working by turning down the number of samples
>> and the trace depth.
>
> I presume it looks weird due to the limited trace depth. (?)

Yes it's probably highlighting the limitations in the RNG by only have a 
low trace depth. I uploaded a video of what it looks like here (samples 
40, trace depth 8) - woohoo for compressing noisy video!

https://youtu.be/rXQa5kHspFk

It only works with powers of two because your graphics card only allows 
power of two sized textures, and I'm not doing anything clever to check 
for powered-of-two-ness of the canvas size and creating bigger textures...

Also it's strange after staring at grainy images for a while your 
eye/brain just filters it out and you don't notice it. It's only when 
you then switch to a smooth image you go "wow that's really smooth" :-)

Post a reply to this message

On 26/07/2015 07:16 PM, scott wrote:
> On 26/07/2015 14:19, Orchid Win7 v1 wrote:
>> I presume it looks weird due to the limited trace depth. (?)
>
> Yes it's probably highlighting the limitations in the RNG by only have a
> low trace depth. I uploaded a video of what it looks like here (samples
> 40, trace depth 8) - woohoo for compressing noisy video!
>
> https://youtu.be/rXQa5kHspFk

Damn, your graphics card is *drastically* faster than mine... (When I 
pan the image, it comes out yellow for the first half a dozen frames.)

Apparently it's time to buy a more expensive GPU.

> It only works with powers of two because your graphics card only allows
> power of two sized textures, and I'm not doing anything clever to check
> for powered-of-two-ness of the canvas size and creating bigger textures...
>
> Also it's strange after staring at grainy images for a while your
> eye/brain just filters it out and you don't notice it. It's only when
> you then switch to a smooth image you go "wow that's really smooth" :-)

As I say, I never get to see it completely smooth. But hey, I guess I 
need a bigger stick. ;-)

I wonder... how long will it be before games look like this in realtime? 
(I'm guessing a while, since this scene contains a piffling half a dozen 
bits of trivial geometry.)

Post a reply to this message

> Damn, your graphics card is *drastically* faster than mine... (When I
> pan the image, it comes out yellow for the first half a dozen frames.)

That's because you had to reduce the samples per frame down. That 
variable controls how many samples the GPU averages over for each 
redraw. When you're rotating the scene it continuously redraws from 
scratch so if you've got samples set to 1 it's going to look *very* 
noisy. 40 is about the max I can do (at 1024x512 resolution) and still 
spin around at what looks like 60 fps. Any higher and it starts to 
stutter (even just dragging around other windows start to stutter too!).

Of course once you stop dragging it starts to remember the previous 
frames and average them out.

> I wonder... how long will it be before games look like this in realtime?
> (I'm guessing a while, since this scene contains a piffling half a dozen
> bits of trivial geometry.)

Bear in mind my implementation is about as unoptimised as you could ever 
get, it's just relying on brute force rather than anything clever at 
all. For something far more optimised look at this:

https://www.youtube.com/watch?v=aKqxonOrl4Q
https://www.youtube.com/watch?v=BpT6MkCeP7Y

I'm sure if nVidia designed a path tracing specific GPU today it would 
be plenty fast enough, the trouble is you're trying to shoe-horn some 
algorithm into a chip that was designed for something completely different.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> An unbiased* global illumination ray tracer running in your web browser,
> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
> and checkered spheres. What more do you want!
>
> Just run the attached html on a PC with a fast GPU, you can drag around
> the scene with your pointer. Inside the html file you can change the
> size of the image (right at the end of the file you'll see width and
> height tags), using non-power-of-two values may not work on your
> graphics card.
>
> You can get some pretty cool effects by looking through the glass ball
> into the mirrored ball.
>
> Disclaimer: It works on my machine (Chrome, Win7, nVidia GTX970) but
> I've not tested it on any other machine. Particularly if you have a much
> slower graphics card it may run so slowly that it crashes, or it may not
> run at all. Also make sure you have the latest graphics drivers, no I'm
> not just saying this it often makes a difference. The output should look
> similar to the attached image after a few seconds.
>
> ...
>
> After creating the standalone html5 page for blobs thread above, I
> realised it would allow me to do something shadertoy doesn't - that is,
> reuse results from a previous calculation in the next frame. I already
> had an attempt at a path-tracer in C# (which was in turn translated from
> some C++ code I found somewhere) but it was pretty slow. The main
> sticking point I had was learning how to render to texture using webGL.
> So it renders one "frame" at a time, which actually consists of 10
> samples per pixel, it then averages this with all the previous results.
> It then repeats until you move the viewpoint. The result is that once
> you stop dragging the scene around the noise should disappear eventually.
>
> Your browser will probably limit the speed of updates to 60 frames per
> second, so that equals 600 samples per second. You can increase the
> number of samples per frame on line 39. But I found if you make it too
> high that a single frame takes longer than a second or so the video
> driver crashes.
>
> * One of the hardest bits is to get a random number generator running on
> the GPU that is random enough to not show any patterns after a while.
> There is still some subtle non-randomness visible, but it's way better
> than it was originally. That's why there's random bits of code like
> rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.


I got a "Could not initialize WebGL" message. with a quadro FX3800

Post a reply to this message

> I got a "Could not initialize WebGL" message. with a quadro FX3800

Does WebGL work at all on other sites? Try these:

https://www.chromeexperiments.com/webgl
https://www.shadertoy.com/

Post a reply to this message

> Have you seen this? The accepted answer looks simplish...
>
>
http://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu

Looks promising, I'll save that page and see if I can implement it. It's 
surely going to be better than my trial-and-error bodge.

As highlighted on that page, the main problem is that every single pixel 
runs exactly the same code with the same inputs (apart from pixel 
coordinate). So you need some way of making every pixel generate a bunch 
of random numbers that are in no way related to any other pixels in the 
image (otherwise you get strange patterns like you saw with your 1 
sample image).

Post a reply to this message

On 27/07/2015 11:47, scott wrote:
>> Have you seen this? The accepted answer looks simplish...
>>
>>
http://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu
>>
>
> Looks promising,

Or not. There's a few bits that don't work in WebGL. Specifically there 
is no integer power function, xor operator, bit shifters or unsigned 
ints (only signed ints). Seems like you need the full OpenGL for this...

Post a reply to this message

On 27/07/2015 04:37 PM, scott wrote:
> Or not. There's a few bits that don't work in WebGL. Specifically there
> is no integer power function, xor operator, bit shifters or unsigned
> ints (only signed ints). Seems like you need the full OpenGL for this...

Ouch. Really? Damn...

Post a reply to this message

On 27/07/2015 11:47 AM, scott wrote:
> As highlighted on that page, the main problem is that every single pixel
> runs exactly the same code with the same inputs (apart from pixel
> coordinate). So you need some way of making every pixel generate a bunch
> of random numbers that are in no way related to any other pixels in the
> image (otherwise you get strange patterns like you saw with your 1
> sample image).

I wonder how long before GPU gets a hardware-based randomness source? 
(It can't be that hard to sample a little thermal noise in hardware, 
especially if you don't need cryptographic strength. The problem is 
usually that hardware randomness sources are a tad slow...)

Post a reply to this message

This works out of the box on OS X Yosemite under Google Chrome and it does so
very well indeed. This is a very clever piece of work. Thanks for sharing it
with us.

Post a reply to this message

> This works out of the box on OS X Yosemite under Google Chrome and it does so
> very well indeed. This is a very clever piece of work. Thanks for sharing it
> with us.

Thanks! I can only claim credit though for modifying an existing path 
tracing algorithm to run on a GPU and modifying JS/WebGL boiler-plate 
code from various sources. I'm quite happy that it all runs from a 
single html document though, hopefully it's a good platform for anyone 
to tinker about with.

Post a reply to this message

So do you remember a few years(?) back when 3D Mandelbulbs were all the 
rage? IIRC there were some threads on these very groups about rendering 
them in POV, however it was painfully slow.

Well now you can do it in realtime on a (fast) GPU near you :-)

I need to tidy up the code a bit to make it easier to "fly around" and 
control the detail settings, but here's a quick teaser:

https://www.youtube.com/watch?v=r_Ek3Kfv8KA

Note there's nothing pre-calculated here, the GPU is doing all the work 
on the fly.

Post a reply to this message

Am 27.07.2015 um 19:35 schrieb Orchid Win7 v1:

> I wonder how long before GPU gets a hardware-based randomness source?
> (It can't be that hard to sample a little thermal noise in hardware,

Well, GPUs should at least be able to provide plenty thermal for the 
noise ;)

Post a reply to this message

>> I wonder how long before GPU gets a hardware-based randomness source?
>> (It can't be that hard to sample a little thermal noise in hardware,
>
> Well, GPUs should at least be able to provide plenty thermal for the
> noise ;)

Yes :-)  It's not hard to sample the thermal noise, the problem is how 
to sample it billions of times per second with enough resolution to be 
useful.

Post a reply to this message

On 04/08/2015 09:55 AM, scott wrote:
>>> I wonder how long before GPU gets a hardware-based randomness source?
>>> (It can't be that hard to sample a little thermal noise in hardware,
>>
>> Well, GPUs should at least be able to provide plenty thermal for the
>> noise ;)
>
> Yes :-) It's not hard to sample the thermal noise, the problem is how to
> sample it billions of times per second with enough resolution to be useful.

Well, no, you typically sample it a few times a second and use that to 
seed a normal PRNG.

In other news, Intel added an op-code to generate truly-random numbers 
using exactly this technique. The Linux kernel team added it to 
/dev/random... and then took it out again, because they were apparently 
concerned that the NSA would modify the die of your CPU to make the 
random numbers non-random. (!!)

Jesus, that's next-level. Surely if you don't trust the hardware your OS 
is running on, it's already game over. (?)

Post a reply to this message

>> Yes :-) It's not hard to sample the thermal noise, the problem is how to
>> sample it billions of times per second with enough resolution to be
>> useful.
>
> Well, no, you typically sample it a few times a second and use that to
> seed a normal PRNG.

But will that not cause the same problems seen already today with 
unrandomness? If the pixel shader for every pixel gets exactly the same 
random seed value, and just uses a PRNG to modify it, won't you see 
patterns? I would have thought every pixel needs its own unique random 
seed value every frame to really get rid of those sort of PRNG patterns. 
If you want a *truly* unbiased ray tracer for example.

> In other news, Intel added an op-code to generate truly-random numbers
> using exactly this technique. The Linux kernel team added it to
> /dev/random... and then took it out again, because they were apparently
> concerned that the NSA would modify the die of your CPU to make the
> random numbers non-random. (!!)

Apparently the on-chip thermal noise sampler outputs a stream of bits at 
3 GHz. I don't know how big the hardware is for that circuit, but it's 
not *that* far away from what you'd need to get a true random number for 
every pixel processed on the GPU.

> Jesus, that's next-level. Surely if you don't trust the hardware your OS
> is running on, it's already game over. (?)

Yes, something like a true RNG in every home home PC seems like 
something the NSA would be extremely interested in.

Post a reply to this message

On 05/08/2015 09:24 AM, scott wrote:
>>> Yes :-) It's not hard to sample the thermal noise, the problem is how to
>>> sample it billions of times per second with enough resolution to be
>>> useful.
>>
>> Well, no, you typically sample it a few times a second and use that to
>> seed a normal PRNG.
>
> But will that not cause the same problems seen already today with
> unrandomness? If the pixel shader for every pixel gets exactly the same
> random seed value, and just uses a PRNG to modify it, won't you see
> patterns?

My plan was more to have some hardware that seeds a PRNG with a 
truly-random seed and then distributes a *different* random iterate from 
the PRNG to each thread in the bunch. It's awkward to code in software, 
but shouldn't be that hard in hardware...

> Apparently the on-chip thermal noise sampler outputs a stream of bits at
> 3 GHz. I don't know how big the hardware is for that circuit, but it's
> not *that* far away from what you'd need to get a true random number for
> every pixel processed on the GPU.

OK.

>> Jesus, that's next-level. Surely if you don't trust the hardware your OS
>> is running on, it's already game over. (?)
>
> Yes, something like a true RNG in every home home PC seems like
> something the NSA would be extremely interested in.

It's slightly mental that the government of one country can insert spy 
hardware into every computer that can ever exist... Especially given 
that all silicon fabrication is done in countries hostile to America... 
But hey, what do I know?

Post a reply to this message

> It's slightly mental that the government of one country can insert spy
> hardware into every computer that can ever exist... Especially given
> that all silicon fabrication is done in countries hostile to America...
> But hey, what do I know?

Oh don't worry, I'm sure if the NSA were capable of inserting spy 
hardware into CPU dies, the fab itself would be more than capable of 
changing it back to something more to their (or their government's) 
liking :-)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > I got a "Could not initialize WebGL" message. with a quadro FX3800
>
> Does WebGL work at all on other sites? Try these:
>
> https://www.chromeexperiments.com/webgl
> https://www.shadertoy.com/

no. it doesn't. too bad.

Post a reply to this message

Am 06.08.2015 um 09:20 schrieb scott:
>> It's slightly mental that the government of one country can insert spy
>> hardware into every computer that can ever exist... Especially given
>> that all silicon fabrication is done in countries hostile to America...
>> But hey, what do I know?
>
> Oh don't worry, I'm sure if the NSA were capable of inserting spy
> hardware into CPU dies, the fab itself would be more than capable of
> changing it back to something more to their (or their government's)
> liking :-)

That's what I was thinking. Yes, absolutely, totally. They'd sure know 
exactly what features to look out for in a set of lithography masks...

Post a reply to this message

>> Oh don't worry, I'm sure if the NSA were capable of inserting spy
>> hardware into CPU dies, the fab itself would be more than capable of
>> changing it back to something more to their (or their government's)
>> liking :-)
>
> That's what I was thinking. Yes, absolutely, totally. They'd sure know
> exactly what features to look out for in a set of lithography masks...

Only if they were "run" by the government - then I'm sure a team of 
100's to reverse engineer and "fix" the "problem" would be easily 
available for the job...

Post a reply to this message