Re: EXA - when does it's implementation depend on DRM?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/7/5 Rafał Miłecki <zajec5@xxxxxxxxx>:
> W dniu 4 lipca 2010 22:37 użytkownik Dave Airlie <airlied@xxxxxxxxx> napisał:
>> 2010/7/5 Rafał Miłecki <zajec5@xxxxxxxxx>:
>>> W dniu 4 lipca 2010 22:24 użytkownik Dave Airlie <airlied@xxxxxxxxx> napisał:
>>>> 2010/7/5 Rafał Miłecki <zajec5@xxxxxxxxx>:
>>>>> AFAIU EXA is collection of operations (Solid, Copy, UploadToScreen,
>>>>> DownloadFromScreen) that touch VRAM. So we can tell hardware to move
>>>>> xterm window 100px right (Copy) and fill freed place with blue
>>>>> (Solid). Is that right?
>>>>>
>>>>> So my question is: when implementing EXA (in DDX) needs DRM and when
>>>>> it does not? I know in case of R6xx-R7xx we had to get DRM first to
>>>>> receive EXA. AFAIK it wasn't the case with R1xx-R5xx.
>>>>>
>>>>> On the other hand some VIA's driver needs DRM for EXA on Chrome9,
>>>>> while openChrome claims to support EXA without DRM[1].
>>>>>
>>>>> Could someone explain this to me, please?
>>>>>
>>>>> [1] http://phoronix.com/forums/showthread.php?p=89776
>>>>
>>>> Nothing to do with EXA, its up to the driver underneath.
>>>
>>> That's why I mentioned "implementation" in subject, not EXA itself :)
>>>
>>>
>>>> If the driver can accel the operations without the drm, it doesn't
>>>> need the drm, it the driver requires the drm to accel operations then
>>>> it needs the drm
>>>
>>> Any tip why acceleration operations are available on some hardware
>>> only with DRM, and sometimes not? Is this related to the way how we
>>> send commands to GPU? AFAIK every command submission implementation
>>> needs DRM... but somehow in case of r1xx-r5xx it is not true.
>>
>> You can program some GPUs via MMIO, its slower and you can't DMA
>> to/from main memory at all, it just works in an offscreen memory area.
>>
>> Its generally pointless maintaining these codepaths since nobody tests
>> them, and for chips like r600 I don't think MMIO is sufficient to
>> program accel engines.
>>
>> Not so sure on r500 its sufficient either since some regs can't be
>> programmed via MMIO properly, but we have the codepaths since they are
>> so similiar to r100.
>
> Ahh, I didn't think of submitting commands using MMIO. Thanks!

Yeah its not so much submitting commands, as setting up the 3D engine
by hand, and then poking in vertices by hand afterwards.

I think at one stage radeonhd wanted to add another path to use VRAM
to store IBs, so you could do basic CP accel without a drm however
there was much point to this, since you just ended up with yet another
codepath that got tested once in a blue moon, and was broken until
someone tested it. More codepaths generally doesn't lead to
better/faster code.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux