Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xbox Architecture

copetti.org

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Xbox Architecture

#71

Post by elcomet »

TeaDude wrote: post #45

I know nothing about the actual underlying architecture but from the (credible) sources I've heard from apparently it's a really nice API hiding an absolutely unholy mess and that's why emulation has been so poor for so long.

If the API is nice, shouldn't the emulation be easy ? Since the emulator doesn't have to care about security / hacks.

Or do you mean that the API only nice in theory, but is actually not nice in practice (lot of undocumented corner cases, or bugs, that games might rely on) ?

Re: Xbox Architecture

#72

Post by Narishma »

vvanders wrote: post #56
phire wrote: post #18

Earlier quoted context omitted.

The xbox (like many consoles, n64, gamecube, xbox360, wii, wii u, xbox one, ps4, switch ps5, XSX) has unified memory, as in the CPU and GPU share the same sdram. The only way to do this is to have one chip (It's always the GPU. The GPU needs more memory bandwidth) connected directly to the dram, and the second chip (CPU) has to send memory requests to the second chip. Though, this console dates to a time when CPUs di…

One notable exception from that list is the PS3. That thing was a real bastard to write for but if you managed to vectorize things properly it did really go at a good clip. One fun thing was optimizing for the SPUs meant that your code was really cache coherent and usually saw significant gains on all platforms. Of course most people at that time wrote for PC+360 first and entered a world of pain when PS3 came along.…

> cache coherent

What do you mean by this?

Re: Xbox Architecture

#73

Post by TeaDude »

elcomet wrote: post #71
TeaDude wrote: post #45

I know nothing about the actual underlying architecture but from the (credible) sources I've heard from apparently it's a really nice API hiding an absolutely unholy mess and that's why emulation has been so poor for so long.

If the API is nice, shouldn't the emulation be easy ? Since the emulator doesn't have to care about security / hacks. Or do you mean that the API only nice in theory, but is actually not nice in practice (lot of undocumented corner cases, or bugs, that games might rely on) ?

I have no idea about the specifics but from what I've heard developers really liked the XBOX (despite it's unholy internals) so I'd say the API was actually nice.

As for HLE based on the API it's definitely possible but there's probably tons of nasty corner cases and that's my theory on why it's never been done. That and the chance of games with their own proprietary APIs existing and thus they won't work with that solution.

Re: Xbox Architecture

#74

Post by cogman10 »

dfox wrote: post #61
phire wrote: post #36

Earlier quoted context omitted.

Infinity fabric isn't serial. Wikichip [1] says there are two versions of infinity fabric (which is a super-set of HyperTransport), one optimised for on-package communication that is 32 bits wide, and one optimised for inter-socket communication that is 16bits wide. I'm not a hardware person, just a software person who dabbles in hardware, so I don't know if the term "SerDes" strongly implies serial and AMD have misu…

Probably all modern fast interconnects work by interleaving some kind of "physical frames" (often bytes with some 8B10B encoding) across multiple distinct serial links that are synchronized as if these frames were bits of parallel interface. The primary reason for this design is that at current frequencies it is essentially impossible to manufacture the physical parallel interface with equal-enough wire lengths. Inte…

> the interface is still mostly parallel

Really? That's crazy! I thought DDR was serial connections. In fact, I thought parallel connections had mostly gone the way of the dodo. Serial is just so much less complicated.

Re: Xbox Architecture

#75

Post by fulafel »

rasz wrote: post #70
fulafel wrote: post #58

Earlier quoted context omitted.

Why would it be impossible to have >1 chip access the SDRAM? Like Amiga did. Especially if the GPU already had custom silicon for it. Whether it would be good engineering (cost, time to market, risks) is of course another issue.

Amiga worked exactly the same way. All memory access to the so called "Chip" ram had to go thru Agnus. CPU address lines didnt touch ram chips directly. CPU was just a passenger riding on the back of powerful GPU. https://www.pmsoft.nl/amiga/A500-block-diagram.jpg

Notice the data bus is shared but the address bus is not in the pic. So there was arbitration by Agnus but the data didn't go through it.

Re: Xbox Architecture

#76

Post by fulafel »

zozbot234 wrote: post #67
fulafel wrote: post #58

Earlier quoted context omitted.

Why would it be impossible to have >1 chip access the SDRAM? Like Amiga did. Especially if the GPU already had custom silicon for it. Whether it would be good engineering (cost, time to market, risks) is of course another issue.

The Amiga "chip" memory was actually quite slow to use, precisely due to it being accessed by both the CPU and chipset - the solution was to add "fast", CPU-only RAM. The address space was unified between "chip" and "fast" memory, but the underlying hardware arrangement was different.

The chip mem slowness only came in the later Amiga models with faster CPUs with 32 bit memory buses I think? Part of the constant trend of custom chipset falling behind, after the first machine. (With a few increasingly laggard refreshes)

Re: Xbox Architecture

#77

Post by rasz »

fulafel wrote: post #75
rasz wrote: post #70

Earlier quoted context omitted.

Amiga worked exactly the same way. All memory access to the so called "Chip" ram had to go thru Agnus. CPU address lines didnt touch ram chips directly. CPU was just a passenger riding on the back of powerful GPU. https://www.pmsoft.nl/amiga/A500-block-diagram.jpg

Notice the data bus is shared but the address bus is not in the pic. So there was arbitration by Agnus but the data didn't go through it.

Low level implementation detail. Agnus is the memory controller here, handling refresh and addressing. Block diagram tristate latch (74LS244 & 74LS373 in real hardware) should be considered part of the chipset (controlled by Gary). Take away Agnus(or even Gary) and CPU cant do anything, cant really say there is any ">1 chip access the SDRAM" here. We would have to go back all the way to C64 to say cpu and graphic chip share same sdram bus ~equally.

Re: Xbox Architecture

#78

Post by noisem4ker »

easde wrote: post #16
saagarjha wrote: post #8

I'm just looking at the motherboard layout at the very top of the article, and it's really strange to my non-expert eyes. The CPU is off to one side, and the GPU is the thing in the middle. And the SDRAM is all split up and far away from the CPU! Is this some sort of game-console specific thing?

The architecture here is similar to old PCs (roughly before 2010) that had integrated graphics in the northbridge. The memory controller also resides in the northbridge. The CPU communicates with the northbridge through the front-side bus. Incidentally the northbridge also used to be responsible for high-speed I/O such as PCIe, so even if you had a discrete GPU it would not be connected directly to the CPU. Over time…

>high-speed I/O such as PCIe

Back in the years we're talking about, that would be AGP (https://en.m.wikipedia.org/wiki/Accelerated_Graphics_Port).

Post reply on HN