RE: [PATCH] drm: exynos: fix for mapping non contig dma buffers
It's good patch. Right, there was my missing point. I thought each sgl would
always have 4k page. But dma mapping api, dma_alloc_alloc(), allocates
physical memory as continuously as possible so the sgl can have group of
pages.
Below is my comment.
> -Original Message-
> From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
> Sent: Thursday, November 01, 2012 9:35 PM
> To: dri-devel@lists.freedesktop.org
> Cc: sw0312@samsung.com; inki@samsung.com; jy0922.s...@samsung.com;
> kyungmin.p...@samsung.com; prashant...@samsung.com; jo...@samsung.com;
> s.shir...@samsung.com; r.sh.o...@gmail.com; rahul.sha...@samsung.com
> Subject: [PATCH] drm: exynos: fix for mapping non contig dma buffers
>
> This patch fixes the problem of mapping gem objects which are non-
> contigous
> dma buffers. These buffers are described using SG table and SG lists. Each
> valid SG List is pointing to a single page or group of pages which are
> physically contigous.
>
> Current implementation just maps the first page of each SG List and leave
> the other pages unmapped, leading to a crash.
>
> Given solution finds the page struct for all the pages in the SG list and
> map them one by one. This ensures all the pages of current SG list are
> mapped.
> Next SG list of the same buffer will be mapped when page fault occurs for
> the offset belongs to that list.
>
> This patch is based on branch exynos-drm-next-iommu at
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 34
> +++---
> 1 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 7057729..d2d6188 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -95,17 +95,43 @@ static int exynos_drm_gem_map_buf(struct
> drm_gem_object *obj,
> {
> struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
> struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
> + struct scatterlist *sgl;
> unsigned long pfn;
> + unsigned int phys_addr;
> + int ret, i;
>
> if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
> if (!buf->pages)
> return -EINTR;
Buf->pages should be checked in all cases. For this, see below comment.
>
> - pfn = page_to_pfn(buf->pages[page_offset++]);
> - } else
> + sgl = buf->sgt->sgl;
> + for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
> + if (page_offset < (sgl->length >> PAGE_SHIFT))
> + break;
> + page_offset -= (sgl->length >> PAGE_SHIFT);
> + }
> +
> + if (i >= buf->sgt->nents) {
> + DRM_ERROR("invalid page offset\n");
> + return -EINVAL;
> + }
> +
> + phys_addr = sg_phys(sgl);
> +
> + for (i = 0; i < (sgl->length >> PAGE_SHIFT); i++) {
> + pfn = __phys_to_pfn(phys_addr + (i << PAGE_SHIFT));
> + ret = vm_insert_mixed(vma, f_vaddr + (i <<
PAGE_SHIFT),
> + pfn);
> + if (ret < 0) {
> + DRM_ERROR("failed to map page.\n");
> + return ret;
> + }
> + }
> + return 0;
> + } else {
> pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
It seems like that you missed EXYNOS_BO_CONTIG type testing. With iommu,
buf->dma_addr has device address but not physical address. So correct it
like below,
pfn = page_to_pfn(buf->pages[0]) + page_offset;
And one more posting? :)
Thanks,
Inki Dae
> -
> - return vm_insert_mixed(vma, f_vaddr, pfn);
> + return vm_insert_mixed(vma, f_vaddr, pfn);
> + }
> }
>
> static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
> --
> 1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: reduce default drm vblank off delay to 50ms
On 30.10.12 20:28, Jesse Barnes wrote: On Tue, 30 Oct 2012 20:20:44 +0100 Daniel Vetter wrote: On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes wrote: People keep whining about this, but no one seems to send a patch. This *ought* to be safe now that we've dealt with the hw races in Mario's updated code, and fixed the bugs we know about in VT switch, DPMS, and multi-head configuraions. Signed-off-by: Jesse Barnes Afaik the fundamental race of enabling the vblank is still there, so this is just duct-tape. And our hw has the required registers (on gen5+ at least) to close this race for real and abolish all "disable vblank irq later to paper over races and smooth things out). Hence I think we should dtrt and so Nacked-by: Daniel Vetter Also discussed with Jesse on irc, we've had fun ;-) That's ridiculous. Just because we have a race we can't fix wrt reading hw regs, doesn't mean we can't reduce the timeout. I nack your nack. Jesse, thanks for cc'ing me, much appreciated :) Psychtoolbox should be fine with a 50 msecs vblank off delay. I think i tested with values somewhere between 50 - 100 msecs at the time the drm patches were made. The way i schedule swaps for a specific target time 'twhen' is to: 1. glXGetSyncValuesOML(msc,ust) as a baseline vblank count and time. 2. Some basic math to calculate targetMSC based on 'twhen' and step 1. 3. glXSwapBuffersMscOML(targetMSC); So it should tolerate wrong vblank counts due to races, as long as vblank doesn't get disabled between 1. and 3. A default vblank off delay lower than maybe 1 refresh duration would make me nervous, given that most kms drivers are not race-free and it is possible for a userspace app or the x-server to get stalled for a couple of msecs. E.g., radeon wouldn't allow this race-free, because the drm code assumes that the hw vblank counter increments at leading edge of vblank, whereas radeon hw does it at the traling edge, iirc. nouveau doesn't have any hw vblank counter support, so it is "race free" until somebody fixes the driver ;-) - ie., it would work with apps that use steps 1/2/3 above, but broken for any other app. More trusting apps could get into more trouble with 50 msecs vs. 5000 msecs ... What kind of race in your code do you mean? What does your commit message "...now that we've dealt with the hw races in Mario's updated code..." refer to? I remember that Matthew Garret sent out a patch set a couple of months ago which aimed to make this configurable per kms driver, so each driver could opt into low vblank off delay if it was ready to do it properly. That would make a lot of sense. That said, for the current intel-ddx it wouldn't even matter for X11/GLX applications if the kernel returned random numbers instead of vblank counts, because the OML_sync_control swap scheduling in the ddx is totally broken, and even glXSwapBuffers is a wreck for any swapinterval setting except 0 and 1 since triple-buffering was introduced a year ago and introduced some bug. Psychtoolbox now detects this since a few weeks, prints out critical warnings to the user and tries to work around with glXSwapBuffers trickery. I submitted a patch to fix the rather trivial but nasty bug. Jesse, if you find some time, could you review it and convince Chris to merge it? Should be on the intel-gfx list and in your inbox, a simple . Subject line "[PATCH 2/3] ddx/dri2: Repair broken pageflip swap scheduling.", sent at 7 October 2012. I'll forward it again to you. Chris Wilson already gave me an off-list review for that patch series after i pinged him. Unfortunately a rather terse one, cited here: "On Mon, 15 Oct 2012 16:46:52 +0200, Mario Kleiner wrote: > Hi Chris, > > can you please check & merge at least the first two patches of the > series into the intel ddx? The first is along the right path, but I think you want to base the split on divisor==0. The second is broken in the DRI2 layer, as the SwapLimit mechanism exposes the multi-client race to a single client (i.e. there is no serialisation between the InvalidateEvent and the GetBuffers, and the InvalidateEvent is always broadcast too early.) The third is just plain wrong, as pageflip may be a blocking ioctl (and will impose client blocking) so anybody who wants to override SwapBuffersWait will also want to prevent the inherent wait due to the flip. In any event that option is to only paper over the loose DRI2 specification and the lack of client control... -Chris " If i understood the comment wrt. to patch [2/3] "The first is along the right path, but I think you want to base the split on divisor==0." correctly, then that would be just as broken as the current implementation, with some code obfuscation and confusion added, but i don't know, maybe i just misunderstood his comment? I asked for clarification, but he didn't respond to my followup e-mails. Maybe he was just too busy to reply, maybe i'm just too pushy and annoying. I will try
[Bug 56659] New: DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 Priority: medium Bug ID: 56659 Assignee: dri-devel@lists.freedesktop.org Summary: DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay Severity: normal Classification: Unclassified OS: All Reporter: runetmem...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 69414 --> https://bugs.freedesktop.org/attachment.cgi?id=69414&action=edit Example of artifact Hello! Please look at attached screenshot - there is triangle where we still see part of old frame, that was displayed on screen few frames before. I doesn't sure about terminology, but from my point of view looks like rendering in this triangle is lag behind rest of the screen. This issue happen for me only for applications launched with enabled offloading rendering (DRI_PRIME=1). It's reproducible not only in "Left 4 Dead 2" but also in other applications. Even in Chromium (if you launch it with "--ignore-gpu-blacklist" option that enabled hardware rendering on Mesa, and "DRI_PRIME=1" that enable offloading rendering) display same artifact (triangle) while scrolling pages. Also you may notice this artifact in glxgears, if you you run it in fullscreen mode. Software: Kubuntu 12.10 x86_64 updated from Xorg Edgers PPA. Mesa: 9.1~git20121029.00e6819e libdrm-radeon1: git20121025.bc494b31 xserver-xorg-video-radeon: git20120928.e8cb0b72 xserver-xorg-core: 1.13.0+git20120920.70e57668 Enabled or disabled V-Sync in KWin settings doesn't make the difference. Enabled or disabled V-Sync in game settings doesn't make the difference. Screenshot taken with stock Kubuntu kernel (3.5.0-17). With 3.7rc3 kernel issue still reproducible, but just a bit less noticeable. Hardware: Acer Aspire 7560G laptop, AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO) Discrete AMD Radeon HD 6650M (TURKS) "xrandr --listproviders" output: Providers: number : 2 Provider 0: id: 138 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 2 outputs: 3 associated providers: 1 name:radeon Provider 1: id: 85 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 1 name:radeon -- 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 56663] New: 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 Priority: medium Bug ID: 56663 Assignee: dri-devel@lists.freedesktop.org Summary: 2D tiling commit renders screen black on kdm Severity: major Classification: Unclassified OS: All Reporter: stompdagg...@yahoo.com Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 69420 --> https://bugs.freedesktop.org/attachment.cgi?id=69420&action=edit seat 0 config I'm running a multiseat setup with 2 radeon (ATI3650HD and ATI5450HD) and 1 intel cpus, I'm using libdrm, mesa and xf86-video-ati from git on gentoo. I'm syncing with the repos every thursday, yesterday I've syned with the repos and after boot today, all the screens connected to radeon are black. in the sync last thursday everything worked ok, also when downgrading to xf86-video-ati-6.14.6, the system works. when observing the commit logs on xf86-video-ati of this timeframe, the only commit is enabling 2D tiling. -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #1 from dagg --- Created attachment 69421 --> https://bugs.freedesktop.org/attachment.cgi?id=69421&action=edit seat 1 config -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #2 from dagg --- xorg logs can be found at http://bpaste.net/show/55347/ (bad boot log) and at http://bpaste.net/show/55346/ (good boot 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #3 from dagg --- (In reply to comment #0) > Created attachment 69420 [details] > seat 0 config > > I'm running a multiseat setup with 2 radeon (ATI3650HD and ATI5450HD) and 1 > intel cpus, I'm using libdrm, mesa and xf86-video-ati from git on gentoo. > > I'm syncing with the repos every thursday, yesterday I've syned with the > repos and after boot today, all the screens connected to radeon are black. > > in the sync last thursday everything worked ok, also when downgrading to > xf86-video-ati-6.14.6, the system works. > > when observing the commit logs on xf86-video-ati of this timeframe, the only > commit is enabling 2D tiling. thats gpus instead of cpus, my bad -- 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 46/51] drm/i915: Add support for atomic modesetting completion events
On Thu, Nov 01, 2012 at 11:39:58PM +0100, Daniel Vetter wrote: > On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote: > > On Thu, 1 Nov 2012 19:07:02 +0200 > > Ville Syrjälä wrote: > > > > > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote: > > > > On Thu, 1 Nov 2012 12:12:35 +0100 > > > > Daniel Vetter wrote: > > > > > > > > > On Thu, Oct 25, 2012 at 8:05 PM, > > > > > wrote: > > > > > > From: Ville Syrjälä > > > > > > > > > > > > Send completion events when the atomic modesetting operations has > > > > > > finished succesfully. > > > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > > > > > > > > I have to admit I'm not on top of the latest ioctl/interface > > > > > discussion, but one new requirement for the modeset (not the pageflip > > > > > part) of the all this atomic stuff I've discovered is that the kernel > > > > > needs to be able to select the crtcs for each output completely > > > > > unrestricted. I think userspace should simply pass in abstract crtc > > > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual > > > > > crtcs it has selected. > > > > > > > > > > We can't do that remapping internally because the crtc abstraction is > > > > > leaky: > > > > > - wait_for_vblank requires the pipe id, which could then change on > > > > > every modeset > > > > > - similarly userspace doing MI_WAIT for scanlines needs to know the > > > > > actual hw pipe in use by a crtc. > > > > > And current userspace presumes that the mapping between crtc->pipe > > > > > doesn't change. > > > > > > > > > > An example why the kernel needs to pick the crtc for userspace: > > > > > - on ivb only pipe A has a 7x5 panel fitter, so usually you want to > > > > > put the panel on the first crtc > > > > > - but if you run in a 3 pipe configuration and have an eDP panel, it's > > > > > better to put the eDP output on pipe C, since then pipes A&B will have > > > > > full 4-lane fdi links to the pch ports (instead of otherwise only 2 > > > > > lanes each on links B&C) > > > > > - similarly when we have a 3 pipe configuration with all encoders on > > > > > the pch, we need to move the mode with the highest dotclock to pipe A > > > > > (since that's the only one which will have 4 lanes, pipe B&C will only > > > > > have 2 each). > > > > > - afaik these kind of asymmetric constraints won't disappear anytime > > > > > soon, haswell definitely still has some. > > > > > > > > Yeah that's a good point... adding a virtual crtc layer would solve > > > > this and let us preserve the existing ABI. > > > > > > How would the state handling work? I mean if drm_crtc X currently has > > > some state, drm_crtc Y has some other state, and then we do a modeset > > > which would require swapping the roles of the crtcs, what would happen > > > to the bits of state that we didn't specify? > > > > > > If we'd do the remapping below the drm crtc layer, the state would > > > always be tied to the drm crtc. But that would definitely require > > > mostly uniform hardware "crtcs" so that the capabilities of the > > > drm_crtcs wouldn't keep changing whenever the remap happens. > > > > > > Well, I suppose we could tie the state to the virtual crtc instead, > > > and doing an operation on a real drm_crtc would also change the > > > state of the currently bound virtual crtc. And then changing the > > > virtual<->real mapping would just copy the state over from the virtual > > > crtc to the real drm_crtc. > > > > > > And if we do it for crtcs, then we'd need to do it for planes as well, > > > because the plane<->crtc mapping can be fixed or otherwise limited > > > in some fashion. > > > > > > Either way it sounds rather messy to me. > > > > > > Another option would be just leave it up to userspace to make the > > > correct choice between crtcs and planes. But then user space needs > > > to be equipped with more hardware specific knowledge, so it's not > > > a very appealing idea either. > > > > Yeah it gets ugly one way or another. From a userspace perspective, > > keeping the ugliness in the kernel is nice, and if we have to do it > > somewhere I guess I'd prefer that. > > My tentative Grand Plan (tm) for the atomic modeset implementation of such > things is to pimp the new struct intel_crtc_config to contain all the > configuration state (so with Rob's atomic modeset proposal that would also > embed the drm_crtc_state struct). It would also contain all the derived > state like pll settings, fdi lanes, ... > > Now the improve >mode_adjust stage, now called ->compute_config allocates > such a struct for each crtc, does some prep, calls down into > encoder->compute_config callbacks, then applies any fixups and screaming > required to come up with a working global config. All rather hazy, I know > ;-) > > But e.g. for the above case of trying to squeeze the fdi links into the > available sets of fdi lanes I guess we could first compute the upper bound > for the fdi link requirements (the curre
[PATCH] drm: exynos: fix for mapping non contig dma buffers
This patch fixes the problem of mapping gem objects which are non-contigous
dma buffers. These buffers are described using SG table and SG lists. Each
valid SG List is pointing to a single page or group of pages which are
physically contigous.
Current implementation just maps the first page of each SG List and leave
the other pages unmapped, leading to a crash.
Given solution finds the page struct for all the pages in the SG list and
map them one by one. This ensures all the pages of current SG list are mapped.
Next SG list of the same buffer will be mapped when page fault occurs for
the offset belongs to that list.
This patch is based on branch exynos-drm-next-iommu at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 34 +++---
1 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 7057729..d2d6188 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -95,17 +95,43 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
*obj,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
+ struct scatterlist *sgl;
unsigned long pfn;
+ unsigned int phys_addr;
+ int ret, i;
if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
if (!buf->pages)
return -EINTR;
- pfn = page_to_pfn(buf->pages[page_offset++]);
- } else
+ sgl = buf->sgt->sgl;
+ for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
+ if (page_offset < (sgl->length >> PAGE_SHIFT))
+ break;
+ page_offset -= (sgl->length >> PAGE_SHIFT);
+ }
+
+ if (i >= buf->sgt->nents) {
+ DRM_ERROR("invalid page offset\n");
+ return -EINVAL;
+ }
+
+ phys_addr = sg_phys(sgl);
+
+ for (i = 0; i < (sgl->length >> PAGE_SHIFT); i++) {
+ pfn = __phys_to_pfn(phys_addr + (i << PAGE_SHIFT));
+ ret = vm_insert_mixed(vma, f_vaddr + (i << PAGE_SHIFT),
+ pfn);
+ if (ret < 0) {
+ DRM_ERROR("failed to map page.\n");
+ return ret;
+ }
+ }
+ return 0;
+ } else {
pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
-
- return vm_insert_mixed(vma, f_vaddr, pfn);
+ return vm_insert_mixed(vma, f_vaddr, pfn);
+ }
}
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Fix nouveau hang after switcheroo
After switcherooing to integrated and starting X, when X fails to start
and causes a console switch, we get hit with a hanger (below). Fix
by checking if we're already in D3.
BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1703]
[] nv04_timer_read+0x28/0x70 [nouveau]
[] nouveau_timer_wait_eq+0x7c/0xe0 [nouveau]
[] nvd0_sor_dpms+0xde/0x1a0 [nouveau]
[] ? fb_set_var+0xe9/0x3a0
[] ? __pte_alloc+0xa9/0x160
[] ? nvd0_sor_dp_link_set+0x2c0/0x2c0 [nouveau]
[] drm_helper_connector_dpms+0xbc/0x100 [drm_kms_helper]
[] drm_fb_helper_dpms.isra.13+0xa5/0xf0 [drm_kms_helper]
[] drm_fb_helper_blank+0x49/0x80 [drm_kms_helper]
[] fb_blank+0x56/0xc0
[] do_fb_ioctl+0x59b/0x5f0
[] ? vma_interval_tree_insert+0x83/0x90
[] fb_ioctl+0x45/0x50
[] do_vfs_ioctl+0x8a/0x340
[] sys_ioctl+0x91/0xb0
Signed-off-by: Daniel J Blueman
---
drivers/gpu/drm/nouveau/nvd0_display.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c
b/drivers/gpu/drm/nouveau/nvd0_display.c
index c402fca..c3285bf 100644
--- a/drivers/gpu/drm/nouveau/nvd0_display.c
+++ b/drivers/gpu/drm/nouveau/nvd0_display.c
@@ -1364,6 +1364,10 @@ nvd0_sor_dpms(struct drm_encoder *encoder, int mode)
int or = nv_encoder->or;
u32 dpms_ctrl;
+ /* prevent hanging after hardware is in D3 */
+ if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ return;
+
nv_encoder->last_dpms = mode;
list_for_each_entry(partner, &dev->mode_config.encoder_list, head) {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56666] New: AMD SUMO GPU lockup when launching any heavy 3D application
https://bugs.freedesktop.org/show_bug.cgi?id=5 Priority: medium Bug ID: 5 Assignee: dri-devel@lists.freedesktop.org Summary: AMD SUMO GPU lockup when launching any heavy 3D application Severity: critical Classification: Unclassified OS: Linux (All) Reporter: runetmem...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 69423 --> https://bugs.freedesktop.org/attachment.cgi?id=69423&action=edit AMD SUMO GPU lockup when I launch Unigine Heaven 3 GPU lockup happen for me while launching any heavy 3D application on Radeon HD 6620G. For example GPU lockup 100% reproducible when I launch Unigine Heaven 3 (dmesg attached). It also may happen in web-browser, if browser use rendering hardware acceleration (for example Firefox with enabled "layers.acceleration.force-enabled" option). Lockup is not reproducible when I launch same applications on discrete Radeon HD 6650M GPU using DRI_PRIME feature, so I guess my issue related to AMD SUMO GPU's (or maybe to more APU's). Software: Kubuntu 12.10 x86_64 updated from Xorg Edgers PPA. Linux 3.7rc3. With Linux 3.5 and 3.6 is also reproducible, Mesa: 9.1~git20121029.00e6819e libdrm-radeon1: git20121025.bc494b31 xserver-xorg-video-radeon: git20120928.e8cb0b72 xserver-xorg-core: 1.13.0+git20120920.70e57668 KDE 4.9.2, desktop effects enabled. Hardware: Acer Aspire 7560G laptop, BIOS 2.04, AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO) Discrete AMD Radeon HD 6650M (TURKS) -- 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
[pull] drm-intel-next for 3.8
Hi Dave, Quite a pile since this is 4 weeks worth of patches: - tons of hsw dp prep patches form Paulo - round scheduled work items and timers to nearest second (Chris) - some hw workarounds (Jesse&Damien) - vlv dp support and related fixups (Vijay et al.) - basic haswell dp support, not yet wired up for external ports (Paulo) - edp support (Paulo) - tons of refactorings to prepare for the above (Paulo) - panel rework, unifiying code between lvds and edp panels (Jani) - panel fitter scaling modes (Jani + Yuly Novikov) - panel power improvements, should now work without the BIOS setting it up - extracting some dp helpers from radeon/i915 and move them to drm_dp_helper.c - randome pile of workarounds (Damien, Ben, ...) - some cleanups for the register restore code for suspend/resume - secure batchbuffer support, should enable tear-free blits on gen6+ (Chris) - random smaller fixlets and cleanups. For Haswell display support, this is not yet everything, big things still missing are: - hdmi/dp encoder unification, otherwise we can't enable non-eDP outputs - vga fixes (which essentially required forking all the fdi/pch code) Both are already in -next-queued, so for the next pull I plan to move Haswell out of experimental support. Note that this also contains a -rc2 backmerge, which I've botched up slightly:( Luckily Jani caught me and fixed things up, his patch is included on top of what QA beat on. For drm core stuff I have two series outstanding: - kerneldoc/DocBook patches demanded by Lauren Pinchart. Note that the last patch in that series depends upon the dp helper refactoring included in here. - relaunched hpd rework, requested&reviewed by Alex Deucher. Can you please look into slurping these into drm-next, too? Yours, Daniel The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to c8241969b44438c9335b59d375b627214bc36483: drm/i915: pass adjusted_mode to intel_choose_pipe_bpp_dither(), again (2012-11-02 09:57:28 +0100) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (3): drm/i915: Extract PCU communication drm/i915: Workaround to bump rc6 voltage to 450 drm/i915: Add rc6vids to debugfs Chris Wilson (5): drm/i915: Align the hangcheck wakeup to the nearest second drm/i915: Align the retire_requests worker to the nearest second drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffers drm/i915: Document the multi-threaded FORCEWAKE bits drm/i915: Clear FORCEWAKE when taking over from BIOS Damien Lespiau (9): drm/i915: Remove the disabling of VHR unit clock gating for HSW drm/i915: Document that we are implementing WaDisableBackToBackFlipFix drm/i915: Remove the WaDisableBackToBackFlipFix w/a for Haswell drm/i915: Fix the SCC/SSC typo in the SPLL bits definition drm/i915: Consolidate ILK_DSPCLK_GATE and PCH_DSPCLK_GATE drm/i915: Program DSPCLK_GATE_D only once on Ironlake drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLV drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler drm/i915: VLV does not have a sprite scaler Daniel Vetter (24): drm/i915: s/DRM_IRQ_ARGS/int irq, void *arg drm/i915: move hpd handling to (ibx|cpt)_irq_handler drm/i915: don't save/restore DP regs for kms drm/i915: don't save/restore irq regs for kms drm/i915: don't save/restore HWS_PGA reg for kms drm/i915/crt: don't set HOTPLUG bits on !PCH drm/i915/crt: explicitly set up HOTPLUG_BITS on resume drm/i915: don't save/restor ADPA for kms drm/i915: unconditionally use mt forcewake on hsw/ivb Merge tag 'v3.7-rc2' into drm-intel-next-queued drm: rename drm_dp_i2c_helper.c to drm_dp_helper.c drm: dp helper: extract drm_dp_channel_eq_ok drm: dp helper: extract drm_dp_clock_recovery_ok drm: extract helpers to compute new training values from sink request drm: extract dp link train delay functions from radeon drm/i915: use the new dp train delay helpers drm: extract dp link bw helpers drm: extract drm_dp_max_lane_count helper drm/i915/dp: actually nack test request drm/i915: make edp panel power sequence setup more robust drm/i915: enable/disable backlight for eDP drm/i915/eDP: compute the panel power clock divisor from the pch rawclock drm/i915/dp: compute the pch dp aux divider fro
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #6 from Andreas Boll --- (In reply to comment #4) > There is a lot of other code which plays role in handling sRGB textures. I > don't think getteximage.c is relevant to this issue(s). > > Nevertheless, it looks like Pavel's and Martin's issues are different bugs. > > Pavel reported that GL_EXT_texture_sRGB_decode, which is only in 7.11, is > broken specifically on r300g, but other drivers might be affected as well > and it definitely looks like a Mesa core bug. Pavel, could you please add it > as a new bug against Mesa core? > > Martin's issue is likely related to the fact that piglit/glean/texture_srgb > fails on r600g. Taking a look at it might be a good start. the piglit passes for me on my rv770 with mesa from git (470952f) @Martin: Can you test with a newer version of mesa (9.0 or mesa from git)? -- 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 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown
https://bugs.freedesktop.org/show_bug.cgi?id=56634 --- Comment #3 from Andy Furniss --- (In reply to comment #2) > Do you mean it's slower than without the commit or is it running mostly at > the same speed when it's slowing down? It's way slower than without the commit, but only temporarily then it recovers. In case you have etqw, I am testing @1920x1080 fullscreen with everything turned on/up as high as possible. I've found another issue, but it's not related to this or llvm and could be quite old as I've not left etqw running for ~30 mins for some months. The issue is I run out of mem (4 gig). I'll open a new bug when I've had more time to test with older kernels. -- 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 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 Andreas Boll changed: What|Removed |Added Product|Mesa|DRI Version|git |XOrg CVS Component|Drivers/DRI/R600|DRM/Radeon -- 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
[PATCH v2 0/4] drm/exynos,intel: fix locking for flip/vbl event list
The patchset adds the missing event_lock when accessing the vblank_event_list in drm_vblank_off() and as preparation for this also fixes a few other issues in the exynos driver. This is also a dependency for Rob Clark's drm_send_vblank_event() rework as that would trigger a warning for the unhold event_lock without this changeset. The exynos changes are only compile tested, the rest is tested on an Intel IVB machine on top of drm-intel-nightly + drm_send_vblank_event() rework, with i-g-t/flip_test. In v2: - Instead of fixing the event_lock vs. vblank_time_lock lockdep issue in drm_handle_vblank(), fix it in the exynos driver. This looks like the more logical thing to do and this way we also have a smaller impact on the rest of DRM code. Imre Deak (4): drm/exynos: hold event_lock while accessing pageflip_event_list drm/exynos: call drm_vblank_put for each queued flip event drm/exynos: fix lockdep for event_lock wrt. vbl_time_lock drm: hold event_lock while accessing vblank_event_list drivers/gpu/drm/drm_irq.c|3 +++ drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 20 +--- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 20 +--- drivers/gpu/drm/exynos/exynos_mixer.c| 11 +-- 5 files changed, 11 insertions(+), 48 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/exynos: hold event_lock while accessing pageflip_event_list
Signed-off-by: Imre Deak
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index fce245f..2efa4b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -236,16 +236,21 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
goto out;
}
+ spin_lock_irq(&dev->event_lock);
list_add_tail(&event->base.link,
&dev_priv->pageflip_event_list);
+ spin_unlock_irq(&dev->event_lock);
crtc->fb = fb;
ret = exynos_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y,
NULL);
if (ret) {
crtc->fb = old_fb;
+
+ spin_lock_irq(&dev->event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
list_del(&event->base.link);
+ spin_unlock_irq(&dev->event_lock);
goto out;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/exynos: call drm_vblank_put for each queued flip event
It's guaranteed that for each event on pageflip_event_list we have
called drm_vblank_get() - see exynos_drm_crtc_page_flip() - so checking
for this is redundant.
Also we need to call drm_vblank_put() for each event on the list, not
only once, otherwise we'd leak vblank references if there are multiple
events on the list.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |8 +---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |8 +---
drivers/gpu/drm/exynos/exynos_mixer.c| 11 +--
3 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 130a2b5..e69b7c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -642,17 +642,11 @@ static void fimd_finish_pageflip(struct drm_device
*drm_dev, int crtc)
list_move_tail(&e->base.link, &e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
+ drm_vblank_put(drm_dev, crtc);
}
if (is_checked) {
/*
-* call drm_vblank_put only in case that drm_vblank_get was
-* called.
-*/
- if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
- drm_vblank_put(drm_dev, crtc);
-
- /*
* don't off vblank if vblank_disable_allowed is 1,
* because vblank would be off by timer handler.
*/
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index e4b8a8f..e26d455 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -401,17 +401,11 @@ static void vidi_finish_pageflip(struct drm_device
*drm_dev, int crtc)
list_move_tail(&e->base.link, &e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
+ drm_vblank_put(drm_dev, crtc);
}
if (is_checked) {
/*
-* call drm_vblank_put only in case that drm_vblank_get was
-* called.
-*/
- if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
- drm_vblank_put(drm_dev, crtc);
-
- /*
* don't off vblank if vblank_disable_allowed is 1,
* because vblank would be off by timer handler.
*/
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 614b2e9..5720e82 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -884,7 +884,6 @@ static void mixer_finish_pageflip(struct drm_device
*drm_dev, int crtc)
struct drm_pending_vblank_event *e, *t;
struct timeval now;
unsigned long flags;
- bool is_checked = false;
spin_lock_irqsave(&drm_dev->event_lock, flags);
@@ -894,7 +893,6 @@ static void mixer_finish_pageflip(struct drm_device
*drm_dev, int crtc)
if (crtc != e->pipe)
continue;
- is_checked = true;
do_gettimeofday(&now);
e->event.sequence = 0;
e->event.tv_sec = now.tv_sec;
@@ -902,16 +900,9 @@ static void mixer_finish_pageflip(struct drm_device
*drm_dev, int crtc)
list_move_tail(&e->base.link, &e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
+ drm_vblank_put(drm_dev, crtc);
}
- if (is_checked)
- /*
-* call drm_vblank_put only in case that drm_vblank_get was
-* called.
-*/
- if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
- drm_vblank_put(drm_dev, crtc);
-
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/exynos: fix lockdep for event_lock wrt. vbl_time_lock
Currently the exynos driver calls drm_vblank_off() with the event_lock
held, while drm_vblank_off() will lock vbl_time and vblank_time_lock.
This lock dependency chain conflicts with the one in drm_handle_vblank()
where we first lock vblank_time_lock and then the event_lock.
Fix this by removing the above drm_vblank_off() calls which are in fact
never executed: drm_dev->vblank_disable_allowed is only ever non-zero
during driver init, until it's set in {fimd,vidi}_subdrv_probe. Both the
driver init and open code is protected by drm_global_mutex, so the
earliest page flip ioctl can happen only after vblank_disable_allowed is
set to 1. Thus {fimd,vidi}_finish_pageflip - with pending flip events -
will always get called with vblank_disable_allowed being 1.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 12
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e69b7c4..2eb131c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -623,7 +623,6 @@ static void fimd_finish_pageflip(struct drm_device
*drm_dev, int crtc)
struct drm_pending_vblank_event *e, *t;
struct timeval now;
unsigned long flags;
- bool is_checked = false;
spin_lock_irqsave(&drm_dev->event_lock, flags);
@@ -633,8 +632,6 @@ static void fimd_finish_pageflip(struct drm_device
*drm_dev, int crtc)
if (crtc != e->pipe)
continue;
- is_checked = true;
-
do_gettimeofday(&now);
e->event.sequence = 0;
e->event.tv_sec = now.tv_sec;
@@ -645,15 +642,6 @@ static void fimd_finish_pageflip(struct drm_device
*drm_dev, int crtc)
drm_vblank_put(drm_dev, crtc);
}
- if (is_checked) {
- /*
-* don't off vblank if vblank_disable_allowed is 1,
-* because vblank would be off by timer handler.
-*/
- if (!drm_dev->vblank_disable_allowed)
- drm_vblank_off(drm_dev, crtc);
- }
-
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index e26d455..4b0c16b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -382,7 +382,6 @@ static void vidi_finish_pageflip(struct drm_device
*drm_dev, int crtc)
struct drm_pending_vblank_event *e, *t;
struct timeval now;
unsigned long flags;
- bool is_checked = false;
spin_lock_irqsave(&drm_dev->event_lock, flags);
@@ -392,8 +391,6 @@ static void vidi_finish_pageflip(struct drm_device
*drm_dev, int crtc)
if (crtc != e->pipe)
continue;
- is_checked = true;
-
do_gettimeofday(&now);
e->event.sequence = 0;
e->event.tv_sec = now.tv_sec;
@@ -404,15 +401,6 @@ static void vidi_finish_pageflip(struct drm_device
*drm_dev, int crtc)
drm_vblank_put(drm_dev, crtc);
}
- if (is_checked) {
- /*
-* don't off vblank if vblank_disable_allowed is 1,
-* because vblank would be off by timer handler.
-*/
- if (!drm_dev->vblank_disable_allowed)
- drm_vblank_off(drm_dev, crtc);
- }
-
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm: hold event_lock while accessing vblank_event_list
Currently the only users of drm_vblank_off() are i915 and gma500,
neither of which holds the event_lock when calling this function.
Fix this by holding the event_lock while traversing the list.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_irq.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..c6cd558 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -949,6 +949,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
/* Send any queued vblank events, lest the natives grow disquiet */
seq = drm_vblank_count_and_time(dev, crtc, &now);
+
+ spin_lock(&dev->event_lock);
list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
if (e->pipe != crtc)
continue;
@@ -965,6 +967,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
e->event.sequence);
}
+ spin_unlock(&dev->event_lock);
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #7 from Martin Lambers --- I don't have access anymore to the AMD graphics card that originally exposed the problem for me. I can only confirm that the problem does not exist with Mesa 9.0 (from Ubuntu 12.10) with an Intel Sandybridge GPU: OpenGL Version: 3.0 Mesa 9.0 OpenGL Renderer: Mesa DRI Intel(R) Sandybridge Mobile OpenGL Vendor: Intel Open Source Technology Center Thanks for your work. Martin -- 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 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/Radeon |Drivers/Gallium/r600 -- 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 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)
https://bugs.freedesktop.org/show_bug.cgi?id=36965 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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] kms: Return a negative error code in kms_bo_create()
On Thu, Nov 1, 2012 at 10:38 AM, Laurent Pinchart wrote: > The function returns returns 0 on success or a negative value in case of an > error, except when given invalid attributes in which case it returns the > positive EINVAL value. Replace that with -EINVAL to allow the caller to detect > errors with a < 0 check. > > Signed-off-by: Laurent Pinchart Reviewed-by: Jakob Bornecrantz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] kms: Make libkms.h usable in C++
On Thu, Nov 1, 2012 at 10:40 AM, Laurent Pinchart
wrote:
> Wrap the header in extern "C" { ... };.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jakob Bornecrantz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48455] Enabling R600_STREAMOUT causes graphical corruption
https://bugs.freedesktop.org/show_bug.cgi?id=48455 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 49632] radeon: The kernel rejected CS,
https://bugs.freedesktop.org/show_bug.cgi?id=49632 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 Alex Deucher changed: What|Removed |Added Attachment #69414|text/plain |image/jpeg mime type|| -- 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 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Alex Deucher --- Please update to a newer xf86-video-ati snapshot. You are missing some patches required for proper support with kwin. Please reopen if you are still having issues with a newer snapshot. -- 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 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #14 from Alex Deucher --- (In reply to comment #13) > (In reply to comment #12) > > If they are 32-bit games, you'll hit the same issue. > > Not meaning to question your expertise, but would you care to explain: if > "wine requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen) > mode is running just fine? In my layman view this would mean wine's > perfectly able to handle the 2D rendering and display on it's part without > having to install 32-bit 3D driver (which in my case would require complete > switch to closed source catalyst package and I'm a bit reluctant to do so). You can install a 32 bit version of the open source 3D driver as well. Just because the graphics in a game do not appear to be 3D, they generally still use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since the apps are 32 bit. Also there seem to be several possibly unrelated issues now piled onto this bug. -- 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 48759] [Piglit] : Regression failure observed for Glean test bufferObject
https://bugs.freedesktop.org/show_bug.cgi?id=48759 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Andreas Boll --- Is this still an issue with a newer driver/kernel? -- 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 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
https://bugs.freedesktop.org/show_bug.cgi?id=44852 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #6 from Andreas Boll --- Is this still an issue with a newer driver/kernel? -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #4 from Alex Deucher --- Are you sure it's the 2D tiling commit? Does just reverting that commit fix the issue? I think it's probably another commit. Does your tree have: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=39eac3104c2f08b4d78aab3f88fd104301eb4711 Can you try again with git master? -- 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 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 --- Comment #7 from Alex Deucher --- Can you try a mesa 8.0.x release? This might be a duplicate of bug 56405. -- 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 56666] AMD SUMO GPU lockup when launching any heavy 3D application
https://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #1 from Alex Deucher --- Can you try mesa 8.0.x? This might be a duplicate of bug 56405. If 8.0.x works, can you bisect? -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #5 from dagg --- (In reply to comment #4) > Are you sure it's the 2D tiling commit? Does just reverting that commit fix > the issue? I think it's probably another commit. Does your tree have: > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/ > ?id=39eac3104c2f08b4d78aab3f88fd104301eb4711 > Can you try again with git master? Hello Alex, I'm not sure, correct me if I'm wrong but Zaphod is for running seperate x sessions on the same card? I'm using a card per session. anyway, I'll revert the patch and try, will report soon. -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #6 from Alex Deucher --- (In reply to comment #5) > I'm not sure, correct me if I'm wrong but Zaphod is for running seperate x > sessions on the same card? > I'm using a card per session. > > anyway, I'll revert the patch and try, will report soon. You are correct, but I'm wondering if that patch is causing a problem in your case. You might try reverting that patch as well if the 2D tiling patch doesn't help. -- 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 25590] commit "drm: disable all the possible outputs/crtcs before entering KMS mode" introduces EDID errors
https://bugs.freedesktop.org/show_bug.cgi?id=25590 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO Product|Mesa|DRI Version|git |unspecified Component|Drivers/DRI/R600|DRM/Radeon --- Comment #6 from Andreas Boll --- Is this still an issue with a newer kernel? Reassigning to drm/radeon. -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 56680 *** -- 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 40931] r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode.
https://bugs.freedesktop.org/show_bug.cgi?id=40931 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Andreas Boll --- Fixed with 86f97f7dc015092aa7fa1b0bdc4fe0a9f696d418 -- 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 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO Product|Mesa|DRI Version|7.10|unspecified Component|Drivers/DRI/R600|DRM/Radeon --- Comment #25 from Andreas Boll --- Is this still an issue with a newer driver/kernel? Reassigning to drm/radeon. -- 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 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #26 from Bob Ham --- (In reply to comment #25) > Is this still an issue with a newer driver/kernel? I'll investigate. -- 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 28223] Screen Blanks on launching racing game Vdrift
https://bugs.freedesktop.org/show_bug.cgi?id=28223 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO -- 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 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #15 from mailbox@gmail.com --- (In reply to comment #14) > You can install a 32 bit version of the open source 3D driver as well. Just > because the graphics in a game do not appear to be 3D, they generally still > use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since > the apps are 32 bit. Also there seem to be several possibly unrelated > issues now piled onto this bug. You've focused on minor point about the inability of having open source 32-bit driver alongside 64-bit one. I don't know the cause of it, I only know that my distribution provides this kind of setup for closed source catalyst package: https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri package mentioned in the link above - but I assume you mean xorg kind of drivers. If this is some sort of distro-related bug, please state it so I can nag other people about it ;-) At the same time, I see my main point about display being fine in virtual desktop mode has been ignored? To reiterate: it doesn't seem to me that, since Wine is capable of rendering and display on the very same setup in different mode, there are some unfullfilled requirements that block said display. After all, as I described before, even in fullscreen mode there was some kind of output, albeit buggy to the point of being unusable. But without the crucial part of plumbing there would be no output at all. -- 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 24542] r600 vertex processing broken in mesa 7.7
https://bugs.freedesktop.org/show_bug.cgi?id=24542 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Andreas Boll --- Note: classic r600 driver has been abandoned. NV_vertex_program won't be implemented in r600g either. Previosly the last bits of this extension got removed from mesa-core (only swrast implemented it) Please use the ARB_vertex_program extension instead. -- 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 32323] GL_EXT_texture_sRGB is broken
https://bugs.freedesktop.org/show_bug.cgi?id=32323 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. It should handle GL_EXT_texture_sRGB correctly. -- 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 25443] [nexuiz] Endless loading without kms
https://bugs.freedesktop.org/show_bug.cgi?id=25443 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andreas Boll --- Note: UMS is deprecated and newer cards are only supported by KMS -- 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 23436] RV620 locks up on starting/quiting 3D app
https://bugs.freedesktop.org/show_bug.cgi?id=23436 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #7 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 36172] xf86-video-ati-git causes Gnome 3 crash (Radeon HD5770 - r800)
https://bugs.freedesktop.org/show_bug.cgi?id=36172 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #10 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? Gnome 3 runs fine for me on rv770 (Kernel 3.6.4, xf86-video-ati git, libdrm git, mesa git) -- 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 23949] [RV620] r600 crash on resolution change & OpenGL start
https://bugs.freedesktop.org/show_bug.cgi?id=23949 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 24857] Lightening and object selection in viewport is not working in Blender 3D
https://bugs.freedesktop.org/show_bug.cgi?id=24857 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #6 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 24860] Triple Buffer is very slow in Blender 3D
https://bugs.freedesktop.org/show_bug.cgi?id=24860 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27457] Blender artifacts when using box select
https://bugs.freedesktop.org/show_bug.cgi?id=27457 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO -- 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 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #6 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27443] radeonFreeTexImageData: Assertion `!image->base.Data' failed when running Ogre3D samples
https://bugs.freedesktop.org/show_bug.cgi?id=27443 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #9 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26997] r600: broken mipmap generation
https://bugs.freedesktop.org/show_bug.cgi?id=26997 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26525] Rendering bug due to ARB_texture_non_power_of_two
https://bugs.freedesktop.org/show_bug.cgi?id=26525 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #12 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26011] Rare font corruption in OpenArena
https://bugs.freedesktop.org/show_bug.cgi?id=26011 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #6 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26114] Black screen on The Sims 3 beginning
https://bugs.freedesktop.org/show_bug.cgi?id=26114 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #8 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 24380] OpenGL fullscreen with KMS multihead
https://bugs.freedesktop.org/show_bug.cgi?id=24380 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 29317] Neverwinter night cloak texture is broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=29317 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 29318] Marbleblast textures broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=29318 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 29200] [wine] Warcraft 3 crashes after trying to launch again
https://bugs.freedesktop.org/show_bug.cgi?id=29200 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26735] r600: rendering artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=26735 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #12 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27723] Vtx endian setup error under big endain CPU
https://bugs.freedesktop.org/show_bug.cgi?id=27723 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 28359] Regression running Second Life viewer on r600 (mipmap generation issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=28359 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 28412] Thief 2 crashes in wine with the open source driver and not with fglrx
https://bugs.freedesktop.org/show_bug.cgi?id=28412 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 32246] [RADEON:KMS:R600C] compiz 0.9 switcher segfaults in mipmap generation code
https://bugs.freedesktop.org/show_bug.cgi?id=32246 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 40936] register address overlap make line stipple error
https://bugs.freedesktop.org/show_bug.cgi?id=40936 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26769] r600: wrong fragment shader input when using gl_fragCoord.
https://bugs.freedesktop.org/show_bug.cgi?id=26769 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27173] r600 wierdness with shaders for blur effect in compiz
https://bugs.freedesktop.org/show_bug.cgi?id=27173 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27434] [rv710] low 3d perfomance in general
https://bugs.freedesktop.org/show_bug.cgi?id=27434 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #9 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27061] r600: software fallback for GL_DEPTH_COMPONENT*
https://bugs.freedesktop.org/show_bug.cgi?id=27061 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 34377] Radeon driver PCIe throughput not up to PCIe2.0 levels
https://bugs.freedesktop.org/show_bug.cgi?id=34377 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27025] Very slow start of The Sims 3
https://bugs.freedesktop.org/show_bug.cgi?id=27025 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26115] blit: lack of depth copies
https://bugs.freedesktop.org/show_bug.cgi?id=26115 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 26933] r600 driver (rv730): piglit test failures
https://bugs.freedesktop.org/show_bug.cgi?id=26933 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #6 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 27132] piglit comparison between F12 7.7-4 and 7.9-git
https://bugs.freedesktop.org/show_bug.cgi?id=27132 Andreas Boll changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #8 from Andreas Boll --- Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel? -- 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 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #16 from Alex Deucher --- (In reply to comment #15) > You've focused on minor point about the inability of having open source > 32-bit driver alongside 64-bit one. I don't know the cause of it, I only > know that my distribution provides this kind of setup for closed source > catalyst package: > https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers I'm not following. You can have both 32-bit and 64-bit versions of the open source driver installed. If your distro doesn't allow it, it's broken. If other 32-bit and 64-bit libs also cannot both be installed, you may have bigger problems. > > To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri > package mentioned in the link above - but I assume you mean xorg kind of > drivers. If this is some sort of distro-related bug, please state it so I > can nag other people about it ;-) Is the 32-bit driver a recent version? Often distros only provide out of date 32-bit drivers on 64-bit distros. > > At the same time, I see my main point about display being fine in virtual > desktop mode has been ignored? To reiterate: it doesn't seem to me that, > since Wine is capable of rendering and display on the very same setup in > different mode, there are some unfullfilled requirements that block said > display. After all, as I described before, even in fullscreen mode there was > some kind of output, albeit buggy to the point of being unusable. But > without the crucial part of plumbing there would be no output at all. The symptoms you are experiencing are commonly seen with an out of date 32-bit 3D driver. If your 32-bit 3D driver is old, you may still be experiencing the problem. Also, there are several people on this bug report and the solution may still be relevant for them even if it doesn't help in your case. -- 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 28359] Regression running Second Life viewer on r600 (mipmap generation issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=28359 --- Comment #5 from Aidan Thornton --- Nope, doesn't affect r600g and I don't think it ever actually did (though I wasn't using it at the time because it had - and still has - other unrelated rendering issues that're harder to work around). Guess this probably wants closing? -- 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 v7 2/8] of: add helper to parse display timings
Hello Steffen,
On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
wrote:
> Signed-off-by: Steffen Trumtrar
> ---
> .../devicetree/bindings/video/display-timings.txt | 139 +++
> drivers/of/Kconfig |6 +
> drivers/of/Makefile|1 +
> drivers/of/of_display_timings.c| 185
>
> include/linux/of_display_timings.h | 20 +++
> 5 files changed, 351 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/display-timings.txt
> create mode 100644 drivers/of/of_display_timings.c
> create mode 100644 include/linux/of_display_timings.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,139 @@
> +display-timings bindings
> +==
> +
> +display-timings-node
> +
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - native-mode: the native mode for the display, in case multiple modes are
> + provided. When omitted, assume the first node is the native.
> +
> +timings-subnode
> +---
> +
> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> + in pixels
> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters
> in
> + lines
> + - clock-frequency: displayclock in Hz
> +
> +optional properties:
> + - hsync-active : Hsync pulse is active low/high/ignored
> + - vsync-active : Vsync pulse is active low/high/ignored
> + - de-active : Data-Enable pulse is active low/high/ignored
> + - pixelclk-inverted : pixelclock is inverted/non-inverted/ignored
> + - interlaced (bool)
> + - doublescan (bool)
> +
> +All the optional properties that are not bool follow the following logic:
> +<1> : high active
> +<0> : low active
> +omitted : not used on hardware
> +
> +There are different ways of describing the capabilities of a display. The
> devicetree
> +representation corresponds to the one commonly found in datasheets for
> displays.
> +If a display supports multiple signal timings, the native-mode can be
> specified.
> +
> +The parameters are defined as
> +
> +struct display_timing
> +===
> +
> +
> +--+-+--+---+
> + | |↑| |
> |
> + | ||vback_porch | |
> |
> + | |↓| |
> |
> +
> +--###--+---+
> + | #↑# |
> |
> + | #|# |
> |
> + | hback #|# hfront |
> hsync |
> + | porch #| hactive # porch | len
> |
> +
> |<>#<---+--->#<>|<->|
> + | #|# |
> |
> + | #|vactive # |
> |
> + | #|# |
> |
> + | #↓# |
> |
> +
> +--###--+---+
> + | |↑| |
> |
> + | ||vfront_porch| |
> |
> + | |↓| |
> |
> +
> +--+-+--+---+
> + | |↑| |
> |
> + | ||vsync_len | |
> |
> + | |↓| |
> |
> +
> +--+-+--+---+
> +
> +
> +Example:
> +
> + display-timings {
> + native-mode = <&timing0>;
> + timing0: 1920p24 {
> + /* 1920x1080p24 */
> + clock = <5200>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hfront-porch = <25>;
> + hback-porch = <25>;
> + hsync-len = <25>;
> + vback-porch = <2>;
> +
[Bug 28359] Regression running Second Life viewer on r600 (mipmap generation issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=28359 Andreas Boll changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #8 from dagg --- (In reply to comment #6) > (In reply to comment #5) > > I'm not sure, correct me if I'm wrong but Zaphod is for running seperate x > > sessions on the same card? > > I'm using a card per session. > > > > anyway, I'll revert the patch and try, will report soon. > > You are correct, but I'm wondering if that patch is causing a problem in > your case. You might try reverting that patch as well if the 2D tiling > patch doesn't help. issue confirmed, it was indeed that Zaphod 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
Re: [PATCH] drm: reduce default drm vblank off delay to 50ms
On Fri, 02 Nov 2012 06:56:57 +0100 Mario Kleiner wrote: > Jesse, thanks for cc'ing me, much appreciated :) > > Psychtoolbox should be fine with a 50 msecs vblank off delay. I think i > tested with values somewhere between 50 - 100 msecs at the time the drm > patches were made. The way i schedule swaps for a specific target time > 'twhen' is to: > > 1. glXGetSyncValuesOML(msc,ust) as a baseline vblank count and time. > 2. Some basic math to calculate targetMSC based on 'twhen' and step 1. > 3. glXSwapBuffersMscOML(targetMSC); > > So it should tolerate wrong vblank counts due to races, as long as > vblank doesn't get disabled between 1. and 3. A default vblank off delay > lower than maybe 1 refresh duration would make me nervous, given that > most kms drivers are not race-free and it is possible for a userspace > app or the x-server to get stalled for a couple of msecs. > > E.g., radeon wouldn't allow this race-free, because the drm code assumes > that the hw vblank counter increments at leading edge of vblank, whereas > radeon hw does it at the traling edge, iirc. nouveau doesn't have any hw > vblank counter support, so it is "race free" until somebody fixes the > driver ;-) - ie., it would work with apps that use steps 1/2/3 above, > but broken for any other app. Right, ok that clarifies things for me. I knew you had some kind of race between reading the hw value and scheduling things. Is the above in a comment somewhere in the vblank code? > More trusting apps could get into more trouble with 50 msecs vs. 5000 > msecs ... > > What kind of race in your code do you mean? What does your commit > message "...now that we've dealt with the hw races in Mario's updated > code..." refer to? I was vaguely referring to all the fixes from a couple of years ago, plus a foggy recollection of the above (which I thought might have been magically fixed somehow). > I remember that Matthew Garret sent out a patch set a couple of months > ago which aimed to make this configurable per kms driver, so each driver > could opt into low vblank off delay if it was ready to do it properly. > That would make a lot of sense. Yeah, that would also be fine with me. Unfortunately, these simple patches seem to rot on the vine and never get applied, so we're stuck with our current 5s timeout (which is huge). > That said, for the current intel-ddx it wouldn't even matter for X11/GLX > applications if the kernel returned random numbers instead of vblank > counts, because the OML_sync_control swap scheduling in the ddx is > totally broken, and even glXSwapBuffers is a wreck for any swapinterval > setting except 0 and 1 since triple-buffering was introduced a year ago > and introduced some bug. Psychtoolbox now detects this since a few > weeks, prints out critical warnings to the user and tries to work around > with glXSwapBuffers trickery. > > I submitted a patch to fix the rather trivial but nasty bug. Jesse, if > you find some time, could you review it and convince Chris to merge it? > Should be on the intel-gfx list and in your inbox, a simple . Subject line > "[PATCH 2/3] ddx/dri2: Repair broken pageflip swap scheduling.", sent at > 7 October 2012. Yeah, I'll check it out. This code has changed a lot since I last worked on it... > I'll forward it again to you. Chris Wilson already gave me an off-list > review for that patch series after i pinged him. Unfortunately a rather > terse one, cited here: > > "On Mon, 15 Oct 2012 16:46:52 +0200, Mario Kleiner > wrote: > > Hi Chris, > > > > can you please check & merge at least the first two patches of the > > series into the intel ddx? > > The first is along the right path, but I think you want to base the > split on divisor==0. The second is broken in the DRI2 layer, as the > SwapLimit mechanism exposes the multi-client race to a single client > (i.e. there is no serialisation between the InvalidateEvent and the > GetBuffers, and the InvalidateEvent is always broadcast too early.) The > third is just plain wrong, as pageflip may be a blocking ioctl (and will > impose client blocking) so anybody who wants to override SwapBuffersWait > will also want to prevent the inherent wait due to the flip. In any > event that option is to only paper over the loose DRI2 specification and > the lack of client control... > -Chris > " > > If i understood the comment wrt. to patch [2/3] "The first is along the > right path, but I think you want to base the split on divisor==0." > correctly, then that would be just as broken as the current > implementation, with some code obfuscation and confusion added, but i > don't know, maybe i just misunderstood his comment? I asked for > clarification, but he didn't respond to my followup e-mails. Maybe he > was just too busy to reply, maybe i'm just too pushy and annoying. > > I will try to make some friendship with piglit and see if i can write > some tests when i find some time to catch such bugs earlier in
[Bug 27443] radeonFreeTexImageData: Assertion `!image->base.Data' failed when running Ogre3D samples
https://bugs.freedesktop.org/show_bug.cgi?id=27443 Laurent carlier changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #10 from Laurent carlier --- Fixed with r600g / mesa from git / kernel 3.6.5 -> closing -- 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 56663] 2D tiling commit renders screen black on kdm
https://bugs.freedesktop.org/show_bug.cgi?id=56663 --- Comment #9 from Ilija Hadzic --- Just uploaded to https://bugs.freedesktop.org/show_bug.cgi?id=56680 Which should fix the Zaphod mode problem without breaking non-Zaphod mode. Sorry about the goof. -- 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 27457] Blender artifacts when using box select
https://bugs.freedesktop.org/show_bug.cgi?id=27457 --- Comment #3 from Willem Swart --- (In reply to comment #2) > Note: classic r600 driver has been abandoned. > Please use r600g (gallium driver) instead. > > Is this still an issue with a newer driver/kernel? Have not been able to reproduce the bug with current setup: Radeon HD6950 Blender 2.64a-5 xf86-video-ati 1:6.14.6-2 ati-dri 9.0-1 -- 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 27457] Blender artifacts when using box select
https://bugs.freedesktop.org/show_bug.cgi?id=27457 Laurent carlier changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED -- 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 24857] Lightening and object selection in viewport is not working in Blender 3D
https://bugs.freedesktop.org/show_bug.cgi?id=24857 --- Comment #7 from Hans Nieser --- With kernel 3.6.2 and xorg/mesa/libdrm from git the object selection problem is no longer occuring on either my 4850 or 5850 radeons with r600g (has probably been fixed long ago since I've used blender before on occasion without this issue). Lighting is looking correct as well -- 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 24857] Lightening and object selection in viewport is not working in Blender 3D
https://bugs.freedesktop.org/show_bug.cgi?id=24857 Laurent carlier changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED -- 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: [Intel-gfx] [PATCH 0/3] drm/i915: eDP scaling mode change support
Hi Jani, Sorry for the delay, our branches have diverged significantly, and it took me quite a while to merge your changes. On the bright sight, I've tested the patch on SandyBridge LDVS and IvyBridge eDP, and it works fine. Regards, Yuly. On Fri, Oct 26, 2012 at 9:44 AM, Paulo Zanoni wrote: > Hi > > 2012/10/26 Jani Nikula : > > [Dropped lkml, added intel-gfx] > > > > Hi Yuly, here's a slightly modified version of your patch, rebased on > > drm-intel-next-queued. I kept your authorship, but any new errors are > > totally mine... > > > > These are compile tested only; I'd appreciate if you could check it > > still does what it says on the box! > > I have nothing to add or remove. Tested on HSW eDP, used "xrandr" to > alternate the property values. Works fine. > > Being consistent on the default value between LVDS and eDP is > certainly a nice thing. > > For the 3 patches: > Reviewed-by: Paulo Zanoni > Tested-by: Paulo Zanoni > > > > > BR, > > Jani. > > > > > > Jani Nikula (1): > > drm/i915/lvds: move fitting mode from intel_lvds_connector to > > intel_panel > > > > Yuly Novikov (2): > > drm/i915/dp: allow configuring eDP panel fitting scaling mode > > drm/i915/dp: change eDP default scaling mode to respect aspect ratio > > > > drivers/gpu/drm/i915/intel_dp.c | 31 ++- > > drivers/gpu/drm/i915/intel_drv.h |1 + > > drivers/gpu/drm/i915/intel_lvds.c | 24 ++-- > > 3 files changed, 41 insertions(+), 15 deletions(-) > > > > -- > > 1.7.9.5 > > > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Paulo Zanoni > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] i915: failure to interoperate with HP ZR30w using an X230
Ping? On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote: > On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote: > > > [1] drm-intel-next-queued branch at > > > git://people.freedesktop.org/~danvet/drm-intel > > > > Hmm, actually not. Either drm-intel-fixes branch, or Linus' master. > > Confirmed, the drm-intel-fixes branch from Daniel's tree > (3.7.0-rc2-00031-g1623392) works fine for me. > > Do you know which commit(s) are likely to have fixed the problem, so we > can cherry pick the appropriate fix(es) to the 3.6.x tree? > > Thanks, > > - Ted ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56666] AMD SUMO GPU lockup when launching any heavy 3D application
https://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #2 from runetmem...@gmail.com --- > This might be a duplicate of bug 56405. Probably. If my issue is still reproducible when the bug 56405 will be fixed, I'll reopen this bugreport. > Can you try mesa 8.0.x? With Mesa 8.0.2 (Kubuntu 12.04.1 x86_64 LiveCD) there is no GPU lockup in Unigine Heaven 3. > If 8.0.x works, can you bisect? I'm afraid I can't. -- 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 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 runetmem...@gmail.com changed: What|Removed |Added CC||runetmem...@gmail.com --- Comment #9 from runetmem...@gmail.com --- *** Bug 5 has been marked as a duplicate of this bug. *** -- 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
[PATCH 1/2] drm/nouveau: Add interface to detect optimus and v1 support
From: Dave Airlie
This is required to decide if we can auto-powerdown and how to implement it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 30 ++
drivers/gpu/drm/nouveau/nouveau_acpi.h | 4
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 48783e1..d97f200 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -35,6 +35,14 @@ static struct nouveau_dsm_priv {
acpi_handle rom_handle;
} nouveau_dsm_priv;
+bool nouveau_is_optimus(void) {
+ return nouveau_dsm_priv.optimus_detected;
+}
+
+bool nouveau_is_v1_dsm(void) {
+ return nouveau_dsm_priv.dsm_detected;
+}
+
#define NOUVEAU_DSM_HAS_MUX 0x1
#define NOUVEAU_DSM_HAS_OPT 0x2
@@ -183,9 +191,7 @@ static int nouveau_dsm_set_discrete_state(acpi_handle
handle, enum vga_switchero
static int nouveau_dsm_switchto(enum vga_switcheroo_client_id id)
{
- /* perhaps the _DSM functions are mutually exclusive, but prepare for
-* the future */
- if (!nouveau_dsm_priv.dsm_detected && nouveau_dsm_priv.optimus_detected)
+ if (!nouveau_dsm_priv.dsm_detected)
return 0;
if (id == VGA_SWITCHEROO_IGD)
return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle,
NOUVEAU_DSM_LED_STAMINA);
@@ -201,7 +207,7 @@ static int nouveau_dsm_power_state(enum
vga_switcheroo_client_id id,
/* Optimus laptops have the card already disabled in
* nouveau_switcheroo_set_state */
- if (!nouveau_dsm_priv.dsm_detected && nouveau_dsm_priv.optimus_detected)
+ if (!nouveau_dsm_priv.dsm_detected)
return 0;
return nouveau_dsm_set_discrete_state(nouveau_dsm_priv.dhandle, state);
@@ -283,24 +289,24 @@ static bool nouveau_dsm_detect(void)
has_optimus = 1;
}
- if (vga_count == 2 && has_dsm && guid_valid) {
+ /* find the optimus DSM or the old v1 DSM */
+ if (has_optimus == 1) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
&buffer);
- printk(KERN_INFO "VGA switcheroo: detected DSM switching method
%s handle\n",
+ printk(KERN_INFO "VGA switcheroo: detected Optimus DSM method
%s handle\n",
acpi_method_name);
- nouveau_dsm_priv.dsm_detected = true;
+ nouveau_dsm_priv.optimus_detected = true;
ret = true;
- }
-
- if (has_optimus == 1) {
+ } else if (vga_count == 2 && has_dsm && guid_valid) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
&buffer);
- printk(KERN_INFO "VGA switcheroo: detected Optimus DSM method
%s handle\n",
+ printk(KERN_INFO "VGA switcheroo: detected DSM switching method
%s handle\n",
acpi_method_name);
- nouveau_dsm_priv.optimus_detected = true;
+ nouveau_dsm_priv.dsm_detected = true;
ret = true;
}
+
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 08af677..d0da230 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -4,6 +4,8 @@
#define ROM_BIOS_PAGE 4096
#if defined(CONFIG_ACPI)
+bool nouveau_is_optimus(void);
+bool nouveau_is_v1_dsm(void);
void nouveau_register_dsm_handler(void);
void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
@@ -11,6 +13,8 @@ int nouveau_acpi_get_bios_chunk(uint8_t *bios, int offset,
int len);
bool nouveau_acpi_rom_supported(struct pci_dev *pdev);
void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
#else
+static inline bool nouveau_is_optimus(void) { return false; };
+static inline bool nouveau_is_v1_dsm(void) { return false; };
static inline void nouveau_register_dsm_handler(void) {}
static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
--
1.7.12.1
[PATCH 2/2] drm/nouveau: convert to dev_pm_ops
From: Dave Airlie
This is a precursor to dynamic power management support for nouveau,
we need to use pm ops for that, so first convert the driver to using pm ops
interfaces.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 93 +--
drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +-
drivers/gpu/drm/nouveau/nouveau_vga.c | 5 +-
3 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ccae8c2..85aa1a6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -392,17 +392,12 @@ nouveau_drm_remove(struct pci_dev *pdev)
}
int
-nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t pm_state)
+nouveau_do_suspend(struct drm_device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_cli *cli;
int ret;
- if (dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
- pm_state.event == PM_EVENT_PRETHAW)
- return 0;
-
NV_INFO(drm, "suspending fbcon...\n");
nouveau_fbcon_set_suspend(dev, 1);
@@ -431,13 +426,6 @@ nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t
pm_state)
goto fail_client;
nouveau_agp_fini(drm);
-
- pci_save_state(pdev);
- if (pm_state.event == PM_EVENT_SUSPEND) {
- pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
- }
-
return 0;
fail_client:
@@ -450,24 +438,33 @@ fail_client:
return ret;
}
-int
-nouveau_drm_resume(struct pci_dev *pdev)
+int nouveau_pmops_suspend(struct device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nouveau_cli *cli;
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;
- if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
- NV_INFO(drm, "re-enabling device...\n");
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- ret = pci_enable_device(pdev);
+ ret = nouveau_do_suspend(drm_dev);
if (ret)
return ret;
- pci_set_master(pdev);
+
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+
+ return 0;
+}
+
+int
+nouveau_do_resume(struct drm_device *dev)
+{
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct nouveau_cli *cli;
+
+ NV_INFO(drm, "re-enabling device...\n");
nouveau_agp_reset(drm);
@@ -491,6 +488,42 @@ nouveau_drm_resume(struct pci_dev *pdev)
return 0;
}
+int nouveau_pmops_resume(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ int ret;
+
+ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ return 0;
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+ pci_set_master(pdev);
+
+ return nouveau_do_resume(drm_dev);
+}
+
+static int nouveau_pmops_freeze(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return nouveau_do_suspend(drm_dev);
+}
+
+static int nouveau_pmops_thaw(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return nouveau_do_resume(drm_dev);
+}
+
+
static int
nouveau_drm_open(struct drm_device *dev, struct drm_file *fpriv)
{
@@ -643,14 +676,22 @@ nouveau_drm_pci_table[] = {
{}
};
+static const struct dev_pm_ops nouveau_pm_ops = {
+ .suspend = nouveau_pmops_suspend,
+ .resume = nouveau_pmops_resume,
+ .freeze = nouveau_pmops_freeze,
+ .thaw = nouveau_pmops_thaw,
+ .poweroff = nouveau_pmops_freeze,
+ .restore = nouveau_pmops_resume,
+};
+
static struct pci_driver
nouveau_drm_pci_driver = {
.name = "nouveau",
.id_table = nouveau_drm_pci_table,
.probe = nouveau_drm_probe,
.remove = nouveau_drm_remove,
- .suspend = nouveau_drm_suspend,
- .resume = nouveau_drm_resume,
+ .driver.pm = &nouveau_pm_ops,
};
static int __init
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h
b/drivers/gpu/drm/nouveau/nouveau_drm.h
index 8194712..e0c99aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.h
@@ -129,8 +129,8 @@ nouveau_dev(struct drm_device *dev)
return nv_device(nouveau_drm(dev)->device);
}
-int nouveau_drm_suspend(struct pci_dev *, pm_message_t);
[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown
https://bugs.freedesktop.org/show_bug.cgi?id=56634 --- Comment #2 from Alexandre Demers --- Do you mean it's slower than without the commit or is it running mostly at the same speed when it's slowing down? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121102/09bcd562/attachment-0001.html>
[PATCH] drm: exynos: fix for mapping non contig dma buffers
It's good patch. Right, there was my missing point. I thought each sgl would
always have 4k page. But dma mapping api, dma_alloc_alloc(), allocates
physical memory as continuously as possible so the sgl can have group of
pages.
Below is my comment.
> -Original Message-
> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> Sent: Thursday, November 01, 2012 9:35 PM
> To: dri-devel at lists.freedesktop.org
> Cc: sw0312.kim at samsung.com; inki.dae at samsung.com; jy0922.shim at
> samsung.com;
> kyungmin.park at samsung.com; prashanth.g at samsung.com; joshi at
> samsung.com;
> s.shirish at samsung.com; r.sh.open at gmail.com; rahul.sharma at samsung.com
> Subject: [PATCH] drm: exynos: fix for mapping non contig dma buffers
>
> This patch fixes the problem of mapping gem objects which are non-
> contigous
> dma buffers. These buffers are described using SG table and SG lists. Each
> valid SG List is pointing to a single page or group of pages which are
> physically contigous.
>
> Current implementation just maps the first page of each SG List and leave
> the other pages unmapped, leading to a crash.
>
> Given solution finds the page struct for all the pages in the SG list and
> map them one by one. This ensures all the pages of current SG list are
> mapped.
> Next SG list of the same buffer will be mapped when page fault occurs for
> the offset belongs to that list.
>
> This patch is based on branch exynos-drm-next-iommu at
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 34
> +++---
> 1 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 7057729..d2d6188 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -95,17 +95,43 @@ static int exynos_drm_gem_map_buf(struct
> drm_gem_object *obj,
> {
> struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
> struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
> + struct scatterlist *sgl;
> unsigned long pfn;
> + unsigned int phys_addr;
> + int ret, i;
>
> if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
> if (!buf->pages)
> return -EINTR;
Buf->pages should be checked in all cases. For this, see below comment.
>
> - pfn = page_to_pfn(buf->pages[page_offset++]);
> - } else
> + sgl = buf->sgt->sgl;
> + for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
> + if (page_offset < (sgl->length >> PAGE_SHIFT))
> + break;
> + page_offset -= (sgl->length >> PAGE_SHIFT);
> + }
> +
> + if (i >= buf->sgt->nents) {
> + DRM_ERROR("invalid page offset\n");
> + return -EINVAL;
> + }
> +
> + phys_addr = sg_phys(sgl);
> +
> + for (i = 0; i < (sgl->length >> PAGE_SHIFT); i++) {
> + pfn = __phys_to_pfn(phys_addr + (i << PAGE_SHIFT));
> + ret = vm_insert_mixed(vma, f_vaddr + (i <<
PAGE_SHIFT),
> + pfn);
> + if (ret < 0) {
> + DRM_ERROR("failed to map page.\n");
> + return ret;
> + }
> + }
> + return 0;
> + } else {
> pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
It seems like that you missed EXYNOS_BO_CONTIG type testing. With iommu,
buf->dma_addr has device address but not physical address. So correct it
like below,
pfn = page_to_pfn(buf->pages[0]) + page_offset;
And one more posting? :)
Thanks,
Inki Dae
> -
> - return vm_insert_mixed(vma, f_vaddr, pfn);
> + return vm_insert_mixed(vma, f_vaddr, pfn);
> + }
> }
>
> static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
> --
> 1.7.0.4
