- Original Message -
> From: "Saket Sinha"
> To: dri-devel at lists.freedesktop.org, kvm at vger.kernel.org, qemu-devel at
> nongnu.org
> Cc: "Dave Airlie"
> Sent: Monday, 15 February, 2016 12:34:18 PM
> Subject: VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs
>
> Hi,
>
> It seems
Hi Harry,
On 13 February 2016 at 00:05, Wentland, Harry wrote:
> The goal with DAL is to provide a unified, full featured display stack to
> service all of our Linux offerings. This driver will have to support our full
> feature set beyond what's supported by amdgpu, e.g.
> - synchronzied tim
Hi Linus,
Jani sent a bunch of i915 display fixes as my weekend started, but
hopefully you can fit them in.
Thanks,
Dave.
The following changes since commit c92a428f408b23215d1a27f652742094bfc50577:
Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/01969633/attachment.html>
On Fri, Feb 12, 2016 at 08:30:32PM +0100, Mario Kleiner wrote:
> In the display resume path, move the calls to drm_vblank_on()
> after the point when the display engine is running again.
>
> Since changes were made to drm_update_vblank_count() in Linux 4.4+
> to emulate hw vblank counters via vbla
On Fri, Feb 12, 2016 at 01:50:53PM +, Carlos Palminha wrote:
Sob-line from you is missing on all patches, I can't merge them. Also
please copypaste a default blurb to all patches that this is only recently
no longer needed. And dunno what happened to your patch series, the
threading is somehow
On Fri, Feb 12, 2016 at 10:28:28PM +0200, Imre Deak wrote:
> On Thu, 2016-01-21 at 15:10 -0800, Rafael Antognolli wrote:
> > So far, the i915 driver and some other drivers set it to the
> > drm_device,
> > which doesn't allow one to know which DP a given aux channel is
> > related
> > to. Changing
top-level post since I can't reply to the diagram directly. So from
very cursor reading-around in the code I think you have a few
mismatches in how you map drm concepts to dal structures:
- cursor is just a drm_plane - step 0 of atomic support is universale
plane support, and you didn't do that in
On Sun, Feb 14, 2016 at 2:32 PM, Rob Clark wrote:
> On Fri, Feb 12, 2016 at 7:05 PM, Wentland, Harry
> wrote:
>> The current amdgpu display stack grew somewhat organically and as such is
>> not well suited to handling all of the hardware dependencies involved
>> especially in areas like audio.
On Sun, Feb 14, 2016 at 12:22 PM, Jerome Glisse wrote:
>> There's still a bunch of legacy stuff in these patches that's on our list of
>> things to refactor. Some of that is
>> - dc/adapter
>> - dc/asic_capability
>> - dc/audio
>> - dc/bios
>> - dc/gpio
>>
>> We should be able to cut the size of
On Sun, Feb 14, 2016 at 11:16:52AM +0200, Oded Gabbay wrote:
> Following Daniel's request, I spent some time removing the hard requirement
> that radeon and amdgpu will always appear _after_ amdkfd in the drm Makefile.
>
> This was done by modifing radeon/amdgpu to defer their loading if they det
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/e119a8af/attachment.html>
On Sun, Feb 14, 2016 at 1:10 PM, Lukas Wunner wrote:
> /**
> + * vga_switcheroo_client_probe_defer() - whether to defer probing a given GPU
> + * @pdev: pci device of GPU
> + *
> + * Determine whether any prerequisites are not fulfilled to probe a given
> GPU.
I'd phrase this as "Determine whet
Hi,
On Tue, Feb 09, 2016 at 10:04:01AM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote:
[...]
> > @@ -967,6 +970,15 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> > struct pci_device_id *ent)
> > if (PCI_FUNC(pdev->devfn))
> >
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/4ebd0999/attachment-0001.html>
On Sat, Feb 13, 2016 at 12:05:48AM +, Wentland, Harry wrote:
> Hi Dave, Daniel, others,
[...]
> There's still a bunch of legacy stuff in these patches that's on our list of
> things to refactor. Some of that is
> - dc/adapter
> - dc/asic_capability
> - dc/audio
> - dc/bios
> - dc/gpio
>
>
blematic?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/fd35e91c/attachment.html>
amdgpu must load only after amdkfd's loading has been completed. If that
is not enforced, then amdgpu's call into amdkfd's functions will cause a
kernel BUG.
When amdgpu and amdkfd are built as kernel modules, that rule is enforced
by the kernel's modules loading mechanism. When amdgpu and amdkfd
radeon must load only after amdkfd's loading has been completed. If that
is not enforced, then radeon's call into amdkfd's functions will cause a
kernel BUG.
When radeon and amdkfd are built as kernel modules, that rule is
enforced by the kernel's modules loading mechanism. When radeon and
amdkfd
Current dependencies between amdkfd and radeon/amdgpu force the loading
of amdkfd _before_ radeon and/or amdgpu are loaded. When all these kernel
drivers are built as modules, this ordering is enforced by the kernel
built-in mechanism of loading dependent modules.
However, there is no such mechani
Following Daniel's request, I spent some time removing the hard requirement
that radeon and amdgpu will always appear _after_ amdkfd in the drm Makefile.
This was done by modifing radeon/amdgpu to defer their loading if they detect
that amdkfd is not loaded yet, in case the drivers are built ins
On Fri, Feb 12, 2016 at 7:05 PM, Wentland, Harry
wrote:
>
> The current amdgpu display stack grew somewhat organically and as such is not
> well suited to handling all of the hardware dependencies involved especially
> in areas like audio. The drm abstractions used by the old code map less and
ump
somewhere).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/3555864a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/ab4de8a2/attachment.html>
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/ca3f6547/attachment-0001.html>
dri-devel/attachments/20160214/8707f76e/attachment.html>
nts/20160214/19b8c772/attachment.html>
xorg-server 1.15 is not supported any more, can this issue be closed?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
have an example of such a kernel?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160214/56d65cdb/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160214/7cb11b13/attachment.html>
reedesktop.org/archives/dri-devel/attachments/20160214/1f8a8e8b/attachment.html>
31 matches
Mail list logo
