So, why are we calling it "10Gbps-TB1"?
 
Notifications
Clear all

So, why are we calling it "10Gbps-TB1"?  

 of  2
  RSS

joevt
(@joevt)
Noble Member
Joined: 3 years ago
 
Posted by: goalque

So are you saying that when the eGPU is just displaying desktop graphics, and I am not transferring any data, the 22Gbps PCIe data part stays mostly untouched because of the DP data/PCIe data separation?

Yes. It's the same situation where you move a graphics card from the CPU slot to a PCH slot. You can still get full performance from an NVMe device that is also in a PCH slot. A PCH slot is limited by the DMI link which is similar to PCIe 3.0 x4 or an NVMe slot.

Posted by: goalque

In the above situation (2), if we connect two 4K displays (DP) to the eGPU, would the remaining H2D PCIe data bandwidth be 8Gbps (40Gbps - 2 x 16Gbps) and the D2H PCIe data part (22Gbps) would not be affected?

No. Multiple display connections to an eGPU just means bigger screen real-estate and does not increase PCIe traffic much or at all so the bandwidth remains unchanged. The Thunderbolt controller has no idea how many displays are connected to the eGPU and therefore cannot adjust itself with that information. DisplayPort traffic is not sent over Thunderbolt unless a DisplayPort device is connected to a Thunderbolt port in the chain of devices. A DisplayPort device connected to an eGPU (graphics card) is not connected to the Thunderbolt. An eGPU box might have another Thunderbolt port (I think Intel frowns on that). A DisplayPort device connected to that port would affect PCIe bandwidth if the DisplayPort traffic exceeds 18 Gbps since Thunderbolt allows up to 22 Gbps for PCIe bandwidth.

Posted by: goalque

For some reason, Startech document states 8Gbps as "download" whereas Intel graph indicates H2D direction (upload).

https://thunderbolttechnology.net/sites/default/files/Thunderbolt3_TechBrief_FINAL.pdf

Yes, it's confusing if you don't define your source and destination when using terms like download and upload and receive and transmit, etc. I think H2D and D2H are more descriptive, but you may need to define the host and device to be absolutely clear.

Posted by: goalque

Intel says that "Two links of (4 lane) DisplayPort 1.2 consume 2x (4 x 5.4 Gbps) or 43.2 Gbps", so one DP 1.2 has up to 21.6Gbps bandwidth but the actual video data rate @60Hz [4K 30bpp] is 16Gbps (as you mentioned).

https://www.amd.com/Documents/50279_AMD_FirePro_DisplayPort_1-2_WP.pdf

DisplayPort uses 10 bits per 8 bit symbol (similar to PCIe 1.0 and PCIe 2.0), so that 21.6Gbps is actually 17.28Gbps (20% drop). PCIe 3.0 uses 130 bits per sixteen 8 bit symbols (128 bits) (1.5% drop). DisplayPort sends "stuffing symbols" during the horizontal and blanking areas as well as between pixels to fill the 17.28 Gbps bandwidth (or whatever the main link is using - 1, 2, or 4 lanes at RBR:1.62, HBR:2.7, HBR2:5.4, HBR3:8.1 Gbps). When transmitted as Thunderbolt, the Thunderbolt controller excludes all the stuffing symbols giving more room for PCIe 3.0 traffic. The receiving Thunderbolt controller will add stuffing symbols for DisplayPort output. The 16Gbps for 4K and 22 Gbps for 5K given in Thunderbolt3_TechBrief_FINAL.pdf shows that the vertical and horizontal blanking pixels are excluded from the used video bandwidth.

For example:

4096 * 2180 pixels/frame * 30 bits/pixel * 60 frames/second = 15.9 Gbps for DisplayPort over Thunderbolt.

If you add the horizontal and vertical blanking pixels (which are transported over DisplayPort as mostly stuffing symbols plus maybe a stream attribute packet containing the image height, width, etc. of the main video stream) then:

4256 * 2222 * 30 * 60 = 17.02 Gbps for DisplayPort, the rest of the 17.28 Gbps is filled with stuffing symbols.

Or you could use the pixel clock:

567.31 MHz * 30 bits = 17.02 Gbps

 

Mac mini (2018), Mac Pro (Early 2008), MacBook Pro (Retina, 15-inch, Mid 2015), GA-Z170X-Gaming 7, Sapphire Pulse Radeon RX 580 8GB GDDR5, Sonnet Echo Express III-D, Trebleet Thunderbolt 3 to NVMe M.2 case


chx and goalque liked
ReplyQuote
chx
 chx
(@chx)
Estimable Member
Joined: 4 years ago
 

 if you're sending video output from the eGPU to your internal graphics card because the graphics buffer copy is sent using the 22 Gbps PCIe bandwidth for each frame that is copied. This is assuming the information at  https://egpu.io/thunderbolt-3-news-for-egpus/#tb3perf is correct.

 

