ROCm 4.0 broke DaVinci Resolve 16 and 17

With ROCm 4.0 DaVinci Resolve 17 crashes on importing media.
With ROCm 4.0 DaVinci Resolve 16 doesn't render viewers in the Media, Cut, Edit and Render pane.
Here's to another broken ROCm release, a major one this time!

I had a hunch ROCm 4.0 would be broken for DaVinci Resolve (surprise, surprise), and decided to search here before trying.
@KristijanZic You just saved me the effort.  Thanks!

Thanks @KristijanZic for reaching out.
Can you please help us with more information like GPUs, OSes, kernel info etc.
Thank you.

@ROCmSupport in case it helps, I am running:

GPU = Vega 64
OS = Ubuntu 18.04
Kernel = 5.4.0-58-lowlatency

And I am happy to provide any additional hardware info you need, as long as I haven't already covered it here:

https://github.com/RadeonOpenCompute/ROCm/issues/768

Which is a thread I started 18 months ago, where I am still waiting for someone from AMD to help.  Every version of ROCm since then has not worked.
I (and others) am still on ROCm 3.3, because of AMD's poor support so far.  Sorry to be cynical, but please don't comment unless you plan on actually fixing the driver.  As mentioned, I am happy to help as much as I can.

Thanks @beatboxa for additional information.
I will check with our QA team and will get the latest result on 4.0.
Thank you.

Why wasn't this tested before ROCm 4.0 was released? Like really, doesn't AMD have their own versions of their own graphics cards to test against? DaVinci Resolve also costs $0 to test for things like this...

I will check with our QA team and will get the latest result on 4.0.

So, it's been over a month, how's the check going so far?!

I will check with our QA team and will get the latest result on 4.0.

So, it's been over a month, how's the check going so far?!

Sorry for the delay @KristijanZic
Can you please help me with the exact steps to reproduce the problem so that I will try to reproduce on my own.
Share me below things to proceed please.

Download location
Launching application from remote location like PUTTY, mobaxterm(keeping that test machine connected to a monitor for X-server display)
Share me all steps for launching GUI application from PUTTY and steps to reproduce the problem so that I will regress it further and move to a component owner asap.

Thanks for helping me with all steps.

@ROCmSupport Sorry, but this cannot be a serious response from you.
Want to reproduce the issue?  Here's how:

Install ROCm (including OpenCL)
Install DaVinci Resolve
Try to use DaVinci Resolve

You don't need to remote in via PUTTY.  Run it local.  DaVinci Resolve is not a command-line application.  It is a GUI application, and we are talking about the Graphics driver for it.
Please tell me you actually understand this; and if not, please assign a support engineer who understands how the general public uses video-editing applications in 2021.

Hi @beatboxa
I am already aware that its a GUI app. Its very basic info and I know this.
As we are working remotely from home due to pandemic situation and I can not access the machine directly, I wish to access the test machine(which is in our lab) remotely and wish to launch GUI screen from remote terminal like PUTTY/Mobaxterm. Thats why I asked you guys to understand the process to launch GUI of the application to proceed further.
Hope you got my point.
Thank you.

Go to https://www.blackmagicdesign.com/products/davinciresolve/ and download
DaVinci_Resolve_17.0b7_Linux.zip. You can provide any email / phone you like, it does not need verification.
After that scp DaVinci_Resolve_17.0b7_Linux.zip to your Linux machine. And then unzip it  in putty and run the DaVinci_Resolve_17.0b7_Linux.run file in putty (With Mobaxterm server running). You can see the installation dialog and you can proceed to install.
After successful installation, you can run "/opt/resolve/bin/resolve" to launch it.

I'd also like to add that some of us use the deb converter for the install package so that our package manager is aware of the application (this is how I do it). So might want to try both at some point.

Hi @helloworld1,
Thanks. I followed the same steps but my installation is always failing with both root and non-root users.
I have display connected with my test machine and other applications like Luxmark are running well.
root@taccuser-X399-DESIGNARE-EX:/home/taccuser/Downloads# ./DaVinci_Resolve_17.0b7_Linux.run
MobaXterm X11 proxy: Unsupported authorisation protocol
QXcbConnection: Could not connect to display localhost:10.0
/tmp/.mount_DaVincwSK5Dh/AppRun: line 10:  5510 Aborted

Understandable problems to encounter trying to debug this remotely, I somewhat sympathise.
I see there being two problems.
VNC/X-forwarding isn't enough on its own
Normally I would suggest simply running via sudo in a VNC session with your window manager running, rather than root directly as you have presented us. Root cannot export windows to a user VNC session without an authentication.
However, I also know this will not be enough to run the application once installed anyway.
Whilst VirtualGL might work if you also have the OpenCL interposer working too, along with the ROCm modules, but we cannot guarantee that will work.
Simplest method is going to be to leverage a real X11 display with OpenCL+GL support for the application to also have a chance of running after installation.
X forwarding will also likely not work unless you are actively logged in on display :0 - I believe, I might be wrong.
Mirroring an existing physical screen via VNC server
The solution I propose may not be in line with AMD internal security policy, but I suggest you use x11vnc to mirror display :0 as if it were another VNC session.
This is also unencrypted by default but I believe this can be enabled if you are not using a VPN for some reason - Which I highly doubt.
Since it's technically not as secure if there's an attached display that isn't off and some bad-actor happening to be in the same room...
We cannot force you to do this, but I am assuming like us over at arm you are holed up at home and security are on the premises/monitoring.
Make sure you remember to lock the screen/have an inactivity timeout lock policy on your window manager, then you are as good to go and covered as anyone can reasonably expect.
Setting up the VNC mirror
Now, hopefully with legalities and risk mitigation out of the way:

I am assuming the lab machine is in runlevel 5
With a session manager running and alive

If not, ensure the machine is in runlevel 5 and check the Xorg log first for signs of death before proceeding.

If you have any firewall running by default: Allocate a small port range to open up temporarily using the distributions' admin tools/command line as appropriate.
Launch an VNC server to mirror display :0 using an open port with x11vnc - This is the magic to allow you to use display :0 as if you were physically there: https://wiki.archlinux.org/index.php/x11vnc
Connect with your VNC viewer of choice to the port you allocated and authentication set up.

Kill the VNC server and close the ports once you are finished.

