 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi!
I would like to make PovRay faster ( and did it also, see 3D!Now ) and I
read the discussion about PovRay and OpenGL. So I thought about the
possibility to make PovRay with different methods of rendering. One would be
the normal, using double precision, precise & slow, the other would be the
fast, using single precision, not so precise but fast. Beause of that reason
I would like to make all necessary C files. They would contain all vector,
matricies and color calculations ( crosproduct, scale, add, sub, div, mul,
invers, linearcombination, square root, sin, cos, tan, exp, spuare etc.; all
of the function/macros which are in colour.c/h, matricies.c/h and vector.c/h
+ some additional functions/macros). But first I want to talk with the
PovRay team so this could be in the official PovRay. So how can I contact
them?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Jungmann wrote:
>
> Hi!
>
> I would like to make PovRay faster ( and did it also, see 3D!Now ) and I
> read the discussion about PovRay and OpenGL. So I thought about the
> possibility to make PovRay with different methods of rendering. One would be
> the normal, using double precision, precise & slow, the other would be the
> fast, using single precision, not so precise but fast. Beause of that reason
> I would like to make all necessary C files. They would contain all vector,
> matricies and color calculations ( crosproduct, scale, add, sub, div, mul,
> invers, linearcombination, square root, sin, cos, tan, exp, spuare etc.; all
> of the function/macros which are in colour.c/h, matricies.c/h and vector.c/h
> + some additional functions/macros). But first I want to talk with the
> PovRay team so this could be in the official PovRay. So how can I contact
> them?
The first thing would probably to contact the TAG about that, they can
forward your suggestions. Anyway, it probably will not be included in
Povray 3.5 so it could be a better idea to incorporate it into a version
of megapov based on 3.5.
Concerning the idea itself, as someone already mentioned, single precision
is not much faster than double (although memory use is lower of course)
and therefore it would be only much difference if it used new features
like 3D!Now which would be problematic for portability reasons.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Concerning the idea itself, as someone already mentioned, single precision
> is not much faster than double (although memory use is lower of course)
> and therefore it would be only much difference if it used new features
> like 3D!Now which would be problematic for portability reasons.
3D!Now and other features make PovRay realy faster ( 50%++, but more then
200% is possible) and I said that you should choise ( in the programm
itselfs, at runtime ) to use fast single precision or slow double precision.
Every new AMD & Intel processor supports SIMD instructions ( SIMD = single
instruction multible data, e. g. 3D!Now or SSE ) and if the processor
doesn't supports this you must not use them. For example if you have an
Pentium II which doesn't have 3D!Now or SSE then the programm ( PovRay )
don't let you render the scene with single precision. I know this looks like
a lot of work, but I don't think so. I did not need 30h to convert most of
the colour calculation of PovRay from "normal" to 3D!Now. I would do the
"fast" version for 3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem
for me. And the support is no OS problem, just the processor must support
the instruction and if it doesn't you can always render with double
precision. I hope you can understand, because my english is not so good.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Jungmann wrote:
>
> 3D!Now and other features make PovRay realy faster ( 50%++, but more then
> 200% is possible) and I said that you should choise ( in the programm
> itselfs, at runtime ) to use fast single precision or slow double precision.
> Every new AMD & Intel processor supports SIMD instructions ( SIMD = single
> instruction multible data, e. g. 3D!Now or SSE ) and if the processor
> doesn't supports this you must not use them. For example if you have an
> Pentium II which doesn't have 3D!Now or SSE then the programm ( PovRay )
> don't let you render the scene with single precision. I know this looks like
> a lot of work, but I don't think so. I did not need 30h to convert most of
> the colour calculation of PovRay from "normal" to 3D!Now. I would do the
> "fast" version for 3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem
> for me. And the support is no OS problem, just the processor must support
> the instruction and if it doesn't you can always render with double
> precision. I hope you can understand, because my english is not so good.
No problem with the english, but remember that Povray is not only used on
x86 machines, but also on Mac, Amiga, Sparc, Alpha, ... just to mention
some. It's a main goal of the Pov-Team to maintain usability for
different platforms which right now is supported through portable c code.
So even if 3D!Now & co were supported by all PC C-Compilers (most
important gcc) this would not be enough.
Of course you could add a whole lot of '#ifdef' to avoid such problems,
but that would be quite difficult to modify the code, becuase it would
essentially mean two code bases in some parts.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Of course you could add a whole lot of '#ifdef' to avoid such problems,
> but that would be quite difficult to modify the code, becuase it would
> essentially mean two code bases in some parts.
Why not just make a special, PC-optimized SIMD compile and offer it as a
separate patch? That way, you could optimize all you want, and forget about
users of other platforms. Then, when POV 4.0 comes around, we just merge
your compile in with the standard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2001-01-29 20:02, Daniel Jungmann <DSJ### [at] gmxnet> wrote:
>> new features like 3D!Now which would be problematic for portability
>> reasons.
>
>Every new AMD & Intel processor supports SIMD instructions ( SIMD =
>single instruction multible data, e. g. 3D!Now or SSE ) and if the
>processor doesn't supports this you must not use them. For example
>if you have an Pentium II which doesn't have 3D!Now or SSE then
>the programm ( PovRay ) don't let you render the scene with single
>precision. I know this looks like a lot of work, but I don't think
>so. I did not need 30h to convert most of the colour calculation of
>PovRay from "normal" to 3D!Now. I would do the "fast" version for
>3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem for me. And
>the support is no OS problem, just the processor must support the
>instruction
It is also a compiler problem. You didn't say which compiler you used or
how you got it to produce 3D!Now code. Essentially there are 3
possibilities:
1) You have a compiler which can generate 3D!Code out of "natural" C
code. This is the ideal case. The same code can be used for 3D!Now
platforms and for others.
2) You have a compiler which can generate 3D!Now code, if the C code
follows a certain pattern. This lets you still write portable C code,
but it may be arranged unintuitively and therefore hard to maintain
and even slower than the "natural" code on other platforms.
3) You used inline assembly. This is very compiler specific. gcc
definitely uses a different syntax than VC++, and what I remember
from my DOS programming days, there were differences between MS C
and Borland C, too. This means a lot of code duplication: Not only
for different processor types, but for different compilers, too.
So, just to maintain the 4 types of SIMD instructions you mentioned,
on the main Intel platforms, you may have to maintain 9 or 13
versions of the same code! And not only you have to maintain it, but
everybody else who wants to change anything in the affected code.
Unless this is very localized, the chances that somebody who wants
to implement a new pattern or media type, has to worry about some
assembler code he can't even read, seem high to me.
hp
--
_ | Peter J. Holzer | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR | which is our implementation of Linux.
| | | hjp### [at] wsracat |
__/ | http://www.hjp.at/ | -- Scott McNealy, Dec. 2000
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Jungmann wrote:
> I would like to make PovRay faster ( and did it also, see 3D!Now ) and I
> read the discussion about PovRay and OpenGL. So I thought about the
> possibility to make PovRay with different methods of rendering. One would be
> the normal, using double precision, precise & slow, the other would be the
> fast, using single precision, not so precise but fast. Beause of that reason
> I would like to make all necessary C files. They would contain all vector,
> matricies and color calculations ( crosproduct, scale, add, sub, div, mul,
> invers, linearcombination, square root, sin, cos, tan, exp, spuare etc.; all
> of the function/macros which are in colour.c/h, matricies.c/h and vector.c/h
> + some additional functions/macros). But first I want to talk with the
> PovRay team so this could be in the official PovRay. So how can I contact
> them?
I think if you do this it should be a patch or something. I don't like the idea
of official POV becoming bloatware. Would it not add considerably to the
program?
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> No problem with the english, but remember that Povray is not only used on
> x86 machines, but also on Mac, Amiga, Sparc, Alpha, ... just to mention
> some. It's a main goal of the Pov-Team to maintain usability for
> different platforms which right now is supported through portable c code.
> So even if 3D!Now & co were supported by all PC C-Compilers (most
> important gcc) this would not be enough.
No problem with Macs... I would _love_ to see a Velocity Engine (on the G4)
version of POV-Ray, which is not possible without using single precision. In
terms of the Sparc or Alpha, well, ... maybe keep the official source the way it
is, and put these fun new speedups in the platform-specific versions.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine wrote:
> I think if you do this it should be a patch or something. I don't like the idea
> of official POV becoming bloatware. Would it not add considerably to the
> program?
You are right, it would add considerably to POV-Ray... It would add the number of
pixels I can render in the same amount of time!!!
By all means, speed it up!!! =)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
> You are right, it would add considerably to POV-Ray... It would add the number of
> pixels I can render in the same amount of time!!!
> By all means, speed it up!!! =)
> ...Chambers
If you want roundoff error.
<duck> Same reason CDs suck. <cover>
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
