Oxide Games and Stardock talk DX12, Mantel, and Vulkan (GDC 2015)

Quick Thoughs on Strobbed LCD Displays for VR Perf Proxy

Using numbers from Alex Vlachos's Vive VR Talk at GDC, Vive with stencil optimization and super-sampling required for regular rendering: 378 Mpix/s (rectangular projection), or with just stencil optimization for ray tracing: 193 Mpix/s (derived from the Valve numbers, no 1.4x multiplier, shoot rays in warped view directly). Interesting that tracing or non-standard rendering tech might be able to leverage a 50% cut in the number of pixels to process.

Looking for a non-VR perf proxy? Something non-VR to target to get in the ballpark for frame cost for VR? For the regular rendering target: 2560x1440 at 100 Hz is still under the Mpix/s target. The 100 Hz figure is the highest ULMB strobbed refresh supported by the first strobbed IPS LCD panel: Acer XB270HU. Other than the viewing angle advantage of that IPS panel, it has roughly the same {gamut, brightness, etc} as the 1080p TN BenQ XL2720Z (roughly $450), and the TN has the advantage of supporting ULMB strobbed refresh all the way up to 144 Hz. For 1440p personally I think the larger BenQ XL2730Z is a better option than the Acer: the BenQ supports the VESA Standard Adaptive-Sync instead of being vendor locked for adaptive frame rate. Getting back to the numbers: 1920x1080 at 120 Hz is roughly 1.3x the "ray tracing" target for Vive, and 1920x1080 at 144 Hz is roughly 0.79x the "regular rendering" target (so would need some amount of super-sampling to be a perf proxy). It would be relatively easy to use the 1080p BenQ as a low persistence non-VR perf proxy for either case.



Awesome link: listing of large CRTs by size and refresh range.
For example,
NEC XP3791 (MultiSync XP37 Xtra) - 36". Apparently this via VGA cable can do 1536p max and 720p at 120 Hz.


Khronos Vulkan Presentation

GLAVE Demo: Debug tool for the Vulkan API

Really awesome to see great capture+replay+debug tools getting done in parallel with the API!


Vulkan (aka GLNext) Information Starting to Surface

Overview from www.khronos.org/vulkan
Khronos Reveals Vulkan API for High-efficiency Graphics and Compute on GPUs
As one of the members of Khronos directly involved in Vulkan, both at Epic and now continuing at AMD, I'm very excited about this API and looking forward to getting into more detail after the technical previews on Thursday!


NX Gamer Does Some Great In-Depth Technical Analysis

Great Example of Horrible API Interface Design

Linux gamepad support (via /dev/input/event) is one of the best examples of horrible interface design that I can remember. It should serve as a reminder of "how not to do it".

(1.) Sparsely Segmented IDs
Every large gap in a sequence of IDs say for input event codes has an associated increase in complexity for the developer: results in special branching, etc.

(2.) Mix of Same Buttons With Different and Similar IDs on Different Devices
There is a dead obvious common mapping between XBOX and PLAYSTATION controllers which should be used for common IDs. When instead the devices have subsets of different IDs for the same buttons, this results in angry developers.

(3.) The Same IDs Getting Used for Different Buttons on Different Devices
Another example of the same disease: creating extra complexity for the developer. The point of a interface is to reduce complexity. When the app needs to special case the device, right the app is now writing the driver too.

(4.) Using Base 10 Numbering Without Leading Zeros
Talking about the ordering of "event#" in "/dev/input/event" file names. Instead of something dead simple for a program like just "/dev/input/event##" where "##" is a hex number with a leading zero when under 0x10, lets instead make it base ten and require the developer to special case numbers under 10 (remove the leading zero). Fail.

(5.) Keeping Information Used Together On Unaligned Memory
For example, "struct input_id { __u16 bustype; __u16 vendor; __u16 product; __u16 version; };", it should be dead obvious that many developers would want to load "{vendor, product}" as a 32-bit value.

(6.) Providing No Good Way to Know if a Device is a Gamepad
The logic of the interface seems to be that developers need to keep an up-to-date {vendor, product} table for all current and future gamepads, this way they can write all the special case per device code required, or alternatively an even worse option of using a string table by device name.

(7.) Resorting To User-Space Daemons to Translate
Fantastic idea. First lets add extra latency to input. Second lets make it so that applications which handle the native /dev/input/event(s) manually now see duplications of the same device as some other kind of device, but with no obvious way to know the device was duplicated? Third lets push the problem to the user, creating another thing which needs to be configured by an expert and can easly go wrong.

Suggestions on How to Fix This Mess
Add INPUT_PROP_GAMEPAD so devs instantly know if the device is a "gamepad" or not. Any device which has the INPUT_PROP_GAMEPAD property uses a standard common set of contiguous input event codes.


