iod

You of course can, assuming that your hardware configuration supports eMMC with dedicated hardware boot partition(s). Some devices, like the one I used in my example, in its default configuration the hardware is actually booted from a MicroSD card as a regular mmc block device; which is quite common in hobbyist targeted SBCs. In those cases you have to be cognizant of boot loader firmware locations if you want a GPT partition table, as most user guides and sample disk images for these systems assume MBR style partition table reserving only the first block. Followed by system-specific boot blob(s) at the required offset location and then a fat32 partition somewhere thereafter with the OS. If the boot firmware blob starts before the 34th¹ block with 512-byte sectors blocks, then for setting up GPT, you move the main GPT table to after the firmware; otherwise you can just allocate the first partition space as reserved protected area in GPT for the firmware so that it doesn't get written to as a reference for future repartioning.

¹ https://en.wikipedia.org/wiki/GUID_Partition_Table#Features

U-Boot does actually have some support for GOP Video¹. It's rather new, so it might be worth revisiting with your specific devices.

¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...

U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices.

For example, right now I have an old armhf i.MX6 Wandboard Quad that runs:

  U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro)

Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.

¹ https://docs.u-boot.org/en/latest/develop/uefi/uefi.html

² https://www.rodsbooks.com/gdisk/sgdisk.html

People interested in FUSE might also be interested in the CUSE companion (sub)project.

CUSE is userspace character device driver emulation. It allows you to emulate hardware without compiling a new kernel module. I just used it recently to write a hardware device supporting IOCTLs using Python. However I didn't find any good Python libraries that worked easily and documentation was lacking, but I found it easy enough that I ended up writing it using just the ctypes ffi library. The only part that wasn't immediately intuitive for me, as someone who has never written kernel drivers, is how IOCTL's require the buffers to be resized for each read and write which means the calls come in pairs, but luckily CUSE has a debug mode which shows all bytes in and out. CUSE was originally implemented to create userspace sound devices¹ but has also been use for things like custom TTYs. I used it for creating a virtual SPI device. Hopefully someone finds this useful and this project can get more attention.

¹ https://lwn.net/Articles/308445/

As per the direct quote in my parent comment, by "unlimited concurrent viewers", I can only assume that they mean what it says as taken by the text from the links of both ¹⁺²

People interested in this project might also be interested in Cloudflare's webrtc streaming service¹ as a cloud hosted solution to this same problem. "Sub-second latency live streaming (using WHIP) and playback (using WHEP) to unlimited concurrent viewers." Using the same OBS WHIP plugin, you can just point to Cloudflare instead. Their target pricing model is $1 per 1000 minutes.² Which equates to $0.06 per hour streamed.

¹ https://developers.cloudflare.com/stream/webrtc-beta

² https://blog.cloudflare.com/webrtc-whip-whep-cloudflare-stre...

I used the demo streaming.html code linked above as-is and host it statically on Nginx alongside Janus on a cloud VPS. As far as config, there is just the one file: /etc/janus/janus.plugin.streaming.jcfg , but you can leave it blank and just use the html api¹ if you don't want to mess with that file as the API has an option:

  "permanent":true

¹ https://janus.conf.meetecho.com/docs/streaming#streamapi

