to use VAO, we must use VBO, so some legency code was removed:
- ARB_map_buffer_range must be available (OGL 3.0), don't call glBufferSubData if not
- ARB_draw_elements_base_vertex also (OGL 3.2), else we have to set the pointers every time
- USE_JIT was removed, it was broken and it isn't needed any more
And the index and vertex buffers are now synchronized, so that there will be one VAO per
NativeVertexFormat and Buffer.
should be done with VAO, but atm, this is not possible :-(
this also partial revert the fix in fb92c338af83 (activating texture0 globally).
Signed-off-by: Ryan Houdek <Sonicadvance1@gmail.com>
change naming in all the backends vertex managers to make more easy to continue with the merge an some future improvements.
please test this as i'm interested in knowing the performance in linux and windows with the different hardware platforms.
So to compensate lets bring back some speed to the emulation.
change a little the way the vertex are send to the gpu,
This first implementation changes dx9 a lot and dx11 a little to increase the parallelism between the cpu and gpu.
ogl: is my next step in ogl is a little more trickier so i have to take a little more time.
the original concept is Marcos idea, with my little touch to make it even more faster.
what to look for: SPEEEEEDDD :).
please test it a lot and let me know if you see any problem.
in dx9 the code is prepared to fall back to the previous implementation if your card does not support the amount of buffers needed.
So if you did not experience any speed gains you know where is the problem :).
for the ones with more experience and compression of the code please test changing the amount and size of the buffers to tune this for your specific machine.
The current values are the sweet spot for my machine.
All must Thanks Marcos, I hate him for giving good ideas when I'm full of work.
PS and VS making. Untested and won't work for now.
Add in program shader cache files.
Readd NativeVertexFormat stuffs.
Add in PS and VS cache things.
SetShaders in places.
Fixed EFB cache index computations in OpenGL renderer.
The previous computation was very likely to go out of array bounds,
which could result in crashes on EFB access.
Also, the cache size was rounded down instead of up. This is a problem
since EFB_HEIGHT (528) is not a multiple of EFB_CACHE_RECT_SIZE (64).
Reason:
- It's wrong, zcomploc can't be emulated perfectly in HW backends without severely impacting performance.
- It provides virtually no advantages over the previous hack while introducing lots of code.
- There is a better alternative: If people insist on having some sort of valid zcomploc emulation, I suggest rendering each primitive separately while using a _clean_ dual-pass approach to emulate zcomploc.
This reverts commit 0efd4e5c29766ba5f5d22204339637ade9ccec83.
This reverts commit b4ec836aca4392a86b864dc58b1030ca616fe0d5.
This reverts commit bb4c9e2205d4117f48fd4ca50774ee56c28c92e4.
This reverts commit 146b02615c07dd52dddaa18b7e23d09bc23b549e.
This reverts commit 402006a83a89bc0f790934096e915f0e8c23f808.
This reverts commit 48d8d71391fc2cc40d85732680eb6421164bf87c.
This reverts commit 450dcc9d2cd874f6ab40d4a339afc29f55751319.
Most of the games using EFB peeks are suffering from major performance problems
when these peeks are not disabled in the graphics settings. This is an attempt
to fix this in the GL renderer by doing the glReadPixels in bulk: instead of
doing a lot of 1x1 pixel reads, read for 64x64 pixels at once and keep that in
a cache.
Deck menu in Baten Kaitos: 3FPS -> 54FPS
Character creation in Monster Hunter Tri: 7FPS -> 60FPS
Profiler.{cpp,h} also happened to be the only dupliated
filenames left in Source, the absence of which should make
link-time optimization easier to get working.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6935 8ced0084-cf51-0410-be5f-012b33b47a6e
Separated UI from debugger functionality. Generally cleaned up that stuff.
Most functionality needs to be reimplemented now, but will be available to D3D9, D3D11 as well as OpenGL then.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6523 8ced0084-cf51-0410-be5f-012b33b47a6e
