Auf DHGate bekommt man gerade den 5500X3D mit Versand aus Spanien deutlich unter 200€ (Neu, Tray). Ist nicht optimal aber könnte für einige interessant sein.

https://www.mydealz.de/deals/5500x3d...panien-2777958

Prompt: Design a PS6
Spoiler Design a PS6 hardware + software ecosystem under the following constraints and ideas:

1. Core philosophical direction
The console should be based on a pure streaming architecture
RAM is treated as a high-speed cache layer, not primary storage
SSD behaves like a hierarchical virtual memory system
Everything is driven by chunk-based streaming of world data
2. Key architectural concept

The system should extend into:

predictive streaming
memory graph systems
decompression pipelines
real-time asset streaming from SSD to GPU

The goal is:

“The OS is a scheduler of future memory states, not just processes.”

3. Design task 1 — Hardware spec

Design a PS6 hardware architecture optimized for this streaming OS, including:

CPU design (stream-aware)
GPU design (streaming-first rendering model)
RAM role and size
VRAM role
SSD role (bandwidth + architecture)
dedicated hardware blocks (decompression, prediction, streaming controller)

You must consider:

current high cost of RAM and SSDs
need for PS5-level or better performance
realistic consumer price constraints

Explain trade-offs, especially if a $299 retail price is impossible.

4. Design task 2 — Operating system kernel

Design a console OS kernel that implements this architecture.

It must include:

A. Memory Graph System (MGS)
world data represented as a probabilistic graph of chunks
edges represent likely future access
B. Stream Scheduler Core
predicts what data is needed next
schedules SSD → RAM → GPU pipeline
C. RAM Cache Orchestrator
RAM as a sliding prediction window
aggressive eviction model
D. SSD Virtual Memory Layer
SSD behaves like structured memory storage, not file system
chunk-addressable world state system
E. GPU execution model
GPU receives pre-resolved “frame bundles”
no direct asset requests from GPU
5. Design requirements
Everything must be real-time and deterministic for gaming
Streaming must be predictive, not reactive
Must avoid frame stalls via fallback LOD/procedural systems
Must explain why SSD cannot fully replace RAM despite high speeds
6. Output expectations

Provide:

hardware spec
OS kernel architecture
memory hierarchy model diagram (textual is fine)
streaming pipeline explanation
explanation of trade-offs vs traditional console design
dolaAI
Spoiler # PlayStation 6 (PS6) Ecosystem Design
**Release Target**: Holiday 2028 | **Core Architecture**: Pure Streaming | **Base Price Target**: $399 (justified below; $299 is not feasible)

---

## Core Philosophy Recap
- RAM = high-speed cache, **not primary storage**
- SSD = hierarchical virtual memory, not just a storage drive
- All game data = chunk-based streamed world state
- OS = scheduler of *future memory states*, not just process manager

---

## 🧩 Design Task 1 — Hardware Specification
Optimized entirely for predictive streaming, balancing performance, cost, and console-grade reliability.

### 📌 Key Constraints Applied
- Maintain **PS5+ performance** (4K60 native, 8K30, ray tracing, global illumination)
- Manage high RAM/SSD costs: use smaller, faster memory pools + high-density, high-bandwidth SSD
- Consumer price ceiling: $399 (**$299 is impossible** — detailed trade-off below)

---

### 🖥️ Full Hardware Architecture

#### 1. CPU: Stream-Aware Multi-Core
- **Design**: Custom AMD Zen 6 (6nm) — 8 cores / 16 threads, **stream-optimized ISA extensions**
- New instructions: `PRED_LOAD`, `CHUNK_SCHED`, `GRAPH_WALK` — built to traverse memory graphs and schedule data flow directly
- 3.5 GHz base / 4.2 GHz boost; SMT enabled but optimized for task-level parallelism (not thread count)
- **Role**:
- Does **not** load or hold assets; only orchestrates streaming logic, updates memory graphs, and schedules pipelines
- Offloads all decompression/transfer to dedicated hardware
- **Trade-off**: Fewer cores vs PC; higher per-core efficiency + streaming-specific logic = better real-time determinism

#### 2. GPU: Streaming-First Rendering Model
- **Design**: Custom AMD RDNA 5 (5nm) — **36 Compute Units (CU)**, 2.5 GHz, 23 TFLOPS FP32
- **Critical change**: No asset fetch logic inside GPU. It only receives *complete frame bundles* (geometry, textures, shaders, materials) already arranged in GPU-accessible cache
- Hardware features: Ray tracing 3.0, mesh shaders, variable rate shading, **streamed texture sampling units**
- Dedicated command processor that accepts only pre-built command buffers from the OS — no direct memory requests
- **Role**: Pure execution engine; no latency caused by waiting for data
- **Performance**: 2× PS5 ray tracing performance; native 4K60 stable; supports 8K30 with dynamic resolution

#### 3. RAM: High-Speed Cache Layer
- **Size**: **16 GB GDDR7** (256-bit bus, 1.5 TB/s bandwidth)
- **Role**: **Sliding prediction window cache**, not main memory
- Holds *only* data predicted to be used in the next 2–8 frames + current working set
- Divided into:
- 12 GB → Shared cache (CPU + GPU visible)
- 4 GB → Priority prediction buffer (locked for high-probability chunks)
- **Why not 32 GB?**
- GDDR7 cost is ~$12/GB at launch → 32 GB = $384 just for RAM; impossible for <$500 pricing
- With perfect prediction + fast SSD, 16 GB is sufficient (proven by PS5’s 16 GB + fast SSD)
- **Eviction rule**: Aggressive LRU + probability-based eviction — lowest-likelihood chunks removed first

#### 4. VRAM: Unified, No Separate Pool
- **Model**: **Unified Memory Architecture (UMA)** — same 16 GB GDDR7 serves as both system cache and GPU cache
- **Difference from PS5**: GPU cannot allocate or request memory; OS assigns regions *only as part of a stream bundle*
- **Benefit**: No split memory overhead; all bandwidth usable for streaming/rendering

#### 5. SSD: Hierarchical Virtual Memory
- **Spec**: **2 TB Custom NVM Express 4.0 SSD**
- **Bandwidth**: 14 GB/s sequential | 7 GB/s random (4K chunks) — **3× PS5 speed**
- **Architecture**:
- **Chunk-addressable**: No file system; addressed by `[World ID → Chunk ID → Version]`
- **Tiered storage inside SSD**:
- Tier 0: On-SSD SRAM (256 MB) → hottest chunks, zero-latency access
- Tier 1: High-speed NAND → active world data
- Tier 2: Background NAND → low-priority/historical data
- **Controller**: Integrated streaming logic — understands memory graph requests directly
- **Role**: **Primary storage + virtual memory** — all game state, assets, code, physics data lives here permanently
- **Why SSD cannot replace RAM**:
1. **Latency gap**: SSD = ~100µs → RAM = ~10ns → **10,000× faster**; even fastest SSDs cannot match random access latency
2. **Determinism**: SSD access times vary; RAM is fixed-latency — critical for no frame drops
3. **Bus contention**: SSD-to-GPU transfer takes bandwidth; active rendering needs zero-wait access
4. **Processing**: Decompression + graph updates require working space RAM

