From aa4a2e56ef8f19bd5542b0fd385c4348be434efc Mon Sep 17 00:00:00 2001 From: TimothyLottes Date: Sat, 12 Nov 2016 10:13:04 -0500 Subject: [PATCH] Add files via upload --- 20150911.html | 26 +++++++++++ 20150912.html | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++ index.html | 3 ++ 3 files changed, 146 insertions(+) create mode 100644 20150911.html create mode 100644 20150912.html diff --git a/20150911.html b/20150911.html new file mode 100644 index 0000000..388ca62 --- /dev/null +++ b/20150911.html @@ -0,0 +1,26 @@ +
+

20150911 - Self-Correcting CPU Pipelines

+
+ +Elaborating an idea which came up in a prior conversation...
+
+The aim is to make CPU programming as fun and easy as iterative run-time edit reload based GPU shader programming. + +Re-purpose the CPU page tables for intra-app memory protection between in-app tasks. +Effectively providing hardware protection for functional programming. + +When in-app tasks switch, adjust page table protection, then use INVLPG (on 486 and up) to flush TLB entries for changed pages. +The page tables change to disallow writes to now read-only data from the prior completed job, +and to allow writes to write-able data for the current job. +Use x86's support for various page sizes and pre-staged page tables for fixed jobs to make this efficient. + +Setup a background watchdog to act as a TDR check, to reset to a stable state if any task runs too long (infinite loop, etc). + +The "kernels" or CPU jobs which transform data can also be designed to be somewhat self correcting, +using min or max to limit indexes, etc... + + + +
+ + diff --git a/20150912.html b/20150912.html new file mode 100644 index 0000000..2f38592 --- /dev/null +++ b/20150912.html @@ -0,0 +1,117 @@ +
+

20150912 - Self-Correcting Part 2 or Rather a Rant on Why Extreme DoD

