OVCC_ANS : Optimised Vector component Compression with Alpha Numeric Sequencing & Compression

OVCC_ANS : Optimised Vector component Compression with Alpha Numeric Sequencing & Compression (c)Rupert S

*

Suitable for codec, Texture, Video Element, Firmware & ROM, Executable, Storage & RAM, DLL & Library runtimes, CSS & JS & HDMI & DisplayPort VESA Specifications : https://science.n-helix.com/2022/09/ovccans.html

Eclectic & for the codecs of the world! OVCCANS (install and maintain as provided HPC Pack)
https://science.n-helix.com/2018/09/hpc-pack-install-guide.html

*

OVCC_ANS : RS

Suitable for codec, Texture, Video Element, Firmware & ROM, Executable, Storage & RAM, DLL & Library runtimes, CSS & JS & HDMI & DisplayPort VESA Specifications

Storage Problems EEPROM : Small powerful packed firmware for Devices, Routers, TV's Cameras & Computers

*

Devices, Drivers, VESA DSC & Active display drivers
PoCL & CL Kernels are used for the codecs & shading; Simply from the point of view multithreading SysCL & OpenCL are most effective at headless worker kernels; Frame buffer not required.

https://science.n-helix.com/2022/08/jit-dongle.html
https://science.n-helix.com/2022/06/jit-compiler.html
*

Cache Cyclic load segment Code Replication is quite a bit more efficient from the Shader, OpenCL, SiMD & Float expression point of view.

With code replication you do not necessarily have to depack the RAM to run the code; But that is a question of Jumps or Cache Cycles!

Similar to vector render on the optimised Vector component input compression is a layer of compression that renders fine lines, Curves & circles & points & basic gradients,

*
Wavelet bF16, F16 are quite useful for MP4 Standard compression
Wavelet bF32, F32 are quite useful for MP4 Enhanced Precision compression
Speed = bF16 (with advantages of long chain integer & small exponent)
For AVX F32 up to F64 are variously advantaged in multithreading,
Exceptionally bF16 & F16 NANO SiMD
*

OVCC is used to apply layers of vector graphic elements with optimised wavelets..
In principle the file is saved like so:

OVCC Layers

V = Vector
W = Wavelet
Gv = Gradient vector
Ns = Numeric Sequence
As = Alphabet Sequence
Ans = Alpha Numeric Sequence

{Load Binary or code: DLL,Exe, Library, WebJS for example}: {Firmware, Separate or joined}
{ Header }
{ Value storage for replication }
{ Gv:1>n, W:1>n, V:1>n }
{ Cans:1>n, Ns:1>n, As:1>n, Ans:1>n }

Vector Storage

[Gv];[Gv];[Gv]
[V];[V];[V];[V]
[W];[W];[W];[W]
[V];[Gv];[V];[Gv]
[W];[W];[V];[Gv];[W];[W];[V];[Gv]

Sequence Storage

[Ans];[Ans];[Ans]
[Ns];[Ns];[Ns];[Ns]
[As];[As];[As];[As]
[Ns];[Ans];[Ns];[Ans]
[As];[As];[Ns];[Ans];[As];[As];[Ns];[Ans]

Code Sequence Storage

[Loader]
[Cans];[Cans];[Cans]
[Ans];[Ans];[Ans]
[Ns];[Ns];[Ns];[Ns]
[As];[As];[As];[As]
[Ns];[Ans];[Ns];[Ans]
[As];[As];[Ns];[Ans];[As];[As];[Ns];[Ans]

You can use vector compression on plane transparency & Greyscale adding a lot to sharpness if optimised.

*
You see at the worst Drivers are compiled with last stage DSC Compression as Pixel shaders or compute shaders,

Thus avoiding bad bios DSC VESA But you can use OpenCL & directly render the frame as smoothing is not particularly required!

Even though before DSC a Smooth Wavelet is a big advantage to compression ratio & sharpness

But OpenCL Can smooth & sharpen with AA & SS Implemented
*

Drill texture & image format (with contrast & depth enhancement)

https://drive.google.com/file/d/1G71Vd9d3wimVi8OkSk7Jkt6NtPB64PCG/view?usp=sharing

https://drive.google.com/file/d/1u2Qa7OVbSKIpwn24I7YDbwp2xdbjIOEo/view?usp=sharing

Scanline Coder Compression
https://drive.google.com/file/d/148-BpVSfT6bA5nPjKoiZ41vwuI9n7P_f/view?usp=sharing

https://is.gd/BTSource

https://is.gd/LEDSource

(documents) JIT & OpenCL & Codec : https://is.gd/DisplaySourceCode

Include vector today *important* RS https://vesa.org/vesa-display-compression-codecs/

https://science.n-helix.com/2022/08/jit-dongle.html

https://science.n-helix.com/2022/06/jit-compiler.html

https://science.n-helix.com/2022/04/vecsr.html

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://science.n-helix.com/2022/08/simd.html

Eclectic & for the codecs of the world! OVCCANS (install and maintain as provided HPC Pack)

https://science.n-helix.com/2018/09/hpc-pack-install-guide.html

https://science.n-helix.com/2022/09/ovccans.html

Suitable for codec, Texture, Video Element, CSS & JS & HDMI & DisplayPort VESA Specifications : https://science.n-helix.com/2022/09/ovccans.html

https://www.gyan.dev/ffmpeg/builds/

https://github.com/GyanD/codexffmpeg/releases/tag/tools-2022-01-01-git-d6b2357edd

https://github.com/GyanD/codexffmpeg/releases/tag/5.1.1

https://www.gyan.dev/ffmpeg/builds/ffmpeg-tools.zip

https://github.com/GyanD/codexffmpeg/releases/download/5.1.1/ffmpeg-5.1.1-full_build.zip

https://ffmpeg.org/download.html

https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2

Full H265, H264 & AV1 Support https://drive.google.com/file/d/1Xka_QSRmVBCqnyCZwrA_yjnqwSl4g0ml/view?usp=sharing

*****

https://www.phoronix.com/news/Rust-UEFI-Firmware-Hope-Tier-2

https://rust-lang.github.io/compiler-team/

https://dvdhrm.github.io/2022/09/07/towards-stable-rust-uefi/

https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html

https://github.com/rust-lang/compiler-team/issues/555

Yes Firmware Codec Development is the Dinosaur!
DOLBY ATMOS 7.1.2 "Dinosaurs in Atmos"- OFFICIAL THEATER DOLBY VISION [4KHDR]
https://www.youtube.com/watch?v=0EKBYVUj4w0

