Bill Hollings

Forum Replies Created

Viewing 19 posts - 101 through 119 (of 119 total)
  • Author
    Posts
  • in reply to: EAGLContext renderbufferStorage:fromDrawable fails #673

    Bill Hollings
    Keymaster

    The latest release of MetalGL is out, and includes a fix for the iOS 9 issue mentioned above.

    MetalGL 0.10.0 can be downloaded here.

    …Bill

    in reply to: [***MetalGL ERROR***] GL_INVALID_VALUE #661

    Bill Hollings
    Keymaster

    @le-foot

    Are you running this on a device with iOS 9? If so, there is a known issue with a change to the Metal API on iOS 9 that causes the pixel format error.

    This is fixed in the MetalGL release that is due out at the end of this week.

    In the meantime, do you have a device running iOS 8 that you can test with?

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #660

    Bill Hollings
    Keymaster

    @le-foot

    Are you running this on a device with iOS 9? If so, there is a known issue with a change to the Metal API on iOS 9 that causes the pixel format error.

    This is fixed in the MetalGL release that is due out at the end of this week.

    In the meantime, do you have a device running iOS 8 that you can test with?

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #658

    Bill Hollings
    Keymaster

    @le-foot

    Okay…if you’re able to replicate the error in a less proprietary app, we can have a look.

    Otherwise, the problem is happening inside Metal during the creation of a MTLRenderPipelineState. If you are running the app in Release mode, can you try running it in Debug mode instead, to get Metal to output more in the logs, and then post them here?

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #655

    Bill Hollings
    Keymaster

    @le-foot

    Are you able to ZIP up the Xcode project and post it to somewhere like Dropbox, so we can have a look at it?

    If you’re concerned about posting it publicly, you can post it privately, and then send a link to support@metalgl.com.

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #653

    Bill Hollings
    Keymaster

    @le-foot

    Was an error output to the log?

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #651

    Bill Hollings
    Keymaster

    @le-foot

    Make sure the Xcode project (or subproject) in which the GetSystemContext() function is implemented is configured to use MetalGL as described in the installation section of the README.md document. Make sure that the user header override build settings parts of that configuration are set to be recursive, and if you have multiple targets in your project, make sure they are either set at the project level, or set for each target that need them.

    …Bill

    in reply to: [***MetalGL ERROR***] GL_INVALID_VALUE #650

    Bill Hollings
    Keymaster

    @le-foot

    Thanks for bringing this to our attention. It looks like you’ve uncovered an issue with how MetalGL handles the deletion of a shader that has just been attached to a program.

    We’ll fix this for the next release. In the meantime, you can work around the issue in GLEssentials by commenting out the calls to glDeleteShader() in OpenGLRender.m.

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #648

    Bill Hollings
    Keymaster

    @le-foot

    MetalGL works by replacing the OpenGL functions and classes with compatible components that replace the native OpenGL functionality with equivalent functionality based on Metal.

    What is the class of the return value of your GetSystemContext() function? It needs to be an instance of MGLEAGLContext. That will happen if the implementation of the GetSystemContext() function has access to the MetalGL headers (as explained in the README.md doc). It won’t work if the GetSystemContext() function comes from an pre-compiled library, and is returning an instance of an OpenGL system class.

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #645

    Bill Hollings
    Keymaster

    @le-foot

    And are you seeing an error message in the console logs?

    If Metal is active, when renderbufferStorage:fromDrawable: returns false, it spits out an error message to the console log. The error message will either indicate that the drawable is not a CAMetalLayer or that the target is not GL_RENDERBUFFER.

    If Metal is not active, then the false is arising from the native EAGLContext.

    …Bill

    in reply to: EAGLContext renderbufferStorage:fromDrawable fails #643

    Bill Hollings
    Keymaster

    @le-foot

    If renderbufferStorage:fromDrawable: returns false, then you should be seeing an error logged in the console. It should provide you with more info.

    If the error message indicates that the Drawable must be an instance of CAMetalLayer, the problem is that the CALayer underlying your view is not compatible with Metal.

    How is your view created, and how does it create its underlying CALayer?

    Make sure that the code that creates the CALayer imports <QuartzCore/CAEAGLLayer.h>, <QuartzCore/QuartzCore.h> or <QuartzCore/CoreAnimation.h>, and that the path to CAEAGLLayer.h is being redirected to RedirectHeaders/include/QuartzCore/CAEAGLLayer.h, so that CAEAGLLayer will be redefined to MGLCAEAGLLayer.

    …Bill

    in reply to: Multi-sampling #641

    Bill Hollings
    Keymaster

    @adedkov

    Thanks for your interest in MetalGL.

    Multisampling is an important feature, and is planned to be included in version 1.0, which should be released within a couple of months.

    …Bill

    in reply to: Crash on App Start #639

    Bill Hollings
    Keymaster

    @makaroni

    It looks like you are using Apple’s GLKView class, instead of the MetalGL replacement.

    Be sure that your headers are being redirected correctly, as described in the installation section of the README.md document.

    If you are using a Storyboard to create the GLKView, be sure to declare a custom subclass (e.g. MyGLKView) and use it in your Storyboard instead. For more info on using GLKView, have a look at this section in the README.md document.

    …Bill

    in reply to: CVOpenGLESTextureCache (CoreVideo) #616

    Bill Hollings
    Keymaster

    @ilnar.aliullov

    Interesting issue.

    Since much of the CVOpenGLES... family of functions and structs are opaque, it will be a challenge to provide an effective and complete implementation directly. In the longer term, we might consider doing so.

    However, your second suggestion, of extracting Metal textures from CoreVideo makes a lot of sense.

    What is currently missing from MetalGL to allow this to happen is the ability to create an OpenGL texture reference from the Metal texture returned from CVMetalTextureCacheCreateTextureFromImage, so that it can be used in functions like glBindTexture().

    One of the goals of MetalGL is to provide the ability to combine OpenGL and Metal functionality, so this is definitely something we have planned. It should be fairly straightforward, and we should be able to make that available by the end of this month. I’ll post more here when it is ready.

    …Bill

    in reply to: Unknown GLenum value (0x84BF) #613

    Bill Hollings
    Keymaster

    @ilnar.aliullov

    Thanks for sending us your stack trace of this error.

    It looks like you’re hitting an issue that arises when a GLSL shader includes a texture sampler that has not been initialized by the application code (i.e.- the app does not set the sampler uniform value). The missing sampler value is not necessarily an error, as it can make sense with shaders that follow selective execution paths. Unfortunately, the current public release of MetalGL does not assume a default sampler value, when the sampler uniform value is not explicitly set by the app, and this is what is causing the error.

    The pre-release version of MetalGL available here fixes this issue. Please download it and give it a try. This fix should be in an upcoming production release of MetalGL by the end of this month.

    …Bill

    in reply to: Unknown GLenum value (0x84BF) #611

    Bill Hollings
    Keymaster

    @ilnar.aliullov

    We’re sorry to hear you’re having trouble.

    Is the OpenGL enumerant 0x84BF something you are using from a custom extension?

    If not, can you provide further info about the environment you are running (iOS version, device, etc).

    Are you able to ZIP up an Xcode project that demonstrates the issue, post it to a site like Dropbox, and then post a link here? We can then have a look at it directly. If your project is not something you want to post in public, once you have posted the ZIP to a site like Dropbox, you can email the private link to support@metalgl.com.

    …Bill

    in reply to: Other platforms ? #608

    Bill Hollings
    Keymaster

    Thanks for having a look at MetalGL!

    Can you clarify what you are asking?

    Are you asking whether MetalGL will bring additional graphics technologies (such as DX) from those platforms to iOS & OSX? If so, we’re certainly looking into that!

    Or are you asking whether we will port MetalGL to those other platforms, using native enhancement technologies? For now, MetalGL is focused on bringing compatibility and performance to the iOS and OSX platforms, by using Metal as a performance enhancer. Later on, we may use similar performance technologies and expertise on those other platforms, but that will be further down the road.

    Or are you asking something else that I haven’t picked up on?

    …Bill

    in reply to: OSX Metal support? ES 3.0/3.1 support? #603

    Bill Hollings
    Keymaster

    @oscarbg

    Adding support for OpenGL ES 3.0 & 3.1 is definitely a priority for MetalGL, and we’re actively working on it!

    We’re also quite excited about Apple’s announcement of support for Metal on OSX! It opens up several interesting possibilities for MetalGL. Look for future announcements from us on that front soon!

    At The Brenwill Workshop Ltd., we’re fans of open-source as an effective model for developing and deploying certain types of software products, as we’ve demonstrated with Cocos3D.

    However, MetalGL is designed to be a plug-and-play framework, and we believe a direct licensing model provides the best mechanism to develop, maintain, deploy, and support it as a product. At this time, we have no plans to release an open-source version.

    Qualified customers who need or want source access may purchase a source-access license for MetalGL by contacting us directly.

    …Bill


    Bill Hollings
    Keymaster

    @mxweas

    You ask a very good question.

    I’ll preface this by recognizing that Apple, being Apple, will do anything they think is in their best interests, of course. And trying to predict what they will or will not do in the future is an entire industry with a history of both successes and failures.

    So…anything can happen, but we think Apple will not head down that road.

    Their entire investment in (and marketing of) Metal is based on it being faster than the OpenGL framework family. For them to then make OpenGL run equivalently fast would raise the question…why bother introducing and marketing a new product at all? In other words, why not simply use the technology underlying Metal to streamline OpenGL itself right from the start (which is basically what MetalGL does)?

    In addition, Apple is asking an entire industry of developers to commit to rewriting and maintaining game engines, graphics libraries, games, and apps, in a new technology that is fundamentally different than OpenGL in API, structure, and shaders. It would be a bit of a slap in the face if Apple was to come back a year or two later and tell these developers they could have ended up with the same results by simply waiting and doing nothing.

    We think Apple has made a strategic decision to invest in and introduce a new, proprietary graphics technology and API that is intentionally distinct from, and incompatible with, OpenGL.

    By contrast, the transition ES1 -> ES2 -> ES3 was more tactical. Implementing ES1 via ES2 was really about not having to dedicate GPU hardware to older fixed-pipeline technology. And ES3 is a backwards-compatible extension of ES2. You don’t so much replace ES2 with ES3, as augment it.

    Metal is, without a doubt, a newer, better-designed, and faster environment than legacy OpenGL, which evolved over a long period of time. However, it is a single-vendor solution to the problem of where to take graphics technology in the future, and Apple has a vested interest in locking the technology to their ecosystem. From a compatibility and portability perspective, Metal creates problems.

    That’s where MetalGL comes in. It provides the ability for developers to benefit from Metal, while maintaining compatibility with their own past investments in OpenGL, and provides industry-wide portability for their games, apps and graphics libraries.

    …Bill

Viewing 19 posts - 101 through 119 (of 119 total)