USB benutzen / Grafikspeicher



  • Hallo,
    ich weiß nicht ob das überhaupt möglich ist aber kann aus C++ auf USB Ports zugreifen und dann z.B. überprüfen ob ein Stick drin ist oder nicht. Meine andere Frage ist kann man irgendwie in den Grafikspeicher schreiben, also ohne die Funktion des Betriebssystem?

    LG



  • Ich gehe davon aus, das dies durch Assembler Programmierung machbar sein müsste. Oder aber Microsoft bietet da etwas an (angenommen du arbeitest an einem Windows).


  • Mod

    USB RED schrieb:

    Hallo,
    ich weiß nicht ob das überhaupt möglich ist aber kann aus C++ auf USB Ports zugreifen und dann z.B. überprüfen ob ein Stick drin ist oder nicht.

    Betriebssystemfunktionen.

    Meine andere Frage ist kann man irgendwie in den Grafikspeicher schreiben, also ohne die Funktion des Betriebssystem?

    Kommt auf das System an und was genau du mit Grafikspeicher meinst und was genau du mit Betriebssystem meinst.

    Wenn du an so etwas wie unter DOS auf dem IBM-PC denkst:

    char * video_memory = reinterpret_cast<char*>(0xA0000);
    write(video_memory, /.../);
    

    Nein, das funktioniert nur auf Systemen wie DOS auf dem IBM-PC und nicht auf einem modernen Desktop.

    ~Ganz genau genommen geht das schon, aber es wird nicht den Effekt haben, den du denkst. Ich muss diesen Satz anfügen, weil sonst irgendein Klugscheißer darauf besteht, dass es doch ginge. Vergiss am besten, dass es dies hier steht :p~

    DilBahadur schrieb:

    Ich gehe davon aus, das dies durch Assembler Programmierung machbar sein müsste.

    Was kann man denn mit Assembler in dieser Hinsicht für tolle Tricks machen, die mit Standard-C++ nicht gingen?



  • Ich schreibe einen Software-Renderer und dort schreibe ich einfach in meinen Speicherbereich und wenn alles fertig ist, wird das in ein Bild umgewandelt und angezeigt. Da ich dieselbe Datenstruktur wie das Bild genommen habe, wird eigentlich nur die Adresse meines Speicherbereiches an eine QPixmap übergeben, welche dann angezeigt wird.



  • @Citizen42: kann ja sein, dass du dein Bild in Software renderst. Na und? Um es darzustellen, muss es wieder in den Framebuffer der Grafikkarte. Und dafür verwendest du einen Kernelcall, oder mehrere, oder du verwendest ein API, dass dann einen oder mehrere Kernelcalls macht, damit es auf dem Bildschirm erscheint.

    Und eine Alternative zum Kernelcall gibt es nicht, zumindest nicht ohne Sicherheitslücke. Weil der Framebuffer so mit zu den Ressourcen gehört, auf die man nicht direkt zugreifen soll. Wo der Zugriff so über ein API gehen soll.



  • Ich habe nur beschrieben wie man so etwas halt heute macht, da man bei den drei großen Betriebssystemen eben nicht mehr direkt die Erlaubnis bekommt auf die Hardware zuzugreifen und schön im Userspace bleibt.

    Die letztendliche Darstellung übernimmt das OS, aber ich kann vorher mit meinen Algorithmen so tun als würde ich in einen Grafikspeicher schreiben, die Algos bleiben gleich.



  • Nein, eigentlich nicht. Die GPU ist ja dafür gemacht, bestimmte Sachen zu machen, und das schneller als die CPU, die zwar mehr kann, aber dafür langsamer. Beispiel: in den guten alten Tagen der SNES hatte man sog. Sprites, Bilder, die im Grafikspeicher lagen. Anstatt dass die CPU immer auf Kollision geprüft hat, was teuer ist (mal abgesehen davon, dass die CPU auf der SNES eh schwach war), hat die GPU immer Interrupts gesendet, wenn es eine Kollision gab. Weil die GPU das halt viel schneller konnte.

    Und daran hat sich auch heute nicht viel geändert. Die CPU ist immer noch eher General-Purpose, kann viel, aber halt langsamer.
    Hier noch ein Beispiel aus jüngerer Zeit: bevor ich mein jetziges System aufgesetzt habe, hatte ich ein ranziges Debian hier. Und das war so ranzig, dass X einen veralterten i915-Treiber hatte, der Haswell nicht kannte. Also hat X einen Software-Renderer genommen, und der hat bei 480p-Videos 200% CPU-Last verursacht.

    Mit dem neuen Hardware-Renderer komme ich auf ein Prozent. :p



  • Ja, das ist mir schon klar. Ich schreibe auch einen Software-Renderer, weil ich eben nicht OpenGL nutzen will, sondern was lernen möchte(Bresenham, Hidden-Surface usw.) Ich möchte die gesamte Pipeline von vorn bis hinten einmal selbst implementiert haben.

    Da der Fragesteller direkt nach dem Grafikspeicher gefragt hat, bin ich davon ausgegangen, dass er auch so "oldschool" wie ich programmieren möchte und wirklich jeden Pixel per Hand setzen will und eben nicht Shader schreiben will und nicht mit VBOs etc. arbeiten möchte.



  • Naja, eigentlich hat er gefragt:

    Meine andere Frage ist kann man irgendwie in den Grafikspeicher schreiben, also ohne die Funktion des Betriebssystem?

    Und das geht halt nicht. Rendern geht, obwohl das (für den produktiven Einsatz - nicht für Lernzwecke) relativ sinnlos ist, Anzeigen geht überhaupt nicht ohne OS. Aber jetzt ist genug Klugscheißerei ... oder? 🙂

    Ach nein, ich erklärbäre besser nochmal, was SeppJ mit seinem Post meinte:

    Damals, in grauer Computer-Vorzeit, konnten sich Prozesse gegenseitig in den Speicher schreiben. Hardwareresourcen wurden in den Hauptspeicher gemappt, und da konnte man dann auch wie bei den anderen Prozessen reinlinsen. Und die Ressourcen wurden immer an relativ konstanten Orten exportiert, beispielsweise 0xA0000 (wobei ich jetzt gerade nicht weiß, ob es Systeme gab, wo dies tatsächlich die Speicheradresse war).

    Da konnte ein Programm dann direkt auf den Grafikspeicher zugreifen. Und lesen und schreiben und Abstürzen lassen. Waren andere Zeiten damals.

    Dann kam man mit Konzepten wie Speicherschutz, virtueller Adressraum, Paging, und MMU. Plötzlich konnten Prozesse nicht mehr andere Prozesse zerstören - ähm, naja, nicht mehr ganz so leicht, meine ich. Und der Zugriff auf die Hardware war jetzt auch verboten. 0xA0000 konnte jetzt auf den eigenen Stack, oder auf einen Teil des Heaps, oder im Nirvana liegen. Stattdessen musste man das OS anhauen. Also, zumindest bei DOS/Windows war das so. Linux war da immer wesentlich konservativer, die hatten, meine ich, nie einen Wechsel. Kann mich aber auch irren hier.

    Und das hat man bis heute beibehalten.


  • Mod

    Einzelne Pixel setzen ist hingegen überhaupt gar kein Problem. Deine Frage war so ungeschickt gestellt, dass die richtige Antwort auf die Frage dich eher verwirrt hat.



  • @SeppJ:
    Ähh, was? Über SetPixel ? Das ist doch auch wieder ein Call des Betriebssystems.


  • Mod

    dachschaden schrieb:

    @SeppJ:
    Ähh, was? Über SetPixel ? Das ist doch auch wieder ein Call des Betriebssystems.

    Ja, zum Beispiel. Aber bei der Problemstellung des TE ist es doch völlig unerheblich, ob das eine OS-Funktion ist oder nicht.


Anmelden zum Antworten