You got it working and you didn't tell me!? /s
Seriously though, great work! I thought it would never happen. If you need help/advice/whatever, just shoot me a message here or tag me on GitHub. (that should ping me... right?)
(06-02-2016, 01:37 PM)OatmealDome Wrote: [ -> ]You got it working and you didn't tell me!? /s
He did tell everyone on #dolphin-dev @ freenode. Bad luck, you weren't there
And indeed, the progress looks well. OGL seems to run "fine", but the ES context hurds a lot as it doesn't support base vertex and so we have to fall back to the very slow buffer streaming way.
For the JIT, we still have issues with memory mappings, both the 4GB memory area for fastmem, also with the RWX pages. Do you know if it's possible to map the JIT memory twice, once as RW, once as RX? This sounds like a good enhancement for the JIT in general.
Finally, input, gui, whatever, I don't care
(06-02-2016, 09:23 PM)degasus Wrote: [ -> ]He did tell everyone on #dolphin-dev @ freenode. Bad luck, you weren't there
And indeed, the progress looks well. OGL seems to run "fine", but the ES context hurds a lot as it doesn't support base vertex and so we have to fall back to the very slow buffer streaming way.
For the JIT, we still have issues with memory mappings, both the 4GB memory area for fastmem, also with the RWX pages. Do you know if it's possible to map the JIT memory twice, once as RW, once as RX? This sounds like a good enhancement for the JIT in general.
Finally, input, gui, whatever, I don't care
For the JIT issue, I was thinking we could store a second buffer for Dolphin to write into as it's executing. Once it returns from the JIT block, the changes could be copied over into the real JIT cache. Does this sound feasible?
And sorry Oatmealdome. Your dolphin bridge class was included in the source and I made sure to leave you some credit. Thank you for your work on this. I would have never gotten started without learning from your initial build
(06-03-2016, 06:45 AM)miniroo321 Wrote: [ -> ]For the JIT issue, I was thinking we could store a second buffer for Dolphin to write into as it's executing. Once it returns from the JIT block, the changes could be copied over into the real JIT cache. Does this sound feasible?
I don't think there is an issue for this workaround. We don't write in the jit code while jit code is executed, we only touch jited code from C++. So locking + unlocking should be fine here, but for performance, mapping it twice sounds faster (only on compilation).
(06-02-2016, 09:23 PM)degasus Wrote: [ -> ]He did tell everyone on #dolphin-dev @ freenode. Bad luck, you weren't there
And indeed, the progress looks well. OGL seems to run "fine", but the ES context hurds a lot as it doesn't support base vertex and so we have to fall back to the very slow buffer streaming way.
For the JIT, we still have issues with memory mappings, both the 4GB memory area for fastmem, also with the RWX pages. Do you know if it's possible to map the JIT memory twice, once as RW, once as RX? This sounds like a good enhancement for the JIT in general.
Finally, input, gui, whatever, I don't care
I haven't used IRC in over 5 years!
I'm not surprised about OGL being a bit weird, as the OS X implementation of desktop GL is *still* very outdated. About the JIT thing, I don't have any answers to give you, really. I'm more suited to the "higher level" things.
(06-03-2016, 06:45 AM)miniroo321 Wrote: [ -> ]And sorry Oatmealdome. Your dolphin bridge class was included in the source and I made sure to leave you some credit. Thank you for your work on this. I would have never gotten started without learning from your initial build
Oh, thanks. Some things:
* How did you come up with the .xcodeproj? I assume it's by passing -GXcode to cmake since it's in the Build/ folder... I personally do not this method, so if you wish, you could use my build system located at my newer fork (it's similar to how Android has its system set up, where gradle calls cmake).
* I personally found that setting ANDROID was a nightmare when building for iOS and that not setting it minimized the invasiveness of the patches.
I haven't looked fully through the code, so I might be missing something.
(06-06-2016, 06:53 AM)degasus Wrote: [ -> ]https://github.com/dolphin-emu/dolphin/pull/3881
It will likely take some time to get it merged, but it's on its way.
Now that's a huge diff. My browser lagged a lot and froze at least twice when trying to look at it. Reviewable to the rescue!
Also, I updated the OP which I intended to do
months ago, so that's checked off my TODO list.
There is now a jailbreak for iOS 9.2-9.3.3 which is a semi-untethered jailbreak. Does this give you the access needed to run what Dolphin needs on these newer iOS versions?
So, I've read the first few and last couple pages of this thread, but not all of it, so I'm not 100% sure what exactly was figured out.
What was figured out as far as JIT? Is it possible to (as a developer) run this just by downloading and compiling it, or will it require a jailbreak?
(I'm an iOS dev myself, but not very experienced with low-level stuff; I don't think I'd be very useful in contributing to Dolphin.)
(08-02-2016, 11:11 AM)Praxis Wrote: [ -> ]So, I've read the first few and last couple pages of this thread, but not all of it, so I'm not 100% sure what exactly was figured out.
What was figured out as far as JIT? Is it possible to (as a developer) run this just by downloading and compiling it, or will it require a jailbreak?
(I'm an iOS dev myself, but not very experienced with low-level stuff; I don't think I'd be very useful in contributing to Dolphin.)
Yes, you just download it and compile it with xcode, i suggest you to add roms in resources-roms folder so xcode add it automatically. I have to tell that when no jailbroken had to be attached to xcode so the app doesnt crash.