Seite 70 von 252

Re: Jammer-Thread

Verfasst: 06.06.2012, 18:30
von dot
Naja, wieso 1x Multisampling == kein Antialiasing ist, sollte offensichtlich sein? ;)

Metro ist für Touch Devices ausgelegt, ein Sektor in dem der momentane Trend zu high DPI Displays afaik besonders stark ausgeprägt ist. Multisampling wird also gerade auf solchen Geräten relativ bald vermutlich obsolet sein bzw. ist es schon bzw. wird man zumindest nichtmehr viel davon profitieren. Die ganze Leistung die Multisampling zieht, macht das Feature imo schwer zu rechtfertigen und es wäre wohl Wahnsinn das default an zu haben. Und wenn man es wirklich haben muss, kann man es ja auch immer noch haben. Nur muss man das Resolving eben selber machen, was nicht nur trivial, sondern imo sowieso auf Awendungsseite besser aufgehoben ist, da die Anwendung das potentiell optimaler implementieren kann als die Compositing Engine...

Re: Jammer-Thread

Verfasst: 06.06.2012, 18:42
von eXile
dot hat geschrieben:Naja, wieso 1x Multisampling == kein Antialiasing ist, sollte offensichtlich sein? ;)
Nein, so dumm bin ich nicht! :) Das „warum eigentlich?“ war als Ellipse auf „warum eigentlich kein Anti-Aliasing?“ gemeint, was logisch zur Konklusion führt, dass eben Energie gespart werden soll.
dot hat geschrieben:Metro ist für Touch Devices ausgelegt, ein Sektor in dem der momentane Trend zu high DPI Displays afaik besonders stark ausgeprägt ist. Multisampling wird also gerade auf solchen Geräten relativ bald vermutlich obsolet sein bzw. ist es schon bzw. wird man zumindest nichtmehr viel davon profitieren. Die ganze Leistung die Multisampling zieht, macht das Feature imo schwer zu rechtfertigen...
Naja, eine höhere Auflösung (das ist halt dann so wie FSAA) braucht immer mehr Leistung als die äquivalente MSAA-Stufe. Außerdem sollte man damit niemals im Bereich der Aliasing-Artefakte argumentieren, weil man zwischen der angulären Sehschärfe und Noniussehschärfe hart unterscheiden muss. Eine schöne Erklärung findest du hier.

Re: Jammer-Thread

Verfasst: 06.06.2012, 18:48
von dot
eXile hat geschrieben:Naja, eine höhere Auflösung (das ist halt dann so wie FSAA) braucht immer mehr Leistung als die äquivalente MSAA-Stufe. Außerdem sollte man damit niemals im Bereich der Aliasing-Artefakte argumentieren, weil man zwischen der angulären Sehschärfe und Noniussehschärfe hart unterscheiden muss.
Da muss ich dir natürlich recht geben.

Re: Jammer-Thread

Verfasst: 06.06.2012, 19:09
von CodingCat
D3D11: WARNING: ID3D11DeviceContext::CSSetShaderResources: Resource being set to CS shader resource slot 10 is still bound on output! Forcing to NULL. [ STATE_SETTING WARNING #2097317: DEVICE_CSSETSHADERRESOURCES_HAZARD ]
Aber die Views überlappen sich nicht !!!!!111elf. AARGH. Ich weiß schon gar nicht mehr, was ich zuerst aus dem Fenster schmeißen soll.

Re: Jammer-Thread

Verfasst: 06.06.2012, 19:19
von Schrompf
Der Link zur Sehschärfe ist interessant! Danke dafür! Ist natürlich schade, dass er seine Argumentation ausgerechnet an einem Apple-Produkt erproben muss... die Apple-Fans sind nicht für ihre Zugänglichkeit für Fakten bekannt. Aber ich empfand es als interessanten Lesestoff.

Zu meinem Gejammer noch abschließend, falls jemand anderes mal das Problem haben sollte:

a) Man kann nicht einfach die Subversion Apache Modules ersetzen, sie müssen auch nach mir unbekannten Kriterien zum Apache Build passen
b) Man muss das Subversion/bin-Verzeichnis im Path haben
c) Und: es muss natürlich exakt das Verzeichnis sein, aus dem auch die Modules stammen.
d) Anscheinend macht es auf WinXP einen Unterschied, ob InternetExplorer 7 installiert ist oder nicht - Begründung
e) Manche Leute mussten den Apache-Service manuell umstellen, so dass er in einem bestimmten User-Account läuft - bei mir war das unwichtig.
f) Ich hatte bisweilen drei separate Apache-Installationen parallel auf der Platte. Es ist unbedingt notwendig zu wissen, welche davon gerade vom Apache Service Monitor gestartet wird.
g) Redmine bzw. RubyOnRails im Allgemeinen ist ohne Fertiginstaller nicht zu ertragen. Es gibt zum Glück Leute wie "Bitnami", deren Stack zum Glück so eine Art Fire&Forget-Install ist.
h) Das Update bleibt aber weiterhin der Hass - man installiert die neue Version parallel, muss vorher die Datenbank dumpen, und danach ein Rudel Zeugs manuell migrieren, um dann irgendwann die alte Version löschen zu können.