JIT Compiler Dongle - The Connection HPC 2022 RS

JIT Compiler Dongle - The Connection HPC 2022 RS (c)Rupert S

JIT Compiler Dongle makes 100% Sense & since it has no problem acting like a printer! It can in fact interface with all printers & offload Tasks,

However in High Performance Computing mode of operation the USB Dongle acts as the central processor from the device side; That is to say the device such as the printer or the Display...

You can supply a full workload to the dongle & of course it will complete the task with no necessity of assistance from the computer or the device.

The JIT Compiler comes into its own one two fronts:

Compatibility between processor types.

Aiding a device in processing &or passing work to that device to run; Work that is shared & if required workloads are passed back & forth & shared,

Shared & optimised...

The final results for example are post-scripts? no problem!
The final results for example are Directly Compute Optimised Printer Jet algorithms? no problem!
The task needs to compute specifics for a DisplayPort LED Layout ? no problem!

The device is powerful so share, JIT Compiler for real offloading & task management & runtime.

Functional Processing Dongle Classification USB3.1+ & HDMI & DisplayPort (c)RS

Theory 1 Printer

Itinerary:

Printers of a good design but low manufacturing cost of ICB printed circuits have a printhead controller,

But no Postscript Processor; But they do have a print dither controller & programmable version need to interface with the CPU on the printing device,

Print controlling is a viable Dongle & also Cache but workload cache has to have a reason!

That reason here given is the JIT Dongle that is able to interface with both Web print protocol & IDF Printing firmware.

But here we have postscript input into the JIT Compiles Kernel & output in terms of Jet Vectors & line by line Bitmap HDR & head motion calculations,

We can also tick the box on Postscript offloading on functioning PostScript printers; But we prefer to offload JIT for speed & size..

Vectors & curves & lines & Cache.

Theory 2 Screen

Itinerary as of printers but also VESA & line by line screen print & VESA Vectors & DisplayPort Active displays,

Cable Active displays require the GPU to draw the screen & calculate the Line Draw!

The Dongle activates like a screen with processor & carries the screen processing out; Instead of a smartwatch or small phone that does not have a good capacity for computer lead active display enhancements.

Theory 3 Hard Drives & controller such as network cards & plugs for PCI

Adapting to Caching & processing Storage or network data throughput commands, While at the same time being functionally responsive to system command & update makes JIT Dongle stand out at the head of both speed & function...

Network cards can send offloading tasks to the PCI socket & the plug will process them.

Hard-drives can request processing & it shall be done.

Motherboard ROMs & hardware can request IO & DMA Translation & all code install is done by the OS & Bios/Firmware.

Offloading can happen from socket to Motherboard & USB Socket & URT..

All is done & adapts to Job & function in host.

The 8M Motherboard & OS verifies the dongle, licences the dongle from the user..
& runs commands! Any Chipset, Any maker & every dongle by Firmware/Bios
What the unit constitutes is a functional Task offloader for OS & Bios/Firmware.

The utility is eternal & the functions creative & secure & licensed/Certificate verified.

Any Motherboard can be improved with the right Firmware & Plugin /+ device.

(c)RS

*****

Technology Demonstration https://is.gd/DongleTecDemo

Combining JIT PoCL with SiMD & Vector instruction optimisation we create a standard model of literally frame printed vectors :

VecSR that directly draws a frame to our display's highest floating point math & vector processor instructions; lowering data costs in visual presentation & printing.

(documents) JIT & OpenCL & Codec : https://is.gd/DisplaySourceCode

Include vector today *important* RS https://vesa.org/vesa-display-compression-codecs/

https://science.n-helix.com/2022/06/jit-compiler.html

https://science.n-helix.com/2022/04/vecsr.html

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://science.n-helix.com/2022/08/simd.html

SiMD Chiplet Fast compression & decompression (c)RS

SiMD Chiplet Fast compression & decompression (c)RS

*
Subject: SiMD Compression / Decompression chip of 2mm on side of die Chiplet (c)RS

Compression / Decompression chip of 2mm on side of die Chiplet (c)RS

Additional CPU & APU Compression / Decompression chip of 2mm to
feature on chiplet console APU's this is planned so that the Chiplet
does not require modification to the console APU,

Additionally to feature pin access Direct Discreet DMA for storage :

https://www.youtube.com/watch?v=1GvUdPn5QLg

*

Configuration of SiMD : Huffman & Compression : RS

To pack the majority of textures to 47 bit, one presumes a familiarity with Huffman codecs & the chaotic wavelets these present...

AVX256 Tasks x 4 = 64Bit
SiMD 16Bit x 2 = 32Bit / Alignment with AVX == x8
SiMD 32Bit x 2 = 64Bit / Alignment with AVX == x4

Closest to 47 = 40Bit Op x 2 (2.5Oe) | 80Bit/2 | 2 op x (1.5Oe)

So 40 Bit x2 parallel 6 Lanes

So on operation terms of precision :
32Bit Satisfies HDR,
40Bit Very much satisfies HDR,

16Bit satisfies JPG (basic)
64Bit satisfies LUT & Wide Gamut HDR Pro Rendering

*
Drill texture & image format (with contrast & depth enhancement)

https://drive.google.com/file/d/1G71Vd9d3wimVi8OkSk7Jkt6NtPB64PCG/view?usp=sharing
https://drive.google.com/file/d/1u2Qa7OVbSKIpwn24I7YDbwp2xdbjIOEo/view?usp=sharing

https://science.n-helix.com/2022/08/simd.html

Research topic RS : https://is.gd/Dot5CodecGPU https://is.gd/CodecDolby https://is.gd/CodecHDR_WCG https://is.gd/HPDigitalWavelet https://is.gd/DisplaySourceCode

*

GPU acceleration process : Huffman (c)RS

In the case of dictionary we create a cubic array: 16 parallel Integer cube, 32 SiMD,

FPU is used to compress the core elliptical curve with SVM Matrixing in 3D to 5D for files of 8Mb,FPU is inherently good versus Crystalline structure, We use the SiMD for comparative matrix & byte swap similarity.

It is always worth remembering that comparative operations are one of the most fundamental SiMD functions; But multiply, ADD & divide exist within SiMD,
Functional FPU code can always use arrays of SiMD to handle chaotic play in the field..

A main example is in Huffman's the variance of a wavelet from the main path,
Routes though main wavelet types are handled by table (on the amiga for example) &or FPU!
Micro changes make SiMD viable; In the same principle as a Hive & her ants.

