I assume that the schedule was extremely harsh and QA and devs were raising all of the alarms, but management just told the to ship whatever even if it's alpha or beta quality at best.
I would suspect you need to go further back to the hardware - I bet it's not right and makes it impossibly complex to develop efficient drivers for. It may well be that it's going to take an iteration or two of hardware development until they have something that you can really develop a good driver for. It may also be that management have been told that this gen of hardware is broken, but they can't really bin the whole lot due to pressure from even higher management so they release something as quietly as possible in china in an attempt to keep the higher ups and the share holders happy.I can't believe that I'm saying this - but I don't think that it's correct blaming QA or the devs. I would have to assume that management pushed the dev and QA teams to release a full list of features no matter what, and that's what they did. I assume that the schedule was extremely harsh and QA and devs were raising all of the alarms, but management just told the to ship whatever even if it's alpha or beta quality at best.
There's no way the devs/QA don't know the state of what they were releasing - it has to be the management that's telling them to ship whatever no matter what.
I would suspect you need to go further back to the hardware - I bet it's not right and makes it impossibly complex to develop efficient drivers for. It may well be that it's going to take an iteration or two of hardware development until they have something that you can really develop a good driver for. It may also be that management have been told that this gen of hardware is broken, but they can't really bin the whole lot due to pressure from even higher management so they release something as quietly as possible in china in an attempt to keep the higher ups and the share holders happy.
If the hardware is tough to code drivers for then it will be take longer to write the drivers and make it tricker to make the card reliably fast. Being as they had to release the card, and it has to have good performance (as that more then anything is what reviews look at) then reliability is going to suffer.It's not really about efficiency at this point. It's a buggy mess, even in the UI. The hardware really isn't what's driving UI bugs.
If the hardware is tough to code drivers for then it will be take longer to write the drivers and make it tricker to make the card reliably fast. Being as they had to release the card, and it has to have good performance (as that more then anything is what reviews look at) then reliability is going to suffer.
Give the lone poor guy at Intel a break who is doing the UI for ALL their software products. Priorities. ARC comes last.This has nothing to do with UI bugs. I specifically pointed out UI bugs...
@HurleyBird and @Stuka87 Your mission, should you choose to accept it, is to infilitrate the GPU divison of Intel, stay there as long as you can bear and report from the trenches on what the hell exactly is going on there? We salute you for your service!
As an aside, I wonder if driver development and QA is being done outside of North America.
Yeah everything in there but not polished. Giving the team mandates that "everything MUST be ready" which leads to everything half-baked due to time constraints.So instead of a base feature set that worked well, they now have a full feature set that is entirely unusable.
And imagine that some promised feature still didn't work with that final tape-out and the driver team had spend ages writing for that feature while it was talked about and had poured resources into trying to simulate that feature(s). While a moving target is sort of to be expected, we have no how idea at what rate the target was moving and whether it could take evasive actions by also become a backward moving target!If we suppose that final silicon was handed over to Lisa on the date of this tweet, it would be a miracle for her team to deliver something as robust as the AMD/Nvidia drivers who've been at it for years.
@HurleyBird and @Stuka87 Your mission, should you choose to accept it, is to infilitrate the GPU divison of Intel, stay there as long as you can bear and report from the trenches on what the hell exactly is going on there? We salute you for your service!
Give the lone poor guy at Intel a break who is doing the UI for ALL their software products. Priorities. ARC comes last.
Intel has had a decade, a DECADE+, to establish a solid framework for a graphics driver User Interface (from their work on iGPU drivers and ui). They even have something marginally workable for their latest iGPU drivers and the Xe iGPU already that they could have easily built off of and it appears that they are further messing that up.
I would actually love to go in there and replace whoever is currently managing it. I enjoy challenges like that.
I also agree with GN on this, they should have stuck to simple geometry / rasterizing. Adding in all the features like SmoothSync, Xess, ray tracing and so on was dumb. I'd guess that 95% of people don't know what those are and don't care about them, nor even use AMD/Nvidia variations. I don't - I don't even bother to try to keep up all the new acronyms and what they mean, and haven't for the past decade. I just use the damn thing and it works.
Lot of blame being sent Lisa's way in some posts here.
But with what looks like the timelines involved, they gave Lisa mission impossible. She never had even a ghost of a chance.
Given that the ARC cards are not heavy performers, I would imagine that having xeSS might be a worthwhile endeavor. It's why I like GSync and DLSS on laptops as they are generally weaker than their desktop counterparts and not easy to upgrade. Features that can effectively boost the performance can allow these machines to be usable for longer than you would've normally seen.
I could imagine it being more frustrating than fun. The biggest problem that I could imagine running into is that you know how to fix the problem, but due to some red tape (company processes, upper management meddling, etc.), you simply cannot fix it or it takes an inordinate amount of time to do so.
I can't believe that I'm saying this - but I don't think that it's correct blaming QA or the devs. I would have to assume that management pushed the dev and QA teams to release a full list of features no matter what, and that's what they did. I assume that the schedule was extremely harsh and QA and devs were raising all of the alarms, but management just told the to ship whatever even if it's alpha or beta quality at best.
There's no way the devs/QA don't know the state of what they were releasing - it has to be the management that's telling them to ship whatever no matter what.
BUT BUT BUT Raja's powerpoint slides pitching this GPU to the management included all of these. Not doing them all would make him look untruthful. He's a very honorable person. He delivered. He didn't say in the slides that he would also take care of the drivers.I also agree with GN on this, they should have stuck to simple geometry / rasterizing. Adding in all the features like SmoothSync, Xess, ray tracing and so on was dumb.
Could be the same problem that Microsoft had (and maybe still has?): Testers aren't given enough respect by developers coz if they were that talented, they would be developers. Similarly, maybe inside Intel, a software engineer ranks a lot lower than a hardware or silicon engineer, thus the management isn't as focused on hiring rockstar software engineers/developers.But there appears to clearly be some issues in their SDLC. Its possible the team just isn't managed well, and is spread around in different countries. Or maybe its just a very inexperienced team. Which ever it is, it really needs some clean up.