Re: [PATCH] drm/nouveau: do not move buffers when not needed
On Wed, Sep 4, 2013 at 11:25 PM, Maarten Lankhorst
wrote:
> Op 04-09-13 03:24, Ben Skeggs schreef:
>> On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
>> wrote:
>>> Op 15-07-13 08:05, Ben Skeggs schreef:
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
wrote:
> I have no idea what this bogus restriction on placement is, but it breaks
> decoding 1080p
> VDPAU at boot speed. With this patch applied I only need to bump the vdec
> clock to
> get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer
> moves.
It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size.
What configuration does the buffer that's getting moved here have
exactly? The placement restriction isn't necessary on GF8, the rest
of the restrictions may currently be required still however.
= vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo.
This is ok because
>>> the vm hides all the tiling translations, and the engines will read the raw
>>> bitstream correctly.
>> Why would you be doing such a thing in the first place? It seems
>> pointless, and quite possibly counter-productive to use a tiled layout
>> for a linear data structure...
> Initially I just allocated everything I didn't need to access directly tiled,
> and it seems I did the same for
> the bitstream bo. I only found out later about the bug with excessive moves
> causing a major slowdown.
>
>>> 8<---
>>> This prevents buffer moves from being done on NV50+, where remapping is not
>>> needed because
>>> the bar has its own VM, instead of only having the first BAR1-size chunk of
>>> VRAM accessible.
>>> nouveau_bo_tile_layout is always 0 on < NV_50.
>>>
>>> Signed-off-by: Maarten Lankhorst
>>> ---
>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> index d506da5..762bfcd 100644
>>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct
>>> ttm_buffer_object *bo)
>>> struct nouveau_device *device = nv_device(drm->device);
>>> u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
>>>
>>> - /* as long as the bo isn't in vram, and isn't tiled, we've got
>>> -* nothing to do here.
>>> + /*
>>> +* if the bo is not in vram, or remapping can be done (nv50+)
>>> +* do not worry about placement, any location is valid
>>> */
>>> - if (bo->mem.mem_type != TTM_PL_VRAM) {
>>> - if (nv_device(drm->device)->card_type < NV_50 ||
>>> - !nouveau_bo_tile_layout(nvbo))
>>> - return 0;
>>> - }
>>> + if (nv_device(drm->device)->card_type >= NV_50 ||
>>> + bo->mem.mem_type != TTM_PL_VRAM)
>>> + return 0;
>> I get what you're trying to do here, and we should definitely avoid
>> the "mappable vram" check on GF8, but I suspect this condition is too
>> broad. I'll think about it more after I finish reviewing the rest of
>> the patches on the list..
>>
> I think this relaxed check is fine. If it's !VRAM, the host can always access
> it because it has direct access to the
> pages without needing anything from the gpu. On >= NV50 the move can always
> be skipped too because the
> memory is mapped to the vm, and always accessible.
Yeah, I think the check is sane, after thinking it through. We shall
find out :)
But first, if you're going to not move tiled system memory to vram
first, you're going to need to deal with mapping it into bar1 so the
vm deals with some of the reordering. See what's done in
io_mem_reserve() for TTM_PL_VRAM.
Ben.
>
> ~Maarten
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 6 September 2013 19:21, Sean Paul wrote:
> On Thu, Sep 5, 2013 at 11:37 PM, Rahul Sharma wrote:
>> On 5 September 2013 19:20, Inki Dae wrote:
>>>
>>>
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
>> ow...@vger.kernel.org] On Behalf Of Rahul Sharma
>> Sent: Thursday, September 05, 2013 3:04 PM
>> To: Inki Dae
>> Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
>> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
>> Shirish S
>> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
>> driver
>>
>> On 5 September 2013 10:52, Inki Dae wrote:
>> >> >> >> >> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
>> >> >> >> >> + {
>> >> >> >> >> + .pixel_clock = 2700,
>> >> >> >> >> + .conf = {
>> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
> 0x30,
>> >> > 0x40,
>> >> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
> 0x54,
>> >> > 0x87,
>> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
> 0x10,
>> >> > 0xE0,
>> >> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
> 0x00,
>> >> > 0x00,
>> >> >> >> >> + },
>> >> >> >> >> + },
>> >> >> >> >> + {
>> >> >> >> >> + .pixel_clock = 27027000,
>> >> >> >> >> + .conf = {
>> >> >> >> >> + 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
> 0x09,
>> >> > 0x64,
>> >> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
> 0x54,
>> >> > 0x87,
>> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
> 0x10,
>> >> > 0xE0,
>> >> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
> 0x00,
>> >> > 0x00,
>> >> >> >> >> + },
>> >> >> >> >> + },
>> >> >> >> >> + {
>> >> >> >> >> + .pixel_clock = 74176000,
>> >> >> >> >> + .conf = {
>> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
> 0xef,
>> >> > 0x5B,
>> >> >> >> >> + 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
> 0x54,
>> >> > 0xb9,
>> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
> 0x10,
>> >> > 0xE0,
>> >> >> >> >> + 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
> 0x00,
>> >> > 0x00,
>> >> >> >> >> + },
>> >> >> >> >> + },
>> >> >> >> >> + {
>> >> >> >> >> + .pixel_clock = 7425,
>> >> >> >> >> + .conf = {
>> >> >> >> >> + 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
> 0xf8,
>> >> > 0x40,
>> >> >> >> >> + 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
> 0x54,
>> >> > 0xba,
>> >> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
> 0x10,
>> >> > 0xe0,
>> >> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
> 0x00,
>> >> > 0x00,
>> >> >> >> >> + },
>> >> >> >> >> + },
>> >> >> >> >> + {
>> >> >> >> >> + .pixel_clock = 14850,
>> >> >> >> >> + .conf = {
>> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
> 0xf8,
>> >> > 0x40,
>> >> >> >> >> + 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
> 0x54,
>> >> > 0xba,
>> >> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
> 0x10,
>> >> > 0xE0,
>> >> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
> 0x00,
>> >> > 0x00,
>> >> >> >> >> + },
>> >> >> >> >> + },
>> >> >> >> >> +};
>> >> >> >> >> +
>> >> >> >> >
>> >> >> >> > Are you aware of the effort to move these to dt? Since these
>> are
>> >> >> >> > board-specific values, it seems incorrect to apply them
>> >> universally.
>> >> >> >> > Shirish has uploaded a patch to the chromium review site to
>> push
>> >> >> these
>> >> >> >> > into dt
>>> (https://chromium-r
Re: drm/radeon: "ring test failed" on PA-RISC Linux
Alex,
09.09.2013, в 21:43, Alex Deucher написал(а):
> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov wrote:
>> Folks,
>>
>> We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
>> native video options of the latest PA-RISC servers and workstations
>> (these are ATIs, most of which are based on R100/R300/R420 chips) work
>> correctly on this platform (big endian pa-risc).
>>
>> However, we hadn't much success. DRM fails every time with
>> "ring test failed" for both AGP & PCI.
>>
>> Maybe you would give us some suggestions that we could check?
>>
>> Topic started here:
>> http://www.spinics.net/lists/linux-parisc/msg04908.html
>> And continued there:
>> http://www.spinics.net/lists/linux-parisc/msg04995.html
>> http://www.spinics.net/lists/linux-parisc/msg05006.html
>>
>> Problems we've already resolved without any signs of progress:
>> - Checked the successful microcode load
>> "parisc AGP GART code writes IOMMU entries in the wrong byte order and
>> doesn't add the coherency information SBA code adds"
>> "our PCI BAR setup doesn't really work very well together with the Radeon
>> DRM address setup. DRM will generate addresses, which are even outside
>> of the connected LBA"
>>
>> Things planned for a check:
>> "The drivers/video/aty uses
>> an endian config bit DRM doesn't use, but I haven't tested whether
>> this makes a difference and how it is connected to the overall picture."
>
> I don't think that will any difference. radeon kms works fine on
> other big endian platforms such as powerpc.
Good! I'll opt it out then.
>
>>
>> "The Rage128 product revealed a weakness in some motherboard
>> chipsets in that there is no mechanism to guarantee
>> that data written by the CPU to memory is actually in a readable
>> state before the Graphics Controller receives an
>> update to its copy of the Write Pointer. In an effort to alleviate this
>> problem, we"ve introduced a mechanism into the
>> Graphics Controller that will delay the actual write to the Write Pointer
>> for some programmable amount of time, in
>> order to give the chipset time to flush its internal write buffers to
>> memory.
>> There are two register fields that control this mechanism:
>> PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
>>
>> In the radeon DRM codebase I didn't found anyone using/setting
>> those registers. Maybe PA-RISC has some problem here?..."
>
> I doubt it. If you are using AGP, I'd suggest disabling it and first
> try to get things working using the on chip gart rather than AGP.
> Load radeon with agpmode=-1.
Already tried this without any luck. Anyway, a radeon driver fallbacks
to the PCI mode in our case, so does it really matter?
In addition, people with PCI cards experiencing the same issue...
> The on chip gart always uses cache
> snooped pci transactions and the driver assumes pci is cache coherent.
> On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
> system ram. On PCIE asics, the gart table is stored in vram. The
> gart page table maps system pages to a contiguous aperture in the
> GPU's address space. The ring lives in gart memory. The GPU sees a
> contiguous buffer and the gart mechanism handles the access to the
> backing pages via the page table. I'd suggest verifying that the
> entries written to the gart page table are valid and then the
> information written to the ring buffer is valid before updating the
> ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
> causes the CP to start fetching data from the ring.
Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
--- radeon_device.c.orig2013-09-10 08:55:05.0 +
+++ radeon_device.c 2013-09-10 09:12:17.0 +
@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
{
if (rdev->dummy_page.page)
return 0;
- rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
- if (rdev->dummy_page.page == NULL)
+ rdev->dummy_page.page = dma_alloc_coherent(&rdev->pdev->dev, PAGE_SIZE,
+ &rdev->dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+ if (!rdev->dummy_page.page)
return -ENOMEM;
- rdev->dummy_page.addr = pci_map_page(rdev->pdev, rdev->dummy_page.page,
- 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
if (pci_dma_mapping_error(rdev->pdev, rdev->dummy_page.addr)) {
dev_err(&rdev->pdev->dev, "Failed to DMA MAP the dummy page\n");
- __free_page(rdev->dummy_page.page);
- rdev->dummy_page.page = NULL;
+ radeon_dummy_page_fini(rdev);
return -ENOMEM;
}
return 0;
@@ -698,9 +696,8 @@ void radeon_dummy_page_fini(struct radeo
{
if (rdev->dummy_page.page == NULL)
return;
- pci_unmap_page(rdev->pdev, rdev->dummy_page.addr,
-
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> Op 04-09-13 05:41, Ben Skeggs schreef:
> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> > wrote:
> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >>> set, it will do a null deref down the line. Warn on that condition and
> >>> return an error.
> >>>
> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >>>
> >>> Reported-by: Pasi Kärkkäinen
> >>> Tested-by: Pasi Kärkkäinen
> >>> Signed-off-by: Ilia Mirkin
> >>> Cc: # 3.8+
> >>> ---
> >>>
> >>> I don't exactly understand what's going on, but this is just a
> >>> straightforward way to avoid a null deref that you see happens in the
> >>> bug. I haven't figured out the root cause of this, but it's getting
> >>> well into the "I have no idea how TTM works" space. However this seems
> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >>> node->pages as a list down, which will be dereferenced by
> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >>> dereferencing not happen, but it definitely was happening here, as you
> >>> can see in the bug.
> >>>
> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >>> since like I hope I was able to convey above, I'm just not really sure :)
> >> Not it really isn't appropriate..
> >>
> >> You'd have to call call nouveau_vm_map_sg_table instead, the only place
> >> that doesn't handle that correctly
> >> is where it's not expected to be called.
> >>
> >> Here, have a completely untested patch to fix things...
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device
> >> *dev,
> >> {
> >> struct nouveau_framebuffer *nouveau_fb;
> >> struct drm_gem_object *gem;
> >> + struct nouveau_bo *nvbo;
> >> int ret = -ENOMEM;
> >>
> >> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> >> if (!gem)
> >> return ERR_PTR(-ENOENT);
> >>
> >> + nvbo = nouveau_gem_object(gem);
> >> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> >> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram
> >> with"
> >> + " valid_domains=%08x\n", nvbo->valid_domains);
> >> + ret = -EINVAL;
> >> + goto err_unref;
> >> + }
> >> +
> > Definitely the right idea, we can't handle this case right now.
> > However, we may someday want/need to be able to scan out of system
> > memory, so this is the wrong place.
> >
> > I suspect the correct thing to do (which'll also handle the
> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> > a DMA-BUF backed object into VRAM.
> >
> > Sound OK?
> >
> If it has a WARN_ON or something that would be ok, I didn't find any other
> places that attempt to move buffers to VRAM though, so it's probably harmless.
>
So hmm.. I guess another patch is needed for the original issue in this thread.
Is someone going to submit that?
> When looking into this bug I noticed that nouveau_bo_vma_add needs to have a
> check for nvbo->page_shift == vma->vm->vmm->spg_shift,
> and only if the check is true it should map the page in TTM_PL_TT. Patch
> below.
> Should probably also be cc'd to stable.
>
Thanks! Is this patch ready to be merged?
-- Pasi
> ~Maarten
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 89b992e..355a1b7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
> nouveau_vm *vm,
>
> if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
> nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> + else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
> + nvbo->page_shift == vma->vm->vmm->spg_shift) {
> if (node->sg)
> nouveau_vm_map_sg_table(vma, 0, size, node);
> else
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 Johannes Obermayr changed: What|Removed |Added Attachment #84756|0 |1 is obsolete|| Attachment #84840|0 |1 is obsolete|| --- Comment #19 from Johannes Obermayr --- Created attachment 85550 --> https://bugs.freedesktop.org/attachment.cgi?id=85550&action=edit link libradeon only once Please try this patch. libradeon will be linked in egl_gallium.so only once. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: "ring test failed" on PA-RISC Linux
On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov wrote:
> Alex,
>
> 09.09.2013, в 21:43, Alex Deucher написал(а):
>
>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov wrote:
>>> Folks,
>>>
>>> We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
>>> native video options of the latest PA-RISC servers and workstations
>>> (these are ATIs, most of which are based on R100/R300/R420 chips) work
>>> correctly on this platform (big endian pa-risc).
>>>
>>> However, we hadn't much success. DRM fails every time with
>>> "ring test failed" for both AGP & PCI.
>>>
>>> Maybe you would give us some suggestions that we could check?
>>>
>>> Topic started here:
>>> http://www.spinics.net/lists/linux-parisc/msg04908.html
>>> And continued there:
>>> http://www.spinics.net/lists/linux-parisc/msg04995.html
>>> http://www.spinics.net/lists/linux-parisc/msg05006.html
>>>
>>> Problems we've already resolved without any signs of progress:
>>> - Checked the successful microcode load
>>> "parisc AGP GART code writes IOMMU entries in the wrong byte order and
>>> doesn't add the coherency information SBA code adds"
>>> "our PCI BAR setup doesn't really work very well together with the Radeon
>>> DRM address setup. DRM will generate addresses, which are even outside
>>> of the connected LBA"
>>>
>>> Things planned for a check:
>>> "The drivers/video/aty uses
>>> an endian config bit DRM doesn't use, but I haven't tested whether
>>> this makes a difference and how it is connected to the overall picture."
>>
>> I don't think that will any difference. radeon kms works fine on
>> other big endian platforms such as powerpc.
>
> Good! I'll opt it out then.
>
>>
>>>
>>> "The Rage128 product revealed a weakness in some motherboard
>>> chipsets in that there is no mechanism to guarantee
>>> that data written by the CPU to memory is actually in a readable
>>> state before the Graphics Controller receives an
>>> update to its copy of the Write Pointer. In an effort to alleviate this
>>> problem, we"ve introduced a mechanism into the
>>> Graphics Controller that will delay the actual write to the Write Pointer
>>> for some programmable amount of time, in
>>> order to give the chipset time to flush its internal write buffers to
>>> memory.
>>> There are two register fields that control this mechanism:
>>> PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
>>>
>>> In the radeon DRM codebase I didn't found anyone using/setting
>>> those registers. Maybe PA-RISC has some problem here?..."
>>
>> I doubt it. If you are using AGP, I'd suggest disabling it and first
>> try to get things working using the on chip gart rather than AGP.
>> Load radeon with agpmode=-1.
>
> Already tried this without any luck. Anyway, a radeon driver fallbacks
> to the PCI mode in our case, so does it really matter?
>
> In addition, people with PCI cards experiencing the same issue...
>
>> The on chip gart always uses cache
>> snooped pci transactions and the driver assumes pci is cache coherent.
>> On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
>> system ram. On PCIE asics, the gart table is stored in vram. The
>> gart page table maps system pages to a contiguous aperture in the
>> GPU's address space. The ring lives in gart memory. The GPU sees a
>> contiguous buffer and the gart mechanism handles the access to the
>> backing pages via the page table. I'd suggest verifying that the
>> entries written to the gart page table are valid and then the
>> information written to the ring buffer is valid before updating the
>> ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
>> causes the CP to start fetching data from the ring.
>
> Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
> dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
>
The dummy page isn't really going to help much. That page is just
used as a safety placeholder for gart entries that aren't mapped on
the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of
the backing pages for the gart. You may want to look there.
Alex
> --- radeon_device.c.orig2013-09-10 08:55:05.0 +
> +++ radeon_device.c 2013-09-10 09:12:17.0 +
> @@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
> {
> if (rdev->dummy_page.page)
> return 0;
> - rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL |
> __GFP_ZERO);
> - if (rdev->dummy_page.page == NULL)
> + rdev->dummy_page.page = dma_alloc_coherent(&rdev->pdev->dev,
> PAGE_SIZE,
> + &rdev->dummy_page.addr, GFP_DMA32|GFP_KERNEL);
> + if (!rdev->dummy_page.page)
> return -ENOMEM;
> - rdev->dummy_page.addr = pci_map_page(rdev->pdev,
> rdev->dummy_page.page,
> - 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
> if (pci_dma_mapping_error(rdev->pdev, rdev->dummy_page.addr)) {
> dev_err(&rdev->pdev->dev, "Fa
Re: drm/radeon: "ring test failed" on PA-RISC Linux
On 09/10/2013 02:37 PM, Alex Deucher wrote:
> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov wrote:
>> Alex,
>>
>> 09.09.2013, в 21:43, Alex Deucher написал(а):
>>
>>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov wrote:
Folks,
We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
native video options of the latest PA-RISC servers and workstations
(these are ATIs, most of which are based on R100/R300/R420 chips) work
correctly on this platform (big endian pa-risc).
However, we hadn't much success. DRM fails every time with
"ring test failed" for both AGP & PCI.
Maybe you would give us some suggestions that we could check?
Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html
Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
"parisc AGP GART code writes IOMMU entries in the wrong byte order and
doesn't add the coherency information SBA code adds"
"our PCI BAR setup doesn't really work very well together with the Radeon
DRM address setup. DRM will generate addresses, which are even outside
of the connected LBA"
Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether
this makes a difference and how it is connected to the overall picture."
>>>
>>> I don't think that will any difference. radeon kms works fine on
>>> other big endian platforms such as powerpc.
>>
>> Good! I'll opt it out then.
Actually, I am experiencing exactly the same problem on a Sam460ex ppc
system, at least as of 3.9 (the last time I tried it).
Very rarely the ringtest would pass, but then it would fail somewhere else.
I never could figure it out since as far as I could tell all the addresses
and logic was correct. It wasn't important enough for me to work more on it,
but I'd be happy to test code. I'm travelling for the next week and a half,
so I can't do anything right now.
One bug I found when working on drm/kms support for the ppc was that in
struct ttm_bus_placement the base address type was wrong: it should be
phys_addr_t, not unsigned long. The PPC460 is in 32-bit mode but physical
addresses are >32 bits.
The patch below fixes that. I always wanted to post this fix, but never got
around to it...
Regards,
Hans
Signed-off-by: Hans Verkuil
---
arch/powerpc/sysdev/ppc4xx_msi.c |6 +++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
include/drm/ttm/ttm_bo_api.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49b0659..fa33568 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1066,7 +1066,7 @@ int radeon_device_init(struct radeon_device *rdev,
if (rdev->rmmio == NULL) {
return -ENOMEM;
}
- DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)rdev->rmmio_base);
+ DRM_INFO("register mmio base: 0x%llx\n", (uint64_t)rdev->rmmio_base);
DRM_INFO("register mmio size: %u\n", (unsigned)rdev->rmmio_size);
/* io port mapping */
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3cb5d84..fcdb208 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -81,7 +81,7 @@ struct ttm_placement {
*/
struct ttm_bus_placement {
void*addr;
- unsigned long base;
+ phys_addr_t base;
unsigned long size;
unsigned long offset;
boolis_iomem;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: "ring test failed" on PA-RISC Linux
On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
> Alex,
>
> 09.09.2013, в 21:43, Alex Deucher написал(а):
>
> > On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov wrote:
> >> Folks,
> >>
> >> We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
> >> native video options of the latest PA-RISC servers and workstations
> >> (these are ATIs, most of which are based on R100/R300/R420 chips) work
> >> correctly on this platform (big endian pa-risc).
> >>
> >> However, we hadn't much success. DRM fails every time with
> >> "ring test failed" for both AGP & PCI.
> >>
> >> Maybe you would give us some suggestions that we could check?
> >>
> >> Topic started here:
> >> http://www.spinics.net/lists/linux-parisc/msg04908.html
> >> And continued there:
> >> http://www.spinics.net/lists/linux-parisc/msg04995.html
> >> http://www.spinics.net/lists/linux-parisc/msg05006.html
> >>
> >> Problems we've already resolved without any signs of progress:
> >> - Checked the successful microcode load
> >> "parisc AGP GART code writes IOMMU entries in the wrong byte order and
> >> doesn't add the coherency information SBA code adds"
> >> "our PCI BAR setup doesn't really work very well together with the Radeon
> >> DRM address setup. DRM will generate addresses, which are even outside
> >> of the connected LBA"
> >>
> >> Things planned for a check:
> >> "The drivers/video/aty uses
> >> an endian config bit DRM doesn't use, but I haven't tested whether
> >> this makes a difference and how it is connected to the overall picture."
> >
> > I don't think that will any difference. radeon kms works fine on
> > other big endian platforms such as powerpc.
>
> Good! I'll opt it out then.
>
> >
> >>
> >> "The Rage128 product revealed a weakness in some motherboard
> >> chipsets in that there is no mechanism to guarantee
> >> that data written by the CPU to memory is actually in a readable
> >> state before the Graphics Controller receives an
> >> update to its copy of the Write Pointer. In an effort to alleviate this
> >> problem, we"ve introduced a mechanism into the
> >> Graphics Controller that will delay the actual write to the Write Pointer
> >> for some programmable amount of time, in
> >> order to give the chipset time to flush its internal write buffers to
> >> memory.
> >> There are two register fields that control this mechanism:
> >> PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
> >>
> >> In the radeon DRM codebase I didn't found anyone using/setting
> >> those registers. Maybe PA-RISC has some problem here?..."
> >
> > I doubt it. If you are using AGP, I'd suggest disabling it and first
> > try to get things working using the on chip gart rather than AGP.
> > Load radeon with agpmode=-1.
>
> Already tried this without any luck. Anyway, a radeon driver fallbacks
> to the PCI mode in our case, so does it really matter?
>
> In addition, people with PCI cards experiencing the same issue...
>
> > The on chip gart always uses cache
> > snooped pci transactions and the driver assumes pci is cache coherent.
> > On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
> > system ram. On PCIE asics, the gart table is stored in vram. The
> > gart page table maps system pages to a contiguous aperture in the
> > GPU's address space. The ring lives in gart memory. The GPU sees a
> > contiguous buffer and the gart mechanism handles the access to the
> > backing pages via the page table. I'd suggest verifying that the
> > entries written to the gart page table are valid and then the
> > information written to the ring buffer is valid before updating the
> > ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
> > causes the CP to start fetching data from the ring.
>
> Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
> dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
Is this platform enabling the SWIOTLB layer? The reason I am asking is
b/c if you do indeed enable it you end up using the TTM DMA pool
which allocates pages using the dma_alloc_coherent - which means that
all of the pages that come out of TTM are already 'DMA' mapped.
And that means the radeon_gart_bind and all its friends
use the DMA addresses that have been constructed by SWIOTLB IOMMU.
Perhaps the PA-RISC IOMMU creates the DMA addresses differently?
When the card gets programmed, you do end up using ttm_agp_bind right?
I am wondering if something like this:
https://lkml.org/lkml/2010/12/6/512
is needed to pass in the right DMA address?
>
> --- radeon_device.c.orig 2013-09-10 08:55:05.0 +
> +++ radeon_device.c 2013-09-10 09:12:17.0 +
> @@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
> {
> if (rdev->dummy_page.page)
> return 0;
> - rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
> - if (rdev->dummy_page.page == NULL)
> + rdev->dummy_page.page = dma_alloc_
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #10 from Alex Deucher --- Created attachment 85563 --> https://bugs.freedesktop.org/attachment.cgi?id=85563&action=edit possible fix The attached patch should fix the issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, 09 Sep 2013, "Rafael J. Wysocki" wrote: > On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote: >> On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: >> > Hi, >> > >> > On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: >> > > Hi Aaaron, >> > > >> > > Have we grown any clue meanwhile about which Intel boxes need this and >> > > for >> > > which we still need to keep the acpi backlight around? >> > >> > First of all, there is a bunch of boxes where ACPI backlight works >> > incorrectly >> > because of the Win8 compatibility issue. [In short, if we say we are >> > compatible >> > with Win8, the backlight AML goes into a special code path that is broken >> > on >> > those machines. Presumably Win8 uses native backlight control on them and >> > that >> > AML code path is never executed there.] The collection of machines with >> > this >> > problem appears to be kind of random (various models from various >> > vendors), but >> > I *think* they are machines that originally shipped with Win7 with a Win8 >> > "upgrade" option (which in practice requires the BIOS to be updated >> > anyway). >> > >> > Because of that, last time we tried to switch all of the systems using i915 >> > and telling the BIOS that they are compatible with Win8 over to native >> > backlight >> > control, but that didn't work for two reasons. The first reason is that >> > some >> > user space doesn't know how to use intel_backlight and needs to be taught >> > about >> > that (so some systems are just not ready for that switch). The second and >> > more >> > fundamental reason is that the native backlight control simply doesn't >> > work on >> > some machines and we don't seem to have any idea why and how to debug this >> > particular problem (mostly because we don't have enough information and we >> > don't know what to ask for). >> > >> > > I've grown _very_ reluctant to just adding tons of quirks to our driver >> > > for >> > > the backlight. >> > > >> > > Almost all the quirks we have added recently (or that have been proposed >> > > to be added) are for the backlight. Imo that indicates we get something >> > > fundamentally wrong ... >> > >> > This thing isn't really a quirk. It rather is an option for the users of >> > the systems where ACPI backlight doesn't work to switch over to the native >> > backlight control using a command line switch. This way they can at least >> > *see* if the native backlight control works for them and (hopefully) report >> > problems if that's not the case. This gives us a chance to get more >> > information about what the problem is and possibly to make some progress >> > without making changes for everyone, reverting those changes when they >> > don't >> > work etc. >> > >> > An alternative for them is to pass acpi_osi="!Windows 2012" which will >> > probably >> > make the ACPI backlight work for them again, but this rather is a step >> > back, >> > because we can't possibly learn anything new from that. >> >> If Win8 is as broken as we are I'm ok with the module option. It just >> sounded to me like right now we don't know of a way to make all machines >> somewhat happy, combined with the other pile of random backlight issues >> the assumption that we do something (maybe something a bit racy) that >> windows doesn't do isn't too far-fetched. So I'm not wary of the machines >> where the aml is busted for acpi_os=win8, but for the others where this >> broke stuff. >> >> Or do I miss something here? > > The ACPI video driver doesn't do anything new now. It only does things that > did work before we started to tell BIOSes we're compatible with Win8. The > reason why they don't work on some machines now is not related to whether or > not Win8 is broken, but to what is there in the ACPI tables on those machines. > That *is* pure garbage, but Win8 users don't see that (presumably, because > Win8 does't execute the AML in question). We don't see that either with > acpi_osi="!Windows 2012" (because then we don't execute that AML either). > > Whether or not Win8 is broken doesn't matter here. What matters is that we > have to deal with broken AML somehow. > > One way may be to tell everyone affected by this to pass > acpi_osi="!Windows 2012" in the kernel command line or possibly create a > blacklist of those machines in the kernel (which Felipe has been pushing for > recently) and wash our hands clean of this, but that leaves some exceptionally > bad taste in my mouth. > > The alternative is to try to use native backlight in i915, which we did, but > that didn't work on some machines. I don't think we will know why it didn't > work there before we collect some more information and that's not possible > without user testing. So, the idea is to make that testing possible without > hacking the kernel and that's why we're introducing the new command line > switch. And we're going to ask users to try it and report back. The thing tha
Re: Stereo 3D v3
On Sun, Sep 08, 2013 at 04:03:52PM +0100, Damien Lespiau wrote: > On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote: > > The series implements SET_CAP as a per _file_ capability set, not per > > master. I like it this way. Note that with SET_VERSION, we already > > have a per _master_ capability set. Compared to SET_CAP it only allows > > incremental capability changes, but that's fine I think. > > > > However, the problem with per-master capabilities (SET_VERSION) is > > that we currently have no way to control which master a > > graphics-server gets assigned to. If it's started in background, it > > will get the same master as the foreground compositor. Therefore, we > > don't want per-master client-capabilities. It's wrong and breaks > > existing setups (same as SET_VERSION, and everyone knows that). I also > > don't see a reason to bind capabilities to a master object. > > > > SET_CAP describes what the *calling client* understands and can work > > with. And this is logically bound to drm_file (as it represents a > > client). On the other hand, GET_CAP describes what the *device* > > understands and provides. This is obviously bound to a "drm_device". A > > "drm_master" object allows to split GET_CAP capabilities and resources > > across multiple logical master objects. But these resemble a > > drm_device much more than a drm_file. > > > > So no, this capability is not dropped with a change in master. It's > > independent of the active/bound master. It just describes what a > > client sees or not sees. > > Right, that sums it up. Note that while I've made stereo_allowed a per > fd thing (which is what I wanted in that case, alter the reality viewed > by the process opening the file), SET_CAP itself it marked as master > only. This can be changed in the future to provide per-cap access > restrictions if needed. This could be renamed to SET_CLIENT_CAP and also drop the master requirement. (That some capabilities only affect master ioctls is irrelevant I think, as the client will be master at that time.) That would reduce the confusion between the device caps and the session caps. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 10 Sep 2013, Matthew Garrett wrote: > On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote: > >> I think the parameter "Does the ACPI backlight interface work or not" >> belongs to the ACPI video driver. > > That depends on how Windows 8 works. If Windows 8 policy is handled by > the GPU drivers then it belongs in i915. If it's handled by the ACPI > code then it belongs in the ACPI code. I fail to see the logic. Windows 8 policy dictates whether we can use the AML code or not. IMHO, ACPI code is in the best position to figure this out and quirk as necessary. It's the part that knows about Windows 8, not i915. > But I have no way of determining that, whereas you work for a company > that produces a Windows 8 video driver… Here I do see the logic. However see signature; I'm not in the best of positions to figure out things about Windows 8 video drivers. ;) But I'll see what I can do. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 Alex Deucher changed: What|Removed |Added Attachment #107911|0 |1 is obsolete|| --- Comment #29 from Alex Deucher --- Created attachment 108011 --> https://bugzilla.kernel.org/attachment.cgi?id=108011&action=edit possible fix Sorry, I had the wrong chip check in the last version. This patch should be correct. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #11 from John --- Hi Alex, Thanks for the quick turn around. Looking at the patch it seems to be for RV770 and RV780 will it still work for our older cards? I am not home right now so I cannot test it to get the answer. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #12 from Alex Deucher --- (In reply to comment #11) > Hi Alex, > > Thanks for the quick turn around. > > Looking at the patch it seems to be for RV770 and RV780 will it still work > for our older cards? Yes. It covers the entire 7xx family of cards. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #14 from Alex Deucher --- Created attachment 85578 --> https://bugs.freedesktop.org/attachment.cgi?id=85578&action=edit disable various dpm features I would suggest disabling various dpm features and see if you can narrow down which, if any, help. This patch disables just about everything. ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) is what actually sets the dynamic performance switching into motion. Prior to that the hw is locked into the low performance level. I sounds like there is some bad parameter that is causing a lock up when the smc enables state switching. Separate from the patch can you also try changing the ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) call in ni_dpm_set_power_state() to low (RADEON_DPM_FORCED_LEVEL_LOW) or high (RADEON_DPM_FORCED_LEVEL_HIGH) rather than auto? See if you still get a lock up. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #15 from Alex Deucher --- Another thing worth checking, what is the value of module_index passed to radeon_atom_init_mc_reg_table() in ni_initialize_mc_reg_table() in ni_dpm.c on your system? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 Erdem U. Altınyurt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #47 from Erdem U. Altınyurt --- Hi Aaron, Well, without the patch, I can verify that bfgminer started to work on my HD6850, using mesa/llvm/libclc trunk. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64225] bfgminer --scyte generates Segmentation Fault on Northern Island
https://bugs.freedesktop.org/show_bug.cgi?id=64225 --- Comment #5 from Erdem U. Altınyurt --- Since "bfgminer --benchmark --scrypt " command produces the error message of: "Cannot use benchmark mode with scrypt" I cannot report if scrypt is start to work or not. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69196] New: gpu lockup and full crash when starting some games in wine
https://bugs.freedesktop.org/show_bug.cgi?id=69196 Priority: medium Bug ID: 69196 Assignee: dri-devel@lists.freedesktop.org Summary: gpu lockup and full crash when starting some games in wine Severity: normal Classification: Unclassified OS: Linux (All) Reporter: maxmust...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 85587 --> https://bugs.freedesktop.org/attachment.cgi?id=85587&action=edit kernel log from the crash First of I searched the bugs and found some similar looking bugs but none which stroke me as the same bug. lspci tells me my graphics card is 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770 GHz Edition] I always use everything mesa and kernel vanilla from git. My kernel has the version 3.11.0-1-08716-g26b0332-dirty.The mesa checkout is 4 days old. glxinfo tells me Mesa 9.3.0-devel (git-0f6fce1) (if this is relevant) I tested it with hyperz enabled and disabled both time it failed the same way. First the display turns dark (no signal) and then after being responsive for a few seconds the pc crashes completly. If I kill the process in time it doesn't die completly on me. I don't know if this is of any relevance but the firmware for the card was missing and I grabbed the file from here: http://people.freedesktop.org/~agd5f/radeon_ucode/VERDE_smc.bin I'll refrain from parsin anything specific from the kernel log since I don't know which lines are relevant -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
[ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley wrote: >> >> I'm also a bit bummed that hw acceleration of video doesn't seem to >> work on Haswell, meaning that full-screen is now a jerky mess. I fear >> that that is user-space libraries/X.org, but I thought I'd mention it >> in the hope of getting a "oh, it's working for us, you'll get a fix >> for it soon". > > Can you give a little more detail about video not working? Video > accel should work fine with the current versions of libva/intel-driver > available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. Non-HD content seems to be fine even full-screen. Either just because it's so much easier to do, or because some level of scaling is hw-accelerated. It may well be that I'm using chrome (and chrome seems to tend to use its own library versions), and firefox indeed seems to be a bit better. But by "a bit better" I mean closer to full frame rate in full-screen, but lots of tearing - and it was stil using 70% CPU when displaying in a window. So I think firefox is also still doing everything in software but may be better about using threads for it. My previous i5-670 which was inferior in almost every other way didn't have these problems.. It had the same 2560x1440 display. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tuesday, September 10, 2013 04:53:40 PM Jani Nikula wrote: > On Mon, 09 Sep 2013, "Rafael J. Wysocki" wrote: > > On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote: > >> On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: > >> > Hi, > >> > > >> > On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: > >> > > Hi Aaaron, > >> > > > >> > > Have we grown any clue meanwhile about which Intel boxes need this and > >> > > for > >> > > which we still need to keep the acpi backlight around? > >> > > >> > First of all, there is a bunch of boxes where ACPI backlight works > >> > incorrectly > >> > because of the Win8 compatibility issue. [In short, if we say we are > >> > compatible > >> > with Win8, the backlight AML goes into a special code path that is > >> > broken on > >> > those machines. Presumably Win8 uses native backlight control on them > >> > and that > >> > AML code path is never executed there.] The collection of machines with > >> > this > >> > problem appears to be kind of random (various models from various > >> > vendors), but > >> > I *think* they are machines that originally shipped with Win7 with a Win8 > >> > "upgrade" option (which in practice requires the BIOS to be updated > >> > anyway). > >> > > >> > Because of that, last time we tried to switch all of the systems using > >> > i915 > >> > and telling the BIOS that they are compatible with Win8 over to native > >> > backlight > >> > control, but that didn't work for two reasons. The first reason is that > >> > some > >> > user space doesn't know how to use intel_backlight and needs to be > >> > taught about > >> > that (so some systems are just not ready for that switch). The second > >> > and more > >> > fundamental reason is that the native backlight control simply doesn't > >> > work on > >> > some machines and we don't seem to have any idea why and how to debug > >> > this > >> > particular problem (mostly because we don't have enough information and > >> > we > >> > don't know what to ask for). > >> > > >> > > I've grown _very_ reluctant to just adding tons of quirks to our > >> > > driver for > >> > > the backlight. > >> > > > >> > > Almost all the quirks we have added recently (or that have been > >> > > proposed > >> > > to be added) are for the backlight. Imo that indicates we get something > >> > > fundamentally wrong ... > >> > > >> > This thing isn't really a quirk. It rather is an option for the users of > >> > the systems where ACPI backlight doesn't work to switch over to the > >> > native > >> > backlight control using a command line switch. This way they can at > >> > least > >> > *see* if the native backlight control works for them and (hopefully) > >> > report > >> > problems if that's not the case. This gives us a chance to get more > >> > information about what the problem is and possibly to make some progress > >> > without making changes for everyone, reverting those changes when they > >> > don't > >> > work etc. > >> > > >> > An alternative for them is to pass acpi_osi="!Windows 2012" which will > >> > probably > >> > make the ACPI backlight work for them again, but this rather is a step > >> > back, > >> > because we can't possibly learn anything new from that. > >> > >> If Win8 is as broken as we are I'm ok with the module option. It just > >> sounded to me like right now we don't know of a way to make all machines > >> somewhat happy, combined with the other pile of random backlight issues > >> the assumption that we do something (maybe something a bit racy) that > >> windows doesn't do isn't too far-fetched. So I'm not wary of the machines > >> where the aml is busted for acpi_os=win8, but for the others where this > >> broke stuff. > >> > >> Or do I miss something here? > > > > The ACPI video driver doesn't do anything new now. It only does things that > > did work before we started to tell BIOSes we're compatible with Win8. The > > reason why they don't work on some machines now is not related to whether or > > not Win8 is broken, but to what is there in the ACPI tables on those > > machines. > > That *is* pure garbage, but Win8 users don't see that (presumably, because > > Win8 does't execute the AML in question). We don't see that either with > > acpi_osi="!Windows 2012" (because then we don't execute that AML either). > > > > Whether or not Win8 is broken doesn't matter here. What matters is that we > > have to deal with broken AML somehow. > > > > One way may be to tell everyone affected by this to pass > > acpi_osi="!Windows 2012" in the kernel command line or possibly create a > > blacklist of those machines in the kernel (which Felipe has been pushing for > > recently) and wash our hands clean of this, but that leaves some > > exceptionally > > bad taste in my mouth. > > > > The alternative is to try to use native backlight in i915, which we did, but > > that didn't work on some machines. I don't think we will know why
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #18 from Alex Deucher --- (In reply to comment #17) > (In reply to comment #15) > > Another thing worth checking, what is the value of module_index passed to > > radeon_atom_init_mc_reg_table() in ni_initialize_mc_reg_table() in ni_dpm.c > > on your system? > > How can I get it? Should I print it in dmesg? yes, that would be great. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
Hi The regular flash plugin 10.2 doesn't have vaapi (Intel) support The Chrome flash plugin (10.7?) doesn't have any vaapi or vdpau support You best option is to install the vdpau to vaapi wrapper and disable the Chrome flash plugin https://github.com/i-rinat/libvdpau-va-gl This will revert you back to the older 10.2 flash version which should work I think I also had to override a few settings in the flash dot file to get it to skip GPU validation along with following the instruction for the above project Its quite convoluted but least it makes YouTube work Cheers Mike [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley wrote: >> >> I'm also a bit bummed that hw acceleration of video doesn't seem to >> work on Haswell, meaning that full-screen is now a jerky mess. I fear >> that that is user-space libraries/X.org, but I thought I'd mention it >> in the hope of getting a "oh, it's working for us, you'll get a fix >> for it soon". > > Can you give a little more detail about video not working? Video > accel should work fine with the current versions of libva/intel-driver > available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. Non-HD content seems to be fine even full-screen. Either just because it's so much easier to do, or because some level of scaling is hw-accelerated. It may well be that I'm using chrome (and chrome seems to tend to use its own library versions), and firefox indeed seems to be a bit better. But by "a bit better" I mean closer to full frame rate in full-screen, but lots of tearing - and it was stil using 70% CPU when displaying in a window. So I think firefox is also still doing everything in software but may be better about using threads for it. My previous i5-670 which was inferior in almost every other way didn't have these problems.. It had the same 2560x1440 display. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #22 from Alex Deucher --- Can you try a vanilla xf86-video-ati rather than the ubuntu version? This looks like it may be specific to their version. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Tue, Sep 10, 2013 at 08:49:58AM -0700, Linus Torvalds writes : > [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] > > On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley > wrote: > >> > >> I'm also a bit bummed that hw acceleration of video doesn't seem to > >> work on Haswell, meaning that full-screen is now a jerky mess. I fear > >> that that is user-space libraries/X.org, but I thought I'd mention it > >> in the hope of getting a "oh, it's working for us, you'll get a fix > >> for it soon". > > > > Can you give a little more detail about video not working? Video > > accel should work fine with the current versions of libva/intel-driver > > available in Fedora 19 - assuming that's what you're using. > > It is indeed F19. > > Easy test: go to youtube, and watch things that are in 1080p HD. They > play fine in a window (using about 70% CPU), but full-screened to > 2560x1440 they play at about one or two frames per second. Yep. I see the same. Chrome is brain dead and appears to simply rely on Flash + FFmpeg software codecs. At least with Firefox you know it will suck and not be hw accelerated. Unless that has changed... > > Non-HD content seems to be fine even full-screen. Either just because > it's so much easier to do, or because some level of scaling is > hw-accelerated. SD content should be relatively fine with software codecs. Ideally, full-screen would disable composition and use hw-overlay in addition to an actual hw accel codec, h.264 or vp8 for html5 video. But that is not the case. That being said HSW does not support vp8 hw decode. > > It may well be that I'm using chrome (and chrome seems to tend to use > its own library versions), and firefox indeed seems to be a bit > better. But by "a bit better" I mean closer to full frame rate in > full-screen, but lots of tearing - and it was stil using 70% CPU when > displaying in a window. So I think firefox is also still doing > everything in software but may be better about using threads for it. Sadly none of those would be hw accel without some specific flavor of flash plugin that favors hw accel over FFmpeg software accel (i.e., has older flash + wrapper for vdpau or vaapi). As someone else in this thread mentioned, it is quite a pain in the arse. Ironically, it is relatively trivial for me to do a chromium browser build form source myself and enable libva/intel-driver HW accel, h.264. And say screw you to flash et al, and leave that out. And that will work fine for html5 video on youtube with fallback to SW accel for VP8 based content. Why it is a chore for Google is not clear to me... Sean > > My previous i5-670 which was inferior in almost every other way didn't > have these problems.. It had the same 2560x1440 display. > > Linus pgpPtT56X6tii.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #16 from Alexandre Demers --- (In reply to comment #14) > Created attachment 85578 [details] [review] > disable various dpm features > > I would suggest disabling various dpm features and see if you can narrow > down which, if any, help. This patch disables just about everything. > > ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) is what > actually sets the dynamic performance switching into motion. Prior to that > the hw is locked into the low performance level. I sounds like there is > some bad parameter that is causing a lock up when the smc enables state > switching. > > Separate from the patch can you also try changing the > ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) call in > ni_dpm_set_power_state() to low (RADEON_DPM_FORCED_LEVEL_LOW) or high > (RADEON_DPM_FORCED_LEVEL_HIGH) rather than auto? See if you still get a > lock up. I'll try it later today. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #30 from Quallenauge --- The last patch works for me :) Thanks! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #21 from Weber K. ---
Hello!
I think I found a workaround!
At this file:
https://github.com/RAOF/xf86-video-ati/blob/master/src/radeon_dri2.c
At line 608:
Changed from:
xorg_list_for_each_entry(ref, &pClientEventsPriv->reference_list,
link) {
ref->valid = FALSE;
radeon_dri2_unref_buffer(ref->front);
radeon_dri2_unref_buffer(ref->back);
}
Replaced by:
xorg_list_for_each_entry(ref, &pClientEventsPriv->reference_list,
link) {
if (ref->valid) {
ref->valid = FALSE;
radeon_dri2_unref_buffer(ref->front);
radeon_dri2_unref_buffer(ref->back);
}
}
I just checked valid before the calls, but I still cannot find what is making
double calls...
Maybe its because I have two boards? Onboard HD4250 e PCIE HD6850?
Thanks!
Weber Kai
bash-4.2# lspci
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880
[Radeon HD 4250]
01:05.1 Audio device: Advanced Micro Devices [AMD] nee ATI RS880 HDMI Audio
[Radeon HD 4200 Series]
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts
PRO [ATI Radeon HD 6800 Series]
02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Barts HDMI Audio
[Radeon HD 6800 Series]
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman wrote: > Alex Deucher writes: > >> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf >> wrote: >> >>> IIRC Alex said the sanity checks are expensive and boot-time could be >>> improved by dropping them. Maybe he can chime in? >> >> They shouldn't be necessary with a proper shutdown, but in this >> particular case, they are not very expensive. What is expensive is >> having a separate sanity check functions for all the various hw blocks >> to teardown everything on startup prior to starting it up in case >> kexec, etc. left the system in a bad state. It ends up amounting to a >> full tear down sequence followed by a full start up sequence every >> time you load the driver. >> >> I can't really comment on the first patch, but the rest seem fine. > > Let me reask the question just a little bit. > > Is it the sanity checks that are expensive? Or is it the > reinitialization that is triggered by the sanity checks that is > expensive? > > From what Christian said in the other reply it sounds like this is a > game we will never completely win, but it would be nice to have half a > chance in the kexec on panic case to have video. So I am curious to > know if the checks are expensive when we are coming at hardware in a > clean state. The particular sanity checks from this patch set are not expensive, but we had previously discussed more extensive sanity checks for other aspects of the chips in prior conversations. Prior to this patch set, the hw is not torn down properly (might have been in the middle of DMA for example) when kexec happens. That's why the sanity checks were added in the first place. With this patch set, the sanity checks shouldn't be necessary. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: "ring test failed" on PA-RISC Linux
On Mon, 2013-09-09 at 20:44 +0400, Alex Ivanov wrote: > > Things planned for a check: > "The drivers/video/aty uses > an endian config bit DRM doesn't use, but I haven't tested whether > this makes a difference and how it is connected to the overall picture." The radeon driver works on PPC, so this can't really be your problem FWIW. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: fix cmdstream size check
Need to check size+offset against bo size (duh!).. now we have a test
case to make sure I've done it right:
https://github.com/freedreno/msmtest/blob/master/submittest.c
Also, use DRM_ERROR() for error case traces, which makes debugging
userspace easier when enabling debug traces is too much.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 3e1ef3a..5281d4b 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -78,7 +78,7 @@ static int submit_lookup_objects(struct msm_gem_submit
*submit,
}
if (submit_bo.flags & BO_INVALID_FLAGS) {
- DBG("invalid flags: %x", submit_bo.flags);
+ DRM_ERROR("invalid flags: %x\n", submit_bo.flags);
ret = -EINVAL;
goto out_unlock;
}
@@ -92,7 +92,7 @@ static int submit_lookup_objects(struct msm_gem_submit
*submit,
*/
obj = idr_find(&file->object_idr, submit_bo.handle);
if (!obj) {
- DBG("invalid handle %u at index %u", submit_bo.handle,
i);
+ DRM_ERROR("invalid handle %u at index %u\n",
submit_bo.handle, i);
ret = -EINVAL;
goto out_unlock;
}
@@ -100,7 +100,7 @@ static int submit_lookup_objects(struct msm_gem_submit
*submit,
msm_obj = to_msm_bo(obj);
if (!list_empty(&msm_obj->submit_entry)) {
- DBG("handle %u at index %u already on submit list",
+ DRM_ERROR("handle %u at index %u already on submit
list\n",
submit_bo.handle, i);
ret = -EINVAL;
goto out_unlock;
@@ -216,8 +216,9 @@ static int submit_bo(struct msm_gem_submit *submit,
uint32_t idx,
struct msm_gem_object **obj, uint32_t *iova, bool *valid)
{
if (idx >= submit->nr_bos) {
- DBG("invalid buffer index: %u (out of %u)", idx,
submit->nr_bos);
- return EINVAL;
+ DRM_ERROR("invalid buffer index: %u (out of %u)\n",
+ idx, submit->nr_bos);
+ return -EINVAL;
}
if (obj)
@@ -239,7 +240,7 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
int ret;
if (offset % 4) {
- DBG("non-aligned cmdstream buffer: %u", offset);
+ DRM_ERROR("non-aligned cmdstream buffer: %u\n", offset);
return -EINVAL;
}
@@ -266,7 +267,7 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
return -EFAULT;
if (submit_reloc.submit_offset % 4) {
- DBG("non-aligned reloc offset: %u",
+ DRM_ERROR("non-aligned reloc offset: %u\n",
submit_reloc.submit_offset);
return -EINVAL;
}
@@ -276,7 +277,7 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
if ((off >= (obj->base.size / 4)) ||
(off < last_offset)) {
- DBG("invalid offset %u at reloc %u", off, i);
+ DRM_ERROR("invalid offset %u at reloc %u\n", off, i);
return -EINVAL;
}
@@ -374,14 +375,15 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
goto out;
if (submit_cmd.size % 4) {
- DBG("non-aligned cmdstream buffer size: %u",
+ DRM_ERROR("non-aligned cmdstream buffer size: %u\n",
submit_cmd.size);
ret = -EINVAL;
goto out;
}
- if (submit_cmd.size >= msm_obj->base.size) {
- DBG("invalid cmdstream size: %u", submit_cmd.size);
+ if ((submit_cmd.size + submit_cmd.submit_offset) >=
+ msm_obj->base.size) {
+ DRM_ERROR("invalid cmdstream size: %u\n",
submit_cmd.size);
ret = -EINVAL;
goto out;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #17 from Alexandre Demers --- (In reply to comment #15) > Another thing worth checking, what is the value of module_index passed to > radeon_atom_init_mc_reg_table() in ni_initialize_mc_reg_table() in ni_dpm.c > on your system? How can I get it? Should I print it in dmesg? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #24 from Weber K. --- Looking at neuromancer Xorg log, I found out: [ 7.278] (--) RADEON(0): Chipset: "SUMO" (ChipID = 0x9641) [ 7.548] (--) RADEON(G0): Chipset: "TURKS" (ChipID = 0x6741) I think its a problem only with two devices with radeon driver... After closing client, the destroy buffer is called twice, and causes the error... I can workaround, but I cant fix it the right way... I have no experience with Xorg or radeon driver... I dont know either how to edit the subject of the bug... Please... Help us... Thanks in advance! Weber Kai -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #23 from Weber K. --- Hi! Ive found that (for me) this layout is causing the error: Section "ServerLayout" Identifier "My X Server" Screen 0 "LeftScreen" 0 0 Screen 1 "RightScreen" RightOf "LeftScreen" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection If I remove "Screen 1" then the error dont occur... Both devices are using radeon driver... I cannot test if the error occur only when both devices are radeon, or if having two Screens of any type... I think the destroy buffer is called twice because of two screens... Anyway, the workaround of checking "valid" value fixes this issue for me... Sorry, I cant test vanilla, I am using Slackware64... Ive downloaded the source DVD and changed x11.SlackBuild... Only changed CFLAGS to -O0 -g3 and removed "strip" symbols... Thanks... Weber Kai -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Tue, Sep 10, 2013 at 1:50 PM, Sean V Kelley wrote: > On Tue, Sep 10, 2013 at 08:49:58AM -0700, Linus Torvalds writes : >> [ Dave - your linux.ie email generates bounces for me, trying redhat instead >> ] >> >> On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley >> wrote: >> >> >> >> I'm also a bit bummed that hw acceleration of video doesn't seem to >> >> work on Haswell, meaning that full-screen is now a jerky mess. I fear >> >> that that is user-space libraries/X.org, but I thought I'd mention it >> >> in the hope of getting a "oh, it's working for us, you'll get a fix >> >> for it soon". >> > >> > Can you give a little more detail about video not working? Video >> > accel should work fine with the current versions of libva/intel-driver >> > available in Fedora 19 - assuming that's what you're using. >> >> It is indeed F19. >> >> Easy test: go to youtube, and watch things that are in 1080p HD. They >> play fine in a window (using about 70% CPU), but full-screened to >> 2560x1440 they play at about one or two frames per second. > > Yep. I see the same. Chrome is brain dead and appears to simply > rely on Flash + FFmpeg software codecs. At least with Firefox you > know it will suck and not be hw accelerated. Unless that has changed... > > > Ironically, it is relatively trivial for me to do a chromium browser > build form source myself and enable libva/intel-driver HW accel, h.264. And > say > screw you to flash et al, and leave that out. And that will > work fine for html5 video on youtube with fallback to SW accel for VP8 > based content. Why it is a chore for Google is not clear to me... Google actually blacklists hardware video acceleration for Linux x86 in Chromium. My builds are based on ChromeOS' browser. That's how I get around it. For more details... https://codereview.chromium.org/16430003/ Sean > > Sean > >> >> My previous i5-670 which was inferior in almost every other way didn't >> have these problems.. It had the same 2560x1440 display. >> >> Linus -- Sean V. Kelley Open Source Technology Center / SSG Intel Corp. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Wed, Sep 11, 2013 at 1:49 AM, Linus Torvalds wrote: > [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] Uggh no worries, I read my list mail from gmail mostly anyways, so if its on a list I'll probably see it. >> Can you give a little more detail about video not working? Video >> accel should work fine with the current versions of libva/intel-driver >> available in Fedora 19 - assuming that's what you're using. > > It is indeed F19. > > Easy test: go to youtube, and watch things that are in 1080p HD. They > play fine in a window (using about 70% CPU), but full-screened to > 2560x1440 they play at about one or two frames per second. It doesn't sound like you are using hw accelerated video at all and its just sw renderered flash, In which case it could be a CPU issue, is the cpu freq scaling working correctly? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #25 from lbdkm...@sharklasers.com --- Yes, this, aparently, only happens in dual AMD graphics laptops (with llano)... and I found a workaround: you have to disable the second (discrete) GPU: echo OFF > /sys/kernel/debug/vgaswitcheroo/switch and it will not crash anymore... Sadly, vgaswitcheroo throws a big warning in dmesg: http://pastebin.com/rXj8rrZa (I'm using kernel 3.11.0-6 from ubuntu's proposed repos) , after which "/sys/kernel/debug/vgaswitcheroo/" disappears completely and I'm not able to use the dGPU until the next boot. I will have to report this.. dunno where though. (and also, I always get a black screen after resume from suspend to RAM). as I said before, the patch "helped", i.e., made it harder to crash, but apps (glxgears, vlc, mplayer + gl) will crash nonetheless. I hope this helps. And I want to thank the devs for their great job with the radeon FOSS driver! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: fix return value check in ERR_PTR()
On Tue, Sep 10, 2013 at 6:56 PM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun
good catch, thanks
Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 6b5a6c8..3462def 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -40,9 +40,9 @@ static struct page **get_pages(struct drm_gem_object *obj)
> }
>
> msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
> - if (!msm_obj->sgt) {
> + if (IS_ERR(msm_obj->sgt)) {
> dev_err(dev->dev, "failed to allocate sgt\n");
> - return ERR_PTR(-ENOMEM);
> + return ERR_CAST(msm_obj->sgt);
> }
>
> msm_obj->pages = p;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #13 from Dieter Nützel --- Hurray Alex, your possible fix from Comment 10 solve it halfway or maybe fully even on my slow Duron 1800, RV730 AGP (4650), if we separate the mosaic into a new bug entry. The SPEED is there, now. I can play 2 H.264 VDPAU accelerated videos (854x480 and 1280x720) simultaneously with ~35% idle rest on this little system. Have a look at 2-times-mplayer-konsole.png attachment. I've tested it with AGP and PCIE mode, both with same results. The mosaic problem IS mouse cursor (hardware cursor?) related! If the (big/fullscreen) video window coming up 'under' (over?) the mouse cursor position I get immediately mosaic. When a smaller video window starts from mouse cursor postion away UVD is excellent. Mosaic starts then not until mouse cursor move over the video window. With mplayer this could be faster reached if one seek into the video window. See 2-times-mplayer-mosaic.png attachment. Tested with AGP and PCIE mode. Very nice! -Dieter -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #14 from Dieter Nützel --- Created attachment 85591 --> https://bugs.freedesktop.org/attachment.cgi?id=85591&action=edit 2-times-mplayer-konsole.png -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #15 from Dieter Nützel --- Created attachment 85592 --> https://bugs.freedesktop.org/attachment.cgi?id=85592&action=edit 2-times-mplayer-mosaic.png -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #16 from Dieter Nützel --- Created attachment 85593 --> https://bugs.freedesktop.org/attachment.cgi?id=85593&action=edit dmesg-drm-next-3.12-AGP-dpm-1-fix-fallback-for-empty-UVD-clocks.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #17 from Dieter Nützel --- Created attachment 85594 --> https://bugs.freedesktop.org/attachment.cgi?id=85594&action=edit dmesg-drm-next-3.12-PCIE-dpm-1-fix-fallback-for-empty-UVD-clocks.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #19 from Alexandre Demers --- (In reply to comment #16) > (In reply to comment #14) > > Created attachment 85578 [details] [review] [review] > > disable various dpm features > > > > I would suggest disabling various dpm features and see if you can narrow > > down which, if any, help. This patch disables just about everything. > > > > ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) is what > > actually sets the dynamic performance switching into motion. Prior to that > > the hw is locked into the low performance level. I sounds like there is > > some bad parameter that is causing a lock up when the smc enables state > > switching. > > > > Separate from the patch can you also try changing the > > ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) call in > > ni_dpm_set_power_state() to low (RADEON_DPM_FORCED_LEVEL_LOW) or high > > (RADEON_DPM_FORCED_LEVEL_HIGH) rather than auto? See if you still get a > > lock up. > > I'll try it later today. I had time for now to play with forcing RADEON_DPM_FORCED_LEVEL_LOW and RADEON_DPM_FORCED_LEVEL_HIGH. The first one works fine, the second triggers the problem. I'm about to play with the suggested patch. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #18 from Dieter Nützel --- (In reply to comment #10) > Created attachment 85563 [details] [review] > possible fix > > The attached patch should fix the issue. Candidate for stable? -Dieter -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #26 from Weber K. --- During a test, I needed to issue 2 "cont" commands at gdb to advance just one frame at one breakpoint I trapped. And when closing the player, I issued twice "cont" at gdb, and only after the segfault occured. I suspect the function "radeon_dri2_screen_init" at "radeon_dri2.c" is called twice, one for each Screen, and then this routine is scheduling the "radeon_dri2_client_state_changed" routine twice with "AddCallBack". This way, when the client state is changed to gone, the "destroy buffers" routine is called twice either, and the error occur. I also want to thank the devs for the radeon driver! Thank you! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #27 from Weber K. ---
I think Ive got it! :)
Changed this file:
https://github.com/RAOF/xf86-video-ati/blob/master/src/radeon_dri2.c
Line 1404 from:
AddCallback(&ClientStateCallback, radeon_dri2_client_state_changed, 0);
Replaced by:
if (pScrn->scrnIndex == 0) {
AddCallback(&ClientStateCallback, radeon_dri2_client_state_changed, 0);
}
The callback is called only once, even if multiple screens! And the error is
gone!
Please, can someone check if it need to be repeated in other parts as well?
If correct, can someone commit it?
Thank you very much! :)
Weber Kai
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 Shawn Starr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Shawn Starr --- Multiple issues... GPU reset issue was fixed, this is GLSL error, reopening with new bug, not SB related -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #19 from John --- I confirm the patch works here as well! Thank you. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
