Bill Hollings

Forum Replies Created

Viewing 21 posts - 101 through 121 (of 121 total)
  • Author
    Posts
  • in reply to: [***MetalGL ERROR***] GL_INVALID_VALUE #675
    Bill Hollings
    Keymaster

      @le-foot

      As the error message indicated, it looks like you have not linked your app to the MetalGL Shader Converter.

      The installation section of the README.md (or now README-UserGuide.md) document in the MetalGL package includes instructions for how to do that.

      …Bill

      in reply to: [***MetalGL ERROR***] GL_INVALID_VALUE #674
      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: 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 21 posts - 101 through 121 (of 121 total)