I wrote a little helper shell code using wget, openssl, dd, jq, and jo to make it easy to talk JSON to the API, for the one-off configs I do. Here is an example of what I use which demonstrates simulcast and srtp ingestion for both h264 and vp8 video streams as well as opus audio. Just fill in the [ ]'s with your specifics. I then use ffmpeg to generate all the streams and pipe to the appropriate ports for each simulcast level and target. If you use gstreamer beware srtp key format is different.

  #!/bin/sh
  server="https://[YOUR_JANUS_SERVER_HOST]/janus"
  token(){ dd if=/dev/urandom bs=6 count=1 status=none|openssl base64;}
  post_jo(){ first="$1";shift;wget --quiet --output-document - --post-data "$(jo -- "$@")" "$server$first";}
  tx(){ post_jo "$@" transaction="$(token)";}
  data_id(){ jq ".data.id//(null|halt_error(1))";}
  message()( set -e
    id="$(tx / janus=create|data_id)" # create janus session and store id
    hn="$(tx "/$id" janus=attach plugin=janus.plugin.streaming|data_id)" # create plugin session and store id
    tx "/$id/$hn" janus=message body="$(jo -- "$@")"
    tx "/$id" janus=destroy >/dev/null
  )

  # example usage:

  # list all streams
  message request=list|jq .plugindata.data.list

  # remove stream with id 666
  message request=destroy id=666 secret=adminpwd permanent=true|jq 

  # create new stream
  message request=create id=666 secret=adminpwd permanent=true name=[YOUR_STREAM_NAME] type=rtp media=["$(
    jo type=video mid=v1 codec=h264 pt=96 simulcast=true svc=false port=5010 port2=5020 port3=5030 \
      fmtp=level-asymmetry-allowed=1\;packetization-mode=1\;profile-level-id=42c01f
    )","$(
    jo type=video mid=v2 codec=vp8 pt=96 simulcast=true svc=false port=5012 port2=5022 port3=5032
    )","$(
    jo type=audio mid=a codec=opus pt=97 port=5000
    )"] srtpsuite=80 srtpcrypto=zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz|jq # your srtp token needs to match your source

  # show new stream info to verify configuration
  message request=info id=666 secret=adminpwd|jq

  # on streaming source device
  ffmpeg [YOUR_INPUT_CONFIG HERE] -f rtp -srtp_out_suite SRTP_AES128_CM_HMAC_SHA1_80 -srtp_out_params zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz srtp://[YOUR_JANUS_SERVER_HOST]/:[PORT]

  # for gstreamer, showing alternative key format
  gst-launch-1.0 [YOUR_INPUT_CONFIG HERE] ! rtpav1pay ! srtpenc key=cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3 ! udpsink host=[YOUR_JANUS_SERVER_HOST] port=[PORT]

I went to your discourse link. As Lorenzo was trying to say, you will want to get a better idea what is going on with ICE candidate gathering. In firefox there is an about:config setting that might help with this:

  media.peerconnection.ice.obfuscate_host_addresses = false

https://webrtc.github.io/samples/src/content/peerconnection/...

If you do not get any valid candidates, then it is most likely a misconfiguration of your browser, vpn, firewall or network. Unfortunately this is most likely not a Janus thing, but I would need more information to know for sure.

Another library that I would recommend people look into for live streaming to WebRTC, as an alternative to Pion used in this project, is Janus WebRTC Server. I use it for ingesting RTP streams I generate from usb webcams and then playing it with very low latency in the browser. It even has a feature where you can stream multiple streams simultaneously. It also has a simple http api for adding, updating, and removing streams on demand.

Here is the library's streaming demo:

https://janus.conf.meetecho.com/demos/streaming.html

Webtorrent

Use a free signalling server from the webtorrent community. You can skip the torrent part of the implementation and just use the signalling, it's awesome. You can use a libraries like:

https://github.com/webtorrent/bittorrent-tracker

https://github.com/subins2000/p2pt

to get started. For me, I found the protocol is simple enough where I just use small vanilla javascipt implementation to talk to the websocket servers to generate the signalling messages. I wish more people knew about this and realize how easy it can be to bring WebRTC to their applications.

List of some free webtorrent trackers:

  wss://tracker.openwebtorrent.com
  wss://tracker.files.fm:7073
  wss://tracker.webtorrent.dev

Some free stun servers for NAT traversal:

  stun:stun.cloudflare.com
  stun:stun.l.google.com:19302

I am sorry if this comes off to be negative, but with every example provided on the site, when compiled and then fed into ShellCheck¹, generates warnings about non-portable and ambiguous problems with the script. What exactly are we supposed to trust?

¹ https://www.shellcheck.net

You might want to consider adding keyboard shortcuts for the keys 1-4 corresponding to the answer order so that the questions can be answered more quickly on desktop. I also agree with the others as far as spelling variations, maybe you want to include Modern Standard Arabic and potentially other dialect versions as well.

Having owned Dell's 5K for years, last year I finally upgraded to their 8K model. I could never go back to anything less. If you need it and can justify the cost, you will know; but I don't see either being justifiably true for very many people at this point. While higher refresh would be nice, 60Hz is more than adequate for me, as it's the screen real estate that matters, and you really don't have many options to choose from.

