I have an integrated Qt gui/povray that builds as a single executable.

git clone https://github.com/dickbalaska/povray.git
cd povray
git checkout qmake
qmake
make -j4
qt/gui/qtpovray		# run the executable

The gui behavior is exactly like, and has the same features as, 
http://www.buckosoft.com/qtpov/
(except you don't have to configure the povray executable, because it is 
built-in).

I have no idea no to get qmake to do super-optimization, i.e. use the 
libraries

../platform/libx86avx.a ../platform/libx86avxfma4.a 
../platform/libx86avx2fma3.a

There doesn't seem to be a "try/compile" thingy like in autoconf.

I still prefer the separate executables of the websockets edition.
1) Separation of gui from povray engine, i.e. "client/server"
2) automake for povray has more mature control of determining best 
compile conditions and processor features.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 21.05.2018 um 00:43 schrieb dick balaska:

> I have no idea no to get qmake to do super-optimization, i.e. use the
> libraries
> 
> .../platform/libx86avx.a ../platform/libx86avxfma4.a
> .../platform/libx86avx2fma3.a
> 
> There doesn't seem to be a "try/compile" thingy like in autoconf.

Here is how these things are supposed to work:

- The `platform/x86/FOO` directories contain source code hand-optimized
for particular instruction set extensions.

- It does not hurt to build and link _all_ of them: There is code in
place that will choose the best optimization _at run-time_ for whatever
x86 family CPU the binary actually happens to be running on. Most
importantly, that code will make sure that optimized code is _never_
invoked on a CPU that doesn't support the instruction set used therein.

- The reason we're compiling the instruction set specific code into
separate libraries is _not_ that we may want to exclude any of them, but
just that (1) g++ only accepts the hand-optimized code if we allow it to
use the same instruction set extensions in its own optimizations as
well, (2) we _must not_ allow instruction set extensions to be used
anywhere outside these particular files (because the functions therein
are the only ones guarded by run-time CPU detection), and (3) the
automake build process does not provide a mechanism to vary the compiler
settings on a per-file basis, so we need to place them in different
libraries.

In Visual Studio, this is different: There, instruction set switches
just govern compiler optimizations, while the instructions are always
available to hand-optimized code -- unless the compiler is too old to
support them at all, but that can easily be tested at compile time (and
the problematic code disabled accordingly) via preprocessor macros.

- The reason we have instruction set related tests in our autoconf build
process at all is _not_ to test whether the CPU supports them, but
merely whether the compiler does. A test for compiler brand and version
could conceivably do the same job, but in the autoconf framework a
direct test for compiler flags is the easier and more robust route.


So, to properly build the optimized code, there are two hurdles to overcome:

(1) Make sure the files in question are compiled with the corresponding
compiler flags, differing from the flags used for the other files. I'm
not sure how to do that with qmake, but from what I gather from the
internerds, `SUBDIRS` might be the keyword you want to search for.

The flags in question should be as follows:

/platform/x86/avx       -mavx
/platform/x86/avxfma4   -mavx -mfma4
/platform/x86/avx2fma3  -mavx2 -mfma  [sic!]

(2) Make sure the compiler in general supports the flags in question. My
guess would be that the easiest route with qmake is probably to detect
compiler brand and version, and from that decide which flags to use
(and, accordingly, which of the platform-specific source code files to
incldue in the build).

For GCC, the version numbers appear to be as follows:

-mfma4    since gcc 4.5
-mavx     since gcc 4.6
-mfma     since gcc 4.7
-mavx2    since gcc 4.7

For clang I have no corresponding information. From the perspective of
the source code, it mimicks the GCC signature and version numbers, so
there never was any need to research its own version history with
respect to the flags. (A potential problem with clang to watch out for
is that Apple's Xcode uses its own version of clang with a different
version numbering scheme.)

A very simple solution would be to require gcc 4.7 or later, or a
compatible clang version, as a prerequisite.

