Is the ElementalDemo on the marketplace? Or is it somewhere else?
I can’t seem to find it.
Thanks
You should be abel to find it in the learn tab of your launcher 
Can I build a test version of UE and replace the one downloaded in ElementalDemo (to fix GL_TIME_ELAPSED on the Mac)…
Also is there a benchmark mode I can use to profile UE and its use of OpenGL?
If you download the ElementalDemo project from the Marketplace you can run it using an executable built from the GitHub source. Just build UE4Editor & then find the ElementalDemo project in /Users/Shared/UnrealEngine/VaultCache & add the .uproject’s path as the first argument to UE4. It would be wise to switch to a Development build & change the executable to UE4Editor.app from UE4Editor-Mac-Debug.app since ElementalDemo is so big.
Add -EnableMacGPUTimestamp to the list of command-line arguments to enable the partially working emulation of GL_TIMESTAMP - this isn’t enabled by default because it crashes Nvidia’s drivers.
Feel free to share your ideas with me since this is my responsibility on Mac. The obvious solution is to switch from GL_TIMESTAMP (which is not & will never be available on OS X) to GL_TIME_ELAPSED, but you still need to deal with nested queries which is why I tried to write an emulation. I mean to get back to it & fix it up, so if you have any related code-changes send a pull request via GitHub & I’ll take a look.
If you really want to profile OpenGL on Mac, log in to Apple’s developer.apple member area (free registration account is fine) & go to the Mac Downloads section, find the Other/Additional Downloads page & then download the most recent Xcode Graphics Tools disk image, which contains Apple’s own OpenGL Profiler. This will give you lots more statistics & tools for tracking OpenGL usage in OS X both with UE4 and other applications.
I can fix it… I implemented GL_TIME_ELAPSED on the Mac (X-Apple OpenGL Desktop Guy)
I implemented GL_TIME_ELAPSED while working at Apple in the OpenGL group, I worked on it for say… 10 years so I know a lot more than the average user
The reason its crashing is because GL_TIME_ELAPSED is a query object, and you start off with say 32 of them then use more and more … the query buffer needs to be re-allocated each time. Its part of the deferred rendering system Apple uses. By the time you get to 769 (which is where UE4 crashes) its trying to bring the count up to 2048 since it includes all the other queries. Each time the query buffer size is increased the GL context effectively needs to do a flush finish which is REALLY bad for you. Its crashing for another reason which I am fixing now.
But the best scheme for using a lot of queries is to force the count high then use them to avoid the resize while you are actually profiling.
Like
glGenQueries(2048, QueryCache);
Then in a for loop
for each query
{
bind query
begin query
draw a point
end query
get query…
}
Finish…
This way you will have pre-allocated all of your queries to the number you will use while profiling and avoid the deferred allocation model.
I am going to test this today on the UE source.
If you want my direct email (home as I am semi-retired) for any additional help on the Mac OpenGL side give me a heads up. It sure beats Apple DTS.
Yep, I can imagine you do. Not that I’m novice - I wrestled with Mac OpenGL on lots of recent (2011-2013) games…
I was aware that the driver would internally be flushing & reallocating internal buffers to provide the stupid number of queries the emulation uses, however I wouldn’t expect that to cause it to crash… provide bogus profiling numbers due to the flushing but not crash.
Yeah, that’s the bit I’m interested in really. The emulation is something I wrote fairly quickly at home & tried to massage into working in UE4, but as it never worked properly it hasn’t seen much debugging in a long while now. I totally expect the bug to be mine but I was too close to the code to see the wood from the trees.
Yes, a query pool would have been a good idea, I’ve added them for other GL types for just his reason but since the timestamp emulation was crashing the GL & I couldn’t see why it didn’t seem like the right thing to do until I understood the more fundamental error I’d made…
Yes please. Best to send it as a private message to me as I’m responsible for Mac OpenGL here.