Intel Arc Graphics A580 On Linux: Open-Source Graphics For Under $200

[pong]

You're right, I miss the sub-$200 GPUs that were usable for a lot of productivity / casual graphical performance / video acceleration / compute / multi-monitor driving applications. Particularly ones that are single PCIE slot or even could run well as eGPUs / over TB / USB4 / whatever.

I've still got use cases where there's no IGPU on motherboards I may want to use but where I may want to use the main DGPU for pass-through so I'd like an inexpensive USB or 1-slot PCIE DGPU for the system monitors, or use cases where I want to use a motherboard with an IGPU for the OS and a basic but capable DGPU for pass-through, or use the main DGPU for the host and pass through the basic GPU for some productivity app.

Re: ARC/SD --

https://vladmandic.github.io/sd-extension-system-info/pages/benchmark.html

https://github.com/vladmandic/automa...scussions/2024

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki

...

Granted I'm not an expert on intel ARC / NV GPU SD though I've read a bit and experimented a bit.

But IIRC the last I heard "they" (Intel / OpenVino / Pytorch / ..., comfyUI, automatic1111 sd-webui, vladmandic's sd.next significantly improved / diverged fork of the automatic1111 sd-webui, (et. al.), and even intel's evolving GIMP 3.x SD plug in) ALL have variously functional / capable / integrated support for ARC GPU use in SD that worked AFAICT pretty well & simply in the couple of those cases I've tried personally.

i.e. the end user set-up / configuration experience for using SD + ARC via those programs / UIs was roughly more or less comparable to what they'd have to do with NVIDIA on those software applications and the resulting performance was reasonable enough that it could be considered to be competitive with some NVIDIA (3050, 3060, ~3070) cards as well as various AMD GPUs (which I gather are problematic for SD use though I've not read much about the details or tried it).

If your point is that say a NV 4090 or NV 4080 or NV 3090 or NV 3080 will be compellingly faster / smoother / easier to use / more capable for basically all SD software applications, of course, you're right.

But for let's say non-demanding "casual" "budget" level GPUs and uses I'd look at whether say an A770-16G would be useful compared to say NV 3070/3060/3050 models given that
the A770-16 is available with significantly more VRAM than those NV models (which can be very advantageous) and has decent VRAM BW (in comparison, and this is important for SD) and at least useful performance and SW UI support at this point for a price / performance ratio that may be OK if one isn't going to just go buy a 4080/4090 or something much more expensive and much more performant.

IDK why anyone much interested in SD might want to buy any GPU without more than 8GBY VRAM but for video encoding / decoding, productivity applications, basic / casual gaming or other real time 3D applications, pass-through, etc. I can see good use cases for the lower cost A3, A5 models given their lower costs.

I've definitely been missing the sub-$200 GPU market. The 4G VRAM that Nvidia and AMD offer isn't cutting it. I'm just not interested in paying hundreds of dollars for a GPU that I use to pay ~150 for just a few years ago. I guess everyone has amnesia but you could buy a really good ~150 GPU just a few years ago that would run most of the new games. Of course now, I'm more interested in Stable Diffusion and these 4GB VRAM offerings are pathetic. Unfortunately, Intel is pretty much a no-go for SD.

[Anux]

This is why there is ... no such thing as HRE, hypothetical reference encoder.

Nitpicking continued: https://aomedia.org/av1-features/get-started/

AV1 Reference Codebase

[sophisticles]

Nitpicking continued: https://aomedia.org/av1-features/get-started/

Where exactly do you see any mention of a reference encoder?

Since you are probably not aware, the AOM has adopted Intel's SVT-AV1:

https://gitlab.com/AOMediaCodec/SVT-AV1

https://aomedia.org/press%20releases/aomedia-software-implementation-working-group-to-bring-av1-to-more-video-platforms/

So if you are implying that AOM has a reference encoder and AOM has adopted SVT-AV1 as the AV1 encoder of choice, then that means that Intel's SVT-AV1 must be the official AV1 reference encoder.

For the record, i like SVT-AV1 very much, over at the videohelp forums after one of my encoding tests i stated that SVT-AV1 was the best encoder currently available,

I have not had a change to thoroughly test VVC encoders, but hope to soon.

[Anux]

Where exactly do you see any mention of a reference encoder?

AV1 Reference Codebase

in my Link. You can also read about it on Wikipedia. Any codec that gets developed has a reference codec, else it couldn't be tested/developed.

[Quackdoc]

