[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Volume Textures



It's going to be dominated by the time for those two texture fetches -
the performance of which will depend sensitively on the caching strategy
of the underlying hardware.   When the polygon slices down through the
third dimension, the cache will have a very hard time doing any good -
so you'll be completely limited by the speed of texture RAM fetching. 
When the polygon cuts the volume close to the X/Y plane, it's going to
be fast.

It's doubtful that there is much hardware out there that has special
caching strategies for true 3D textures - so I'd bet you'd have a hard
time spotting any kind of performance difference at all.

If you can pack your 3D texture into a single row of 2D maps instead of
a 16x16 grid, you can do better...but it has to be a pretty tiny map for
that to work out.

  -- Steve


On 03/26/2011 08:07 PM, John Davis wrote:
> How does this bench against hardware trilinear?
>
> On Fri, Mar 25, 2011 at 7:06 AM, Thatcher Ulrich <tu@tulrich.com
> <mailto:tu@tulrich.com>> wrote:
>
>     John -- the code to do a trilinear sample is pretty short.  I'm
>     wondering if you could test this to see if it works for you.  I just
>     typed this up and compiled it, but didn't test it, so no guarantees:
>
>     // Tex is a "simulated" 3D 256x256x256 texture -- a 4096x4096 2D
>     // texture, made up of 256x256 tiles, arranged in a 16x16 pattern.
>     // The tiles are z-slices, minimum z in lower left, increasing
>     // left-to-right and bottom-to-top.
>     vec4 texture3D(sampler2D tex, vec3 xyz) {
>      // Find the two adjacent z slices, take a 2D sample from each, and
>      // blend them together.
>
>      vec3 xyz_256 = xyz * 256.0;
>      float z = xyz_256.z;
>      // TODO: z0,z1 could be put in a vec2; then floor() and mod()
>      // below could be vectorized.
>      float z0 = floor(z);
>      float z1 = z0 + 1.0;
>      float zblend = z - z0;
>
>      // Choose the tiles.
>      vec2 offset0 = vec2(floor(z0 / 16.0), mod(z0, 16.0)) * 256.0;
>      vec2 offset1 = vec2(floor(z1 / 16.0), mod(z1, 16.0)) * 256.0;
>
>      // Sample the tiles.
>      vec4 s0 = texture2D(tex, (offset0 + xyz_256.xy) / 4096.0);
>      vec4 s1 = texture2D(tex, (offset1 + xyz_256.xy) / 4096.0);
>
>      return mix(s0, s1, zblend);
>     }
>
>     -T
>
>     On Fri, Mar 25, 2011 at 11:20 AM, John Davis
>     <jdavis@pcprogramming.com <mailto:jdavis@pcprogramming.com>> wrote:
>     > Wait how long?  Can't we at least start the Angle work?  I'm
>     guessing the
>     > changes will take a few months, and then there will be testing.
>     >
>     > On Thu, Mar 24, 2011 at 11:12 PM, Mo, Zhenyao <zhenyao@gmail.com
>     <mailto:zhenyao@gmail.com>> wrote:
>     >>
>     >> On Thu, Mar 24, 2011 at 7:42 PM, Benoit Jacob
>     <bjacob@mozilla.com <mailto:bjacob@mozilla.com>> wrote:
>     >> >
>     >> >
>     >> >
>     >> > ----- Original Message -----
>     >> >> On Mar 24, 2011, at 4:18 AM, John Davis wrote:
>     >> >>
>     >> >> > In the meantime, is there any chance we could add an
>     extension to
>     >> >> > WebGL and Angle to support volume textures for the rather
>     large use
>     >> >> > case of Chrome and FireFox? This is very low hanging fruit
>     that will
>     >> >> > add considerable bang on the fragment shader side.
>     >> >>
>     >> >> Let's be careful about what we call "low hanging fruit". WebGL
>     >> >> attempts to allow content to be written across a wide range of
>     >> >> hardware. That's why we based the spec on OpenGL ES 2.0
>     rather than
>     >> >> desktop OpenGL. If you look at the WebGL extension registry
>     >> >> (http://www.khronos.org/registry/webgl/extensions/), all of the
>     >> >> extensions there are available on at least one OpenGL ES
>     >> >> implementation on mobile devices (iPhone).
>     >> >>
>     >> >> That doesn't mean we can't discuss other extensions (like
>     this one).
>     >> >> But I would be very against adding any and all extensions
>     just because
>     >> >> they exist on some driver in some version of OpenGL on some
>     platform.
>     >> >> I even agree that 3D textures are available in a majority of
>     desktop
>     >> >> OpenGL implementations. And GL_OES_texture_3D is defined for
>     OpenGL
>     >> >> ES. But I don't know of any current implementations of
>     OpenGL ES that
>     >> >> support it.
>     >> >>
>     >> >> My concern is that WebGL will get fragmented and that
>     authors will
>     >> >> start using extensions that are available on a small number of
>     >> >> implementations degrading the WebGL experience for everyone
>     else. I
>     >> >> don't think we want to go there at this early stage of
>     development.
>     >> >
>     >> > For what it's worth, I am agreeing with Chris on this matter.
>     >> >
>     >> > To put it in more abstract terms: being a web specification,
>     WebGL
>     >> > should (try hard to) be universally implementable.
>     >> >
>     >> > Benoit
>     >>
>     >> Web is never universal.  For example, many Korean website build
>     around
>     >> ActiveX, and it's only for Windows/IE users.  Also, we all know
>     if a
>     >> web is built in Flash, certain devices won't display it.
>     >>
>     >> Again, I think we should wait, but at certain point when webgl
>     is well
>     >> known and well perceived, adding kicking ass but none-universal
>     >> extensions should be on the agenda.  Otherwise we are limiting
>     >> possibilities and holding back potential business/markets.
>     >>
>     >> > -----------------------------------------------------------
>     >> > You are currently subscribed to public_webgl@khronos.org
>     <mailto:public_webgl@khronos.org>.
>     >> > To unsubscribe, send an email to majordomo@khronos.org
>     <mailto:majordomo@khronos.org> with
>     >> > the following command in the body of your email:
>     >> > unsubscribe public_webgl
>     >> > -----------------------------------------------------------
>     >> >
>     >> >
>     >>
>     >
>     >
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------