[LoD14]

ok, noch ein versucht es dir klar zu machen.

stell dir vor du hast eine grafikkarte und einen arbeitsspeicherbaustein in deinem komputer. die grafikkarte hat auch arbeitsspeichert. jetzt kommt windows ins spiel. windows erstellt sich eine "landkarte" des speichers und erstellt einen abstrakten adressraum des speichers.

kommt jetzt anwendung x an und will speicher haben, sagt das betriessystem "hier haste speicherbereich a". so, speicherbereich a geht für die anwendung von speicherraum 1-1000. im echten speicher von mir aus von 2444-3444. anwendung y ll auch speicher kriegt auch nen speicherbereich b. der für die anwendung von 1-1000. mittlerweile ist aber anwendung z die vorher schon lief und auch einen speicherbereich hatte beendet worden. jetzt geht der speicher für bereich b, den anwendung y haben wollte halt von 2000-2443 und von dann bei 3445 weiter...

moral von der geschichte: eine anwendung im betriebssystem greif NIE auf den realen speicher über den realen adressraum zu. ein BS erstellt IMMER einen virtuellen adressraum und stellt diesen virtuellen adressraum einer anwendung zur verfügung. desewegen sind acuh die programme, über die du dich wunderst, an BS gebunden -> speicherzuweisung.

stell dir jetzt mal vor die programme sind 3D anwendungen und greifen auf den grafikspeicher zu. das tun sie über einen virtuellen adressraum, der vom BS verwaltet wird und dann vom BS auf den realen Adressraum abgebildet wird. da hat kein treiber und kein programm einfluss drauf. der treiber sagt uU dem BS, von wo bis wo der reale adressraum geht, aber verwaltet wird der dann wieder über den virtuellen vom BS.

so, jetzt gehen wir mal ne stufe weiter. wir haben ein CF/SLi system. wir haben 2 "Speicher" von jeder graka einen... die verwaletet nun das BS, egal was der treiber einem sagt. jetzt kannst du dir ja unterscheide mal ausmahlen. ich geb dir mal ein beispiel: es würde schon einen unterschied ausmachen, ob dein grafikspeicher auf den beiden grakas als ein raum oder als 2 räume betrachtet wird.

hätte übrigens eine seite weiter im pdf gestanden...

[*TLC*]

Leute dies ist ein Ergebnis Thread, also bitte nur Ergebnisse posten, macht einen neuenThread auf, wenn ihr diskutieren wollt!



Grüsse

[LoD14]

tja, da gehn wohl einem die argumente aus.

also... nochmal für dich alles aufgedröselt.

problem: software -> zugriff -> hardware

von unten nach oben:

die harware ist im computer.

der treiber stellt dem System eine art "api" zur verfügung um auf die hardware zuzugreifen. darunter exemplarisch der speicher den ich dir ja schon versucht hab zu erklären

das System verwaltet nun die hardwareresourcen. darunter, recht- und zugriffsmanagement, speicherverwaltung, prozessprioritäten etc. das musst du dir wie eine abstrakte virtuelle maschine vorstellen.

das System stellt (in diesem fall über DirectX) eine API zur verfügung, die die vom System verwalteten und abstrahierten hardwarekomponenten für software zugänglich macht.

das programm (hier 3DMark) greift über die DirectX API auf virtuelle Hardware im System zu.

das System verwaltet die anfrage, prüft deren rechte, weist denen prioritäten und rechenzeit zu, weist speicher zu und leitet dass dann über den treiber an die hardware weiter.

so reicht dir das? da haste den grund, warum ein programm NIEMALS direkt auf die hardware zugreift. es geschieht immer über diese 2 oder mehr APIs. wobei cih jetzt nicht weis, ob ein treiber direkt als API bezeichnet wird oder der noch ne extra bezeichnung hat. aber im grunde funktioniert er wie ne api.

das system spiel IMMER die zentrale rolle. es gibt keine software, die direkt auf die hardware zugreift. es sei denn die software heißt zufällig betriebssystem.

und an dem speicher kann man halt wunderbar zeigen, wie das system als mittelsmann dazwischen steht. aber das funktioniert so bei jedem hardwarezugriff.

Dieser Beitrag wurde von LoD14 bearbeitet: 05. Januar 2008 - 14:06

[LoD14]

Zitat

