Bug 31682
| Summary: | Radeon console output very slow with kms | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Kurt Roeckx (kurt) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | aelschuring, alan, alexdeucher, glisse |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.38 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Kurt Roeckx
2011-03-22 18:30:09 UTC
This is not exactly a bug. KMS does not provide any acceleration for console operations while radeonfb does. So then see this as a feature request or something. @alex: by saying "not a bug", are you implying that this is by design and will not be fixed? Or do you simply mean that there are no clear, simple ways to improve the situation? TBH, I could just as easily classify this as a performance regression since 2.6.32 (or whenever KMS was made the default). What is the recommended solution for no-X servers with AMD IGPs? Blacklist the radeon module, or will the modeset=0 option be supported indefinitely? Someone could implement support for accelerated fb operations, I just don't have any plans to. The problem is, the drawing engine is usually the part of the GPU that hangs if there is a problem so if we use the drawing engine to accelerate fb operations and it hangs, you may end up with a hosed console whereas. The other issue is that on newer asics, there is no 2D engine, so you'd have to implement fb acceleration with the 3D engine which is substantially more complex. (or use the GART like GMA50 ...) We can not do the GART trick on radeon, radeon is using dedicated VRAM and not scaning out from system memory mapped through a gart. (Well we could do GART trick on newer GPU that has virtual address space where we can remap the VRAM with a GART but anybody with such a GPU that is using fbdev as others more serious personal issues) You only need to use the GART trick if you might not have enough memory to allocate twice the memory needed for the framebuffer. If you can afford the memory then allocate two copies and write each text blit into both. Then just change the start of the scan out as needed. It's even faster than the GMA500 GART trick! Alan |