Inherent expansion doubles the expected SiMD use; Ideally 2MB ram per cube
Taking advantage of a known quantity & precision we code-block by 16Bit to 128Bit segments.

Self correction allows us to Cube Huffman Decode into blocks, we parallelize blocks,
To (additionally) handle error we block the original compression.

"We also use fine-grained locking for the frequency dictionary, individually locking each key-value pair. Once the symbol codes have been determined, each symbol is replaced by its code, and all symbols; So are processed in parallel.

Decompression is inherently sequential, and hence much harder to parallelize. In this case, we take advantage of the self-synchronizing property of Huffman coding, which allows us to start at an arbitrary point"

In order of SiMD
https://github.com/lemire/SIMDCompressionAndIntersection
https://github.com/lemire/FastPFor

Huffmans still worth the money!

Principally an order & load+Vec https://github.com/jearmoo/parallel-data-compression

Huffman source, Requires analysis https://github.com/catid/Zpng

https://vignan.ac.in/pgr20/20ES011.pdf
https://bestofgithub.com/repo/Better-lossless-compression-than-PNG-with-a-simpler-algorithm

ZPNG
faster than PNG and compresses better for photographic images. This compressor often takes less than 6% of the time of a PNG compressor
https://github.com/catid/Zpng

*

SiMD Chiplet Fast compression & decompression (c)RS

3 proposals

https://is.gd/BTSource

LZ77:
https://github.com/jearmoo/parallel-data-compression

The FastPFOR C++ library : Fast integer compression :
https://github.com/lemire/FastPFor

SIMDCompressionAndIntersection
C/C++ library for fast compression and intersection of lists of sorted integers using SIMD instructions : https://github.com/lemire/SIMDCompressionAndIntersection

Compressor Improvements and LZSSE2 vs LZSSE8
http://conorstokes.github.io/compression/2016/02/24/compressor-improvements-and-lzsse2-vs-lzsse8
http://conorstokes.github.io/compression/2016/02/15/an-LZ-codec-designed-for-SSE-decompression

Compression Science Docs

A General SIMD-based Approach to Accelerating Compression
Algorithms
https://arxiv.org/ftp/arxiv/papers/1502/1502.01916.pdf

SIMD Compression and the Intersection of Sorted Integers
http://boytsov.info/pubs/simdcompressionarxiv.pdf

Fast Integer Compression using SIMD Instructions
https://www.uni-mannheim.de/media/Einrichtungen/dws/Files_People/Profs/rgemulla/publications/schlegel10compression.pdf

Fast integer compression using SIMD instructions
https://www.researchgate.net/publication/220706907_Fast_integer_compression_using_SIMD_instructions

*****

The FastPFOR C++ library : Fast integer compression
Build Status Build Status Ubuntu-CI

https://jearmoo.github.io/parallel-data-compression/

GO

https://github.com/zentures/encoding

http://zhen.org/blog/benchmarking-integer-compression-in-go/

https://github.com/golang/snappy

The FastPFOR C++ library : Fast integer compression
Build Status Build Status Ubuntu-CI

What is this?

A research library with integer compression schemes. It is broadly applicable to the compression of arrays of 32-bit integers where most integers are small. The library seeks to exploit SIMD instructions (SSE) whenever possible.

This library can decode at least 4 billions of compressed integers per second on most desktop or laptop processors. That is, it can decompress data at a rate of 15 GB/s. This is significantly faster than generic codecs like gzip, LZO, Snappy or LZ4.

https://github.com/lemire/FastPFor

https://github.com/lemire/FastPFor/archive/refs/tags/v0.1.8.zip

https://github.com/lemire/FastPFor/archive/refs/tags/v0.1.8.tar.gz

Java May have a use in JS ôo
https://github.com/lemire/JavaFastPFOR

https://github.com/lemire/JavaFastPFOR/blob/master/benchmarkresults/benchmarkresults_icore7_10may2013.txt

*****

SIMDCompressionAndIntersection

C/C++ library for fast compression and intersection of lists of sorted integers using SIMD instructions : https://github.com/lemire/SIMDCompressionAndIntersection

SIMDCompressionAndIntersection
Build Status Code Quality: Cpp

As the name suggests, this is a C/C++ library for fast compression and intersection of lists of sorted integers using SIMD instructions. The library focuses on innovative techniques and very fast schemes, with particular attention to differential coding. It introduces new SIMD intersections schemes such as SIMD Galloping.

This library can decode at least 4 billions of compressed integers per second on most desktop or laptop processors. That is, it can decompress data at a rate of 15 GB/s. This is significantly faster than generic codecs like gzip, LZO, Snappy or LZ4.

*****LZ77*****

Principally an order & load+Vec https://github.com/jearmoo/parallel-data-compression

https://jearmoo.github.io/parallel-data-compression/


Summary of What We Completed

We have written and optimized the sequential version of the Huffman encoding and decoding algorithms, and tested it. For the parallel CPU version of this, we were debating between SIMD intrinsics and ISPC, and OpenMP.

However, Huffman coding compression and decompression doesn’t seem to have a workload that can appropriately use SIMD. This is because there is no elegant way of dealing with bits instead of bytes in SIMD. Moreover, different bytes compress to a different number of bits (there is no fixed mapping of input vector size to output vector size), which makes byte alignment in SIMD very difficult (for example, the compressed form for a random 4 byte input could range from 2 to 4 bytes). This is much worse for decompression, where resolving bit-level conflicts (where a specific encoding spreads over 2 bytes) is almost impossible and might actually result in the algorithm being slower than the sequential version. Therefore, we decided to focus on OpenMP.

For compression, we first sort the array in parallel, to minimize number of concurrent updates to the shared frequency dictionary, reducing contention and false sharing. We also use fine-grained locking for the frequency dictionary, individually locking each key-value pair. Once the symbol codes have been determined, each symbol is replaced by its code, and all symbols are so processed in parallel.

Decompression is inherently sequential, and hence much harder to parallelize. In this case, we take advantage of the self-synchronizing property of Huffman coding, which allows us to start at an arbitrary point in the encoded bits, and assume that at some point, the offset in bits will correct itself, resulting in the correct output thereafter.

We read about the LZ77 algorithm and explored the different variants of the algorithm. We also explored different ways to parallelize LZ77. One naive approach is running the LZ77 algorithm along different segments of the data. This approach could output the same result as the sequential implementation if we use a fixed size sliding window and reread over some of the data. Another approach is the one outlined in Practical Parallel Lempel-Ziv Factorization which uses an unbounded sliding window and employs the use of prefix sums and segment trees to calculate the Lempel-Ziv factorization in parallel.

