You could deliberately add some timeslice yield call (dunno how Win32 calls that, but I think there is one: it just ends the current timeslice and lets other threads run).
Try playing with two internal frame buffers, then you could keep locking time down to a minimum: Lock in EndUpdate, swap both buffers, immediately unlock again. In StartUpdate, you'd only give out the current buffer's address without locking. The rendering thread would likewise just lock-transfer-unlock. (when speaking of "lock", feel free to use signalling semaphores like I did)

As far as I understand (feel free to correct misunderstandings), PCIe, AGP and PCI are related this way: all use the same DMA transfer mechanism, there is only one. AGP is simply driven at a higher clock rate, that's why it's faster. The aperture thingy is a mapping table, so that the AGP card can make linear accesses even when the actual contents are scattered throughout physical memory. It should be able to access all 4GB, just not all of it at once (except on athlon64s, since their internal mapping table is big enough for that). PCIe still works mostly like PCI, but it has more data lines and higher clock frequency than AGP, for even more speed. Since PCs begin to break the 4GB barrier, PCIe has a certain addressing mode which allows to use 36- or 48-bit addressing (or was it even 64 bit? don't recall). So, regarding allocation and speed, it's just a matter of setting up the AGP table entries (if needed) and properly aligning memory. The speed difference stems mainly from increased bandwidth, not some magic new transfer mechanism.

The problem is that D3D buffers (textures) are always internal. Locking it (it's a call...pTexture->Lock() 😉) provides a buffer address but there's no guarantee it won't change the next lock. Creating my own buffer and then copying it would certainly be slower than directly writing the pixels to the d3d texture (texture lock/unlock usually return immediately). As I understand SDL_SemWait already yields the timeslice the problem is Present call. It won't come back for some time (which is usualy less than thread timeslice), yet I cannot suspend the thread before calling it 😀

Why is then the memory provided by glAllocateMemoryNV() so much faster then the normal malloc'ed? There is also a similar trick here in D3D...if I do not specify a D3D_DYNAMIC flag (or if the driver does not support it), texture writes will be 10 times slower! I dunno, but as I understand it there's only a limited number of write-combining uncached AGP-capable addresses, the rest use normal PCI transfers even with AGP card.

For DMA to work efficiently, you need proper alignment. I'm not sure how strict this requirement is, but it's best to align mem on a 4096-byte (page) boundary. glAllocateMemoryNV does that, plus it allows to select where to allocate the memory: for example, it might return memory on the graphics card if you specified you'd be reading (using) this texture much more often than writing it. Or it may allocate a block in main memory, properly aligned, with any needed AGP entries set up and write-combining or whatever is needed for top performance if you tell it you'll write often and use the texture only once after each write. The first case sounds like D3D without the DYNAMIC flag, while the second case sounds like what DYNAMIC does.

How about two textures then? One that's locked and thus writable by the main thread, while the render thread uses the second one, and swapping them on EndUpdate.

Well, you can't lock a texture located in video memory that does not have a dynamic flag specified. So currently I check if dynamic is supported and create a texture in video memory, else the texture is located in the D3D managed memory (video memory backed by a system memory copy which is then locked). The latter is much slower but I haven't done much optimizations since any recent GPU should support dynamic flag. With Fast Writes it is possible to write directly to AGP bus so there is 1 system memory write & read less in the case of dynamic textures. I guess this is then superfast compared to AGP-DMA from system memory 😁
I'll do more experimenting with threads...I now also found it's possible that Present() does not stall, but returns an error if GPU is still busy. So a loop like

1while(!D3D->Present())
2   yield_thread_timeslice();

should do the trick...although I don't know what happens if the thread is back after too long time...fps might be jerky.

Hello All,

I have DosBox 0.63 as well as the 30.06.2005 build from : http://home.amis.net/lkslavi/ running in Wine from : http://directxwine.sourceforge.net/
Most of the DirectX 9 Wine patch from the link above is now in winehq cvs.
I only have 4 DOS games to test with and there demo's at that, but better than nothing I suppose.

Sound = Works very well
Keyboard = Perfect
Mouse = 25% usage with my current config's (it's next on my list to look into)
Output = This is Warcraft2 demo results

surface:
CPU 70%
tom@prostar tom $ cd /home/tom/.dx9wine/drive_c/Program\ Files/dosbox-cvs
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.
err:msacm:MIDIMAP_LoadSettingsDefault Registry glitch: couldn't find midi out (L"#0")
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
tom@prostar dosbox-cvs $

overlay:
Crash :)
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.
err:msacm:MIDIMAP_LoadSettingsDefault Registry glitch: couldn't find midi out (L"#0")
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
wine-kthread: main.c:705: DDRAW_width_bpp_to_pitch: Assertion `bpp != 0' failed.
wine: Unhandled exception (thread 0009), starting debugger...
tom@prostar dosbox-cvs $

opengl:
CPU 2%
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.
err:msacm:MIDIMAP_LoadSettingsDefault Registry glitch: couldn't find midi out (L"#0")
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
tom@prostar dosbox-cvs $

openglnb:
CPU 2%
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.
err:msacm:MIDIMAP_LoadSettingsDefault Registry glitch: couldn't find midi out (L"#0")
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
tom@prostar dosbox-cvs $

openglhq:
Crash :)
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035f858)->(00000000,00000008)
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:ConvertAttribWGLtoGLX unsupported 2070 WGL Attribute
fixme:opengl:ConvertAttribWGLtoGLX unsupported 1 WGL Attribute
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
fixme:opengl:wglChoosePixelFormatARB unused pfAttribFList
fixme:opengl:ConvertAttribWGLtoGLX unsupported 2070 WGL Attribute
fixme:opengl:ConvertAttribWGLtoGLX unsupported 1 WGL Attribute
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2072)
err:opengl:ConvertAttribWGLtoGLX trying to use WGL_render_texture Attributes without support (was 2073)
tom@prostar dosbox-cvs $

ddraw:
CPU 70%
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.
err:msacm:MIDIMAP_LoadSettingsDefault Registry glitch: couldn't find midi out (L"#0")
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
tom@prostar dosbox-cvs $

direct3d:
CPU 15%
tom@prostar dosbox-cvs $ dx9wine dosbox
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4035e858)->(00000000,00000008)
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.
fixme:wine_d3d:WineDirect3DCreate Createing global statistics store
fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x439dc2c8) : stub, emulating 64Mib for now, returning 64Mib
fixme:d3d:D3DFmt2GLFmt Unhandled fmt(0,WINED3DFMT_UNKNOWN)
fixme:d3d:D3DFmt2GLIntFmt Unhandled fmt(0,WINED3DFMT_UNKNOWN)
fixme:d3d:D3DFmt2GLType Unhandled fmt(0,WINED3DFMT_UNKNOWN)
fixme:d3d:IWIneD3DDeviceImpl_ApplyRenderState (0x439dc2c8) multisample antialias not yet supported
fixme:d3d:IWIneD3DDeviceImpl_ApplyRenderState (0x439dc2c8) Debug streams not yet supported
err:msacm:MIDIMAP_LoadSettingsDefault Registry glitch: couldn't find midi out (L"#0")
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x4037cc70) : Repacking the surface data from pitch 2560 to pitch 4096
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x43930ee0) : Repacking the surface data from pitch 2560 to pitch 4096
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x43941718) : Repacking the surface data from pitch 1280 to pitch 2048
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x439312a8) : Repacking the surface data from pitch 2560 to pitch 4096
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403655b8)->(00010024,00000008)
fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x43932060) : Repacking the surface data from pitch 2560 to pitch 4096
fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock
fixme:d3d:IWineD3DDeviceImpl_SwapChainReleased swapchain (0x4037be60) released
tom@prostar dosbox-cvs $

My System =
Gentoo Linux Current
nVIDIA GeForce Go 6800 ULTRA PCI-E with 256MB DDR3
3.8GHz Intel® 570 Pentium® 4E HT Enabled CPU - 800MHz FSB
1024MB 533MHz DDR2 RAM (2 DIMMS)
60GB IDE ATA100 HDD 7200 RPM 8MB Cache

If anyone wants more info/screen shot's let me know and i'll do my best to post the info/results.
Please keep in mind i've only been at this for a couple hours now and i'm still in the newbie learning mode at this time.

Cheers,
Tom

Wow.

You know that DOSBox compiles and runs natively under Linux, right? You might have better luck running it that way.

HunterZ wrote:

Wow.

You know that DOSBox compiles and runs natively under Linux, right? You might have better luck running it that way.

Yes i'm aware you guys have a Linux port, I seen the post asking if DosBox would run in Wine. So I thought it would be nice to see if the current wined3d work would enable DosBox to run in d3d mode. With the current build my CPU usage in d3d mode is about 15% where it's only 1 or 2% in opengl mode.

This laptop has Windows XP SP2, Gentoo, and FreeBSD installed on it in a tri-boot config using bing as my boot loader. What i'm interested to see now is the difference between OS's, and where Wine/DosBox stands.

So I went to : http://www.benchmarkhq.ru/english.html?/b_e.html and downloaded some benchmarks, and have 5 of them running now. Next is to install DosBox into XP and bench it there... I already have 0.63 running in Gentoo. And post my results :-)

Just having FUN..........

Tom

hehe...nice to know. I tried with transgaming cvs but I couldn't get it to work (with any output mode). Seems winehq cvs might be a better choice 😀

Yep, DosBox didn't work under Cedega last time I tried it. Nice to see that Wine works....good thing I don't pay for Cedega (Suckers!) heh, just use the compiled CVS.

run Dosbox in WinE and then run Windows 3.11 in Dosbox and please post a screenshot of this insanity 😀

Dominus wrote:

run Dosbox in WinE and then run Windows 3.11 in Dosbox and please post a screenshot of this insanity 😀

I am going to try Linux -> Wine -> DosBox -> DOS/32 Advanced DOS Extender-> and a Game ........ So run a emulator to run a emulator and run a emulator in it to run the game.. Simple enough eh?

Then try Linux -> Wine -> DosBox -> Win 3.11 -> DOS/32 Advanced DOS Extender-> and a Game.

Windows 3.11 and Office 4.3 are on order 😀 And if I get this to work you can bet the farm ill post a screen shot.

Cheers,
Tom

For the game, it should be a DOS-based emulator of a console system, such as Gameboy 😀

Also, I'm not sure that DOS/32A is technically an emulator...

HunterZ wrote:

For the game, it should be a DOS-based emulator of a console system, such as Gameboy 😀

Also, I'm not sure that DOS/32A is technically an emulator...

That sound interesting... humm.. Anyone else have any suggestions? I'm off work fri,sat,sun so if you can think of something totally off the wall post it. And if it's within reason i'll give it a shot this coming week end. In the mean time i'll keep a eye on this thread for suggestions.

I'm not sure about DOS/32A either, and I would hate to blow a couple hours only to be called on a technicality 😁 . I'ill look into this now....

Cheers,
Tom

I really don't see the point of this 😁. OK, there's the possibility of running dosbox w/ D3D and perhaps even some other win32 only features (directserial?) under wine but that's about it...if you want an endless loop, get a hercules mainframe emulator, run it under linux, boot linux s390, compile hercules under it, etc... 🤣 😁 😎 😵

Well, having a self-hosting dosbox would sure be a nice example of it's capabilities. I guess the nearest we could get is a variant patched for win95 (using that highly experimental patch from somewhere in the forums), running dosbox in that session. Well, actually I once had this already. That way, you could run games in dosbox that are broken but worked before: just load them in an older version inside the current version. Yeah, well. I guess I'll seek some cover now before you start trowing things at me 😉

To bring this thread back to topic... 😀

I added a PS 1.4 version of the scale2x shader to my page. This shader should work on Radeons 8500 and the whole 9x00 family. I'd be interested to know how it works (if it's useable at all) on lower 9000 class cards...

The two shaders work the same on my R9550. I suppose it's a good thing 😀

Yep, 9500 and up are already PS20 so both shaders should work the same (although 1.4 version might be slightly faster, but this is unoticable on my 9800pro). The 1.4 version is interesting for owners of 8500, 9000, 9100 and 9200 cards since this is the first advanced hardware scaling for these cards. Other shaders (and openglhq) all need PS20.

Since you mention it, it's not primarily the pixel shader language which limits OHQ to the opengl-equivalent of PS20, but the actual performance of the older cards, or rather, lack thereof. I think it just might be possible to port OHQ to the 8500 series, but it would be incredibly slow - too low clock rates and too few shader units.

Although my dearest scaler (hq2x) seems not feasable on my Radeon 9000, it's very nice Advmame is now supported. Thanks and great work, gulikoza.

(I really envy those people having a PS 2.0 capable graphics card. Those screenshots of Openglhq look _nice_. I guess it would be some sort of an overkill to buy a better graphics card only for dosbox, though.)