Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A few questions
#1
Hi, I just have a few questions in term of development.. First, I found the key to trigger 64bits build which fail miserably on a piece of hand written assembly code, memcpy, memxor and memcmp reimplementations. Is there any workaround? Or should it be recoded(in c or asm)? Is it really much faster than optimized c implementation? What else is needed for 64bits(as I can not go further in compilation).
Then, about linux itself, how can I build gsdx(and everything else?) with avx support in cmake. I see it's one project for linux developpers(in dev section), is the code ready for that? it only needs test? I try to just add march and mtune at native(which includes avx) on global CXX and C flags of cmake, it compiles and seems to work somehow, is it because it did not change anything(I never used cmake)?
Then, on the simulator itself. First, I guess that by recompiler you mean that you use a DBT simulator(or you decompile code to perform optimizations on it?). But what troubles me is that in the option(speedhack) I see that there is a notion of frequency... The simulator is cycle accurate then? Isn't that very heavy? Mips processors are pipelined right? So it must not be so easy to keep a good cycle count, branch prediction/prefetch should be part of the game too I guess. I mean here the program should just work, so brutal binary translation(especially with only one core) should do the trick no? Do you really need to know the number of cycle that has really been done on original hardware?

Thanks to take time to answer my curiosity Smile
64bits would be nice.. If I can help... Would remove dual libs again from my system.
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply

Sponsored links

#2
64 bit is only for dev porting. Nothing is done yet. Even if you fix the basic stuff, you be limited to interpreter (5fps on best cpu). I will rename the option.

For avx, you can try editing BuilParameter.cmake. Maybe I can an option to cmake but I can't test anything on my 5 year old cpu.

Recompiler transform binary code to x86-32 code. A cycle accurate approach will be much easier but much more slower. Ps2 contains 4 cpu + 3 main memory zones + all sound/io periph + a 10 channel dma to transfer data from any block to other block. All this crew runs in parallal. Are you sure that you don't need some kind of timing Smile
Reply
#3
Ha, seen that way, yes timing will be useful seems... 4 cpus? IOP, EE and VU and? Hmm but on qemu they manage to make smp without cycle accuracy, don't know how they do that exactly though.
I live off a core i3-3217U, 5 fps will not make me afraid hahaha. For the recompiler, going to x86_64 would require a full rewrite or just a backend? Your frontend should be host agnostic no? Are you based on qemu? Maybe you can port their backend or use TCI already for tests?
I will test avx, but on my desktop maybe... Will be much much faster... Is there any particular test protocol? I manage to trigger it in cmake yes, it's compiling now.
I will try to get familiar with the project a bit(and cmake) before I try to fix the "basic stuff"(intel assembly... My breakfast is not going to stay in my stocmach so long Smile ).
Also, what about HLE bios? It has been studied? Is the bios of ps2 really used, I guess functions in themselves are not so complex normally? Most of the scarry stuff should be done by bootloader/OS? On Intel, the only use I have for my bios is to load the first stage of kernels from disk to memory, then it's pretty much finished, Jump to protected mode and life goes on, I load the rest "by myself".
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#4
For avx:
I tried around a little, it compiles, seems to run on a few of my games at least(FFX/X-2/XII and Dark Chronicle right now). On FFX2 opening FMV, on software mode, there seems to be a slight speed up, going from 43~46 to 47~51(frame limiting disabled) on my desktop computer(core i7-2600k & nvidia gt 770m, ArchLinux x86_64). But is there a way to get preicse statistics on that? Otherwise, it *seems* stable from what I tested, don't cause any bug that was not here before. But need more testing I guess. On my laptop, the cpu is just too limited to run anythig interesting for now, and speed measurement is well... slow with and slow without Smile . For the little tests I made it seems stable there too though(core i3 3217U - intel hd4000, ArchLinux x86_64 too).
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#5
VU*2, there are not exactly the same. Anyway you can't compare a modern SMP CPU with an old heterogeneous multi-core system. Anyway PCSX2 is not cycle accurate but you still need some timing.