#### 6. Dedicated Hardware Blocks (Fixed-Function)
| Block | Purpose | Spec |
|---|---|---|
| **Streaming Controller Unit (SCU)** | Runs prediction algorithms, traverses memory graphs, schedules data movement | 2 dedicated cores, 512 KB SRAM; bypasses CPU for 0.1µs scheduling |
| **Decompression Engine v3** | Real-time decompression of all streamed chunks — hardware-only, no CPU load | 20 GB/s throughput; supports custom lossless + lossy formats (ratio 10:1–40:1) |
| **LOD + Procedural Generator** | Fallback system — generates simplified assets instantly if prediction fails | Hardware mesh/texture synthesis; <1ms response |
| **Memory Graph Engine** | Updates probability edges, tracks access history, maintains chunk relationships | 128 MB internal cache; updates graph in background |

---

### 💵 Price & Trade-off Justification
- **Bill of Materials (BOM) Estimate**: ~$270–$290
- CPU/GPU: ~$90 | RAM: ~$100 | SSD: ~$50 | Other: ~$40
- **Retail Price**: **$399**
- *Why not $299?*
- Current RAM/SSD tech costs make BOM >$270; selling at $299 = loss per unit — unsustainable for 5–7 year lifecycle
- $399 matches PS5 launch price; allows profit margin + room for cost reductions later
- **Trade-offs made**:
- 16 GB instead of 24/32 GB RAM → offset by perfect prediction + 14 GB/s SSD
- 2 TB instead of 4 TB → games use ~100–200 GB; chunked streaming means you never load full game at once
- Fixed-function hardware instead of general-purpose → better real-time performance, lower power, lower cost

---

## 🧠 Design Task 2 — Operating System Kernel
**Name**: PlayStation Stream Kernel (PS-SK)
**Core Principle**: *OS = scheduler of future memory states*, not just process manager

---

### A. Memory Graph System (MGS) — Core Data Model
All game world data is represented as a **probabilistic directed graph**:
- **Nodes = Chunks**: 64 KB–2 MB blocks (geometry, textures, audio, physics, AI state, code)
- **Edges = Access Probability**: `P(A→B) = likelihood chunk B is needed after chunk A`
- Updated in real-time by observing player movement, camera direction, game logic, and historical data
- **Properties**:
- Graph is dynamic: new chunks added as world expands; old ones marked low-priority
- Supports versioning: edges track *when* data will be needed (0–100ms, 100–500ms, >500ms)
- **Example**: If player turns 45° right → edges for chunks to the right get probability boosted from 20% → 90%

### B. Stream Scheduler Core
The brain of the OS — **predictive, not reactive**
1. **Prediction Window**: 8–16 frames ahead (~130–270ms at 60 FPS)
2. **Workflow**:
- Step 1: SCU + Memory Graph Engine scan edges → identify *high-probability future chunks*
- Step 2: Calculate required arrival time → schedule SSD read + decompression + transfer
- Step 3: Coordinate pipeline: `SSD → Decompressor → RAM Cache → GPU Frame Buffer`
- Step 4: Adjust schedule every 1ms — adapt to sudden changes (player jumps, turns, teleports)
3. **Determinism Guarantee**: All scheduled transfers complete *before* needed; no blocking calls

### C. RAM Cache Orchestrator
Manages RAM as a **sliding prediction window**:
- **Allocation Policy**:
- Chunks sorted by `(Probability × Urgency)`
- Only top 16 GB worth of chunks stay in RAM
- Splits RAM into:
- *Active Set*: Current frame + next 2 frames
- *Prediction Set*: Frames 3–16 (highest probability)
- *Free Pool*: Reserved for emergency fallback
- **Eviction Model**:
- **Hard Eviction**: Remove chunks with <5% probability OR not accessed in >500ms
- **Soft Eviction**: Demote to SSD Tier 0 (fast cache) instead of deleting — instant reload possible
- **Rule**: **Game code cannot pin memory**; OS controls *all* cache residency

### D. SSD Virtual Memory Layer
Replaces file system — **SSD = structured memory, not storage**
- **Addressing**: Flat address space: `Chunk Address = [World:4b][Sector:16b][Index:24b][Version:8b]`
- **Hierarchy Management**:
- Tier 0 (SSD SRAM): Holds *most likely next 100 chunks* — preloaded by scheduler
- Tier 1: Active world data — read at 14 GB/s
- Tier 2: Background/remote data — lower priority, read when bandwidth free
- **Swap Model**: No traditional page files; chunks are moved between SSD tiers and RAM as probabilities change
- **Key Feature**: **Zero-copy transfer** — decompressed data flows directly from SSD → RAM → GPU without CPU copy

### E. GPU Execution Model
**Strict separation of concerns**:
1. OS prepares **Frame Bundles** 2–4 frames in advance
- Each bundle contains: all geometry, textures, shaders, commands, and constants needed for that frame
- Bundles are stored in pre-reserved GPU cache regions
2. GPU only:
- Reads complete bundles
- Executes rendering
- Writes results to display buffer
3. **No direct GPU memory requests** — eliminates stalls from texture fetch, shader load, or asset miss
4. **Fallback Mechanism**: If prediction misses → OS injects **procedural LOD assets** in <1ms; no visual drop or frame skip

---

## 📊 Memory Hierarchy Model (Textual Diagram)
```
[ GAME WORLD STATE ]
↓
[ SSD: Tier 2 (Low Priority) ] ← Slow background reads
↓
[ SSD: Tier 1 (Active Data) ] ← 14 GB/s read
↓
[ SSD: Tier 0 SRAM (Hot Chunks) ] ← Zero-latency SSD cache
↓
[ DECOMPRESSION ENGINE ] ← 20 GB/s, hardware-only
↓
[ RAM: 16 GB GDDR7 — Sliding Prediction Cache ]
├─ Active Set: Current + Next 2 Frames
├─ Prediction Set: Frames 3–16
└─ Priority Buffer: Critical assets
↓
[ GPU: Pre-built Frame Bundles ]
↓
[ RENDER OUTPUT → DISPLAY ]
```

---

