Hello, all.
I am wondering if there is a particular (and obvious?) reason why x86 asm
blitters are not included/built by the MSVC project file. I realize the gcc
inline asm code cannot be built by MSVC, but what about the Hermes nasm
code? I’ve built SDL w/ Hermes successfully with MSVC – no problems. The
project would not even have to be completely dependent upon nasm (though
getting win32 nasm is trivial) – I’ve added a “Release ASMBLIT” build
configuration, for example. Would a patch for the VC project file be desired
and accepted?
Also, seeing how the official win32 SDL builds are made with MSVC, I think
we could also really benefit from the MSVC versions of MMX blitters in
SDL_blit_A.c. Would such patch be accepted?
Hello, all.
I am wondering if there is a particular (and obvious?) reason why x86 asm
blitters are not included/built by the MSVC project file. I realize the gcc
inline asm code cannot be built by MSVC, but what about the Hermes nasm
code? I’ve built SDL w/ Hermes successfully with MSVC – no problems.
So you say. Nasm/win32 has been causing us more than its share of
issues. When I finally find the time, my plan is to rewrite the nasm
blitters for gas.
The
project would not even have to be completely dependent upon nasm (though
getting win32 nasm is trivial) – I’ve added a “Release ASMBLIT” build
configuration, for example. Would a patch for the VC project file be desired
and accepted?
Next versions of visual C will not support inline asm. So an external
assembler like nasm is the only choice for assembly with visual C.
Also, seeing how the official win32 SDL builds are made with MSVC, I think
we could also really benefit from the MSVC versions of MMX blitters in
SDL_blit_A.c. Would such patch be accepted?
I think the solution is to build SDL with gcc (mingw or cygwin) to
benefit from the mmx code, even if only for the releases.
I am wondering if there is a particular (and obvious?) reason why x86
asm blitters are not included/built by the MSVC project file. I
realize the gcc inline asm code cannot be built by MSVC, but what
about the Hermes nasm code? I’ve built SDL w/ Hermes successfully with
MSVC – no problems.
So you say. Nasm/win32 has been causing us more than its share of
issues. When I finally find the time, my plan is to rewrite the
nasm blitters for gas.
Could you elaborate on nasm/win32 problems please? Or at least point me in
the direction of some articles perhaps? I am really curious, as I’ve been
using win32 nasm for years.
Next versions of visual C will not support inline asm. So an
external assembler like nasm is the only choice for assembly
with visual C.
I think the solution is to build SDL with gcc (mingw or cygwin) to benefit
from the mmx code, even if only for the releases.
The problem with using cygwin builds, is that the dll linkage .lib’s it
creates cannot be used with VC6 (most likely not v5 either, not sure about
v7+). Perhaps the makefile just needs an option somewhere, I am not sure.
The SDL.dll, however, can be used without problems.
In any case, the blitters could also be done using MSVC MMX/SSE intrinsics.
Do you know if the next versions of VC will support those or if there are
any other serious counterindications to doing so? Worst case, the blitters
could also be done in MASM, if necessary.
I am wondering if there is a particular (and obvious?) reason why x86
asm blitters are not included/built by the MSVC project file. I
realize the gcc inline asm code cannot be built by MSVC, but what
about the Hermes nasm code? I’ve built SDL w/ Hermes successfully with
MSVC – no problems.
So you say. Nasm/win32 has been causing us more than its share of
issues. When I finally find the time, my plan is to rewrite the
nasm blitters for gas.
Could you elaborate on nasm/win32 problems please? Or at least point me in
the direction of some articles perhaps? I am really curious, as I’ve been
using win32 nasm for years.
Well, you can google the SDL mailing list. Not nasm issues per se, but
side effects of using multiple tools for the same job.
Next versions of visual C will not support inline asm. So an
external assembler like nasm is the only choice for assembly
with visual C.
I think the solution is to build SDL with gcc (mingw or cygwin) to benefit
from the mmx code, even if only for the releases.
The problem with using cygwin builds, is that the dll linkage .lib’s it
creates cannot be used with VC6 (most likely not v5 either, not sure about
v7+). Perhaps the makefile just needs an option somewhere, I am not sure.
The SDL.dll, however, can be used without problems.
That’s what I meant with ‘even if only for the release’.
In any case, the blitters could also be done using MSVC MMX/SSE intrinsics.
Do you know if the next versions of VC will support those or if there are
any other serious counterindications to doing so? Worst case, the blitters
could also be done in MASM, if necessary.
As I said, inline asm will not be supported. You have to use an external
assembler if you want to be future proof. Or take the simpler way : use gcc.
I know that you are talking about C here, but at
least form C++ the support should be there. Inline
asm is part of the C++ standard.> Next versions of visual C will not support inline asm. So an
external assembler like nasm is the only choice for assembly
with visual C.
This message was sent using IMP, the Internet Messaging Program.
So after some research I’ve found out in the documentation for the
upcoming VS 2005 that they still support inline assembly.
So can you please point us to some official M$ document where they
say that the feature will no longer be supported?
He probably meant the 64-bit Itanium compiler, which does not support inline
asm. However, MS clearly states that “Compiler intrinsics are provided for
almost every machine instruction” (see http://msdn.microsoft.com/visualc/productinfo/faq/) which is even better in
many cases, as the compiler can optimize the register usage for you and
avoid stalls.
I have already ported most of the x86 asm Alpha blitters from SDL_blit_A.c
to MSVC MMX intrinsics (not inline asm), so if anyone is interested, please
let me know and I’ll send a patch (if anyone cares).
I’m quite interested on MMX patch for VisualC, maybe it will be added to SDL
CVS…
Anyway, could you send me that patch?
Thanks in advance!> ----- Original Message -----
From: avcp-sdlmail@usa.net (Alex Volkov)
To: "‘A list for developers using the SDL library. (includesSDL-announce)’"
Sent: Wednesday, September 14, 2005 10:11 PM
Subject: RE: [SDL] x86 asm blitters, win32/MSVC?
Paulo Pinto wrote:
So after some research I’ve found out in the documentation for the
upcoming VS 2005 that they still support inline assembly.
So can you please point us to some official M$ document where they
say that the feature will no longer be supported?
He probably meant the 64-bit Itanium compiler, which does not support
inline
asm. However, MS clearly states that “Compiler intrinsics are provided for
almost every machine instruction” (see http://msdn.microsoft.com/visualc/productinfo/faq/) which is even better
in
many cases, as the compiler can optimize the register usage for you and
avoid stalls.
I have already ported most of the x86 asm Alpha blitters from SDL_blit_A.c
to MSVC MMX intrinsics (not inline asm), so if anyone is interested,
please
let me know and I’ll send a patch (if anyone cares).
SDL_blit_A.mmx-speed.patch.txt –
Speed improvements and a bugfix for the current GCC inline mmx
asm code:
- Changed some ops and removed some resulting useless ones.
- Added some instruction parallelism (some gain)
The resulting speed on my Xeon improved upto 35% depending on
the function (measured in fps).
- Fixed a bug where BlitRGBtoRGBSurfaceAlphaMMX() was
setting the alpha component on the destination surfaces (to
opaque-alpha) even when the surface had none.
(The patch itself is not exactly clean because I changed all
indentation to tabs – it was very inconsistent and used
tabs+spaces.)
SDL_blit_A.mmx-msvc.patch.txt –
MSVC mmx intrinsics version of the same GCC asm code.
MSVC compiler tries to parallelize the code and to avoid
register stalls, but does not always do a very good job.
Per-surface blending MSVC functions run quite a bit faster
than their pure-asm counterparts (upto 55% faster for 16bit
ones), but the per-pixel blending runs somewhat slower than asm.
You will need to define USE_ASMBLIT to build these blitters,
see SDL.dsp below.
SDL_blit_A.mmx-both.patch.txt –
Both above patches rolled into one. Though both will apply
independently and in tandem, this is just for convenience.
SDL.dsp –
Updated MSVC v5/6 project file
- Hermes nasm code compilation added
- New build config “Release ASMBLIT” with USE_ASMBLIT defined
Overall speed improvements for the current GCC inline mmx asm code
(more speed than previous patch for 15/16bpp blenders; a couple
previous mistaken optimizations reverted)
Bugfix for BlitRGBtoRGBSurfaceAlphaMMX() setting the alpha component
on the destination surfaces (to opaque-alpha) even when the surface
has none
BlitRGBtoRGBSurfaceAlphaMMX and BlitRGBtoRGBPixelAlphaMMX (and all
variants) can now also handle formats other than (A)RGB8888. Formats
like RGBA8888 and some quite exotic ones are allowed – like
RAGB8888, or actually anything having channels aligned on 8bit
boundary and full 8bit alpha (for per-pixel alpha blending).
The performance cost of this change is virtually 0 for per-surface
alpha blending (no extra ops inside the loop) and a single non-MMX
op inside the loop for per-pixel blending. In testing, the per-pixel
alpha blending takes a ~2% performance hit, but it still runs much
faster than the current code in CVS. If necessary, a separate function
with this functionality can be made.
MSVC mmx intrinsics version of the same GCC asm code.
You will need to define USE_ASMBLIT to build these blitters (or use
the SDL.dsp from the previous patch).
This code requires Processor Pack for VC6.
Please let me know if you find anything broken. General comments are welcome
too!
Alex.
So after some research I’ve found out in the
documentation for the upcoming VS 2005 that
they still support inline assembly.
On x86, yes. On Win64 (either amd64 or Itanium) there is NO inline
assembly support in the compiler, and you have to use MASM or some
equivalent if you must have it (or compiler intrinsics, which are a
better proposition, if you ask me).
I don’t have a document, but you can download the Platform SDK for free
from Microsoft and try it yourself with 32 and 64-bit targets. This is a
compiler issue; I imagine if you could target gcc at Win64 (as you can
64-bit Linux), you can use inline assembly. Just avoid the floating
point registers.
Inline assembly is not part of any C or C++ standard.
Hey Alex, I see several different versions of your blit patches.
Can you visit the SDL bugzilla and let me know if this bug has the latest
information and versions of your patches?
