Announcement

Collapse
No announcement yet.

Intel Arc Graphics A770 Launching 12 October For $329 USD

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pong
    replied
    It has been too long since I've looked at the low level documentation for NVIDIA/AMD but for instance IIRC NVIDIA documents their PTX "assembly" which is sort of a close to hardware reality but maybe is still a pseudo-code semi-intermediate representation (??) and in other CUDA / performance tuning documents they mention the cycle count / latency etc. of various arithmetic, logical, shift, memory access instructions. So I assume among those are the actual FP32, FP64 instructions. Aren't they something close to IEEE-754 compliant?
    So I assume Intel should have such instruction level compatibility documents and also performance tuning / cycle cost documents if the architecture of the Xe-HPG stuff is really open for development.

    Nvidia CUDA you can run standard C/C++ code on the GPU without any significant exceptions as I recall from the baseline C/C++ standards.
    So I'd certainly hope with DPC++ or whatever you can write code using "float", "double" and have it "just work" moderately efficiently using only the GPU resources even if a factor of N slower in FP64 mode than FP32 mode.

    I really can't understand how anyone considers FP64 or better something that is sane to have be "optional" in this decade. Yeah ok maybe most of the critical uses of it are in engineering / scientific computing but I think also graphics / modeling etc. is very relevant. Just like uint64, int64 has become the baseline data type for modern 64-bit processors, so should FP64 / "double" be the default lingua franca FP type for cases where one doesn't HAVE to save every last bit of memory and execution time when processing billions of operations / variables and one doesn't want to have to worry so much about whether one is going to get trash results from overflow / underflow / rounding etc. just like it's pretty easy to overflow I32, so FP32 isn't really great for either int or precision over moderate dynamic ranges.

    Leave a comment:


  • coder
    replied
    Originally posted by gsrcrxsi View Post
    i would like to see this independently tested/verified. Forum moderators don’t necessarily have the most correct or up to date information. The Tom’s hardware and referenced Intel forum post are the only source for this so far. I’m skeptical of the accuracy until independently tested.
    I hope you're right, but I fear you're not.

    Their product brief for the datacenter GPUs, based on the same chips, conspicuously omits any specification of fp64 performance:



    Also, their Hot Chips slide deck, from 2020, ominously shows the fp64 block as optional.



    Intel had a 3rd GPU product line, which they cancelled in summer of 2021, that was to be datacenter-focused (I think what they were calling XeHP). Instead, they opted to repurpose their consumer GPU chips (XeHPG​), for that market segment. Perhaps it was the former, which actually had the fp64 it the Xe EUs.
    Last edited by coder; 06 October 2022, 09:50 AM.

    Leave a comment:


  • gsrcrxsi
    replied
    Originally posted by coder View Post
    Well, it looks like DarkFoss was right:



    That sucks. I guess if you need lots of fp64, your best bet would be a used Radeon VII -- or better yet, a Radeon Pro VII.

    Once upon a time, this was really a stand-out feature of Intel iGPUs. From Gen7 to Gen9, their iGPUs actually had a 4:1 fp32:fp64 ratio. That actually made the GT4 Iris Pro graphics, found in some Skylake laptop CPUs, the fastest fp64 consumer product on the market, between when the GTX Titan Black (Kepler) was discontinued and Radeon VII launched.

    Wow. Now I feel betrayed. It'd be understandable if they wanted to just implement it at just like 32:1 or 64:1, but emulated performance is going to be garbage.

    And I don't buy for a minute that it takes too many gates. We've had hardware fp80 in Intel FPUs since the 8087. The throughput and latency weren't good, but they used so few transistors you could almost write out the schematics by hand. There's certainly some compromise they could've struck that would've used negligible die area while still providing a lot better performance than emulation.
    i would like to see this independently tested/verified. Forum moderators don’t necessarily have the most correct or up to date information. The Tom’s hardware and referenced Intel forum post are the only source for this so far. I’m skeptical of the accuracy until independently tested.

    Leave a comment:


  • coder
    replied
    Originally posted by smitty3268 View Post
    Intel's recent iGPUs only support it via soft-fp64 support in shaders. No idea about ARC, though. I suppose it's likely native.
    Well, it looks like DarkFoss was right:



    That sucks. I guess if you need lots of fp64, your best bet would be a used Radeon VII -- or better yet, a Radeon Pro VII.

    Once upon a time, this was really a stand-out feature of Intel iGPUs. From Gen7 to Gen9, their iGPUs actually had a 4:1 fp32:fp64 ratio. That actually made the GT4 Iris Pro graphics, found in some Skylake laptop CPUs, the fastest fp64 consumer product on the market, between when the GTX Titan Black (Kepler) was discontinued and Radeon VII launched.

    Wow. Now I feel betrayed. It'd be understandable if they wanted to just implement it at just like 32:1 or 64:1, but emulated performance is going to be garbage.

    And I don't buy for a minute that it takes too many gates. We've had hardware fp80 in Intel FPUs since the 8087. The throughput and latency weren't good, but they used so few transistors you could almost write out the schematics by hand. There's certainly some compromise they could've struck that would've used negligible die area while still providing a lot better performance than emulation.
    Last edited by coder; 30 September 2022, 02:34 AM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by coder View Post
    There literally must be at least some. You can't support APIs like OpenGL 4.x or DX11 without it!

    According to TechPowerup, it'll have 1:4 (fp64:fp32), which means 4.3 TFLOPS peak. They don't cite a source on that. I'll update, if I find one.

    Intel's recent iGPUs only support it via soft-fp64 support in shaders. No idea about ARC, though. I suppose it's likely native.

    Leave a comment:


  • coder
    replied
    Originally posted by DarkFoss View Post
    Too bad there is no FP64 on the Arc cards. It makes them useless for [email protected]
    There literally must be at least some. You can't support APIs like OpenGL 4.x or DX11 without it!

    According to TechPowerup, it'll have 1:4 (fp64:fp32), which means 4.3 TFLOPS peak. They don't cite a source on that. I'll update, if I find one.

    Leave a comment:


  • coder
    replied
    Originally posted by Mahboi View Post
    Will they actually respect the date? Will they have load or just a paper launch again?
    Rumors indicate that card makers have been sitting on piles of inventory for a while, so I don't expect availability to be a problem.

    Leave a comment:


  • coder
    replied
    Originally posted by rogerx View Post
    Find it really odd EVGA, as supposedly as successful as EVGA is, is supposedly exiting the GPU market. Maybe just more hype?
    No, it's real. They've announced there will be no RTX 4000 cards, nor any more GPU cards for chips from any chip maker. They're completely exiting the GPU business.

    Originally posted by rogerx View Post
    What would be even funnier, if EVGA is just dumping nVidia for Intel GPU's.
    A couple months ago, I saw a rumor that a couple GPU makers canceled their Intel GPU product lines. Maybe EVGA was one of them.

    Leave a comment:


  • coder
    replied
    Originally posted by zexelon View Post
    I am also curios to see how the Intel A770 handles GPU compute loads and if they can cobble together anything close to CUDA. At least ROCm is starting to look like something these days!
    Yes, we need to see some GPU Compute benchmarks on these, from Michael. The few OpenCL benchmarks he has should give us a rough apples-to-apples comparison across the 3 vendors, but I hope he'll also have some oneAPI vs. CUDA benchmarks, in the mix.

    Leave a comment:


  • coder
    replied
    Originally posted by gustavoar View Post
    I'm skeptical of buying if the platform might be dead in a year or so. So I'd wait for the 2nd or 3rd generation to jump in, don't want to be like HDDVD or Betamax.
    Intel is has publicly said it's committed to executing on its roadmap, which means at least one more generation of performance-oriented gaming cards. However, I guess if enough people are taken in by the viscous rumors and speculation, it might ultimately turn out to be a self-fulfilling prophesy.

    I'm not too worried about the prospect of cancellation, for three reasons:
    1. Intel's iGPU are moving onto their own tile, which means they should scale up further and should increasingly resemble the dGPUs (aside from dedicated memory... for now). The more similar they are, the more driver fixes & enhancements the dGPU products would automatically inherit from the ongoing tGPU support.
    2. Intel sells professional & datacenter GPU products with a 5 year availability window, which basically means 5 years of software support.
    3. Intel's software stack is in-tree and open source. This has enabled strong ongoing support for the legacy Radeon products, for example.

    So, I'll see how RDNA 3 lands, but my current expectation is that my next dGPU purchase will be Intel.

    Originally posted by Mike Frett View Post
    If Intel is already considering cancelling this GPU endeavour, I'm not going to buy something that will have support ended in a year.
    ​Nope. At this stage, that's just FUD. The internet does have a track record of wishing things into existence (or "manifesting" as I think the kids are calling it), so I guess nobody can say for sure.
    Last edited by coder; 29 September 2022, 11:36 AM.

    Leave a comment:

Working...
X