## 🔄 Full Streaming Pipeline
1. **Predict** — Memory Graph updated by player input, camera, AI, physics → scheduler selects chunks needed in 10–200ms
2. **Schedule** — SCU assigns bandwidth, calculates exact delivery time, prioritizes critical assets
3. **Fetch** — SSD reads chunks from correct tier → direct to decompressor
4. **Decompress** — Hardware engine decodes to raw data; format optimized for streaming (smaller size = faster transfer)
5. **Cache** — Data placed in correct RAM region; evict low-probability chunks
6. **Bundle** — OS assembles all data for next frames → GPU-ready bundles
7. **Execute** — GPU renders from bundles; no waiting
8. **Learn** — Graph engine updates probabilities based on actual usage → improves future predictions

---

## ⚖️ Trade-offs vs Traditional Console Design

### ✅ Advantages of PS6 Streaming Architecture
- **Near-infinite virtual memory**: 2 TB SSD = effectively unlimited RAM; games can have seamless open worlds without loading screens
- **Faster load times**: <0.5s load times; no texture pop-in
- **Better performance predictability**: Deterministic pipeline = stable frame rate always
- **Lower memory cost**: Smaller RAM pool + fast SSD = same or better experience vs 32 GB RAM at lower cost
- **Future-proof**: Scales to 4K/8K, ray tracing, and larger worlds without hardware changes

### ⚠️ Disadvantages & Trade-offs
- **Developer complexity**: Must design games around chunk-based graphs; cannot use traditional memory allocation
- **Higher SSD cost**: Custom high-speed SSD more expensive than standard drives
- **Prediction dependency**: Bad prediction = temporary lower LOD; requires good algorithms
- **No user-upgradable RAM**: Fixed cache size — future games must optimize for 16 GB

### ❓ Why Not Traditional Design?
Traditional consoles: RAM = primary storage, SSD = file cache → **wastes RAM on unused data** and relies on *reactive* loading → stalls, pop-in, and limits world size.

PS6 design: RAM = cache, SSD = memory → **always load what you need, when you need it** — removes all limits from memory size.

Gemini
Spoiler This is an exceptional and highly forward-thinking architectural prompt. Shifting the console paradigm from a "load and store" model to a "pure predictive streaming" model fundamentally changes how games are developed and played.

By treating the OS as a **scheduler of future memory states**, we eliminate traditional loading screens, loading corridors, and memory bloat, focusing instead on throughput and deterministic execution.

Here is the design for this next-generation PS6 ecosystem.

---

### **1. Hardware Specification: The "Stream-First" Console**

To achieve pure streaming, we must reallocate the hardware budget. Instead of buying massive pools of expensive RAM, we invest in ultra-high-bandwidth I/O, custom silicon for prediction, and top-tier SSD speeds.

*Note on the $299 Price Constraint:* **A $299 retail price is currently impossible** without massive loss-leading. High-speed NAND flash (PCIe 6.0 speeds) and custom ML prediction silicon are expensive. A realistic target is **$499**. To hit $299, Sony would have to compromise SSD capacity (e.g., 512GB) and rely on a slower, unified GDDR6 pool, which bottlenecks the "pure streaming" philosophy. Therefore, this spec targets a $499 premium architecture that maximizes the streaming paradigm.

* **CPU (Stream-Aware):** Custom 8-Core Zen-based (or ARM-v9) processor.
* *Role:* 6 cores are dedicated to game logic and physics. 2 cores are **hardware-locked** to the OS Stream Scheduler.
* *Design:* Heavy focus on branch prediction and minimal cache latency. The CPU does not wait for assets; it only calculates state.


* **GPU (Streaming-First):** Custom RDNA/Next-Gen architecture.
* *Role:* Operates on a **strict push model**. It does not request assets. It simply executes "Frame Bundles" (pre-packaged geometry, textures, and shaders) handed to it by the OS.
* *Hardware:* Massive ALU count dedicated to procedural generation and hardware ray-tracing, serving as a fallback mechanism if high-fidelity data prediction misses.


* **RAM (The Sliding Window):** 16GB Ultra-Fast GDDR7 (Unified).
* *Role:* Strictly a high-speed cache. It holds *only* the data needed for the next 2 to 5 seconds of gameplay. 12GB is allocated for the active and predicted Frame Bundles; 4GB is reserved for OS and the Memory Graph.


* **SSD (Hierarchical Virtual Memory):** 2TB Custom PCIe 6.0 NVMe.
* *Bandwidth:* 14+ GB/s raw, peaking at 30+ GB/s compressed.
* *Role:* Acts as primary memory. It bypasses traditional file systems entirely, functioning as a block-addressable NVRAM layer.


* **Dedicated Hardware Blocks:**
* **NPU (Neural Prediction Unit):** Evaluates player telemetry (input velocity, camera vectors) against the game's Memory Graph to predict the next required chunks.
* **Decompression Engine (Kraken vNext):** Can decompress streaming chunks in real-time at 30 GB/s without touching the CPU.
* **DMA Streaming Controller:** A custom Direct Memory Access controller that routes data from SSD $\rightarrow$ Decompression $\rightarrow$ RAM $\rightarrow$ GPU Cache completely autonomously.



---

### **2. Operating System Kernel: The "Chronos" Architecture**

The OS kernel must operate deterministically. It doesn't manage inactive background processes; it orchestrates the future.

#### **A. Memory Graph System (MGS)**

Games are no longer compiled as a series of files (meshes, textures). They are compiled as a **probabilistic directed graph** of fixed-size chunks (e.g., 64KB pages).

* **Nodes** are physical locations or game states.
* **Edges** represent the probability of the player moving from State A to State B. The MGS continuously updates these weights based on player input (e.g., if the player is sprinting forward, the nodes "behind" them drop to a near 0% probability).

#### **B. Stream Scheduler Core**

This is the heart of the OS. It operates at $t - 1$ second. By reading the NPU's probabilities from the Memory Graph, the Scheduler issues read commands to the SSD for chunks the player *will* need shortly. It packages these chunks into "Frame Bundles" and stages them in RAM.

#### **C. RAM Cache Orchestrator**

Operates an **Aggressive Eviction Model**. RAM is a sliding window moving through the Memory Graph. The millisecond a chunk's probability drops below a safety threshold (e.g., the player turns 180 degrees), that chunk is evicted from RAM. There is no garbage collection; memory is treated as a continuous ring buffer overwritten by the future.

#### **D. SSD Virtual Memory Layer**

The SSD abandons traditional file formats (like exFAT or custom game files). It acts as a chunk-addressable world state. When a developer builds a game, the engine maps the world directly to physical hardware blocks on the SSD. The OS addresses the SSD exactly like it addresses RAM, just with a higher latency tolerance handled by the Scheduler.

#### **E. GPU Execution Model**

