On Sat, Mar 1, 2014 at 5:29 AM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > Am 01.03.2014 10:15, schrieb Lauri Kasanen: > >> 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?) > > > AFAIK the stolen VGA memory must be at the very beginning. > > The UVD firmware memory block needs to be in the first 256MB, allocated and > initialized before all other blocks are started and after used once can't be > moved around any more. > > I'm not sure about this but we probably have more allocations that assume > they end up at the beginning of the address space (GART?). > Gart (vmid 0) needs to be in the visible area since we use the CPU to update it. Alex > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
