Hi,
Is there a way to check, if the current system has a shared memory
architecture (-> the video memory is part of the system memory and the CPU
can write to/read from it without major performance loss)? Could this be
added to SDL?
Currenlty, when I want to do alpha blits, I check for SDL_VideoInfo->blit_hw_A
and if it’s not set, I won’t use a HW surface. I cannot test it myself, but
according to a discussion on this list, software alpha-blits to a HW surface
are said to be terribly slow.
BUT if the system has shared memory (like my PC, with stupid on-board
graphics), software alpha-blit to a HW surface are still much faster than
using a SW surface.–
Benjamin Niemann (P!\K)
pink at odahoda.de
http://www.odahoda.de
Is there a way to check, if the current system has a shared memory
architecture (-> the video memory is part of the system memory and the CPU
can write to/read from it without major performance loss)? Could this be
added to SDL?
if that information is readily accessible from a user process then yes
it could, but the key issue is whether the decision taken upon a
machine having UMA or not (for example, use hw surfaces) is valid on
all platforms
BUT if the system has shared memory (like my PC, with stupid on-board
graphics), software alpha-blit to a HW surface are still much faster than
using a SW surface.
A safer and more general way is to either leave it as a user choice or
write a small test loop that actually measures the blit performance both
ways and picks the faster one, maybe when the program starts or installs
I also recommend a “calibrate” step or program that spews out some sort of
.ini file that your program (or any SDL program) uses to set-up the
parameters, such as driver, resolution, bit depth, frequency, etc., a bit
like OpenPTC’s ptc.cfg file…
Anybody else thinks this is a good feature? I think I might just implement
it… :)–
Olivier A. Dagenais - Software Architect and Developer
“Mattias Engdeg?rd” wrote…
BUT if the system has shared memory (like my PC, with stupid on-board
graphics), software alpha-blit to a HW surface are still much faster than
using a SW surface.
A safer and more general way is to either leave it as a user choice or
write a small test loop that actually measures the blit performance both
ways and picks the faster one, maybe when the program starts or installs
Perhaps someone should collect that kind of code along with some general
system and driver data into some sort of performance database library…
Specify roughly what you want to do and a list of setups that you support,
and pass that to a library call that returns the best alternative of your
specified setups.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 08 February 2001 16:29, Mattias Engdeg?rd wrote:
Is there a way to check, if the current system has a shared memory
architecture (-> the video memory is part of the system memory and the CPU
can write to/read from it without major performance loss)? Could this be
added to SDL?
if that information is readily accessible from a user process then yes
it could, but the key issue is whether the decision taken upon a
machine having UMA or not (for example, use hw surfaces) is valid on
all platforms
BUT if the system has shared memory (like my PC, with stupid on-board
graphics), software alpha-blit to a HW surface are still much faster than
using a SW surface.
A safer and more general way is to either leave it as a user choice or
write a small test loop that actually measures the blit performance both
ways and picks the faster one, maybe when the program starts or installs