This fixes running Dolphin on the Nexus 9.
Android's EGL stack has internal arrays that they use for tracking OpenGL function usage. Probably has something to do with their OpenGL profiling
garbage that used to be in ADT.
Android has three of these arrays, each statically allocated.
One array is for all GLES 1.x functions
One array is for all GLES 2.0/3.0/3.1 and a couple of extensions they deem worthy of being in this array.
The last array is for all function pointers grabbed via eglGetProcAddress that isn't in the other two arrays.
The last array is the issue that we are having problems with. This array is 256 members in length.
So if you are pulling more than 256 function pointers that Google doesn't track in their internal array, the function will return NULL and yell at you
in logcat.
The Nvidia Shield Tablet gets around this by replacing part of the EGL stack with their own implementation that doesn't have this garbage.
The Nexus 9 on the other hand doesn't get away with this. So we pull >100 more function pointers than the array can handle, and some of those we need
to use.
The workaround for this is to grab OpenGL 1.1 functions last because we won't actually be using those functions, so we get away with not grabbing the
function pointers.
Fixes a typo where the official IMGTec drivers were said to be the OSS driver support.
Removes Mali GPU family detection just like I removed the Adreno family detection.
We don't support Mali Utgard anyway.
If we need family detection we can properly add it, right now it isn't needed.
Adreno 300 and 400 have the same video driver performance issues because they are very similar architectures which use basically the same thing with
everything.
There isn't any need to detect the family of the driver with Qualcomm anyway. If we ever need family specific bugs then we can implement real support
for that.
Performance issue on Adreno 400 series was due to us only detecting Adreno 300 series, and with Adreno 400 it wouldn't use the bugs, which would cause
it to use glBufferSubData, causing the huge performance hit.
If the host device supports GLES 3.1 and AEP we can have stereo rendering.
Just need to make sure to grab the correct function pointer that GL_EXT_geometry_shader provides, and enable AEP in the shaders.
We can't just check if AEP is in the extension list for support because Qualcomm has failed once more.
With the Nexus 6 it reports support for AEP but doesn't support OpenGL ES 3.1, which is an impossible combination.
From reports on their forum it seems that attempting to use any AEP things results in nothing happening, seems like a stub implementation.
Instead of abusing whatever VAO is previously bound, which might have
enabled arrays.
Only used in one instance currently, which fixes a crash with older
NVIDIA drivers.
This is the same extension that we all know and love but under a different name with some different requirements.
In regular OpenGL fashion, you can't just move a desktop OpenGL extension to OpenGL ES without ratifying a new extension, which is why this falls
under a EXT extension, which in turn causes it to have suffixes attached to their function names.
This is the first step in our way towards conquering all mobile GPUs that don't support desktop OpenGL, hopefully we also can add support for
buffer_storage to OpenGL ES as well so we can make full use of this extension.
This wasn't too much of a concern since we normally don't care about this feature set, but it is nice when testing on new devices and they don't
support the higher feature sets but want to run under software renderer.
The Mesa softpipe and PowerVR 5xx drivers don't support higher GL versions, but they shouldn't exit out just because they couldn't get a GL3 function
pointer that isn't even going to be used at that point.
This is pretty much a step backwards in our code. We used to use attributes in our PP shader system a long time ago but we changed it to attributeless
for code simplicity and cleanliness. This reimplements the attribute code path as an optional path to take in the case your system doesn't work with
attributeless rendering. In this case the only shipping drivers that we can know for sure supports attributeless rendering is the Nexus 5's v95 driver
that is included in the Android 5.0 image.
I hadn't planned on implementing a work around to get post processing working in these cases, but due to us force enabling the PP shader system at all
times it sort of went up on the priority list. We can't be having a supported platform black screening at all times can we?
Due to changes in how we render to the final framebuffer we no longer encounter this bug.
With the change to post processing being enabled at all times and no longer using glBlitFramebuffer, Qualcomm no longer has the chance to rotate our
framebuffer underneath of us.
This is good hygiene, and also happens to be required to build Dolphin
using Clang modules.
(Under this setup, each header file becomes a module, and each #include
is automatically translated to a module import. Recursive includes
still leak through (by default), but modules are compiled independently,
and can't depend on defines or types having previously been set up. The
main reason to retrofit it onto Dolphin is compilation performance - no
more textual includes whatsoever, rather than putting a few blessed
common headers into a PCH. Unfortunately, I found multiple Clang bugs
while trying to build Dolphin this way, so it's not ready yet, but I can
start with this prerequisite.)
This noticeably includes GL_ARB_get_program_binary, which was previously
thought unsupported on OS X. Well, actually, the OS X implementation is
trivial and reports 0 binary formats (as of 10.10; this is hardcoded in
GLEngine, by the way), but at least it'll work if it's fixed someday.
The D3D / OGL backends only ever used RGBA textures, and the Software
backend uses its own custom code for sampling. The ARGB path seems to
just be dead code.
Since ARGB and RGBA formats are similar, I don't think this will make
the code more difficult to read or unable to be used as
reference. Somebody who wants to use this code to output ARGB can simply
modify the MakeRGBA function to put the shift at the other end.
This causes glDrawArrays to fail in core profile, and thus on OS X, see:
http://renderingpipeline.com/2012/03/attribute-less-rendering/
There must be something bound, even though it is not used.
Fixes#7599. I'm not sure this is actually the best way to fix it,
since AFAICT it makes a nonobvious assumption that *something* will be
bound before the first attributeless rendering in
TextureConverter::DecodeToTexture, but it's what degasus suggested and
seems to work.
We were generating a texture without ever setting the data to a known value.
This happened on the old code as well, just that PP shaders are receiving some love and people are using it and noticing some of its issues.
The only possible functionality change is that s_efbAccessRequested and
s_swapRequested are no longer reset at init and shutdown of the OGL
backend (only; this is the only interaction any files other than
MainBase.cpp have with them). I am fairly certain this was entirely
vestigial.
Possible performance implications: efbAccessReady now uses an Event
rather than spinning, which might be slightly slower, but considering
the slow loop the flags are being checked in from the GPU thread, I
doubt it's noticeable.
Also, this uses sequentially consistent rather than release/acquire
memory order, which might be slightly slower, especially on ARM...
something to improve in Event/Flag, really.
This is effectively unused, as the window handles that we pass to the
GLInterface are window handles for the frame which isn't ever a real
toplevel window. Host_UpdateTitle is what actually sets the proper title
on the render window.
Now that MainNoGUI is properly architected and GLX doesn't need to
sometimes craft its own windows sometimes which we have to thread back
into MainNoGUI, we don't need to thread the window handle that GLX
creates at all.
This removes the reference to pass back here, and the g_pWindowHandle
always be the same as the window returned by Host_GetRenderHandle().
A future cleanup could remove g_pWindowHandle entirely.
Seems mesa has a quirk where
define THING(x) (#x)
is the same as
define THING(x) (##x)
Didn't realize I messed it up since it just worked since I only tested on Mesa.
This class loads all the common PP shader configuration options and passes those options through to a inherited class that OpenGL or D3D will have.
Makes it so all the common code for PP shaders is in VideoCommon instead of duplicating the code across each backend.
It was only used for Windows XP and lower.
This also bumps the _WIN32_WINNT define in the stdafx precompiled headers to set the minimum version as Windows Vista.
The hack was needed because the Nvidia 3D Vision heuristics are documented to only support surfaces that are the same size as the backbuffer. This would be the case if you enabled the hack and selected the "Auto (Window Size)" internal resolution.
However, on recent drivers the same effect is achieved by selecting the "Auto (Multiple)" internal resolution. Therefore the hack is no longer required.
In the cases where we support the binding layout keyword, use it for more than binding UBO location.
This changes it so it is supported for samplers as well.
Instances when this is enabled is if a device supports GL_ARB_shading_language_420pack, or if it supports GLES 3.10.
s_encodingPrograms is defined as an array with a length of 64
NUM_ENCODING_PROGRAMS is also defined as 64.
However 64 is out of bounds, so we want to be comparing for "equal to or
greater than here"
- Isolate it into it's own namespace
- Shorten function names, the namespace self-documents.
- Just use the std I/O, we can just write directly to the stream for
logging.
gcc doesn't optimize this loops with -O2, so using memset now.
A flag to skip the clear funktion was added as the cache is already cleared most of the time.
We need to pull in function pointers for OpenGL 3.0 in order to use glAttribIPointer.
This isn't too big of an issue, and this code will be gone in the future when we change over to libepoxy.
Just need to push code upstream to libepoxy to support Android with GLES and GL first.
Jules Blok