You get an open source compute stack at a price lower than AMD (correct me if I'm wrong). nVidia doesn't offer an open-source compute stack at all.

But I didn't check any of that, can someone post here what's the open-source support by each vendor for oneAPI / ROCm / CUDA / OpenCL. Crippled stacks (i.e. sans reclocking) do not count.

ah, I mean, I just feel like the pricing is too close to even their own cards one performance stack up.

[pong]

You get an open source compute stack at a price lower than AMD (correct me if I'm wrong). nVidia doesn't offer an open-source compute stack at all.

But I didn't check any of that, can someone post here what's the open-source support by each vendor for oneAPI / ROCm / CUDA / OpenCL. Crippled stacks (i.e. sans reclocking) do not count.

Intel's open source / documentation is obviously much better than NVIDIA's open source / documentation though in a way it's ironic to mention crippled by lack of reclocking in that that's sort-of a problem for both intel (with the i915 / oss driver / oss intel linux support code) and nvidia (with nouveau).

In nvidia+nouveau's case I guess the clocks are just the default boot clocks and are not able to scale to achieve the full potential of the GPU, whereas with nvidia+nvidia driver there are OSS and nvidia OEM clock / settings / temperature / power control & monitoring & power management related controls / programs / settings utilities.

In intel's case with their OSS (and AFAIK any other) code / documentation the intel DGPU clocks / performance level does scale from "low" default performance to maximum performance automatically so one can get full performance from the DG2 DGPUs with the i915 driver, but there seems to be no / very incomplete support for "energy efficiency at near idle and low utilization" controls so the ASPM BIOS setup intel commends people to use to reduce the GPU "low load" power doesn't seem to do anything functional under LINUX. And unlike NVIDIA's non-OSS stack, there's no open / documented (AFAICT) way to monitor or control fans, clocks, settings, temperatures, power limits, power management for the intel DG2 DGPUs under LINUX besides one total energy monitor report anyway.

So nouveau has no settings / reclocking. NVIDIA non-OSS has moderately capable clock / fan / power / temperature / PM support.
And Intel has no clock / fan / power management / temperature control / monitoring support other than "letting" the GPU's performance ramp up
between 20% and 100% of power consumption from "idle" to full load or whatever but doesn't at all respond to monitors going to "off" state, unplugged monitors,
etc. to get the GPU idle power consumption under ~40W for their A770 and something proportional to that for the lesser ones.

[pong]

Indeed yes the Intel stack has openCL as well as SYCL / DPC++ and other oneAPI / oneDNN / openVINO etc. etc. support.

CUDA is quite nice all considering particularly for its age and ubiquity over their recent generations of product lines.

OTOH the articles here lately suggest that there's movement to get support integrated into LLVM for OpenAMP, SYCL, et. al.
nvidia's PTX ISA is roughly stable but evolves new generational features and is easy enough to target by an IR / code generator.
I believe the same is / could be so for intel DG2 ISA and amd RDNAx ISA.

And even nvidia's own application notes suggest HPC people with codes to accelerate DON'T (have to) start with CUDA but
rather start out looking at standardized C++ / fortran parallel constructs, the vendor neutral OpenMP specification's decorations,
OpenACC, and also their canned performance primitives, canned libraries for BLAS, FFT, whatever else.

One can do similarly with other GPUs, use standard parallel language constructs that can target CPU or GPU MT / SIMD first, then
look at say OpenMP, OpenACC then consider in what small "hot" areas for performance it's even relevant to optimize further to
go down to more significantly platform specific (CUDA / ROCm / SYCL / OneAPI / GPU ISA ) things.

So hopefully we'll be entering a better more vendor neutral time where we can more and more just specify some kind of vectorization /
parallelism / threading in a generic way in code and have LLVM or whatever target that to RISC/x64 CPUs, AMD/NV/INTEL GPUs,
different CL implementations whether based indirectly on vulkan / DX, or GPU ISAs.

I've lost track entirely of what stack elements can play with which others to know if POCL or RUSTICL or what not could actually work on
nouveau these days but I imagine it'll get there.

I'd have likely already bought an AMD GPU were it not for horror stories about generationally delayed / skipped ROCm support and so on,
so now I use NVIDIA + ARC and we'll see if / when another AMD joins the party after my 9800s from ~2008.

In that case, I would say that Intel OSS compute stack is better than nVidia Nouveau OSS, but not as good as AMD OSS compute.

Also, in nVidia Nouveau OSS, there is no support for CUDA, so I guess OpenCL only? Or not even OpenCL? AMD OSS and Intel OSS support OpenCL API + oneAPI / ROCm API.

And in AMD OSS case, the OpenCL + ROCm support is officially only for RDNA3 + some RDNA2 cards.