Update on Deliverables

Our sequential implementations are close to finished, and we have some idea of how to parallelize the algorithms. Our goal for the checkpoint was to have both of these parts finished, but we have not completely met the goal. We may pivot and work on parallelizing the compression and decompression of the Huffman coding algorithm and drop the LZ77 part of the project altogether.

Our new goals:

Parallelize the Huffman Coding compression.
Parallelize the Huffman Coding decompression or LZ77 compression

Hope to achieve:
Both parts of part 2 in our new goals.

*****ZPNG

Huffman source, Requires analysis https://github.com/catid/Zpng

Small experimental lossless photographic image compression library with a C API and command-line interface.

It's much faster than PNG and compresses better for photographic images. This compressor often takes less than 6% of the time of a PNG compressor and produces a file that is 66% of the size. It was written in just 500 lines of C code thanks to Facebook's Zstd library.

The goal was to see if I could create a better lossless compressor than PNG in just one evening (a few hours) using Zstd and some past experience writing my GCIF library. Zstd is magical.

I'm not expecting anyone else to use this, but feel free if you need some fast compression in just a few hundred lines of C code.

**************************

Main interpolation references:

Interpolation https://drive.google.com/file/d/1dn0mdYIHsbMsBaqVRIfFkZXJ4xcW_MOA/view?usp=sharing

ICC & FRC https://drive.google.com/file/d/1vKZ5Vvuyaty5XiDQvc6LeSq6n1O3xsDl/view?usp=sharing

FRC Calibration >

FRC_FCPrP(tm):RS (Reference)

https://drive.google.com/file/d/1hEU6D2nv03r3O_C-ZKR_kv6NBxcg1ddR/view?usp=sharing

FRC & AA & Super Sampling (Reference)

https://drive.google.com/file/d/1AMR0-ftMQIIC2ONnPc_gTLN31zy-YX4d/view?usp=sharing

Audio 3D Calibration

https://drive.google.com/file/d/1-wz4VFZGP5Z-1lG0bEe1G2MRTXYIecNh/view?usp=sharing

2: We use a reference pallet to get the best out of our LED; Such a reference pallet is:

Rec709 Profile in effect : use today! https://is.gd/ColourGrading

Rec709 <> Rec2020 ICC 4 Million Reference Colour Profile : https://drive.google.com/file/d/1sqTm9zuY89sp14Q36sTS2hySll40DilB/view?usp=sharing

For Broadcasting, TV, Monitor & Camera https://is.gd/ICC_Rec2020_709

ICC Colour Profiles for compatibility: https://drive.google.com/file/d/1sqTm9zuY89sp14Q36sTS2hySll40DilB/view?usp=sharing

https://is.gd/BTSource

Colour Profile Professionally

https://displayhdr.org/guide/
https://www.microsoft.com/store/apps/9NN1GPN70NF3

*Files*

This one will suite Dedicated ARM Machine in body armour 'mental state' ARM Router & TV https://drive.google.com/file/d/102pycYOFpkD1Vqj_N910vennxxIzFh_f/view?usp=sharing

Android & Linux ARM Processor configurations; routers & TV's upgrade files, Update & improve
https://drive.google.com/file/d/1JV7PaTPUmikzqgMIfNRXr4UkF2X9iZoq/

Providence: https://www.virustotal.com/gui/file/0c999ccda99be1c9535ad72c38dc1947d014966e699d7a259c67f4df56ec4b92/
https://www.virustotal.com/gui/file/ff97d7da6a89d39f7c6c3711e0271f282127c75174977439a33d44a03d4d6c8e/

Python Deep Learning: configurations

AndroLinuxML : https://drive.google.com/file/d/1N92h-nHnzO5Vfq1rcJhkF952aZ1PPZGB/view?usp=sharing

Linux : https://drive.google.com/file/d/1u64mj6vqWwq3hLfgt0rHis1Bvdx_o3vL/view?usp=sharing

Windows : https://drive.google.com/file/d/1dVJHPx9kdXxCg5272fPvnpgY8UtIq57p/view?usp=sharing

JIT Compiler

Driver & Firmware Integrated JIT Compiler (c)RS

Driver & Firmware Integrated JIT Compiler - DPIC Display Protocol Indirect Compute 2022

Presenting JIT for hardware interoperability & function : https://is.gd/DisplaySourceCode

Integrated JIT Compiler directly into a Shader & OpenCL / Direct Compute Driver Ethernet Protocol Socket & IP

To & from all devices though Firmware Central JIT Compute Compiler

Computation tasks can be carried out by all installed Hardware & USB / Plugged devices:

WebGPU
Python
JavaScript
WebCL, OpenCL & Direct Compute
JIT compiled maths

Indirect Computation such as maths in Application : WebGPU, WebCL, OpenCL & Direct Compute.

Utilising Computation is as simple as having a V8 WebGPU function available,

May be directly available from the GPU without accessing the CPU if SDK is directly supported in GPU RAM...

So in the case of a TV BlueRay Player as an example; We may infact simply be able to integrate..

HTTPS: WebGPU, WebCL, OpenCL & Direct Compute & Methods such as JIT compiled maths.

The plan we use is to; Integrate JIT Compiler directly into a Shader & OpenCL / Direct Compute Driver Ethernet Protocol Socket & IP

Computation tasks can be carried out by all installed Hardware & USB / Pluged devices,

To & from all devices though Firmware Central JIT Compute Compiler

*

Kernel Method requires around 20Kb + Cache Kernel run on OpenCL &or Direct Compute,
Closest device runtime &or Operation infrastructure procedure call.

In the case examples:

Camera focus OpenCL Kernel Ofload
(Edge detect, No image : edges & 4pixels with gradient with jpg compression)

Audio device with buffers OpenCL Kernel Ofload
(processing input is from CPU to Audio Device : Simple Objective Pre Processing case)

SSD & HDD Firmware OpenCL Kernel Ofload
(Location & Write & Math proof of safe write &or read, Error correction)

Printer OpenCL Kernel Ofload
In the case of the printer the postscript driver "Is NOT" installed in your router,
The router prints but has basic drivers,

OpenCL Kernel Ofload (from printer),
Makes the task of processing a Postscript Font & Curl Angle print; Easy!

If you have a USB Hub with processor,
The Postscript Instruction Set is processed as OpenCL Vector Print

*

DPIC Device Protocol Indirect Compute Hub

