jtran56
commented
6 years ago Filed as internal issue #158488.
Closed zhoub closed 1 year ago
jtran56
commented
6 years ago Filed as internal issue #158488.
meshula
commented
6 years ago I notice this in your log - glVersion : 210
It looks like you have an old fixed-function context. Perhaps check how your context is created to make sure recent OpenGL is available? If you tell GL that you want a 3.2 core context, 4.1 features will be available.
zhoub
commented
6 years ago Hi,
I tested latest usdview with USD 0.8,4, and it always shows Hydra Disabled. According the stageView.py, the glFormat.setProfile(QtOpenGL.QGLFormat.CoreProfile) was commented out from _ init _ method, this explains that why the usdview could not pick up proper OpenGL context.
And also tried the Hydra rendering system from UsdMaya, the shader was not able to be compiled. I manually by tweaked the simpleLighting.glslfx and renderPass.glslfx as workaround.
According the GLEW log I attached to here, it supports up to GL_VERSION_4_0, higher versions are missing.
I will test more on OSX to make sure where are the issues when have time.
pberto
commented
6 years ago FYI This is on a slightly different GPU, Radeon 455.
You can see that anything after GL_VERSION_4_0 is missing.
---------------------------
GLEW Extension Info
---------------------------
GLEW version 2.1.0
Running on a AMD Radeon Pro 455 OpenGL Engine from ATI Technologies Inc.
OpenGL version 2.1 ATI-1.60.26 is supported
GL_VERSION_1_1: OK
---------------
GL_VERSION_1_2: OK
---------------
glCopyTexSubImage3D: OK
glDrawRangeElements: OK
glTexImage3D: OK
glTexSubImage3D: OK
GL_VERSION_1_2_1: OK
-----------------
GL_VERSION_1_3: OK
---------------
glActiveTexture: OK
glClientActiveTexture: OK
glCompressedTexImage1D: OK
glCompressedTexImage2D: OK
glCompressedTexImage3D: OK
glCompressedTexSubImage1D: OK
glCompressedTexSubImage2D: OK
glCompressedTexSubImage3D: OK
glGetCompressedTexImage: OK
glLoadTransposeMatrixd: OK
glLoadTransposeMatrixf: OK
glMultTransposeMatrixd: OK
glMultTransposeMatrixf: OK
glMultiTexCoord1d: OK
glMultiTexCoord1dv: OK
glMultiTexCoord1f: OK
glMultiTexCoord1fv: OK
glMultiTexCoord1i: OK
glMultiTexCoord1iv: OK
glMultiTexCoord1s: OK
glMultiTexCoord1sv: OK
glMultiTexCoord2d: OK
glMultiTexCoord2dv: OK
glMultiTexCoord2f: OK
glMultiTexCoord2fv: OK
glMultiTexCoord2i: OK
glMultiTexCoord2iv: OK
glMultiTexCoord2s: OK
glMultiTexCoord2sv: OK
glMultiTexCoord3d: OK
glMultiTexCoord3dv: OK
glMultiTexCoord3f: OK
glMultiTexCoord3fv: OK
glMultiTexCoord3i: OK
glMultiTexCoord3iv: OK
glMultiTexCoord3s: OK
glMultiTexCoord3sv: OK
glMultiTexCoord4d: OK
glMultiTexCoord4dv: OK
glMultiTexCoord4f: OK
glMultiTexCoord4fv: OK
glMultiTexCoord4i: OK
glMultiTexCoord4iv: OK
glMultiTexCoord4s: OK
glMultiTexCoord4sv: OK
glSampleCoverage: OK
GL_VERSION_1_4: OK
---------------
glBlendColor: OK
glBlendEquation: OK
glBlendFuncSeparate: OK
glFogCoordPointer: OK
glFogCoordd: OK
glFogCoorddv: OK
glFogCoordf: OK
glFogCoordfv: OK
glMultiDrawArrays: OK
glMultiDrawElements: OK
glPointParameterf: OK
glPointParameterfv: OK
glPointParameteri: OK
glPointParameteriv: OK
glSecondaryColor3b: OK
glSecondaryColor3bv: OK
glSecondaryColor3d: OK
glSecondaryColor3dv: OK
glSecondaryColor3f: OK
glSecondaryColor3fv: OK
glSecondaryColor3i: OK
glSecondaryColor3iv: OK
glSecondaryColor3s: OK
glSecondaryColor3sv: OK
glSecondaryColor3ub: OK
glSecondaryColor3ubv: OK
glSecondaryColor3ui: OK
glSecondaryColor3uiv: OK
glSecondaryColor3us: OK
glSecondaryColor3usv: OK
glSecondaryColorPointer: OK
glWindowPos2d: OK
glWindowPos2dv: OK
glWindowPos2f: OK
glWindowPos2fv: OK
glWindowPos2i: OK
glWindowPos2iv: OK
glWindowPos2s: OK
glWindowPos2sv: OK
glWindowPos3d: OK
glWindowPos3dv: OK
glWindowPos3f: OK
glWindowPos3fv: OK
glWindowPos3i: OK
glWindowPos3iv: OK
glWindowPos3s: OK
glWindowPos3sv: OK
GL_VERSION_1_5: OK
---------------
glBeginQuery: OK
glBindBuffer: OK
glBufferData: OK
glBufferSubData: OK
glDeleteBuffers: OK
glDeleteQueries: OK
glEndQuery: OK
glGenBuffers: OK
glGenQueries: OK
glGetBufferParameteriv: OK
glGetBufferPointerv: OK
glGetBufferSubData: OK
glGetQueryObjectiv: OK
glGetQueryObjectuiv: OK
glGetQueryiv: OK
glIsBuffer: OK
glIsQuery: OK
glMapBuffer: OK
glUnmapBuffer: OK
GL_VERSION_2_0: OK
---------------
glAttachShader: OK
glBindAttribLocation: OK
glBlendEquationSeparate: OK
glCompileShader: OK
glCreateProgram: OK
glCreateShader: OK
glDeleteProgram: OK
glDeleteShader: OK
glDetachShader: OK
glDisableVertexAttribArray: OK
glDrawBuffers: OK
glEnableVertexAttribArray: OK
glGetActiveAttrib: OK
glGetActiveUniform: OK
glGetAttachedShaders: OK
glGetAttribLocation: OK
glGetProgramInfoLog: OK
glGetProgramiv: OK
glGetShaderInfoLog: OK
glGetShaderSource: OK
glGetShaderiv: OK
glGetUniformLocation: OK
glGetUniformfv: OK
glGetUniformiv: OK
glGetVertexAttribPointerv: OK
glGetVertexAttribdv: OK
glGetVertexAttribfv: OK
glGetVertexAttribiv: OK
glIsProgram: OK
glIsShader: OK
glLinkProgram: OK
glShaderSource: OK
glStencilFuncSeparate: OK
glStencilMaskSeparate: OK
glStencilOpSeparate: OK
glUniform1f: OK
glUniform1fv: OK
glUniform1i: OK
glUniform1iv: OK
glUniform2f: OK
glUniform2fv: OK
glUniform2i: OK
glUniform2iv: OK
glUniform3f: OK
glUniform3fv: OK
glUniform3i: OK
glUniform3iv: OK
glUniform4f: OK
glUniform4fv: OK
glUniform4i: OK
glUniform4iv: OK
glUniformMatrix2fv: OK
glUniformMatrix3fv: OK
glUniformMatrix4fv: OK
glUseProgram: OK
glValidateProgram: OK
glVertexAttrib1d: OK
glVertexAttrib1dv: OK
glVertexAttrib1f: OK
glVertexAttrib1fv: OK
glVertexAttrib1s: OK
glVertexAttrib1sv: OK
glVertexAttrib2d: OK
glVertexAttrib2dv: OK
glVertexAttrib2f: OK
glVertexAttrib2fv: OK
glVertexAttrib2s: OK
glVertexAttrib2sv: OK
glVertexAttrib3d: OK
glVertexAttrib3dv: OK
glVertexAttrib3f: OK
glVertexAttrib3fv: OK
glVertexAttrib3s: OK
glVertexAttrib3sv: OK
glVertexAttrib4Nbv: OK
glVertexAttrib4Niv: OK
glVertexAttrib4Nsv: OK
glVertexAttrib4Nub: OK
glVertexAttrib4Nubv: OK
glVertexAttrib4Nuiv: OK
glVertexAttrib4Nusv: OK
glVertexAttrib4bv: OK
glVertexAttrib4d: OK
glVertexAttrib4dv: OK
glVertexAttrib4f: OK
glVertexAttrib4fv: OK
glVertexAttrib4iv: OK
glVertexAttrib4s: OK
glVertexAttrib4sv: OK
glVertexAttrib4ubv: OK
glVertexAttrib4uiv: OK
glVertexAttrib4usv: OK
glVertexAttribPointer: OK
GL_VERSION_2_1: OK
---------------
glUniformMatrix2x3fv: OK
glUniformMatrix2x4fv: OK
glUniformMatrix3x2fv: OK
glUniformMatrix3x4fv: OK
glUniformMatrix4x2fv: OK
glUniformMatrix4x3fv: OK
GL_VERSION_3_0: OK
---------------
glBeginConditionalRender: OK
glBeginTransformFeedback: OK
glBindFragDataLocation: OK
glClampColor: OK
glClearBufferfi: OK
glClearBufferfv: OK
glClearBufferiv: OK
glClearBufferuiv: OK
glColorMaski: OK
glDisablei: OK
glEnablei: OK
glEndConditionalRender: OK
glEndTransformFeedback: OK
glGetBooleani_v: OK
glGetFragDataLocation: OK
glGetStringi: OK
glGetTexParameterIiv: OK
glGetTexParameterIuiv: OK
glGetTransformFeedbackVarying: OK
glGetUniformuiv: OK
glGetVertexAttribIiv: OK
glGetVertexAttribIuiv: OK
glIsEnabledi: OK
glTexParameterIiv: OK
glTexParameterIuiv: OK
glTransformFeedbackVaryings: OK
glUniform1ui: OK
glUniform1uiv: OK
glUniform2ui: OK
glUniform2uiv: OK
glUniform3ui: OK
glUniform3uiv: OK
glUniform4ui: OK
glUniform4uiv: OK
glVertexAttribI1i: OK
glVertexAttribI1iv: OK
glVertexAttribI1ui: OK
glVertexAttribI1uiv: OK
glVertexAttribI2i: OK
glVertexAttribI2iv: OK
glVertexAttribI2ui: OK
glVertexAttribI2uiv: OK
glVertexAttribI3i: OK
glVertexAttribI3iv: OK
glVertexAttribI3ui: OK
glVertexAttribI3uiv: OK
glVertexAttribI4bv: OK
glVertexAttribI4i: OK
glVertexAttribI4iv: OK
glVertexAttribI4sv: OK
glVertexAttribI4ubv: OK
glVertexAttribI4ui: OK
glVertexAttribI4uiv: OK
glVertexAttribI4usv: OK
glVertexAttribIPointer: OK
GL_VERSION_3_1: OK
---------------
glDrawArraysInstanced: OK
glDrawElementsInstanced: OK
glPrimitiveRestartIndex: OK
glTexBuffer: OK
GL_VERSION_3_2: OK
---------------
glFramebufferTexture: OK
glGetBufferParameteri64v: OK
glGetInteger64i_v: OK
GL_VERSION_3_3: OK
---------------
glVertexAttribDivisor: OK
GL_VERSION_4_0: OK
---------------
glBlendEquationSeparatei: OK
glBlendEquationi: OK
glBlendFuncSeparatei: OK
glBlendFunci: OK
glMinSampleShading: OK
GL_VERSION_4_1: MISSING
---------------
GL_VERSION_4_2: MISSING
---------------
GL_VERSION_4_3: MISSING
---------------
GL_VERSION_4_4: MISSING
---------------
GL_VERSION_4_5: MISSING
---------------
glGetGraphicsResetStatus: MISSING
glGetnCompressedTexImage: MISSING
glGetnTexImage: MISSING
glGetnUniformdv: MISSING
GL_VERSION_4_6: MISSING
---------------
glMultiDrawArraysIndirectCount: MISSING
glMultiDrawElementsIndirectCount: MISSING
glSpecializeShader: MISSINGGLEW issue maybe? 4.1 is officially supported. https://developer.apple.com/opengl/OpenGL-Capabilities-Tables.pdf
pberto
commented
6 years ago I checked with glew on my iMac 2013 with Nvidia:
GL_VERSION_3_3: OK
---------------
glVertexAttribDivisor: OK
GL_VERSION_4_0: OK
---------------
glBlendEquationSeparatei: OK
glBlendEquationi: OK
glBlendFuncSeparatei: OK
glBlendFunci: OK
glMinSampleShading: OK
GL_VERSION_4_1: MISSING
---------------
GL_VERSION_4_2: MISSING
---------------
GL_VERSION_4_3: MISSING
---------------We need to have support for GL 4.3 at least.
pberto
commented
6 years ago When can we expect Hydra to switch from OpenGL to Metal on macOS? If you could provide an ETA, even if remote, it would give some perspective.
bmrosen
commented
6 years ago So... has anyone gotten Hydra to work on OSX? I haven't gotten past zhoub's issue. Uncommenting the glFormat.setProfile line in stageView.py didn't work. Explicitly requesting version 4.1 with glFormat.setVersion(4,1) doesn't work. No matter what I seem to do, the glString(GL_VERSION) still ends up being "2.1 INTEL-12.0.34" (which is the string that the HdStRenderDelegate::IsSupported seems to use to figure out what OpenGL is supported).
I've kludged the GlfContextCaps code to fool the system into thinking OpenGL 4.1 is supported (because... Apple claims it is) but now I'm getting GLSL compilation issues. I'll keep on plugging away, but I'm curious if anyone's gotten this working.
pberto
commented
6 years ago +1, @PixarAnimationStudios: maybe time to move Hydra to Metal2? Being this a widespread project, all platforms should be supported (and thoroughly tested) without exceptions.
bmrosen
commented
6 years ago I dunno @pberto, seems to me that's exactly why it's open source and not a product for sale. If someone needs Metal2 support, they're more than free to code that up. Pixar certainly doesn't have much need for Metal2 support internally and not much reason to dedicate engineers for that. (Although I could see Apple maybe doing that in the near future.)
drwave
commented
6 years ago A Metal port that Apple is doing was demoed at the RenderMan Science and Art fair and was mentioned at the BOF.
It was shown playing the canonical Finding Dory shot (that is usually used by Pixar to demo usdview) on an iMac Pro at speed. There were some features missing (I think Instancing was broken), but it looked great, and the folks doing the work seemed very capable.
I have high hopes.
On Oct 20, 2018, at 1:56 PM, bmrosen notifications@github.com wrote:
I dunno @pberto, seems to me that's exactly why it's open source and not a product for sale. If someone needs Metal2 support, they're more than free to code that up. Pixar certainly doesn't have much need for Metal2 support internally and not much reason to dedicate engineers for that. (Although I could see Apple maybe doing that in the near future.)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
bmrosen
commented
6 years ago For those following along at home:
Looks like it's not possible to properly set the CoreProfile properly using PySide, but it does seem to work with PySide2 (which explains the "# XXX: for OSX (QT5 required)" comment where the setProfile was commented out.) I'm now successfully getting GL 4.1 from my Intel graphics chip.
Things are still rough with the OSX build though. The glslfx shaders do a bunch of swizzling into integers that's unsupported in GLSL v4.1 as well as some miscellaneous casting problems. I've managed to address all the shader compilation errors, but the simpleShading example still isn't working. And the main window UI is all misshapen.
@drwave, do you know if the Apple folks got Hydra working on their machines?
drwave
commented
6 years ago Hey Brian. If the question is do I know if they got it working as checked in using OpenGL - I do not know.
I do know that that they demoed it working on an iMac Pro at Siggraph, where they said it was an in progress port to Metal.
Sent from my iPad
On Oct 21, 2018, at 10:02 PM, bmrosen notifications@github.com wrote:
For those following along at home:
Looks like it's not possible to properly set the CoreProfile properly using PySide, but it does seem to work with PySide2 (which explains the "# XXX: for OSX (QT5 required)" comment where the setProfile was commented out.) I'm now successfully getting GL 4.1 from my Intel graphics chip.
Things are still rough with the OSX build though. The glslfx shaders do a bunch of swizzling into integers that's unsupported in GLSL v4.1 as well as some miscellaneous casting problems. I've managed to address all the shader compilation errors, but the simpleShading example still isn't working. And the main window UI is all misshapen.
@drwave, do you know if the Apple folks got Hydra working on their machines?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
poljere
commented
6 years ago Hydra itself does not depend on GL, Hydra is a framework to connect scenegraphs and renderers.
However, as part of the USD distribution, we provide a backend (renderer) called Stream which uses OpenGL. As is today, that renderer won't work correctly on the Mac (due to GL version differences) and, if you run usdview you will basically get a old/legacy renderer that has nothing to do with Stream (unless you have Embree or any other renderer installed).
Having said that, we saw a PR recently (https://github.com/PixarAnimationStudios/USD/pull/622) that was exploring the possibility of using GL4 in usdview on Mac, which is a first step towards using Stream. Even with that change though, Stream would still need to be better at gracefully handling GL versions < 4.5.
As others have already said here, a metal backend was shown at SIGGRAPH 2018.
Thanks! Pol.
bmrosen
commented
6 years ago Thanks for the info @poljere. So that's what the St in HdSt is - Stream? That wasn't clear from the documentation. Speaking of which, is there much documentation for this stuff? I see some high level explanation of Hydra architecture, but not so much about how renders are to interact with it.
The following page is all I've found. And it doesn't seem to distinguish between Hydra and Stream. Or is it all out of date? So far it seems like the best bet is just tracing the code from usdview.
poljere
commented
6 years ago The Hydra APIs are evolving very quickly, and we're not quite ready for them to be stable. We should update incorrect information in the documentation though, thanks for letting us know!
chadrik
commented
6 years ago I've heard Stream referred to variously as HdSt, HdStream, HydraGL, and just plain Hydra, so there's a lot of confusion in the community surrounding this. Even if the APIs are in flux, I think it would be helpful to pick a name and stamp it out all over the place.
On Mon, Oct 22, 2018 at 5:23 PM Pol notifications@github.com wrote:
The Hydra APIs are evolving very quickly, and we're not quite ready for them to be stable. We should update incorrect information in the documentation though, thanks for letting us know!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PixarAnimationStudios/USD/issues/430#issuecomment-431992433, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD3E8t5b-ts7-8vp0HUDPNx_2vZQq1bks5unjdIgaJpZM4Suvmk .
bmrosen
commented
6 years ago Soo... @poljere, it sounds like if someone were to want to write some other backend renderer for Hydra it would be better to wait? Is there a time frame?
poljere
commented
6 years ago @bmrosen We do encourage people to write backends today and many have already, the only thing we would like to ask is that you would be understanding in the case of any API changes.
@chadrik Agreed! We hope to clarify the naming of the components in the upcoming months.
davidgyu
commented
1 year ago Hydra Storm now runs native using Metal on macOS thanks to tremendous contributions by Apple and the community. This has been available since USD v22.05 and continues to improve with each release. This should work on macs with integrated Intel GPUs, macs with discrete AMD GPUs, as well as the latest macs with Apple Silicon GPUs (M1, M2, etc).
Hi
I'm using a MBP with independent GPU AMD Radeon Pro 450, installed latest high Serria, but unfortuanlly even this machine doesn't support Hydra, and here is the specification from HdStRenderContextCaps
So that the HdSt_CodeGen could not generate the correct shader source. I knew that everybody works on the workstation here, but it still would be great if we could supply back compatibility to user.
Thank you very much.
GPU specification from GLEW MBP_glew_AMD_Radeon_450.log