Emulator

So should development begin in a new branch? The target will be x86 devices first. Most manufacturers (AMD/Nvidia) already support OpenGL ES 2.0 as it is used for WebGL.

There's a tutorial for porting here if anyone is interested: http://pandorawiki.org/Porting_to_GLES_from_GL
While porting, please keep in mind that everything you're ported might not necessarily be the best method or may be redundant.

I'm not really sure if we really need a new video backend or if you time would be better spent if you cleaned up the existing opengl backend.

ARM devices will probably need it in future and it'll help people (at least me) code for the arm-support branch.
Any improvements that can be put through to OpenGL will be done simultaneously as they are found.

I see. Guess the backend can be within its own branch until it's in a usable state. Any cross-platform improvements should probably go to master.

btw Xsacha, iirc you were working on OpenCL, are there any imporvements planned for it? AFAIK OCL 1.2 introduced some stuff that could be used to further speed up dolphin.

There could be improvements for OpenCL with context sharing for OpenGL & DX. Again, this would be particularly relevant for mobile platforms.

Unfortunately, there are no new improvements in the spec to speed up OpenCL itself. For example, I rewrote OpenCL to use 'shuffle' and 'shuffle2' but the profiler says it would make no difference to speed. The new instructions just make the code look neater and makes everyone upgrade their old GPU to use it.

Doesn't context sharing mean that you can basically decode textures on the gpu and store the result in a ogl/d3d texture instead of transferring them back to RAM? I haven't run a profiler, but I imagine that would GREATLY speed up the opencl texdecoder.

Neobrain: Yeah, context sharing was available in 1.1. Problem is my GPU doesn't support it so I'm unable to even attempt to test it.
I can't profile that stuff without writing the code of course (It's C++ stuff, not OCL) :P I'd imagine it pretty much eliminates latency issue though.

Only if you promise to get rid of DirectX9 and 11.

I really like where this is going. It's been a while since I've done OpenGL, and I've never done it for embedded systems before. Maybe I could write some test cases?

Does Dolphin have unit tests, or some type of benchmark? If not, this might be a good place to start.

dtittle, you could write test dol's for us to compare the results with the real hardware.

What we really need is a dff player for the Wii.

^ this

No need to waste hours of coding unit tests if you can just go ahead and run game X, go to scene Y, record a list of all graphics commands being sent to the GPU and being able to generate some homebrew app from that for easier testing.

That sounds great. You could also use it for benchmarking performance on various systems, and let Dolphin select "ideal" video settings.

I'll take a crack at this, but I'm still a novice at Wii dev. I wrote my own shell for the PS2, so it'll just take some time.

NeoBrainX has a good idea, but where to start?

Take a look at FifoPlayer code in Source/Core/Core/Src/FifoPlayer and figure out how it works ;)
(basically everything but the homebrew app generation is already done)

"NeoBrainX has a good idea, but where to start?"

Yea.. good idea Neo :(

Hello,

I am currently experimenting with OpenGL ES and had a startling realization. It should be possible to implement the "Hollywood"/"Flipper" GPU with a stack-like state machine based upon OpenGL ES.

The reasoning is that since the "gpu" interprets opcodes, it should be possible to implement both a stack based VM and optimization passes with an increase in speed, whereas the drawing is done by the OpenGL ES API.

I had become interested in doing this since my laptop's gpu (9400M G) should be more than ample to run games at full speed, however I barely get above 30fps at the lowest of settings of the OpenGL Plugin.

If anyone has any insight into the graphics/gpu emulation code and documentation on the gpu's instruction set, please message me. I am indeed interested in making a proof-of-concept in the coming weeks.

btw, OpenGL ES 3.0 specs have been released and it appears to be backwards compatible with 2.0 while borrowing features and improvements from OpenGL 3.3 and OpenGL 4.2.

The backend is being worked on to get ES 3 compatible, just changing the title here.