Proposed HDMI/DisplayPort Hub (also GPU Processed)
Proposed USB Hub,
Proposed Bluetooth Hub,
Proposed WiFi Hub
Proposed Ethernet/Net Hub

with
50Mhz to 800Mhz processor with Dynamic Eco settings
*

On the aspect of HDMI & DisplayPort HTTP Ethernet protocol - DPIC Display Protocol Indirect Compute 2022 (c)RS https://bit.ly/VESA_BT

On the aspect of HDMI & DisplayPort HTTP Ethernet protocol; Several forms of Computation exist as possible for the equipment involved : Televisions, Monitors & GPU & CPU

*

(c)Rupert S https://bit.ly/VESA_BT

Research topic RS : https://is.gd/Dot5CodecGPU https://is.gd/CodecDolby https://is.gd/CodecHDR_WCG https://is.gd/HPDigitalWavelet https://is.gd/DisplaySourceCode

*

Example : JIT Optimise Dynamic code - DPIC Device Protocol Indirect Compute

Audio/Video/GPU/CPU/Urt/USB/BT : hardware to slow or fast? trade Processor Resources : How? DCP:JIT

Camera Focusing API for Web : Application,
Because Computers surely focus a camera better if we use DPIC : Device Compute
Processing JIT Compiler,
Then Latency is not the issue!

Video & Audio can do with additional processing : How? DCP:JIT

Monitor would be able to do so much more! With additional processing : How? DCP:JIT

Kernel Method requires around 20Kb + Cache Kernel run on OpenCL &or Direct Compute,
Closest device runtime &or Operation infrastructure procedure call.

Tier processing; Objectives:

High quality process,
Performance,
Shared workload,
Appropriate Computing unit

In the case examples:

Camera focus OpenCL Kernel Ofload
(Edge detect, No image : edges & 4pixels with gradient with jpg compression)

Audio device with buffers OpenCL Kernel Offload
(processing input is from CPU to Audio Device : Simple Objective Pre Processing case)

SSD & HDD Firmware OpenCL Kernel Offload
(Location & Write & Math proof of safe write &or read, Error correction)

Printer OpenCL Kernel Offload
In the case of the printer the postscript driver "Is NOT" installed in your router,
The router prints but has basic drivers,

OpenCL Kernel Offload (from printer) > (from USBHub : Some) > (Router back to printer),
In an ideal situation the Kernel processes the next tier up; In this case Pro-USBHub;
Leaving the router process free but with a very high quality printing job done.

Makes the task of processing a Postscript Font & Curl Angle print; Easy!

If you have a USB Hub with processor,
The Postscript Instruction Set is processed as OpenCL Vector Print

*
DPIC Device Protocol Indirect Compute Hub

Proposed HDMI/DisplayPort Hub (also GPU Processed)
Proposed USB Hub,
Proposed Bluetooth Hub,
Proposed Wifi Hub
Proposed Ethernet/Net Hub

with
50Mhz to 800Mhz processor with Dynamic Eco settings
*

Inter-device JIT Compiler Kernels (c)RS

JIT Compiler : Driver facing the Monitor is included with JIT Compiler Firmware
subjectively...

For the JIT Compiler to be available add the JIT Compiler to the HDMI
& Displayport Driver,

Facing from the Monitor/AUDIO/VIDEO/BUSS/URT <>
GPU <> CPU

USB & Bluetooth require both the USB, Dongle adapter <> BUSS/URT <> CPU/GPU...
To further connect Printers & other devices...

Under the same principle the Lens of a camera operating under the mounting fixture requires a fast connection,
In order to utilize Infrared/UV/Laser & Light or DIODE Controlled fixtures that require special firmware downloaded kernels,

These kernels are flexible & will speed up devices & assure top performance with:

16Bit, 32Bit, 64Bit & Float Kernels

Driving the monitor & Learning sharper graphics

https://is.gd/BTSource

Technology Demonstration

*

Combining JIT PoCL with SiMD & Vector instruction optimisation we create a standard model of literally frame printed vectors :

VecSR that directly draws a frame to our display's highest floating point math & vector processor instructions; lowering data costs in visual presentation & printing.

(documents) JIT & OpenCL & Codec : https://is.gd/DisplaySourceCode

Include vector today *important* RS https://vesa.org/vesa-display-compression-codecs/

https://science.n-helix.com/2022/06/jit-compiler.html

https://science.n-helix.com/2022/04/vecsr.html

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://science.n-helix.com/2022/08/simd.html

VecSR - Vector Standard Render

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

Photos & Performance https://is.gd/4447GamerWEBB

https://youtu.be/dOTwq7lDh1g

https://youtu.be/nPvUSTDJ45A

Research topic RS : https://is.gd/Dot5CodecGPU https://is.gd/CodecDolby https://is.gd/CodecHDR_WCG https://is.gd/HPDigitalWavelet https://is.gd/DisplaySourceCode

*

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."

ICE-SSRTP GEA Replacement 2022 + (c)RS

ICE-SSRTP GEA Replacement 2022 + (c)RS

"GEA-1 and GEA-2, which are very similar (GEA-2 is just an extension
of GEA-1 with a higher amount of processing, and apparently not
weakened) are bit-oriented stream ciphers."

GEA-2 > GEA-3 is therefor 64Bit Safe (Mobile calls) & 128Bit Safe (Reasonable security)

SHA2, SHA3therefor 128Bit Safe (Reasonable security Mobile) ++

AES & PolyChaCha both provide a premise of 128Bit++

So by reason alone GEA has a place in our hearts.

*

ICE-SSRTP GEA Replacement 2022 + (c)RS

IiCE-SSR for digital channel infrastructure can help heal GPRS+ 3G+ 4G+ 5G+

Time NTP Protocols : is usable in 2G+ <> 5G+LTE Network SIM

ICE-SSRTP Encryption AES,Blake2, Poly ChaCha, SM4, SHA2, SHA3, GEA-1 and GEA-2 

'Ideal for USB Dongle & Radio' in Rust RS ' Ideal for Quality TPM Implementation'

"GEA-1 and GEA-2, which are very similar (GEA-2 is just an extension
of GEA-1 with a higher amount of processing, and apparently not
weakened) are bit-oriented stream ciphers."

IiCE-SSRTP : Interleaved Inverted Signal Send & Receive Time Crystal Protocol

Interleaved signals help Isolate noise from a Signal Send & Receive ...

Overlapping inverted waves are a profile for complex audio & FFT is the result.

Interleaved, Inverted & Compressed & a simple encryption?

Time differentiated : Interleave, Inversion & differentiating Elliptic curve.

