Skysnake
Lötkolbengott/-göttin
Da gibt es nichts zu "können" bei der FPGA-Version. Das ist alles fix und fertig. Den musste "nur" noch Programmieren. nVidia hat halt "nur" die Sparversion genutzt. Mit den Topmodellen wäre das sicherlich ohne DRAM gegangen, zur Not halt mit zwei FPGAs. Da biste aber bei fünfstelligen Summen für EINEN! FPGA. Der kleinste Startix V kostet so ca 6k€....Wenn du einen kompletten Frame zwischenspeichern willst, wirst du mit einzelnen Flipflops nicht weiter kommen. SRAM wäre eigentlich die naheliegendere Lösung - aber Nvidia hat jede Menge Erfahrung mit DRAM und null Ahnung von großen oder gar externen Caches. Da war ein breites DDR-Interface dann vermutlich die leichter umzusetzende Lösung.
Du kannst das aber dann alles in einem Chip machen, brauchst keinen externen DRAM und keinen Controller usw. Das würde sich durchaus lohnen alles in SRAM zu machen.Je nach Vorrausplanung wäre SRAM ggf. auch schlicht (zu) teuer.
Na lass mal UHD weg.Ein UHD-Frame unter Ausnutzung der spezifizierten 12 Bit Kanäle hat 36 MiB. Wenn das Ding hier einen zwischenspeichern und einen zweiten für den Vergleich annehmen können muss (wo ich mich Frage, was Overdrive im Scaler macht), sind wir bei 72 MiB allein an Bildspeicher. Will man vorarbeiten, braucht man noch einen dritten Puffer für die Ergebnisse. (Gsync hilft ja nur bei niedrigen fps. Hat die Karte einen Frame fertig, bevor der letzte komplett dargestellt wurde, kann für das erste Pixel schonmal der Overdrive kalkuliert werden, bevor es dargestellt wird. Fällt mir auf: Das würde sogar gut zu dem ungewöhnlichen 3-Chip Interface passen)
Damit wären wir bei 127 MiB Speicher und haben noch kein bißchen Firmware, Daten des Panels oder ähnliches geladen. 256 MiB SRAM sind schon ein dicker Brocken, On-DIE definitiv nicht praktikabel.
2560x1440 reicht völlig aus erstmal. Auf 12 Bit Pro Kanal würde ich auch nicht direkt gehen, sondern auf 8Bit. Mehr ist es meines Wissens nach aktuell eh nicht. Damit biste nur noch bei 10,5MB pro Bild.
Das sollte man in nen FPGA unter bekommen, und auch in nem ASIC.
Die Sache mit dem Puffer ist ja auch die. Du musst ja nur warten, bis der jeweilige Pixel da ist vom neuen Bild. Dann kannste das alte Bild überschreiben. Im Prinzip solltest du das sogar über FiFos und FliFlops machen können, wo du nur den Buffer einmalig hast, und die Daten eben ausliest, und direkt mit den neuen geschrieben Daten verrechnest und ans Display ausgibst.
Das ist ja das tolle an so nem ASIC. Du kannst das alles GENAU aufeinander abstimmen, und hast 100% Kontrolle darüber was passiert. Du musst halt ne finateStateMachine bauen, aber das wars. Dir funkt halt kein OS und nichts dazwischen

"Firmware" usw brauchste auch für den FPGA usw an sich nicht. Das steckt ja alles im FPGA, bzw im ASIC dann später drin. Da ist irgendwo noch nen EPROM und der das Config des FPGAs hält, und das wars dann auch schon.
@Superwip:
Eher unwahrscheinlich, das wäre ne dumme Idee... Zumal eben andere Möglichkeiten die SEHR viel eleganter sind bestehen und offensichtlich sind.
PS:
Gipsel ausm 3DCenter
Aus der aktuellen pcper-Meldung dazu:
Zitat:
Finally, as a last minute stirring of the pot, I received an email from AMD's Koduri that indicated that there might be some monitors already on the market that could support variable refresh rate TODAY with just a firmware update. [..] We are trying to find a list of these monitors so we can talk with them and ask for these necessary changes.
Genau das würde ich eigentlich auch vermuten, da der Support des variablen vblanks im Prinzip nicht so kompliziert ist (und man benötigt auch nicht unbedingt DP1.3, irgendein Flag in den EDID-Infos, der den Support signalisiert, würde eigentlich auch reichen). Aber warten wir mal ab.
EDIT:
Danke für das Update

Zuletzt bearbeitet:



und das ist den elitären Nvidia Nutzern (so sieht er sich wohl) natürlich auch mehr Geld wert. 
)
.