ZFX + Developia

kaiserludi hat geschrieben:Wieso verlangt C++ keinen expliziten cast, wenn ich einem void* den Wert eines void** zu weise?

dot hat geschrieben:

kaiserludi hat geschrieben:Wieso verlangt C++ keinen expliziten cast, wenn ich einem void* den Wert eines void** zu weise?

C++ verlangt da sogar einen reinterpret_cast...

void** a;
void* b = a; // compiles just fines

kaiserludi hat geschrieben:Allerdings muss man dann bei der Kommunikation mit bestehender API, welche void* nutzt, immer noch casten.

CodingCat hat geschrieben:Hm, ich bringe es mit ordentlicher Schleifenbedingung tatsächlich nicht zum Laufen. Habe auch schon etliche Male die Branches umgestellt, bringt nix. Eventuell wegen massiver Konkurrenz ganze Warps endlos im Lockzustand? Aber wie käme ein solcher Warp dort hinein? Mögliches Szenario: Warp lockt teilweise, wird suspendet, anderer Warp läuft endlos ohne Suspend?

eXile hat geschrieben:Ich werde mal weiter über das Thema nachdenken; ich jedoch für mich habe noch nie einen flicker-freien, sowohl auf Fermi wie auch Kepler funktionierenden und nicht-deadlockenden Spinlock in einem Pixel-Shader gesehen.

kaiserludi hat geschrieben:Schön wärs, das ist genau, was ich mir wünsche, tut es aber leider nicht. Probiere aus.

MSDN hat geschrieben:Unlike short-circuit evaluation of &&, ||, and ?: in C, HLSL expressions never short-circuit an evaluation because they are vector operations. All sides of the expression are always evaluated.

CodingCat hat geschrieben:

dot hat geschrieben:Ich muss leider nochmal: Sollte wohl >= 0 heißen... ;)

Ich habe die STL bei diesem Projekt bewusst rausgehalten. Aber es gibt ja noch andere Alternativen zu new[], z.B. ordentlich benannte Funktions-Templates zur Allokation und Konstruktion nach Wunsch, welche ich schlussendlich auch gewählt habe.

template<typename Ftype>
Ftype* allocate(size_t count=1u)
{
	size_t* pRaw = reinterpret_cast<size_t*>(GlobalMemoryPoolManager.alloc(sizeof(Ftype)*count+sizeof(size_t)));
	*pRaw = count;
	Ftype* p = reinterpret_cast<Ftype*>(pRaw+1);
	for(size_t i=0; i<count; ++i)
		new(p+i) Ftype();
	return p;
}

template<typename Ftype>
void deallocate(const Ftype* p)
{
	if(!p)
		return;
	size_t* pRaw = (reinterpret_cast<size_t*>(const_cast<Ftype*>(p))-1);
	for(size_t i=*pRaw; i-->0;)
		p[i].~Ftype();
	GlobalMemoryPoolManager.dealloc(pRaw);
}

kaiserludi hat geschrieben:Das funktioniert so natürlich nur für den Default Konstruktor.

kaiserludi hat geschrieben:Wie teile ich dem Funktionstemplate jetzt am besten mit, welchen Konstruktor von Ftype er aufrufen soll [...]

kaiserludi hat geschrieben:[...], ohne dass es zu seiner Kompilierzeit wissen muss, über welche Konstruktoren Ftype verfügt, und ohne unnötige Komplexität für den Aufrufer?

template <class Element>
inline void destruct(Element *destr, Element *destrEnd)
{
        while (destr < destrEnd)
                (--destrEnd)->~Element();
}

template <class Element>
inline void construct(Element *dest, Element *destEnd, ...)
{
        Element *destr = dest;

        try
        {
                for (; dest < destEnd; ++dest)
                        new((void*)dest) Element(...);
        }
        catch (...)
        {
                destruct(destr, dest);
                throw;
        }
}

Zu Flush hat geschrieben:Because Flush operates asynchronously, it can return either before or after the GPU finishes executing the queued graphics commands.

CodingCat hat geschrieben:

Zu Flush hat geschrieben:Because Flush operates asynchronously, it can return either before or after the GPU finishes executing the queued graphics commands.

• Das erste Present() schubst, wie die vorangegangenen Flush()s, das Rendern an und kehrt vor Vollendung zurück.
• Das zweite Present muss auf den Back Buffer (ich habe in meiner Swap Chain nur einen definiert) warten, und damit auch auf Vollendung des allerersten Renderns.

dot hat geschrieben:Verwend Queries (1x D3D11_QUERY_TIMESTAMP_DISJOINT + nx D3D11_QUERY_TIMESTAMP)...

Krishty hat geschrieben:Aber warum kehrt Present #2 auch schon vor Vollendung zurück?!

CodingCat hat geschrieben:IDXGIDevice1::SetMaximumFrameLatency

CodingCat hat geschrieben:IDXGIDevice1::SetMaximumFrameLatency

CodingCat hat geschrieben:

kaiserludi hat geschrieben:[...], ohne dass es zu seiner Kompilierzeit wissen muss, über welche Konstruktoren Ftype verfügt, und ohne unnötige Komplexität für den Aufrufer?

Gar nicht, die aufgerufenen Konstruktoren müssen genau wie bei new oder new[] im Aufrufer-/Instantiierungskontext deklariert worden sein. Wenn sie das sind, erhälst du mit variadischen Templates / Template Overloads über die mitgegebenen Parameter automatisch den richtigen Konstruktoraufruf.

class MyClass
{
public:
MyClass(int a, int b, int c);
};

MyClass* myClass = new MyClass(1, 2, 3);

kaiserludi hat geschrieben:Aber sowas

Code: Alles auswählen

class MyClass
{
public:
MyClass(int a, int b, int c);
};

MyClass* myClass = new MyClass(1, 2, 3);

geht doch, ohne dass die Standardlib weiß, welche Parametertypen die Konstruktoren von MyClass haben, sprich, es kompiliert auch, wenn MyClass nur dem Code bekannt ist, der new MyClass(1, 2, 3) aufruft. Dem Code in der Standardlib hingegen, der new definiert, muss MyClass dafür nicht bekannt sein.
Ich vermute mal, wir haben uns hier einfach missverstanden?

eXile hat geschrieben:

eXile hat geschrieben: Direct3D 11.1 kommt doch. Aber warum dann im Jammer-Thread?

Weil das eher Direct3D 11.05 ist. Es unterstützt nichts, was einen WDDM-1.2-Treiber braucht.

D3D_FEATURE_LEVEL_11_1 braucht WDDM 1.2.

Meiner Einschätzung nach bringt das also exakt Null.