We will be able to know and test the Cypher : PRINCIPLE OF INTENT TO TRUST

We know of a cypher but : (Principle RS)

We blend the cypher..
Interleaved pages of a cypher obfuscate : PAL CScam does this

Timed : Theoretically unique to you in principle for imprecision, But we cannot really have imprecise in Crypto!

But we can have a set time & in effect Elliptic curve a transient variable T,
With this, Interleave the resulting pages (RAM Buffer Concept)

Invert them over Time Var = T

We can do all & principally this is relatively simple.

(c)RS

*

Modulus Dual Encrypt & Decrypt package : Processor feature (c)RS

AES-CCM & AES-GCM & Other Cypher Modulus + CCM & GCM can be accelerated with a joint AES Crypto module,

Processor feature & package : Module list:

2 Decryption pipelines working in parallel,
With a Shared cache & RAM Module
Modulus & Semi-parallel modulating decryption & Encryption combined with Encapsulation Cypher IP Protocol packet

Parallax Cryptographic Processing Unit: RS

The capacity To Multiply decryption on specific hardware in situations such as lower Bit precision is to be implemented as follows:

On AES-NI & ARM Cryptographic processors; In particular PSP+PPS(ARM+) & SiMD ..

The capacity to exploit the fact that the nonce is 16Bit to 64Bit & full float upto 128Bit for legal decryption (client) means there is a simple method to use:

In situations that a AES-NI & ARM Cryptographic unit can process 2 threads on a 256Bit Function we can do both the main 128Bit/192Bit & the nonce 16Bit to 64Bit & Enable a single instruction Roll to Synchronise both The main HASH & Nonce.

AES & Crypto hardware can utilise the CPU/GPU/Processor FPU & SiMD to decrypt the nonce (smaller so fast) & in the same 8bto to 64Bits of code; Inline & parallax the cryptographic function.

With a 256Bit AES-NI & Cryptographic unit : Parallel Decryption & Return Encryption by using 2x 128Bit & a Processor Enciphered Nonce.

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

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

AES & Elliptic Hardware Acceleration : AES & SVM along with AVX Micro-block decoding.

ECC Elliptic Curve encrypt is 20% to 40% more efficient than Large Size RSA AES on game packets @ QUICC
512/384/256 AES Elliptic is clearly advantageous because of compression block size on small network packets,

Larger streams such as video clearly favour 2048 Bit RSA AES; With SVM Elliptic feature,

RSA,512, 384 AES Elliptic curve is a clear winner!

(c)Rupert S

*reference*

https://science.n-helix.com/2022/02/interrupt-entropy.html

https://science.n-helix.com/2022/03/ice-ssrtp.html

https://science.n-helix.com/2022/01/ntp.html

Performance Comparison of AES-CCM and AES-GCM Authenticated Encryption Modes
http://worldcomp-proceedings.com/proc/p2016/SAM9746.pdf

Basic comparison of Modes for Authenticated-Encryption -IAPM, XCBC, OCB, CCM, EAX, CWC, GCM, PCFB, CS
https://www.fi.muni.cz/~xsvenda/docs/AE_comparison_ipics04.pdf

*

Example Encryption Results:

gnutls-cli --benchmark-tls-ciphers

Testing throughput in cipher/MAC combinations (payload: 1400 bytes)

AES-128-GCM - TLS1.2 0.56 GB/sec
AES-128-GCM - TLS1.3 0.57 GB/sec
AES-128-CCM - TLS1.2 185.36 MB/sec
AES-128-CCM - TLS1.3 182.74 MB/sec
CHACHA20-POLY1305 - TLS1.2 112.79 MB/sec
CHACHA20-POLY1305 - TLS1.3 111.61 MB/sec
AES-128-CBC - TLS1.0 168.16 MB/sec
CAMELLIA-128-CBC - TLS1.0 53.82 MB/sec
GOST28147-TC26Z-CNT - TLS1.2 15.39 MB/sec

As can be seen:

AES-GCM is
1056x better than Camellia &
508x Better than ChaChaPoly
309x Better than AES-CCM

So what about ChaChaGCM?

RS

*

Example of use:

Nostalgic TriBand : Independence RADIO : Send : Receive :Rebel-you trade marker

Nostalgic TriBand 5hz banding 2 to 5 bands, Close proximity..
Interleaved channel BAND.

Microchip clock and 50Mhz Risc Rio processor : 8Bit : 16Bit : 18Bit
Coprocessor digital channel selector &

channel Key selection based on unique..

Crystal time Quartz with Synced Tick (Regulated & modular)

All digital interface and resistor ring channel & sync selector with
micro band tuning firmware.

(c)Rupert S

*

Good for cables ? and noise ?

Presenting :  IiCE-SSR for digital channel infrastructure & cables

<Yes Even The Internet &+ Ethernet 5 Band>

So the question of interleaved Bands & or signal inversion is a simple

question but we have,

SSD & HDD Cables & does signal inversion help us? Do interleaving bands help us?

In Audio inversion would be a strange way to hear! but the inversion

does help alleviate ...

Transistor emission fatigue...

IiCE-SSRTP : Interleaved Inverted Signal Send & Receive Time Crystal Protocol

Interleaved signals help Isolate noise from a Signal Send & Receive ...

Overlapping inverted waves are a profile for complex audio & FFT is the result.

Interleaved, Inverted & Compressed & a simple encryption?

Good for cables ? and noise ?

Presenting : IiCE for digital channel infrastructure & cables <Yes
Even The Internet &+ Ethernet 5 Band>

(c) Rupert S

*
Given the ZFS Results the strategy to utilize (c)RS

Crypto Storage & RAM Strategy (c)RS

GCM : Accelerated by SVM Elliptic Curve & AES & ARM Crypto-Extensions,
Processor Compression Accelerated,

2 to 64 Blocks,
Header Separated; GZIP, BZip & LZ8 & LZH & Wavelet & Hardware Compression with independent Encrypted Segmentation & Sub-Grouping.

Hash main block group listing & Tables for drive repair and DIR & Access Acceleration.

https://www.medo64.com/content/media/ubuntu-2204-zfs-speed.png
AES-128-GCM - TLS1.2 0.56 GB/sec
AES-128-GCM - TLS1.3 0.57 GB/sec

*

https://science.n-helix.com/2018/12/rng.html

https://science.n-helix.com/2022/02/rdseed.html

https://science.n-helix.com/2017/04/rng-and-random-web.html

https://science.n-helix.com/2022/02/interrupt-entropy.html

https://science.n-helix.com/2021/11/monticarlo-workload-selector.html

