>> Oh, that's a very interesting find. Could you try to turn around the way the >> patch works? >> >> E.g. instead of forcing the UVD FW into the first segment, change >> amdgpu_uvd_force_into_uvd_segment() so that the BOs are forced into the same >> segment as the UVD firmware. >>
I started implementing this and I realized two main problems with this approach. First, there's currently no guarantee the UVD FW does not cross a 256MB boundary. Checking for this and providing a fallback is going to make this patch... not really any less complex than the original. Second, most of time this is just going to end up selecting the first segment anyway. I'll go more into this below. >> That would resolve my concern that this could overload the first segment. >> The feedback and message BO are usually rather small (4 or 128k IIRC), but >> the firmware is a couple of megabytes in size. >> >> When we have other FW and VGA emulation buffers in the first segment as well >> then that could result into clashing that segment to much. >> During my initial investigation, I found out that the UVD FW got placed in the first segment *because* things were already placed there. This is why adding a 'stolen_vga_memory' substitute was an effective workaround. So, CIK is *already* forced to deal with an overloaded first segment and, with the inverted approach, will continue to do so for typical use cases. Explicitly placing the UVD FW into the first segment just makes this guaranteed. I did implement a module parameter for testing that allows designating a specific 256MB segment as the legacy UVD segment. I can polish this up so the user has the option to manually relieve some of the first segment pressure on SI and CIK devices. I haven't run into a situation where I've needed this during normal use, but I can certainly appreciate it being available. Thanks, John
