Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » DirectX VRAM-VRAM accelerated stretch blit

This thread is locked; no one can reply to it. rss feed Print
DirectX VRAM-VRAM accelerated stretch blit
Jens-Michael Kuhn
Member #6,298
October 2005
avatar

Quote:

I know it's all relative and such, but that code isn't representative of real blitting or a real program as you are just chucking out tiny sprites between each other and not onwards to the screen or another buffer.

You're right, I tested the MEM, SYS and VRAM blitting to the screen and the SYS and VRAM blitting is now much faster.:)
I tested it on another PC and especially the VRAM to VRAM blit is very fast related to the old software routine (more than 5x faster than memory blitting to the screen and 32x faster than the old VRAM->VRAM blitting). The source sprite is the same 64 x 64 pixel bitmap.
I don't know, why my computer was so slow in VRAM->VRAM blitting, perhaps because I have installed the DirectX SDK and had configured DirectX as a debug or software (without hardware acceleration) version.???

EDIT: I tested this at home again, but there it runs as slowly as in the allegro software functions (and slower). I think my DirectDraw acceleration is broken (perhaps a bug in the nvidia drivers or a wrong option in the DirectX SDK).:(

A J
Member #3,025
December 2002
avatar

which DirectX SDK have you got ?

___________________________
The more you talk, the more AJ is right. - ML

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

DirectX 9.0 SDK February 2005.
But the settings for DirectDraw are right, I think, because the hardware acceleration is enabled. In the "DirectX Caps Viewer" under "BLT Caps" the FX "DDFXCAPS_BLTMIRRORLEFTRIGHT" and "DDFXCAPS_BLTMIRRORUPDOWN", which are nessecary for vertical and horizontal flipped sprites, are hardware accelerated for System -> Video, Video -> Video, System -> System and Video -> System.

A J
Member #3,025
December 2002
avatar

does this "DirectX Caps Viewer" under "BLT Caps" mention Alpha blitting ?

___________________________
The more you talk, the more AJ is right. - ML

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

I didn't find anything about that.
But I think it is not implemented in DirectDraw and will never be, because the last version is from DirectX7.
In the MSDN library there is a documentation to the IDirectDrawSurface7::Blt function. That is the newest and last version of DirectDraw Blt:

MSDN said:

Obsolete and unsupported flags
All DDBLT_ALPHA flag values.
Not currently implemented.

you can find it under http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/ddraw7/directdraw7/ddref_4b7b.asp
If we want hardware accelerated alpha blending (and many more accelerations), we have to update the DirectX driver of Allegro to DirectX9 (from DirectDraw -> DirectGraphics). Then we have a simulated 2d screen on a Direct3d-Interface, which supports hardware accelerated alpha blending and I think, also hardware accelerated primitives (circle, line etc.)

A J
Member #3,025
December 2002
avatar

Do you see any issues with allegro using DX9 ?

___________________________
The more you talk, the more AJ is right. - ML

Thomas Fjellstrom
Member #476
June 2000
avatar

I don't see any. Evert might, no idea.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Neil Walker
Member #210
April 2000
avatar

What's the point in going down the DX9 route, I thought by the time this would become a reality, allegro will be OpenGL. Or is this a bad thing now Vista is looming?

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

GullRaDriel
Member #3,861
September 2003
avatar

I'm sure to have rode somewhere that Vista will 'pipe' OGL to his own grafic handler, so we'll loose some speed.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Thomas Fjellstrom
Member #476
June 2000
avatar

The whole GL/Vista issue is MS's idea of "fair play". I recall hearing from a reputable source that NVidia had a working composite driver for Vista that worked allong side GL, and didn't hurt either's speed, then MS locked them out, and forced everyone to "do it thier way".

There is no valid reason why GL on Vista should be slower than DX.

With this roadblock in place for GL, allegro will need a DirectGraphics and/or Direct3d driver.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Thomas Harte
Member #33
April 2000
avatar

Quote:

With this roadblock in place for GL, allegro will need a DirectGraphics and/or Direct3d driver.

I don't see why. There's about a million other things Allegro does in software that could be done in hardware if there were an API change and everybody has seemed "happy" so far. Here on OS X everything is done in software despite a flawlessly supported OpenGL driver.

Elias
Member #358
May 2000

Quote:

I don't see why.

Of course, nothing is needed. Still, as much performance as possible should be one of the design goals - so we may wish for such a driver at least - if it gives better performance than a software or OpenGL one.

--
"Either help out or stop whining" - Evert

Evert
Member #794
November 2000
avatar

Quote:

With this roadblock in place for GL, allegro will need a DirectGraphics and/or Direct3d driver.

Actually, what I think Allegro needs is good platform-independent code (for the same reason that the assembler code should go). Something that the people who actually work on Allegro can work on and debug and which will actually work in Windows.

I'm not saying that it'd be pointless to have a DX 9 or D3D driver, but unless someone is interested in writing one, it's just not going to happen.

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

Is there any tutorial for writing a gfx driver (how the driver have to be connected to allegro)? At present I'm learning, who to use Direct3d for 2d games and I'm interested in writing the driver, if I am ever practiced enough.
I had a look at the current DirectDraw driver and tried to understand the driver management of allegro. I think, I have understood the most, but I'm not sure, if I understood all, e.g. how to add the driver to the global driverlist.

But back to my hardware accelerated draw_sprite_*_flip().
After I updated my test program to make a "real" test (blitting to screen or a screensized system and memory bitmap), in comparison to the old software function my hardware accelerated function was much faster in SYS->VRAM and about 32x faster in VRAM->VRAM blitting (see my last posts).
So the code works, but this is my first patch for Allegro, so what have I to do now, that this code will be taken up in future Allegro releases?
I read the ahack.htm and found this:

Quote:

The best you can do is to send your patch to the Allegro Developers mailing list. Read the readme.txt file for information on how to subscribe to this list. Alternatively, updated subscription instructions should always be available at http://alleg.sourceforge.net/maillist.html.

I have already published the code in this thread (and it has not changed since the post). Must I send a copy- or diff-file to the allegro developers mailing list, too?

Thomas Harte
Member #33
April 2000
avatar

Quote:

I have already published the code in this thread (and it has not changed since the post). Must I send a copy- or diff-file to the allegro developers mailing list, too?

Just posting here should have been enough - Evert is definitely a developer and I believe Elias is too, so your patches should make their way into the main release code. Whenever I've had a bug or patch to suggest, posting here seems to have accomplished the right effect.

Evert
Member #794
November 2000
avatar

I think most of us also have an e-mail subscription to the Allegro Development forum (whence my frequent requests for moving threads that are off-topic here to another forum). All the same, I will post and send the patch on the mailinglist before applying it. I'm not sure if everyone on the mailinglist reads the forums (it certainly wasn't so in the past) and besides, the mailinglist is a bit easier to keep track off: threads don't get distracted so much and if they do someone will usually change the topic description.
This second patch, for instance, should really be posted and discussed in a separate thread. The reason is that this makes it easier to keep track of where the patch is posted and which version supersedes which. This is a bit more cumbersome with the forums, even in the e-mail form.