schon lustig, nix anderes habe ich weiter oben geschrieben die software greift über die api auf die grafikkarte zu. das diese vom OS als virtuell verwaltet wird, ist mir durchaus klar und bewusst - darum ging es aber niemals, es ging lediglich um die ansteuerung, und die funktioniert nunmal so wie du nun auch beschrieben hast über die api.

Zitat

joar, ist ja auch logisch weil die software, in diesem falle 3dmark06, auf das cf/sli zugreift und nicht das os ;o) man du bist mir ne pflaume

ja ne is klaaa. entweder hast du schon vergessen, was du behauptet hast, oder hast was anderes hingeschrieben als du denkst.

der zugriff auf hardware erfolgt immer übers OS. den zugriff macht immer das OS für die anwendung.

---
stan, wenn du schon löscht, stell bitte den post mit dem XP ergbniss wieder her. das vista ist einfach zu schlecht weiter oben.

Dieser Beitrag wurde von LoD14 bearbeitet: 05. Januar 2008 - 14:18

[LoD14]

Zitat

so aber ich frage mich immernoch warum es für vista / xp keine updates/patches gibt, die cf/sli performance technisch auf die sprünge helfen, wenn hier der hauptkern liegt ? (und darum ging es in der gesammenten diskussion ja)

ein tiefgreifender eingriff ins speichermanagement eines systems birgt immer einen riesen berg gefahren, dass es etwas anderes amok läuft. das gilt auch für andere breiche.,

Zitat

das ist nicht richtig, der zugriff erfolgt über die API, die API wird vom OS gelenkt - was etwas ganz anderes ist, als der reine zugriff.

das wäre dann aber eine protokoll api. wir reden hier aber von einer datei/objekt api.

Dieser Beitrag wurde von LoD14 bearbeitet: 05. Januar 2008 - 14:43

[LoD14]

Zitat

gingen dir jetzt die argumente aus?

nenn mir nen grund warum das nicht stimmt. das ist doch das selbe wie die geschichte mit den 2 verschiedenen trident enginens in XP. eine für dateigeschichten und eine fürs internet, ab dem moment, wo der IE7 installiert ist.

[LoD14]

wenn du nicht lesen kannst oder willst oder hirnlos liest, ist es dein problem. ich habs schon geschrieben. ich bin doch nicht dein kindergärtner.

[LoD14]

bei vista wurde so einiges geändert, was in einigen bereichen deutliche schübe bewirken *könnte*

wie h0nk schon sagt, läuft alles über die ring0 ebene. und da kann man eigentlich davon ausgehen, dass eine komponente wie der/die/das HAL an die neuen zeiten angepasst wurde.

auch dürften module wie der I/O Manager mal überarbeitet worden sein. dazu kommt, dass garantiert acuh das verhalten im setzten von mutuel exclusions an mehrkernsysteme (eventuell acuh mehr GPU Systeme) angepasst worden sein dürft. und eigentlich alles was mim objektmanager zu tun hat.

übrigens wurde der memory manager in vista komplett überarbeitet. vista behandelt sessions jetzt ganz anders als alle teile vorher. da fallen die umwegen über die win32 komponenten weg.

Zitat

Entscheidend ist immer der Kernel oder die Firmware auf der Ring0-Ebene, der Treiber oder Layer spricht diesen ja jeweils an.

im grunde müsste vor kernel und fw ja noch der/die/das hal stehen (welches geschlecht hat das tier eigentlich?) naja, theoretisch geht das ja. der starforce kopierschutz soll durch seinen treiber ja nen tunnel für den kopierschutz in den ring0 basteln/gebastelt haben. dadurch konnte der kopierschutzt über diesen treiber aus ring3 raus im ring0 rumpfuschen, vorbei an allen admins etc. was natürlich viren und würmern auch ein wunderbares tor geboten hätte. aber selbst *wenn* 3dMark im kernelmodus laufen würde, würde er immer noch vor dem HAL und IOManager etc stehen. und dem framwork der treiber. (und das hätte man gehört, dann wär ein aufschrei durchs netz gegangen) du kannst schon davon ausgehen, dass es im nutzermodus hantiert. und dann muss es die umwege gehen.

jetzt bleibt an der stelle noch dei ganz neu aufgeworfene frage nach den begrenzungen durch die hardware und wie stark sie bremsen bzw wie stark man mit einem OS bustransfers noch optimieren kann.