ed/TimothyLottes.github.io
1
0
Fork 0
mirror of https://github.com/gomson/TimothyLottes.github.io.git synced 2026-08-04 14:48:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add files via upload

Browse Source
This commit is contained in:
TimothyLottes
2016-11-21 22:32:17 -05:00
committed by GitHub
parent 57a510c658
commit a593deb746
3 changed files with 129 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
20140810.html
+26
View File
@@ -0,0 +1,26 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20140810 - Front Buffer Rendering</h1>
<br>
<i>Ideas for practical front buffer rendering?</i><br>
<br>
The largest problem is probably variability in CPU thread scheduling. In theory not sleeping and polling causes an OS to treat the thread like a compute bound thread, increasing scheduling variability. Sleeping might increase interactiveness, but only if not blocking on a timer event (which typically has poor accuracy), and instead blocking on real IO. Attempting to track and adapt to scheduling variability is an option: sleep until the worst expected time before needing to wake, then spin until the actual event. But in practice, at interesting frame rates, I'd bet variability is too high for this to be practical.<br>
<br>
<b>A Better Way</b>
<br>
At home I'm working in 100% pull-model graphics. Meaning, what to draw is computed on the GPU, not the CPU. For a majority of the time, the CPU simply blasts the same exact rendering commands every frame. This decoupling of CPU and GPU enables the CPU to batch commands with any number of frames of latency before the GPU draws them. All IO between the CPU and GPU (gamepad input, etc) goes via low latency persistent mapped client side storage. This is fully async from the generation of draw calls. The issue of non-atomic writes and no memory barrier over PCIe is managed by sending and checking CRCs for all data transfered. The latency wall is effectively gone.<br>
<br>
The next step in the evolution of this system is to race scan-out using front buffer rendering instead of double buffered rendering. Have not had the time to try this yet, so the rest of this post is theory...<br>
<br>
Given the lack of API tools to make this easy, the core idea is to have the CPU periodically updating a "wall clock" value in persistent mapped client storage. The GPU shaders would read this value, and adapt the cost of rendering towards meeting the target framerate and sync. A background real-time priority CPU thread would write the time, then sleep, repeat. If required due to OS scheduling variability, regular CPU threads would also write out the time periodically. On platforms with no way to find the time of v-sync, likely this system would require providing the user with a tuning knob which dials in the v-sync phase (knob moves the tear line until it is off-screen).<br>
</div></body></html>
20140830.html
+92
View File
@@ -0,0 +1,92 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20140830 - HDFury Nano GX: Part 2</h1>
<br>
<i>Continuing to talk about the radical <a href="http://www.hdfury.com/shop/videoprocessors/hdf1-nano-gx/">HDFury Nano GX</a> HDMI to VGA converter...</i><br>
<br>
Got a better VGA monitor (ViewSonic G75f) which can do up to a 85 KHz horizontal scan, which is good for 960x540 @ 140 Hz. This works perfectly through the Nano. Getting a 16:9 aspect ratio on display is as easy has changing the monitor's vertical scaling.<br>
<br>
<b>Method for Generating Modelines</b>
<br>
Using the EDID, or fetching the modes from the monitor automatically, is effectively useless for anything interesting (non-standard). Not sure if this has more to do with the Monitor's EDID settings, what the Nano returns, or what the driver does with the EDID information. Instead I go back to classic "modelines" in the xorg configuration files.<br>
<br>
In order to easily generate "modelines", first take the monitors advertised peak specs, in my case, 1600x1200 @ 68Hz, run them through "cvt" and write down the "hsync". Use this as the maximum hsync the monitor can handle,<br>
<br>
<tt>[/etc/X11/xorg.conf.d] cvt 1600 1200 68<br>
# 1600x1200 67.96 Hz (CVT) hsync: 84.95 kHz; pclk: 183.50 MHz<br>
Modeline "1600x1200_68.00" 183.50 1600 1712 1880 2160 1200 1203 1207 1250 -hsync +vsync</tt><br>
<br>
Then use "cvt" to generate what ever modes are desired at a given resolution, making sure to limit the vertical refresh low enough such that the "hsync" value is never exceeded. At 640x480 this monitor can do 160 Hz,<br>
<br>
<tt>[/etc/X11/xorg.conf.d] cvt 640 480 160<br>
# 640x480 159.42 Hz (CVT) hsync: 84.49 kHz; pclk: 73.00 MHz<br>
Modeline "640x480_160.00" 73.00 640 688 752 864 480 483 487 530 -hsync +vsync</tt><br>
<br>
<b>X.org Configuration</b>
<br>
Thankfully with NVIDIA drivers, it is possible to completely turn off mode validation.
This is what enables the interesting non-standard modes,
and also enables users to destroy old VGA monitors which have no out-of-range protection.
In the "Device" section add (this is all one line),<br>
<br>
<tt>
Option "ModeValidation" "AllowNon60hzmodesDFPModes, NoEDIDDFPMaxSizeCheck, NoVertRefreshCheck, NoHorizSyncCheck, NoDFPNativeResolutionCheck, NoMaxSizeCheck, NoMaxPClkCheck, AllowNonEdidModes, NoEdidMaxPClkCheck"</tt><br>
<br>
Using this, I was able to try something similar to a 15.5 KHz arcade monitor modeline. This is actually for an Amiga I think. Also note "cvt" won't make correct 15.5 KHz modelines, horizontal frequency will be wrong.<br>
<br>
<tt>Modeline "640x240" 13.22 640 672 736 832 240 243 246 265 -hsync -vsync</tt><br>
<br>
Which is out of range of the ViewSonic (to low of a horizontal sync)
and triggers the monitor's out-of-range protection.
The same mode seems to work on the really old VGA monitor I have (which probably supported CGA, EGA, and VGA horizontal frequencies).
This seems to validate that newer NVIDIA GPUs and drivers (in X at least) and the Nano,
can be made to generate the lower hsync signals needed to drive CGA arcade monitors.
I'm still missing the conversion box required to test this (see the bottom of this post).<br>
<br>
<b>Solving the "Broken Panning"</b>
<br>
The problem I was having before is the X.org+driver automatically configuring and using both the laptop and HDMI out displays whenever I switch from "Metamode" to classic "Modeline". Since the "Modeline" was not supported by the laptop display, the display would show nothing but still be enabled, and that is why it looked as if the panning was broken. Everything was actually working, the mouse was just going over to the other display which was a black screen.<br>
<br>
Fixing this is easy, just disable the laptop screen using the "Monitor-<connection>" option (use the "xrandr" command line to list the display connections to find the proper name),<br>
<br>
<tt>
### SETTINGS FOR THE DISPLAY WHICH IS TO BE DISABLED<br>
Section "Monitor"<br>
Identifier "nope"<br>
Option "Ignore" "true"<br>
Option "Enable" "false"<br>
EndSection<br>
<br>
### SETTINGS FOR MY VGA MONITOR<br>
Section "Monitor"<br>
Identifier "Monitor0"<br>
VendorName "Unknown"<br>
ModelName "Unknown"<br>
Option "Primary" "true"<br>
Option "Enable" "true"<br>
HorizSync 31-86<br>
VertRefresh 60-162<br>
UseModes "Modes0"<br>
Option "DPMS"<br>
EndSection<br>
<br>
### THEN IN THE SCREEN SECTION, TURN OFF THE LAPTOP DISPLAY<br>
Section "Screen"<br>
Identifier "Screen0"<br>
Device "Device0"<br>
Option "Monitor-DP-2" "nope"<br>
Option "Monitor-HDMI-0" "Monitor0"<br>
Monitor "Monitor0"<br>
...</tt><br>
<br>
Next step is to attempt to see if I can drive both screens at different frequency and resolution. Then I can use one for programming and the other for analog output.<br>
<br>
<b>240p Arcade Options</b>
<br>
Great place to go for information: <a href="http://scanlines.hazard-city.de/">scanlines.hazard-city.de</a>. Under the assumption that my setup can generate a proper 240p VGA signal at the standard 15.5KHz used by arcade monitors (and NTSC TVs), <a href="http://forum.arcadecontrols.com/index.php/topic,95833.msg1278226.html#msg1278226">this thread post</a> talks about a converter which will convert that VGA signal into component for a US TV: <a href="http://www.crescendo-systems.com/transcoder.html">TC1600 VGA to YPrPb Transcoder</a> (no resampling/scaling).<br>
</div></body></html>
20140920.html
+11
View File
@@ -0,0 +1,11 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20140920 - Interlacing at High Frame Rates and Low Persistence?</h1>
<br>
After hearing Carmack's talk at the Oculus keynote, wanted to see first hand if interlacing artifacts are still visible at high rates on low persistence displays. Tried 180Hz interlaced on my CRT (get a pair of even-line and odd-line frames every 90 times per second). Still see massive artifacts. For instance when on-screen vertical motion is some multiple of scan-out, it is possible to see the black gaps between lines. The visible size of the gap is a function of the velocity of motion. Horizontal motion also does not look good. Probably has a lot to do with resolution (running 640x480 on a CRT which can do 1600x1200). Coarse shadow mask interlaced NTSC TVs did not look as bad at low frame rates, probably because the even and odd lines would partly illuminate the same bits of the screen (or maybe they had higher persistence phosphors)? If I use the display's Vertical Moire control to align the even and odd scan-lines to the same position in space, then the output looks much better even with constant black gaps between the lines. To me this whole experiment suggests that some kind of motion adaptive de-interlacing logic is needed at high frame rates (best case) or at a minimum the OLED display controller needs to fill in the missing lines in any interlaced mode using some spatial filter.
</div></body></html>