Here some news on my DIB Engine :
Corrected some small bugs in text handling (still VERY poor) Corrected a couple of crashes Added code to enable/disable by environment or registry Made optionals all engine stubs FIXMEs (speeds up a lot....)
The engine is disabled by default; can be changed by environment variable :
export WINEDIB=ON (or ENABLE or ENABLED or TRUE) enables it export WINEDIB=OFF (or DISABLE or DISABLED or FALSE) disables it
or by registry key :
HKCU/Software/Wine/DIB Engine/Enable='Y' enables it HKCU/Software/Wine/DIB Engine/Enable='N' disables it
the environment variable has precedence on registry, so for example if WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is enabled.
I suggest to use the environment for the moment, at less you have an app that runs much better with the engine (autocad, for example...) which benefits from a default enabled engine in registry.
Still many many things to do, the most noticeable by now is the missing ROP operations on blitting (and the semi-stub stretchblt...) which is quite noticeable in autocad, for example.
I'm pasting a zipped patch of today's current git.
Ciao
Max
2009/1/25 Massimo Del Fedele max@veneto.com:
The engine is disabled by default; can be changed by environment variable :
export WINEDIB=ON (or ENABLE or ENABLED or TRUE) enables it export WINEDIB=OFF (or DISABLE or DISABLED or FALSE) disables it
or by registry key :
HKCU/Software/Wine/DIB Engine/Enable='Y' enables it HKCU/Software/Wine/DIB Engine/Enable='N' disables it
the environment variable has precedence on registry, so for example if WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is enabled.
I suggest to use the environment for the moment, at less you have an app that runs much better with the engine (autocad, for example...) which benefits from a default enabled engine in registry.
I'm still opposed to adding an environment variable for something so simple (an enable/disable flag). It just seems like extra work for no benefit to me. I'm sure we can all agree that the registry is a suitable place for the setting.
Isn't the idea that the DIB engine will only be used as needed, and will be good in all cases where it's used? If that's the case, it's not too important having on-the-fly per-application enabling/disabling (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
2009/1/25 Massimo Del Fedele max@veneto.com:
The engine is disabled by default; can be changed by environment
variable :
export WINEDIB=ON (or ENABLE or ENABLED or TRUE) enables it export WINEDIB=OFF (or DISABLE or DISABLED or FALSE) disables it
or by registry key :
HKCU/Software/Wine/DIB Engine/Enable='Y' enables it HKCU/Software/Wine/DIB Engine/Enable='N' disables it
the environment variable has precedence on registry, so for example if WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is enabled.
I suggest to use the environment for the moment, at less you have an app that runs much better with the engine (autocad, for example...) which benefits from a default enabled engine in registry.
I'm still opposed to adding an environment variable for something so simple (an enable/disable flag). It just seems like extra work for no benefit to me. I'm sure we can all agree that the registry is a suitable place for the setting.
Isn't the idea that the DIB engine will only be used as needed, and will be good in all cases where it's used? If that's the case, it's not too important having on-the-fly per-application enabling/disabling (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
Having an environment variable is a minor detail. Sure it should be used transparently but it will take a lot of time (when the architecture is correct) to enable it by default. A lot of performance tuning would be needed as it could seriously decrease performance in a lot of cases. The gain / loss depends on what type of calls the program is making. If it draws lets say on a line by line basis then software rendering could help. But if it uses a smarter method a single X call might be more efficient. Further there are also other tradeoffs e.g. when the latest version of the drawable is in X then it might not be smart at all to copy it back to the DIB engine and let it do the rendering just because we have a DIB engine. The cost for the download and reupload to the videocard might be much higher.
Roderick
Roderick Colenbrander ha scritto:
Having an environment variable is a minor detail. Sure it should
be used transparently but it will take a lot of time (when the architecture is correct) to enable it by default.
IMHO the engine will (if it ever enters on main trunk....) stay disabled by default for long, long time. Having it to work ok to the same extent as is gdi32/winex11 now will take a lot of time and patches.
A lot of performance tuning would be needed as it could seriously decrease performance in a lot of cases.
I agree completely on this
The gain / loss depends on what type of calls the program is making. If it draws lets say on a line by line basis then software rendering could help. But if it uses a smarter method a single X call might be more efficient.
More precisely, it will depend on the degree of optimization of dib engine code which, by now, is close to zero. When blitting will be optimized, for example, the performance increase will be huge.
Further there are also other tradeoffs e.g. when the latest version of the drawable is in X then it might not be smart at all to copy it back to the DIB engine and let it do the rendering just because we have a DIB engine. The cost for the download and reupload to the videocard might be much higher.
The engine, as it is now, just renders on DIBs, when they're in memory, not on DDB. So it shouldn't penalize at all the rendering of drawables already owned by X. It'll just avoid the double copy between dib and x ant the way back just to, for example, render some text. That happens now in autocad, for example, which slows it down by a factor off 100. The only "mixed" behaviour is when you're blitting a dib onto a ddb (or the way around), but even then the code converts the source bitmap to the destination format and then uses the best way to blit it. It could even be optimized by blitting without converting before, but it would need some hard intervention on GDI code, which is what I wanted to avoid.
Ciao
Max
On Sun, Jan 25, 2009 at 10:23 AM, Massimo Del Fedele max@veneto.com wrote:
...IMHO the engine will (if it ever enters on main trunk....) stay disabled by default for long, long time. Having it to work ok to the same extent as is gdi32/winex11 now will take a lot of time and patches. ...
I haven't looked into your implementation in much detail (I need more hours in a day, I swear), but would it be possible to pass all the stubs on so that unimplemented functionality still works even if it's dog slow? It'd be nice if we could take advantage of the implemented features, still be able to handle everything, and then spew a "FIXME: Help Wine run faster by implementing this function in the DIB engine!" for features that are not handled yet. (yeah, yeah, I want my cake and be able to eat it too)
Erich Hoover ehoover@mines.edu
Erich Hoover ha scritto:
I haven't looked into your implementation in much detail (I need more hours in a day, I swear), but would it be possible to pass all the stubs on so that unimplemented functionality still works even if it's dog slow? It'd be nice if we could take advantage of the implemented features, still be able to handle everything, and then spew a "FIXME: Help Wine run faster by implementing this function in the DIB engine!" for features that are not handled yet. (yeah, yeah, I want my cake and be able to eat it too)
Erich Hoover ehoover@mines.edu mailto:ehoover@mines.edu
Well, by now many functions are stubbed (with disabled FIXMEs for speed), and 3 apps I've tested on it works ok. Some bad graphics, but mostly usable. You can test it easily and, if you like, you can enable all the stubs FIXMEs uncommenting a #define on header file.
Ciao
Max
On Sun, Jan 25, 2009 at 11:25 AM, Massimo Del Fedele max@veneto.com wrote:
Erich Hoover ha scritto:
I haven't looked into your implementation in much detail (I need more hours in a day, I swear), but would it be possible to pass all the stubs on so that unimplemented functionality still works even if it's dog slow? It'd be nice if we could take advantage of the implemented features, still be able to handle everything, and then spew a "FIXME: Help Wine run faster by implementing this function in the DIB engine!" for features that are not handled yet. (yeah, yeah, I want my cake and be able to eat it too)
Erich Hoover ehoover@mines.edu mailto:ehoover@mines.edu
Well, by now many functions are stubbed (with disabled FIXMEs for speed), and 3 apps I've tested on it works ok. Some bad graphics, but mostly usable. You can test it easily and, if you like, you can enable all the stubs FIXMEs uncommenting a #define on header file.
Ciao
Max
What I was trying to say is if you could have something like this for all the stubs: ---- BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT widthDst, INT heightDst, DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT widthSrc, INT heightSrc, BLENDFUNCTION blendfn) { FIXME("reverting to slow behavior!\n"); return TheOldBehavior->AlphaBlend(...); } ----
While I'm obviously not greatly familiar with this code, it seems like the engine would have a better chance of being successful if unimplemented features fell back to the old behavior. It seems like that would allow you to gradually transition over to the integrated DIB engine a little bit at a time, rather than having a lot of unavailable features that would all need to be implemented before the integrated DIB engine could be turned on for everyone. Even if you had to create a special surface and copy the bitmap back and forth every time you had to revert to the old behavior it seems like it would at least provide a good testbed.
Erich Hoover ehoover@mines.edu
Erich Hoover ha scritto:
What I was trying to say is if you could have something like this for all the stubs:
BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT widthDst, INT heightDst, DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT widthSrc, INT heightSrc, BLENDFUNCTION blendfn) { FIXME("reverting to slow behavior!\n"); return TheOldBehavior->AlphaBlend(...); }
While I'm obviously not greatly familiar with this code, it seems like the engine would have a better chance of being successful if unimplemented features fell back to the old behavior. It seems like that would allow you to gradually transition over to the integrated DIB engine a little bit at a time, rather than having a lot of unavailable features that would all need to be implemented before the integrated DIB engine could be turned on for everyone. Even if you had to create a special surface and copy the bitmap back and forth every time you had to revert to the old behavior it seems like it would at least provide a good testbed.
Erich Hoover ehoover@mines.edu mailto:ehoover@mines.edu
Well... almost impossible by keeping GDI and driver structure separated. You call winex11 whith its physDev, and WineDib with it's own (different) physDev. Either don't have knowledge of other's structure (they're opaque pointers), nor they have e pointer of each other. So, from Dib driver is impossible to call an x11 driver function. That could be done directly from inside GDI32, but would require some deep changes on it, which I wanted to avoid. BTW, I'm still thinking that the "better" way of adding the dib engine would be from inside gdi32, but whis would mean to change deeply a code that is working good. Another possibility would be to add a pointer to x11 physDev inside the Dib physDev.... that one would be easier, but hacky.
Ciao
Max
Ben Klein ha scritto:
I'm still opposed to adding an environment variable for something so simple (an enable/disable flag). It just seems like extra work for no benefit to me. I'm sure we can all agree that the registry is a suitable place for the setting.
The environment variable allows testing on the fly of enabled/disabled engine, AND allows to run some apps with engine enabled as others with engine disabled. Having to run regedit just to test an app run is overkilling, IMHO. BTW, the environment variable is fully optional, you can but you haven't to use it, if you choose so. just set the registry variable and all is ok.
Isn't the idea that the DIB engine will only be used as needed, and will be good in all cases where it's used? If that's the case, it's not too important having on-the-fly per-application enabling/disabling (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
The engine, as it is, is by far less than complete, so very few apps do benefit of it, one of them is autocad, at the moment. I guess most apps are penalized by the engine in present state. So I really don't see the point of avoiding an environment var which, BTW, is checked just ONCE and on first loading of the DIB driver, and costs just about 5 lines of code.
Max
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
Ciao
Max
2009/1/27 Massimo Del Fedele max@veneto.com:
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
Hi,
I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry).
My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it).
The only thing I would say is to break it up. For example, there are bits that you have taken from Jesse and Huw's efforts that are various isolated patches. These should be sent in a git patch format so that the authors can be attributed in the Wine git tree as well as being in the Copyright notices. Aside from that, if you could break the DIB patch into smaller logical chunks it will be easier to review and get the patches in.
Have you asked Alexandre on IRC what he thinks of the design?
- Reece
Reece Dunn ha scritto:
2009/1/27 Massimo Del Fedele max@veneto.com:
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
Hi,
I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry).
Thanx, that was what I wanted to have :-)
My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it).
Yep, the blitting code is just a "placeholder" to make most apps run, not an optimized one. Making it optimized is trivial but requires many code lines, so before proceeding I thought to wait for "approval" of the way the engine is done. The same is for text stuffs.
The only thing I would say is to break it up. For example, there are bits that you have taken from Jesse and Huw's efforts that are various isolated patches. These should be sent in a git patch format so that the authors can be attributed in the Wine git tree as well as being in the Copyright notices.
Well, that one could be only partially done, because I modified most of both Huw and Jesse's code. I let Jesse and Huw's copyright notices because of that, but going back from original code, joining the 2 and adding my mods by mean of many git patches would be overkilling. Even more, both trees were somehow outdated in respect to actual wine tree, so the automatic merge didn't work for some parts of code. I'd see easier to put the 3 names on each patch when (if) merged with main tree.
Aside from that, if you could break the DIB
patch into smaller logical chunks it will be easier to review and get the patches in.
Well, that also can be partially done :
1- First GDI32 patch, the one that allows to insert DIB Driver, without blitting (mostly from Huw's tree, but driver loading displaced from SelectBitmap to CreateDC by me, with some additions to avoid crashes if driver is not present. 2 - Starting dib engine, without blitting and (maybe) many stubs, but with primitives and some basic stuffs, mostly from Huw's tree, some small patches by me 3 - Blitting, which requires both patching GDI32 again and adding the code to DIB driver, and all stubs; all that mostly from Jesse's tree, many patches by me 4 - Initial text and font implementation, by me 5 - Registry and environment variable stuffs, by me
Most chunks need to span over more source files. After that, I guess the code is defined enough to be opened for completion.
Have you asked Alexandre on IRC what he thinks of the design?
No.... I'm not using IRC since ages :-) Is this the way to ask him ?
- Reece
Ciao and thanx for comments !
Max
On Tue, Jan 27, 2009 at 1:51 PM, Massimo Del Fedele max@veneto.com wrote:
Reece Dunn ha scritto:
2009/1/27 Massimo Del Fedele max@veneto.com:
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
Hi,
I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry).
Thanx, that was what I wanted to have :-)
My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it).
Yep, the blitting code is just a "placeholder" to make most apps run, not an optimized one. Making it optimized is trivial but requires many code lines, so before proceeding I thought to wait for "approval" of the way the engine is done. The same is for text stuffs.
The only thing I would say is to break it up. For example, there are bits that you have taken from Jesse and Huw's efforts that are various isolated patches. These should be sent in a git patch format so that the authors can be attributed in the Wine git tree as well as being in the Copyright notices.
Well, that one could be only partially done, because I modified most of both Huw and Jesse's code. I let Jesse and Huw's copyright notices because of that, but going back from original code, joining the 2 and adding my mods by mean of many git patches would be overkilling. Even more, both trees were somehow outdated in respect to actual wine tree, so the automatic merge didn't work for some parts of code. I'd see easier to put the 3 names on each patch when (if) merged with main tree.
Aside from that, if you could break the DIB
patch into smaller logical chunks it will be easier to review and get the patches in.
Well, that also can be partially done :
1- First GDI32 patch, the one that allows to insert DIB Driver, without blitting (mostly from Huw's tree, but driver loading displaced from SelectBitmap to CreateDC by me, with some additions to avoid crashes if driver is not present. 2 - Starting dib engine, without blitting and (maybe) many stubs, but with primitives and some basic stuffs, mostly from Huw's tree, some small patches by me 3 - Blitting, which requires both patching GDI32 again and adding the code to DIB driver, and all stubs; all that mostly from Jesse's tree, many patches by me 4 - Initial text and font implementation, by me 5 - Registry and environment variable stuffs, by me
Most chunks need to span over more source files. After that, I guess the code is defined enough to be opened for completion.
Have you asked Alexandre on IRC what he thinks of the design?
No.... I'm not using IRC since ages :-) Is this the way to ask him ?
He's usually on IRC, nickname julliard.
Though, to be frank, his lack of response to the e-mails leads me to believe either: A) He doesn't like the design. B) Is really busy, and hasn't had time to look it thoroughly. C) Both.
2009/1/27 Massimo Del Fedele max@veneto.com:
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
Hi,
I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry).
My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it).
In the end a dib engine will help a bit for StarCraft but for StarCraft the only proper way for hardware acceleration is to use the ddraw-gl backend in combination with the right rendertargetlockmode. Some games can really use a DIB engine though and that are games like Age of Empires I and II. Though in combination with a DIB engine more changes are needed for optimal performance (e.g. allow the DIB engine to directly draw into a ddraw surface without a memcpy)
Roderick
2009/1/27 Roderick Colenbrander thunderbird2k@gmx.net:
2009/1/27 Massimo Del Fedele max@veneto.com:
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry).
My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it).
In the end a dib engine will help a bit for StarCraft but for StarCraft the only proper way for hardware acceleration is to use the ddraw-gl backend in combination with the right rendertargetlockmode. Some games can really use a DIB engine though and that are games like Age of Empires I and II. Though in combination with a DIB engine more changes are needed for optimal performance (e.g. allow the DIB engine to directly draw into a ddraw surface without a memcpy)
Sure,
I wasn't expecting a speed boost here, because the implementation is essentially a proof of concept - hence me saying that the blitting code was not optimised .
The game was functional; no noticible visual regressions, which is good. I haven't done any more testing yet.
Another thing this should improve is the theme rendering for alpha-blended images, but likely not at the moment.
- Reece
On Tue, Jan 27, 2009 at 12:29 PM, Reece Dunn msclrhd@googlemail.com wrote:
2009/1/27 Massimo Del Fedele max@veneto.com:
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ?
Hi,
I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry).
My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it).
The DIB engine is really unlikely to help starcraft the game at all. However, try staredit.exe ;)
Jesse
Jesse Allen ha scritto:
The DIB engine is really unlikely to help starcraft the game at all. However, try staredit.exe ;)
Jesse
The engine in its current state will, IMO, help just those apps that don't require real time graphics but do make many drawings on dibs, so requiring many conversions between dib itself and X11. For example, apps with tons of text drawings on dibs will benefit greatly with the engine. Optimizing blitting will increase the number of such apps. Keep in mind that by now the blitting is a slow sequence of read pixel-convert format-write pixel, with no care if source and destination bitmaps have the same format, for example, which could be handled by simple memmove. It doesn't handle clipping, either, nor ROP operations.
For Autocad (with many TT fonts on drawing) the speed gain is something like 50x - 100x, depending on the amount of text objects.... I don't know staredit, but I'd like to know what is the speed increase :-)
Ciao
Max
-
Austin English -
Ben Klein -
Erich Hoover -
Jesse Allen -
Massimo Del Fedele -
Reece Dunn -
Roderick Colenbrander