ZFX + Developia

http://msdn.microsoft.com/en-us/library/windows/desktop/ff476457 hat geschrieben:Don't read from a subresource mapped for writing
When you pass D3D11_MAP_WRITE, D3D11_MAP_WRITE_DISCARD, or D3D11_MAP_WRITE_NO_OVERWRITE to the MapType parameter, you must ensure that your app does not read the subresource data to which the pData member of D3D11_MAPPED_SUBRESOURCE points because doing so can cause a significant performance penalty. […]

Note
Even the following C++ code can read from memory and trigger the performance penalty because the code can expand to the following x86 assembly code.

C++ code:

Code: Alles auswählen

*((int*)MappedResource.pData) = 0;

x86 assembly code:

Code: Alles auswählen

xor [eax],0

Use the appropriate optimization settings and language constructs to help avoid this performance penalty. For example, you can avoid the xor optimization by using a volatile pointer or by optimizing for code speed instead of code size.

http://msdn.microsoft.com/en-us/library/windows/desktop/ee418650 hat geschrieben:String operations (MOVS and STOS) and 16-byte SSE reads can be internally reordered

Krishty hat geschrieben:Für einen selbstgeschriebenen Zuweisungsoperator, auf dem die linke Seite volatile ist, bedeutet das: Auch er muss diese Schreibblockade aufweisen.

volatile __m128 a;
volatile __m128 b;
__m128 c;

a = b; // C2678
a = c; // C2678

error C2678: binary '=' : no operator found which takes a left-hand operand of type 'volatile __m128' (or there is no acceptable conversion)
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmmintrin.h(70): could be '__m128 &__m128::operator =(const __m128 &)'
while trying to match the argument list '(volatile __m128, volatile __m128)'

error C2678: binary '=' : no operator found which takes a left-hand operand of type 'volatile __m128' (or there is no acceptable conversion)
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmmintrin.h(70): could be '__m128 &__m128::operator =(const __m128 &)'
while trying to match the argument list '(volatile __m128, __m128)'

eXile hat geschrieben:Da die XMMath aber für alle Datentypen unions auf float-Arrays anbietet, kopiere ich im Augenblick die float-Arrays. Das ist Mist, aber es funktioniert; wahrscheinlich kommst du aber gleich zu einer besseren Lösung.

• einen, der auf __m128 basierte und nach Möglichkeit 1:1 auf ein Register abgebildet wurde – also nur als lokale Variable oder rvalue existieren dürfte; und
• einen, der auf float[4] basierte und für Speicherung ausgelegt war (z.B. als Attribut oder in Datenstrukturen).

Krishty hat geschrieben:Für’s Mappen ist das alles sehr wohl brauchbar – aber nur als Hack.

1. Auf volatile verzichten (so wie wohl 99 % aller Direct3D-Benutzer) und zügig mittels des eingebauten

   Code: Alles auswählen

   XMMATRIX& operator= (const XMMATRIX& M)
   {
   	r[0] = M.r[0]; r[1] = M.r[1]; r[2] = M.r[2]; r[3] = M.r[3];
   	return *this;
   }

   als __m128 kopieren und hoffen, dass alles gut geht? (Eventuell noch mittels _mm_sfence von außen absichern.)
