Building without installing

hamarb123 commented 2 years ago

How do I build without having to install all of these things into my /usr directory, and what should I reinstall/delete from that directory with brew. I don't want to stuff up my installations of things. Thanks :)

douira commented 2 years ago

I also made the mistake of actually running make install which seriously gummed up my /usr. I recommend checking out the install instructions given on #5 which worked for me.

darkaegisagain commented 2 years ago

I guess we can modify the Xcode project to build locally for debug and have an install version for release... libMGL.dylib is targeted at /usr/local/lib and /usr/local/include/GL all the Khronos libs can be built locally.

I know installing it to /usr leaves a bit of trash around but its a pretty nonstandard location for MacOS applications.

hamarb123 commented 2 years ago

/usr is not non-standard in my opinion, everything from Homebrew gets put all throughout there. It's probably stuffed up half of my installations :( Edit: also the XCode project directly references a specific user folder in multiple spots

hamarb123 commented 2 years ago

I also made the mistake of actually running make install which seriously gummed up my /usr. I recommend checking out the install instructions given on #5 which worked for me.

Thanks - I am looking into this

hamarb123 commented 2 years ago

I'm now trying to use

make install-pkgdeps
make -j test

Is this what I'm supposed to be using? Thanks :)

douira commented 2 years ago

That's what I used and it produced a built product. However, if you run into issues then there's a few things described in the thread you can try to fix it.

hamarb123 commented 2 years ago

I'm getting

MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7850:3: error: cannot initialize a parameter of type 'spv::Op' with an lvalue of type 'uint32_t' (aka 'unsigned int')
                MSL_AFMO(and);
                ^~~~~~~~~~~~~
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7820:22: note: expanded from macro 'MSL_AFMO'
#define MSL_AFMO(op) MSL_AFMO_IMPL(op, ops[5], false)
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7816:73: note: expanded from macro 'MSL_AFMO_IMPL'
                emit_atomic_func_op(result_type, id, "atomic_fetch_" #op "_explicit", mem_sem, mem_sem, false, ptr, val, \
                                                                                      ^~~~~~~
external/SPIRV-Cross/spirv_msl.hpp:924:93: note: passing argument to parameter 'opcode' here
        void emit_atomic_func_op(uint32_t result_type, uint32_t result_id, const char *op, spv::Op opcode,
                                                                                                   ^
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7854:3: error: cannot initialize a parameter of type 'spv::Op' with an lvalue of type 'uint32_t' (aka 'unsigned int')
                MSL_AFMO(or);
                ^~~~~~~~~~~~
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7820:22: note: expanded from macro 'MSL_AFMO'
#define MSL_AFMO(op) MSL_AFMO_IMPL(op, ops[5], false)
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7816:73: note: expanded from macro 'MSL_AFMO_IMPL'
                emit_atomic_func_op(result_type, id, "atomic_fetch_" #op "_explicit", mem_sem, mem_sem, false, ptr, val, \
                                                                                      ^~~~~~~
external/SPIRV-Cross/spirv_msl.hpp:924:93: note: passing argument to parameter 'opcode' here
        void emit_atomic_func_op(uint32_t result_type, uint32_t result_id, const char *op, spv::Op opcode,
                                                                                                   ^
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7858:3: error: cannot initialize a parameter of type 'spv::Op' with an lvalue of type 'uint32_t' (aka 'unsigned int')
                MSL_AFMO(xor);
                ^~~~~~~~~~~~~
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7820:22: note: expanded from macro 'MSL_AFMO'
#define MSL_AFMO(op) MSL_AFMO_IMPL(op, ops[5], false)
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:7816:73: note: expanded from macro 'MSL_AFMO_IMPL'
                emit_atomic_func_op(result_type, id, "atomic_fetch_" #op "_explicit", mem_sem, mem_sem, false, ptr, val, \
                                                                                      ^~~~~~~
external/SPIRV-Cross/spirv_msl.hpp:924:93: note: passing argument to parameter 'opcode' here
        void emit_atomic_func_op(uint32_t result_type, uint32_t result_id, const char *op, spv::Op opcode,
                                                                                                   ^
MGL/SPIRV/SPIRV-Cross/spirv_msl.cpp:8802:19: error: out-of-line definition of 'emit_atomic_func_op' does not match any declaration in 'spirv_cross::CompilerMSL'
void CompilerMSL::emit_atomic_func_op(uint32_t result_type, uint32_t result_id, const char *op, uint32_t mem_order_1,
                  ^~~~~~~~~~~~~~~~~~~

I don't think I saw anything on that thread about that. What do I do about this? Thanks

hamarb123 commented 2 years ago

I guess we can modify the Xcode project to build locally for debug and have an install version for release... libMGL.dylib is targeted at /usr/local/lib and /usr/local/include/GL all the Khronos libs can be built locally.

I know installing it to /usr leaves a bit of trash around but its a pretty nonstandard location for MacOS applications.

Thanks, I've managed to remove all of these :)

darkaegisagain commented 2 years ago

Looks like there is a dependency on an installed version of SPIRV-Cross, let me check the header includes for MGL.

I really need to get rid of the SPIRV-Cross files in the project and just use the libraries... but for debugging crashes in SPIRV-Cross and SPIRV-Tools I had to include them... and both were a big black box with little or no documentation so I had to figure out what it was doing by walking the code.

darkaegisagain commented 2 years ago

I ran update_external.sh and build_external.sh and it built fine from Xcode, not sure what the differences are between builds. I will delete any /usr trash that may be hanging around and see if that makes a difference.

conversy commented 2 years ago

I'm now trying to use
make install-pkgdeps
make -j test
Is this what I'm supposed to be using? Thanks :)

yes. Looking at the Makefile, this command (make install-pkgdeps) does this:

install-pkgdeps:
    brew install glm glslang spirv-tools glfw3
    (cd .. && git clone --depth 1 https://github.com/KhronosGroup/SPIRV-Headers)
    (cd .. && git clone --depth 1 https://github.com/KhronosGroup/SPIRV-Cross)
    (cd ../SPIRV-Cross && mkdir -p build && cd build && cmake .. && make)

First it installs as-much-as-regular dependencies (including glfw, see below)). Then it git clones two directories: you should have two new directories next to MGL: SPIRV-Headers and SPIRV-Cross. Only SPIRV-Cross requires to be built, which is done on the last line of the command.

The MGL Makefile will take care of the right headers and libs for you if you comment the correct lines in the Makefile, or if you create a config.mk next to Makefile file that reads:

spirv_headers_path := ../SPIRV-Headers/include/spirv/1.2
spirv_cross_include_path := ../SPIRV-Cross
spirv_cross_lib_path := ../SPIRV-Cross/build

(it's better not to modify the Makefile and use config.mk).

Then a simple `make -j test' should compile everything and launch the test.

Beware, the Makefile does not compile and does not use the modified glfw anymore. If the test fails to launch due to an incorrect OpenGL context version, change glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6); with glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);

Around line 2831 in test_mgl_glfw/main.cpp

darkaegisagain commented 2 years ago

I think it may be loading the apple OpenGL framework, if you ask for 4.6 the apple OpenGL framework will fail.

glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);

I would have to trace and check, but the 4.1 issue may be a GLFW thing.

hamarb123 commented 2 years ago

Thanks for your guidance, I've managed to get it built, but I had to do some modification of files. Here is it running:

Is it meant to be antialiased? - I have a retina display This is it without the retina mode on: (no antialiasing) The main thing I did to get it built is removing the MGL/SPIRV/SPIRV-Cross (& modifying the makefile) since it was causing these errors: https://github.com/openglonmetal/MGL/issues/9#issuecomment-1018992589. Also, how do I force it to use the modified glfw and make it use GL 4.6? And how do I verify that it is actually using metal, since usually gSwitch doesn't tell me it's using the Discrete GPU when metal uses it - but it does when I run this (indicating it is using system OpenGL)?

darkaegisagain commented 2 years ago

Interesting, my iMac just uses the AMD... it definitely using MGL, the system OpenGL doesn't support compute shaders or any of the 4.6 features used by this demo.

Right now MGL chooses the default device given, check out MGLRenderer.m that's where the device is picked up.

hamarb123 commented 2 years ago

I've now replaced the code for selecting the Metal device & can confirm that it's using 2 different GPUs. This is what I've used so I can test different devices:

NSArray<id<MTLDevice>>* _devices = MTLCopyAllDevices();
for (id<MTLDevice> object in _devices)
{
    if (![object isLowPower]) //I can change this line to switch to iGPU
    {
        _device = object;
        break;
    }
}
if (!_device && [_devices count] > 0)
{
    _device = [_devices objectAtIndex:0];
}
assert(_device);

I've noticed however, that it is quite glitchy. On iGPU, the white part is transparent, but it rotates. Whereas on AMD GPU, the white part is there, but it only glitches (some pixels seem to change) instead of rotating.

I've got a temporary fix to it ignoring retina as well, the correct fix would be updating _layer.contentsScale every time the window moves to a new screen, or the screen configuration changes if the user specifies GLFW_COCOA_RETINA_FRAMEBUFFER = GL_TRUE (I've just set it to 2 lol).

On my apps, I use windowDidChangeScreen and CGDisplayRegisterReconfigurationCallback & CGDisplayRemoveReconfigurationCallback and extract the backingScaleFactor from the screen. I'm not sure how to integrate all of this into your codebase though, so I'll leave that up to you to do properly.

Also, how do I force it to use & build the modified glfw (I'll need the glfw for my use case).

darkaegisagain commented 2 years ago

Thanks!

I believe make lib will make the modified version of glfw, I use Xcode which builds it automatically.

The modified version will be built to build and you can just link there.

CGDisplayRegisterReconfigurationCallback & CGDisplayRemoveReconfigurationCallback are catching the switch from low to high power modes.. hmm. If you can integrate a callback in glm_context.c that would probably be the place then make up a objc call to MGLRenderer.m to update the _device. I am ok with that if it works.

Mike

"The difference between communism and socialism is that under socialism central planning ends with a gun in your face, whereas under communism central planning begins with a gun in your face." ― Kevin D. Williamson

On Wed, Jan 26, 2022 at 12:21 PM Hamish Arblaster @.***> wrote:

I've now replaced the code for selecting the Metal device & can confirm that it's using 2 different GPUs. This is what I've used so I can test different devices:

NSArray<id>* _devices = MTLCopyAllDevices();for (id object in _devices) { if (![object isLowPower]) //I can change this line to switch to iGPU { _device = object; break; } }if (!_device && [_devices count] > 0) { _device = [_devices objectAtIndex:0]; }assert(_device);

I've noticed however, that it is quite glitchy. On iGPU, the white part is transparent, but it rotates. Whereas on AMD GPU, the white part is there, but it only glitches (some pixels seem to change) instead of rotating.

I've got a temporary fix to it ignoring retina as well, the correct fix would be updating _layer.contentsScale every time the window moves to a new screen, or the screen configuration changes if the user specifies GLFW_COCOA_RETINA_FRAMEBUFFER = GL_TRUE (I've just set it to 2 lol).

On my apps, I use windowDidChangeScreen https://developer.apple.com/documentation/appkit/nswindowdelegate/1419267-windowdidchangescreen?language=objc and CGDisplayRegisterReconfigurationCallback & CGDisplayRemoveReconfigurationCallback and extract the backingScaleFactor from the screen. I'm not sure how to integrate all of this into your codebase though, so I'll leave that up to you to do properly.

Also, how do I force it to use & build the modified glfw (I'll need the glfw for my use case).

— Reply to this email directly, view it on GitHub https://github.com/openglonmetal/MGL/issues/9#issuecomment-1022570162, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOKD35HQQDNSCEF5TK2WZTUYBJVLANCNFSM5MQ4K7FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

darkaegisagain commented 2 years ago

I guess we could do it all in MGLRenderer.m, there is a copy of the ObjC MGLRenderer object in the glm_context... I guess you would just have to figure out how to wire it up.

"The difference between communism and socialism is that under socialism central planning ends with a gun in your face, whereas under communism central planning begins with a gun in your face." ― Kevin D. Williamson

On Wed, Jan 26, 2022 at 1:36 PM Michael Larson @.***> wrote:

Thanks!

I believe make lib will make the modified version of glfw, I use Xcode which builds it automatically.

The modified version will be built to build and you can just link there.

CGDisplayRegisterReconfigurationCallback & CGDisplayRemoveReconfigurationCallback are catching the switch from low to high power modes.. hmm. If you can integrate a callback in glm_context.c that would probably be the place then make up a objc call to MGLRenderer.m to update the _device. I am ok with that if it works.

Mike

"The difference between communism and socialism is that under socialism central planning ends with a gun in your face, whereas under communism central planning begins with a gun in your face." ― Kevin D. Williamson

On Wed, Jan 26, 2022 at 12:21 PM Hamish Arblaster < @.***> wrote:

I've now replaced the code for selecting the Metal device & can confirm that it's using 2 different GPUs. This is what I've used so I can test different devices:

NSArray<id>* _devices = MTLCopyAllDevices();for (id object in _devices) { if (![object isLowPower]) //I can change this line to switch to iGPU { _device = object; break; } }if (!_device && [_devices count] > 0) { _device = [_devices objectAtIndex:0]; }assert(_device);

I've noticed however, that it is quite glitchy. On iGPU, the white part is transparent, but it rotates. Whereas on AMD GPU, the white part is there, but it only glitches (some pixels seem to change) instead of rotating.

I've got a temporary fix to it ignoring retina as well, the correct fix would be updating _layer.contentsScale every time the window moves to a new screen, or the screen configuration changes if the user specifies GLFW_COCOA_RETINA_FRAMEBUFFER = GL_TRUE (I've just set it to 2 lol).

On my apps, I use windowDidChangeScreen https://developer.apple.com/documentation/appkit/nswindowdelegate/1419267-windowdidchangescreen?language=objc and CGDisplayRegisterReconfigurationCallback & CGDisplayRemoveReconfigurationCallback and extract the backingScaleFactor from the screen. I'm not sure how to integrate all of this into your codebase though, so I'll leave that up to you to do properly.

Also, how do I force it to use & build the modified glfw (I'll need the glfw for my use case).

— Reply to this email directly, view it on GitHub https://github.com/openglonmetal/MGL/issues/9#issuecomment-1022570162, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOKD35HQQDNSCEF5TK2WZTUYBJVLANCNFSM5MQ4K7FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

hamarb123 commented 2 years ago

I've used make lib to use the modified glfw, thanks! It works with OpenGL 4.6 now. Also, I was having trouble with XCode, it was caused by all the signing values and this (for some of the projects):

I still get this when I try to launch through XCode:

Do you have any idea how to fix this?

darkaegisagain commented 2 years ago

You may have to install the Xcode command line tools (see web) or install make from brew.

You may not be able to start it because of signing, if you have a developer ID you can use your own.

Yeah.. I don't know how to release a clean version of the Xcode project.. I should just apply for a new developer ID and run it under that, I will look into that.

CrossGridder commented 2 years ago

I've used make lib to use the modified glfw, thanks! It works with OpenGL 4.6 now. Also, I was having trouble with XCode, it was caused by all the signing values and this (for some of the projects):

I still get this when I try to launch through XCode: Do you have any idea how to fix this?

I was able to overcome this by removing the debug build, following a suggestion from here [](url)

darkaegisagain commented 2 years ago

It looks like make is required, I installed it via brew install make.

I should add that to the external script or just add it in the instructions.

As for the launch error, do you have your system setup for development?

xcode-select --install will install lldb, that should work for all the command line utils.

Mike

"The difference between communism and socialism is that under socialism central planning ends with a gun in your face, whereas under communism central planning begins with a gun in your face." ― Kevin D. Williamson

On Thu, Feb 24, 2022 at 11:04 AM CrossGridder @.***> wrote:

I've used make lib to use the modified glfw, thanks! It works with OpenGL 4.6 now. Also, I was having trouble with XCode, it was caused by all the signing values and this (for some of the projects): [image: image] https://user-images.githubusercontent.com/25316035/151255849-c60ccff9-926e-4a06-8c61-8872a40c613f.png

I still get this when I try to launch through XCode: [image: image] https://user-images.githubusercontent.com/25316035/151256309-5925512c-e306-4f98-99d8-50fd33e78b6a.png [image: image] https://user-images.githubusercontent.com/25316035/151256324-8ab2d1b0-fcae-476e-9a6b-3fc482cda44c.png Do you have any idea how to fix this?

I was able to overcome this by removing the debug build, following a suggestion from here [] https://stackoverflow.com/questions/65813181/xcode-fails-to-create-archive-with-unable-to-spawn-process-usr-bin-make-error (url)

— Reply to this email directly, view it on GitHub https://github.com/openglonmetal/MGL/issues/9#issuecomment-1050167450, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOKD3ZI66VND2QKIUT3KIDU4Z6LNANCNFSM5MQ4K7FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

openglonmetal / MGL

Building without installing #9