Example command call:
x11vnc \   -display :0 \   -usepw \   -forever \   -o ~/x11vnc_x0.log
The "-forever" switch disables exiting of the VNC server after the user disconnects, as I assume you will need to connect many times.
This argument "-usepw" will inherit the current users' ~/.vnc/passwd password.
If you want to set a temporary launch-time password I would suggest creating a separate authentication file:
`vncpasswd ~/.vnc/vncx0passwd"
And specify with "-auth ~/.vnc/vncx0passwd "
To kill the server once you are done, I believe, it is just like any other VNC server.
Failing that sending the middle finger with "kill -9 PID" will achieve the same goal, just more rudely.
Drop a reply if you need some specific guidance on this.
There are other potential options but I believe they would also require X :0 sessions for them to work anyway - i.e. parsec (https://parsec.app/downloads/) Which might be easier and better for latency but I have never used it myself to know and would require a commercial license prior to use in this case.
Regards,
Jim Shorter

@ROCmSupport Have you had opportunity to try launching an X :0 mirror?
@KristijanZic @beatboxa @BloodyIron -
I do not wish to confuse any existing issues on this thread, but out of interest what media formats/containers are you guys importing? (And thanks in advance)
Possible I have functionally reproduced this but I'm not sure if this is for the same reason, I am not a long-time users of DaVinci Resolve but have been a Linux user for ~18 years and can see you guys have done a very reasonable job of reporting specifics here.
Unfortunately, the existing log file dump links seem to have now expired on the other threads.
From my own recent experiments, I now have:

rocm-3.3.0 - Installed with package manager, freshly, with partial package selection.
amdgpu-pro-20.30 - Extracted RPMs from the source bundle without rocm-dkms, using a similar workaround as documented on ArchWiki except it requires a further trick to enforce only a singular OpenCL provider to be picked up correctly thanks to running strace + dbarbi1's post.
DaVinci Resolve 17b8

Side note: Now, specifically, DaVinci Resolve 17 Beta 8 finally allowed me to actually open DaVinci Resolve without crashing which wasn't the case for earlier versions of 17 and most of 16 for me personally. The only other version that even opened without failure and seemingly without the work-arounds was 16.2.8.
I'm certain this is still truly broken for everyone but for completeness to others, in my case it seems to be "Unsupported codecs" on the free-version for Linux (i.e. H264, H265, Xvid nor MP3, AAC...) -- Which is not documented officially anywhere by the vendor, only by experienced folk on their forums giving support.
Most of these threads are about 2 years old.
The upshot is in my case it is similarly leaving the video preview completely grey (not black as if it has a decoder instance).
I noticed the debug log fills up if you try and scrub any clips, the log file in question which will be spammed if this is the case for you is:
~/.local/share/DaVinciResolve/logs/ResolveDebug.txt
Common workaround suggested on their forums state to use/transcode to ProRes + PCM as a combination that at least functions.
Also an editor on YouTube using Linux with a full Studio version license states that version does support these codecs it out-of-box.I can confirm using these supported codecs (as they put it) do indeed work and the other features too.
However, this is pretty impractical for common use unless you already plan to convert-upon-ingest automatically which does not seem worth it. It also does not solve stability in my case as the application will randomly lock-up.
Not to mention, most GPU accelerated encoded recordings, OBS or rather any modern consumer video device will not be immediately importable and waste your time with transcoding settings+disc space+power...
I have not had chance to validate this running on a secondary clean Linux install with what BMD officially supports.
So forgive me if this is entirely wrong, as I am working around driver clashes myself here since theres no 32bit libraries for Steam with AMDGPU-Pro anymore as-provided sigh.
If this is the case for you as well, I can only assume this if this partly due to the issues of license and provision of media libraries...
As even installing VLC these days (on OpenSuSE at least) requires the right decoding libraries for common formats making it needlessly painful updating/keeping stable, and that was not seemingly an issue as I remember in the recent past.
Relevant system specs + OS + launch workaround:
OpenSuSE Leap 15.2
Kernel: 5.3.18-lp152.60-preempt
LD_LIBRARY_PATH="$LIBRARYROOT/opt/amdgpu-pro/lib64:/opt/resolve/libs/:/usr/lib64" LIBGL_DRIVERS_PATH="$LIBRARYROOT/usr/lib64/dri/" dri_driver="amdgpu" /opt/resolve/bin/resolve

Where $LIBRARYROOT is the base extraction path of all the RPMs from amdgpu-pro 20.30.
/etc/OpenCL/vendors/amdocl-orca64.icd is the only OpenCL provider ICD and is soft linked to $LIBRARYROOT/etc/OpenCL/vendors/amdocl-orca64.icd

AMD Ryzen 9 3900X
AMD Radeon R9 285 - I know, ancient...
Kind regards,
Jim Shorter

@jfshorter Thanks for your update on davinci resolve studio 17 beta 8. It DID open and works but only on Rocm 3.3.0. The initial previewing of the video is extremely slow but afterwards, it seems to work normally.

Thanks @helloworld1 , @KristijanZic and @jfshorter for your help.
Now I am able to install DavinciResolve 17b version successfully.
But when I launch the application, for the first time, from /opt/resolve/bin/resolve, it shows white window, holds for a long time. So ended the application forcefully.
But I am able to launch the application from second time onwards.
My config is: Vega10 + ROCm 4.0 + Ubuntu 20.04.
Please let me know the exact steps to reproduce the problem.
Thank you.

@jfshorter The only format I use (import/export) in DaVinci Resolve is DNxHR.
If & when I want to work with other formats, I first convert them to DNxHR prior to importing; or from DNxHR after exporting from DaVinci Resolve.  I will check the new 17 beta 8 version.
@ROCmSupport does the application work (eg. preview videos), or just install/launch?

@helloworld1 No problems!
@beatboxa I see, understood! Sure I'll give this a try with an existing clip and let you know if it functions or not when I get chance.
And, no problems at all! It's a constantly evolving bit of software and I just happened to get lucky like previous times you guys have had.
If you are on an older version of Linux and get any dependency issues, feel free to message me. There's always ways around these things.
Also BMD are seemingly always open to feedback, perhaps there's an acceptable middle ground if it does turn out to "just" be codec support more than anything else that's actually broken...
Seeing as they support IOPlugins for export I think it's a possibility if the interface API is presented :)
@ROCmSupport Great, I am glad that has helped you to work around working on GUI-based issues!
I think, the blank welcome/"induction loader" is usually because it cannot find a suitable OpenGL renderer on first launch.
This is how the user initially configures things like the GPU to use (if more than one option is available) and other user preferences.
Thankfully this is unimportant as you can change the GPU settings from a fresh launch.
Setting up the tool
Unforuntately, to get the main window, you have to create a dummy project to load the full-screen video editor window:

Click "New project" at the bottom right
Give it a name, e.g. "Test"

To get to the preferences:

In the top left you should be able to click the main menu named "DaVinci Resolve" (Not File) -> "Preferences".
In the new window, you can then select the "Memory and GPU" preferences on the left hand side.

This should ideally list the card and default to an OpenCL provider in the settings if it has detected automatically, which it sounds like it will already have done this for you.
The most important setting you need to configure is under "Media Storage" on the left:

Add a directory to the list
Likely, best to also uncheck Direct I/O tickbox

... The first entry is where all the preached previews of the videos the user adds/imports to the tool will be written to.
Reproducing the issue
Now, to reproduce the issue, you will need:

Access to any short test video file you can get hold of that you have rights to.
My suggestion would be picking one short video and encoding it to a variety of
formats and containers to regress test this against

For now, you can at least test by use something like this to convert a single clip to a few formats: Apple ProRes, H264 and MPEG4 to validate if the preview works:
ffmpeg -i $INPUT_FILE -c:v prores -c:a pcm_s24le ${INPUT_FILE##*.}.mov
ffmpeg -i $INPUT_FILE -c:v mpeg4 -c:a mp3 ${INPUT_FILE##*.}.mp4
ffmpeg -i $INPUT_FILE -c:v h264 -c:a aac ${INPUT_FILE##*.}.mkv
Assuming your default shell is BASH and where INPUT_FILE=abc.ext is your test video.
These will absolutely need some tweaking to make valid/work and a sensible choice of encoder rate to keep the files small enough. Happy for anyone else tagged here to correct these with something more helpful.
Next, you can then begin testing whether the preview works

Click on the "Media" view (The very first icon from the left at the bottom)
You should get a grey box on the left and a media player to the right.
Drag the file in to the grey panel on the left.
Next, once the preview is generated you should have a preview icon on the left for the file and be able to play back the video on the right.

Did they all preview correctly for you?
Or did the application offer no preview or crash out?
As a side note for development testing:

The good thing is this piece of software has a Python API which I believe you can leverage quite nicely to help automate generating test projects and save the initial configuration pains. Might even be able to automate a basic UI interaction and check the debug log + video area is not grey or black to detect this failure.
I would also recommend a more extensive list of codecs, especially if you wanted to support the professional licensed software, including: VP9, AV1, Xvid, H265 et al.
I do not think audio would be impacted by any of the AMD GPU driver stack, although possible with OpenCL I highly doubt any plugins make sense to leverage it but I could be wrong.

@jfshorter the issue I have is not related to codecs, as I've already solved that aspect for me over a year ago. It is something worth keeping in mind, indeed, but I've already created a transcoding VM that converts my source material into content I can ingest into DaVinci Resolve with the free edition just fine. I can't remember the container/codec configuration I went with, but I believe the audio was PCM.
The issue I've been having is that the ROCm project itself has been a joke of a tool to get OpenCL acceleration from my GPU into my environment without having to compromise elsewhere. The industry I'm making content for is for the gaming industry, and so I need the ability to not lose performance on the gaming side just so I can get OpenCL/other acceleration. I have found the AMDGPU + ROCm to be the best configuration thus-far.
But the reason the project is a joke, is because the most stable version for me to run is ROCm v3.3, and we're now talking about v4.0. I have had to roll back ROCm versions multiple times, and I don't even see v4.0 being available, let alone a good idea to actually install and use.
Also, I'm on DaVinci Resolve <IP_ADDRESS>, and my GPU is an RX 580.
I don't yet have a need to upgrade to a newer version of Resolve, and it sounds like there's hiccups on that path too.
It sounds like @ROCmSupport are more active than they have in the past, and I really hope that turns this project around. I for one CHOOSE AMD because of their open source drivers (AMDGPU & ROCm), and I would prefer to stay in that ecosystem, but they really need to get this act together to keep me here.
As of today, last I checked, my OpenCL acceleration works, but in the future I want to get a 6800 XT (when the market isn't hundreds of dollars above MSRP), and right now I'm not sure if my configuration would actually work with that GPU for OpenCL. And that's a bigger problem for me. I don't want to buy a top of the line GPU and discover that I have to choose between gaming performance (AMDGPU) or OpenCL ability (AMDGPU-PRO), as that really defeats the point.
So, I also want to ask the question, why on earth have we had so many "releases" of ROCm since 3.3 that have clearly been broken and not corrected since? I would say this contributes to the original topic of this thread, ROCm v4.0 breaking DaVinci Resolve (16 & 17).

@BloodyIron Indeed, ahh I see! Yeah, fair enough I rather suspected there were deeper problems than just video formats in all cases but could not prove this quickly myself yesterday.
Means this failure is likely to be a bit ambiguous without the Resolve debug log and at least a stack trace/debug build of the driver stack to inspect at point of failure.
May also require that AMD interface with BMD to figure out root causes, as I am not convinced that we alone will be able to provide the necessary data.
Thanks for also sharing your experience with ROCm and link to your transcoding setup/approach!
This is the first time I have used it so cannot offer my perspective on the instability.
However I have had similar issues with other libraries in the past and this sounds just as disappointing, major rearchitecting is never easy and often causes a lot of headaches downstream.
[@ROCmSupport - I can imagine this was equally a challenge for the developers and may not have been anticipated, hopefully lessons can be learnt and communication can improve to allow dependent software to align and provide the stability we all want. ]
Seeing it from AMDs perspective it could be hard to directly attribute the value to debugging/supporting this amongst their own priorities, as some of us are not running officially supported configurations however I think you (and I am sure many others) are running absolutely a supported combination.
Completely agree with your position with hardware and software support in general too, although I am just an enthusiast and not dependent upon this as a professional.
We all have the burden of a choice to make, between simply using status quo as it is supported or what we actually want/prefer to use to help stimulate competition. This is only something we can answer for ourselves:

Which problems you want or can live/deal with
How much has it cost you/value you place on it?

[Also as you can probably tell I am in a similar position with my ageing GPU, prices are pretty astronomical this side of the end too. :)]
Kind regards,
Jim Shorter

For me, I'm not yet a professional in this regard, but I'm working up to my setup being used for professional endeavours in the future. Hence trying to get these issues ironed out.
Honestly, the drivers should provide an OpenCL and other API interfacing in such a way that you shouldn't have to care whether an application is compatible or not. That's the whole point of standard APIs like that. The application supports it, or it doesn't. Clearly that hasn't been the case with AMD ROCm stuff just yet.
While I agree there are certain configurations that are obscure and hard to support, the many configurations we see in issues on this github repo are plenty common enough that the kind of issues we've been seeing for 1-2+ years now, should not exist. There's enough people with issues with OpenCL (AMDGPU + ROCm) with Resolve over the last 1-2+ years, that it's demonstrateably not about obscure configurations, but a lack of quality control within the ROCm release pipeline, CI/CD and other testing.
I don't know if they have a proper DevOps pipeline, but I sure hope they do, because this aspect of AMD software horribly needs proper testing automation and other software release automation. (ask me how I know, literally in this industry right now)

To add to BloodyIron's point:  ROCm 4.0 is not the first time things broke.  We've seen several major re-architectures that regressed functionality and broke things.  See my thread here:
https://github.com/RadeonOpenCompute/ROCm/issues/768
I started that thread 2 years ago with ROCm 2.2.  Because ROCm 2.3 broke compatibility.
This compatibility wasn't fixed again until ROCm 3.3.  But then, literally the next version (ROCm 3.5) broke things again.  There was no real 3.4.
We are now in 2021, on ROCm 4.0, where things are still broken.
Let's visualize this a bit, since 2.2.  Here is a list of all of the ROCm versions released, and I've put in bold the versions that work.  As a note:  many of these require "fresh & clean installations" and don't support upgrades, including, the latest 4.0.1.
2.2
2.3
2.4
2.5
2.6
2.7
2.7.2
2.8
2.9
2.10
3.0
3.1
3.2
3.3
3.5
3.5.1
3.7
3.8
3.9
3.10
4.0
4.0.1 (not sure about if this works or not)
So fewer thank 10% of versions from the past few years have worked.  These don't even have to be professional applications--this is poor even for consumer support.

I'm starting to think that nVidia is the better way to go :/

Thanks @jfshorter for your suggestions on reproducing the problem.
While I launch videos from test machine, its showing blank black screen and so I am not able to troubleshoot the problem.
Working on fixing the issue now.

Hi All,
As per the latest information and clarity provided in our Documentation that ROCm does not support GUI applications officially.
Docs also updated accordingly @ https://github.com/RadeonOpenCompute/ROCm#hardware-and-software-support
Hardware and Software Support
ROCm is focused on using AMD GPUs to accelerate computational tasks such as machine learning, engineering workloads, and scientific computing. In order to focus our development efforts on these domains of interest, ROCm supports a targeted set of hardware configurations which are detailed further in this section.
Note: The AMD ROCm™ open software platform is a compute stack for headless system deployments. GUI-based software applications are currently not supported.

Jesus Christ, you f***ed us all so hard it's not even funny.

"Working on fixing the issue" >> "We have updated the documentation to say we won't support graphical interfaces with our graphics card."
@ROCmSupport are you confirming that you've verified that DaVinci resolve + ROCm 4.0 works in headless mode (using the --nogui launch option)?
It sounds to me like this also means that it won't support graphical machine learning uses, like Machine Vision, like facial or object recognition, or OCR + NLP.  And it also sounds like it won't support interactive geospatial uses, like 5G tower rollout planning.
In essence, what this is saying is:  "AMD ROCm is very limited.  If you want proper full-breadth machine learning support (as well as graphical application support), use a system that works.  The industry standard system that works is":
https://developer.nvidia.com/cuda-zone

Well guess I'm buying nVidia now.

Apologies, this should not have been closed. We use the ROCm platform components in our graphics driver stacks as well and they absolutely are expected to support GUI apps there.
We are trying to do a better job of documenting the current situation, which is that the ROCm stack on its own does not include userspace graphics components (eg Mesa) and so will not support GUI apps. This is not a change of direction (ROCm stack releases have never included userspace graphics) just an attempt to prevent customers installing the ROCm stack on its own and running into problems.
We are working on revising the message to make it a bit more clear.

@johnbridgman that kind of clarification seems reasonable, but quite frankly, I've been waiting for ROCm to be usable and ugpradable for most of the last year. I'm still stuck on v3.3 because it's the only working version that works with DaVinci Resolve.

CLEARLY explain that AMD officially supports ROCm and is COMMITTED to MAKING THIS RIGHT.
Ensure that ROCm works agnostic of what distro is used. Having to worry about RHEL/CentOS/Debian/Ubuntu/etc support is UNACCEPTABLE in the way that we have seen it thus-far.
Convince me to buy an AMD GPU, because what we saw today and phoronix confirming it has turned me so much off buying AMD GPUs that I started deciding what nVidia GPU I'm going to buy.

Look, from this post @johnbridgman it sounds like AMD goofed and wants to make this right. To make this right, AMD needs to PUBLICLY (also to Phoronix) clarify on all this. If AMD wants OpenCL to work FULLY on their consumer GPUs for workstations and other professionals, THAT NEEDS TO BE SAID EXPLICITLY AND PUBLICLY.
Please John, show us the AMD that we love, that helped made the AMDGPU driver a reality. Give us ROCm in a stable, awesome suite. I know it takes time, and we've been very patient, but we NEED far more communication from AMD than we have seen in the last 1-2 years on the whole situation with ROCm.
To put it another way, I WANT to buy a 6800 XT, but not if ROCm is anything like what we saw within the last 24 hours, and within the last 1-2yrs. I'm not going to drop that kind of money if the card being a workstation GPU for me, turns into a massive uncertainty as to whether I can do work with it on Linux. Because if that uncertainty exists, I'm buying nVidia.

One thing I should mention is that the commitment to support workstation apps on ROCm compute is fairly recent, and that before that the PAL-based OpenCL implementation we were shipping with AMDGPU-PRO was the primary solution for applications like Resolve and Blender. We are now at the point where ROCm-based OpenCL is a good alternative to the previous PAL-based solution, and have made it the default on Linux for Vega, Navi and onwards.
The work we did for ROCm OpenCL in AMDGPU-PRO has not yet made it into a regular ROCm release but it should get there soon - at that point you should see the same improvement in the ROCm releases with one caveat.
The caveat concerns GL/CL interop - as far as I know the testing focus for GL/CL interop has been against the workstation GL driver in AMDGPU-PRO rather than the upstream Mesa GL driver (radeonSI). I don't know the exact state of GL/CL interop at the moment but will make sure we find out and get that documented publicly.
The reason I'm saying all this is that in the short term you might still get directed to the AMDGPU-PRO driver packages (with ROCm-based OpenCL plus workstation OpenGL) since that is what has been tested and fixed with applications using GL/CL interop.

Hey @johnbridgman That helps clarify a lot of stuff, but there's still some areas that I think need clarifying on. Namely, we need an improved commitment and communication from AMD going forward. It sounds a hell of a lot like you're trying to correct that, at least at this time, and we need that consistently improved. What is AMD prepared to do on this aspect?
I myself am on an RX 580, using AMDGPU + ROCm for DaVinci Resolve. I am on the AMDGPU driver because I make gaming related content, so I need to have high gaming performance (AMDGPU vs -Pro) and OpenCL offload. As I mentioned earlier, I'm very seriously considering a 6800(+/- XT) so I can have my gaming and eat my OpenCL too. This is more the direction I personally am interested in, and I think there's a lot of people around here who are interested in similar things. (+/- the gaming aspect).
So, while what you're saying here clarifies a lot on the history and current state of things, it sounds like AMDGPU + ROCm for my scenario (and others) is what AMD is working towards. But is it? And what about the other aspects I raised concerns about? (such as distros, etc).
Your improved communications and responses here is VERY MUCH appreciated! Thanks! :)

Thank you for the clarification @johnbridgman   This is the most useful bit of clarification I have seen in years (quite literally, I'm afraid).  In case it's useful as you think through the strategy, architecture, interoperability, etc.: here is the original thread on this topic, that sort of runs through specific package & driver versions, since ROCm 2.2 (and where things broke):
https://github.com/RadeonOpenCompute/ROCm/issues/768
It would be brilliant if your team can think through the smoothest & clearest transition points or selection strategies between the various drivers, since many of these uses cross between them; and these get into some grey areas anyway.
For example, in my professional life, I work in the field of data science, machine learning, & AI (including GPU accelerated).  By nature of my role, I'm not hands on; but I do dabble sometimes to keep up with the technologies, since I often have to decide how we partner and sell commercially.  But in my personal use, I do everything from fairly heavy video & graphics editing to occasional gaming.  And I'd like to be able to use the same system for all of these use cases, even if it requires a quick "settings change" when I switch use cases.  Obviously, this is much more complicated than it seems; but this is also the reality of expectations that a lot of consumers have, since at least 1 competitor appears to offer something more along these lines; and since this is how good architectures work.  Just a thought.

@BloodyIron
AMD had drop offical support for gfx803. I guess it may be the reason.
I own a RX580 and try to fix the issues by myself, but it is not an easy mission. I can just reproduce the issue using a very simple example. https://github.com/ROCmSoftwarePlatform/Tensile/issues/1287 . Hope someone could give me some clue.

Thanks @jfshorter for your suggestions on reproducing the problem.
While I launch videos from test machine, its showing blank black screen and so I am not able to troubleshoot the problem.
Working on fixing the issue now.

Well you fixed it alright..
What's with the fix?

Apologies, this should not have been closed.

I guess that doesn't really mean anything if you don't actually reopen the issue...

I guess that doesn't really mean anything if you don't actually reopen the issue...

Agreed, but IMO it would be even worse if I re-opened the issue and someone else closed it again. Want to get everyone aligned first.

Agreed, but IMO it would be even worse if I re-opened the issue and someone else closed it again. Want to get everyone aligned first.

Touché.

How did the internal alignment go? Should we be worried again?

It's making progress, although going slowly because everyone now understands that these are shared components and so the simple "we don't support GUI apps" statement is not workable. Now we're getting into more complicated questions like whether the ROCm stack is "the datacenter stack" or "the upstream for our shared compute components" or both.
Saying that the datacenter stack does not support GUI apps is perfectly reasonable, but obviously saying that our shared compute components (also used in workstation / consumer / embedded) is not. I suspect the real solution is going to be separating out "datacenter stack releases" from "upstream for shared compute components". That will take a while, but in the meantime AFAIK we have agreement to re-open the closed tickets.

Not supporting GUI for datacenter, I can get that. I'm glad this distinction is being more realised, and that the ROCm stack messaging is being corrected to seemingly clearly show that GUI is supported for workstation/consumer/embedded.
When you say that the solution is conceptually separating, do you more mean, developer efforts, or are we talking about a forking of code and having a ROCm version for datacenter and a version for everything else?
This sounds like great development! @johnbridgman how do you see this work-in-progress shift impacting the reliability of the ROCm stack in the foreseeable future? Do you think this will have a positive impact in this regard? Or?

I see the changes as being more semantic and symbolic than anything else - we have some teams that focus on datacenter and we don't want to stick them with issues related to graphical apps that they never use, but fixing that is more a matter of getting the tickets to the right people than anything else. Might mean we add more problem reporting buckets, for example.
I don't see anything like forking of code being required other than the usual per-release branching we have already. The biggest change I would like to see is making the "AMDGPU-PRO OpenCL package" a separate source release and not tying it as strongly to the workstation graphics components. It's not quite that simple, of course, since GL/CL interop with Mesa is a bit different from GL/CL interop with our workstation GL driver, but that is all manageable with time. Same with HIP and libraries once we get caught up on RDNA support.

@johnbridgman That's really good info, but you appear to be skirting my inquiry about stability. So perhaps a rephrase of my question might help us both.
The changes that are being described here, semantic, symbolic, as well as helping improve the flow of where tickets/issues go to (the right people, with higher accuracy rates of who the "right people" are). Do you see that addressing the issues that, for example, we have seen with the DaVinci Resolve issues between v3.3 and v4.0, as in all the versions in between. Those issues, do you see them being addressed naturally with these changes you're describing? Or is there another way you see that being addressed with future versions?

Sorry, I thought that was implicit in my answer. I don't expect any of the changes to have any impact on stability except to the extent that clarification of uses and issue communication might help make investigation of problems and ongoing tweaking of QA test plans a bit more efficient. Not promising any of that right now though, top priority is getting back to things being no worse than they were a week ago.
If we can take advantage of the discussion and attention to improve things at the same time we will, of course.

@johnbridgman thanks for the clarification! I really like the direction this is headed. Thanks for your help with this and thanks to your team working to turn this whole situation around! I really hope ROCm can get ROCm' solid! haha XD

@johnbridgman I just want to point out that if DaVinci Resolve is not one of the apps you include in your workstation QA test plans, then AMD may want to avoid marketing its products as such:
https://www.amd.com/system/files/documents/davinci-resolve-solution-brief-radeon-pro-vii.pdf
While I appreciate the honest & candid response, AMD's financial situation and lack of support through now (which, btw, I'll point out was so poor that some of us identified that a lack of AMD's investment must be the issue) is not really a consumer's problem.  Nor is AMD's fragmented teams.  These are internal AMD problems, not problems that consumers should be burdened with.  I don't mean to be rude; but frankly, as a consumer, I don't really care why.  I just want what I bought to work; and if this is the pattern and current capability, then I will buy competitive products next time.  It's as simple as that.
In fact, I'll just point out for everyone that problems such as unclear organization, understaffing, and de-prioritization are typically fundamental, longer-term problems that make it even less likely that we'll see a fix than if a bug was identified and being actively worked on (as we were previously being told in these threads, which has now changed).
My knee-jerk reaction to comments like that are:  If AMD is saying they are disorganized & understaffed; and that they will prioritize corporate requirements (even though they explicitly advertise the functionality I want with their products); and that they will reverse course to no longer work on these issues (but will make it clearer why they won't work on these issues), then typical consumers are not a fit for AMD's products for these types of use cases.  And AMD's marketing & messaging doesn't appear aligned to reality, and could even be considered misleading.  I know it's not your fault as a support team for ROCm--this spans across teams.
But this doesn't give me confidence that this will get resolved, and actually has the opposite effect.  Because the bottom line is that statements along the lines of: "it's not supported" and "It should be supported, but I'll make it clearer why it won't get fixed by this team" have the same net result.  And that result is failure.

Hah - I hadn't seen that, thanks. Guessing it is referring to Windows (which has a lot more QA coverage) but will find out. It may turn out that this is a Linux-only issue, which should make it easier to address.
I don't really understand the rest of your post - my comment about resource constraints was in the past tense and I explicitly mentioned our financial position improving and being able to hire more people. Is there something in my wording I missed ?

In this case, Resolve uses OpenCL, at least so far as I am aware for AMD acceleration. (my case?)

Thanks... I was thinking more about display APIs though. Until the 20.45 release the OpenCL code was common between Linux and Windows, so if it was running well on Windows but failing most of the time on Linux that suggested a display- or interop-related issue rather than compute-related at first glance.

Without being a subject matter expert in the finer points of how my DE/GUI are rendered, I am sceptical it is OpenGL for the non-OpenCL components. I'm on Ubuntu 20.04, RX 580, Gnome.

I don't know either - all I can say is that based on a bunch of years dealing with issues like this it seems unlikely that OpenCL problems on their own would cause the symptoms I'm seeing reported against Linux when Windows & Linux have been using pretty much the same code, at least in the AMDGPU-PRO drivers. That is only triage-level analysis though.
The ROCm stack is a bit of a different case because we only started using ROCm code paths in the workstation driver in the 20.45 AMDGPU-PRO release, so that is the first time that workstation/consumer QA would have been testing them. We did a lot of testing and fixing on GUI apps (including fixing a bunch of Blender issues) but I don't think we got as far as Resolve yet.
I need to mention again that the work we did as part of 20.45 testing fixing probably has not yet appeared in ROCm releases.

There are several threads on this topic elsewhere.  They may have useful information.
For example, there's a whole thread on Blackmagic's (Davinci Resolve's) forums about this topic:
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=56878&hilit=amdgpu+pro&start=1850#p722813
Including one from Blackmagic's own engineer:
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=56878&hilit=amdgpu+pro&start=1850#p727400
(And there's also apparently a thread going on at phoronix, in the comments of an article):
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=56878&hilit=amdgpu+pro&start=1850#p730896
(And here is the comments section referred to):
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1240178-the-state-of-rocm-for-hpc-in-early-2021-with-cuda-porting-via-hip-rewriting-with-openmp/page2

Just adding that I was able to get DaVinci Resolve 17.1 working, with ROCm 3.3.
(The initial previews from 16.x was very slow for me as well, as I'm guessing Resolve had to rebuild its database, and likely regenerated caches).
I'll also point out that this was a hassle. Because I only upgrade to 17.1 after my 16.x installation stopped launching.  After much debugging, I found that I had updated my linux kernel recently.
Every single time you upgrade the linux kernel, you must uninstall rocm-dkms3.3 (and all associated packages); and then upgrade your system kernel; and finally reinstall rocm-dkms3.3.  Because as the rocm manual points out, it does not support operating system upgrades and must be completely wiped and reinstalled every time you update your system.

Beatbox, would you do me a favor please? Could you go to the Fairlight tab and check to see if waveforms are displayed for each audio channel? AMDGPU-Pro and whatever ROCm version they use for that has this bug where they are not displayed, making it almost impossible to do a proper audio mix down, and it's driving me nuts.

@paranoidfactoid might be the various levels.  Try vertically zooming out.  At first, mine didn't show up; but then I deleted my cache (just in case) and also zoomed out vertically--this got the waveforms showing on Fairlight.

Just adding that I was able to get DaVinci Resolve 17.1 working, with ROCm 3.3.
(The initial previews after upgrading from 16.x was very slow for me as well, as I'm guessing Resolve had to rebuild its database, and likely regenerated caches).
I'll also point out that this was a hassle. Because I only upgraded to 17.1 after my 16.x installation stopped launching and began hanging indefinitely on launch. I later finally found that my clinfo was hanging. And after much further debugging, I found that this was because I had updated my linux kernel recently.
So a friendly reminder: Every single time you upgrade the linux kernel, you must uninstall rocm-dkms3.3 (and all associated packages); and then upgrade your system kernel; and finally reinstall rocm-dkms3.3.
Because as the rocm manual points out, it does not support operating system upgrades and must be completely wiped and reinstalled every time you update your system. So rocm3.3 will eventually break relatively often enough, even if we stay on 3.3, as long as we keep up with system kernel updates.

Are you using upstream mesa OpenGL or AMDGPU-PRO's OpenGL?

@ROCmSupport any progress on this?

Hi @clapbr
We are taking time to unify ROCm with graphics support.
We already started working to deliver this solution.
We hope this solution solves all of graphical issues with ROCm stack.
Please stay tuned for updates.
Thank you.

@ROCmSupport what is the ETA for that work?
Proper ROCm support is very much needed now (like yesterday) since AMDGPU-PRO 21.20 is broken again and DaVinci Resolve is not launching, Blender is not rendering, Darktable crashes etc. Nothing works on 21.20. We need a proper driver.

Hi @KristijanZic
I don't have exact timelines right now, but tentatively before end of 2021.
I will surely share some information, once I receive, if any.
Thank you.

Proper ROCm support is very much needed now (like yesterday) since AMDGPU-PRO 21.20 is broken again and DaVinci Resolve is not launching, Blender is not rendering, Darktable crashes etc. Nothing works on 21.20. We need a proper driver.

Can you remind me which GPU and DaVinci version you are using ? As far as I know Blender rendering should be part of the standard testing for the packaged graphics driver releases like 21.20.
As ROCmSupport said we still have some work to do in terms of getting graphics integration and coverage in the ROCm stack releases, but the graphics driver releases should already have some coverage. I'm not sure if we include Darktable but will ask.

Can you remind me which GPU and DaVinci version you are using ?

AMD Radeon RX Vega 64 Liquid Cooling
DaVinci Resolve Studio 17.2.2
Blender 2.93.1
OS: Ubuntu 20.04.2 LTS x86_64
Kernel: 5.8.0-59-generic
DE: GNOME
WM: Mutter
CPU: AMD Ryzen Threadripper 1900X (16) @ 3.800GHz
GPU: AMD ATI Radeon RX Vega 56/64
With AMDGPU-PRO 21.20 DaVinci Resolve (multiple versions) don't start and Blender (multiple versions) can't render with GPU.
Haven't tested ROCm since it still say it doesn't support GUI apps, whatever that means.
I can't test the Frontier Edition cards atm since I'm working from home but I'd suspect it would be the same think if we were to upgrade.

Hi @KristijanZic
I don't have exact timelines right now, but tentatively before end of 2021.
I will surely share some information, once I receive, if any.
Thank you.

So ROCm v4.1 or v4.2 does not address the issues? I have to say this is taking a long time to fix, well over a year! Furthermore, it seems that buying a newer GPU (RDNA 2 era) would completely break the ability to use DaVinci Resolve currently (as I am on an RX 580 right now). This really perpetuates pressure to just not buy AMD GPUs at all.
And now the target ETA is before end of 2021? I'm sorry but that's just unacceptable.

@BloodyIron yeah, it would appear that they didn't get the message last time. They keep toying with and ignoring their users again. Basically ROCm is still unusable, latest AMDGPU-PRO is broken too. You need to roll back AMDGPU-PRO to the 21.10 and downgrade your kernel and eventually it works but at reduced performance. It's barely usable for DaVinci Resolve and unusable for Blender.

Yeah I've decided I'm going to just get an RTX 3060 ti when I can make it happen, unless AMD pulls magic out of their back between now and then and finally gets ROCm solved. I'd rather stay with AMD for my next GPU, but not at the cost of either gaming performance or OpenCL for Resolve. As the customer I shouldn't have to deal with these problems. The cards cost a good chunk of money and there's no excuse at this point.

We got jebaited :(

I voted with my wallet. RTX 3060 ti in-hand.

Pardon my ignorance, but is the base assumption here that Blackmagic Design's software is able to run correctly and efficiently on all GPUs on all linux distros and any problem must be unrelated to their software?  That seems like a stretch to me.  Does Blackmagic Design officially claim to support the problem configurations and if so, what does their support department have to say about the concerns raised here?  Has their support department relayed to someone here that they are having trouble working with AMD to solve problems when running their software?

@b-sumner read through this thread, the sublinks within this thread (which includes some of Blackmagic's engineering team's comments as well), the history, AMD's own comments, and the other similar topics for other GUI applications (not just Blackmagic software) before commenting that this is a stretch.  Your questions were answered before you asked them.
This is an AMD ROCm driver issue.

@beatboxa I haven't studied every line of this long issue, but while scanning didn't see where it says Blackmagic specifically claims support for your configuration.  I'm also having trouble finding information on their website about which versions of ROCm and which AMD GPU's they actually do claim to support.  Could you point me at the messages where Blackmagic has specifically reached out to AMD for help?

@b-sumner it broke Blender and pretty much all other apps that require OpenCL. Please, point me to the Blender post that says it was designed for this specific config... You won't find it. What you will find is that they support OpenCL, ROCm provides it and it's broken. Therefore the software can't run correctly because of the broken drivers. Please, be a kind lad and go trough all the other issues that AMD has been dragging on trough the years and then come back and offer your informed opinion. (Sorry for being blunt, but we're all annoyed with AMD)

Hi @KristijanZic, what I'm trying to claim here is no software is correct.  Certainly not AMD's, but certainly no ISV's either.  Users running ISV code they paid for should go to the ISV first.  If the ISV doesn't claim to support the user's config, then what does the user actually expect?  If the ISV does claim to support the config but then claims it's not their problem, then I would question what they actually mean to when they say "support".
I definitely hear the pain you all are expressing, but what I still don't get is why the blame is being completely assigned to AMD when there is a whole other layer of software involved that an ISV sold to you and has promised to support.

@b-sumner Just my two cents... Do not forget that there are standards, namely OpenCL and OpenGL. At some point, this is the only link that makes our computers do what they have to do. There just have been a discontinued support for standards from AMD for a too long time! Discontinued support for their Linux users and discontinued support for the ISVs building software upon standards.
Nvidia sends samples to every software manufacturers in town, even open-source ones. AMD just surprise everyone with half-baked solutions. This is unprofessionnal. Period.

but what I still don't get is why the blame is being completely assigned to AMD when there is a whole other layer of software involved that an ISV sold to you and has promised to support.

Because software that was working would only stop working when ROCm was updated, with no other changes.
Could this mean that all of the popular graphical OpenCL accelerated software was using bad coding practices or not fully adhering to the OpenCL standard? Theoretically possible, but it is far more likely that the issue stems from a regression in the ROCm driver, seeing as it effects a wide swath of software, and not just one or two outliers.
The discussion here seems to indicate that the ROCm team (possibly 1 person?) is not terribly well versed with testing graphical applications, and is possibly out of their depth. The difficulty and inconvenience in testing graphical applications remotely through VNC appears to be another stumbling block in getting much progress in this area. So it would make sense that only graphical applications are experiencing issues, where as command-line OpenCL programs continue to function as normal.
I believe it is abundantly clear that the ROCm driver team is understaffed to effectively deal with the regressions and issues users are facing. One can only hope that AMD use some of their new found money and success to hire more people to help with the situation.

@ROCmSupport it has been months, how long are we supposed to stay tuned for updates? We need a clear statement about what is happening. You've made many promises but months, actually years later literally nothing has been done. Could you release a statement urging users not to buy your hardware? At some point if this continues we, the current scammed customers will require a refund, damages or some sort of compensation for this.
You've made vague promises and we haven't receive any updates since those were made. If you were hoping that your customers who you scammed will just die off in this pandemic and this issue will be forgotten, I'm glad to report that we are still alive and still facing the same issues with your neglected drivers.

Writing a quick comment for now, should have more info later in the week. We mentioned earlier that we were working on integrating/harmonizing the ROCm and graphics stack releases so that the same ROCm component versions were used in both. That way graphics stack testing/fixing should help ROCm releases and vice versa.
ROCm 4.5 is the first of these "same ROCm components" releases and is twinned with 21.40.
Apps requiring GL/CL interop are only tested on the graphics stack, however, since the ROCm releases do not include graphics driver components. I expect that will change over time as well, but first priority is getting compute+graphics apps running reliably for our customers on the graphics stack releases.
In the short term it would really help if issues with compute+graphics apps like Blender and Resolve could be filed against the AMDGPU-PRO graphics stack releases rather than against the ROCm releases. That way we can separate compute issues from GL/CL interop issues.
The AMDGPU-PRO releases are tested with Blender and I am told that we are testing Resolve as well, so if the releases are working for us and not working for you then we need to dig deeper re: what we are testing vs what you are seeing fail. Our QA folks were away last week for a national holiday but I should hear back tomorrow re: whether we are testing Resolve and in what environment.

In the short term it would really help if issues with compute+graphics apps like Blender and Resolve could be filed against the AMDGPU-PRO graphics stack releases rather than against the ROCm releases.

For completeness: where would one report issues against the graphics stack?

@johnbridgman It's now about 8 days from the "end of 2021". What's going on, and where are those working OpenCL and OpenGL drivers? Is this problem being tracked by the AMDGPU-PRO project, and where are we to go for status updates?

ROCm 4.5 and AMDGPU-Pro 21.40 were indeed released.  When I tried them several times in a few different configurations, my system would not boot.  I had to recover my system in command line, uninstalling all AMD & ROCm drivers just to be able to boot again; and then I had to reinstall the older versions.  So I am now back on the previous AMDGPU-PRO and ROCm 3.3 (released over 1.5 years ago), since those are the latest versions that worked.
You can see some examples of discussion on ROCm 4.5 in the phoronix article here:

@beatboxa you have to add graphics or multimedia to use-cases which installs amdgpu-lib it is because of new mesa versions. You can check https://gitlab.freedesktop.org/mesa/mesa/-/issues/6005 and thumbs up for a fix.
I am making an article about struggling with AMD. It is worth mentioning a brief: I do Regret buying AMD GPU.

@beatboxa you have to add graphics or multimedia to use-cases which installs amdgpu-lib it is because of new mesa versions. You can check https://gitlab.freedesktop.org/mesa/mesa/-/issues/6005 and thumbs up for a fix.
I am making an article about struggling with AMD. It is worth mentioning a brief: I do Regret buying AMD GPU.

Are you able to run DaVinci Resolve and use GPU Rendering Acceleration in Blender using the new ROCm 4.5?

@BloodyMess Since we can't return GPUs in my country, unfortunately, I switched to Windows, and now everything works fine.
I hate Windows but at least they cooperated with Canonical and made a Linux submodule and you can work with your desired Linux distro in Windows. I love it.

OK... Has ANYONE successfully installed and used ROCm 4.5on Linux with DaVinci Resolve and/or Blender?

OK... Has ANYONE successfully installed and used ROCm 4.5 (or higher) on Linux (ubuntu 18.04 based) with DaVinci Resolve and/or Blender?

Not I...

I've got it mostly working on elementary 5.1.7 (ubuntu 18.04), with a radeon RX590.
Blender Cycles is working fine now.
Here's a demo of the results:
https://youtu.be/u_TQaArfROE

Long time since I caught up on this thread, finally had chance to trial latest combination of AMDGPU drivers + ROCm releases.
I appear to have got lucky, I just updated to the following combinations and finally a functional set of working drivers that allows DaVinci Resolve to work without breaking Steam/games and with a simple test example in Blender it seems to be using the GPU with HIP from ROCm without a problem!
This does end up defaulting to the Proprietary library for OpenGL, which may have some performance impacts for games but at least functions, so I am hoping with a few overrides will allow me to pick and choose which I use for the appropriate library for best performance.
System & Package Versions

GPU: Navi22 [RX 6700 XT]
Distro: OpenSuSE 15.4
Kernel: 5.14.21-15040024.33-default
Xorg: 1.20.3-1504<IP_ADDRESS>
AMDGPU + AMDGPU-PRO: 5.4.1 [ Have a snoop around under https://repo.amd.com/amdgpu ]
ROCm: 5.4.1
DaVinci Resolve: 17.4.3. Build 10
Blender: 3.4.0

Uninstalled all existing/legacy AMDGPU + ROCm packages first, removed the old repositories too.
Installed approximately like so:
zypper addrepo https://repo.radeon.com/amdgpu/5.4.1/sle/15.4/main/x86_64/ "AMDGPU 5.4.1 repository"
zypper addrepo https://repo.radeon.com/amdgpu/5.4.1/sle/15.4/proprietary/x86_64/ "AMDGPU 5.4.1 Proprietary repository"
zypper addrepo https://repo.radeon.com/rocm/zyp/5.4.1/main "ROCm 5.4.1 repository"

zypper --no-gpg-checks install https://repo.radeon.com/amdgpu/5.4.1/sle/15.4/main/x86_64/amdgpu-install-5.4.50401-1518338.noarch.rpm

amdgpu-install --usecase=graphics,multimedia,amf,opencl,hip,workstation,rocm --opencl=rocr,legacy --vulkan=amdvlk,pro

DaVinci Resolve
For DaVinci Resolve at first it was very choppy for the playback, lots of intermediate dark frames and GPU dispatch errors when playing back or skipping.
All I had to do to resolve this, was select the correct OpenCL provider under the settings menu. (i.e. Override the automatic selection mode)

AMD Radeon RX 6700 XT
AMD Radeon RX 6700 XT (navi22, LLVM30.0.1 DRM 3.42, 5.14.21-50400.24.33-default)

First one mapped to the AMDGPU-PRO OpenCL provider, this matched an independent installation on a spare drive I'd done as a work-around.
Blender
Tested GPU rendering by doing the following:

Edit -> Preferences
System -> Cycles Render Devices
Select HIP at the top
Then you get a choice of detected GPUs
Confirmed by switching back to CPU and monitoring CPU load + GPU load when rendering in each mode

This is similar to DaVinci provided, except this time it searches/loads ROCm dynamically once you select this rather than being linked against a particular library -- According to strace.
Kind regards,
Jim Shorter

Update:
It seems AMD may have now delivered on a couple of the promises for the future.
I do admittedly now have a different hardware configuration below, which happens to have the lead feature support announced in ROCm release 5.7.x for Navi31, however the software versions have not really changed a huge amount other than base AMDGPU, ROCm, kernel upgrade for latest GPU firmware to function as intended.

Motherboard: Asus ProArt X670E Creator WiFi
RAM: 64GB (4x16GB, SK Hynix-M die 6400MT/s kit currently at 6000MT/s)
CPU: AMD Ryzen 9 7900X
GPU: Navi31 [RX 7900 XTX]
OS: OpenSuSE Leap 15.4
Kernel: 6.1.5lp153.2.g0fb77d6 (backports)
DaVinci Resolve: v17.4.3 Build 10
AMDGPU: 5.5.3
ROCm: 5.7.1

I am able to use the ROCm OpenCL provider in this case as I cannot use the Proprietary OpenGL + CL code path without breaking OpenGL compatibility for Steam.
I am editing off of a 10GbE LAN connected NAS with OpenZFS storage and the scrubbing performance is perfect.
Some file types require a bit of pre-caching but aside from this it's an absolute dream compared to before, but especially adding post-processing effects that really stress the OpenCL performance and its practically a dream!
For those of you expecting to need things like the amdgpu-dkms, overriding OpenGL library paths or OpenCL provider - None of that nonsense is needed anymore, launch the application as-is and it works!
Kind regards,
Jim Shorter

They didn't deliver on anything. They lied to us and sold us unsupported hardware. They kept promising support and never delivered. And now they dropped support for Vega all together... A >1000€ card. AMD is honestly the worst company ever.
I hope Intel and Nvidia eat AMD market share in the future. AMD does not deserve it and they can only sell anything by defrauding customers...

Hi @KristijanZic, DaVinci Resolve 18 is working when paired with ROCm 6.1.3.
Please follow the instructions here and specify the workstation usecase when installing with amdgpu-install as done below
amdgpu-install -y --usecase=workstation,rocm
If you encounter any issues DaVinci Resolve with ROCm 6.1.3, please open a new ticket. Thanks!


[FR]: Async Await FirebaseStorage observers

Description
https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseStorage/Sources/AsyncAwait.swift
In this file we emit StorageUploadTask, and we can't add observers, so we don't know about the progress. (e.g. putFileAsync)
Uploading large files difficult to handle without knowing status
API Proposal
Perhaps you can add delegate and handle all observers inside, then tell that something is changed to delegate?
Firebase Product(s)
Storage

Thanks for the request. We're exploring an async/await API with Progress support in #10161.  We're somewhat hesitant to go forward with this since Apple's roadmap for Progress is unclear. See https://forums.swift.org/t/what-s-next-for-foundation/61939#removed-types-8
In the meantime, the original non-async/await Storage APIs continue to support Progress.

Hello @paulb777
Thank you!

After more thought, I believe the original APIs that return Task handles should be sufficient if you want to check task status. The async/await API's should only be used for fire and forget mode.
I'll close here, but feel free to continue the conversation.

@paulb777 Hi, yeah, I'm using original Api to check statuses now, but I want to improve my code to fit async await, and functions like delete are working well, so I thought if you can improve other methods as well, so I won't loose any functionality

@paulb777 Hi
Why do you think that async await API should be different from the original one?
From my perspective it should be the same. Also Apple's doing the same thing. For example you can access 'fractionCompleted' in async/await in Progress, it is easy to access via KVO. What do you think about KVO?

I defined an extension which takes a closure, which is called when progress happens, while the result is still returned from an async function.
extension StorageReference {
    func write(toFile url: URL, onProgress: @escaping (Double?) -> Void) async throws {
        let downloadTask = self.write(toFile: url)
        try await withCheckedThrowingContinuation { continuation in
            downloadTask.observe(.progress) {
                onProgress($0.progress?.fractionCompleted)
            }

            downloadTask.observe(.success) { _ in
                continuation.resume(with: .success(()))
            }

            downloadTask.observe(.failure) { snapshot in
                continuation.resume(with: .failure(snapshot.error ?? NSError()))
            }
        }
    }
}

// on the call site
try await reference .write(toFile: file) { progress in
    print(progress ?? 0.0)
}

That is working fine so far, but an integration of something like this into the package would be nice.


Update mixin_swiftpm_base to include swift-driver

Updates the base spm preset to include building and installing the swift driver. This ensures that ci jobs properly use the new driver instead of the to-be-removed c++ version.
Fixes the issue with the spm LTO test fixture on linux here: https://github.com/apple/swift-package-manager/pull/6891

@swift-ci please test

@swift-ci please smoke test

@neonichu is this still true: https://github.com/apple/swift-package-manager/pull/5842#issuecomment-1302470145?
I thought some things had changed wrt now needing swift to build swift?

Unlike that PR this one has CI checks green, so maybe things have changed enough for this to be ok?

Unlike that PR this one has CI checks green, so maybe things have changed enough for this to be ok?

Unclear, it seems like this PR is a needed first step but won't fix the issue where SPM is built and tested before swift-driver is built


ISPN-10102 Bound checks with byte should be 1

https://issues.jboss.org/browse/ISPN-10102

Integrated into master, thanks @galderz !


Add LitState to LitElement extensions

I thought whether I should use the npm package name. But the name of a package isn't always the "name". With LitElement itself for example, the package name is lit-element, but the official name of the library is "LitElement".
Don't you think it's better to use the "real name" instead of the package name?

I think it makes sense to use a consistent approach in the list. Not every package has an "official" name. But I might reconsider that.

Yes, I agree with consistency. If we would use the "official name", we should do it everywhere. In the case if a package doesn't have an "official name" aside from the package name, then I would argue the package name itself is the official name.
I think that package creators would appreciate it if the official name would be used. Because npm package names have limitations that a official name doesn't have.
But yeah, think about it. Thanks for the merge anyway! :smile:


Async calls raise RuntimeError when called after catching KeyboardInterrupt

When we get a SIGINT, we inject a KeyboardInterrupt into our child process
(https://github.com/ethereum/asyncio-run-in-process/blob/master/asyncio_run_in_process/_child.py#L105),
but as I described in https://github.com/ethereum/trinity/issues/1613, any async calls made when
handling a KeyboardInterrupt inside the child seemed to raise another KeyboardInterrupt. I've
been trying to figure out what's going on and although I haven't had any luck so far, I've managed
to get a similar behavior in the tests here, so I'm posting this to see if anybody has any idea
what's going on
As you can see, our tests were using await asyncio.sleep(0), to simulate an asynchoronous cleanup
after a KeyboardInterrupt is caught, but that doesn't seem to have the same effect as a non-zero sleep.
With the non-zero sleep we get a crash similar to the one I describe in that trinity issue, although
here it seems to manifest itself as a RuntimeError.

@jannikluhn as you seem to have looked into this recently (#11), I thought I'd ping you as well

Very stange.  I found it also hangs indefinitely if you replace the sleep(0) from the except block with a call to an arbitrary async function like the following.
async def whatever():
    pass

Very stange. I found it also hangs indefinitely if you replace the sleep(0) from the except block with a call to an arbitrary async function like the following.

Where is that function defined? Did you run with -s --log-cli-level=0? For me the test passes with that change as long as the function is not defined in the test file

Actually, as long as the empty async function is not defined at the top level of the test file (which makes it unpicklable), the test seems to still pass

I suspect my failures were somehow related to the pickli-ability of those functions.  I'll dig in some tomorrow and see if I can't get any new insight into this.

So, I've managed to come up with a simpler test case that exhibits this issue, and at least now it's clear why the test passes with a sleep(0). It's because the throw() method returns whatever the coroutine yields after catching the exception, and py3.7's asyncio.sleep() uses a bare yield when the delay is 0 (https://github.com/python/cpython/blob/master/Lib/asyncio/tasks.py#L627-L636), instead of creating a Future. And something in asyncio-run-in-process must be attempting to await on that future, as that is what causes the RuntimeError we're seeing.
Here's the test I came up with:
import asyncio
import sys

async def sleep_on_exc(delay):
    try:
        await asyncio.sleep(1)
    except KeyboardInterrupt:
        print("caught KeyboardInterrupt in sleep_when_handling_exc(), sleeping %f seconds" % delay)
        await asyncio.sleep(delay)
        print("finished sleeping after KeyboardInterrupt")

async def return_on_exc():
    try:
        await asyncio.sleep(1)
    except KeyboardInterrupt:
        print("caught KeyboardInterrupt in return_on_exc(), returning")

async def main(coro):
    asyncio.ensure_future(coro)
    await asyncio.sleep(0.1)
    print("Injecting KeyboardInterrupt")
    try:
        v = coro.throw(KeyboardInterrupt)
    except StopIteration:
        # When the coroutine returns immediately, like return_on_exc(), this is what happens.
        print("coroutine raised StopIteration, exiting")
    else:
        # When the coroutine performs an async call after catching the injected exception,
        # it will effectively yield and that is then the return value of throw()
        # https://www.python.org/dev/peps/pep-0342/#new-generator-method-throw-type-value-none-traceback-none
        print("coroutine yielded: %r" % v)
        if v is not None:
            await v

loop = asyncio.get_event_loop()
loop.run_until_complete(main(sleep_on_exc(float(sys.argv[1]))))
# loop.run_until_complete(main(return_on_exc()))

And here's what we get when running it with a delay of 0:
salgado@t495~/src/trinity (concurrent-component-termination) $ python coro-throw.py 0
Injecting KeyboardInterrupt
caught KeyboardInterrupt in sleep_when_handling_exc(), sleeping 0.000000 seconds
coroutine yielded: None
Task was destroyed but it is pending!
task: <Task pending coro=<sleep_on_exc() done, defined at coro-throw.py:5> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f09ae8a2490>()]>>

And here with non-zero delay:
salgado@t495~/src/trinity (concurrent-component-termination) $ python coro-throw.py 0.1
Injecting KeyboardInterrupt
caught KeyboardInterrupt in sleep_when_handling_exc(), sleeping 0.100000 seconds
coroutine yielded: <Future pending>
Traceback (most recent call last):
  File "coro-throw.py", line 40, in <module>
    loop.run_until_complete(main(sleep_on_exc(float(sys.argv[1]))))
  File "/usr/lib/python3.7/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "coro-throw.py", line 36, in main
    await v
RuntimeError: await wasn't used with future
Task was destroyed but it is pending!
task: <Task pending coro=<sleep_on_exc() done, defined at coro-throw.py:5> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7fbf1f8174d0>()]>>

And looking at how Future.__await__() is implemented, it becomes clear that something must be causing us to await for that future twice, as that's what causes the RuntimeError: https://github.com/python/cpython/blob/dec367261e7e2bb4dd42feeb58031abed2ade683/Lib/asyncio/futures.py#L260-L266

It looks like it's because _handle_coro() runs in a loop, awaiting for coro_task on each iteration...

I've filed https://bugs.python.org/issue40152 as it's looking like we may have to use something other than coro.throw() here

Kinda neat if this is actually a python bug!

Not clear what to do here, waiting to see if someone sheds some light on that python issue


How to change where Next looks for pages?

So, I am wanting to build a Next app with T$.
To do that, I install typescript and compile my Next app into a bin directory:
+ bin/
  + server.js
  + pages/
    + index.js
+ server.js
+ pages/
+ index.tsx
+ package.json

In package.json, I have a script: node bin/server.js. When I run said script, Next will look in ./pages instead of ./bin/pages (i.e. from the cwd not __dirname). To work around this, I have to cd into bin before running node ./server.js (a one-line would be (cd ./bin && node ./server), if you're reading this and you need a work-around)
It it possible to configure where Next looks for pages?

When you create your custom server you can pass a argument dir to next.
const next = require('next')
const dev = process.env.NODE_ENV !== 'production'
const app = require({ dir: './bin', dev })

Next.js it's going to use ./bin to look for pages directory.

Ah, that is exactly what I was looking for but couldn't find in the docs 😢

Posted https://github.com/zeit/next.js/issues/8451


Locking by label from 2 jobs exact the same time causes lock up of one of them

The Situation:

We have 2 pipeline jobs starting the exact same time running on 2 different agents.
We have 3 registered lockable resources with the same label.

This is what happens:

Both jobs reach the lock command for a label exact the same time
Both jobs get the same resource back and try to lock it
Only one job continues with the locked resource, the other one waits.

What should have happened:

Both jobs reach the lock command for a label exact the same time
Each job gets another resource name back and locks it
Both jobs continue each with their locked resource

Shared pipeline code for both jobs:
lock(label: 'STP-' + CFG_NR, variable: 'STPCLONE') {
        echo "Current Lock on Clones: " + env.STPCLONE
       .... Lot more code ....
}

Our Lockable Resource configuration:
(Manually entered in Jenkins configuration!)
Name: STP-S2D01
Labels: STP-001

Name: STP-S4D04
Labels: STP-001

Name: STP-S1D04
Labels: STP-001

Job 1 Console
[Pipeline] lock
22:43:19 Trying to acquire lock on [Label: STP-001, Quantity: 1]
22:43:19 Lock acquired on [Label: STP-001, Quantity: 1]
[Pipeline] {
[Pipeline] echo
22:43:19 Current Lock on Clone: STP-S2D01

Job 2 Console
[Pipeline] lock
22:43:19 Trying to acquire lock on [Label: STP-001, Quantity: 1]
22:43:20 [Label: STP-001, Quantity: 1] is locked, waiting...
06:40:13 Lock acquired on [Label: STP-001, Quantity: 1]
[Pipeline] {
[Pipeline] echo
06:40:13 Current Lock on Clone: STP-S2D01

I wonder if this race is related to an issue we rarely see in other conditions: a freestyle job with a custom groovy script evaluating the whether available resources to lock are suitable for this job (so the custom logic returns a boolean, and the plugin builds a map), and eventually assigning the locked resource name into a string usable by further groovy/shell/... steps.
Once in a few weeks this string comes out empty while there is nothing logged about resource inspection failures, etc. I did not correlate if there are indeed some "same-time" assignments.
But if there are, maybe there is a way (mutexes?) to ensure that the state-change of the locked resources (including picking a free one from the map) are sequential. Then in such situations one run would get the map of available suitable resources (whichever way to do so is defined for the job), mutex, pick a resource from the map, lock it to the job, un-mutex. A second competing build would hit the mutex, wait for it to be un-held, and eventually find and get another available resource (or wait in the queue if there is none).

Should be the same problem as #149.
Getting a resource is not synchronized.

Can you check if you can reproduce the issue with recent release (2.14 or newer)?
There were changes since 2019 about use of synchronized methods, as well as a fixed corner cut short in the assignment of a just-now-released resource to the next job in queue, that might impact the behaviors explained above.

We hadn't had this issue for quite a while now, at least a year, so we cannot reproduce it any more.


Support for umbrella projects

Shameless steal from https://github.com/ddmck/lcov_ex fork.
Thanks @ddmck!

Glad it was useful!


Removed Security Event Log from default Event Log configuration.

Fix for https://github.com/Microsoft/vstest/issues/1257

@dotnet-bot  test this please.

@dotnet-bot test this please.

@dotnet-bot test this please.


Unicode regex support

Bug report

What is the current behavior?
IE11 doesn't support unicode regex constructor. For ex: new RegExp('[^\p{L}\p{N}\p{Zs}\-]', 'u') or /[^\p{L}\p{N}\p{Zs}-]/u throws an error.
What is the expected behavior?
Supporting unicode regex constructor in IE11
What's your environment?
Internet Explorer 11

@prakashpsde Sorry, but looks like a problem directly in your application and not in redux-form. Try to polyfill RegExp in your application.


Unexpected Microsoft.PythonTools.Attacher.exe in the running processes

MS build 3.0.1487
VS 2015 RTW build

In VS2015, create a powershell script project. You can use the one pasted below.  (the problem is not script specific)
Set a breakpoint somewhere in the script.
F5 to stop at the breakpoint
Select "Debug->Attach to Process" in the Attach to Process dialog. Leave all settings with default values. Then chose "PowerShell host service" to attach to. Close the dialog
Set the focus back in the editor then hit F10 and F5.
Click on stop debugging in the toolbar
Repeat steps 3 and 4.

Notice, in the Attach To Process, you will see an extra process named "Microsoft.PythonTools.Attacher.exe", which probably was launched by the PoshTools on the second attach.
I understand this isn't a typical "Local Attach" scenario, but there was nothing preventing me from doing so.
Script attached:

Script.ps1

Get-Service
Get-Process
$var = 'hello'
$number = 1
$numbers = 1,2,3,4,5,6,7,8,9
$debug = "$computer contains $computer" $head = "ColumntColumn`tColumn"
$filter1 = "name='BITS'"
$computer = 'BITS'
$filter2 = "name=$computer'"
$var = 'hello'
$var | Get-Member
$svc = Get-Service
$svc[0].name
$name = $svc[1].name
$name.Length
$name.ToUpper()
$service = 'bits'
$name = "Service is $service.ToUpper()"
$upper = $name.ToUpper()
$name = "Service is $upper"
Write-Host $name
$name = (Get-Service)[0].name
Write-Host $name