Long message short: if you feel like posting the diff on the mailinglist, please do (be sure to hang around for questions and comments). If you don't, that's ok too, but it'll take a bit longer for the message to get posted there and applied.

As for applying it - I'll have to be sure all things were properly tested. Have you tried things like VRAM->MEM blitting with this patch applied? Does that work as expected?

A J
Member #3,025
December 2002
avatar

Thats good to hear we have someone intested in writing a DX9 driver.

As for the asm code in allegro, which routines need re-writing?

I've made several attempts at writing stretch_blit and blit in C, and now also blit in SSE2.

i noticed in iblit32.s there is a #ifdef ALLEGRO_SSE
so perhaps adding #ifdef ALLEGRO_SSE2 can also be done

___________________________
The more you talk, the more AJ is right. - ML

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

Quote:

As for the asm code in allegro, which routines need re-writing?

There is a big difference between DirectDraw and DirectGraphics (Direct3D), so I have to write a new driver and all routines, which are implemented in the directDraw driver need to be re-written.

Quote:

Have you tried things like VRAM->MEM blitting with this patch applied? Does that work as expected?

I testet all 9 blittings (VRAM,SYS,MEM->VRAM,SYS,MEM) and after the test I blitted the system and memory destination bitmaps to the screen to see, if they are working correctly. The routine is working correctly (it draws flipped sprites) with all variations. If no hardware acceleration is supported for one variation, the routine calls the original routine (like the other ddraw_* routines). If the destination bitmap is MEM, then draw_sprite_*_flip does not call the ddraw_draw_sprite_*_flip routine anyway.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