+
+ +Related idea to the prior post, and as a partial reply to some twitter comments...
+
+A "modern" API effectively coupled to a language: +everything revolves around calling "functions", +which is a lock-in to a very specific and constrained way of thinking.
+
+What if the API instead is a language agnostic description of data layout, +with some protocols (again data layout) for communication (message passing). +The "language" need not matter, and is completely replaceable at will. +The components which transform the data, aka the nodes in the program's data flow, +could be written in any language and are effectively throw-away, replaceable pieces. +
+
+The aim is to get to the point where the program is a canvas which is easily and instantly malleable, +but still runs at to-the-metal performance, with zero downside to dangerous experimentation --- that instant feedback addiction loop. +
+
+GPU provides this natively: dedicated hardware to contain accesses to within resources. +Traditionally the data layout is the collection of images and buffers, +the format of the data inside those resources, +and the rules at which the data can be adjusted. +For GPU programming using the "bind-all" style of programming +(where there is only one giant descriptor set with everything in it, +so that all shaders have access to all descriptors): +shaders accessing wrong resources is less of a problem, +the larger problem is out of bounds access in a given resource. +
+
+On the GPU you can build a pipeline of operations which keeps running even in the presence of bad data. +Sure the output may be totally wrong, but it runs. +For live compressed video broadcast in the presence of packet loss, +you have sweeping I (non-predictive encoded) macro-block(s) which +acts as a cleaner which causes the frame to re-converge to correct form +when data goes bad. +This same concept can be applied to GPU data. +Resource caches could have a cleaner which periodically +at a slow rate reloads parts of the data from storage. +Or with hardware support for async compute, +run a very low utilization and low priority background job which rebuilds procedural structures, +or validates correctness of various data structures. +The robustness of such a system might enable things like partial state saves +and then restores from out of sync systems, +to work enough to be useful. +This also has a relation to maintaining bounded frame rate, +designing in ability for the engine to limit itself and scale regardless of input, +and perhaps adapt to rapidly varying limits. +This isn't really a programming convention for language, +it is more about making robust solutions which allow for rapid development. +
+
+One of the key components missing from PC GPU APIs is a stable way to mutate +the GPU command stream from the GPU, +or perhaps this just starts with efficient predication in a given stream: +just place everything possible in the baked stream which gets replayed all the time, +then use logic embedded in the stream to avoid things which need not run (but with a decision based on active GPU state), +and dispatch indirect for variable workloads. +This works as long as the kernels/shaders in the graph are constant. +When code is specialized instead of data, then the process breaks down. +However, specializing code is ultimately what leads to giant bloatware and development grid-lock. +Simplification favors data specialization over code specialization. +Second issue, when bindings are specialized instead of data, +then the process breaks down. +This is why I'm a "bind-all" type of person. +If I'm stuck with limited bindings I'd rather take the hit using texture arrays. +
+
+This is also heavily related to memory organization. +I don't dynamically allocate in the traditional sense. +I always statically partition into fixed resources with bound limits at start time, +with aliasing to maximize utilization. +Machines have GB's of memory, why variable size dynamically allocate anything. +Use a dead simple fixed size resource pool allocator, +which is trivial to implement on highly parallel machines like GPUs. +
+
+Getting back to CPUs, having function call interfaces for everything is a disease. +What I much rather have is a collection of ports or interfaces in a fixed layout in memory. +Starting with something simple like time. +If the hardware has an accessible wall-clock time interface, say via some ISA opcode, +then I don't need a function to get the time. +I just need a convention for this fixed layout in memory of where to find the base time value +which I add to the ISA opcode results to get the real time. +Now for keyboard access. +Just give me a key bitarray at a fixed location in the memory layout. +Have a background thread atomically OR bits on key presses, +while I atomically AND out bits after I process key presses. +How about file access. +Just have a convention for maximum number of file handles, +maximum path size, a bit array to flag entries which are new requested transactions, +a bit array for the OS to reply that a transaction is finished, +a convention that lowered array elements (requests) are completed first, etc, +setup fixed arrays for this stuff in memory. +Everything ends up being, write data to memory, then ring some kind of doorbell, +to signal to the OS to get busy. +There is no functional interface, +just a text document which describes the memory layout and how to use it. +
+
+Bringing this back to GPUs, when the GPU can just write into CPU-side memory, +and there is some convention for triggering an interrupt, +or some OS convention to poll at a rate in which interrupts are not necessary +(aka you don't run hot then sleep, but rather stay live at lowest power state, +with cores powered down), then the GPU and CPU simply access the same +memory as the CPU to communicate with the OS. +And perhaps you split the read and write sections of this memory, +and not depend on atomics as in my prior examples, etc. +New OS functionality doesn't need a new API when the GPU wants to access, +the API = dead simple loads and stores. + + +
+ + diff --git a/index.html b/index.html index e50e8f3..f44f42e 100644 --- a/index.html +++ b/index.html @@ -89,6 +89,8 @@ O OOO ||..||OO||||||||||OOo || ||||||||||||| ||||OO|| |o| ||||||||OO||OOO 20150930 - Tonemapping and Slot Mask Simulation
20150915 - Bacon Wrapped Sour Cream
20150914 - Tearaway Unfolded PS4 on Wega CRT HDTV
+20150912 - Self-Correcting Part 2 or Rather a Rant on Why Extreme DoD
+20150911 - Self-Correcting CPU Pipelines
20150910 - September Trip to Iceland

20150829 - Ketogenic Diet Working on Year 2
@@ -150,6 +152,7 @@ O OOO ||..||OO||||||||||OOo || ||||||||||||| ||||OO|| |o| ||||||||OO||OOO 20140921 - Using GDB Without Source and With Runtime Changing of Code
20140920 - Interlacing at High Frame Rates and Low Persistence?

+20140830 - HDFury Nano GX: Part 2
20140828 - HDFury Nano GX: HDMI to VGA
20140826 - Scifi Reading Suggestion List From Twitters
20140823 - MinWM