https://science.n-helix.com/2022/03/security-aspect-leaf-hash-identifiers.html

Basic comparison of Modes for Authenticated-Encryption -IAPM, XCBC, OCB, CCM, EAX, CWC, GCM, PCFB, CS

Integral to Telecoms Security TRNG

*RAND OP Ubuntu : https://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html

https://pollinate.n-helix.com

*

Audio, Visual & Bluetooth & Headset & mobile developments only go so far:

https://science.n-helix.com/2022/02/visual-acuity-of-eye-replacements.html

https://science.n-helix.com/2021/11/ihmtes.html

https://science.n-helix.com/2022/03/ice-ssrtp.html

https://science.n-helix.com/2021/10/eccd-vr-3datmos-enhanced-codec.html
https://science.n-helix.com/2021/11/wave-focus-anc.html
https://science.n-helix.com/2021/12/3d-audio-plugin.html

*

***** Dukes Of THRUST ******

Nostalgic TriBand : Independence RADIO : Send : Receive :Rebel-you trade markerz

Nostalgic TriBand 5hz banding 2 to 5 bands, Close proximity..
Interleaved channel BAND.

Microchip clock and 50Mhz Risc Rio processor : 8Bit : 16Bit : 18Bit
Coprocessor digital channel selector &

channel Key selection based on unique..

Crystal time Quartz with Synced Tick (Regulated & modular)

All digital interface and resistor ring channel & sync selector with
micro band tuning firmware.

(c)Rupert S

Dev/Random : Importance

Dev/Random : Importance : Our C/T/RNG Can Help GEA-2 Open Software implementation of 3 Bits (T/RNG) Not 1 : We need Chaos : GEA-1 and GEA-2 Implementations we will improve with our /Dev/Random

Our C/T/RNG Can Help GEA-2 Open Software implementation of 3 Bits
(T/RNG) Not 1 : We need Chaos : GEA-1 and GEA-2 Implementations we
will improve with our /Dev/Random

We can improve GPRS 2G to 5G networks still need to save power, GPRS
Doubles a phones capacity to run all day,

Code can and will be improved, Proposals include:

Blake2
ChaCha
SM4
SHA2
SHA3

Elliptic Encipher
AES
Poly ChaCha

Firstly we need a good solid & stable /dev/random

So we can examine the issue with a true SEED!

Rupert S https://science.n-helix.com/2022/02/interrupt-entropy.html

TRNG Samples & Method DRAND Proud!

https://drive.google.com/file/d/1b_Sl1oI7qTlc6__ihLt-N601nyLsY7QU/view?usp=drive_web
https://drive.google.com/file/d/1yi4ERt0xdPc9ooh9vWrPY1LV_eXV-1Wc/view?usp=drive_web
https://drive.google.com/file/d/11dKUNl0ngouSIJzOD92lO546tfGwC0tu/view?usp=drive_web
https://drive.google.com/file/d/10a0E4Gh5S-itzBVh0fOaxS7JS9ru-68T/view?usp=drive_web

https://github.com/P1sec/gea-implementation

"GEA-1 and GEA-2, which are very similar (GEA-2 is just an extension
of GEA-1 with a higher amount of processing, and apparently not
weakened) are bit-oriented stream ciphers."

"A stream cipher, such as the well-known RC4 or GEA-1, usually works
through using the Xor operation against a plaintext. The Xor operation
being symmetrical, this means that encrypting should be considered the
same operation as decrypting: GEA-1 and GEA-2 are basically
pseudo-random data generators, taking a seed (the key, IV and
direction bit of the GPRS data, which are concatenated),

The generated random data (the keystream) is xored with the clear-text
data (the plaintext) for encrypting. Then, later, the keystream is
xored with the encrypted data (the ciphertext) for decrypting. That is
why the functions called in the target library for decrypting and
encrypting are the same.

GEA-1 and GEA-2 are bit-oriented, unlike RC4 which is byte-oriented,
because their algorithms generate only one bit of pseudo-random data
at once (derived from their internal state), while algorithms like RC4
generate no less than one byte at once (in RC4's case, derived from

permutation done in its internal state). Even though the keystream
bits are put together by the current encryption / decryption C and
Rust libraries into bytes in order to generate usable keystream,
obviously.

Based on this, you can understand that GEA-1 and GEA-2 are LFSR:
Linear Feedback Shift Register-oriented ciphers, because their
internal state is stored into fixed-size registers. This includes the
S and W registers which serve for initialization / key scheduling
purposes and are respectively 64 and 97-bit wide registers, and the A,
B, C (and for GEA-2 only D) registers which serve for the purpose of
keystream generation, which are respectively 31, 32, 33 and 29-bit
wide registers.

On each iteration of the keystream generation, each register is
bit-wise rotated by one position, while the bit being rotated from the
left towards the right side (or conversely depending on in which bit
order you internally represent your registers) is fed back to the
algorithm and mutated depending on given conditions. Hence, the

shifted-out bit is derived from other processing, and reinserted,
while being for this reason possibly flipped depending on conditions
depending on bits present at the other side of the given register.

This is the explanation for the name of linear feedback shift register
(shift because of the shift operation required for the rotation, and
linear feedback because of the constant-time transform operation
involved).

The rest of the register may also be mutated at each iteration steps,
as in the case of the GEA-1 and 2, whole fixed Xor sequences (which
differ for each register) may be applied depending on whether the
rotated bit is a 0 or a 1.

Note that a step where the register iterates is called clocking (the
register is clocked), and that the fixed points where the register may
be Xor'ed when the rotated bit becomes a 1 are called taps. The linear
function which may transmute the rotated bit at the clocking step
(taking several bits of the original register as an input) is called
the F function.

Those kind of bit-oriented LFSR algorithms, such as GEA-1 and 2 (for
GPRS) and A5/1 and 2 (for GSM), were designed this way for optimal
hardware implementations in the late 80's and early 90's."

*****

IiCE-SSRTP : Interleaved Inverted Signal Send & Receive Time Crystal Protocol

Interleaved signals help Isolate noise from a Signal Send & Receive ...

Overlapping inverted waves are a profile for complex audio & FFT is the result.

Interleaved, Inverted & Compressed & a simple encryption?

Good for cables ? and noise ?

Presenting :  IiCE-SSR for digital channel infrastructure & cables

<Yes Even The Internet &+ Ethernet 5 Band>

So the question of interleaved Bands & or signal inversion is a simple

question but we have,

SSD & HDD Cables & does signal inversion help us? Do interleaving bands help us?