No we don't use qemu. I'm not sure we can anyway. The mips of the PS2 is not standard. Memory management is a bit different than a standard OS/PC. By the way what is TCI? "Only" the backend need to be ported.

Rom code (IMHO HLE bios is a poor naming) was studied. But you miss a big point, the kernel is inside the ROM code, actually both kernel and both bootloader (EE vs IOP). The ROM code contains also low level libs like libc, memory management... So it is quite big, and not so easy.
Reply
#6
Oh my... Yeah seems completely crazy that stuff...
Hmm even if it's not standard, you can basically code a frontend for Qemu actually, or even a full platform, the idea is to have an already optimized code generator/ caching algorithms(Efficiently caching your translated blocks is fun right? Optimization on the abstract code too... Smile ) / backend for intel & arm and all other niceties such as research from insane number of persons, for free Smile
TCI is another nicetie from qemu, basically, it's a universal code generator that works for any 32/64 bits host.

Everything in the rom... Two kernel... libc... Did they include the toaster and frying pan also?Smile Hmm yap, can imagine.They use linux though no? Hmm it does not seem easy... But if so maybe it can be done... If it's based in gnu code you can do whatever you want with it too normally(actually I think they distributed a linux system at some point, must not be so far?) libc I guess woud have to be redone... How fun... Especially if it's not standard...Memory management I guess too right? Though this one, with the age, they should not use something too exotic I think. A nice best fit... Now that would be great...
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#7
I don't know qemu internal. It sounds interesting. It feels easy unfortunately the PS2 is all but an easy system. Do you know what level of speed they're able to achieve to emulate a (64bits?) MIPS? Some documentation of the architecture will be nice. However I'm afraid that a generic architecture will add too much overhead for us.

You didn't expect game devs to provided they're own kernel, did you? The Rom code includes also gzip/drivers/security/elf loading/RPC/timer.... No they don't use linux. It would be damn slow! They recreate a gaming dedicated low-latency kernel. The kernel requirement on a console is not the same that a PC. Hopefully for us, the kernel is rather small (vs a fat tiny-linux). It can be done but it takes times.
Reply
#8
http://www.linux-mips.org/wiki/Qemu is what they say about mips, they think it's as fast as other processors(should be fast then). They explain the architecture a bit also, careful, the memory map seem a bit wrong to me(but since you will recode it anyway...). When I try to print using VESA, it fails, nothing on screen. So either they changed something or I don't know. Debian is compatible with mips qemu, you can look at their documentation also I guess.
For qemu internals, well, their documentation mostly tells you to... Look at the code. You have the base manuals there : http://wiki.qemu.org/Manual .
After, when you want to program a frontend, it's the "target-ARCHITECTURE" folders. translate.c is you code translator, using the functions of qemu. tcg-archi are the backends. In each, target-* you have a description of the cpu you want to emulate and all. When you make your translation you have two main ways, if it's "simlple" you have the tcg_gen_* functions which are more or less qemu assembly. Then you have the tcg_gen_helper_* which are "helpers" that is, complex c functions that you code yoursel, use with caution, it's more heavy.
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#9
Seriously that look interesting but I'm afraid
1/ it is a tons of work (the frontend of PCSX2 is likely more complex than the backend).
2/ I don't have any time for it. I already severals projects to finish first Smile

Does any game emulator use this qemu infrastructure?
Reply
#10
I didn't find any game emulators actually, only board emulators... Yes, would probably be a ton of work in fact as the way things get done(in organization) seems sligtly different from what I see of your code... Well, maybe for the future, actually, I think about it a bit, and I may have help but it is really not sure... The laboratory I am in would be happy to have a mips based platfrom simulated they told me... But after, it is not said they would really help me haha since it is not my main work at all... After it may also be worth it to investigate into SystemC which can do parts of the work for you(it is a language to program simulator(over qemu also). SystemC does suffer from performance loss compared to pure qemu.
Sorry for the time I took to answer I have been quite busy lately...
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply




Users browsing this thread: 1 Guest(s)