Reply 20 of 127, by Deunan
bitplanes allow you to cleverly arrange your palette so that setting a single bit can act as a transparency effect for example.
OK, so there is _one_ scenario where having individual bit per every pixel is useful. Except not on any PC cards from that era. But other than that, what other uses are there? I'm serious, give me some examples where setting just one bit of out N that a pixel has would be such a huge win that you'd want them on a separate planes. Screen clearing or redrawing requires, on average, full flush of the pixel color anyway. It gets even worse if you have to draw something that is not aligned to 8 pixels, then you still end up with read-modify-write. The whole VGA pixel enigne was basically meant to overcome this stupid idea with even more complicated HW solution.
Everyone usually comes up with "Amiga did it" - well, sure, and it flopped once SVGAs finally moved to banked 256+ color modes. FM Towns was basically a gaming machine made in '89 and it had graphics modes that more-or-less matched the VGA, except with 256 (640x480) and 32k (320x240) color modes. It also had 16-color modes where every byte was 2 pixels. And a sprite engine. Nothing about this is weird or difficult to use - clearly, someone sat and though "If I wanted to make a fast DMA blit to VRAM, how should the pixels be packed?".
I actually need to pull the display port cable loose, then power-cycle the PC, and then plug it back in once the PC is booting, else the video simply won't come on anymore.
I don't think that's a driver issue. Possibly HW one. I've noticed that the 2200G APU that my parents have now sometimes will go to sleep and then will not wake up with a picture. I have to disconnect and reconnect the video cable (I can hear Windows sounds for device lost/device found as I do that) to get the monitor to show something again.
But, it's an old LCD that is now using DP to VGA adapter. I've never had this issue with a modern monitor that has native DP input. So I think there's something wrong with how the iGPU detects the active output and I suspect it's not the software that's the problem. AMD has been re-using the same output blocks in all their GCN series (or even earlier than that) and possibly there is a glitch there somewhere.
It had a combined AMD and Intel graphics setup, and it rarely worked when I plugged in a VGA or HDMI cable for a beamer. Never had that problem with combined NV and Intel laptops.
Lucky you. There's no shortage of NV Optimus issues on laptops but I don't have one and can't bring up any first-hand experience. Though I have to say, I've never seen a laptop with Intel+AMD combo that I'd pick over Intel-only or AMD-only. Maybe that recent thing that Intel did, with AMD GPU and VRAM on interposer, would actually work and not be gimped somehow by thermals or stupid design decision on the laptop manufacturer's part. But I haven't used that either so can't comment.
What I can say is I've seen a lot of very happy AMD Zen APU users. It's like the perfect gaming machine for people who can't afford a modern console but need a PC for the kids anyway. Again, it "just works".
Which made me wonder how you would ever get both these cards working in the same system.
You don't - and that's not just AMD thing. You can't really use 2 (or more) cards with different GPU family chips. But the way I see it you've learned an important lesson - do not use OpenGL and there's no problem.
AMD also sucks at DirectX 11. They simply didn't even bother to implement the multithreading model at all.
That's a huge misconception. DX11 was never meant to be threaded - you can tell just by looking at the API calls. They have to come from the same thread, period. It's a bit complicated but the long story short it boils down to having API that is thread-safe, or fast. DX11 was meant to be fast, and not do any unnecessary sanity checks in runtime. The cost of that is there are cases where you can't tell what thread submitted what - because of how Windows driver model, and process isolation in general, was designed.
There is one particular case where you can build a list of commands and submit that, and the building can be done in separate thread (submission must still be tied to the thread that owns all DX11 objects). But there are some serious limits to what this method can do. It works reall well for NV who does a lot of pre-rendering things driver-side (tile binning, early out-of-bound checks, etc). AMD however relies on HW doing all that stuff and for them the requirement is you have to submit all the stuff as early as you can so that GPU can start working on it right away and not choke. That's great for computations but doesn't fit DX11 rendering pipeline well. They sort-of brute-force this in other words. There's a reason why consoles use mostly compute for actual rendering, and why such game engines on PC (new Doom for example) work so well on AMD.
TL;DR: It's not really driver limitation on AMD side but the result of having a compute-oriented architecture doing rendering via API that's not designed for it. As for why AMD has just one arch for everything rather than 2 (compute and gaming) like NV does, it's a huge topic that's mostly finance and economies-of-scale related.