From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Viewport Notes / Work Log

I'm working mostly in the GPU_data_request branch. Some also in master and temp_viewport_fx_merge.

List of all my commits in case you want more detail.

March 15-21

7 commits this week

Checked in a new OpenGL batched geometry API that I had made in Nov/Dec 2014. This is a clean slate design, with some overlap with existing Blender APIs. Using GPUx_ prefix to avoid confusion with current GPU_ files.

  • specify vertex attribs
  • buffer in main memory & VRAM
  • build element lists of points, lines, triangles
  • draw these --^
  • state tracking (fairly basic)
  • lots of error & bounds checking!!! can turn this off

The idea is to handle things like VBOs, VAOs, other useful extensions automatically so users of this API don't have to work hard to get it right every time. This also lets us turn things on/off in one place for debugging & perf measurements.

Got basic grid floor & objects drawing in new viewport, using old draw functions for now.

Also spent way too much time on this non-viewport bug. Was not able to find root cause after a few days, so dropped it to focus on the main project.

March 22-28

7 commits this week.

Some code cleanup of Viewport FX merge branch.

Studied Blender's GPU module which currently handles most of the VBO drawing. What exactly does it do? How does it do those things? What does it not do? How could it be improved?

Some code cleanup of GPU module.

Created shell of a GLSL material node. This will hold a single GLSL function, which can be mixed & matched with other nodes. Goal: similar workflow to OSL shader node but for real-time rendering, not Cycles.

Thomas gave me some notes on this. I left the GLSL node for dead after that, but we will need it soon for building Workflow shader materials...

Made new versions of Camera and Mesh object draw functions. Minor changes so far to draw more efficiently; not using new GPUx API yet.

March 29-April 4

29 commits this week.

Rewrote Camera object drawing, down to single GL draw call (2 calls for active camera).

Added support in GPUx for non-generic vertex attribs for easier integration into legacy GL usage. Instead of specifying generic arrays with a name string, choose any or all of these:

  • GL_VERTEX_ARRAY
  • GL_NORMAL_ARRAY
  • GL_COLOR_ARRAY
  • GL_TEXTURE_COORD_ARRAY

Original GPUx API is based on generic attribs, which are still there for when we move to shader-based drawing / a newer GL.

Tweaked GPUx state-tracking API to force reset GL to our current tracked values. This allows interop with the majority of Blender code that doesn't use GPUx.

Some cleanup & optimization of Viewport FX merge branch. Psy-fi made some good notes on that branch's status.

Proper cross-platform handling of VAOs, which are not part of GL 2.1 (but are supported everywhere).

Started actually using GPUx to draw things! Camera objects for now. Fixed issues in GPUx which were exposed during its maiden voyage.

April 5-11

12 commits this week.

Draw base and derived meshes with GPUx API. Just Points or Edges (wireframe) at first, then added smooth solid.

Improved GPUx state tracking API.

New grid floor drawing in perspective views. More efficient (single GL draw call, every line drawn only once) and improved quality (subdivision lines never cross major lines).

April 12-18

11 commits this week.

Set up a new Linux dev environment (Fedora 21 with Mesa/Gallium drivers).

Fixed an NDOF regression (single-character code change!) on Linux, when I noticed my SpaceExplorer wasn't being detected. Affected 2.64 only and I haven't heard any user complaints.

Discovered a small bug in Mesa, made a small workaround in GPUx to compensate.

Started caching GPUx batches to improve performance. Before this, all draw data was generated from scratch at draw time.

Everything needed for drawing is collected into a GPUxBatch. These are generated per-object the first time drawn, then reused for subsequent draws. Regenerated when DerivedMesh or draw mode changes.

TODO:

  • actively reclaim memory (like gpu_buffers.c’s pool)
  • store a list of batches per DM, for complex drawing

Also started storing index buffers in VRAM. With this change, smooth solid meshes draw faster in the new viewport than the old/current VBO path. Wireframe was already faster, now it's CRAZY fast.

Remove short int -> float conversion for vertex normals. Keeping normals as GL_SHORT uses less memory. Would be 1/2 but padding/alignment makes it 2/3. These stay GL_SHORT in VRAM also, and are converted to floats when loaded by the vertex shader.

Added interpolation (smooth vs. flat shading) to GPUx state tracker. Now drawing code doesn't have to call glShadeModel. add to GPUx state: interpolation (smooth shading)

TODO: interpolation qualifier per attrib (flat/smooth/noperspective) instead of here. This requires GLSL 1.3 (OpenGL 3.0) or EXT_gpu_shader4 so we can’t go down that path yet.

April 19-25

19 commits this week.

Now managing GL buffer IDs in a thread-safe way. Old way was causing crash in GL when DerivedMesh discarded its GPUxBatch from another thread. New way deletes ID when safe to do so, otherwise “orphans” the ID to be deleted later.

Added a variety of surface normal treatments. Already had smooth, added flat (faceted) shading and generalized loop normals.

Added a GPUxBatch size query. How much VRAM does our draw data use? Or process memory for client-side data.

Optimized memory usage of flat-shaded and loop-normal-shaded mesh drawing.

Added compile-time option to keep vertex data in main mem or VRAM (but not both). If we’re using VBOs, free our own copy once GL has the data. Data always lives in main memory while being constructed, so that we don’t need to call any OpenGL functions until it’s time to draw. This allows us to build draw structures from mesh data using multiple threads.

Not yet checked in:

Started exploring ways to make wireframes more visually interesting / useful / informative. Some of these can be done on CPU, others need GLSL. Time to revisit GLSL node and Workflow shaders?