The GPU never asks, "Where is the texture for this wall?" The OS pushes a completed Frame Bundle into the GPU's L2 cache. If the bundle is there, the GPU renders it. If it isn't, the GPU immediately falls back to procedural generation.

---

### **3. The Predictive Streaming Pipeline & Fallback System**

Because everything is real-time, **stalls are unacceptable**. If the player behaves unpredictably (e.g., snapping the camera 180° instantly), the predictive stream will "miss."

**The Pipeline:**

1. **Telemetry:** NPU tracks camera vector and player velocity.
2. **Prediction:** MGS identifies the next 5 likely chunks.
3. **Fetch & Unpack:** DMA Controller pulls chunks from SSD $\rightarrow$ Decompressor $\rightarrow$ RAM.
4. **Resolution:** OS builds the Frame Bundle and pushes it to the GPU.

**The Fallback Mechanism:**
If a prediction miss occurs, the SSD cannot fetch the data fast enough for the *current* frame (which needs data in $\sim16ms$). To prevent stuttering, the OS commands the GPU to render a **Procedural LOD**.

* The GPU uses its ALUs to generate low-polygon, algorithmic textures (like a high-fidelity blur or a nanite-style proxy) based on a tiny, always-resident global base-mesh.
* This lasts for exactly 2-3 frames ($\sim50ms$) until the DMA controller successfully fetches the high-fidelity chunk from the SSD, fading it in seamlessly.

---

### **4. Memory Hierarchy Model Diagram**

```text
[ PLAYER INPUT & TELEMETRY ]
│
▼
[ NEURAL PREDICTION UNIT (NPU) ] ── Evaluates Probabilities ──┐
│ │
▼ ▼
[ MEMORY GRAPH SYSTEM (OS) ] [ STREAM SCHEDULER ]
│ │
│ ┌───────────────────────────────────────────────┴────────┐
▼ ▼ │
[ SSD VIRTUAL MEMORY (2TB) ] │
(Chunk-Addressable State) │
│ │
▼ (14-30 GB/s) │
[ HARDWARE DECOMPRESSION ] │
│ │
▼ ▼
[ RAM CACHE ORCHESTRATOR ] ◄──── (Sliding Prediction Window) ──── [ RAM 16GB ]
│ (Aggressive Eviction)
▼
[ PRE-RESOLVED FRAME BUNDLES ]
│
▼
[ GPU EXECUTION (Streaming-First) ] ──► (Procedural Fallback if Bundle Misses)
│
▼
[ DISPLAY ]

```

---

### **5. Why SSD Cannot Fully Replace RAM**

Despite PCIe 6.0 speeds, an SSD cannot act as the *direct* execution memory for the GPU/CPU for three distinct reasons:

1. **Latency (The Speed of Light constraint):** RAM latency is measured in nanoseconds ($\sim50-100$ ns). NVMe SSD latency, even optimized, is measured in microseconds ($\sim10-20$ $\mu$s). A GPU rendering at 60fps or 120fps cannot afford microsecond waits for texture sampling; it would cause catastrophic frame drops.
2. **Addressing Granularity:** GPUs need to fetch highly specific, tiny pieces of data (e.g., a few bytes for a texel or vertex). SSDs read/write in blocks (typically 4KB). Fetching a 4KB block every time the GPU needs a 4-byte texel would clog the bus instantly.
3. **Flash Endurance (TBW - Terabytes Written):** If the OS used the SSD exactly like RAM (constantly swapping data in and out every few milliseconds), the physical NAND flash cells would degrade and die within a matter of weeks due to write-amplification. RAM is volatile and has infinite read/write endurance; SSDs do not.

### **Trade-Offs vs. Traditional Console Design**

| Feature | Traditional Console (PS5) | Pure Streaming OS (PS6 Concept) |
| --- | --- | --- |
| **Asset Loading** | Reactive (Wait for data to load into RAM). | Predictive (Data is there before you need it). |
| **RAM Capacity** | Needs high capacity (16GB+) to store entire levels to avoid loading screens. | Can survive on lower capacity (16GB max) because it only holds the next few seconds of time. |
| **World Design** | Restricted by RAM limits (requires hidden loading corridors/elevators). | Infinite. Scalable based purely on SSD storage size. |
| **Engine Compatibility** | Easy porting from PC (Unreal, Unity). | **Difficult.** Requires fundamental rewrites of third-party game engines to support probabilistic chunk streaming. |

This architecture would create the most fluid, open, and visually dense gaming experiences in history, but it shifts the engineering burden entirely onto prediction accuracy and engine compatibility.

Given how disruptive this architecture would be to third-party developers using traditional engines like Unreal or Unity, how would you design the developer tools (SDKs) to help them port their games to a probabilistic chunk-streaming model without having to rebuild their games from scratch?
GwenAI
Spoiler # PS6 Streaming Architecture: Hardware + OS Ecosystem

## 1. Hardware Specification
The PS6 hardware abandons the traditional "storage → load → RAM resident" paradigm. Instead, it treats the SSD as the primary virtual address space and RAM as a high-bandwidth predictive cache. All silicon is co-designed to minimize cache miss penalties and guarantee deterministic frame delivery.

| Component | Specification & Streaming Role |
|-----------|--------------------------------|
| **CPU** | 8-core Zen 6-performance + 2 dedicated **Stream Cores**. Main cores handle game logic, AI, physics. Stream Cores run the OS scheduler, traverse the Memory Graph, and execute lightweight predictive inference. Hardware support for speculative graph traversal and atomic residency updates. |
| **GPU** | Custom RDNA 6 streaming-first architecture. Tile/cluster-optimized for continuous chunk residency. Includes **Frame Bundle Assembler** hardware unit that packs command streams + texture/mesh handles into deterministic batches. Supports hardware ray tracing, VRS 2.0, and mesh shading 2.1. |
| **RAM** | 16GB GDDR7 (800 GB/s peak). **Role:** Unified physical memory, logically partitioned as a sliding prediction cache. Not primary storage; acts as a zero-copy staging buffer between SSD and GPU/CPU. Aggressively recycled via probabilistic eviction. |
| **VRAM** | 12GB subset of the 16GB GDDR7, directly mapped to GPU page tables. Holds only chunk data required for the current frame + predicted 1–3s lookahead. Managed by the RAM Cache Orchestrator to guarantee 100% residency during frame execution. |
| **SSD** | 1TB Custom PCIe 6.0 x4 NVMe. Raw: 18 GB/s. With hardware decompression: 36–40 GB/s effective. **Role:** Hierarchical virtual memory. Chunk-addressable (256KB blocks). No traditional filesystem; exposed as a flat memory-mapped address space to the OS. |
| **Dedicated Silicon** | • **MGS-X Prediction Engine:** Hardware graph-traversal coprocessor + lightweight temporal Markov/transformer predictor. <2ms lookahead computation.<br>• **DMA-X Streaming Controller:** 8-channel zero-copy DMA with priority arbitration and direct RAM↔VRAM routing.<br>• **CODEC-X Decompression Pipeline:** Multi-format hardware decoder (Kraken++, BC7/ASTC, mesh/geometry codecs, custom engine formats). 150 GB/s peak throughput. |

