no screens found(EE) - Cannot use AMD R5 M330 as output to monitor
Sreyan Chakravarty
sreyan32 at gmail.com
Sun May 17 14:38:43 UTC 2020
Will this launch firefox on the dGPU ?
$ DRI_PRIME=1 && firefox
On 5/16/20 1:58 AM, Alex Deucher wrote:
> 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
> <mailto: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>
>
>
>
> On Fri, May 15, 2020 at 7:16 PM Alex Deucher
> <alexdeucher at gmail.com <mailto: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 <mailto: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>
>
>
>
> On Thu, May 14, 2020 at 9:52 PM Alex Deucher
> <alexdeucher at gmail.com <mailto:alexdeucher at gmail.com>> wrote:
>
> On Thu, May 14, 2020 at 2:47 PM IL Ka
> <kazakevichilya at gmail.com
> <mailto: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
>
--
Regards,
Sreyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20200517/c70f6c86/attachment.htm>
More information about the xorg
mailing list