2. Die MSDN beachten, volatile einsetzen und mittels des selbstgebastelten

   Code: Alles auswählen

   VXMMATRIX volatile & operator=(const XMMATRIX& M) volatile
   {
   	_11 = M._11; _12 = M._12; _13 = M._13; _14 = M._14;
   	_21 = M._21; _22 = M._22; _23 = M._23; _24 = M._24;
   	_31 = M._31; _32 = M._32; _33 = M._33; _34 = M._34;
   	_41 = M._41; _42 = M._42; _43 = M._43; _44 = M._44;
   
   	return *this;
   }

   kopieren? (Jaja, Vergleiche von &M == this gab's auch in deren Code nirgendwo, und memcpy könnte man wohl auch benutzen.)
3. Irgendwas anderes? Was wäre die un-hack-igste Möglichkeit, dieses Problem (Benutzung von __m128 und gleichzeitig Beachtung der MSDN) zu lösen?

eXile hat geschrieben:

Krishty hat geschrieben:Für’s Mappen ist das alles sehr wohl brauchbar – aber nur als Hack.

Sorry, dass ich so nachhake, aber ich versuche es zu verstehen. Die Aquire&Release-Semantik beim Lesen&Schreiben ist ja eigentlich gut, denn das verhindert die von der MSDN angesprochenen ungewollten Lesezugriffe.

Krishty hat geschrieben:Ich bin trotzdem von mir überzeugt und glaube, dass von den Leuten, die das Schlüsselwort einsetzen, nur ein Bruchteil die tatsächliche Bedeutung verstanden hat, sondern stattdessen noch ausschließlich an das sich ständig aktualisierende 80er-Jahre-C-Sensorregister glaubt. Das Wort hätte es vor C++0x niemals in den Standard schaffen dürfen.

Jörg hat geschrieben: Zum "Don't read from a subresource mapped for writing" eine Anmerkung. Das liegt einfach daran, dass das Mapping im meisten Fall ein Uncached, Write-Through Mapping ist. D.h. jeder Lesezugriff geht direkt ins RAM, ohne irgendwie vom Cache abgefangen zu werden. Daher die Performance-Einbußen.

Lynxeye hat geschrieben:Das Mapping wird in der Regel Uncached,Write-Combined sein

Jonathan hat geschrieben:Also ich bin ja überaus gespannt auf Clang + Eclipse. Sobald das gut läuft, könnte es sehr gut sein, dass ich mich von Visual Studio verabschiede. Jedenfalls wenn dann Eclipse für C++ so gut ist, wie für Java (immerhin ist Eclipse der Grund, aus dem Java erst erträglich geworden ist).

Jörg hat geschrieben:Es wird nur kritisch, wenn der Compiler aus welchen Gruenden auch immer annehmen sollte, ein Map oder Unmap-Aufruf waere seiteneffektfrei und deshalb Lade/Schreiboperationen "ueber" die Funktionsaufrufe zieht. Und das sollte wirklich nicht passieren.

Lynxeye hat geschrieben:da der MS Compiler anscheinend immer noch glaubt es ist eine gute Idee eine 0 per xor zu erzeugen, statt sie als Konstante zu setzen. Das war auf alten Pentium Prozessoren der Fall, bei modernen CPUs ist das aber nicht mehr so.

Lynxeye hat geschrieben:Der Fall, den die MSDN nennt, ist aber ein ziemlicher Sonderfall, da der MS Compiler anscheinend immer noch glaubt es ist eine gute Idee eine 0 per xor zu erzeugen, statt sie als Konstante zu setzen. Das war auf alten Pentium Prozessoren der Fall, bei modernen CPUs ist das aber nicht mehr so.

dot hat geschrieben:sondern auch was Instruction Level Parallelism angeht.

Intel Software Optimization Manual hat geschrieben:Some micro-ops can execute to completion during rename and are removed from the
pipeline at that point, effectively costing no execution bandwidth. These include:

• Zero idioms (dependency breaking idioms)
• NOP
• VZEROUPPER
• FXCHG

[...]

Instruction parallelism can be improved by using common instructions to clear
register contents to zero. The renamer can detect them on the zero evaluation of the
destination register.

Use one of these dependency breaking idioms to clear a register when possible.

• XOR REG,REG
• SUB REG,REG
• PXOR/VPXOR XMMREG,XMMREG
• PSUBB/W/D/Q XMMREG,XMMREG
• VPSUBB/W/D/Q XMMREG,XMMREG
• XORPS/PD XMMREG,XMMREG
• VXORPS/PD YMMREG, YMMREG

Since zero idioms are detected and removed by the renamer, they have no execution
latency.

Furthermore, they do not consume an issue port or an execution unit. So using zero idioms are preferable than moving 0’s into the register.

Software Optimization Guide for AMD Family 15h Processors hat geschrieben: Rationale
AMD Family 15h processors are able to avoid the false read dependency on the XOR instruction.

Acceptable
mov reg, 0

Preferred
xor reg, reg

Lynxeye hat geschrieben:Warum diskutieren wir eigtl. die solche Sachen immer im Jammerthread?

Ein Garbage Collector ist ein Designfehler.

CodingCat hat geschrieben:Jedes Mal, wenn ich von Dozenten an der Uni vom Java GC vorgeschwärmt bekomme