blink you are sending rendered frames over the PCIe bus? Who receives those? How? What?

Lenovo ThinkPad 25 -- GALAX SNPR TB3 1060 -- Lenovo Graphics Dock -- Benq BL2411PT - - two PackedPixels - Dasung not-eReader backer


ReplyQuote
joevt
(@joevt)
Noble Member
Joined: 3 years ago
 
Posted by: chx

blink you are sending rendered frames over the PCIe bus? Who receives those? How? What?

Graphics rendered by an eGPU can only be shown on your laptop's built in display if the OS copies the contents from the eGPU to the frame buffer of your laptop's GPU. This can only happen over the PCIe bus through Thunderbolt using part of Thunderbolt's alloted device to host PCIe bandwidth which won't be affected by DisplayPort bandwidth because DisplayPort can only be host to device but it will be affected by and affects reads from another device such as a hard drive on the same Thunderbolt bus.

https://egpu.io/how-to-egpu-accelerated-internal-display-macos/

Mac mini (2018), Mac Pro (Early 2008), MacBook Pro (Retina, 15-inch, Mid 2015), GA-Z170X-Gaming 7, Sapphire Pulse Radeon RX 580 8GB GDDR5, Sonnet Echo Express III-D, Trebleet Thunderbolt 3 to NVMe M.2 case


ReplyQuote
chx
 chx
(@chx)
Estimable Member
Joined: 4 years ago
 
Posted by: joevt
 
Graphics rendered by an eGPU can only be shown on your laptop's built in display if the OS copies the contents from the eGPU to the frame buffer of your laptop's GPU. This can only happen over the PCIe bus through Thunderbolt using part of Thunderbolt's alloted device to host PCIe bandwidth [...]  and affects reads from another device such as a hard drive on the same Thunderbolt bus.

https://egpu.io/how-to-egpu-accelerated-internal-display-macos/

Ah so memory copy between two PCIe devices, sure, that can work, I guess that's how bridgeless SLI works too. I got very confused and didn't consider the built in GPU still having a role although it's quite interesting that the framebuffer has such n iron clad standard this can work, usually two GPU can't agree on the name of the day. Also, this doesn't affect the eGPU bandwidth itself because it's bidirectional, does it?

Lenovo ThinkPad 25 -- GALAX SNPR TB3 1060 -- Lenovo Graphics Dock -- Benq BL2411PT - - two PackedPixels - Dasung not-eReader backer


ReplyQuote
joevt
(@joevt)
Noble Member
Joined: 3 years ago
 
Posted by: chx

I got very confused and didn't consider the built in GPU still having a role

The built in display is connected to the built in GPU. The pixels must therefore come from a frame buffer of the built in GPU. The eGPU is doing all the drawing because it's better at doing that (faster 3D performance). The eGPU is chosen by the software (such as a game) to do the drawing. The eGPU does the drawing in it's own buffers. Therefore, a method of getting the pixels from the eGPU to the GPU must exist.

Think about what happens when a window overlaps two displays. There are two options:

  1. A draw command is done twice, once for each display.
  2. A draw command is done once, and the pixels are copied for the other display.

Option (a) happened a lot in classic Mac OS. Option (b) is what we're talking about. It's used by apps and games targeting a specific GPU.

Posted by: chx

it's quite interesting that the framebuffer has such n iron clad standard this can work, usually two GPU can't agree on the name of the day.

It's done in a higher level than that - in software (drivers) instead of hardware. The drivers are the standard. The drivers must provide certain API's to do drawing and copying. How the hardware works doesn't matter. The drivers probably ask for a certain format of the pixels. It's a simple task for the eGPU's drivers to provide that format, possibly doing some conversion using the eGPU. How the transfer of data occurs doesn't matter (DMA, or CPU copies, or whatever) - though some methods are more efficient, all the pixels must come over the PCIe/Thunderbolt bus.

Posted by: chx

Also, this doesn't affect the eGPU bandwidth itself because it's bidirectional, does it?

The OS asks the eGPU (using the drivers) to send the pixels to a buffer that can be used by the built in GPU (maybe a buffer in RAM that is sent to the built in GPU by a call to the built-in GPU's drivers). That takes time, a tiny bit of bandwidth to the eGPU (the commands from the driver), and a lot of bandwidth from the eGPU (the pixels). Thunderbolt is bidirectional which means receive and transmit use different paths so they don't interfere.

Mac mini (2018), Mac Pro (Early 2008), MacBook Pro (Retina, 15-inch, Mid 2015), GA-Z170X-Gaming 7, Sapphire Pulse Radeon RX 580 8GB GDDR5, Sonnet Echo Express III-D, Trebleet Thunderbolt 3 to NVMe M.2 case


ReplyQuote
 of  2