summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-09-14fb: update copyright lineVito Caputo
2017-09-14fb: s/fb_fragment_divide_single/fb_fragment_slice_single/Vito Caputo
Mechanical cosmetic change
2017-09-14ray: switch to the tiling fragmenterVito Caputo
2017-09-14fb: implement a tiling fragmenterVito Caputo
2017-09-14*: use fragment generatorVito Caputo
Rather than laying out all fragments in a frame up-front in ray_module_t.prepare_frame(), return a fragment generator (rototiller_fragmenter_t) which produces the numbered fragment as needed. This removes complexity from the serially-executed prepare_frame() and allows the individual fragments to be computed in parallel by the different threads. It also eliminates the need for a fragments array in the rototiller_frame_t, indeed rototiller_frame_t is eliminated altogether.
2017-09-14util: add MIN/MAX macrosVito Caputo
2017-09-14ray: simplify object iterators using sentinel typeVito Caputo
Trivial optimization eliminates some instructions from the hot path, no need to maintain a separate index from the current object pointer.
2017-09-13ray: cleanup ray_camera_frame_t fragmentsVito Caputo
Previously every fb_fragment_t (and thus thread) was constructing its own ray_camera_frame_t view into the scene, duplicating some work. Instead introduce ray_camera_fragment_t to encapsulate the truly per-fragment state and make ray_scene_render_fragment() operate on just this stuff with a reference to a shared ray_camera_frame_t prepared once per-frame. Some minor ray_camera.c cleanups sneak in as well (prefer multiply instead of divide, whitespace cleanups...)
2017-09-12ray: don't assume x_alpha is 0 at begin or y_stepVito Caputo
Currently fragments always start at the left edge of the frame, but when switching to a tiling fragmenter this is no longer true and causes visible errors.
2017-08-15ray: misc computational fixupsVito Caputo
ray:object intersection coordinates were incorrectly being computed relative to the ray origin using a subtraction instead of addition, a silly mistake with surprisingly acceptable results. Those results were a result of other minor complementary mistakes compensating to produce reasonable looking results. In the course of experimenting with an acceleration data structure it became very apparent that 3d space traversal vectors were not behaving as intended, leading to review and correction of this code.
2017-08-07rototiller: remove unused variableVito Caputo
2017-08-07ray: more fragments for better thread utilizationVito Caputo
For now, a simple cpu multiplier of 64 is used. fb_fragment_t needs a tiling fragment divider added...
2017-08-07threads: rework threaded fragment schedulingVito Caputo
Instead of creating fragment lists striped across available threads uniformly in a round-robin fashion, just have the render threads iterate across the shared fragments array using atomics. This way non-uniform cost of rendering can be adapted to, provided the module prepares the frame with sufficient fragment granularity. In the ray tracer for example, it is quite common for some areas of the screen to have lower complexity/cost than others. The previous model distributed the fragments uniformly across the threads with no ability for underutilized threads to steal work from overutilized threads in the event of non-uniform cost distributions. Now no attempt to schedule work is made. The render threads simply race with eachother on a per-frame basis, atomically incrementing a shared index into the frame's prepared fragemnts. The fragment size itself represents the atomic work unit. A later commit will change the various renderers to prepare more/smaller fragments where appropriate. The ray tracer in particular needs more and would probably further benefit from a tiling strategy, especially when an acceleration data structure is introduced.
2017-06-03ray: convert from recursive to iterative tracingVito Caputo
Small speedup, I personally find the code cleaner this way too. Everything in the hot path should now be inlined, no function calls.
2017-06-02ray: skip intersection tests on reflector objectsVito Caputo
We can just assume the object which reflected the ray being tracing isn't going to be intersected. Maybe later this assumption no longer holds true, but it is true for now.
2017-06-02ray: precompute primary ray for ray_object_sphere_tVito Caputo
This gets rid of some computation on the primary ray:plane intersection tests The branches on depth suck though... I'm leaning towards specialized primary ray intersection test functions.
2017-06-02ray: precompute primary ray for ray_object_plane_tVito Caputo
This gets rid of some computation on the primary ray:plane intersection tests
2017-06-02ray: plumb depth and camera to objectsVito Caputo
To enable prepare to precompute aspects of primary rays which all have a common origin at the camera, bring the camera to ray_object*_prepare() and bring the depth to ray_object*_intersects_ray() for primary ray detection. This is only scaffolding, functionally unchanged.
2017-06-02ray: separate lights from objectsVito Caputo
This may need to be undone in the future when more sophisticated lights, like area lights, are implemented. For now I can avoid polluting the objects list with the lights by strictly separating them.
2017-06-02ray: simplify trace_ray inner loop slightlyVito Caputo
Remove unnecessary nearest_object check, the distance comparison alone is sufficient when initialized to INFINITY.
2017-06-01ray: move shadow check to a functionVito Caputo
Just tidying up shade_ray() before more optimizations.
2017-06-01ray: perform ambient light color scale in prepareVito Caputo
Trivially removes a ray_3f_mult_scalar() from the hot path.
2017-06-01ray: move max depth check out of trace_ray()Vito Caputo
We can avoid some unnecessary work at the max depth by checking it in shade_ray() instead.
2017-05-27ray: inline ray_object_* switch functionsVito Caputo
2017-05-27ray: simplify ray_3f_normalize()Vito Caputo
This is functionally identical.
2017-05-27ray: redo ray_3f_distance()Vito Caputo
This function isn't currently used, but its implementation was awful.
2017-05-27ray: normalize direction missed in 28d8022Vito Caputo
Need to normalize the direction when we step the y axis and @ start.
2017-05-27ray: use approximate power in specular reflectionVito Caputo
powf() is slow but precise, this isn't the fastest method but it's at least portable and a bit faster.
2017-05-26ray: s/nlerp/lerp/ where normalize is unnecessaryVito Caputo
It's only necessary to normalize the direction stored vector in x_step(), the rest can simply be linearly interpolated which saves some divides.
2017-05-12ray: mult normalize in ray_object_sphere_normalVito Caputo
Simple optimization taking advantage of the prepare, mults generally are cheaper than divs.
2017-05-12ray: add ray_scene_prepare() object precomputingVito Caputo
Just embed a _prepared struct in the object where precomputed stuff can be cached. Gets called once before rendering, which ends up calling the object-specific ray_object_$type_prepare() methods per object.
2017-04-27*: remove vestigial module/${module}/${module}.hVito Caputo
Prior to rototiller_module_t these headers were included and the module-specific render functions called directly. That's no longer the case, these files are irrelevant today.
2017-04-27sparkler: enable rudimentary threaded renderingVito Caputo
This moves most of the particle system maintenance into the serially executed sparkler_prepare_frame(), divides the frame into ncpus fragments, and leaves the draw to occur concurrently. The drawing must still currently process all particles and simply skips drawing those falling outside the fragment. Moving more of the computation out of prepare_frame() and into render_fragment() is left for future improvements, as it's a bit complex to do gainfully.
2017-04-27sparkler: respect fragment->frame_{width,height}Vito Caputo
should_draw_expire_if_oob() assumed the fragment represented the entire frame. Instead, return 0 if the coordinates are outside the fragment, but only reset longevity if outside of the frame. If sparkler goes threaded in the drawing, this would result in threads simply skipping particles outside the fragment. The longevity reset occurring in all threads appears suspicious but should be benign since they all write the same thing - 0.
2017-04-27fb: apply fragment coordinates put pixel helperVito Caputo
fb_fragment_put_pixel_unchecked() assumed the x,y coordinates of the fragment were always 0.
2017-04-26sparkler: utilize context struct for module stateVito Caputo
2017-04-26sparkler: add virtual flag to particle_props_tVito Caputo
The burst particle abused a zero mass to circumvent the effects of aging. Instead use an explicit virtual flag to suppress aging, change busrt_cb to ignore all virtual particles instead of only its center. Previously burst_cb would thrust other bursts like any other particle, and this was incorrect. Now burst centers are always stationary, even when they overlap other bursts.
2017-04-22roto: utilize context struct for module stateVito Caputo
2017-04-22plasma: utilize context struct for module stateVito Caputo
2017-04-22julia: utilize context struct for module stateVito Caputo
2017-04-22*: add module context machineryVito Caputo
introduces create_context() and destroy_context() methods, and adds a 'void *context' first parameter to the module methods. If a module doesn't supply create_context() then NULL is simply passed around as the context, so trivial modules can continue to only implement render_fragment(). A subsequent commit will update the modules to encapsulate their global state in module-specific contexts.
2017-04-22ray: remove vestigial ray_threads codeVito Caputo
Now that rototiller is generally threaded when a prepare_frame() method is supplied, and modules/ray has been updated accordingly, discard the now redundant ray-specific threading code and related stuff.
2017-04-22ray: convert to generalized threaded renderingVito Caputo
The ray tracer was already threaded, so this required little change other than making some state global like the previous commits, and calling the underlying non-threaded single-fragment scene renderer function. A future commit will discard the now vestigial ray_threads related code.
2017-04-22roto: enable threaded renderingVito Caputo
Same basic changes as the previous commits made to julia and plasma.
2017-04-22plasma: enable threaded renderingVito Caputo
Same general procedure as the previous commit made to the julia module.
2017-04-22julia: enable threaded renderingVito Caputo
Move maintenance of per-frame variables into julia_prepare_frame(), which requires making them static file-scope globals for now. Also make minor adjustments to the code to make less assumptions about the fragment being rendered (like it's x/y coordinates being 0, etc.) A future commit will probably add an initializer function to rototiller_module_t, with an opaque pointer output which will be fed to all the module methods so these globals can be encapsulated and instantiated.
2017-04-22rototiller: add threaded renderingVito Caputo
This is a simple worker thread implementation derived from the ray_threads code in the ray module. The ray_threads code should be discarded in a future commit now that rototiller can render fragments using threads. If a module supplies a prepare_frame() method, then it is called per-frame to prepare a rototiller_frame_t which specifies how to divvy up the page into fragments. Those fragments are then dispatched to a thread per CPU which call the module's rendering function in parallel. There is no coupling of the number of fragments in a frame to the number of threads/CPUs. Some modules may benefit from the locality of tile-based rendering, so the fragments are simply dispatched across the available CPUs in a striped fashion. Helpers will be added later to the fb interface for tiling fragments, which modules desiring tiled rendering may utilize in their prepare_frame() methods. This commit does not modify any modules to become threaded, it only adds the scaffolding.
2017-04-22rototiller: add prepare_frame & rototiller_frame_tVito Caputo
Undecided on wether rototiller_frame_t should be fb_frame_t or not, may change later.
2017-04-22fb: add frame_{width,height} to fb_fragment_tVito Caputo
Modules need to know the overall dimensions of the frame the fragment they're rendering is part of. Previously it wasn't really necessary since the fragments supplied to the modules had always been the full page, but that's changing. This commit also changes the julia module to use the frame dimensions, others will need updating as well.
2017-04-22*: /render/render_fragment/ in rototiller_module_tVito Caputo
Adding more context to the name in anticipation of adding a prepare_frame() method to the module struct.
© All Rights Reserved