On 2 May 2011 13:20, Emanuele Oriani wrote:
> Hi, let me agree with you... probably there might be one or two fixes
> somewhere which will make performance go better, but apparently the idea is
> that now, if "early optimization is the root of all evils" was true a while
> a go, I guess we're at a
Hi, let me agree with you... probably there might be one or two fixes
somewhere which will make performance go better, but apparently the idea
is that now, if "early optimization is the root of all evils" was true a
while a go, I guess we're at a place where all the small optimizations
should t
On Sunday 01 May 2011 14:34:53 Emanuele Oriani wrote:
> Indeed, I've written a spinlock with GCC extension and replaced the
> EnterCriticalSection in the x11 drv file.
> Apart that the lock has got to be recursive, so I implemented a quick
> (but incorrect) recursive spinlock for the purpose of run
Indeed, I've written a spinlock with GCC extension and replaced the
EnterCriticalSection in the x11 drv file.
Apart that the lock has got to be recursive, so I implemented a quick
(but incorrect) recursive spinlock for the purpose of running SC2 and
difference was barely negligible.
The biggest
On Saturday 30 April 2011 18:26:04 Emanuele Oriani wrote:
> Hi Stefan,
>
> What do you think about using inline spinlocks (in asm code maybe) to
> implement locks?
> Clearly an optimized spinlock would mean different code for different
> compilers/architectures, but shouldn't it be the best soluti
On Saturday 30 April 2011 17:18:54 Stefan Dösinger wrote:
> 9-11) Distributor / End use choice. Note that some compiler
> flags(especially the framepointer one) can break apps and copy protection
> systems.
Forget about -O3. I can't get any Windows game working with that. Apparently I
am already l
Hi Stefan,
What do you think about using inline spinlocks (in asm code maybe) to
implement locks?
Clearly an optimized spinlock would mean different code for different
compilers/architectures, but shouldn't it be the best solution?
For your reference, once I commented out the GL locks to see St
Hi,
Here's another update.
First I expanded my performance tests at https://84.112.174.163/~git/perftest
a bit. The old tests were renamned to streamsrc_d3d and streamsrc_gl, and I
added another set of tests that just tests the draw overhead without ever
changing any states: drawprim_d3d and dr
Hi,
I spent a few hours debugging wined3d performance today. No, I found no magic
fix for the slowness, just some semi-usable data.
First I wrote a hacky patch to avoid redundant FBO applications. This gave a
tiny, tiny performance increase, see http://www.winehq.org/pipermail/wine-
devel/2011-
