VecSR - Vector Standard Render
VESA Standards : Vector Graphics, Boxes, Ellipses, Curves & Fonts : Consolas & other brilliant fonts : (c)RS
Vector Compression VESA Standard Display protocol 3 : RS
SiMD Render - Vector Graphics, Boxes, Ellipses, Curves & Fonts
*
32Bit SiMD Operations Available on AVX Per Cycle (A Thought on why 32Bit operations are good!)
(8Cores)8*32Bit SiMD(AVX) * 6(times per cycle) * 3600Mhz = 1,382,400 Operations Per Second
Security Relevant Extensions
SVM : Elliptic Curves & Polynomial graphs & function
AES : Advanced Encryption Standard Functions
AVX : 32Bit to 256Bit parallel Vector Mathematics
FPU : IEEE Float Maths
F16b : 16Bit to 32Bit Standards Floats
RDTSCP : Very high precision time & stamp
Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 popcnt aes f16c syscall nx lm avx svm sse4a osvw ibs xop skinit wdt lwp fma4 tce tbm topx page1gb rdtscp bmi1
*
OT-SVG Fonts & TT-SVG Obviously Rendered in Direct X 9+ & OpenGL 3+ Mode & Desktop Rendering modes
Improve Console & TV & BIOS & General Animated Render
Vector Compression VESA Standard Display protocol 3 : RS
SiMD Render - Vector Graphics, Boxes, Ellipses, Curves & Fonts
Improve Console & TV & BIOS & General Animated Render
Vector Display Standards with low relative CPU Weight
SiMD Polygon Font Method Render
Default option point scaling (the space) : Metadata Vector Fonts with Curl mathematical vector :
16 Bit : SiMD 1 width
32 Bit : SiMD Double Width
High precision for AVX 32Bit to 256Bit width precision.
Vectoring with SiMD allows traditional CPU mastered VESA Emulation desktops & safe mode to be super fast & displays to conform to VESA render standards with little effort & a 1MB Table ROM.
Though the VESA & HDMI & DisplayPort standards Facilitates direct low bandwidth transport of and transformation of 3D & 2D graphics & fonts into directly Rendered Super High Fidelity SiMD & AVX Rendering Vector
Display Standards Vector Render : DSVR-SiMD Can and will be directly rendered to a Surface for visual element : SfVE-Vec
As such transport of Vectors & transformation onto display (Monitor, 3D Unit, Render, TV, & Though HDMI, PCI Port & DP & RAM)
Directly resolve The total graphics pipeline into high quality output or input & allow communication of almost infinite Floating point values for all rendered 3D & 2D Elements on a given surface (RAM Render Page or Surface)
In high precision that is almost unbeatable & yet consumes many levels less RAM & Transport Protocol bandwidth,
Furthermore can also render Vector 3D & 2D Audio & other elements though Vector 'Fonting' Systems, Examples exist : 3D Wave Tables, Harmonic reproduction units for example Yamaha and Casio keyboards.
RGBA Composite Layer X-OR
RGBA Can simply be the shape printed onto alpha layer; Wide Transparency effect.
RGB-Supposition is X-OR Shape on mapping block or cube or curve & shape; Due to Alpha Alias smooth blending is achieved.
*
Furthermore can also render Vector 3D & 2D Audio & other elements though Vector 'Fonting' Systems, Examples exist : 3D Wave Tables, Harmonic reproduction units for example Yamaha and Casio keyboards.
Personally QFT is a much more pleasurable experience than VRR at 2xFPS+
Stable FPS & X-OR Partial Frame Retention saving on compression.
"QFT a Zero compression or low level compression version of DSC
1.2bc
X-OR Frame Buffer Compression & Blank Space Compression:
Vector Compression VESA Standard Display protocol 3"
"QFT transports each frame at a higher rate to decrease “display
latency”, which is the amount of time between a frame being ready for
transport in the GPU and that frame being completely displayed. This
latency is the sum of the transport time through the source’s output
circuits, the transport time across the interface, the processing of
the video data in the display, and the painting of the screen with the
new data. This overall latency affects the responsiveness of games:
how long it appears between a button is pressed to the time at which
the resultant action is observed on the screen.
While there are a lot of variables in this equation, not many are
adjustable from an HDMI specification perspective. QFT operates on the
transport portion of this equation by reducing the time it takes to
send only the active video across the cable. This results in reduced
display latency and increased responsiveness."
*
(c)Rupert S
Drawing tools & functions that are the basis of our draw frame & font functions : Polygon maths
Core Processor features : SVM, SiMD, FPU
Core tools : https://science.n-helix.com/2019/06/vulkan-stack.html
Reference material for Drawing Elliptoids, Curves & Polygons
SVM Elliptic Curve magic:
Fractal maths for improved efficiency & Combustion energy, Regard the photos & the FX8320E for details
Effective Application of SVM Processor Elliptic Maths
https://is.gd/SVMefficiency
Linear Bounding Volume Hierarchy &
Elliptic Bounding Volume Hierarchy for SVM Processor Feature:
SVM Can be emulated in SiMD pure 32Bit Single or 64Bit Double Precision,
& is for high complexity rendering such as non regular windows.
https://www.phoronix.com/scan.php?page=news_item&px=RADV-LBVH-Lands
SVM Can be emulated in SiMD pure 32Bit Single or 64Bit Double Precision..
Is useful for creating non Circle curves such as elliptoids & oblong wave boxes.
In VSR & VSR Variable Lighting we can define spaces with eliptoids SVM,
Therefore shape around trees & grasses & animals &or people & Whales.
https://www.youtube.com/watch?v=UojqzrPtR70
(c)RS
*
FFT or QFFT : Fast Fourier Transform
FFT or QFFT is not only about audio; But also Video & 3D, Mouse & input/output devices (c)RS 2022
FFT or QFFT is not only about audio; But also Video & 3D,
In fact FFT Fast Fourier Transforms are about any device such as a mouse that directly interacts with Waves,
Such a device is the laser mouse & pointer; The primary reason is to use Noise reduction & path smoothing,
Primarily to create a 16Bit to 256Bit pure float with high compression or pack bit properties.
Creating Sine-oidial curves & waves or SiMD, Float & packed integer/Float operations saves on bandwidth & increases messaging speed therefore!
Both the input & output from Bluetooth, 2.4G & USB & Serial can in fact be reduced to mapped Curves & angles; While this introduces a small error factor & this is a factor that producers & driver developers need to work out & create error margins for.
Creation & development of Ultra high precision Input & output for Humans, Robots & precision pointers; Requires a precise production FFT & to account for the fact surrounding the interactive motion of point A to point B; & In fact point C...
Development continues & today's mission is to open minds about why we use FFT & noise reduction & Curve maps such as elliptic SVM & Bit Averaging Fast transforms for Center point Algebra & Math Tables & Graphs.
Further study includes Raytracing & All Haptic motion; Sensors & Car engine Mechanics.
(c)Rupert S
*
Include vector today *important* RS https://vesa.org/vesa-display-compression-codecs/
https://science.n-helix.com/2016/04/3d-desktop-virtualization.html
https://science.n-helix.com/2019/06/vulkan-stack.html
https://science.n-helix.com/2019/06/kernel.html
https://science.n-helix.com/2022/03/fsr-focal-length.html
https://science.n-helix.com/2018/01/integer-floats-with-remainder-theory.html
https://bit.ly/VESA_BT
*
Core Concepts of Direct Vector Render Frame Buffers & Cache
LHP_DSC_Xor : Screen Fast Buffer Access
VESA Standard Ethernet Standard Frame Protocol for QFT, VRR & Low Latency High Performance Dynamic Compression XOR Frame Refresh : LLHP_DSCX : LHP_DSC_Xor
QFT & VRR basically allow the TV to float a resolution refresh free from Frame Cache Memory Refresh (Refueling the Cache Buffer) ,
Basically the frame can be fetched from the Frame Cache (4MB to 64MB) Without interacting with the CPU
This means a Fast Direct DMA Cache pull on frame to Screen & does not demand that the CPU need to perform this fast; Additionally the Frame comes without tearing or Frame pulls from the HDMI or display port VESA Ethernet Standard Frame Protocol.
Rupert S
*
Predicted Content Compression Frame Negotiation (c)RS
Compression for HDMI & DP : VRR & QFT with frame content prediction & Minimal Adjust; X-OR Content replacement
Compression Implicitly supported : STC, DXT, EAC & ATSC & DSC , Most of these compression forms are available in ARM, AMD, NVidia & Intel Hardware & therefore directly supported by us in creating the best frames & video; HDR WCG RGBA/X 4 Channel.
Compression required for a display; Common details include using Compression as a last desperate measure to improve bandwidth for displays on High Definitions such as 4K on HDMI 2!
My personal strategy is to implement compression that is transparent; Starting right at almost non,
Frequently the problem with VRR & QFT is that a frame is sent or not sent...
By utilizing Prediction in compression we force the prediction of an exact copy of present data,
We adjust the frame with X-OR & modify only a few details; Therefore we do not need to send a lot of data & can send more frames!
*
Vector Compression VESA Standard Display protocol 3 +
DSC : Zero compression or low level compression version of DSC
1.2bc
Frame by Frame compression with vector prediction.
Personally, QFT is a much more pleasurable experience than VRR at 2xFPS+
Stable FPS & X-OR Partial Frame Retention saving on compression.
X-OR Frame Buffer Compression & Blank Space Compression:
X-OR X=1 New Data & X=0 being not sent,
Therefore Masking the frame buffer,
A Frame buffer needs a cleared aria; A curve or ellipsoid for example,
Draw the ellipsoid; This is the mask & can be in 3 levels:
X-OR : Draw or not Draw Aria : Blitter XOR
AND : Draw 1 Value & The other : Blitter Additive
Variable Value Resistor : Draw 1 Value +- The other : Blitter + or - Modifier
*PCCFN
The idea Behind PCCFN is to modify the frame by a smaller amount with low bandwidth & thereby increase frame rate by the following method:
DSC Compression is used & Predict is enabled..
Predict is used to redisplay the frame on the screen; With no data needing to be sent : X-OR..
However Modifications are made to the frame by overruling parts of the Static frame with data..
The effect is that only parts of the frame (Vector Motion Prediction); Are sent,
Both bandwidth & speed are preserved & the same effect works from BFrames & Partial Full Frames.
https://hdmi.org/spec21sub/variablerefreshrate
https://hdmi.org/spec21sub/quickframetransport
*
ITS_DHDR_VRR : Gaming & Desktop : HDR, Source-Based Tone Mapping (SBTM)
High Efficiency DSC Screen Dynamic Shift State Screen blanking Replacement
Low Bandwidth Requirement for 40Hz to 240Hz+
HDR, HDMI & Display-port Standards VESA 2022 : Independent Thread
Asymmetric Compute Frame Buffer Tree for HDR, Display & Compression
DSC : RS (c)Rupert S
Composer Frame DSC is where we Compose a frame in the renderer, That
frame is for example the window task bar & another box for the
Explorer frame; The example is not OS Exclusive; Is an example.
We implement DSC Display compression in the frame (smaller than the
display resolution or super sampled),
Every piece of content in the Main Render Frame to HDMI & Display port
is computed independently with static content not being adjusted or
recompressed until needed,
Our goal is to place Every frame or window in a Sub-Buffer Cache & Render to the main Frame Cache/Buffer,
On completion of the frame at whatever FPS Refresh we desire for the Main Frame Buffer,
Effectively we Blitter &or Byte-swap our Window Frame Buffer to a location within the Main Frame buffer,
The location of our window & our localised processing mean that content of each window & therefore process is independently proven to be the Same as the frame before (We X-OR),
Therefore we Frame Predict (DSC) That a small portion of the main frame buffer has the same data,
We do not need to change a thing & so we do not need to utilize the processor to render it..
However if data has changed; Then the change is localised to a single small render space in the main frame buffer & we therefore can refresh the screen faster & Frame Prediction (Like JPG & MPEG)
Proves that we only need to inform the Screen (HDMI & DP Signal in our case);
That no additional date is sent; However any changes to the main frame buffer such as main view or video or text files or HTML Refresh will be Sent & Rendered,
Without Latency issues or large amounts of data being sent though the Cable..
But we still render faster than recompressing a main frame buffer completely & in addition change what we wish per thread without the resulting processing Hanging or waiting on Data To arrive from a baton-pass.
Our reasoning is that each frame is independent; Therefore we compose
in GPU or CPU & independently Compress the Frame within adjusted
context of the HDMI & DisplayPort,
3 Frame Buffer; We can optimise the whole frame with Prediction
Compression if we wish,
The Main goal : Independent Thread Render for Sub-Framing High Dynamic
Range with Independent Application Variable Refresh Rate :
ITS_DHDR_VRR.
The main advantages are : Task bar is Low CPU Resource use but high
refresh rate; low data modification rate over a tiny area of the task
bar,
The Game Window & the Frame (Mostly Square) are drawn with sub-pixel
precision on location..
But the frame that barely changes does not need recompression in DSC..
The Game window does not need to compute or adjust content Compression
for the frame...
Every piece of content in the Main Render Frame to HDMI & Display port
is computed independently with static content not being adjusted or
recompressed until needed.
This works with the HDR, HDMI & Display-port Standards VESA
(c)Rupert S
*
*Application of SiMD Polygon Font Method Render
*3D Render method with Console input DEMO : RS
3D Display access to correct display of fonts at angles in games & apps without Utilizing 3rd Axis maths on a simple Shape polygon Vector font or shape. (c)Rupert S
3rd dimensional access with vector fonts by a simple method:
Render text to virtual screen layer AKA a fully rendered monochrome, 2 colour or multi colour..
Bitmap/Texture,
Due to latency we have 3 frames ahead to render to bitmap DPT 3 / Dot 5
Can be higher resolution & we can sub sample with closer view priority...
We then rotate the texture on our output polygon & factor size differential.
The maths is simple enough to implement in games on an SSE configured Celeron D (depending on resolution and Bilinear filter & resize
Why ? Because rotating a polygon is harder than subtracting or adding width, Hight & direction to fully complex polygon Fonts & Polygon lines or curves...
The maths is simple enough to implement in games on an SSE configured Celeron D (depending on resolution and Bilinear filter & resize.
Such an example is my SiMD & MMX > AVX Image resizer,
Mipmapping fonts does tend to require over sized fonts..
For example Size 8 & 9 font output = Size 10 to 14 Font,
TT-SVG & Open Fonts OT-SVG & Bitmap fonts compress well;
Mipmapped from 3 sizes larger & Cached as a DOT3/5 or NV12...
You have to save a cache; The Cache can be:
Emulated or Dynamic Spacing (for difficult SETSPACE Console Font situations)
2 Tone, Grey, RGB, RGBA_8888, RGBA_1010102, RGBA_F16, P010, 444A, 888A or 101010A &
(DSC Precached Predicted Block Compression)tm
The representation with alpha is mainly for smoothing & clean lines & is very quick to draw.
Therefore we can Cache a Bitmap Version of any font,
We can of course Vector Render A font & directly to compressed surface rendering.
The full process leads up to the terminal & how to optimize CON,
We can & will need to exceed capacities of any system & To improve them!
*
DSC Precached Predicted Block Compression
We have a font for example with Alpha stored in the screen buffer & of a set size for BLITTING on top of a colour or image background,
The alpha prevents the transposed X-OR Image or Font from having noise & creates ..a smooth sharp in-place modification of content.
For our purpose X-OR can use Alpha instead of a single colour because this allows a very delicate smooth presentation on top of the background..
Repeated application (& Probably Saving of, To save Resource usage); Can overlay graphic of Font Content.*
VecSR is really good for secondary loading of sprites & text; In these terms very good for pre loading on for example the X86, RISC, AMIGA & Famicom type devices,With appropriate loading into Sprite buffers or Emulated Secondaries (Special Animations) or Font Buffers.
Font Drawing & Vector Render
Although Large TT-SVG & OT-SVG fonts load well in 8MB Ram on the Amiga with Integer & Emulated Float (Library); Traditional Bitmap fonts work well in a Set Size & can resize well if cached & Interpolated &or Bilinear Anti-Alias & sharpened a tiny bit!
presenting: Dev-Con-VectorE²
Fast/dev/CON 3DText & Audio Almost any CPU & GPU ''SiMD & Float/int"
Class VESA Console +
With Console in VecSR you can 3DText & Audio,
VecSR Firmware update 2022 For immediate implementation in all
operating systems & ROM's
Potential is fast & useful.
*
I will put this in print, My 3D & 2D Vector SiMD standard is the thing that i believe will save the most bandwidth on HDMI & DisplayPort Cables & Enable Vector 3D such as Laser Printers & Laser Screens, At the end of the day WE NEED VECTORS : RS
*
https://science.n-helix.com/2022/04/vecsr.html
https://is.gd/Dot5CodecGPU
*
Camera & HDMI & DP Compression Modes
Camera Modes
4:2:1 , 4:2:2 for the 4K Camera : HDR
4:4:4 for the faster 4K Camera : HDR
4:2:1 , 4:2:2 for the faster 8K Camera : HDR
TV Modes
HDMI 1.4 | 4:2:1 , 4:2:2 , 8bit, 10Bit for HD to HD+
HDMI 2 | 4:2:2 , 10Bit, 12Bit HDR 4K
HDMI 2.1 | 4:2:2, 10Bit, 12Bit, 16Bit 4K to 6K/8K..
Example : 5120x2880x 60000Khz-GPixClock-DataRate GRefreshRate-38.365Hz-DBLScan 4:2:2 12Bit
If we had DSC compression modes installed in firmware ...
BEST MODE : Can we upgrade this dynamically to HDMI 2.1 Standards with firmware & DSC Installed
Question is can we implement BEST MODE for our Quality range & Also utilize DSC & Alternative Texture Mode Compression & Dynamic MAX Speed
Yes We Can RS : DSC, ETC, ASTC & DTX Compression for display frames
Yes for Studio recording 4:2:2 mode offers 2x the resolution & 4 extra Bit for the same money as 4:4:4 : 4:2:2 10Bit, 12Bit, 14Bit, 16Bit : Higher Dynamic Contrast & Colour
Examples
https://youtu.be/VCdrB1b7wfc
https://youtu.be/NIsoSA8uO04
https://youtu.be/Suc0OV_9TiA
Render Folder https://bit.ly/VESA_BT
*
ASTC, EAC, DXT, PVRTC & DSC with firmware updated & need to be
included in the standards & firmware.
YCoCg-R
https://en.wikipedia.org/wiki/YCoCg
The screen content coding extensions of the HEVC standard and the VVC standard include an adaptive color transform within the residual coding process that corresponds with switching the coding of RGB video into the YCoCg-R domain.
The use of YCoCg color space to encode RGB video in HEVC screen content coding found large coding gains for lossy video, but minimal gains when using YCoCg-R to losslessly encode video
Yes for Studio recording 4:2:2 mode offers 2x the resolution & 4 extra Bit for the same money as 4:4:4 : 4:2:2 10Bit, 12Bit, 14Bit, 16Bit : Higher Dynamic Contrast & Colour
HDMI 1.4 | 4:2:1 , 4:2:2 , 8bit, 10Bit for HD to HD+
HDMI 2 | 4:2:2 , 10Bit, 12Bit HDR 4K
HDMI 2.1 | 4:2:2, 10Bit, 12Bit, 16Bit 4K to 6K/8K..
Example : 5120x2880x 60000Khz-GPixClock-DataRate
GRefreshRate-38.365Hz-DBLScan 4:2:2 12Bit
https://www.cablematters.com/blog/DisplayPort/hdmi-2-1-vs-displayport-2-0
https://www.cablematters.com/blog/DisplayPort/what-is-display-stream-compression
https://en.wikipedia.org/wiki/YCoCg
https://is.gd/Dot5CodecGPU
*
Things Task Shaders can (c)RS
https://www.phoronix.com/scan.php?page=news_item&px=AMD-RDNA3-More-5.19-Tasks-RADV
Task Shaders can be launched to implement Elliptic & Polygon MESH & thus create:
Things Task Shaders can implement though MESH Shading & Polygons:
(Direct Load of a preform MESH)
Multi-Threaded+
Tundra & fauna
Polygon Fonts
Video Rendering Polygon interpretative interpolation..
Polygon MESH Conceptualised Vector Audio.
X-OR DSC Blank space removal
Polygon math & viewer & Viewer Angle based dynamic MESH Subtraction & Addition..
Close loop Tessellation
OpenCL Group micro tasks
Direct Compute/DirectedCL Group micro tasks
Multi-Threading
*
"Task shader is an optional stage that can run before a Mesh shader in a graphics pipeline. It's a compute-like stage whose primary output is the number of launched mesh shader workgroups (1 task shader workgroup can launch up to 2^22 mesh shader workgroups), and also has an optional payload output which is up to 16K bytes."