Post a reply to this message

On 05/21/2018 04:10 AM, clipka wrote:
> Am 21.05.2018 um 00:43 schrieb dick balaska:
> 
>> I have no idea no to get qmake to do super-optimization,

Thank you for the super documentation.  I have libplatform.a built.  I 
can't really tell if it's doing anything. I'm going to have to wire up 
the benchmark.

So, I just build those files and it magically works?  There's an awful 
lot of #ifdefs that look like they want some service somehow.

#ifdef MACHINE_INTRINSICS_H
#ifdef TRY_OPTIMIZED_NOISE_AVX
#ifdef TRY_OPTIMIZED_NOISE_AVX2FMA3
#ifdef TRY_OPTIMIZED_NOISE_AVXFMA4


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 11.06.2018 um 06:38 schrieb dick balaska:
> On 05/21/2018 04:10 AM, clipka wrote:
>> Am 21.05.2018 um 00:43 schrieb dick balaska:
>>
>>> I have no idea no to get qmake to do super-optimization,
> 
> Thank you for the super documentation.  I have libplatform.a built.  I
> can't really tell if it's doing anything. I'm going to have to wire up
> the benchmark.

Wiring up the benchmark shouldn't actually be necessary, provided your
variant of POV-Ray spits out the usual version and copyright information
(see `InitInfo()` in `renderfrontend.cpp`; BTW, if your variant of
POV-Ray does /not/ spit out that information, it would be in violation
of some of the 3rd party libraries' licensing conditions.)

If you got the optimization framework up and running, the last portion
in that section will read something like this:

Dynamic optimizations:
  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
  Noise generator: avx2fma3-intel (hand-optimized by Intel)

If the section is missing entirely, the optimized noise framework is
disabled entirely.

If the section is present but reports "Noise generator: generic
(portable)", then the framework /per se/ is working, but the individual
optimizations (or at least those that would fit your CPU) are all disabled.


> So, I just build those files and it magically works?  There's an awful
> lot of #ifdefs that look like they want some service somehow.
> 
> #ifdef MACHINE_INTRINSICS_H

Define this to the header file (if any required) that enables
machine-specific compiler intrinsics for extended instructions. E.g. for
GCC this needs to be `<x86intrin.h>`, while for MS Visual Studio this
needs to be `<intrin.h>`.

> #ifdef TRY_OPTIMIZED_NOISE_AVX
> #ifdef TRY_OPTIMIZED_NOISE_AVX2FMA3
> #ifdef TRY_OPTIMIZED_NOISE_AVXFMA4

Define these depending on which instruction set extensions the
/compiler/ supports.

These should be (un)defined globally for all source files. If for some
reason the decision to enable or disable a particular noise generator
can't be made globally, do define `TRY_OPTIMIZED_NOISE_XXX` globally,
but define `DISABLE_OPTIMIZED_NOISE_XXX` when compiling xxxnoise.cpp if
it turns out that the required instruction set extension isn't supported
after all. However, this non-global mechanism is inferior, and should be
avoided if possible.

Also, don't forget `TRY_OPTIMIZED_NOISE`, which must be defined
identically for all source files, serving as the master switch to turn
on the optimized noise framework /per se/.


Another set of macros used in conjunction with the optimized noise
framework are the `POV_CPUINFO`, `POV_CPUINFO_DETAILS` and
`POV_CPUINFO_H` macros, but these are primarily for diagnostic purpose.
If you omit them, the "Dynamic optimizations:" section will not report
"CPU detected:", but the optimized noise framework should still work fine.

Post a reply to this message

On 06/11/2018 04:18 AM, clipka wrote:
> Am 11.06.2018 um 06:38 schrieb dick balaska:
>> On 05/21/2018 04:10 AM, clipka wrote:
>>> Am 21.05.2018 um 00:43 schrieb dick balaska:

> 
> If you got the optimization framework up and running, the last portion
> in that section will read something like this:
> 
> Dynamic optimizations:
>    CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>    Noise generator: avx2fma3-intel (hand-optimized by Intel)
> 
> If the section is missing entirely, the optimized noise framework is
> disabled entirely.
> 
> If the section is present but reports "Noise generator: generic
> (portable)", then the framework /per se/ is working, but the individual
> optimizations (or at least those that would fit your CPU) are all disabled.
> 

Ah poo.  I don't see this even with generic Linux 3.8 alpha
http://news.povray.org/povray.general/message/%3C5b105212%241%40news.povray.org%3E/#%3C5b105212%241%40news.povray.org%3E
( https://tinyurl.com/y6udonlu )

It is definitely being built with 3.8-alpha.
I have seen these messages in the past, perhaps on Windows?

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:

> Ah poo.

Apu.

http://www.drawinghowtodraw.com/stepbystepdrawinglessons/2011/08/how-to-draw-apu-from-the-simpsons-with-easy-step-by-st
ep-drawing-tutorial/

Post a reply to this message

Am 12.06.2018 um 00:47 schrieb dick balaska:

>> If you got the optimization framework up and running, the last portion
>> in that section will read something like this:
>>
>> Dynamic optimizations:
>>    CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>>    Noise generator: avx2fma3-intel (hand-optimized by Intel)
>>
>> If the section is missing entirely, the optimized noise framework is
>> disabled entirely.
>>
>> If the section is present but reports "Noise generator: generic
>> (portable)", then the framework /per se/ is working, but the individual
>> optimizations (or at least those that would fit your CPU) are all
>> disabled.
>>
> 
> Ah poo.  I don't see this even with generic Linux 3.8 alpha
[...]
> 
> It is definitely being built with 3.8-alpha.
> I have seen these messages in the past, perhaps on Windows?

On Linux, it doesn't show when running "povray --version" (don't ask me
why); you'll have to render a scene. (If you're re-building anyway, you
can use "make check" for that purpose.)

