How do most people do HW acceleration for emulators?

Discussion in '3DS - Homebrew Development and Emulators' started by shutterbug2000, Oct 12, 2015.

  1. shutterbug2000
    OP

    shutterbug2000 Cubic NINJHAX!

    Member
    1,081
    2,182
    Oct 11, 2014
    United States
    Title says it all pretty much. :P
     
  2. Tigroid
    This message by Tigroid has been removed from public view by Veho, Oct 12, 2015, Reason: Not an imageboard.
    Oct 12, 2015
  3. Author
    This message by Author has been removed from public view by Veho, Oct 12, 2015, Reason: Reply to trashed post.
    Oct 12, 2015
  4. TheCruel

    TheCruel Developer

    Banned
    1,351
    2,886
    Dec 6, 2013
    United States
    They utilize hardware components that are quicker than their emulated counterparts usually by interpreting or recompiling instructions. For the 3DS, the acceleration would likely be done with the GPU. I think dynamic recompilation can be considered hardware acceleration, but that's normally not what people mean, they typically mean something running on something more specialized than the main CPU.
     
  5. nop90

    nop90 GBAtemp Maniac

    Member
    1,437
    2,138
    Jan 11, 2014
    Italy
    Rome
    The general idea is to parallelize the computation on the greater number of available processors/HW components.

    On 3DS it would be great to use the arm9 for some task (i.e. sound handling and timing like it's for 3DS). But at the moment it's not posible using ctrulib or latest entrypoints.

    Another option is to move all the GFX computation on the GPU; there are some libs that helps doing this (like @xerpi sf2dlib) but to have the best performance one should write specilized code for every single need.

    The last option could be to move some non graphic computation on the GPU using a relatively recent and experimental way to convert processive computation in parallel computation. This is called GPGPU (General purpouse computing on graphics processing units) which I recently started to study to experiment with it on 3ds. The bad thing is that on other GPU there are some high level languages to do this (a sort of C for GPU) but on 3DS one has to use the shaders asm (without any step by step tutorial available).
     
  6. Spaqin

    Spaqin GBAtemp Regular

    Member
    122
    69
    Feb 17, 2015
    Poland
    I was going to say to nop90 that emulators can't be really parallelized, as manycore code must be written with that in mind from the beginning, and is only applicable when you have lots of the same stuff to calculate. It's worth it only for big amounts of data, where overhead of loading data to and then from vram can be ommited in the long run, and responsivity is not a concern. And emulators need to react fast to always changing data (instructions).
    But then I realized that he's an active developer, so he must know what he's doing. I'd be glad if someone corrected me and showed how parallel computing can be used in emulation.
     
  7. nop90

    nop90 GBAtemp Maniac

    Member
    1,437
    2,138
    Jan 11, 2014
    Italy
    Rome
    It's a very experimental area and I'm a only beginner, but i'm reading some papers on the matters and interesting algorithms
    are under developements.

    On Wii U GPGPU seem promising (only rumors). I don't know if something good can be achived on 3DS, but I'm curious abouth this technology.

    At the moment I was only able to load dummy shaders with a template made modifying th GPU examples in the CTRUlib sources, so don't expect anything in the near future.

    PS: @Spaqin you are right when you say that multicore code must be written with that in mind. This technology probably can't be useful for porting old emulators, but could help to write a new one from scratch.