Sunday, 15 December 2013

SharpDX, refactoring and complexity

I finally was able to spend some proper time to port over SlimDX dx11 to SharpDX (still on quite a few stressful projects, so I try to lock the little amount of spare time I have to test new goodies ;)

Main thing, I didn't redo all from scratch, here is my workflow in that case:

  • Port the core API: This is quite minimal, so I got rid of a lot of the boilerplate, less types, split some parts. API is now much more minimal and easy to work with. 
  • Port of the core: On first instance, I also just replace namespaces/namings. Then I started to refactor parts.
  • Nodes : Since you don't want to break all naming, I keep all very simple. I copy/paste all the nodes and remove the code inside ;) That means I don't have random compile errors, but I got all the in/outs up front (which is kinda similar to test driven development. When I think my core API is ready I push the code again.
So lately I was able to also add improvements, no more multi device helps a lot cleaning codebase, which would help 1 person in a lifetime but makes suffer all the others. Now dx nodes are simpler, easier to write.
There's sill a bit of work polishing API, but foundation seems much nicer for now.

Shader node finally got the improvement it deserved, and is much lighter api wise (eg, also decently faster in many cases).

I also looked to port a few of my high level nodes, and give some decent improvements to the layer system, and all of this is also promising, plan for next release being to provide more low level access to advanced users, while having more high level nodes for general patchers. This is for me a good step forward, but balancing this is hard ;)

On the week end I was able to test a bit API, and results are pretty promising:

Now one major issue with move to SharpDX is the following:

  • You want to support win7
  • You want access to latest DirectX (eg : 11.2)
Luckily, SharpDX makes it relatively easy, only pain part is file load/save. (In win7 you have dxut which makes it easy, in 8/8.1 you hve to do it yourself, or port DirectXTex from c++ to c#).

But that already makes 3 builds to maintain (I'd say ok, 2, 11.1 and 11.2 is not much difference for now).
And since in 4v you need to differenciate x86/x64, that makes 6 builds,uff, just a right pain.

So I looked again a bit more in 4v core, and oh man everything is so overcomplex.

SlimDX is really ultra tied to the core, and it's also the only assembly that forces this 32/64 bits build (90% of the rest could happily be anycpu).
But since it's tied to the core any plugin must choose.

This is a right pain.

I did a few tests, replacing SharpDX by SlimDX also for DX9, but it doesn't scale well, since then you tie yourself to the win7 assembly, which kinda sucks (assembly loading order can create some... interesting errors).

So easiest way ended up to be the brute force, eg, just get rid of SlimDX, and basically just break any plugin with DX9 mesh/layer/texture out.

For me right now it is the best and most sensible solution. I don't have access to the full 4v core, so I'm not able to split a few interfaces, so both of them can live together.

Since I'm really not into dx9/dx11 working in the same 4v instance, it's really not a biggie, but it can bring a few maintenance issues.

So what is the plan now?

Well it would be great to work with devvvvs in order to properly split standard pin logic to render pins, and properly isolate SlimDX (and any architecture dependent code) from he main core. I think it's primordial, but if i have to ship a custom core to avoid this nonsense, then so be it, I will gladly do it.

All those Matrices in 4v are also nonsense, I forgot some of the exact bits, but they add so much complexity to the system, and for me thinking that a simple 16 floats array create such a mess feels kinda bad.
So since I got mostly all of them with a much simpler, custom type, I might introduce that in the next build.
That would be a big thing since it would break backwards compatibility, but at the end I tend to plan for the future not the past.

Rest is to continue into SIMPLIFYING the system. I think most people tend to think too much about a problem, then the most you think of it the more twisted you mind becomes, then you produce a system 10 times more complex than it should be. This is wrong. Not saying that your system should be more flexible, but it needs to be easily testable/debuggable. More complexity never brings any good, over design is bad. 
For example, I looked a lot at code generation, and finally, I will only use it for fx->c# generation.
Doing it for all my types sounds good, but finally I ported all my geometry nodes in 20 minutes, would have taken 2 days to build a generator. For effects with reflection it stays a pretty good idea, since any user can write their own fx, so in that case it makes some sense.

The most fun part of it, you will complain about a system being overcomplex, decide to rewrite all, and makes something 5 times more complex up front (while repeating a lot of mistakes and adding new ones). Not worth it, refactor and improve.

Stop using crappy defaults, and inform user when something is wrong. Crappy defaults sounds a good idea on first instance, but it also makes your system more complex, and when your crappy defaults don't work anymore, you have to know if it comes from the user or yourself, and your user didn't learn anything. A few well placed defaults (with proper information eg : Ok you didn't provided this info, so I used this instead, but please be wary) is a step in the right direction. Choosing silent defaults is a NO GO.

Take more painful decisions if I need to ;) I know users hate changes in some ways (myself included), but then you have to decide and take the risk if you think this is future proof, not stay like ten years ago. I know on programmer side this is also a problem, but finally, changing library if you need is also taking care of users. I could just take AddFlow (the ui library used in 4v), which is now so crap that it's impossible to use vvvv in a live environment anymore (move a few nodes and all your render freezes). I wish they would take the painful path and just switch library, and it doesn't take that much time to do (just bit boring).

Ok stop mumbling, lot of new goodness on the way, be happy ;)

Monday, 2 December 2013

Last DX11 Release...

Using SlimDX ;)

