|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/15/2018 08:38 AM, clipka wrote:
> 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?
>
Dub baf.
As I was unwinding what I did to answer your questions (I deleted that
partially composed post), I realized I straightened out the -I list in
the same pass that I renamed cpuid.h to povcpuid.h.
So, ignore what I said, everything works as expected. :)
I'm happy with the qmake build on Linux.
My next step is to build a debian package (binaries installer)
and then get the qmake edition on Windows to build.
-------
Oh, one thing I don't like, but am leaving alone,
unix/povconfig/syspovconfig.h contains
#define POV_CPUINFO CPUInfo::GetFeatures()
#define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
#define POV_CPUINFO_H "cpuid.h"
and then later used as
#ifdef POV_CPUINFO_H
#include POV_CPUINFO_H
#endif
1) The file cpuid.h contains the class CPUInfo. The file should be named
cpuinfo.h to match the class.
2) POV_CPUINFO_H looks a lot like the header marker
#ifndef POVRAY_CPUID_H
#define POVRAY_CPUID_H
used to read includes once. It works because of the misnaming.
(My personal style has always been
#ifndef _POVRAY_CPUID_H_
#define _POVRAY_CPUID_H_
)
3) The only option for POV_CPUINFO_H is "cpuid.h" ,
why have it at all? It *is* used as a boolean switch, but wouldn't that
be better served by a boolean?
I guess it was envisioned at conception as having different values for
different architectures, but on the core editions Windows/Linux/(Mac?)
it is only ever "cpuid.h"
I would have preferred
#ifdef HAVE_CPUINFO
#include "cpuinfo.h"
#endif
--
dik
Rendered 328976 of 330000 (99%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.06.2018 um 21:36 schrieb dick balaska:
> Oh, one thing I don't like, but am leaving alone,
> unix/povconfig/syspovconfig.h contains
>
> #define POV_CPUINFO CPUInfo::GetFeatures()
> #define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
> #define POV_CPUINFO_H "cpuid.h"
>
> and then later used as
> #ifdef POV_CPUINFO_H
> #include POV_CPUINFO_H
> #endif
>
> 1) The file cpuid.h contains the class CPUInfo. The file should be named
> cpuinfo.h to match the class.
The file `cpuid.h` just /happens/ to define only that one class these
days. The translation unit's main feature is that it provides access to
the CPUID instruction of the x86 architecture, and the name actually
predates the class. It originally started out as a collection of global
functions, which have now been bundled into aforementioned class.
Since it's not a total misnomer, it has never been renamed, in order to
more easily track the file's history.
The moniker CPUInfo, on the other hand, was chosen because other
architectures may provide CPU information in a different manner.
> 2) POV_CPUINFO_H looks a lot like the header marker
> #ifndef POVRAY_CPUID_H
> #define POVRAY_CPUID_H
> used to read includes once. It works because of the misnaming.
No, it would still work without the "misnaming", due to the header
markers having the naming convention `POVRAY_foo_H`, whereas the
compile-time config settings (mostly) have the naming convention
`POV_foo_H`.
I do concede that it does still /look/ a lot like a header marker.
> (My personal style has always been
> #ifndef _POVRAY_CPUID_H_
> #define _POVRAY_CPUID_H_
> )
That's actually very bad practice, as it is technically in violation of
the C++ standard, which reserves to "the implementation" (*) any names
beginning with an underscore followed by an uppercase letter (**).
(* i.e. the compiler and its accompanying standard include files.)
(* Also reserved are any names containing a double underscore, as well
as any names in the global namespace starting with an underscore.)
> 3) The only option for POV_CPUINFO_H is "cpuid.h" ,
> why have it at all? It *is* used as a boolean switch, but wouldn't that
> be better served by a boolean?
> I guess it was envisioned at conception as having different values for
> different architectures, but on the core editions Windows/Linux/(Mac?)
> it is only ever "cpuid.h"
Not only /was/ it envisioned as having different values for different
architectures, it still /is/. We might for instance decide to add
optimized noise implementations for ARM, where `cpuid.h` would indeed be
a misnomer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|