gl conflicts with different macs?
Are there any known conflicts with GL objects and different modern Mac systems? I made a patch that works perfectly on a 2013 iMac with an Nvidia GPU. Same patch doesn't work properly on a newer iMac with an AMD card. (same versions of Max)
I haven't been able to inspect the patch on the system in question and it's being used by someone with limited Max experience, so it could be a range of issues. However, I built the patch for click and go functionality and it works fine on all of my systems. The patcher output on the troubled system looks as if everything but GL functionality is intact. Jitter and Max are doing their thing but everything that relies on GL is flatlined.
Possible issues include, Sierra vs El Cap, Nvidia vs AMD, non-ideal patching practices (some unnamed GL and Jitter objects and potentially non-ideal use of jit.gl.texture/slab/pix objects for vbo/feedback functions - again, all fine on my system but...), improperly set system settings , etc.
Thank you for reading this. Any thoughts?
nothing comes to mind, but feel free to send me the patches (offlist if you prefer - robr at cycling), and i'll see if i can suss it out.
My friend working on Quatz Composer told me something similar - maybe it's nothing related to the Jitter itself, rather something on the OS level.
Hey Metamax!
This may or may not inform you some...
**** warning - this is a massive oversimplification and recalled by fuzzy memory only ****
I was speccing a mac rig for a client a while back - he wanted to use Resolume, and the sum of the research around that was:
The Macs that have "iris" graphics cards are not on the same horsepower "plane" as the other graphics cards (whose name I cannot remember)
(3 layers in resolume vs 12 or 15)
The theory being - maybe you are running into one of the differences between those two series of cards
This is a cool page from the Resolume site that has different benchmarks that may help point to what your problem could be...sort by operating system and see if it informs your thinking...
https://docs.google.com/spreadsheets/d/1dffqNTHnPiaC3w-hbMYtJwlgWJZ9e2c5mk9svXfnqiM/edit#gid=1522306833
Having said all that, if you want me to stress-test your patch on several "eras" and OS versions of Macs i will be glad to....
cheers!
jd
I'll probably end up rubber ducking it after I get it cleaned up anyway. If I do, I'll post the fix. Otherwise, I'll send it along. I appreciate the help!
Again, I think it's due to differences in grid vs texture processing. [jit.gl.slab], [jit.gl.pix] and [jit.gl.texture] can be used interchangeably as feedback buffers in many situations, but I also recall reading about low-level differences in different GPUs when performing grid operations. All it takes is one manufacturer to process one kind of thing in a different order.. and blammo. If I actually understood any it, I would have more insight. But I don't.
Any thoughts on a definition of the above objects in terms of one another? iow, what don't they do? ex. both [i] and [f] can be used interchangeably most of the time but misuse can easily bring down a patch. What does [jit.gl.slab] do that the others don't do and vice versa? Hypothetically, how can use of one over another be a problem?
To keep it simple, lets say all of the objects are unnamed and we're only using plain ol' [jit.gl.texture], [jit.gl.slab] with no code and [jit.gl.pix] that passes the input with in = out. When said objects are used as occasional buffers within a chain of [jit.gl.pix] objects (which contain the actual logic), what determines the best object for use as a buffer? I was originally using [jit.matrix @thru 1] as per Rob's suggestion, but it's not clear if @thru keeps the action on the GPU or not.
r², yaniki, jd, thank you again.
Onward and upward!
not sure if related but i can recall having significant performance differences when using poly_mode 1 1 so you just see a grid), and if i do that on Windows it was actually faster... also did you have a look at the jitter benchmark forum thread ? maybe useful info there ?
I was originally using [jit.matrix @thru 1] as per Rob’s suggestion, but it’s not clear if @thru keeps the action on the GPU or not
i hope i never suggested that! using jit.matrix as a buffer for texture processing is not a good idea, as it forces a texture readback (and thus degradation in FPS) for no apparent reason, since you are ostensibly sending the output back to the texture processing chain.
you can use jit.gl.slab/pix/texture interchangeable for a one frame texture buffer.
@vichug Yeah I saw the benchmark thread. Most of my confusion is because I had zero GL experience prior to Gen, so I don't really have any sense of what is happening under the hood. But I think it's close to what you're describing.
@Rob That makes sense. I'm glad I had the wherewithal to ignore my own misunderstanding. I think it started here: https://cycling74.com/forums/dfdx-dfdy/ when I was trying to port a shader into Max that was using dfdx and dfdy operators. I wasn't clear about context. That's why I use brackets now around all patcher objects when referencing them with text - especially Gen objects.
re: frame textures.. that's what I thought. I'll keep looking. I assume that an output buffer with the same name as the input buffer is equivalent to using said buffers with no names but in correct tdrl patching order.. That's the other possible issue.
I'll figure it out. Thanks guys.