**Cost & Price Reality:** A $299 retail price is architecturally impossible. The custom memory controller, GDDR7, PCIe 6.0 NAND, and dedicated silicon add ~$90–$120 BOM over a conventional console. A realistic launch MSRP is **$499–$549**. Cost reductions could include: 12GB total RAM (tightens cache margins), standardized PCIe 5.0 SSD (drops bandwidth to ~14 GB/s), or moving MGS traversal fully to software (increases CPU overhead and prediction latency). The chosen spec prioritizes deterministic streaming over raw TFLOPS, shifting performance from brute-force rendering to architectural predictability.

---

## 2. Operating System Kernel Architecture

The kernel is explicitly designed around the principle: *“The OS is a scheduler of future memory states, not just processes.”* It replaces reactive I/O with proactive memory orchestration.

### A. Memory Graph System (MGS)
- **Structure:** Probabilistic directed acyclic graph where each node = a 256KB world chunk (geometry, textures, audio, physics, shaders). Edges = likely traversal paths, weighted by `P(access)` and `Δt` (time until expected access).
- **Updates:** Driven by camera vectors, player velocity, scripted triggers, AI pathing, and engine hints. Lightweight on-device ML continuously refines edge weights.
- **Determinism:** Graph updates are batched per frame and applied during V-Sync overlap to avoid mid-frame mutation.

### B. Stream Scheduler Core
- Runs on Stream Cores. Consumes MGS and outputs a **Lookahead Queue** (2–5 seconds ahead).
- Prioritizes chunks using: `Score = P(access) × (1 / Δt) + PriorityFlag (cinematic, gameplay-critical) + FallbackReadiness`.
- Schedules the SSD → RAM → VRAM pipeline via hardware DMA queues. Enforces hard deadlines to prevent frame stalls.
- On prediction miss or latency spike, automatically triggers fallback LOD meshes or procedural generation stubs.

### C. RAM Cache Orchestrator
- Implements a **sliding prediction window** across the 16GB cache.
- **Eviction Policy:** `Temporal Decay + Access Frequency + Graph Centrality + Predicted Miss Penalty`. Chunks with low centrality and expired TTL are evicted first, even if recently accessed (anti-LRU bias for streaming).
- **Aggressive Pre-charge:** When `P(access) > 0.85`, chunks are staged in VRAM before they enter the active rendering graph.
- Cache coherency is maintained via hardware residency bitmasks; CPU/GPU never fetch from untagged addresses.

### D. SSD Virtual Memory Layer
- Bypasses POSIX/FAT/ext. SSD is exposed as a **Chunk-Addressable Virtual Address Space (CAVAS)**.
- 64-bit virtual chunk IDs map directly to SSD logical block addresses via a compact hardware page table.
- Hierarchical tiering is logical, not physical: Hot/warm/cold status dictates scheduling priority and eviction TTL, not NAND type.
- Background wear leveling, garbage collection, and bad-block remapping are fully transparent and rate-limited to avoid I/O jitter.

### E. GPU Execution Model
- **No dynamic asset requests during frame execution.**
- GPU receives **Frame Bundles** pre-assembled during frame overlap. Each bundle contains: command buffers, residency manifests, constant buffers, and pre-decompressed chunk pointers.
- Render graph is fully deterministic; all texture/mesh lookups resolve to VRAM-resident data or hardware fallback samplers.
- If a bundle reference points to a missing chunk, the hardware sampler automatically falls back to a cached procedural proxy or lower LOD without shader recompilation or pipeline bubble.

---

## 3. Memory Hierarchy Model (Textual Diagram)

```
[GAME ENGINE / CAMERA / AI STATE]
↓ (spatial/temporal hints)
[MEMORY GRAPH SYSTEM (MGS-X)] ← Predictive DAG, updated per frame
↓ (Lookahead Queue + Priority Scores)
[STREAM SCHEDULER CORE] ← Time-sliced, deterministic I/O planner
↓ (DMA descriptors + chunk offsets)
[SSD VIRTUAL MEMORY LAYER] (1TB, 256KB chunks, direct LBA mapping)
↓ (18–36 GB/s raw/effective)
[CODEC-X DECOMPRESSION] → [DMA-X STREAMING CONTROLLER] (zero-copy routing)
↓
[RAM CACHE ORCHESTRATOR] (16GB GDDR7 sliding window)
├── VRAM Window (12GB) ← GPU-resident, guaranteed for current frame
└── Stream Buffer (4GB) ← MGS state, scheduler queues, CPU working sets
↓ (pre-resolved pointers)
[FRAME BUNDLE ASSEMBLER] → [GPU EXECUTION PIPELINE]
↓ (deterministic draw/trace dispatch)
[DISPLAY / HRTF / HAPTICS]
```

---

## 4. Streaming Pipeline Explanation

1. **State Sampling & Graph Update:** During frame overlap, engine state (camera, velocity, AI paths, triggers) is hashed into the MGS. Edge weights are recalculated using spatial locality + lightweight temporal prediction.
2. **Lookahead Generation:** The Stream Scheduler traverses the MGS, producing a prioritized queue of chunks needed for `t+0` to `t+5s`. Critical path chunks get hard deadlines.
3. **I/O Scheduling & Decompression:** DMA-X reads compressed chunks directly from SSD. CODEC-X decompresses in-flight, writing raw data to predetermined RAM cache slots via zero-copy transfers.
4. **Cache Placement & Eviction:** RAM Cache Orchestrator places chunks in the VRAM window. Low-probability or expired chunks are aggressively evicted. Residency bitmasks are updated atomically.
5. **Frame Bundle Assembly:** Command buffers are compiled. Texture/mesh handles are resolved against residency bitmasks. If a handle is missing, a fallback proxy is bound. The completed bundle is submitted to GPU.
6. **GPU Execution:** GPU processes the bundle deterministically. No runtime I/O, no texture streaming mid-draw. All bandwidth is dedicated to rendering.
7. **Continuous Overlap:** Steps 1–5 run concurrently with step 6, pipelined across frames. The OS guarantees that by V-Sync, the next frame's bundle is fully resident.

**Determinism & Fallbacks:** All scheduling is time-sliced with hard deadlines. If SSD latency spikes or prediction confidence drops below threshold, the scheduler injects pre-baked fallback LODs or procedural geometry stubs into the frame bundle. This guarantees <1ms pipeline stalls and eliminates hitching.