BTW, this machine does have Python Tools for Visual Studio installed.

From looking at the PTVS code, it appears they launch their attacher to detect if a process is attachable. So, when you selected debug all types, the PTVS attacher must have been launched to see if PTVS could attach to it.


unicode characters that behave different from the corresponding LaTeX macro

I've made a list of unicode symbols that behave different from the corresponding LaTeX macro:
\begin{align}
\alpha &=α\\
\Bbb R &=ℝ\\
\sum_{k=0}^n&=∑_{k=0}^n \\
\prod_{k=0}^n&=∏_{k=0}^n \\
\sqrt{2}&=√{2} \\
\sqrt[3]{2} &=∛{2} \\
\sqrt[4]{2} &=∜{2} \\
x^2&=x² \\
x_2&=x₂ \\
\mathscr{C}&=𝒞 \\
\mathcal{C}&=𝒞 \\
\overbrace{x+y} &= ⏞{x+y} \\
\underbrace{x+y} &= ⏟{x+y} \\
\end{align}

Demo: http://jsfiddle.net/4WvgA/6/
I made a unicode math typer here: http://kasperpeulen.github.io/PressAndHold/Unicode/
And there I use some Davide hack there, to make those unicode symbol behave like LaTeX macros,  but I would like it if people can use my tool also at other places as well. There are probably same unicode characters where it is not obvious how mathjax should handle them. But for many cases, I think there is only one obvious option.

