New d3d8 code and FFXIBench3 - pretty good!

[Al Tobey]

I just tried the new d3d8 code with FFXiBench3 again tonight and it's
pretty good!    The textures are mostly there and there are only a
handful of recurring glitches.    This demo is downloadable from
http://www.playonline.com.

Some textures had their colors munged up.   I assume this is related
to earlier discussions about RGB_ v.s. BGR_ formats.
Screenshots:
http://img238.imageshack.us/img238/9879/screenshot28hh.jpg
http://img48.imageshack.us/img48/4135/screenshot35wa.jpg
http://img48.imageshack.us/img48/28/screenshot48xx.jpg

I got a lot of these two messages:
fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking
to Rendering surface surf@0x7d388550 usage(1)
fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces
not implemented, returning D3DERR_INVALIDCALL

I'll play around with my CopyRects patch a bit and see if I can get it
to work properly then submit it.   I'm not convinced MSDN is telling
the whole truth about how partial copies should work.

Keep up the good work!
-Al Tobey

[Stefan Dösinger]

Hi,
> I got a lot of these two messages:
> fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking
> to Rendering surface surf@0x7d388550 usage(1)
> fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces
> not implemented, returning D3DERR_INVALIDCALL
>
> I'll play around with my CopyRects patch a bit and see if I can get it
> to work properly then submit it.   I'm not convinced MSDN is telling
> the whole truth about how partial copies should work.

This CopyRect functionality could be implemented using 
IWineD3DSurface::BltFast, once my DirectDraw patches are in.

[Coleman Kane]

On Wed, 2006-03-01 at 07:50 +0100, Stefan Dösinger wrote:
> Hi,
> > I got a lot of these two messages:
> > fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking
> > to Rendering surface surf@0x7d388550 usage(1)
> > fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces
> > not implemented, returning D3DERR_INVALIDCALL
> >
> > I'll play around with my CopyRects patch a bit and see if I can get it
> > to work properly then submit it.   I'm not convinced MSDN is telling
> > the whole truth about how partial copies should work.
>
> This CopyRect functionality could be implemented using 
> IWineD3DSurface::BltFast, once my DirectDraw patches are in.

Hi. I've been dealing with a program that seems to be very slow at
Blitting images onto a D3D surface. Unfortunately, this is not my code
so I can't fix it. Would the above mentioned BltFast/CopyRect patches
deal with code that attempts to provide this feature?

--
Coleman Kane
IntelliTree Solutions llc.

[Stefan Dösinger]

> Hi. I've been dealing with a program that seems to be very slow at
> Blitting images onto a D3D surface. Unfortunately, this is not my code
> so I can't fix it. Would the above mentioned BltFast/CopyRect patches
> deal with code that attempts to provide this feature?

Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty 
slow on that cards. BltFast won't fix that, it needs a better UnlockRect 
implementation in WineD3D. I tried to do that, but I failed because of a lack 
of gl knowledge, but I'll make another attempt sooner or later?

[Coleman Kane]

Its actually an i865 and "must remain" an i865. Its amazing, the 3D
performance (with shadows and all) is pretty fast if I disable the code
that results in the screen blits.

It looks like it may actually be running them through some "Stretch
Blit" function. I don't know if this might translate down to a D3D call
or not that does a size transform at the time of Blit.

If you'd like, I'd be willing to help out if I can on getting this
working better. Sounds like you've gotten a head start on it.

--
Coleman Kane
IntelliTree Solutions llc.

On Wed, 2006-03-01 at 09:05 +0100, Stefan Dösinger wrote:
> > Hi. I've been dealing with a program that seems to be very slow at
> > Blitting images onto a D3D surface. Unfortunately, this is not my code
> > so I can't fix it. Would the above mentioned BltFast/CopyRect patches
> > deal with code that attempts to provide this feature?
>
> Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty 
> slow on that cards. BltFast won't fix that, it needs a better UnlockRect 
> implementation in WineD3D. I tried to do that, but I failed because of a lack 
> of gl knowledge, but I'll make another attempt sooner or later?

[Stefan Dösinger]

Hi,
> Its actually an i865 and "must remain" an i865. Its amazing, the 3D
> performance (with shadows and all) is pretty fast if I disable the code
> that results in the screen blits.

I have never used an Intel chip, so I can't judge about it's speed.
> If you'd like, I'd be willing to help out if I can on getting this
> working better. Sounds like you've gotten a head start on it.

I'm quite busy now with finishing my ddraw patch, but when that is in and the 
regressions are out, I'll ask for apps that aren't working as they should, 
and then I can look at it.
Except, if you desperatly need this blits working, I can have a quick look at 
it.

