On Sat, 1 Mar 2014 06:47:41 +1000 Dave Airlie <airlied@xxxxxxxxx> wrote: > On Sat, Mar 1, 2014 at 5:56 AM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > > Am 28.02.2014 19:50, schrieb Lauri Kasanen: > > > >> Without this, a bo may get created in the cpu-inaccessible vram. > >> Before the CP engines get setup, all copies are done via cpu memcpy. > >> > >> This means that the cpu tries to read from inaccessible memory, fails, > >> and the radeon module proceeds to disable acceleration. > >> > >> Doing this has no downsides, as the real VRAM size gets set as soon as the > >> CP engines get init. > >> > >> This is a candidate for 3.14 fixes. > >> > >> v2: Add comment on why the function is used > >> Reviewed-by: Christian König <christian.koenig@xxxxxxx> >> >> And I suggest to add "Cc: stable@xxxxxxxxxxxxxxx" as well. > > Won't this create objects that are stuck in the middle of VRAM with > the new top down approach? > > then when we go to use all the VRAM they'll be pinned in the middle? Yes, the initial pins would act like that with the top-down code. But the top-down logic is 3.15 material and still WIP. Depending on their constraints, I think I'll either add a new flag, or turn them into FIXED allocations - do they need to be at exact position foo or only at the beginning. (Christian?) So sending this fix to stable is safe, as they all use bottom-up. - Lauri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