Also the unicode symbol ∞ behaves different from the corresponding LaTeX macro \infty
Below is $\infty ∞$ converted to MathML:
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mi mathvariant="normal">∞</mi>
  <mrow data-mjx-texclass="ORD">
    <mo>∞</mo>
  </mrow>
</math>

Also, the behavior is different for unicode characters ∑ and the corresponding LaTeX macro \sum in display style (the LaTeX macro with sub/superscripts are converted to munderover but unicode characters with sub/superscripts are converted to msubsup). For example,
$$∑_{i=1}^n\sum_{i=1}^n$$

is converted to
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <msubsup>
    <mo>∑</mo>
    <mrow data-mjx-texclass="ORD">
      <mi>i</mi>
      <mo>=</mo>
      <mn>1</mn>
    </mrow>
    <mi>n</mi>
  </msubsup>
  <munderover>
    <mo data-mjx-texclass="OP">∑</mo>
    <mrow data-mjx-texclass="ORD">
      <mi>i</mi>
      <mo>=</mo>
      <mn>1</mn>
    </mrow>
    <mi>n</mi>
  </munderover>
</math>

Also, the behavior is different for unicode uppercase greek letters and the corresponding LaTeX macros.
For example, $Σ\Sigma$ is converted to
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mi>Σ</mi>
  <mi mathvariant="normal">Σ</mi>