[Aric Cyr]

Stefan Dösinger <stefandoesinger <at> gmx.at> writes:
> > Hi. I've been dealing with a program that seems to be very slow at
> > Blitting images onto a D3D surface. Unfortunately, this is not my code
> > so I can't fix it. Would the above mentioned BltFast/CopyRect patches
> > deal with code that attempts to provide this feature?
>
> Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty 
> slow on that cards. BltFast won't fix that, it needs a better UnlockRect 
> implementation in WineD3D. I tried to do that, but I failed because of a lack 
> of gl knowledge, but I'll make another attempt sooner or later?

If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help.  We
could set up a time to chat/irc off-list or if you want I could see if I can get
your existing stuff to work (just send me the diffs).

Regards,
  Aric

[Stefan Dösinger]

> If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help.
>  We could set up a time to chat/irc off-list or if you want I could see if
> I can get your existing stuff to work (just send me the diffs).

I'll publish a patch in the next days, I just want to fix S3TC decompression 
and perhaps get my hands on Diablo 2.

The problem I have with GL ATM is UnlockRect. The current code in 
WineD3DSurface::UnlockRect doesn't work with a lot of cards / drivers(radeon, 
fglrx and mesa software rendering fail). glReadPixels and glWritePixels is 
horribly slow on radeons, it takes 1-4 secounds for an 800x600 image.

So what I need is an UnlockRect code for render targets that doesn't use 
glDrawPixels. I have written a code that replaces ReadPixels with copying the 
render target to a texture and reading back the texture, this works much 
better. I tried to write an UnlockRect code that loads a temporary texture 
and Draws a textured quad, but the quad had the solid color of the first 
pixel.

Thanks for your help :)
Stefan

[Aric Cyr]

Stefan Dösinger <stefandoesinger <at> gmx.at> writes:
> > If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help.
> >  We could set up a time to chat/irc off-list or if you want I could see if
> > I can get your existing stuff to work (just send me the diffs).
>
> I'll publish a patch in the next days, I just want to fix S3TC decompression 
> and perhaps get my hands on Diablo 2.

I own Diablo 2... this would be a good reason to dust it off :)
> The problem I have with GL ATM is UnlockRect. The current code in 
> WineD3DSurface::UnlockRect doesn't work with a lot of cards / drivers(radeon, 
> fglrx and mesa software rendering fail). glReadPixels and glWritePixels is 
> horribly slow on radeons, it takes 1-4 secounds for an 800x600 image.

I am running fglrx as well, so I could work on getting the performance up on
these cards.  I also have contacts at ATI, so if there are specific problem I
could send feedback directly, and hopefully they can fix things for future
releases.  Although I'd check glDrawPixels on Windows as well... I suspect it is
just as slow there.  Also for glDrawPixels you should turn off a lot of the GL
state (lighting and stuff that you don't need).  That could speed things up a 
bit.
> So what I need is an UnlockRect code for render targets that doesn't use 
> glDrawPixels. I have written a code that replaces ReadPixels with copying the 
> render target to a texture and reading back the texture, this works much 
> better. I tried to write an UnlockRect code that loads a temporary texture 
> and Draws a textured quad, but the quad had the solid color of the first 
> pixel.

Sounds like it shouldn't be too difficult OpenGL problem.  There are a lot of
commands related to texturing, so it is quite easy to muck things up.  I looked
at the code a bit that you posted before, but nothing jumped out at me, although
it would be easier if I had the full code to play with.
> Thanks for your help :)

No problem, anything that will help accelerate the merge of ddraw/d3d7 into
wined3d :)

Regards,
  Aric

[Stefan Dösinger]

Hi,
> I own Diablo 2... this would be a good reason to dust it off :)

