Page 2 of 4
Re: TSI include, new image file format
Posted: Sat Oct 24, 2009 5:48 pm
by DoubleDutch
Do you have a check to ensure the instructions are available for the processor, if not then a fallback?
Re: TSI include, new image file format
Posted: Sat Oct 24, 2009 6:21 pm
by Thorium
DoubleDutch wrote:Do you have a check to ensure the instructions are available for the processor, if not then a fallback?
Yes.
It even checks if the CPUID instruction is available. So the code will even run on a 386. ^^
Even if i don't think it makes much sense to use it on a 386.
In detail:
With the 0.3 version of the TSI include you will have to call Tsi_Init() one time befor you use any procedure of it. The init procedure will first check if the CPUID instruction is available, if not it will disable MMX and SSE2 using.
If CPUID is available it will check if MMX and SSE2 are available.
After that the procedures will dynamicaly choose which implementation to use: MMX, SSE2 or simple assembler. Depanding on what your CPU is supporting. This checks are only done on x86. For x64 we can assume that every CPU is at least supporting SSE2.
Re: TSI include, new image file format
Posted: Sat Oct 24, 2009 7:16 pm
by DoubleDutch
I think one of the VIA x64 chips may not support SSE2, not sure though.
Re: TSI include, new image file format
Posted: Sat Oct 24, 2009 7:35 pm
by Thorium
DoubleDutch wrote:I think one of the VIA x64 chips may not support SSE2, not sure though.
Thanks for the info. I searched on the VIA website for informations about that but don't find anything reliable. So i will build in a check for x64.
I even not found a real technical document or manual on the VIA website. o.O
The white paper says just nothing with much words.
3.4 High Performance Media Computation
The VIA Nano processor places significant emphasis on high-performance floating-point execution. It can execute four floating-point adds and four floating-point multiplies every clock. It uses a completely new algorithm for floating-point adds that results in the lowest floating-point add latency of any x86 processor—two clocks for any format (SP, DP, DE, packed or scalar). Similarly, the floating-point multiplier has the lowest latency of any x86 processor—three clocks for SP multiply, and four for DP and DE.
In addition, the integer data path for SIMD integer (SSEx) instructions is 128-bits wide, and almost all SSEx instructions (including all shuffles) execute in only one clock.
That says exacly nothing about the supported instruction sets.
Re: TSI include, new image file format
Posted: Sat Oct 24, 2009 7:42 pm
by ts-soft
All VIA C7 and higher supports SSE2
Re: TSI include, new image file format
Posted: Sun Oct 25, 2009 1:20 pm
by Thorium
ts-soft wrote:All VIA C7 and higher supports SSE2
Hm ok.
I decided to but in a check for x64 anyway. It don't hurts performance and it's just a few bytes in code size. So there will be no surprise if someone actualy have a x64 CPU that is not supporting SSE2. I even don't knew that VIA makes CPU's until DoubleDutch wrote about it.
Re: TSI include, new image file format
Posted: Sun Oct 25, 2009 3:36 pm
by DoubleDutch
Thats a good idea, there are all kinds of companies doing 'compatibles' that may not be fully compatible.
Re: TSI include, new image file format
Posted: Tue Oct 27, 2009 8:21 am
by mar
Great work!
What image depth does it support?
Is it also possible to decode 16 bit gray images?
Mar
Re: TSI include, new image file format
Posted: Tue Oct 27, 2009 11:23 pm
by Thorium
mar wrote:Great work!
What image depth does it support?
Is it also possible to decode 16 bit gray images?
Mar
Only 32bit true color plus alpha channel at the moment.
If there is interesst i can add more modes.
Re: TSI include, new image file format
Posted: Wed Oct 28, 2009 11:35 am
by blueznl
If it's explicitly for games, and to load stuff at maximal speed, then I wonder why it would have to offer support for other formats... Is there something I'm overlooking?
Re: TSI include, new image file format
Posted: Wed Oct 28, 2009 12:34 pm
by Thorium
blueznl wrote:If it's explicitly for games, and to load stuff at maximal speed, then I wonder why it would have to offer support for other formats... Is there something I'm overlooking?
Well grayscale is special because it is used for height maps, for 3D terrain creation. So it would fit the purpose of the TSI format.
At the moment i think i will not build in indexed colors (1/2/4/8 bit depth). Because this depths tend to be very slow on new graphic cards. Well new is relative, this is a fact for a some years now. It would make sense to save a image with less than 257 colors as indexed to reduce file size and convert it back to 32bit on decoding. But there will be no need for that if my compression is ready. It should take care of that problem.
Re: TSI include, new image file format
Posted: Wed Oct 28, 2009 12:46 pm
by DoubleDutch
3+1 (2 bit), 7+1 (3 bit), 15+1 (4 bit), etc up to 255+1 (8-bit) are popular game image formats because they can be used with palettes.
Re: TSI include, new image file format
Posted: Wed Oct 28, 2009 1:12 pm
by Thorium
DoubleDutch wrote:3+1 (2 bit), 7+1 (3 bit), 15+1 (4 bit), etc up to 255+1 (8-bit) are popular game image formats because they can be used with palettes.
That was a long time ago. Using palettes today does nothing else than slowing your game down.
Re: TSI include, new image file format
Posted: Wed Oct 28, 2009 2:29 pm
by DoubleDutch
But it makes easy work of creating new objects - just by changing palettes - you can them copy them to 32 bit images.
Re: TSI include, new image file format
Posted: Thu Oct 29, 2009 2:21 am
by Thorium
DoubleDutch wrote:But it makes easy work of creating new objects - just by changing palettes - you can them copy them to 32 bit images.
Of course, i don't thought about that.
Then it's the questen if i add support for indexed colors if i add support for multiple palettes in a single file.