</math>

How to change "mathvariant" of unicode uppercase greek letters to "normal" by default? Thanks!

@hbghlyj, you are correct that MathJax doesn't handle raw unicode characters in the same way as it does the corresponding macros.  it is possible, however, to map these characters to the appropriate macros if you wish.  One possible version 3 configuration that does this would be the following:
MathJax = {
  startup: {
    ready() {
      const {Configuration} = MathJax._.input.tex.Configuration;
      const {MacroMap} = MathJax._.input.tex.SymbolMap;
      const BaseMethods = MathJax._.input.tex.base.BaseMethods.default;

      //
      //  Subclass the MacroMap to add ['Macro', ...] around the macro string
      //    in the definitions for each character
      //
      class MacroChars extends MacroMap {
        constructor(name, json, methods) {
          for (const [name, macro] of Object.entries(json)) {
            json[name] = ['Macro', macro];
          }
          super(name, json, methods);
        }
      }

      //
      //  Create a macro mapping for the characters to their TeX equivalents
      //
      new MacroChars('unicode-chars', {

        //
        //  Some larg operators
        //
        '\u220F': '\\prod',
        '\u2210': '\\coprod',
        '\u2211': '\\sum',
        '\u222B': '\\int',
        '\u222C': '\\iint',
        '\u222D': '\\iiint',

        //
        //  Greek capitals (you can add the rest)
        //
        '\u03A3': '\\Sigma',

        //
        //  Some other symbols
        //
        '\u221E': '\\infty',
        '\u221A': '\\sqrt',
        '\u221B': '\\sqrt[3]',
        '\u221C': '\\sqrt[4]',

        //
        //  Double-struck letters (add the rest)
        //
        '\u2102': '\\mathbb{C}',
        '\u211D': '\\mathbb{R}',

        //
        //  Over- and under-braces (could do over/under-parens, etc.)
        //
        '\u23DE': '\\overbrace',
        '\u23DF': '\\underbrace',

      }, BaseMethods);
      //
      //  Create the package containing these characters
      //
      Configuration.create(
        'unicode-chars', {handler: {character: ['unicode-chars']}}
      );

      MathJax.startup.defaultReady();
    }
  },
  tex: {
    //
    //  Tell TeX to use your new package
    //
    packages: {'[+]': ['unicode-chars']}
  }
}

