The current output related options:

--preview|-y

--authors|-authors
--generation
--help|-help|-h|-?
--libraries|-libraries
--license|-license
--version|-version|--V

$POVCON
$POVINC
$POVINI

become:

+-dm_ display_method

--authors
--compilation_settings
--generation
--help
--image_formats
--libraries
--license
--optimizations
--version

Aims / thinking :

- Yes. In general my options work is moving from the current yuqk fork 
options to what I think v4-ish ones should be. This more apparent with 
these basic 'unix' ones given the prior yuqk work long implemented.

- As with the existing yuqk implementation, trying to cut down on the 
routine defaulted output while providing users direct answers to 
specific requests for information.

- I'd extended yuqk's environment variable support initially, but I 
think it not strictly needed; It makes too for conceptual clutter both 
inside the code base and for users.

- These options are now fully part of the new options parsing module.

- No specific option for it, but there is change in error message when 
yuqk/povray called with no arguments.  In recent official POV-Ray 
versions we get two repeated messages about no input file (in yuqk one), 
but I believe a cleaner message suggesting the user try --help better.

Code wise, except for clearing out a couple prior ways to do these 
unix-ish options (and part of the optimizations reporting determined at 
run time(*)), is done.

Bill P.

(*) - The CPU specific, hand coded, optimizations.

I'm toying on and off with dropping this code from yuqk.

As mentioned in a bug posting, the code isn't working in official 
POV-Ray for recent (last several years) g++ builds. I implemented a 
patch in the yuqk code to fix this. This code is nice to have as a user, 
but it's also something more to support - which doesn't strictly need to 
be supported.

The reality is the hand coded optimizations we have are of much less 
general benefit to us than the official POV-Ray benchmark suggests... 
(The yuqk fork, long ago, dropped all the inbuilt benchmark support.)

There are too questions with with future CPU directions in that it looks 
like vendors are moving away from avx512 support, for example, in the 
lower end, user, CPUs. Guessing this power driven given the more cores / 
low power cores direction with user offerings. Maybe, it's part 
marketing too - adding reasons to go for server-ish class CPUs over 
something cheaper. In any case, the direction itself makes supporting 
CPU specific optimizations less attractive for those supporting the code 
bases to do it.

Post a reply to this message