I should get it by today :) I ordered it at Amazon for a cheap price. Usually 
it takes 3 days until I get things. Snail mail that is :).
> I am running fglrx as well, so I could work on getting the performance up
> on these cards.  I also have contacts at ATI, so if there are specific
> problem I could send feedback directly, and hopefully they can fix things
> for future releases.  Although I'd check glDrawPixels on Windows as well...
> I suspect it is just as slow there.  Also for glDrawPixels you should turn
> off a lot of the GL state (lighting and stuff that you don't need).  That
> could speed things up a bit.

The attached program illustrates the problem: It's a d3d9 app and runs with 
current Wine CVS. On startup, it shows a black screen. If you press any 
button(except ESC), it will do a Clear with a solid color based on the key 
you pressed. If you click anywhere with the left mouse button, it locks the 
backbuffer, fills it with 0xff, unlocks it and flips. On Mesa radeon this has 
no effect(image doesn't change), with software rendering it's the same, as 
well with fglrx. If you change the pixel format to D3DFMT_R8G8B8, then it 
will work for fglrx. I haven't tested this on Windows, but I was told that it 
works with Nvidia cards in Wine. I just tested it in some old cvscedega 
version, and there it works, although I have to click twice.

If you change D3DSWAPEFFECT_FLIP to D3DSWAPEFFECT_DISCARD in line 121, the 
screen will go black on clicks, with a delay of about one secound, so you can 
see the slowlyness. In some rare cases in games, glDrawPixels writes a dark, 
solid color, and if it writes to the front buffer, it's possible to see the 
new color sliding down slowly.

I suspect that glDrawPixels isn't really broken, but WineD3D sets up render 
states which break it. I wanted to do a test with a simple GL app, but I 
didn't find the time yet. Current DDraw is broken in the same way, but it in 
the most cases, it draws a textured quad instead of using glDrawPixels, which 
works fine there.

[Raphael]

On Wednesday 01 March 2006 05:48, Al Tobey wrote:
> I just tried the new d3d8 code with FFXiBench3 again tonight and it's
> pretty good!    The textures are mostly there and there are only a
> handful of recurring glitches.    This demo is downloadable from
> http://www.playonline.com.
>
> Some textures had their colors munged up.   I assume this is related
> to earlier discussions about RGB_ v.s. BGR_ formats.
> Screenshots:
> http://img238.imageshack.us/img238/9879/screenshot28hh.jpg
> http://img48.imageshack.us/img48/4135/screenshot35wa.jpg
> http://img48.imageshack.us/img48/28/screenshot48xx.jpg
>
> I got a lot of these two messages:
> fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking
> to Rendering surface surf@0x7d388550 usage(1)
> fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces
> not implemented, returning D3DERR_INVALIDCALL
>
> I'll play around with my CopyRects patch a bit and see if I can get it
> to work properly then submit it.   I'm not convinced MSDN is telling
> the whole truth about how partial copies should work.
>
> Keep up the good work!
> -Al Tobey

Good news :)
Seems working correctly

But we must fix all the RGB v.s. BGR problems

Best Regards,
Raphael

[Aric Cyr]

Raphael <fenix <at> club-internet.fr> writes:
> But we must fix all the RGB v.s. BGR problems

I'll submit a patch for this when I get home.  I verified it with Age of
Mythology and the latest CVS (well, from a few days ago).  There are just a
couple of mistakes in d3d8/utils.c (whoops this file is gone now, great!) and
wined3d/utils.c that need fixing, although I don't know if my patch covers all
cases, it certainly works for RGB888, RGB565, RGB332 (8bpp rgb).

For those intested here is a quick patch against dlls/wined3d/utils.c, I'll
submit an "official" one to wine-patches later, in the meantime feedback is
appreciated.

--- dlls/wined3d/utils.c.orig        2006-03-01 19:09:08.000000000 +0900
+++ dlls/wined3d/utils.c     2006-03-01 19:09:32.000000000 +0900
@@ -1703,9 +1703,9 @@
         case WINED3DFMT_Q8W8V8U8:         retVal = GL_RGBA; break;
         case WINED3DFMT_Q16W16V16U16:     retVal = GL_COLOR_INDEX; break;
             /* color buffer */
-        case WINED3DFMT_R3G3B2:           retVal = GL_BGR; break;
-        case WINED3DFMT_R5G6B5:           retVal = GL_BGR; break;
-        case WINED3DFMT_R8G8B8:           retVal = GL_BGR; break;
+        case WINED3DFMT_R3G3B2:           retVal = GL_RGB; break;
+        case WINED3DFMT_R5G6B5:           retVal = GL_RGB; break;
+        case WINED3DFMT_R8G8B8:           retVal = GL_RGB; break;
         case WINED3DFMT_A1R5G5B5:         retVal = GL_BGRA; break;
         case WINED3DFMT_X1R5G5B5:         retVal = GL_BGRA; break;
         case WINED3DFMT_A4R4G4B4:         retVal = GL_BGRA; break;

Regards,
  Aric

[Stefan Dösinger]

Hi,
> For those intested here is a quick patch against dlls/wined3d/utils.c, I'll
> submit an "official" one to wine-patches later, in the meantime feedback is
> appreciated.

I planned sending a similar patch which looked quite the same, but I'll let 
you do this.