---

## 5. Trade-offs vs. Traditional Console Design

| Aspect | Traditional Console | PS6 Streaming Architecture |
|--------|---------------------|----------------------------|
| **Primary Memory Role** | RAM holds active assets; SSD is fast storage | SSD is hierarchical VM; RAM is predictive cache |
| **I/O Model** | Reactive: game requests assets as needed | Proactive: OS schedules future memory states |
| **Developer Burden** | Manual streaming, LOD management, load zones | OS-driven; engine submits state hints, OS handles residency |
| **Frame Determinism** | Vulnerable to I/O stalls, async loading hitches | Guaranteed via Frame Bundles + fallback injection |
| **RAM Utilization** | Fixed allocation; often under/over-provisioned | Dynamic sliding window; high utilization efficiency |
| **Hardware Complexity** | Standardized I/O, simple memory mapping | Custom DMA, prediction silicon, cache orchestrator, codec pipeline |
| **Scalability** | Open worlds hit RAM/VRAM ceilings | Scales with chunk graph; effective working set limited only by prediction accuracy |
| **Development Shift** | Level design constrained by memory budgets | World design driven by traversal graphs & prediction confidence |

**Why SSD Cannot Fully Replace RAM:**
1. **Latency Gap:** Even PCIe 6.0 NVMe SSDs exhibit 10–20μs average read latency. GDDR7 operates at ~150ns. A 50–100x latency penalty guarantees frame misses if the GPU directly queries the SSD mid-render.
2. **Random Access Granularity:** SSDs optimize for sequential/large-block throughput. CPUs/GPUs require fine-grained, byte/word-level random access for shader constants, small structs, and pointer chasing. RAM provides bounded latency for these patterns.
3. **Write Endurance & Wear:** Continuous streaming of volatile cache data would rapidly degrade NAND cells. RAM sustains infinite read/write cycles without wear leveling overhead.
4. **Deterministic Guarantees:** SSD latency varies due to garbage collection, thermal throttling, and wear distribution. RAM delivers strictly bounded access times, which is non-negotiable for 120Hz/VR/deterministic lockstep.

**Conclusion:** The PS6 architecture flips the memory hierarchy: storage becomes addressable memory, RAM becomes a smart cache, and the OS acts as a predictive scheduler. This enables truly seamless open worlds, eliminates traditional loading screens, and shifts performance from raw silicon wattage to architectural foresight. While BOM costs push retail toward $500+, the trade-off is justified by the elimination of I/O stalls, reduced developer streaming overhead, and a platform that scales predictably with world complexity.
Poe - incomplete -
https://poe.com/s/ZDcxDq1BGv23Iwe31q2C
TurboSeek
Spoiler Hardware Architecture for PS6 (Streaming‑First)
CPU (Stream‑Aware Zen‑6)
• 8 cores at 3.0 GHz with dedicated “Pre‑fetch & Graph” out‑of‑order units that can stream metadata ahead of execution.
• Hardware TLB for world‑chunk pages and a lightweight policy engine that can hand off predicted chunk requests to the Streaming Controller without OS intervention.
GPU (RDNA‑5 Streaming‑First)
• Core count reduced to 40 compute units – sufficient for 60 fps at 4K – because all heavy data flows through a high‑bandwidth RDNA‑5 bus.
• Integrated Neural Array for real‑time upscaling and denoiser pass that operates on the virtual texture stream.
• On‑chip Radiance Core accelerates ray‑tracing traversal for per‑pixel streaming of light probes.
• Sparse memory interface for virtual textures, so the GPU always sees a resolved “frame bundle.”
RAM (30 GB GDDR6, 256‑bit, 640 GB/s)
• Acts as a high‑speed cache layer for all predicted world data.
• Size chosen to hold a sliding window of 2–3 world segments plus dynamic LOD, keeping per‑frame random access patterns within a few milliseconds.
VRAM (8 GB GDDR6)
• Dedicated to the GPU’s immediate needs: pre‑configured tiles, shaders, and the active frame bundle.
• Kept minimal to reduce cost while enabling a 12‑GB total graphics bandwidth budget.
SSD (2 TB NVMe‑Gen5, 10 000 MB/s raw)
• Re‑architected as a chunk‑addressable memory layer with a “Universal Compression” engine on‑device – allows ~3× effective throughput at a fraction of power.
Dedicated Hardware Blocks
• Decompression Accelerator: 64‑bit SIMD engine that inflates compressed chunks in under 1 ms.
• Prediction Engine: Tiny Tensor‑Core array fed by the Memory Graph System, producing probability distributions for next‑segment access.
• Streaming Controller: PCIe Gen5 fabric hub that orchestrates transfer pipelines SSD → RAM, RAM → VRAM and synchronizes with the Stream Scheduler.
Trade‑Offs & Pricing
• 30 GB GDDR6 + 2 TB NVMe pushes manufacturing cost to ~$600–650 at launch – higher than the ~$299 target but necessary for a 3‑K, 60‑fps experience.
• The price gap can be partially amortized by bundling the console with a discounted SSD upgrade kit and a subscription for cloud‑based asset libraries.
• Eliminating an external SSD slot (as in the PS5 digital model) keeps the unit small and simplifies the firmware, further controlling cost.

Console OS Kernel – Streaming‑First Scheduler
A. Memory Graph System (MGS)
World data is decomposed into chunks (~256 × 256 m). The MGS stores a probabilistic graph where each node is a chunk and weighted edges indicate likelihood of future access. A lightweight Markov model runs on the Prediction Engine, updating edge weights each frame based on player velocity, quest logs, and pre‑computed path graphs.
B. Stream Scheduler Core
Given the MGS, the core computes a “predicted future window” (next 2–3 seconds of gameplay). It issues ordered requests to the Streaming Controller: SSD → RAM for all chunks in the window, reserving bandwidth for high‑fidelity assets while lower‑res proxies are already resident. The scheduler guarantees each asset lands in RAM before its frame window begins, using real‑time checks.
C. RAM Cache Orchestrator
RAM is treated as a sliding prediction window. An aggressive LRU/clock eviction policy is combined with “stay‑in‑window” heuristics: chunks outside the predicted window are purged, those within are promoted. The orchestrator also manages a priority stack for high‑importance assets (e.g., cut‑scene textures) to prevent mid‑stream stalls.
D. SSD Virtual Memory Layer
The OS presents the SSD as a 3‑D array of chunk blocks rather than a file system. Chunk IDs map directly to NVMe command queues; the firmware translates these into DMA descriptors. This eliminates file‑system overhead and allows the kernel to batch requests per region, boosting throughput.
E. GPU Execution Model
For each frame the GPU is handed a “frame bundle” that contains all textures, models, and shader binaries resolved for the current view. The bundle is assembled by the Stream Scheduler after the RAM Cache guarantees all data is resident. The GPU never issues on‑device asset requests, so frame pacing is deterministic. If a chunk misses the pipeline, the fallback LOD engine injects a procedural surrogate, guaranteeing no stall.