I would expect ROCm to work just fine with with Steam Deck. Given that the Steam Deck apparently uses gfx1033. So you probably need to specify the environment variable HSA_OVERRIDE_GFX_VERSION=10.3.0 and corresponding gfx1030_20.ukdb miopen kernel. I do not own a Steam Deck, but I do have another RDNA2 card, an RX 6700XT, which uses the similar gfx1031 ISA, which works just fine. While I don't have a RX 570, I do have a RX 480 which is also gfx803 like your RX 570 which should technically work, however don't expect much in performance or capability, as most work loads expect more than your 4GB of vram and much more compute power. You will also would need to use older versions of ROCm as well as these older cards are deprecated; I think I had to use ROCm <=4.3.1 if I remember correctly. What did you want to run specifically?

Seems that specific benchmark is deprecated. For me, I do get around 15 iterations/second on my 7900xt when running "stabilityai/stable-diffusion-2-1-base" for 512x512. I get around 10 iterations/second when running "stabilityai/sd-x2-latent-upscaler" to upscale a 512x512 to 1024x1024.

Here is a link to a tom's HARDWARE stable diffusion benchmark from January to get a rough idea on where various cards fit in for that use case:

https://www.tomshardware.com/news/stable-diffusion-gpu-bench...

In the article they show a performance comparison chart here:

https://cdn.mos.cms.futurecdn.net/iURJZGwQMZnVBqnocbkqPa-970...

Can confirm, I can run PyTorch with ROCm just fine on 6900xt and 7900xt on Debian. The 7900xt does require the nightly build of PyTorch (for ROCm >=5.5 support, I run 5.6) in order to automatically get the gfx1100_42.ukdb miopen kernel. I must specify which gpu and which miopen kernel when starting python. My device 0 is the 7900xt and device 1 is 6900xt, so for each I run the corresponding commands:

  $ CUDA_VISIBLE_DEVICES=0 HSA_OVERRIDE_GFX_VERSION=11.0.0 python3

  $ CUDA_VISIBLE_DEVICES=1 HSA_OVERRIDE_GFX_VERSION=10.3.0 python3

I think you have gotten to the crux of it, distro package maintainers seem to have not done a particularly good job in many distros when it comes to AMD, but that is hardly AMD's fault as they have done a fairly good job at running their own full binaries repo¹ for various package formats. I also would recommend therefore that you change to AMD's repo as it definitely contains the HIP runtime. It would appear that you just need to add https://repo.radeon.com/rocm/yum/rpm to your package manager for Fedora. For ROCm OpenCL, my only pointer is that you have to make sure that you are adding the dynamic library path, for example:

  $ env LD_LIBRARY_PATH=/opt/rocm-5.4.0/opencl/lib clinfo

¹ https://repo.radeon.com/rocm

When it comes to graph databases, my favorite is still ArangoDB, definitely worth checking out if you are worried and looking for alternatives.

https://www.arangodb.com

While AMD might not have "official" support for their consumer hardware lineup on offerings that have traditionally been a non-consumer area of GPGPU, there is plenty of evidence that it will indeed still work just fine on most of them (once compiled properly and sometimes with the right environment flags); as witnessed by me and even people in the link you reference. I agree that "official" support would be great eventually, but for me as long as it works, that's adequate enough for me on consumer hardware.

What exactly is locked to 6000 series cards? I can't speak specifically to having had any old 500 series, but I was using even more ancient 400 series cards (rx480 from 2016) with ROCm for years up until recently. So I am not sure what what issue you would have with 500 series other than probably being old slow hardware, but I don't see why they wouldn't work otherwise¹.

¹ https://community.amd.com/t5/knowledge-base/amd-rocm-hardwar...

Not sure what you are talking about as far as AMD?

This statement in particular:

"unlike AMD ROCM which requires a custom kernel and closed-source components"

As far as my experience, ROCm does not require a custom kernel nor special kernel modules as it works just fine for me with stock distro kernels, nor does it require closed-source components. OpenCL and OpenGL have pretty much always worked fine for a long time now. I think that AMD drivers are just as good as Intel ones especially when it comes to how open-source they are. While it's cool that Intel already has AV1 encoding on their new cards, I fully expect AMD will have just as good AV1 encoding on their next gen RDNA 3 cards too when they come out soon.

