Re: Realtime raytracing in webgl

[m.dewa...@atmind.nl]

Hi Tim,

Thanx for your reply.
We tried limiting the for loops, but it seems that the shader is still to complex. A raytracer does have many loops ;)
We seperated the shader in multiple shaders, but that didn't seem to help much. Well Firefox did perform slightly better, but Google Chrome still had the problem of loosing its GL-context.

We'll try Chrome with the --use-gl=desktop and see if that helps...

Thx,
Rgds,
Monique


On Tuesday, April 23, 2013 1:29:28 AM UTC+2, nobbis wrote:

I've written a (sparse voxel octree) raytracer for WebGL and see the same problem in Windows.

I believe the problem is my for loops are being unrolled by the HLSL compiler.  As I increase the number of steps, the compile time increases until at some point the context is lost (after ~10s of compilation.)

I'd reduce your number_of_steps constant and see if that helps.  Also, run Chrome with the --use-gl=desktop argument to check that it's the translation to HLSL causing the problem.  To see the HLSL output, build ANGLE and run the essl_to_hlsl command-line tool.

I imagine ANGLE using DirectX 11 will fix this.

Tim

On Friday, April 19, 2013 9:45:01 AM UTC-7, m.dewa...@atmind.nl wrote:

Hi all,

We are experimenting with webgl and shaders, and tried implementing a realtime raytracer using WebGL and shaders. The raytracing is done in the fragment shader.

On Linux, Android (tablet) and the MacOS things work okay using Google Chrome and FireFox.
But on the Windows platform we are facing issues with Google Chrome and also some (but less) with Firefox.

Compiling the raytracer in one fragment shaders works for Chrome and Firefox on Linux and MacOs, but it doesn't for Windows. We have split the shader into several smaller shaders and that seems to compile okay in Firefox on Windows, but still fails in Chrome.
It seems that the gl_context is lost (null).
You can find the experiment here, but keep in mind that it doesn't work properly on Windows:
http://www.atmind.nl/webgl/marchingpath.html

Does anyone have any idea what goes wrong here?
And does any one know how we can view the Angle -generated code for Firefox?

Thanx in advance.
Rgds,
Jeroen & Monique
(At Mind)

[m.dewa...@atmind.nl]

BTW it works with the --use-gl=desktop option

Wondering why Google & Firefox choose to use ANGLE instead of OpenGL on Windows?

Rgds,
Monique

[Kenneth Russell]

The decision to use Direct3D instead of OpenGL on Windows for Chrome
was made a few years ago, and at the time, some vendors' OpenGL
drivers were actually less capable than the Direct3D drivers -- for
example, not supporting GLSL shaders at all. It was also the case (I'm
not sure how true this is today) that some OEMs were shipping machines
without functioning OpenGL drivers. We hope that the ecosystem will
change and that OpenGL will become more pervasive on Windows, but the
ANGLE translation path will basically always be required. In Chrome,
to simplify the code paths, this means that the default will continue
to be to use ANGLE.

Shader compilation issues on Windows are still being investigated.
There have been some problems in the style of code generated by
ANGLE's GLSL ES -> HLSL translation path which we believe have been
solved, but there are definitely also issues in Microsoft's HLSL
shader compiler. If you have small shaders which demonstrate
pathological situations please file a bug either on the ANGLE issue
tracker at https://code.google.com/p/angleproject/issues/list or on
the Chromium issue tracker at http://crbug.com/ , and include a
complete, self-contained WebGL example. Again, please simplify the
shader as much as possible.

-Ken

> --
> You received this message because you are subscribed to the Google Groups
> "WebGL Dev List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to webgl-dev-lis...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jeroen Bakker]

Hi Ken,

Thanks for the insight. We will try to isolate the issue and report it.
It seems that a raytracer is a bit too much :) .

Best regards,
Jeroen & Monique

[Michel Braz de Morais]

hello, I'm starting on WebGL found interesting discussion.
It's good to be aware of this little things.
Any changes please do not stop posting.

att,

Michel Braz de Morais