Memory‑Hierarchy Model (Textual Diagram)
┌──────────────────────┐ ┌────────────────────┐
│ ROM / Firmware │ │ OS Kernel (Scheduler)│
└───────────┬──────────┘ └───────┬──────────────┘
│ │
┌───────────▼─────────────────────┐ │
│ RAM Cache │ │
└───────┬───────────────┬─────────┘ │
│ │ │
┌───────▼─────────┐ ┌────▼───────┐ │
│ Streaming Hub │ │ SSD Virtual│ │
└───────┬─────────┘ └─────┬──────┘ │
│ │ ▼
┌───────▼─────────┐ ┌────▼───────┐ ┌────▼─────┐
│ GPU VRAM (VRAM)│ │ GPU Core │ │ GPU Thread│
└───────────────────┘ └────────────┘ └──────────┘


Streaming Pipeline Explanation
1. The user boots; the Firmware loads a tiny executable bundle (<100 MB). The kernel immediately builds the initial MGS based on level geometry.
2. Each frame the Stream Scheduler consults the MGS, pushes predicted chunk IDs to the SSD via the Streaming Hub.
3. The Decompression Accelerator inflates chunks on‑the‑fly; the RAM Cache stores them in a sliding window. Out‑of‑order eviction keeps capacity for next segment.
4. Once all resolved assets are in RAM, the Stream Scheduler packages them into the frame bundle and hands it to the GPU.
5. The GPU consumes the bundle without I/O stalls; on missing assets the fallback LOD engine steps in, procedurally generating a low‑res surrogate while the rest of the stream catches up.

Trade‑Offs vs Traditional Console Design

Cost & Power – Replacing bulk SSD capacity with a large RAM cache raises component cost and power draw. The hybrid approach keeps total cost below a mid‑tier price point while delivering near‑instant loading.
Latency – SSD cannot match RAM latency for per‑frame random access; keeping a sliding window in RAM eliminates the 3–5 ms delays that would stall the GPU.
Determinism – The scheduler guarantees that all needed data is available before the GPU renders, eliminating unpredictable stalls seen in cloud‑gaming or reactive streaming.
Scalability – As game worlds grow, the system scales by adding more chunks to the SSD and expanding the RAM cache, without needing to increase internal storage on the console.
Backward Compatibility – Existing PS5 titles can be remastered or patched to generate light “streamable” assets, benefiting from the new pipeline while still operating on the old disk format.

This architecture delivers a PS6 that feels instant, never shows pop‑in, and keeps the end‑user cost close to consumer expectations, while enabling the next generation of gigantic, dense worlds.
Exa.AI
https://exa.ai/search/cmp1dag430001356ti7cbeni9
ChatGPT
https://chatgpt.com/share/6a01fb26-d274-83eb-a400-c7c284c899f4

Feeding all AI responses
https://www.dola.com/thread/wbbd714734e7b5b28

Zitat: Zitat von ][immy (Beitrag 13922316) Nintendo Titel widersprechen dir da ;)
Würde ich nicht sagen. Super Mario Wonder hat deutlich von den Möglichkeiten moderner Technik profitiert. So auch Mario Kart World.
Gerade die älteren Nintendo Games wirken trotz starkem Artdesign mittlerweile doch ziemlich veraltet und sehen halt stark nach "alte Videospielgrafik" aus. Je älter die Spiele werden, desto weniger nimmt man sogar den Artstyle wahr und desto stärker fällt einem die alte Technik auf.


Ich hab das auch erst letztens bei Bioshock Infinite gesehen. Ich fand den Artstyle damals so besonders und markant, dass es mir damals total zeitlos vorkam.
Wenn man das Spiel aber heute startet bröckelt die fassade schon ziemlich und man merkt dass man es eben mit einem mittlerweile ziemlich alten Spiel zu tun hat und keinem zeitlosen Grafikstil, der über die Technik hinwegtäuschen könnte. Borderlands 1 und 2 haben das gleiche Problem. Trotz Cell Shading, sie wirken grafisch mittlerweile veraltet.

Update: 11.05.2026 - Commit fd8a2c2 - https://github.com/optiscaler/OptiSc...ommits/master/
Download: https://app.filen.io/#/f/d1474725-ed...51347543636b38

Ich habe es auch mal mit meiner PNY 5070 TI ausprobiert.Ich wollte so einfach wie möglich undervolten und das hat prima geklappt.
In AC Shadows bin ich von 260 Watt auf 180-190 Watt runter und die Temperatur von 74 auf 64 Grad runter :up:

Ja ich weiß OT, deshalb der letzte Beitrag von mir: Ich schaue da mehr auf die Wachstumsraten als auf den Status quo. Ansonsten wäre bsw. Nvidia auch nicht das wertvollste Unternehmen der Welt. Das Wachstum findet in der Cloud statt und den Zug hat Apple völlig verpennt. AMD und Nvidia combined werden Apple beim Umsatz/Gewinn bald überholt haben.

Die Spanne an maximal stabilem UV ist unter den Spielen enorm hoch. Selbst wenn einige Spiele mit -130mV noch laufen, muss man in anderen dafür auf -50mV runter. Das macht irgendwelche UV-Ergebnisse in einem einzigen Spiel ziemlich nichtssagend. Vom Gefühl her würde ich sagen, dass Spiele mit generell niedrigerem GPU-Takt auch anfälliger beim UV sind, d.h. weniger Reserven haben. Sonst ist es - gerade bei CPUs - ja eher so, dass die hohen Boost-Frequenzen am schnellsten instabil werden.

Und ich hatte mal durch Logs herausgefunden, dass die Standard V/f-Kurve meines OC-BIOS (317W) ca. 10mV mehr anlegt als das Quiet-BIOS (304W) bei gleichem Takt. Folglich hätte ich im OC-BIOS auf dem Paper immer ein um 10mV besseres UV-Ergebnis, auch wenn es gar nicht besser läuft als das Quiet-BIOS. Bei 340W vs 304W könnte das natürlich noch extremer sein, je nachdem was die Hersteller da als Standardeinstellung reinhauen.

Sapphire 9070XT Pulse + 32 GB DDR5 6000er CL30 kit für 899€

https://www.alternate.de/ALTERNATE/S...duct/100194858


Einzelpreise Laut GH:

9070XT Pulse: 655€. https://geizhals.de/sapphire-pulse-r...loc=de&hloc=at