What specifically is your issue with ROCm & HIP that makes it a joke? It has actually worked great for me on both Blender and Pytorch (Stable-Diffusion) with Debian on my 6700XT.

More details in a prior comment: https://news.ycombinator.com/item?id=32908918

Stable Diffusion works fine for me on my RDNA2 gfx1031 ( RX6700 XT ) under Debian. If you are on a Linux kernel with amdgpu, have your distro's latest version of ROCm HIP runtime, and a relatively recent AMD GPU, you just need to replace the default pytorch with the ROCm HIP version.

    # Install your distro's HIP runtime and rocminfo
    $ apt install rocminfo hip-runtime-amd # for debian and derivatives

    # Confirm ROCm is installed properly and confirm your gpu is supported
    $ rocminfo
    ROCk module is loaded
    ...                 
      Name:                    gfx1031                            
      Marketing Name:          AMD Radeon RX 6700 XT  
    ...

    # Must uninstall any non-ROCm torch libs
    $ pip3 uninstall torch torchvision torchaudio

    # Install latest ROCm pytorch, see website for more versions
    $ pip3 install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/rocm5.1.1

    # Required env for unofficially supported newer gpu's like gfx1030 & gfx1031 that give error "hipErrorNoBinaryForGpu", can be added to /etc/environment to make permanent
    $ export HSA_OVERRIDE_GFX_VERSION=10.3.0

    # Test torch HIP is working
    $ python3
    >>> import torch
    >>> torch.cuda.is_available()
    True
    >>> quit()

    # Run Stable Diffusion workloads like normal...

Blender can also take advantage of the installed HIP runtime for render acceleration in the latest versions too once you enable the setting in preferences.

AMD HIP support on Linux now works without proprietary drivers on RDNA2 cards! My 6700xt is great as all I had to do was just install hip-runtime-amd package on Debian from AMD's ROCm repo¹. I am glad they are putting the work into supporting AMD hardware and I no longer have to use opencl and be stuck on older Blender versions.

¹ https://repo.radeon.com/rocm/apt/debian ubuntu main

Per the article, it's $10 per foot² of space leased. So I am guessing that to lease the whole place it would therefore be 7500ft² * $10-per-ft²-per-year / 12 months-per-year = $6250/month .

I have not done an official cyclopentolate on myself as it requires a prescription here, but in the past I believe it's standard practice at my ophthalmologist when I get checkups, but I haven't gone for one in years.

I have been working on doing this since the start of 2020. I purchased glasses for almost all the diopters from .5 to -4.25 (where I started) cheaply on Zenni, by going with minimal add-ons, it makes the total cost per glasses pair between $10 and $30 each. I have customized text on each of the frames that says their correction, since some of my frames are duplicates with different lenses. I am down to about -2.75 so far for normal stuff. I spend most of my day in front of computers so I end up using much lower correction between -1 and -2 diopters for the various screens I sit in front of to maintain the edge of just-in-focus depending on distance. You just have to remember that progress is slow, it took years get this way and will take years to go back. I wish you luck and patience if you try it yourself.

Edward Snowden, who had access to basically all the US governments secrets for NSA and CIA with the highest above top-secret clearance, went specifically looking for stuff related to this and says that he came up with nothing. Out of anyone who could know things about this, I find his situation and argument to be most convincing.

GRUB does this relatively easily (without needing emulation) as I too have done it before on an old tablet. I am not sure what OS you are using but it should work fine for Linux and Windows although only the prior is easy and just works. On Debian and it's derivatives you just need the grub-efi-ia32 package, and then regular GRUB install process and 64bit loads fine without anything special.

Apparently you can officially just shut off the restriction that forces Windows 11 to only run on new CPUs and the newest TPM by just setting a registry key AllowUpgradesWithUnsupportedTPMOrCPU on install.¹ But I never use Windows and don't plan to start anytime soon, so it's not something that I will try.

¹ https://support.microsoft.com/en-us/windows/ways-to-install-...