Beta31.2 marks a little history as now the plan is to make a full move to SharpDX.

Some people might ask what is the benefits, or if I'm some kind of masochist who like to redo everything again :)

First, a move to SharpDX sounds like the smart option so far, and offers quite a few cool bits:

  • It's quite actively maintained
  • Support for DX11.2
  • Generally API calls are better for performance
  • No more dreaded 32/64 bits builds
And now I'm not rewriting everything, but I feel a lot of things which are already nicer than in old DirectX9 can be done in an even smarter way. Some years of programming in DX taught me a lot as well, and there's definitely some parts that I'm looking forward to improve or rework.

On a first note, writing an API is hard, it takes a lot of time, trial and error, to find a decent compromise between performances/features/ease of programming. So far I consider the first round as a success, there's still a few bugs/features missing, but hey, I'm more or less on my own writing the core, even tho I of course want to thanks people who contributed nodes/shaders ;)

So besides moving to SharpDX, there's of course many plans to improve what is there, in no particular order.


New wrapper is almost as fully featured as previous one, but has quite a decent amount of improvements:
  • Clear separation between Device/DeviceContext (multi threaded rendering in mind).
  • Resources are much thinner and much less abstract class/overrides, which should decently help where sometimes it was just a right pain to link 2 elements.
  • Now most of the runtime (not finished yet), is unit tested. So I can quickly see if a change breaks resource creation, pool... This is such a time saver.
  • Resource also have much easier to use creation methods, copies are much more streamlined (only one method to copy to dynamic texture now.
  • Wrapper will mostly manage many addons too (vlc/kinect/geometries...) so most of this can be independently tested in a much cleaner way.
  • Input layout handling is still one of the area for me, it's a bit of a pain to find the right model (for a game engine you can safely build a small hash, but in 4v case, there's so many permutations that it's really not easy).


Now on the vvvv side, there are also quite some (drastic) changes on the main core. Please don't be afraid as a patcher, on your side it shouldn't be any change.

Death of multi device. Having to handle resource dictionary per device sucks (pain to do anything thread safe), it never got used , and single device works on multi graphics card anyway (tested on a decently fat project). Maybe there's a 0.00001% scenario would pop up where it has a usage, but to be honest I prefer to ease the pain of the 99.9999% of other people ;)

That will mean some performance improvement (specially for large patches) more streamlined coding (less mess up with interfaces).

Layer system is also getting a little improvement, with better stacks for camera, reserved cbuffers, easier rebinding.

Scheduler improvement is also on the way, and small Task based rendering is an area I'm actively looking and experimenting.

3/Shader management

That's the main area where I want to work on, I find shader management in 4v sucks at the moment, you have gazillions of little pieces of code messing around that you can way too easily modify.

Not that modifying shader to fit you needs is bad, but it's just a pain for standard ones. That involves 2 big changes.

Shader package:

basically you have a pack folder and you can compile a library with the following:
  • Precompiled shaders (namespaced as in folder structure)
  • Json content file
So instead of having 200 shaders lying around, you can pack all that lot and easily distribute.

FX Projects

I always found FX projects to be a bit of an issue (an fx project is just a single file, so technically it's not even a project ;)

Also having an extension for each shader type gives some limitations (you don't want to give 50 extensions, but you still want to allow to give a shader a context). Context is for me what is the most missing in vvvv, most stuff is just... stuff.

Giving context to a shader, as selecting host via gui, would allow to create different ways of interpreting it (geometry generator/particle emitter....) in a much easier way, improving quality of contributions.

Ah and on the loop, shader will compile in background, no more massive freeze when you press Ctrl+S on this big fatty compute shader blur :)

I'm not sure if this one will be ready for first release, but it's definitely on decent priority list.

4/Shader API footprint

When you batch like a nutter, Shader API footprint doesn't matter much (you end up <100 draw calls anyway).

But now with compute you can also easily build data structures and manage a decent amount of logic directly in your gpu (on our last project we ended up having most of the processing hosted in there).

So API footprint starts to make sense again, specially on compute side.

There's already some prototypes/experiment done on that side, stay tuned, it rocks believe me ;)

5/Be high (No connotations with any type of substance... )

For now I consider 4v to be fairly low level. 

First part of the plan for DirectX11 was to build a backbone to have people getting used to it. Plan to have high level nodes was always there, but it's not that useful without a decent backbone, now time is getting there.

Many more high level nodes are needed, where people can really do things out of the box.
  • Deffered Renderers
  • Better Light equations
  • Easier to use materials
  • Pluggable particle systems
  • Geometry processors
  • All that wrapped in proper plugins (sandboxed) to also ensure quality API usage.
Some people will claim that it's less tweakable when you sandbox, but for many users they don't write shaders anyway, so some defaults where you can do quality rendering is one thing that is definitely needed.

Resource management, Smart ordering is where normally most user will fail, so giving them a decent start up is not a bad thing (and of course you still have access to the low level API if you feel up for it ;)

And please note that if you want to contribute you are more than welcomed, since doing all that lot takes time and I'm more or less on my own, and I also do projects ;)

That includes mostly:
  • One person to help manage GitHub/Builds (really that would be god send)
  • People to do help patches/examples
  • People for writing some nodes (even tho with new system it will be a bit different).

    So that's it for this post, would say, one chapter closes, one new chapter opens, exciting times ;)