I have not included every character that you will want, so you will need to augment this to suit your needs.  Note also that the replacement string can be any TeX code, not just a single macro.
This could be the basis for a proper extension, and that would make a nice first effort for someone looking to contribute to MathJax.

I am working on latex converter tool - https://kamalveer-singh.github.io/Latex_Online/
I don't know if I can share it here or not, but I thought it might be of some help, please notify me if it's not!!

This is not an appropriate place to post advertisement for your tool.  Also, as it is KaTeX-based rather than MathJax-based, it's also not very tactful.

This is not an appropriate place to post advertisement for your tool. Also, as it is KaTeX-based rather than MathJax-based, it's also not very tactful.

No, I wasn't advertising it, I just wanted to seek some guidance and be skillful enough for doing open source. Can you tell me which technologies to use, or can you tell me where to contact you for the same, also if it's not the right place just tell me once I'll delete the comments.

I just wanted to seek some guidance and be skillful enough for doing open source.

Not at all clear from your original post.  Your statement that "I don't know if I can share it here or not, but I thought it might be of some help" suggests you are trying to point people to your tool and that it might be useful to them, which seems like an advertisement, not a request for help.
This issue tracker is for reporting bugs in MathJax or requesting new features, not general guidance for non-MathJax projects or other open-source projects.  Since you are not reporting a bug or asking for a feature, and your project isn't even MathJax-based, this is not the right place for your post.  It is also not good practice to attache your comment to an existing issue that really has nothing to do with your post, even if it were appropriate for this forum.
If you are looking for general programming or open-source advice, you might consider a forum like stack overflow.