Analista / Desenvolvedor de sistemas

2013/4/23 Jeroen Bakker <j.ba...@atmind.nl>

email to webgl-dev-list+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-list+unsubscribe@googlegroups.com.

[Jeroen Bakker]

Hi Kenneth,

We tried to isolate the issue, doing many things, but eventually came to
the conclusion that limiting the number of loops made it stable and
correct on Windows platform. Too bad as with more iterations the
resulting image looks a lot better.

Best regards,
Jeroen & Monique

- At Mind -

On 04/23/2013 07:38 PM, Kenneth Russell wrote:

[m.dewa...@atmind.nl]

A small add-on,  splitting up the complexity (for loops) in multiple shaders seems to make quite a big difference . i.e. having the reflections and AO pass in different shaders does imrpove the performance on the Windows platform....

Rgds,
Monique

[m.dewa...@atmind.nl]

BTW, if anyone is interested, we have written a small article about a few challenges we had when developing the raytracer:
http://www.atmind.nl/?p=623

[Mark Callow]

On 2013/05/24 22:38, m.dewa...@atmind.nl wrote:

On Friday, May 24, 2013 3:25:28 PM UTC+2, m.dewa...@atmind.nl wrote:

A small add-on,  splitting up the complexity (for loops) in multiple shaders seems to make quite a big difference . i.e. having the reflections and AO pass in different shaders does imrpove the performance on the Windows platform....

I didn't notice any difference in startup time for this version between MacOS and Windows. Looks like your change succeeded.

There is one nasty artefact in Firefox on Windows XP. I haven't tested on Windows 7.  That is tearing. It seems that either the page composition is happening while the WebGL app is still drawing the canvas or the page->screen updates are not happening in sync with screen refresh. I think it is a Firefox problem on Windows. I vaguely recall reporting it a long time ago. It doesn't occur in Firefox on MacOS.

I showed the demo to a colleague who is working on ray-tracing. His first question was why is there a "depth pass? You don't do depth buffering in ray tracing." I was hoping your blog might explain something about how you have implemented this but it was exclusively about WebGL shader issues. Have you written up an explanation somewhere else?

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

[Benoit Jacob]

2013/5/26 Mark Callow <callo...@artspark.co.jp>

On 2013/05/24 22:38, m.dewa...@atmind.nl wrote:

On Friday, May 24, 2013 3:25:28 PM UTC+2, m.dewa...@atmind.nl wrote:

A small add-on,  splitting up the complexity (for loops) in multiple shaders seems to make quite a big difference . i.e. having the reflections and AO pass in different shaders does imrpove the performance on the Windows platform....

I didn't notice any difference in startup time for this version between MacOS and Windows. Looks like your change succeeded.

There is one nasty artefact in Firefox on Windows XP. I haven't tested on Windows 7.  That is tearing. It seems that either the page composition is happening while the WebGL app is still drawing the canvas or the page->screen updates are not happening in sync with screen refresh.

Has to be the latter (compositing not on vsync). Check if you are getting Direct3D compositing (in about:support) and if not,  check if force-enabling it (layers.acceleration.force-enabled in about:config, restart) makes a difference.

Benoit

I think it is a Firefox problem on Windows. I vaguely recall reporting it a long time ago. It doesn't occur in Firefox on MacOS.

I showed the demo to a colleague who is working on ray-tracing. His first question was why is there a "depth pass? You don't do depth buffering in ray tracing." I was hoping your blog might explain something about how you have implemented this but it was exclusively about WebGL shader issues. Have you written up an explanation somewhere else?

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

--

[Mark Callow]

On 2013/05/27 20:10, Benoit Jacob wrote:

2013/5/26 Mark Callow <callo...@artspark.co.jp>

There is one nasty artefact in Firefox on Windows XP. I haven't tested on Windows 7.  That is tearing. It seems that either the page composition is happening while the WebGL app is still drawing the canvas or the page->screen updates are not happening in sync with screen refresh.