Ich habe fertig.

Re: Jammer-Thread

Verfasst: 06.06.2012, 19:56
von Artificial Mind
Google Chrome wirft dann mal die vertical tabs wieder raus.
Vielen Dank. Mein Lieblingsfeature von Chrome. Sayonara~~~~

EDIT: Treffendes Zitat von einem erzürnten Chrome-Nutzer:
I hate how the devs are like [...] “we know what our users want. You are a user, you don’t know about that. WE DO. So shut up already.”

Re: Jammer-Thread

Verfasst: 06.06.2012, 21:53
von Krishty
Warum erkennt Visual C++ nicht, dass sich

    0 != ((uint_x & 0x80) >> 7)

und

    0 != (uint_x & 0x80)

gleichen?!
Und rein präventiv: Diese Stelle wird tatsächlich 300 mio Mal in einer zeitkritischen Schleife durchlaufen

Re: Jammer-Thread

Verfasst: 06.06.2012, 23:48
von dot
Ist der Typ von uint_x tatsächlich unsigned?

Re: Jammer-Thread

Verfasst: 07.06.2012, 00:54
von Schrompf
Randjammer: Visual C++ 10 kann den Typ des Rückgabewerts eines Lambdas nicht mehr automatisch erkennen, wenn das Lambda aus mehr als einem einzelnen return-Statement besteht. Sowas hier:

Code: Alles auswählen

auto meinLambda = [&](const Objekt* obj) { irgendwas(); return obj->FragMichMal(); };
Das Lambda besteht aus einem Statement und erst danach dem return; Und das hält Visual Studio für ein Lambda mit void-Rückgabetyp. Erst die Deklaration mittels "-> bool" gestattet dann die Verwendung als Prädikat.

Re: Jammer-Thread

Verfasst: 07.06.2012, 03:31
von dot
Perfekt, genau so wie's im C++ Standard steht ;)

Re: Jammer-Thread

Verfasst: 07.06.2012, 09:16
von Krishty
dot hat geschrieben:Ist der Typ von uint_x tatsächlich unsigned?
Stell dir vor; eigentlich habe ich sogar

    0u != ((uint_x & 0x80u) >> 7u)

geschrieben … ich wollte es nur nicht zu kompliziert machen, weil es dann keiner liest. Die Berechnung hängt in einer Funktion; der Vergleich findet mit dem Rückgabewert der Funktion statt. Aber da die Funktion geinlinet wird, sollte das egal sein und entspricht tatsächlich obigem Fragment.

Ich habe nun einfach eine zweite Funktion geschrieben, die die Bitschieberei weglässt und das Vergleichsergebnis via bool zurückgibt. Jetzt flutscht es.

————

Wie kann man im Startmenü bloß den Pfeil, über den man zum Ruhezustand-Knopf kommt, neben einem gigantischen Herunterfahren-Knopf platzieren? Ich habe gestern abend schon wieder versehentlich meinen PC runtergefahren (und damit Daten und endlose Zeit zum Booten verloren) … wenn ich in den Energieplaneinstellungen unter Netzschalter und Zuklappen die Standardaktion für Beenden auf Energie sparen stelle, passiert einfach nichts. Unter Vista ging das noch.