load multiple defender positions

Proposed changes

#276
Related issues

Necessary checks

[ ] Update package version
[ ] Run catkin build
[ ] Write documentation
[ ] Create issues for future work
[ ] Test on your machine
[ ] Test on the robot
[ ] Put the PR on our Project board

How can this be tested?

How can this be tested?

Walk to the initial positions with all role configurations (role and role position number). You can change the role in the config. I think it is in the game settings or the body behavior config.


Client Allocation Request for: Genesis

Client Allocation Questions
Core Information

Name: Genesis
Website / Social Media: zhongchuangIPFS
Region: Greater China
DataCap Requested: 50TiB
Addresses to be Notarized: f3wwiudiv2vjdswtc4aab5o3qs6ygeujrrixyv6a2z4o6aoma34rjayapsmwvqxxgn7aavmzomfquzwd2dn3fa
Notary Requested: steven004

@1ane-1 Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Hey @1ane-1 ， thanks again for your saving data in Filecoin network.
I will not request more information from you since you had applied a few rounds of datacap, and passed the verification. Would you please list your previous applications here for public reference? Thanks.

Hey @1ane-1 ， thanks again for your saving data in Filecoin network. I will not request more information from you since you had applied a few rounds of datacap, and passed the verification. Would you please list your previous applications here for public reference? Thanks.
Here it is. Thank you very much.
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/1496
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/720
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/532
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/366