Has to be the latter (compositing not on vsync). Check if you are getting Direct3D compositing (in about:support) and if not,  check if force-enabling it (layers.acceleration.force-enabled in about:config, restart) makes a difference.

Hi Benoit,

Force-enabling D3D compositing made no difference (or do I need to restart FF?)

As for whether I am getting it without force-enable, there seems no way to easily tell. All the layers.* config items are at their default settings. I don't see anything directly relevant in about:support except perhaps "GPU Accelerated Windows" which says "1/1 Direct3D 9".

[Jeroen Bakker]

Hi Mark,

About the depth pass. You are correct in the example we do not make use of the depth pass. Normally a ray-tracer outputs all kind of data to a compositor and the compositor combines these passes and outputs the final color. During this compositor process the depth-pass can be used for example to render depth clouds or mist.

In OpenGL terms it is closer to deferred render technique where a lot of data is calculated and stored in G-Buffers and sometimes a buffer is not used or does not influence the final color but is still calculated.

Also the depth-pass is almost free as we do use the world position pass. Hmm.. just saw that there is also an error in the depth pass as it does not calculates the camera depth, but the world depth. Will fix this soon.

We hope this clarifies it a bit, but you are right that the pass is not used during the compositing process in our example. If you have more questions, please ask them!

Regards,

Jeroen & Monique
 - At Mind -

[Benoit Jacob]

2013/5/27 Mark Callow <callo...@artspark.co.jp>

On 2013/05/27 20:10, Benoit Jacob wrote:

2013/5/26 Mark Callow <callo...@artspark.co.jp>

There is one nasty artefact in Firefox on Windows XP. I haven't tested on Windows 7.  That is tearing. It seems that either the page composition is happening while the WebGL app is still drawing the canvas or the page->screen updates are not happening in sync with screen refresh.

Has to be the latter (compositing not on vsync). Check if you are getting Direct3D compositing (in about:support) and if not,  check if force-enabling it (layers.acceleration.force-enabled in about:config, restart) makes a difference.

Hi Benoit,

Force-enabling D3D compositing made no difference (or do I need to restart FF?) 

Yes, you would need to (as I tried to express in my email ;-) ). However, see below, you are already getting D3D compositing.

 

As for whether I am getting it without force-enable, there seems no way to easily tell. All the layers.* config items are at their default settings. I don't see anything directly relevant in about:support except perhaps "GPU Accelerated Windows" which says "1/1 Direct3D 9".

OK, that means that your one window is D3D composited. Never mind my idea, then.

This is well worth filing a bug and CC'ing Jeff and Vlad.

Benoit

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

--

[Mark Callow]

On 2013/05/28 20:44, Benoit Jacob wrote:

This is well worth filing a bug and CC'ing Jeff and Vlad.

I added the information to my existing old bug report about this problem. - Bug 646383. I also cc'ed Vlad. You and Jeff are already in the cc list.

[Thomas Kjeldsen]

On Friday, May 24, 2013 3:38:12 PM UTC+2, m.dewa...@atmind.nl wrote:

BTW, if anyone is interested, we have written a small article about a few challenges we had when developing the raytracer:
http://www.atmind.nl/?p=623

Hi Monique,

I recently presented a talk about some of the challenges that we encountered when we implemented a pathtracer in WebGL.

If you are interested, you can find my slides here

http://cg.alexandra.dk/2013/06/10/webgl-raytracing-presented-at-visionday/

and some more detail in this blogpost

http://cg.alexandra.dk/2012/12/21/glsl-and-webgl-pathtracing-benchmark/

Regards

Thomas

[m.dewa...@atmind.nl]

Hi Thomas,

This is very impressive! Thank you for sharing your slides.
In Blender we also ran into similar kinds of issues (BVH, compiling) when implementing Cycles, a pathtracer, on the GPU (so not WebGL). It sounds familiar.

Kind regards,
Monique & Jeroen

[nobbis]

Chrome 30 uses the latest ANGLE with support for a DirectX 11 renderer.  Try your raytracer with Chrome Canary and it should work without resorting to --use-gl=desktop.

Tim