zdoom/gzdoom
0
0
Fork 0
mirror of https://github.com/ZDoom/gzdoom.git synced 2024-11-05 20:40:30 +00:00
Code Issues Projects Releases Packages Wiki Activity
gzdoom/src/x86.h

112 lines
1.9 KiB
C
Raw Normal View History

- Went back to using RDTSC for timing on Win32. Ironically, QueryPerformanceCounter() is obviously using the TSC for its timing on my machine, yet the overhead it has to do to keep the timer sane is apparently noticeable on a few maps. I suppose I should at some time check clock_gettime() and see if it has similar issues on Linux. SVN r1460 (trunk)
2009-03-04 06:06:31 +00:00
#ifndef X86_H
#define X86_H
- fixed DUMB-compile problem with gcc. SVN r1679 (trunk)
2009-06-24 22:16:51 +00:00
#include "basictypes.h"
- Changed Linux to use clock_gettime for profiling instead of rdtsc. This avoids potential erroneous results on multicore and variable speed processors. Windows will need to be updated accordingly. SVN r1142 (trunk)
2008-08-10 03:25:08 +00:00
struct CPUInfo // 92 bytes
{
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
union
{
char VendorID[16];
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 dwVendorID[4];
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
};
union
{
char CPUString[48];
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 dwCPUString[12];
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
};
- Changed Linux to use clock_gettime for profiling instead of rdtsc. This avoids potential erroneous results on multicore and variable speed processors. Windows will need to be updated accordingly. SVN r1142 (trunk)
2008-08-10 03:25:08 +00:00
- Fixed: The FeatureFlags array in the CPUInfo struct was not mapped to the flags properly. SVN r1761 (trunk)
2009-08-08 13:32:58 +00:00
BYTE Stepping;
BYTE Model;
BYTE Family;
BYTE Type;
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
union
{
struct
{
- Fixed: The aliasing of CPUInfo was still wrong. (Yarr! The things I do for you, GCC!) The AMD feature flags weren't stored anywhere, either; not that it really matters. SVN r1794 (trunk)
2009-09-05 03:28:58 +00:00
BYTE BrandIndex;
BYTE CLFlush;
BYTE CPUCount;
BYTE APICID;
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 bSSE3:1;
uint32 DontCare1:8;
uint32 bSSSE3:1;
uint32 DontCare1a:9;
uint32 bSSE41:1;
uint32 bSSE42:1;
uint32 DontCare2a:11;
- Fixed: The FeatureFlags array in the CPUInfo struct was not mapped to the flags properly. SVN r1761 (trunk)
2009-08-08 13:32:58 +00:00
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 bFPU:1;
uint32 bVME:1;
uint32 bDE:1;
uint32 bPSE:1;
uint32 bRDTSC:1;
uint32 bMSR:1;
uint32 bPAE:1;
uint32 bMCE:1;
uint32 bCX8:1;
uint32 bAPIC:1;
uint32 bReserved1:1;
uint32 bSEP:1;
uint32 bMTRR:1;
uint32 bPGE:1;
uint32 bMCA:1;
uint32 bCMOV:1;
uint32 bPAT:1;
uint32 bPSE36:1;
uint32 bPSN:1;
uint32 bCFLUSH:1;
uint32 bReserved2:1;
uint32 bDS:1;
uint32 bACPI:1;
uint32 bMMX:1;
uint32 bFXSR:1;
uint32 bSSE:1;
uint32 bSSE2:1;
uint32 bSS:1;
uint32 bHTT:1;
uint32 bTM:1;
uint32 bReserved3:1;
uint32 bPBE:1;
- Fixed: The FeatureFlags array in the CPUInfo struct was not mapped to the flags properly. SVN r1761 (trunk)
2009-08-08 13:32:58 +00:00
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 DontCare2:22;
uint32 bMMXPlus:1; // AMD's MMX extensions
uint32 bMMXAgain:1; // Just a copy of bMMX above
uint32 DontCare3:6;
uint32 b3DNowPlus:1;
uint32 b3DNow:1;
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
};
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 FeatureFlags[4];
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
};
- Changed Linux to use clock_gettime for profiling instead of rdtsc. This avoids potential erroneous results on multicore and variable speed processors. Windows will need to be updated accordingly. SVN r1142 (trunk)
2008-08-10 03:25:08 +00:00
BYTE AMDStepping;
BYTE AMDModel;
BYTE AMDFamily;
BYTE bIsAMD;
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
union
{
struct
{
BYTE DataL1LineSize;
BYTE DataL1LinesPerTag;
BYTE DataL1Associativity;
BYTE DataL1SizeKB;
};
- Fixed: R_CreatePlayerTranslation() only initialized the first truecolor palette entry. SVN r1795 (trunk)
2009-09-05 03:55:29 +00:00
uint32 AMD_DataL1Info;
- Removed -fno-strict-aliasing from the GCC flags for ZDoom and fixed the issues that caused its inclusion. Is an optimized GCC build any faster for being able to use strict aliasing rules? I dunno. It's still slower than a VC++ build. I did run into two cases where TAutoSegIterator caused intractable problems with breaking strict aliasing rules, so I removed the templating from it, and the caller is now responsible for casting the probe value from void *. - Removed #include "autosegs.h" from several files that did not need it (in particular, dobject.h when not compiling with VC++). SVN r1743 (trunk)
2009-08-02 03:38:57 +00:00
};
- Changed Linux to use clock_gettime for profiling instead of rdtsc. This avoids potential erroneous results on multicore and variable speed processors. Windows will need to be updated accordingly. SVN r1142 (trunk)
2008-08-10 03:25:08 +00:00
};
extern "C" CPUInfo CPU;
- fixed DUMB-compile problem with gcc. SVN r1679 (trunk)
2009-06-24 22:16:51 +00:00
struct PalEntry;
- Went back to using RDTSC for timing on Win32. Ironically, QueryPerformanceCounter() is obviously using the TSC for its timing on my machine, yet the overhead it has to do to keep the timer sane is apparently noticeable on a few maps. I suppose I should at some time check clock_gettime() and see if it has similar issues on Linux. SVN r1460 (trunk)
2009-03-04 06:06:31 +00:00
void CheckCPUID (CPUInfo *cpu);
void DumpCPUInfo (const CPUInfo *cpu);
- Changed Linux to use clock_gettime for profiling instead of rdtsc. This avoids potential erroneous results on multicore and variable speed processors. Windows will need to be updated accordingly. SVN r1142 (trunk)
2008-08-10 03:25:08 +00:00
void DoBlending_SSE2(const PalEntry *from, PalEntry *to, int count, int r, int g, int b, int a);
- Went back to using RDTSC for timing on Win32. Ironically, QueryPerformanceCounter() is obviously using the TSC for its timing on my machine, yet the overhead it has to do to keep the timer sane is apparently noticeable on a few maps. I suppose I should at some time check clock_gettime() and see if it has similar issues on Linux. SVN r1460 (trunk)
2009-03-04 06:06:31 +00:00
#endif
Reference in a new issue Copy permalink