In Audio inversion would be a strange way to hear! but the inversion

does help alleviate ...

Transistor emission fatigue...

IiCE-SSRTP : Interleaved Inverted Signal Send & Receive Time Crystal Protocol

Interleaved signals help Isolate noise from a Signal Send & Receive ...

Overlapping inverted waves are a profile for complex audio & FFT is the result.

Interleaved, Inverted & Compressed & a simple encryption?

Good for cables ? and noise ?

Presenting : IiCE for digital channel infrastructure & cables <Yes
Even The Internet &+ Ethernet 5 Band>

(c) Rupert S

Security Aspect Leaf HASH Identifiers

VM Virtual Call Frame : Security Aspect Leaf HASH Identifiers : Rupert S

Leaf HASH Identifiers in 16Bit/32Bit/64Bit : RS

With this example in mind 16Bit HASH Values & identifiers make sense.

16Bit HASH Reasoning Table: based upon Leaf HASH Identifiers in 16Bit/32Bit/64Bit

16Bit Leaf HASH, Compatible max RAM) : 4GB Large Page

16 Million HASH groups for identifiers with 128MB RAM per HASH Master group..

256 HASH master Table
256 HASH Per Group

16:32MB up to 4GB(16Bit Leaf HASH, Compatible max RAM) : RAM per group

16Bit Hash identifier tables load into 16KB of processor cache
Load, Save & Store can be done in a higher Bit depth; 32Bit for example
SiMD can operate in Half, Single & Double Float capacity

Micro work loads such as motion & video & 3D Tessellation

*

VM Virtual Call Frame : Security Aspect Leaf HASH Identifiers in 16Bit/32Bit/64Bit : RS

If the CPU Manager can call Compression & Cypher independently on TASK Call,
If the Processor Manager can call from Virtualisation functions for each secure task group.

Security Aspect : With CPU Cache in the 8MB+ Region Leaf HASH Identifiers can be stored:

Compressed if Processor has Compression such as BZip
Encrypted Compressed if Processor has Compression such as AES

In a Secure &+ Work Isolation Container : WIC or SWIC contained L2 (Compress Store Small Identifier List)

In a Secure &+ Work Isolation Container : WIC or SWIC contained L3 (larger identifier lists),

(c)Rupert S

Reference Kernel Security:

https://science.n-helix.com/2021/11/monticarlo-workload-selector.html

https://science.n-helix.com/2022/02/interrupt-entropy.html

https://science.n-helix.com/2018/12/rng.html

https://science.n-helix.com/2022/02/rdseed.html

https://science.n-helix.com/2017/04/rng-and-random-web.html

Leaf HASH Identifier Paths to clear logic:

Performance issues related to handheld would be solved with the use of:

FP16 packed pixel
FP16 background object maths
FP/Int8/4 Machine learning adaptive code...
Compute Shaders
Compression > DOT Image format

With these resources available, We can potentially do more!

https://science.n-helix.com/2019/06/vulkan-stack.html

https://science.n-helix.com/2022/03/fsr-focal-length.html

https://science.n-helix.com/2021/09/temporal-aliasing-image-shaping-polygon.html

https://science.n-helix.com/2022/03/simd-render.html

*

https://science.n-helix.com/2019/06/kernel.html

Trace ID : Kernel & Bios HASH Reference

https://lkml.org/lkml/2022/3/22/446

Jumpless Security HASH

https://lkml.org/lkml/2022/3/22/440

SPE Decode & Encode

https://lkml.org/lkml/2022/3/22/415

IDR Transaction ID's VMBus : HASH

https://lkml.org/lkml/2022/3/22/459

*

As you know in my studies i found that 16x AA rarely has a performance hit on all verified hardware since RX200 3GB (and the RX560) & even the RX5770 1GB.The NVidia 1080 can manage most of this & i optimised Elite Dangerous for the 1080 & RX200 market.


A lot of the performance issues related to handheld would be solved with the use of:

FP16 packed pixel
FP16 background object maths
FP/Int8/4 Machine learning adaptive code...
Compute Shaders
Compression > DOT Image format

With these resources available, We can potentially do more!

*

"Apex Legends : I get the feeling that the lower final precision on the screen output is the result of a 4x Anti Aliasing layer and lower Image compression settings,"

*

Elite Dangerous Reference Videos:https://www.youtube.com/watch?v=JmMQPS_azJA&list=PL8DNvgnwiUU1cezx_Y9DraHjyqJxnrrN7

ML & Game performance improvement https://is.gd/ProcessorLasso

Rupert S

The Handheld market performance ratings are :

Snapdragon (often used & is good)

High quality option based upon Notebook expectations

AMD Chipset
NVidia

My studies concluded that both NVidia and AMD have little to worry about AA performance upto 16x and it makes almost no performance advantage to use less in my performance tuning...

I am frequently in possession of older hardware; Like many users i cannot always afford all the best gear,

However there are examples of things that make a bigger hit:

16x tessellation rarely causes a problem (RX200 3GB+)24 & 32 both dynamically jiggle FPS around heavy asteroids & space stations in frontier elite..

but looks amazing!

Multisampling is manageable at 2x on RX200 on elite dangerous

(a quite intense graphic space MMO)
4x MultiSampling does involve a 20% frame rate drop, Quality is preferred but i went for 2x as it rarely causes issues.

Texture Image compression format optimisation is a priority NO.1 Priority..

You save a lot of space & heavy usage of DOT 1 > 5 compression management is advised..
10Bit sampling is perfectly logical.

https://www.nintendolife.com/news/2021/03/video_check_out_this_side-by-side_comparison_of_apex_legends_running_on_switch_and_ps4_pro

https://www.youtube.com/watch?v=uGrPwt_KHRE

Elite Dangerous 64Bit PvP Arena DeathMatch 4Q 2xMultiSampling.mp4 (93.26 MB) https://mirrorace.org/m/6qr3y

Elite Dangerous 64 Sub.FM Rastafari PvP 2016-04-23 19-27-22-552.mp4 (89.27 MB) https://mirrorace.org/m/54waA

EliteDangerous - CQC PvP Arena - Bloody is the bath of kings - 2016-05-05 14-30-27-909.mp4 (277.04 MB) https://mirrorace.org/m/3IO7p

yes cloudflare apex_eoso.nx7v.icu apex_eu.nx7v.icu apex_wes.nx7v.icu apex_eas.nx7v.icu

USA: pop: apex_sv1.nx7v.icu apex_sv2.nx7v.icu apex_sv3.nx7v.icu

*