cheezwiz7899 d87f1241c9 video_core: bindless texture correctness and performance
Fix texture corruption caused by the shader compiler treating unknown
constant buffer sizes as 0 instead of the bindless array length:
- Set BINDLESS_FALLBACK_LENGTH = BINDLESS_ARRAY_LENGTH (1024) in
  texture_pass.cpp so shaders always allocate the full descriptor range
- Pre-capture cbuf sizes in GraphicsEnvironment/ComputeEnvironment
  constructors and serialize them through FileEnvironment to prevent
  intermittent 0-size reads from async worker threads
- Bump CACHE_VERSION to 14 to force one-time recompile of existing
  shader caches with the corrected metadata
- Reduce MAX_IMAGE_ELEMENTS from 16384 to 1024 to eliminate TLS
  pressure caused by the oversized per-thread descriptor array

Add BindlessCache (64 entries, round-robin eviction) keyed on
(cbuf_addr, count, image_table_generation) to skip redundant GPU memory
reads across draws:
- Track image_table_generation in each cache entry; a generation mismatch
  forces a full re-read and re-resolve, a match replays cached views
- Mark resolved ImageViewInOuts with id_cached so FillImageViews can
  skip VisitImageView for already-resolved entries
- Add GraphicsImageTableGeneration() / ComputeImageTableGeneration()
  accessors to DescriptorTable and expose them from TextureCache

Deduplicate PrepareImageView calls for cached bindless entries:
- On a cache hit, FillImageViews was calling PrepareImageView once per
  descriptor slot (up to 1024 calls/draw). Replace with a batch pass
  that collects unique ImageIds from id_cached views, deduplicates via
  sort+unique, then calls PrepareImage once per unique image (~10-50x
  fewer calls in practice)
2026-05-07 03:25:44 -04:00
2026-03-17 05:47:57 +00:00
2026-05-03 06:50:06 +00:00
2026-05-03 06:50:06 +00:00
2024-01-08 09:34:32 -05:00
2026-03-16 14:45:07 +10:00
2026-03-17 02:33:03 +00:00
2023-11-04 18:26:49 +00:00
2026-03-17 19:34:43 +00:00
2026-04-27 05:51:26 +00:00
2025-10-03 15:05:41 +10:00
2026-03-28 03:10:26 +00:00

Citron Neo

what

Feel free to open issues and PRs to the repository.

Enjoy!













































































































































































































Abstract

Citron is a specialized research software designed to orchestrate high-fidelity virtual environments. Unlike general-purpose tools, it focuses on the intersection of containerization and deep-system virtualization to provide researchers with granular control over network behavior and resource management. Core Capabilities

High-Fidelity Networking: Citron creates Docker container environments where network accuracy is the priority. It ensures that latency, throughput, and topology mirror real-world conditions with high precision, making it ideal for testing distributed systems or network protocols.
Hybrid Orchestration: Beyond containers, it can spawn and manage multiple Virtual Machines (VMs) simultaneously. This allows for heterogeneous testing environments where containers and VMs interact seamlessly.
Kernel Addressing: The software utilizes advanced kernel addressing techniques for resource management. By interacting closely with the host and guest kernels, Citron achieves low-overhead monitoring and advanced control over virtualized assets that standard management layers often miss.

Summary Citron is a technical powerhouse for researchers who need more than just "standard" virtualization. It bridges the gap between the lightweight agility of Docker and the robust isolation of VMs, all while maintaining a rigorous, high-fidelity network layer managed through direct kernel-level operations. Would you like to draft a README file or a technical abstract for a research paper based on this?

Citron functions as a high-fidelity hardware-software co-design platform that bridges the gap between high-level container orchestration and low-level embedded hardware constraints. By integrating specialized architectures like Xtensa cores, Citron allows researchers to simulate and manage complex system-on-chip (SoC) behaviors within a virtualized framework.

  1. Integration with Specialized Hardware (Xtensa Cores) Citron addresses the unique constraints of Xtensa processors, which are modular, extensible 32-bit RISC architectures often used in networking and audio processing.

    Custom Instruction Support: Citron can leverage the Tensilica Instruction Extension (TIE) language to simulate custom datapath elements and instructions within the virtualized environment. Protocol-Specific Optimization: Because Xtensa cores excel at processing packet headers and rule-based checks, Citron uses them to maintain network fidelity—ensuring that simulated network stacks perform with the same cycle-accurate behavior as physical networking chips.

  2. High-Fidelity Computing Devices To achieve "high fidelity," Citron must manage the deterministic performance of computing devices, ensuring that virtualized sensors and actuators respond within real-world timing constraints.

    Cycle-Accurate Modeling: It utilizes an Instruction Set Simulator (ISS) to provide instant feedback on how software interacts with the underlying hardware pipeline, preventing the "timing drift" common in standard VMs. Resource Determinism: Citron mitigates hardware constraints—such as limited memory and power—by tailoring the virtual environment to match the specific cache sizes and memory hierarchies of the target device.

  3. Advanced Kernel Addressing and Management Citrons specialization in kernel addressing allows it to bypass traditional virtualization overhead:

    Direct Register Access: By interacting with the Application Binary Interface (ABI), Citron manages how programs interact with the kernel, allowing for precise debugging and resource allocation across multiple spawned VMs. Kernel-Level Hypervisors: It functions similarly to a KVM (Kernel-based Virtual Machine), turning the host Linux system into a high-performance hypervisor that provides near-native execution of privileged instructions. Memory Lookup Interfaces: Citron can connect directly to arbitrary-width memories or RTL (Register Transfer Level) blocks for low-latency data transfers, effectively treating virtualized memory as if it were a direct point-to-point hardware connection.

  4. Technical Constraints & Architecture Feature Implementation in Citron Processor Type Supports 32-bit configurable RISC/Xtensa architectures. Virtualization Method Hardware-assisted virtualization using extensions like Intel VT-x or AMD-V for direct execution. Networking Layer High-fidelity emulation that avoids standard I/O bottlenecks by using custom processor interfaces. Management Centralized synchronization controller for container scheduling and I/O compensation. Would you like to explore how Citron handles specific network protocols like CoAP or MQTT on these virtualized Xtensa cores?

S
Description
No description provided
Readme GPL-3.0 157 MiB
Languages
C++ 63.2%
cpp 31%
Kotlin 2.6%
CMake 1.2%
Shell 1.1%
Other 0.7%