Re: Jammer-Thread

Verfasst: 07.06.2012, 11:10
von spobat
@Krishty
Wieso muss ich auf "Start" klicken wenn ich herunterfahren will? ;)

Re: Jammer-Thread

Verfasst: 07.06.2012, 11:37
von Krishty
Das ist was völlig anderes …
meh.png
meh.png (4.87 KiB) 2678 mal betrachtet
Ich hasse das

————

Außerdem hat Cat mit den Bots recht – 1016 Gäste sind mir irgendwie nicht geheuer.

Re: Jammer-Thread

Verfasst: 07.06.2012, 11:40
von CodingCat
Vielleicht hilft Start-Rechtsklick -> Properties -> Power button action.

Re: Jammer-Thread

Verfasst: 07.06.2012, 11:43
von CodingCat
Krishty hat geschrieben:Außerdem hat Cat mit den Bots recht – 1016 Gäste sind mir irgendwie nicht geheuer.
Das wiederum sieht mir mehr danach aus, als wollte gerade jemand den wertvollen Inhalt von ZFX archivieren (oder kopieren?!).
80legs offers powerful web crawling. Extract data from web pages, images, and any other online content. [...]

Re: Jammer-Thread

Verfasst: 07.06.2012, 20:38
von Krishty
CodingCat hat geschrieben:Vielleicht hilft Start-Rechtsklick -> Properties -> Power button action.
Ja! Danke. Verdammt; warum bin ich da nicht selber draufgekommen … wieder mal zu viel gestänkert.

Re: Jammer-Thread

Verfasst: 08.06.2012, 01:02
von eXile
Zed A. Shaw - The Web Will Die When OOP Dies

Außerdem sind meine bisherigen Erfahrungen mit der DirectXMath-Library eher negativ. Die wollen auf Deubel komm raus einen dazu verleiten, alles mit XMVECTORen (intern __m128) zu berechnen; selbst wenn ich nur mal zwei XMFLOAT2s (intern zwei floats) addieren will, geht das nicht, denn die haben keine Operatoren für XMFLOAT2s definiert. Das wäre ja noch OK.

Aber bevor einer fragt: Natürlich haben die auch keine zweidimensionalen Vektoren definiert, die intern mit __m128 arbeiten. Warum auch.

(… buhhhhlshit …)

Re: Jammer-Thread

Verfasst: 08.06.2012, 01:57
von CodingCat
Ich versuche seit einer Stunde, die falsche Ausgabe meines Präfixsummen-Shaders nachzuvollziehen. Ich habe bereits tonnenweise Texturdaten zurückgelesen, das einzige, was ich bis jetzt fixen konnte, ist der Texture Readback. Ich habe heute den ganzen Tag damit verbracht, missglückte Resource Bindings aufzuspüren und Resource Hazards aufzulösen. Das einzige, was bis jetzt kaum Fehler hatte, war der Shader Code selbst. Diese ganze Compute API ist doch ein einziger aufgeblasener Witz, der Programmierer mit maximaler Redundanz (und damit Fehlerquellen!) bei minimaler Dokumentation in den Wahnsinn treiben soll.

Re: Jammer-Thread

Verfasst: 08.06.2012, 12:43
von CodingCat
HLSL:
uint2 threadIdxTest = (threadIdx >> 1); // threadIdx [0 .. 7]
threadIdxTest.x = threadIdxTest.x & 0xfffffffe;
threadIdxTest.y = threadIdxTest.y & 0xfffffffe;


ASM:
l(0,0,0,0)

OH REALLY?!? DARAN DEBUGGE ICH SEIT NUNMEHR 24 STUNDEN?!?

Re: Jammer-Thread

Verfasst: 08.06.2012, 12:48
von Artificial Mind
Ich sehe gerade nicht, was daran falsch ist...

(Also am HLSL-Code)

Re: Jammer-Thread

Verfasst: 08.06.2012, 12:49
von j.klugmann
NVIDIA mag keine For-Schleifen in GLSL-Shadern im 330 Compatibility Profile...

Re: Jammer-Thread