Hey @1ane-1 , Your Datacap Allocation Request has been approved
Message sent to Filecoin Network

bafy2bzacedtvasddfamjcqnvh4j2yvklotqv6rc4ys42bvlvfl2c25otyhfda

Address

f3wwiudiv2vjdswtc4aab5o3qs6ygeujrrixyv6a2z4o6aoma34rjayapsmwvqxxgn7aavmzomfquzwd2dn3fa

Datacap Allocated

50.0TiB

@1ane-1 , I would suggest you applying large dataset, if you will have more data to save into Filecoin network. Thanks.

https://github.com/filecoin-project/filecoin-plus-large-datasets/issues/260
thank you very much, this is the large datacap application, i need the notary siganture sincerely.

@1ane-1 , I would suggest you applying large dataset, if you will have more data to save into Filecoin network. Thanks.

https://github.com/filecoin-project/filecoin-plus-large-datasets/issues/260
thank you very much, this is the large datacap application, i need the notary siganture sincerely.

deals.txt
Here is the deal list, Pls check it.

This user’s identity has been verified through filplus.storage


[CI] Replace colcon-mixin-name with colcon-defaults

The former is not a valid option in<EMAIL_ADDRESS>having been removed in favor of the latter in https://github.com/ros-tooling/action-ros-ci/pull/591.
Fixes https://github.com/ros-controls/ros2_controllers/issues/305.
Signed-off-by: Abrar Rahman Protyasha<EMAIL_ADDRESS>

This will/should be an integral part of #317

Closing this PR since the changes have been incorporated in #317.


Update 2000-01-01-download.md

The app seems to be packed in a format that Yosemite doesn't support. A simple two step process solved the problem. It will be useful to have this documented.
More details here: https://github.com/ariya/phantomjs/issues/12974

@hneelakantan we don't need it. This was fixed.


Decreased tab symbol size to improve look

I think that the tab symbol is really large and this decreases the general clarity of the code when there are lots of tab characters. This is how it looks currently:

This is the proposed look (similar to Visual Studio Code):

Can you please make it optional? I have made the arrow this long intentionally, because it clearly shows that where the tab begins and where it ends. (Other text editors do the same thing btw) However, I am aware of that it is kind of a question of personal taste or preference, so if you could make it switchable by a bool property with the appropriate setter/getter funcs, that would be the best.

Ok, I'll do it when I can! Also for the name of the property I'm thinking about OneCharLongTab or something like that. What do you think?

Yes, or maybe just "ShowShortTabGlyphs".... Anything simple would do it I think.

Done!


Istio 1.1.1 breaks routing

Describe the bug
After upgrading from 1.1.0 to 1.1.1, all the routing stopped working. Everything responds with a 404.
Expected behavior
Routes should not be impacted by a minor revision upgrade!
Steps to reproduce the bug
Upgrade from an existing 1.1.0 with some routes (gateway + virtualservice) and then upgrade to 1.1.1 and you should get 404.
Version
Working with 1.1.0
Everything 404 with 1.1.1
Installation
Helm chart
Environment
Kubernetes 1.13

I am seeing the same thing with the 1.1.1 release.

So i didn't see this and wondering what is different!
I don't use Gateway at all, but have 200+ VirtualService

After upgrading from 1.1.0 to 1.1.1, I'm facing similar issue.
Routing on :80 is working fine, however it's failing for :443:
[2019-03-26 22:46:14.020][52][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:70]
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener <IP_ADDRESS>_443: error adding listener '<IP_ADDRESS>:443': multiple filter chains with the same matching rules are defined

Just looking at the release notes, it seems like this is most likely related to "Add namespace scoping to the Gateway ‘port’ names." @philrud
or possibly " Do not apply VirtualService rule to the wrong gateway" @rshriram
The other changes seem unlikely to be related

@emedina @hgontijo I wasn't able to reproduce it yet with a couple of rather trivial examples that I've tried. Could you please provide some extra details so we know what to look for? Specifically:

please share some yamls -- at least your gateway/virtualservice definitions
please provide installation options/flags that were used to install 1.1.0/upgrade to 1.1.1
is this only happening as the result of an 1.1.0 -> 1.1.1 upgrade? did you have a chance to try reproducing this with a clean 1.1.1 installation?
is it permanently broken with 1.1.1 or would it recover eventually after upgrade is finished?

thanks!

Okay, looks like I'm able to reproduce 404s during a short time window right after 1.1.0 -> 1.1.1 upgrade (eventually they go away in my case though, would be great if anybody who's hitting this issue could confirm whether the 404s are permanent).
This seems to be related to my changeset: https://github.com/istio/istio/pull/12556

@philrud Please find here the answers to your questions:

please share some yamls -- at least your gateway/virtualservice definitions
_https://gist.github.com/emedina/ba73a409158d8f0bfbfd7c60bfdd4240_

please provide installation options/flags that were used to install 1.1.0/upgrade to 1.1.1
is this only happening as the result of an 1.1.0 -> 1.1.1 upgrade? did you have a chance to try reproducing this with a clean 1.1.1 installation?
Reproducible for me as a clean 1.1.1 installation (deleted ìstio-system namespace, crd, then re-install everything from scratch).

is it permanently broken with 1.1.1 or would it recover eventually after upgrade is finished?
Permanently broken, although I do see the clusters and listeners in the Ingress gateway proxy.

Let me know where I can help further.

I am also getting 404s, but they appeared already shortly after upgrading to 1.1.0 from 1.0.6. Upgrading to 1.1.1 did not change anything. Trying to reproduce it locally on a minikube.

Thanks, @emedina.
So this definitely has nothing to do with #12556 as that change only affects HTTPS routes and all of @emedina's gateways are HTTP. I've tried that setup fitted with a few helloworld-like services -- that actually works for me, I can't reproduce the 404s.
Also looks like 404s indeed aren't new as @hpohl mentioned. I can reproduce the same spurious 404s during 1.0.x -> 1.1.0 upgrade as well, so I'm taking back what I said earlier regarding that it may be related to #12556 (worth noting I was trying with only a single ingressgateway/single pilot instance).
If anybody can come up with an isolated example and steps to reproduce the issue (with either https or http case) that would be super-useful.

Also happened to me, but only on GPRC/HTTP2 protocols

Here is a gist of a slimmed down setup triggering this issue: https://gist.github.com/hpohl/85a2195ff798845ae38821446136c9b9
One of the services works while the other one just returns 404s. Which one is working and which one not seems to be picked by random.

@hpohl I think this is the same issue as https://github.com/istio/istio/issues/13014

Yes, can confirm it's that issue. So maybe this one is a duplicate (or the other one).

Closing this due to lack of information. If there's any additional information on how to reproduce this, please re-open or rather open a more specific issue.

@philrud they provided yaml of their setup to reproduce. what other info is needed? I don't think this should be closed

@howardjohn oh, so we're not yet sure if this is the port conflict? I've misinterpreted your prev. comment.
@hpohl's issue isn't 1.1.1 specific according to his prev. comments so probably should be tracked separately (or as part of #13014 if we believe this is a dup) as this is getting very confusing.

I don't think the original issue is the same, but looking closer it is unclear, maybe they are a dupe. @emedina do you have two services on the same port targeting different container ports?

@howardjohn yeah, I get it now. Regarding @emedina case, see the conversation above, here's the yaml: https://gist.github.com/emedina/ba73a409158d8f0bfbfd7c60bfdd4240 – I've tried it with 1.1.1, that actually works (after substituting container images with a helloworld-style app), I wasn't able to reproduce the behavior that was described

@howardjohn Yes, the port where the Pod's API is listening and the port where the Pod's health is listening. My Pods are typically Spring Boot applications where the API listens on 8080 and health actuator on 8081.

It seems I'm still facing this issue with 1.1.3, but I will confirm in a while whether it's actually the case. I will downgrade to 1.0.1 and see...

@emedina do you still face this issue?

This has been solved at least in 1.1.8, so closing the issue.


release: 0.7.0

Codecov Report

Merging #10 (d535f01) into main (fc3d361) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #10   +/-   ##
=======================================
  Coverage   19.89%   19.89%
=======================================
  Files           7        7
  Lines         553      553
  Branches      553      553
=======================================
  Hits          110      110
  Misses        421      421
  Partials       22       22

Impacted Files
Coverage Δ

cargo-sbom/src/main.rs
53.96% <100.00%> (ø)

serde-cyclonedx/src/lib.rs
100.00% <100.00%> (ø)

serde-spdx/src/lib.rs
100.00% <100.00%> (ø)


How to set a Starting document

I need to know how to set an existing excel file to debug my add-in
Can any one please help me?

Hi @Mahmoud3193,
You should be able to sideload an add-in into any existing Excel file. The sideloading instructions can be found here.
@millerds, is there a way to specify an existing file when running a project created through yo office?

I'm sorry but the. VS code instructions only applies for the web, is there a way to side load to a desktop file

For desktop, you'll have to follow the instructions for sideloading using a network share, found here.