paracomp-spec Mailing List for Parallel Compositing Library
Brought to you by:
shreekumar
Menu
▾
▴
paracomp-spec — Discussions related to the API Specification happen here
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Balázs T. <tb...@gm...> - 2008-07-09 10:10:46
|
On Fri, May 30, 2008 at 11:53:03AM +0530, Shree Kumar wrote: > Hi Randy, > > Randall Frank wrote: > > Hello, > > I have to ask why not 16bit ints, perhaps in W space? > > That's a good idea too. 16 bit unsigned ints would be good > enough for alpha blending. Using 16 bits for just the W component > seems like an improvement over using 16 bits for all components > - but I'm not sure how this will affect the readback speed > from the GPU. > > I'm keen to hear what folks from TU Budapest think about this. We think, that we'll have trouble with the readback, as there is no pixel format like A16R8G8G8 or similar. So we have to read back the RGB and the A channels separately and combine them together somehow. > 16 bit int/unsigned int could be a separate extension too. The R16 int/uint format looks to be a good idea, as well as the R16F. Balazs |
|
From: Balázs T. <tb...@gm...> - 2008-07-09 09:18:41
|
----- Forwarded message from =?ISO-8859-1?Q?Cs=E9bfalvi_Bal=E1zs_ <cs...@ii...>, ?= ----- From: Csébfalvi Balázs <cs...@ii...> Date: Mon, 7 Jul 2008 16:54:46 +0200 Subject: RE: [Fwd: Re: [Paracomp-spec] RFC : Extension EXT_datatype_float - floating point datatypes for compositing] Hi Shree, I think using 16 bits for just the W component would be appropriate especially for applications requiring front-to-back compositing, but the lack of precision in the color channels would still lead to some accumulated error. The integer format might also be advantageous if the compositing operator is not necessarily the classical alpha-blending. For example, there are applications, where only the geometrical primitives projected onto a given pixel have to be counted, or the unique integer ID of the closest primitive has to be obtained in the given pixel in order to reference it in a subsequent pass. Regards, Balazs ----- End forwarded message ----- |
|
From: Shree K. <shr...@hp...> - 2008-05-30 06:23:12
|
Hi Randy, Randall Frank wrote: > Hello, > I have to ask why not 16bit ints, perhaps in W space? That's a good idea too. 16 bit unsigned ints would be good enough for alpha blending. Using 16 bits for just the W component seems like an improvement over using 16 bits for all components - but I'm not sure how this will affect the readback speed from the GPU. I'm keen to hear what folks from TU Budapest think about this. 16 bit int/unsigned int could be a separate extension too. > The 16bit float is necessary, I agree, but expensive to > implement while the int form is relatively cheap. I know > HDR folks may not like the linear space, but for extended > blending, it works pretty well and is fast. Are you already using 16 bit ints ? With the hardware coming out, the 16 bit floats could be fast too - but with GPUs compositing the images. I don't have anything to prove this though. Thanks -- Shree > > Shree Kumar wrote: >> Motivation : >> >> Paracomp currently has support for only 8 bit unsigned color components. >> This is not enough in many cases where better precision is needed. >> Floating point data types are increasingly being used in rendering >> algorithms. So it is useful to extend the API to support higher >> precision floating point data types. >> >> Floating point values with 16 bit & 32 bit precision are supported on >> GPUs. 16 bit values supports a lower range of values, but are adequate >> for a good number of applications. They take lesser bandwidth and >> storage space, and could offer higher performance for the applications >> which don't need the extra precision. >> >> Rough extension description : >> >> These new values will be supported by PC_PIXEL_FORMAT: >> 1. PC_PF_RGBA32F_EXT - 4 component RGBA, with each being a single >> precision value (following the IEEE 754 standard) >> 2. PC_PF_RGB32F_EXT - 3 component RGB, with each being a single >> precision value (following the IEEE 754 standard) >> 3. PC_PF_RGBA16F_EXT - 4 component RGBA, with each a half precision >> floating point value. The floating point format is the same as for the >> OpenGL extension ARB_half_float_pixel. This floating-point format is >> very similar to the IEEE single-precision floating-point standard, >> except that it has only 5 exponent bits and 10 mantissa bits. >> 4. PC_PF_RGB16F_EXT - 3 RGBA, each being a half precision floating >> point value. >> >> RGBA values will be valid for both DEPTH & ALPHA_SORT compositing. (It >> will also be valid for the ADD operator, once that is included as an >> extension) >> >> RGB values will be valid for DEPTH compositing, but not for ALPA_SORT. >> It may also make sense to support RGB values for the ADD operator with >> PC_ALPHA_BEHAVIOUR set to PC_ALPHA_SEPARATE. Please refer to the >> extension proposal for ADD operator in a separate email. >> >> Questions/Comments are welcome. 32 bit floating point values are >> proposed by Technical University of Budapest. The 16 bit floating point >> values are included by me. >> >> Note : >> >> An implementation of these pixel formats is already available for trying >> out at : >> >> http://paracomp.svn.sourceforge.net/viewvc/paracomp/branches/developer/shree/feature/composite_float/ >> >> samples/intermediate/multithreaded.cpp demonstrates using these >> datatypes on a single node. >> >> It uses the Half class from the OpenEXR software distribution >> (www.openexr.com) to composite 16 bit floating point values. These >> values are not native types on the CPU, so compositing is quite slow. >> Compositing on the GPU seems to be a better bet in this case. >> >> For 32 bit floating point, CPU compositing is used. No optimization has >> been done, so expect things to be slow in this case too. >> >> Regards >> -- Shree >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Paracomp-spec mailing list >> Par...@li... >> https://lists.sourceforge.net/lists/listinfo/paracomp-spec >> > > -- > rjf. > > ------------------------------------------------------------- > | Quando omni flunkus moritati | > | Randall Frank ran...@co... | > ------------------------------------------------------------- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Paracomp-spec mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/paracomp-spec > . > |
|
From: Randall F. <ran...@co...> - 2008-05-29 23:56:47
|
Hello,
I understand the desire for this, and I think it should
be added as an extension, but it raises the question of a more
general mechanism for this (e.g. programmable operations). The
concern being that as this type of stuff evolved with gfx hw,
it may become obsolete faster here. This can be easily
implemented in CUDA in a more general form outside of the
rendering facility. I'll have to dig up the old PICA spec,
which allowed conceptual, multi-stage compositing that was
run-time compiled into flat operations. It could also be used
to implement these type of extensions as well and perhaps
extend better into programmable HW.
Thanks.
I need to write up the CEI extension sometime and send
it out for folks to look at.
Shree Kumar wrote:
> I'm proposing this extension on behalf of the Technical University of
> Budapest. Their proposal has three parts - an ADD operator, plus
> floating point and intensity datatypes. So I'm splitting their proposal
> into three parts.
>
> Motivation:
>
> Paracomp currently supports two compositing modes - PC_COMP_DEPTH &
> PC_COMP_ALPHA_SORT.
>
> PC_COMP_ALPHA_SORT offers just a single blending mode from the 9x9=81
> modes offered by OpenGL. Other blending modes also have importance in
> particular algorithms. For example, if the material at sample points
> have significant emission and are almost transparent (e.g. fire,
> emission nebulae, astrophysics simulations, etc.), then the contribution
> of sample points can be simply added without any previous depth sort.
> Note that the elimination of the previous depth sort is a significant
> advantage since it can simplify and speed up the implementation
> considerably. Such operation, called accumulation, would be specified by
> glBlendFunc(GL_ONE, GL_ONE) in OpenGL, and could be described by the
> following equation:
>
> (R,G,B,A) = (R1+R2, G1+G2, B1+B2, A2+A2)
>
> Rough Extension Proposal:
>
> Extend the API to include the ADD operation as follows:
>
> 1. pcContextCreateMaster accepts a new value for PC_COMPOSITE_TYPE -
> PC_COMP_ADD_EXT. The accumulation is order independent.
>
> 2. Add a new context property, PC_ALPHA_BEHAVIOUR. This property
> affects the add operator. This property can take two values
>
> a. PC_ALPHA_SEPARATE: Implements glBlendFunc(GL_ONE, GL_ONE).
>
> (Rs, Gs, Bs, As)+(Rd, Gd, Bd, Ad)=(Rs+Rd, Gs+Gd, Bs+Bd, As+Ad)
>
> Where + means saturated addition. This is useful when
> accumulation has to be performed for separate scalar values.
>
> b. PC_ALPHA_PREMULTIPLED: Color values are multiplied by alpha
> value before the compositing operation.
>
> (Rs, Gs, Bs, As)+(Rd, Gd, Bd, Ad)=(As*Rs+Ad*Rd, As*Gs+Ad*Gd,
> As*Bs+Ad*Bd, As*As+Ad*Ad)
>
> Where + means saturated addition. This is useful when more
> complicated compositing model is used with multiple compositing
> contexts. For example an alpha blending context takes the
> output of an intensity accumulation context as its input, or
> vice versa.
>
> 3. pcFrameBegin ignores the "order" parameter if COMPOSITE_TYPE is
> COMP_ADD_EXT, since the operation is order independent.
>
> Comments/questions welcome.
>
> Thanks in advance
> -- Shree
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Paracomp-spec mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-spec
>
--
rjf.
-------------------------------------------------------------
| Quando omni flunkus moritati |
| Randall Frank ran...@co... |
-------------------------------------------------------------
|
|
From: Randall F. <ran...@co...> - 2008-05-29 23:50:06
|
Hello, I have to ask why not 16bit ints, perhaps in W space? The 16bit float is necessary, I agree, but expensive to implement while the int form is relatively cheap. I know HDR folks may not like the linear space, but for extended blending, it works pretty well and is fast. Thanks. Shree Kumar wrote: > Motivation : > > Paracomp currently has support for only 8 bit unsigned color components. > This is not enough in many cases where better precision is needed. > Floating point data types are increasingly being used in rendering > algorithms. So it is useful to extend the API to support higher > precision floating point data types. > > Floating point values with 16 bit & 32 bit precision are supported on > GPUs. 16 bit values supports a lower range of values, but are adequate > for a good number of applications. They take lesser bandwidth and > storage space, and could offer higher performance for the applications > which don't need the extra precision. > > Rough extension description : > > These new values will be supported by PC_PIXEL_FORMAT: > 1. PC_PF_RGBA32F_EXT - 4 component RGBA, with each being a single > precision value (following the IEEE 754 standard) > 2. PC_PF_RGB32F_EXT - 3 component RGB, with each being a single > precision value (following the IEEE 754 standard) > 3. PC_PF_RGBA16F_EXT - 4 component RGBA, with each a half precision > floating point value. The floating point format is the same as for the > OpenGL extension ARB_half_float_pixel. This floating-point format is > very similar to the IEEE single-precision floating-point standard, > except that it has only 5 exponent bits and 10 mantissa bits. > 4. PC_PF_RGB16F_EXT - 3 RGBA, each being a half precision floating > point value. > > RGBA values will be valid for both DEPTH & ALPHA_SORT compositing. (It > will also be valid for the ADD operator, once that is included as an > extension) > > RGB values will be valid for DEPTH compositing, but not for ALPA_SORT. > It may also make sense to support RGB values for the ADD operator with > PC_ALPHA_BEHAVIOUR set to PC_ALPHA_SEPARATE. Please refer to the > extension proposal for ADD operator in a separate email. > > Questions/Comments are welcome. 32 bit floating point values are > proposed by Technical University of Budapest. The 16 bit floating point > values are included by me. > > Note : > > An implementation of these pixel formats is already available for trying > out at : > > http://paracomp.svn.sourceforge.net/viewvc/paracomp/branches/developer/shree/feature/composite_float/ > > samples/intermediate/multithreaded.cpp demonstrates using these > datatypes on a single node. > > It uses the Half class from the OpenEXR software distribution > (www.openexr.com) to composite 16 bit floating point values. These > values are not native types on the CPU, so compositing is quite slow. > Compositing on the GPU seems to be a better bet in this case. > > For 32 bit floating point, CPU compositing is used. No optimization has > been done, so expect things to be slow in this case too. > > Regards > -- Shree > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Paracomp-spec mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/paracomp-spec > -- rjf. ------------------------------------------------------------- | Quando omni flunkus moritati | | Randall Frank ran...@co... | ------------------------------------------------------------- |
|
From: Shree K. <shr...@hp...> - 2008-05-29 07:06:48
|
Motivation : Paracomp currently has support for only 8 bit unsigned color components. This is not enough in many cases where better precision is needed. Floating point data types are increasingly being used in rendering algorithms. So it is useful to extend the API to support higher precision floating point data types. Floating point values with 16 bit & 32 bit precision are supported on GPUs. 16 bit values supports a lower range of values, but are adequate for a good number of applications. They take lesser bandwidth and storage space, and could offer higher performance for the applications which don't need the extra precision. Rough extension description : These new values will be supported by PC_PIXEL_FORMAT: 1. PC_PF_RGBA32F_EXT - 4 component RGBA, with each being a single precision value (following the IEEE 754 standard) 2. PC_PF_RGB32F_EXT - 3 component RGB, with each being a single precision value (following the IEEE 754 standard) 3. PC_PF_RGBA16F_EXT - 4 component RGBA, with each a half precision floating point value. The floating point format is the same as for the OpenGL extension ARB_half_float_pixel. This floating-point format is very similar to the IEEE single-precision floating-point standard, except that it has only 5 exponent bits and 10 mantissa bits. 4. PC_PF_RGB16F_EXT - 3 RGBA, each being a half precision floating point value. RGBA values will be valid for both DEPTH & ALPHA_SORT compositing. (It will also be valid for the ADD operator, once that is included as an extension) RGB values will be valid for DEPTH compositing, but not for ALPA_SORT. It may also make sense to support RGB values for the ADD operator with PC_ALPHA_BEHAVIOUR set to PC_ALPHA_SEPARATE. Please refer to the extension proposal for ADD operator in a separate email. Questions/Comments are welcome. 32 bit floating point values are proposed by Technical University of Budapest. The 16 bit floating point values are included by me. Note : An implementation of these pixel formats is already available for trying out at : http://paracomp.svn.sourceforge.net/viewvc/paracomp/branches/developer/shree/feature/composite_float/ samples/intermediate/multithreaded.cpp demonstrates using these datatypes on a single node. It uses the Half class from the OpenEXR software distribution (www.openexr.com) to composite 16 bit floating point values. These values are not native types on the CPU, so compositing is quite slow. Compositing on the GPU seems to be a better bet in this case. For 32 bit floating point, CPU compositing is used. No optimization has been done, so expect things to be slow in this case too. Regards -- Shree |
|
From: Shree K. <shr...@hp...> - 2008-05-29 06:10:54
|
I'm proposing this extension on behalf of the Technical University of
Budapest. Their proposal has three parts - an ADD operator, plus
floating point and intensity datatypes. So I'm splitting their proposal
into three parts.
Motivation:
Paracomp currently supports two compositing modes - PC_COMP_DEPTH &
PC_COMP_ALPHA_SORT.
PC_COMP_ALPHA_SORT offers just a single blending mode from the 9x9=81
modes offered by OpenGL. Other blending modes also have importance in
particular algorithms. For example, if the material at sample points
have significant emission and are almost transparent (e.g. fire,
emission nebulae, astrophysics simulations, etc.), then the contribution
of sample points can be simply added without any previous depth sort.
Note that the elimination of the previous depth sort is a significant
advantage since it can simplify and speed up the implementation
considerably. Such operation, called accumulation, would be specified by
glBlendFunc(GL_ONE, GL_ONE) in OpenGL, and could be described by the
following equation:
(R,G,B,A) = (R1+R2, G1+G2, B1+B2, A2+A2)
Rough Extension Proposal:
Extend the API to include the ADD operation as follows:
1. pcContextCreateMaster accepts a new value for PC_COMPOSITE_TYPE -
PC_COMP_ADD_EXT. The accumulation is order independent.
2. Add a new context property, PC_ALPHA_BEHAVIOUR. This property
affects the add operator. This property can take two values
a. PC_ALPHA_SEPARATE: Implements glBlendFunc(GL_ONE, GL_ONE).
(Rs, Gs, Bs, As)+(Rd, Gd, Bd, Ad)=(Rs+Rd, Gs+Gd, Bs+Bd, As+Ad)
Where + means saturated addition. This is useful when
accumulation has to be performed for separate scalar values.
b. PC_ALPHA_PREMULTIPLED: Color values are multiplied by alpha
value before the compositing operation.
(Rs, Gs, Bs, As)+(Rd, Gd, Bd, Ad)=(As*Rs+Ad*Rd, As*Gs+Ad*Gd,
As*Bs+Ad*Bd, As*As+Ad*Ad)
Where + means saturated addition. This is useful when more
complicated compositing model is used with multiple compositing
contexts. For example an alpha blending context takes the
output of an intensity accumulation context as its input, or
vice versa.
3. pcFrameBegin ignores the "order" parameter if COMPOSITE_TYPE is
COMP_ADD_EXT, since the operation is order independent.
Comments/questions welcome.
Thanks in advance
-- Shree
|
|
From: Shree K. <shr...@hp...> - 2008-05-29 05:17:14
|
Hi,
A quick intro before we get involved in discussing extensions & changes
to Paracomp.
This list exists to discuss & evolve the Paracomp API. Changes to
Paracomp are possible
in two ways (in some ways this mirrors OpenGL)
a. Extensions
b. Changes to the core API
These changes (I think), will be done by following a rough process -
- Someone proposes an extension
- The list discusses the extension. The extension may get modified in
the process.
- The proposer of the extension gives an initial implementation to the
developers.
The proposer also works with developers during the
integration/testing phase.
- Proposer, developers and admin (developer==admin at this point!)
decide which
release this extension can be a included in.
- An extension may be promoted to the core by consensus. A change to
the core
API may also be proposed on the list.
We're hoping to keep the API as backward compatible as possible. Not
breaking earlier
applications is a priority.
Thanks
-- Shree
|