Verfasst: 08.06.2012, 12:50
von CodingCat
Nichts. Wie es scheint, hat der HLSL-Compiler eine ganze Palette von Bitoptimierungen drauf, die irgendwas berechnen, aber ganz sicher nicht das, was im HLSL-Code steht.

Re: Jammer-Thread

Verfasst: 08.06.2012, 12:51
von j.klugmann
Das Compatibility Profile scheint noch kaputter zu sein, als gedacht:
"[..] = xSobel[ (i * 3) + j ];"
==>
"lvalue in array access too complex"

Re: Jammer-Thread

Verfasst: 08.06.2012, 12:53
von CodingCat
HLSL
uint2 threadIdxTest = (threadIdx >> 1) & 0xfffffffe;
OffsetFieldUAV[dispatchIdx] = threadIdxTest.y * 4 + threadIdxTest.x;


ASM
and r0.x, vThreadIDInGroup.x, l(4)
ubfe r0.x, l(3), l(1), r0.x
store_uav_typed u0.xyzw, vThreadID.xyyy, r0.xxxx // OffsetFieldUAV<0>


Ich habe KEINE AHNUNG, WAS er da tut. Aber alleine die Tatsache, dass threadIdx.y überhaupt nicht vorkommt ...

Re: Jammer-Thread

Verfasst: 08.06.2012, 13:05
von Schrompf
Dagegen ist mein Gejammer ja ganz profan. Direct3D9-Shader Compiler:

Code: Alles auswählen

for( int a = 1; a < ANZAHL; ++a )
{ /* ... */ }

for( int a = 1; a < ANZAHL; ++a )
{ /* was anderes */ }
führt zu
HLSL Compiler hat geschrieben:warning X3078: 'a': loop control variable conflicts with a previous declaration in the outer scope; most recent declaration will be used
Äh... nein? Es gibt keine "declaration in the outer scope". Nur Stümper auf dieser Welt.

Re: Jammer-Thread

Verfasst: 08.06.2012, 13:07
von Artificial Mind
Cat, sei froh, dass du dir den asm-Code angucken kannst. Wir auf der OGL Seite können das nämlich nicht (mehr).

Re: Jammer-Thread

Verfasst: 08.06.2012, 13:12
von CodingCat
Müll:
uint2 threadIdxTest = ((threadIdx) >> 1) & 0xfffffffe;

Korrekt:
uint2 threadIdxTest = ((threadIdx + ZeroViaCBuffer) >> 1) & 0xfffffffe;

Ganz offensichtlich macht dieses Drecksteil vollkommen falsche Annahmen über den Wertebereich von SV_GroupThreadID.

Schrompf: Ohja. Ganz zweifellos haben sie als Grundlage für den fxc den ältesten und verschissensten C-Compiler rausgekramt, den sie in ihren Bergen von kaputtem MS-Compilercode finden konnten.

Re: Jammer-Thread

Verfasst: 08.06.2012, 14:10
von Matthias Gubisch
Auch mal was zu Jammern
Warum schaffen die bei Nokia es nicht vorkompilierte Binarys für x86 und x64 von QT anzubieten sondern ich muss auf Windows den Mist jedesmal selbst bauen wenn ich beide Konfigurationen haben will.
Das nervt :(

Re: Jammer-Thread

Verfasst: 08.06.2012, 16:15
von CodingCat
Mein Debugger braucht seit heute morgen > 30s zum Starten (auf meinem i7!) und genauso lang zum Beenden, und ich habe keine Ahnung warum. Ganz Visual Studio ist in diesem Zeitraum eingefrohren.

Re: Jammer-Thread

Verfasst: 08.06.2012, 18:52
von Krishty
CodingCat hat geschrieben:Mein Debugger braucht seit heute morgen > 30s zum Starten (auf meinem i7!) und genauso lang zum Beenden, und ich habe keine Ahnung warum. Ganz Visual Studio ist in diesem Zeitraum eingefrohren.
Ist bei uns fast schon Routine … lösch alle Haltepunkte; Deaktivier das Laden von Symboldateien von Systembibliotheken; lösch die <SolutionName>.sdf im Lösungsverzeichnis und den ipch-Ordner; lösch alle temporären Dateien und kompilier komplett neu.