Questions about Code generation, testing and build process

I have a few development related questions:

  1. I found the makesdna and makesrna code generation tools in source/blender. Additionally I found msgfmt in source/blender/blentranslation and I found the file source/blender/gpu/intern/gpu_codegen.c

    • These all appear to be pre-build time code generators. Is this correct?
    • Are there any other pre-build time code generators?
    • Would it be a good idea to move all of these into a common parent directory? (i.e. source/blender/codegens)
    • Are these (or should these) be run as part of make format code cleanup step?
    • Where should I put a new code generator, if needed (until there is a common parent for them)? and is there a standard place to add it to the makefiles for the build processes?
    • Are there any general/multi-purpose code generators in blender’s codebase already, so I am neither reinventing the wheel nor contributing to an explosion of small single-purpose tools in the tree?
  2. I was very happy to hear that Blender includes an automated unit test suite. I was also happy to hear that OSL supports automated unit test suites as well. While I’m a big proponent of TDD, I am not using it for my current effort, as I am still stumbling around, trying to find my way around the codebase.

    • How do I run the current automated test suite(s) for blender?
      • If there are more than one, or one with multiple modes, what does each suite (or mode) cover?
      • Do any of these have options to skip slow or hardware dependant tests?
      • Do I need any additional software or hardware installed (or other prerequisites) to run any of them (beyond what is required to build blender from source)?
      • Do any/all of these return a non-zero exit code on failure, so I can fail my build on a test suite failure?
      • Is there any easy way to fail my build on test failure when building on Windows?
    • Where in the code are the test suite subdirectories, and how are they subdivided?
    • Does GLSL support (at least in blender, if not in general) automated test suites?
    • Do Blender’s automated test suite(s) include tests for OSL and/or GLSL shader code already?
    • Do Blender’s addons repositories also have automated test suite(s) for the python code there?
  3. I’m working on a complex patch to Voronoi algorythms in Blender, and am aware that even if I manage to get it finished, submitted, reviewed, tested and merged before the July release cycle, not all of my changes may be desired. Locally, I am keeping my changes grouped in such a way that I can easily squash them into several logical commits that would allow the reviewer(s) to easily remove subfeatures they want to delay or remove.So far I have only seen ways to submit single diff patches to Blender.

    • Is there an official mechanism to submit a multi-commit branch for Blender review?
    • How?
    • Is there anything else I should consider to break this patch up?
  4. Some of the shader code I’m working on contains some “unrolled loops” (in quotes because nothing remaining in the code indicates it should be interpreted as a loop) which inhibits readability. In C++ this wouldn’t be a problem, as the compiler’s optimizer can be relied on to unroll them when appropriate. As much as I am no fan of C preprocessor tricks, that seems to be the one trick available to C++, OSL and GLSL that I can use to address this. I will have to experiment, but I believe I can leverage C preprocessor macros to make these unrolled loops much more clear and readable, but the proof will be in the pudding.

    • I know very few developers that are fans of doing anything fancy with the C preprocessor. I am no fan of it myself; so I expect this to be controversial. My focus will be on code clarity, but do you anticipate this will still be rejected outright?
    • I believe repeated code is a bad idea in general, and I don’t expect any of my C preprocessor macro loop unrolling code to be language specific. Is there anywhere I can put an .h file in the blender source code tree that can be included from C++, OSL and GLSL?
    • Have any of you seen something like this done clearly and successfully? I’m pretty sure I know how I want to do this, but I’m certainly open to better ideas.
  5. Should this have been 4 separate posts?

Thank you in advanced for your answers. Everybody in the blender development community has been very welcoming and helpful.

Almost all your questions on testing can be been answered by reading the developer wiki on testing and just experimenting by your self with building and running these tests.

Please do the minimum amount of research on our wiki and google, before you unload such a massive amount of questions.

Looks like a massive treasure trove of information. I will review it and highlight any questions I can’t find answers to. Thanks for pointing me in the right direction.

Hey Dr Linux, nice that you are mentioning tests.
After finishing the wiki, maybe you can update your post with the remaining questions and add suggestions to include in the wiki. E.g., I don’t think the Wiki mentions if the tests are run in an automated way (e.g. with every commit).

Recently I saw some commits to master that caused trivial crashes, and I was wondering if automated tests could have prevented that.

They are not, devs are currently expected to run them before committing large changes. I’d like to run them at least nightly in the somewhat near future.

On test automation:

git does support “hooks” that run automatically based on git events, but these hooks can not be installed from remotes. They can be installed, for instance, by the make file. I definitely think running all tests on commit is a good idea, i’m not sure that a failure should prevent a commit, in cases developers want to do a “work in progress” commit. Perhaps the test failure would prepend [BROKEN] to the commit message instead? and maybe prevent a push? The git server should certainly (eventually) reject push attempts that fail tests. I agree with @LazyDodo that running the test suit on nightly builds is an important first step.

On precomputed compile-time constants:

I did see Eigen3 mentioned as a Blender dependency, but I saw no library that appears to accommodate compile-time computation. I searched the code for gcem, which blender currently doesn’t use, but wonder if we currently use another library that does this. I doubt adding another dependency is justified at this time, but if we already have a library that does this, it would be silly not to use it. Do you know of one?

  1. There are a bunch of build time code generators. Moving them into a single directory does not seem helpful to me, that would move a bunch of unrelated code together, code generation can stay in the relevant modules. Code generation should only be used when it solves an important problem, since it makes debugging and maintenance harder.

  2. See the wiki and run the tests to see what’s there.

  3. arc has ways of submitting each commit individually, with dependencies between revisions. It’s not really easy to use though.

  4. If there are unrolled loops in the shader code, it’s often to make the code run efficiently on the GPU. Relying on the compiler to optimize it does not always work, so we do manual tweaking. I recommend to not touch such code for the sake of readability, it’s not worth the risk of impacting performance.

  1. Code Generators:
    • It was certainly just a suggestion. I’m new here and it felt like a parent directory would make sense.
    • I’m actually leaning away from compile-time code generation, toward pregenerated code blocks inserted into code by a tool I’ll build in source/tools/gen_code (new directory, but similar to source/tools/check_code) I guess I need to learn Python. :wink:
  2. I found the wiki page and directory. The tests look rather sparse, But I’m still reviewing them. So far I haven’t noticed any obvious tests for any OSL or GLSL code yet.
  3. I will look into arc, thank you.
  4. This is code I’m working on, so “leave it alone” probably isn’t the best advice. I certainly understand why the loops are unrolled, and am not suggesting relying on the shader compilers to do such optimizations. I was suggesting using preprocessor macros to do the loop unrolling. I realize this isn’t a traditional use for preprocessor macros, but I think I can make it work effectively, but I welcome other suggestions.

Updated: Please be aware that I’m not claiming to have any “right answers” here. I’m fully aware that you have all been working on this project several magnitudes longer than I have, and i’m mostly flailing around cluelessly in the dark. I’m not claiming to have accidentally discovered some insight that any of you have been missing for many years.

I am writing this here, now because I realize that some of what i’ve posted could be interpreted as: “This is the way i’m going. Follow me!” When my intent is when I say “This is the way i’m going.” someone else would say “Watch out for that tree!!!”

For anyone who took my comments as a know-it-all mouthing off, I apologize for speaking unclearly. Thanks.