Hi! Skipping si_setup_spi doesn't help at all. Where is harvesting handled/setup then? Only other place that to me seems related would be si_setup_rb, but from what I can see by logging none of my backends seem to be disabled. Anything else I can check? Thanks! Alexandre On Mon, Oct 12, 2015 at 5:20 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Thu, Oct 8, 2015 at 9:59 PM, Alexandre Biron > <bironalexandre@xxxxxxxxx> wrote: >> Hi! >> >> I've never been able to run the open source drm driver on my 7870 >> Tahiti card. The console kms works but it crashes as soon as X is >> started. There have been many mentions of it in bug reports, but none >> of the attempts at fixes worked. >> https://bugs.freedesktop.org/show_bug.cgi?id=71689 is currently open >> https://bugs.freedesktop.org/show_bug.cgi?id=60879 was about a few >> different issues, including this one, but none of the proposed fixes >> worked on my 7870 >> >> I decided to debug this on my own, and though I am a total noob at >> driver development, I think I made some progress at understanding the >> issue. >> >> The 7870 Tahiti is a "harvested" chip, which means some CUs are >> disabled. 25% of them in this case. The code handling this is in >> si.c, in the function is si_setup_spi(). The idea seems to be that a >> bit mask telling which CUs are truly available must be set in the >> SPI_STATIC_THREAD_MGMT_3 register. But the algorithm to build that >> mask seems fuzzy to me. It walks the bits of active_cu until it finds >> an active one, and stop there to build its make. >> >> data = RREG32(SPI_STATIC_THREAD_MGMT_3); >> active_cu = si_get_cu_enabled(rdev, cu_per_sh); >> mask = 1; >> for (k = 0; k < 16; k++) { >> mask <<= k; >> if (active_cu & mask) { >> data &= ~mask; >> WREG32(SPI_STATIC_THREAD_MGMT_3, data); >> break; >> } >> } >> >> However, from the little I understand that doesn't cover all cases, >> but only works if the disabled CUs are in the lower bits. For my card, >> the active_cu results are: >> Decimal - Binary >> 252 - 11111100 >> 252 - 11111100 >> 207 - 11001111 >> 252 - 11111100 >> >> As you can see the 3rd group has its disabled CUs straight in the >> middle of it, but the algorithm probably thinks that they are all good >> since the first bit is 1 and it stops right there. So I guess it tries >> to use bad CUs at runtime and fails miserably >> I tried to change the way the register data is computed by I just >> can't figure the logic of it (and I couldn't find much details in >> AMD's doc). Assuming it generates the right thing for active_cu == >> 11111100, I get data == 1111111111110111. >> So I have 2 disabled units, but only a single 0 in the mask? >> Pretending to have more disabled units, active_cu == 11110000, that >> generates data == 1111111110111111. Again, single 0. Is that right? >> What would be the bit pattern required for active_cu == 11001111 ? >> >> I might be way off track in my investigation, so please enlighten me! > > I don't think this register even needs to be programmed. Can you try > skipping the call to si_setup_spi()? The hw default values 0xffff > should be fine. These registers are not for harvesting, but rather > for limiting the number of CUs uses by specific shader stages so even > if you program them wrong, the hw will do the right thing internally. > > Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
