Planned OpenGL driver improvements

General Development
#1

I have some planned GL driver improvements lined up but I’m currently blocked on the fact that I don’t have a Mac. All things I’m planning requires good OSX support (not SDL 1.2 crap), so I’m kinda screwed … Since I was never able to lend a Mac from someone, I’ll have to shell out for a Mac Mini soon …

Anyways, what I want in the near future:

  • Ability to create GL core contexts in libretro GL. Currently, only GL 2.1/GLES2 contexts are supported. This greatly limits libretro GL when you want to do more fancy stuff. Not supporting GL core contexts in 2013 is kinda backwards. Ofc, you can rely on extensions, but in some cases things will conflict. Core contexts requires some fixes in RetroArch as well. I’ve already implemented this in a branch, but it’s not done.

  • Stencil buffers. I dropped that initially because it just didn’t work, but “the way” to do depth and stencil attachments is a packed format, not separate. Atm, it’s 16-bit depth buffer (only thing GLES2 supports without extensions), but stencil attachment means 24/8 packed.

  • Cached GL contexts. Currently, when you go from fullscreen to windowed and vice versa, the GL context is destroyed and recreated. Strictly speaking, this isn’t 100% necessary. It is kinda troublesome for libretro GL cores, because it means they have to handle the context_reset() callback, which can be hard to implement correctly when the code isn’t written with reinit in mind. Even if it’s handled right, it will likely stall quite a bit. Same here, there’s a WIP branch, but not done yet.

  • Cocoa GL context/drivers. SDL 1.2 is fucked up on OSX due to recent breakages from Apple. There are so many hacks right now, it’s not even funny. If Cocoa proves too hard/fucked up, I’ll have a look at SDL 2.0 instead, which recently got its first stable release.

  • A very simple GLEW replacement. Symbol handling in RetroArch is kinda messy atm, since I cannot rely on a symbol loading library and symbol loading goes in many places, ugly. GLEW is inadequate anyways (doesn’t handle EGL stuff or GLES for one …). Apple hates being standard here so they name everything differently in glext.h <_< Ideally, this will be a lib which is easily reusable in libretro GL cores.

1 Like
#2

Any idea why shaders suddenly work on the iOS port when they haven’t worked for months - as recent as 0.9.9.2? I didn’t see any real substantial changes to gl.c happening inbetween 0.9.9.2 and 0.9.9.3 that pertained to the iOS port.

There are still some broken Cg-to-GLSL shaders on iOS - I don’t know if they work properly on the Android port - waterpaint-mudlord seems broken as does mudlord-noise. There are also weird vertex problems with certain shader passes. I’ll try making some screenshots later.

Hunterk also has some shader issues with his HTC One (fairly recent phone) - RetroArch Android - apparently not a single shader works. Something else I just want to mention that might need looking into.

#3

@maister You’re welcome to remote into my Lion iMac if that’ll help.

#4
  • A very simple GLEW replacement. Symbol handling in RetroArch is kinda messy atm, since I cannot rely on a symbol loading library and symbol loading goes in many places, ugly. GLEW is inadequate anyways (doesn’t handle EGL stuff or GLES for one …). Apple hates being standard here so they name everything differently in glext.h <_< Ideally, this will be a lib which is easily reusable in libretro GL cores.

Will this mean we will no longer have to instrument every GL function call with GLSYM or some similar macro like that? Because that certainly is a problem to have to do everytime - not to mention I don’t think many existing projects would be happy to have us ‘change’ every single GL function call like that just to have it working with libretro.

On that note, the coordinate flipping ‘gotcha’ is still a major problem - it means a lot of porters need to butcher up GL code with wrapper functions for glScissor and whatnot. No way is any of this code ever going to be merged upstream in existing projects if we will have to butcher up code like this to get it working properly as a libretro GL port. Can’t we do better there?

This is going to be a problem when I’m going to look at adding a GLES video driver to Tyrquake and when I want to push the libretro port upstream.

I’d like to eventually look at a PPSSPP port as well (through libretro GL). So there’s also that

#5

Ye, I’m grateful for having access to that, but it’s sadly not enough for really testing driver stuff. 10 fps and shaky ping ain’t gonna cut it :\

Square: I guess I can add a mode eventually which uses standard GL conventions, but it will break certain shaders which make use of (0, 0) being top left tex coord. Not a big deal I suppose as they’re kinda uncommon. I’ll add it to the GL cleanup list.

GLSYM was used in modelviewer because it’s the leanest way to do extension loading imo. The conventional C alternative will be hundreds of lines of monkey work, pasting out every single function entry point and macro wrappers.

Shaders suddenly work because cg2glsl was changed to include a workaround for iOS’s broken compiler.

I’ll wait until I get my Mac before doing any substantial stuff.

#6

If you’re referring to that workaround to do with the for loop (where lesser than got changed into != ) - I don’t believe that did anything for me on 0.9.9.2 though.

Oh well - it works now I guess.

#7

Since I finally got Hackintosh running on my Lenovo G580 - I can finally do some productive stuff in Xcode (in the VM it was so godawfully slow that anything but commandline was non-workable).

I based this on an example I found from Apple - called CocoaGL.

https://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html

I updated it for OSX 10.8 and modified it somewhat so that it works on current OSX. Also added a Resize button to it and removed the ‘cube sample’ stuff. It’s still pretty much a mockup but I think it provides us with much of what we need - I think this is a better route to take than writing a context file specifically for CoreGL - with this you could kill two birds with one stone - both a context driver AND a frontend.

https://github.com/twinaphex/RA-CocoaGL-Frontend

A screenshot of how it looks now -

It also has a menu bar (which you can’t see on this pic). The current SDL port on Mac is really badly scaled - we really need a native frontend like this badly. I think this could finally get us a halfway respectable userbase on OSX since the current implementation really does quite suck - appearance-wise.

#8

Maister im assuming splashtop2 in a parallels mac vm where you get over 30 fps assuming you pay for remote login or set up a vpn in the vm is not fast enough for you? I regularly use only like 20% of my cpu :stuck_out_tongue:

The only issue is that the vm is not hardware accelerated… You can thank apple for that.

#9

Hackintosh is a big pain at first to get working but once it works it’s lovely - at least on my Lenovo.

I’ll never look back after this and bother again with the terrible performance inside those VMs - it is simply unworkable.

#10

Hackintosh is a big pain at first to get working but once it works it’s lovely - at least on my Lenovo.

I’ll never look back after this and bother again with the terrible performance inside those VMs - it is simply unworkable.[/quote]

But using a MAC to vm a MAC os is not bad at all… Its fast.

Hell I play halo 2 in a windows 8 vm just fine… (then again when parallels is allowed to use hardware acceleration you only loose 20% performance)

It is quite workable and is faster then my 3rd hackantosh :stuck_out_tongue:

Those new intel i7 dual core cpus are POWERFUL suckers. I can play wii games at full speed