Re: [Mesa-dev] r600g old design - new design
On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: - use score for placing bo, bo placement will be recorded in bo structure and each time a state is bind bo score will be updated (bo bound as framebuffer will get their score for placing into vram increase while bo bound as small vertex buffer will endup in GTT, also anytime a bo is mapped for transfer for CPU read its score for GTT placement increase thus bo that are often updated by CPU will more likely place into GTT) Beware that the EXA 'classic' scheme originally (with the 'greedy' and 'smart' heuristics) used a score like that to determine whether a pixmap should reside in VRAM or system memory, and it could result in quite erratic / inconsistent / unreproducible behaviour when the score hovered around the threshold. It could make fixing or even reproducing problems harder than it is already. In case of dual API use (ie if cs ioctl is also use) kernel will assume GPU has loose context and will reprogram, reflush everythings. This might be an opportunity for getting st/xorg working well with r600g, so the corresponding changes to xf86-video-ati could at least be delayed until the new scheme has matured in the Gallium tree. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g old design - new design
On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: - use score for placing bo, bo placement will be recorded in bo structure and each time a state is bind bo score will be updated (bo bound as framebuffer will get their score for placing into vram increase while bo bound as small vertex buffer will endup in GTT, also anytime a bo is mapped for transfer for CPU read its score for GTT placement increase thus bo that are often updated by CPU will more likely place into GTT) Beware that the EXA 'classic' scheme originally (with the 'greedy' and 'smart' heuristics) used a score like that to determine whether a pixmap should reside in VRAM or system memory, and it could result in quite erratic / inconsistent / unreproducible behaviour when the score hovered around the threshold. It could make fixing or even reproducing problems harder than it is already. Did trying some sort of hysteresis - eg. having different thresholds for upload vs. download help? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g old design - new design
On Mit, 2010-09-29 at 11:49 +0100, Keith Whitwell wrote: On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: - use score for placing bo, bo placement will be recorded in bo structure and each time a state is bind bo score will be updated (bo bound as framebuffer will get their score for placing into vram increase while bo bound as small vertex buffer will endup in GTT, also anytime a bo is mapped for transfer for CPU read its score for GTT placement increase thus bo that are often updated by CPU will more likely place into GTT) Beware that the EXA 'classic' scheme originally (with the 'greedy' and 'smart' heuristics) used a score like that to determine whether a pixmap should reside in VRAM or system memory, and it could result in quite erratic / inconsistent / unreproducible behaviour when the score hovered around the threshold. It could make fixing or even reproducing problems harder than it is already. Did trying some sort of hysteresis - eg. having different thresholds for upload vs. download help? There actually already is a hysteresis — I forgot about that, thanks for reminding me. I never tried playing with the threshold values, don't know if anyone did. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g old design - new design
2010/9/29 Michel Dänzer mic...@daenzer.net: On Mit, 2010-09-29 at 11:49 +0100, Keith Whitwell wrote: On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: - use score for placing bo, bo placement will be recorded in bo structure and each time a state is bind bo score will be updated (bo bound as framebuffer will get their score for placing into vram increase while bo bound as small vertex buffer will endup in GTT, also anytime a bo is mapped for transfer for CPU read its score for GTT placement increase thus bo that are often updated by CPU will more likely place into GTT) Beware that the EXA 'classic' scheme originally (with the 'greedy' and 'smart' heuristics) used a score like that to determine whether a pixmap should reside in VRAM or system memory, and it could result in quite erratic / inconsistent / unreproducible behaviour when the score hovered around the threshold. It could make fixing or even reproducing problems harder than it is already. Did trying some sort of hysteresis - eg. having different thresholds for upload vs. download help? There actually already is a hysteresis — I forgot about that, thanks for reminding me. I never tried playing with the threshold values, don't know if anyone did. Yeah i do remember the issue with the ddx, i hope to be able to come up with somethings that won't change its mind every cs (ie once a bo is assigned to GTT or VRAM it will stay there for a bit before being re-evaluated to move to other domain). Anyway if it's catastrophic it will be self contained enough that it should be easy to test other way to be smart about bo placement (if we could ever be smart about it :)) Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