TeamGroup Speicher Kit: 403€, https://geizhals.de/teamgroup-t-crea...loc=de&hloc=at

Ersparnis also ca 150€, oder günstigste 9070XT 630€ und günstigste RAM mit selben Werten 370€, immer noch huni gespart.

wer sowieso beides braucht....

Würde hier passen: https://www.forum-3dcenter.org/vbull...d.php?t=476081

Zitat: Zitat von SKYNET (Beitrag 11810496) Gigabyte GTX 1070 Xtreme Gaming
MSI GTX 1080 Armor OC
Gigabyte GTX 1080 Ti Aorus Xtreme Edition Desktop:
MSI Ventus 2X OC 3060 12GB
Sapphire Nitro+ RX 9060 XT
Sapphire Nitro+ RX 9070 XT - Aktuell

Laptop(es lebe das MXM modul):
AMD FirePro M6100 2GB
Nvidia Geforce GTX 880M 8GB
Nvidia Quadro P3200 6GB
Nvidia Quadro P5200 16GB - Aktuell

Zitat: Zitat von Daredevil (Beitrag 13920019) Nachdem Apple offiziell nun ihre MacStudios auf 96GB begrenzt hat und die MacBooks eh nicht mehr als 128GB adressieren, ist das ein kluger Schachzug. Jetzt aber bitte liefern AMD und Momentum mitnehmen! :) Der M3 Ultra ist im Abverkauf, Apple stellt die Modelle nicht mehr her. Daher der Rückgang. Alle Modelle mit den großen Speicheroptionen sind einfach abverkauft worden.

Die neuen Mac Studio und mini Modelle mit M5 Ultra und M5 sollten Anfang Juni vorgestellt werden, dann auch wieder mit den großen Speicheroptionen.

Zitat: Zitat von DrFreaK666 (Beitrag 13918537) Wie soll das erst auf der Switch 2 laufen? :ugly: Du kannst UE5 nach Bedarf reduzieren.
Die Batman Anforderungen nutzen FG damit sie uralte GPU wie 2070 Listen können.

Cronos auf Switch Very Low Settings

Das ist zu wenig, außerdem prügelt Doom die Grakas nicht gerade dick. Ich habe ja nicht mal 4k weil ich sowieso der Meinung bin, dass weder die 4090 noch die 5090 4k Karten sind. (y)
Ich rechne aber auch erst mit in 2 Jahren Verfügbarkeit der 6090.
Kann aber auch sein, dass die 6090 gar nicht kaufbar sein wird, weil China sowieso Taiwan platt machen wird bzw. erst mal Seeblockade. (y)

Zitat: Zitat von ChaosTM (Beitrag 13919828) 30+ % in der Hose sollte man nicht ignorieren ! (y)
Naya, ob 5 oder 6,5 cm/fps ist auch schon egal. (y)
Double enlargement klingt schon besser. :redface:

Zitat: Zitat von Ex3cut3r (Beitrag 13918655) Tolller Monitor, 39", endlich 5120x2160 also 21:9 4K und damit 32" PPi endlich im UW Format. Aber nur mit 165HZ.....das ist mir im Jahre 2026 in Zeiten von MFG ein bisschen zu wenig, für mich müssten es bei einem neukauf mindenstens 240HZ als untere Grenze sein, eher 360HZ und am idealsten wären sogar 480HZ. Hab das gleiche Problem, vor allem wenn man von 240Hz kommt will man das noch weniger machen. Aber es geht in die richtige Richtung, vor nicht allzu langer Zeit gabs solche 5kx2k Screens nur in 60Hz. Aber ja, mit MFG kann man eigentlich nicht genug Hz am Monitor haben, oder es kommt endlich Pulsar mit OLED :D

XPS 14 vs Macbook Air/Pro

https://www.computerbase.de/artikel/....96958/seite-2

Bei allen Android-Phones und allen Iphones seit 10 Jahren Gang und Gäbe.

Aber bei Windows ist es störend und nervig.

Dass man bei den Grafikkarten einen Cut macht ist nur logisch.
Wie soll man bei einem (DRM-)geschützten Medium sonst die Verschlüsselung bis zum Monitor hin aufrechterhalten.

Ich weiß ich drifte ab - aber eine Dreambox ist aktuell faktisch tot.
Es gibt keine Android-Box mit funktionierenden Netflix-/DisneyPlus-/... und gleichzeitig Satelliten-Eingang und diese Box sollte noch ein bisschen öffentlich-rechtlich aufzeichnen können.

Wenn Microsoft das nicht durchzieht, dann ist Windows so tot wie die Dreambox.

Zitat: Zitat von gedi (Beitrag 13918351) Den Treiberschrott gibt es doch eher von NV und insbesondere Intel …

Zudem scheint es mir, dass du bereits Hilfe beim Einschalten deines PCs benötigst. Wenn dann ist Nvidias Treiber im Vergleich zu AMD/Intel ‚unsauberer‘. Nvidia ist bereits informiert.

Zitat: Zitat von joe kongo (Beitrag 13848963) Ist bei meiner 9070XT das Gleiche, -70mV liefen nur scheinbar stabil,
Probleme kamen später sporadisch bei geringer Belastung.
Die notwendigen Reserven für spontane Lastwechsel kennt nur AMD.
Takte können instant wechseln, Spannungen nicht. meine nitro+ läuft bei den meisten sachen mit -120mV ohne probleme, wirklich stabil über alle getesten games und benches ist sie aber erst mit -80mV, und da ich gerne ne reserve habe sind 24/7 auf -70mV am laufen.

Zitat: Zitat von Palpatin (Beitrag 13917523) Das Argument macht keinen Sinn, weil sich 16:9 auch gegenüber 4:3 durchsetzen konnte und das zu einer Zeit als die Inhalte überwiegend 4:3 waren. Als sich 16:9 durchgesetzt hat, waren Fernseher auch noch so klein dass sie auf einem Phonomöbel verloren aussahen. Da macht es natürlich Sinn das Format an den (überwiegenden) Content anzupassen.

Heute kannst du dir den größtmöglichen Fernseher kaufen der in dein Wohnzimmer passt, und das wird in der Regel von der Breite bestimmt.

Der einzige Grund auf Höhe zu verzichten wäre wenn es dafür signifikante preisliche Vorteile gäbe.

Das wird aber nicht der Fall sein, wenn man ein neues Nischenformat einführt. Das wird sogar teurer sein. Damit wird es berechtigterweise niemand kaufen, und es schnell wieder vom Markt verschwinden.

Ich sehs kommen: kleinere Entwickler nutzen das Standard-Modell und schon bewegt sich Charakter A in Spiel 1 genauso wie Charakter B in Spiel 2