Post a reply to this message

On 06/12/2018 02:21 AM, clipka wrote:

> 
> On Linux, it doesn't show when running "povray --version" (don't ask me
> why); you'll have to render a scene. (If you're re-building anyway, you
> can use "make check" for that purpose.)
> 

Ah. Don't mute the banner, thanks. :)

Yes, I see that exact message on 3.8-alpha (and on my websockets 
edition), but not on the qmake edition.

That gives me something to work from.

Thanks.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Dynamic optimizations:
   CPU detected: Intel,SSE2,AVX,AVX2,FMA3
   Noise generator: avx2fma3-intel (hand-optimized by Intel)

The "Noise generator" was easy, but the "CPU detected" required that I 
rename platform/x86/cpuid.h to povcpuid.h because it conflicts with
/usr/lib/gcc/x86_64-linux-gnu/5/include/cpuid.h

I don't get why, and why that wouldn't also be a problem with the 
autoconf build.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 15.06.2018 um 06:18 schrieb dick balaska:
> Dynamic optimizations:
>   CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>   Noise generator: avx2fma3-intel (hand-optimized by Intel)
> 
> The "Noise generator" was easy, but the "CPU detected" required that I
> rename platform/x86/cpuid.h to povcpuid.h because it conflicts with
> /usr/lib/gcc/x86_64-linux-gnu/5/include/cpuid.h
> 
> I don't get why, and why that wouldn't also be a problem with the
> autoconf build.

I'd say that it's not a problem with the autoconf build because it
shouldn't be a problem ;)

Which way round is the conflict? Is `platform/x86/cpuid.h` included
where the other one should have been, or vice cersa? Also, in which
source file is the offending `#include` located (and if that's not a
POV-Ray source file, what's the exact `#include` statement)?

Does your build process invoke the compiler with a command line
containing `-I-`? Also, what compiler are you using anyway?

Post a reply to this message