The Order 1886!

This review contains no spoilers...

The Order 1886 is a fantastic game, one of my personal favorite games of all time.

Initially I was caught off guard by the doubt cast by various critics out to smear the game. They ended up doing me a favor, in that I now have a great list of online publications which I know to avoid spending any future time reading.

My quest started with a pre-order roughly 16 hours prior to launch. Followed by a playthrough on easy, beginning in early morning then wrapping a regular working Friday.

Why Easy? And a Word on "Replay Value"
When I want a gaming challenge, aka something on "hard", and something with "replay value", I take on the best humans I can find in competitive multiplayer: often in Call of Duty or Killzone. It is the people who bring you back, not specifically the game. The Order 1886 serves a different purpose in my eye, to provide a self-contained story experience which can be consumed, enjoyed, and remembered, and in this regard The Order 1886 excels. There is no expectation or need for replay value in this kind of game, just like there is no need for shoes to double as a toaster oven.

Quality Over Quantity
The game had the right length for me: not too long paired with high production value. To experience the ultimate in a given art form, to be immersed in attention to detail so fine that the mind is transplanted into the scene: this is where The Order takes you. The Order is a ride, part film, part cover shooter, with time inbetween to get absorbed in the style, sound, material and environment of years past. Gunplay feels refined, with fantastic audio/visual feedback expressed in the technology of the era. The focus on quality pixels brings The Order to a place no other game has yet to venture visually.

Too all those at Ready At Dawn, your hard work is much appreciated. Look forward to whatever you have in store next!


Leaving Something for the Imagination

Lack of information can invoke the perfect reconstruction of the mind. For visuals, seems like the deepness and slope of the uncanny valley is proportional to the spatial temporal resolutions of the output device. This 4K and eventual 8K crazyness, while awesome for 2D and print, has an unfortunate consequence for real-time realistic 3D: available perf/pixel tanks simultaneously as required perf/pixel skyrockets due to the increased correctness required for perceptual reality.

The industry continues to shoot itself in the foot focusing on quantity instead of quality, raising the baseline cost required for digital 3D content to climb out of the uncanny valley.

The industry also seems to be on a roll reducing the quality of display technology. Sitting through an "IMAX" film at a DLP based theater destroyed the respect I had for that brand. Paying extra for a "cubism" filter applied to what otherwise might have been a good experience is not what I had in mind when going to the theater. Quite a shock for someone who grew up with analog IMAX and OMNIMAX (IMAX projected in a dome).

Scan-and-hold LCDs have killed the quality of motion, and strobed LCDs have insane frame-rate requirements compared to a similar experience on a CRT. With typical HDTVs and LCD displays, 60Hz sits in the no-man's land between having more perf/pixel for something visually interesting, and having enough frame-rate on a scan-and-hold device to remove enough blur in motion (120Hz and higher required). For this scan-and-hold generation the true purpose of the "motion-blur filter" is not to add realistic motion blur, but remove enough visual quality to mask the distortion caused by scan-and-hold in motion.

Making Lemonade
Display technology trends provide a powerfull polarization: general flexible rendering solutions attempting to solve all problems will result in mediocre results (jack of all trades and the master of none of them). IMO everything interesting can only be found by sacrificing something others view as required, but which enables you to do something otherwise impossible.

Giving up frame-rate, for example the hot path for realistic rendering on PC: leverage variable refresh rate (to be able to simultaneously maximize the quality of animation and GPU utilization), render letterboxed around 30Hz (to maximize perf/pixel), run all game logic on the GPU reading input from CPU-filled persistent mapped ring buffer (minimize input latency), use heavy post processing like motion blur and extreme amounts of film grain (remove enough exactness to invoke the mind's reconstruction filter).

4K presents a serious problem in that in-display up-sampling can add latency, and often in-GPU-scan-out or in-display up-sampling is total garbage (for example too strong negative lobe adds a halo effect). The way I'd tackle the 4K display is actually the oppsite of convention: output native but use the increased resolution to simulate a synthetic CRT shadow mask or maybe a very high ISO film (massive grain), to reduce the required internal target resolution to something under 1080p. On that topic, the majority of the trending "pixel art" games completely missed the point of the arcades: ultra-low-latency input with constant frame-rate (not possible on mobile platforms or in browsers), arcade joystick input (something well-grounded and precise which can take a pounding), and high-quality non-block pixels produced by a CRT.

My personal preference is for the most extreme tradeoffs: drop view dependent lighting, go monochome, drop resolution, drop motion blur, drop depth of field, no hard lighting, no hard shadows, remove aliasing, add massive amounts of film grain, maximize frame-rate, and minimize latency. Focus on problems which can be solved without falling into the valley, produce something which respects the limits of the machine, and yet strives for timeless beauty.