As for the asm code in allegro, which routines need re-writing?

AFAIK, all of them. The "Plan"™ seems to be just to dump all ASM, and use C equivelents, as your average compiler generates better code for most processors than the current asm. Its also more portable.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

A J
Member #3,025
December 2002
avatar

are all ports going to drop ASM ?

does any of the mac code use ASM ?

how about the DJGPP port.. or is the DOS support going to get finally dropped ?

___________________________
The more you talk, the more AJ is right. - ML

Evert
Member #794
November 2000
avatar

Quote:

are all ports going to drop ASM ?

That's the idea.

Quote:

does any of the mac code use ASM ?

No. Only 32 bit Intel ports use ASM code (well, there is some in the AMD64 port, for cpuid mostly).

Quote:

how about the DJGPP port.. or is the DOS support going to get finally dropped ?

Hasn't this been answered ten times already? If no one updates the DOS port to work with the new API, then it's effectively dropped when it stops compiling and no one can be bothered to fix it.

A J
Member #3,025
December 2002
avatar

i've done some more stretchblit in C code, and im struggling to match the asm codes speed. even with cache instructions, althou there is no specific instructions that really assist in stretching.

Has anyone had any luck writing stretch_blit in C ?

___________________________
The more you talk, the more AJ is right. - ML

Evert
Member #794
November 2000
avatar

Quote:

Has anyone had any luck writing stretch_blit in C ?

What do you mean? Allegro comes with a C version of stretch_blit (otherwise it wouldn't work at all on non-Intel machines)... obviously someone has had some luck...

Quote:

i've done some more stretchblit in C code, and im struggling to match the asm codes speed.

Allegro uses self-modifying code to stretch sprites on Intel machines (more accurately put, it assembles a piece of code in memory to do the stretching and then calls it). I can imagine that that can still be an efficient way of doing it on modern machines (even if the code generated is i386 oriented).

Thomas Harte
Member #33
April 2000
avatar

[quoete]althou there is no specific instructions that really assist in stretching
</quote>
You could use the vector unit to calculate source positions for four pixels at a time rather than one, which would hopefully bring you closer to the inevitable memory bandwidth bottleneck.

You also probably need to invent fairer tests. I have informally found that the most obvious C implementation usually beats stretch_blit for horizontally thin outputs, outputs that are shrunk vertically and the special case of outputs that are only one row high.

A J
Member #3,025
December 2002
avatar

Evert, my entire post is one statement, i wasn't expecting to have individually sentences picked apart, reading the post backwards takes it out of context.

Thomas, the tests i've done, were i build the stretcher first and then apply it to the image, building the stretcher is a trivial amount of time, its the only place i can see the possibly use for vectors to calcuate the positions, and im not so sure it would be worth the swizzling overhead for such a trivial part of the equation.

Im keen to have the asm code removed, but i'd also like to replace it with something as fast or better.

___________________________
The more you talk, the more AJ is right. - ML



Go to: