no screens found(EE) - Cannot use AMD R5 M330 as output to monitor
Alex Deucher
alexdeucher at gmail.com
Fri May 15 20:28:34 UTC 2020
source and sink only make sense in the specific randr commands to set this
up. Essentially a source is a producer and sink is a consumer. In a
nutshell, devices can either: drive displays, render content, or both. For
example, a USB to VGA adapter can just display, but it has no graphics
engine to actually draw any content. You can also have devices which have
no display hardware (like the chip in this thread) or no displays
physically wired to the chip which can only render. Finally you have the
traditional case where you have a device which has display hardware with
display connectors wired up which also has a graphics engine. Regardless
of what hardware capabilities the device has, the display manager can pick
which one(s) will be used for display and which one will be used for
rendering. If the rendering and display device is the same, everything
happens on the device directly. If the rendering and display devices are
separate, the rendering device will render to it's own memory and the the
contents will be copied to a buffer suitable for use by the display device.
Alex
On Fri, May 15, 2020 at 12:46 PM IL Ka <kazakevichilya at gmail.com> wrote:
> Thank you, Alex.
>
> I am not topic starter, just a curious one. This is how it works:
>
> * AMD card renders some 3D output to some memory region (this card is
> called "source" by randr)
> * Intel sends it to the output (this card is called "sink")
>
> By setting "DRI_PRIME=1" you are asking app to use AMD to render.
>
> Is it correct?
>
>
>
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Без
> вирусов. www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_7974421917490793411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Fri, May 15, 2020 at 7:16 PM Alex Deucher <alexdeucher at gmail.com>
> wrote:
>
>> Most modern desktop environments set this up already. All you need to do
>> is set the env var DRI_PRIME=1 when running an app and it will run on the
>> dGPU. Many desktop environments also provide a GUI based option to choose
>> which GPU to run a particular application on.
>>
>> Alex
>>
>> On Fri, May 15, 2020 at 8:23 AM IL Ka <kazakevichilya at gmail.com> wrote:
>>
>>> Then what is the right thing to do here?
>>> Use AMD only for rendering, but not for the output. Something like:
>>> $ xrandr --setprovideroffloadsink provider sink
>>> ?
>>>
>>>
>>>
>>>
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Без
>>> вирусов. www.avg.com
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>> <#m_7974421917490793411_m_2971641462066569585_m_-1550470071674472515_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> On Thu, May 14, 2020 at 9:52 PM Alex Deucher <alexdeucher at gmail.com>
>>> wrote:
>>>
>>>> On Thu, May 14, 2020 at 2:47 PM IL Ka <kazakevichilya at gmail.com> wrote:
>>>> >
>>>> > Here is what happened:
>>>> >>
>>>> >> [ 347.043] (WW) RADEON(0): No outputs definitely connected, trying
>>>> again...
>>>> >> [ 347.043] (WW) RADEON(0): Unable to find connected outputs -
>>>> setting 1024x768 initial framebuffer
>>>> >> [ 347.043] (II) RADEON(0): mem size init: gart size :7fbcf000 vram
>>>> size: s:80000000 visible:fbbe000
>>>> >
>>>> >
>>>> > It seems that you have 2 video cards: intel (built into CPU I
>>>> believe) and ATI.
>>>> > Intel is connected, not ATI.
>>>> >
>>>> > I think you need to enable ATI video card in your BIOS settings.
>>>> > There should be something like "discrete video card" or "on board
>>>> video card" switch.
>>>>
>>>> Not possible on this system. The dGPU in question has no display
>>>> hardware at all so it cannot drive a display. It can only support
>>>> render offload.
>>>>
>>>> Alex
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20200515/961af147/attachment.htm>
More information about the xorg
mailing list