[Bug 36602] New: Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Summary: Hierarchical Z support for R600 Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pell...@gmail.com Add Hierarchical Z (HiZ) support for r600g driver. I'm attaching my work-in-progress patchs to this bug report to keep track of comments. This patch adds 3 new env vars : - R600_EARLYZ : controls whether EarlyZ functionnality is used (DB_SHADER_CONTROL register) - R600_HIZ : HiZ enabled/disabled - R600_HIZ_READ_HACK : this one is a quick hack for debugging HiZ data buffer. If set, data will be read from HiZ bo instead of depth buffer bo when calling glReadPixels( ... GL_DEPTH_COMPONENT ...) General notes on HiZ on r600 : (all testing done using : ATI Technologies Inc RV770 [Radeon HD 4850]) * HiZ buffer is made of DWORD entries. Each DWORD represents one tile (4x4 or 8x8 pixels depending DB_HTILE_SURFACE register fields) * HiZ buffer does not need to be manually cleared by the driver * DB_RENDER_CONTROL:RESUMMARIZE_ENABLE bit is not necessary to get it working - but if enabled it slows things down * application performance are roughly the same using R600_EARLYZ or R600_HIZ Know problems : * Hierarchical Stencil has not been tested * HiZ buffer data layout is still unclear. As an example : using 640x640 window and 8x8 tiles. HiZ buffer should contain (640/8)*(640/8) = 6400 entries. When reading it back using the above hack, it contains 6400 entries but spread on the 7680 first dwords of the buffer. Therefore HiZ bo if largely oversized for now (ie = depth buffer size) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #1 from Pierre-Eric 2011-04-26 00:59:16 PDT --- Created an attachment (id=46081) View: https://bugs.freedesktop.org/attachment.cgi?id=46081 Review: https://bugs.freedesktop.org/review?bug=36602&attachment=46081 Hiz bo deletion patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #2 from Pierre-Eric 2011-04-26 00:59:59 PDT --- Created an attachment (id=46082) View: https://bugs.freedesktop.org/attachment.cgi?id=46082 Review: https://bugs.freedesktop.org/review?bug=36602&attachment=46082 HiZ initial patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #3 from Pierre-Eric 2011-04-26 01:01:54 PDT --- Created an attachment (id=46083) View: https://bugs.freedesktop.org/attachment.cgi?id=46083 Review: https://bugs.freedesktop.org/review?bug=36602&attachment=46083 kernel side patch to handle TILE_SURFACE commands (patch built against linux 2.6.38.3) This one is minimum, and is lacking hiz bo size checks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 Riccardo Angelino changed: What|Removed |Added CC||rikyinformat...@gmail.com --- Comment #3 from Riccardo Angelino 2011-04-26 09:31:02 --- njin thanks for report. (In reply to comment #1) > Please attach your dmesg output and xorg log. Is this a laptop with hybrid > graphics? Hello Alex not is a laptop but a pc desktop with hybrid graphics. My graphic card is ATI Radeon HD 3450. I attach the xorg log file and the file of my hardware, so you can check. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 --- Comment #4 from Riccardo Angelino 2011-04-26 09:32:03 --- Created an attachment (id=55532) --> (https://bugzilla.kernel.org/attachment.cgi?id=55532) xorg log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 --- Comment #5 from Riccardo Angelino 2011-04-26 09:33:26 --- Created an attachment (id=55542) --> (https://bugzilla.kernel.org/attachment.cgi?id=55542) My hardware components -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 Riccardo Angelino changed: What|Removed |Added Attachment #55542|My hardware components |hardware components description|| -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
> I was planning on adding a new fb ioctl to allow us to create fbs with
> specific surface format types. We could either enumerate all of the
> ones we support (a list which will grow as drivers and devices are
> added) or try to factor out commit bits into a separate surface struct:
>
> struct drm_mode_surface {
> enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
> int depth;
> enum packing; /* some list of packing types? */
> ...
> };
Any reason for not just using the Video4Linux 2 formats here, they've
been enumerating video formats for some time already.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
> A lot of older hardware had one overlay that could be sourced to any > crtc, just not simultaneously. The tricky part is the formats and > capabilities: alpha blending, color/chromakey, gamma correction, etc. > Even the current crtc gamma stuff is somewhat lacking in in terms of > what hardware is capable of (PWL vs. LUT, user defined conversion > matrices, gamut remapping, etc.). Rather than re-inventing enough wheels to run a large truck would it not make sense to make hardware sourced overlays Video4Linux objects in their entirity so you can just say "attach V4L object A as overlay B" That would provide format definitions, provide control interfaces for the surface (eg for overlays of cameras such as on some of the Intel embedded and non PC devices), give you an existing well understood API. For some hardware you are going to need this integration anyway so that you can do things like move a GEM object which is currently a DMA target of a capture device (as well as to fence it). For a software surface you could either expose it as a V4L object that is GEM or fb memory backed or at least use the same descriptions so that the kernel has a consistent set of descriptions for formats and we don't have user libraries doing adhoc format translation crap. A lot of capture hardware would map very nicely onto GEM objects I suspect and if you want to merge live video into Wayland it seems a logical path ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36525] Enemy territory freezes system with r600g.
https://bugs.freedesktop.org/show_bug.cgi?id=36525 Michel Dänzer changed: What|Removed |Added Product|DRI |Mesa Version|unspecified |git Component|DRM/Radeon |Drivers/Gallium/r600 CC||fred...@kde.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36598] [RS880] Slow resume from suspend generates kernel warning
https://bugs.freedesktop.org/show_bug.cgi?id=36598 Alex Deucher changed: What|Removed |Added Summary|[RS880] Slow resume from|[RS880] Slow resume from |suspend generates kernel|suspend generates kernel |oops|warning --- Comment #1 from Alex Deucher 2011-04-26 06:39:28 PDT --- This is not an oops it's just a warning that it took longer than 10 seconds. If it works fine after resume there's nothing to worry about. Is the warning a regression from a previous kernel? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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: [RFC] drm: add overlays as first class KMS objects
On Mon, Apr 25, 2011 at 8:33 PM, Jesse Barnes wrote:
> On Mon, 25 Apr 2011 20:28:20 -0400
> Alex Deucher wrote:
>
>> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
>> wrote:
>> > On Mon, 25 Apr 2011 16:16:18 -0700
>> > Keith Packard wrote:
>> >
>> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
>> >> wrote:
>> >>
>> >> > Overlays are a bit like half-CRTCs. They have a location and fb, but
>> >> > don't drive outputs directly. Add support for handling them to the core
>> >> > KMS code.
>> >>
>> >> Are overlays/underlays not associated with a specific CRTC? To my mind,
>> >> overlays are another scanout buffer associated with a specific CRTC, so
>> >> you'd create a scanout buffer and attach that to a specific scanout slot
>> >> in a crtc, with the 'default' slot being the usual graphics plane.
>> >
>> > Yes, that matches my understanding as well. I've deliberately made the
>> > implementation flexible there though, under the assumption that some
>> > hardware allows a plane to be directed at more than one CRTC (though
>> > probably not simultaneously).
>>
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stuff is somewhat lacking in in terms of
>> what hardware is capable of (PWL vs. LUT, user defined conversion
>> matrices, gamut remapping, etc.).
>
> Right, this implementation allows an overlay to be tied to any crtc
> listed in the possible_crtcs mask (matching the other possible_*
> fields), but only one at a time. I think that's fairly common.
>
> Agree about formats and capabilities. I think enumerating available
> formats is best, perhaps making that a driver specific array if we
> can't agree on a common set.
I would rather have format be common to all hardware, rather than
having a list per hardware. uint32_t would give enough room to add all
formats even if one format is only supported by one hardware only (at
one point in time). Also this would allow to have second dumb way to
allocate scanout buffer in non driver specific way. Maybe we need
another ioctl to query support format somethings like :
struct drm_format_supported {
uint32_t nformats;
uint32_t __user *formats;
};
Userspace supply an array of format and driver overwritte entry that
are not supported with 0, 0 would be a special INVALID format.
> Dealing with color correction could also be driver specific; once
> the client has an overlay id it can use driver specific ioctls to
> get/set specifics.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
Is there that many different way to do color corrections ?
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
> having a list per hardware. uint32_t would give enough room to add all > formats even if one format is only supported by one hardware only (at It would indeed. A point realised by the Amiga designers in 1985 and turned into a standard of sorts with a registry and process and adopted by folks like Apple and Microsoft. See www.fourcc.org. 4CC is already used by the kernel for Video4Linux. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36608] New: Corrupt GL rendering
https://bugs.freedesktop.org/show_bug.cgi?id=36608 Summary: Corrupt GL rendering Product: Mesa Version: git Platform: IA64 (Itanium) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: emeric.masch...@gmail.com Created an attachment (id=46090) --> (https://bugs.freedesktop.org/attachment.cgi?id=46090) Screenshot showing corrupt GL rendering in glxgears as an example Hi, I was asked there (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622299#67) to report this bug upstream. GL rendering is currently corrupt on IA-64 with Gallium r300 driver (cf. attached screenshot with running glxgears as an example). Classic driver renders display correctly. Regards, Émeric -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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: [RFC] drm: add overlays as first class KMS objects
On Tue, Apr 26, 2011 at 10:16 AM, Alan Cox wrote: >> having a list per hardware. uint32_t would give enough room to add all >> formats even if one format is only supported by one hardware only (at > > It would indeed. A point realised by the Amiga designers in 1985 and > turned into a standard of sorts with a registry and process and adopted > by folks like Apple and Microsoft. > > See www.fourcc.org. 4CC is already used by the kernel for Video4Linux. > I think 4cc it bit useless with RGB stuff (or maybe i just don't understand 4cc). For instance i think we want uniq different id for RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says rgb and than rely on additional informations for color order or components size. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
On Tue, 26 Apr 2011 11:01:30 +0100 Alan Cox wrote: > > A lot of older hardware had one overlay that could be sourced to any > > crtc, just not simultaneously. The tricky part is the formats and > > capabilities: alpha blending, color/chromakey, gamma correction, etc. > > Even the current crtc gamma stuff is somewhat lacking in in terms of > > what hardware is capable of (PWL vs. LUT, user defined conversion > > matrices, gamut remapping, etc.). > > Rather than re-inventing enough wheels to run a large truck would it not > make sense to make hardware sourced overlays Video4Linux objects in their > entirity so you can just say "attach V4L object A as overlay B" > > That would provide format definitions, provide control interfaces for > the surface (eg for overlays of cameras such as on some of the Intel > embedded and non PC devices), give you an existing well understood API. > > For some hardware you are going to need this integration anyway so that > you can do things like move a GEM object which is currently a DMA target > of a capture device (as well as to fence it). > > For a software surface you could either expose it as a V4L object that > is GEM or fb memory backed or at least use the same descriptions so that > the kernel has a consistent set of descriptions for formats and we don't > have user libraries doing adhoc format translation crap. > > A lot of capture hardware would map very nicely onto GEM objects I > suspect and if you want to merge live video into Wayland it seems a > logical path ? Thanks Alan, of course that's a good idea, I'll see about integrating the two. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
> I think 4cc it bit useless with RGB stuff (or maybe i just don't > understand 4cc). For instance i think we want uniq different id for > RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says > rgb and than rely on additional informations for color order or > components size. Yes - grep "fourcc" include/linux/videodev2.h plus see the docs - I think its sufficient for pretty much all of it we would end up needing except maybe a few texture formats like S3TC (which are of course 4CC codes too) Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote: > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > wrote: > > > Overlays are a bit like half-CRTCs. They have a location and fb, but > > don't drive outputs directly. Add support for handling them to the core > > KMS code. > > Are overlays/underlays not associated with a specific CRTC? To my mind, > overlays are another scanout buffer associated with a specific CRTC, so > you'd create a scanout buffer and attach that to a specific scanout slot > in a crtc, with the 'default' slot being the usual graphics plane. And what if you don't have a "default" plane as such. For example, OMAP3 has one graphics plane and two video planes, and two output paths. Each of the planes can be assigned to zero or one outputs. To accomodate this, the design should allow for CRTCs without any scanout buffers. Also a glance at DirectFB and OpenWF Display APIs might be helpful. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
On Tue, 26 Apr 2011 18:20:03 +0300 Ville Syrjälä wrote: > On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote: > > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > > wrote: > > > > > Overlays are a bit like half-CRTCs. They have a location and fb, but > > > don't drive outputs directly. Add support for handling them to the core > > > KMS code. > > > > Are overlays/underlays not associated with a specific CRTC? To my mind, > > overlays are another scanout buffer associated with a specific CRTC, so > > you'd create a scanout buffer and attach that to a specific scanout slot > > in a crtc, with the 'default' slot being the usual graphics plane. > > And what if you don't have a "default" plane as such. For example, OMAP3 > has one graphics plane and two video planes, and two output paths. Each > of the planes can be assigned to zero or one outputs. To accomodate this, > the design should allow for CRTCs without any scanout buffers. > > Also a glance at DirectFB and OpenWF Display APIs might be helpful. The current drm crtc code ties together a crtc and fb, but it wouldn't be too hard to split it out a little (such that passing a null fb on a mode set wouldn't disable the crtc, or attaching a new scanout surface to a crtc would enable it) to support something like that. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
> And what if you don't have a "default" plane as such. For example, OMAP3 > has one graphics plane and two video planes, and two output paths. Each > of the planes can be assigned to zero or one outputs. To accomodate this, > the design should allow for CRTCs without any scanout buffers. Some TV type stuff is a bit like that - well there may be a scanout buffer but its on a protected hardware path and no part of the system except certain bits of hardware can touch it from decrypt to output connector. Clearly a scanout buffer isn't the only way to describe what a crtc is outputting and you need a somewhat more flexible handle including one you can acquire somehow to represent other objects like capture buffers, protected planes and live video merges. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add missing safe regs for 6xx/7xx
needed for HiS in mesa. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/reg_srcs/r600 |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/r600 b/drivers/gpu/drm/radeon/reg_srcs/r600 index af0da4a..92f1900 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/r600 +++ b/drivers/gpu/drm/radeon/reg_srcs/r600 @@ -708,6 +708,7 @@ r600 0x9400 0x00028D0C DB_RENDER_CONTROL 0x00028D10 DB_RENDER_OVERRIDE 0x0002880C DB_SHADER_CONTROL +0x00028D28 DB_SRESULTS_COMPARE_STATE0 0x00028D2C DB_SRESULTS_COMPARE_STATE1 0x00028430 DB_STENCILREFMASK 0x00028434 DB_STENCILREFMASK_BF -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add info query for tile pipes
needed by mesa for htile setup.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 13 +
include/drm/radeon_drm.h|1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index bf7d4c0..871df03 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -221,6 +221,19 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_NUM_TILE_PIPES:
+ if (rdev->family >= CHIP_CAYMAN)
+ value = rdev->config.cayman.max_tile_pipes;
+ else if (rdev->family >= CHIP_CEDAR)
+ value = rdev->config.evergreen.max_tile_pipes;
+ else if (rdev->family >= CHIP_RV770)
+ value = rdev->config.rv770.max_tile_pipes;
+ else if (rdev->family >= CHIP_R600)
+ value = rdev->config.r600.max_tile_pipes;
+ else {
+ return -EINVAL;
+ }
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 3bce1a4..7aa5ddd 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -909,6 +909,7 @@ struct drm_radeon_cs {
#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
#define RADEON_INFO_NUM_BACKENDS 0x0a /* DB/backends for r600+ - need
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
struct drm_radeon_info {
uint32_trequest;
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36611] New: [wine] The Witcher: Crash in u_vbuf_mgr_draw_begin
https://bugs.freedesktop.org/show_bug.cgi?id=36611 Summary: [wine] The Witcher: Crash in u_vbuf_mgr_draw_begin Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se Created an attachment (id=46094) --> (https://bugs.freedesktop.org/attachment.cgi?id=46094) Backtrace The game The Witcher (running in Wine) crashes shortly after start: u_vbuf_mgr_draw_begin+0x198(mgrb=0x7c5937c0, info=0x1c6ec5c, buffers_updated="À`¬d|", uploader_flushed="") [/home/sa/Programming/gfx/mesa/mesa/src/gallium/auxiliary/util/u_vbuf_mgr.c:549] in r300_dri.so (0x01c6e9f4) This does not happen in 7.10. Bisecting leads to this commit: c95bc1224a4b20b9470ddcb37b5f78975991073b is the first bad commit commit c95bc1224a4b20b9470ddcb37b5f78975991073b Author: Marek Olšák Date: Mon Feb 7 02:00:44 2011 +0100 r300g: use the new vertex buffer manager :04 04 4be08dc19f4fa4e1de6b1b259c6bd481b2fc33e5 28f8c721e519137890b5082fdff66671dbcfacb0 Msrc I'm attaching a backtrace, but I'm not sure how helpful it is, as getting it from Wine was quite tricky. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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: i915 completely unusable in 2.6.38.x
* Melchior FRANZ -- Tuesday 26 April 2011:
> [https://bugzilla.kernel.org/show_bug.cgi?id=31522]
I've replied to this error message, but here again for this audience:
The commit that broke all 2.6.38.* releases for my machine is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba3820ade317ee36e496b9b40d2ec3987dd4aef0
(Takashi Iwai: "drm/i915: Revive combination mode for backlight
control").
In 'is_backlight_combination_mode()' INTEL_INFO(dev)->gen
equals 4, and the function returns 0x4000 in "combination mode".
In 'intel_panel_get_backlight()' this happens:
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK; // val = 0x0b4a
if (IS_PINEVIEW(dev)) // false
val >>= 1;
if (is_backlight_combination_mode(dev)){
u8 lbpc;
val &= ~1;// val = 0x0b4a
pci_read_config_byte(dev->pdev, PCI_LBPC, &lbpc); // lbpc = 0
val *= lbpc; // val = 0
}
The backlight remains off and does also not react to the "brighter" key
event.
Reverting the patch fixes my system, obviously.
m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #4 from Alex Deucher 2011-04-26 11:53:25 PDT --- Thanks for starting on this. I've provided an overview of of how HiZ and HiS work on 6xx+ hw and some relevant drm patches here: http://people.freedesktop.org/~agd5f/htile/ ping me on irc (agd5f) if you have any questions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 35935] since 2.6.38.1, screen become garbled after some times (RV770)
https://bugs.freedesktop.org/show_bug.cgi?id=35935 --- Comment #5 from Mjules 2011-04-26 14:20:30 PDT --- The result of the bisection is : ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 is the first bad commit commit ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 Author: Stanislav Kinsbursky Date: Thu Mar 17 18:54:23 2011 +0300 RPC: killing RPC tasks races fixed commit 8e26de238fd794c8ea56a5c98bf67c40cfeb051d upstream. RPC task RPC_TASK_QUEUED bit is set must be checked before trying to wake up task rpc_killall_tasks() because task->tk_waitqueue can not be set (equal to NULL). Also, as Trond Myklebust mentioned, such approach (instead of checking tk_waitqueue to NULL) allows us to "optimise away the call to rpc_wake_up_queued_task() altogether for those tasks that aren't queued". Here is an example of dereferencing of tk_waitqueue equal to NULL: CPU 0 CPU 1CPU 2 --- nfs4_run_open_task rpc_run_task rpc_execute rpc_set_active rpc_make_runnable (waiting) rpc_async_schedule nfs4_open_prepare nfs_wait_on_sequence nfs_umount_begin rpc_killall_tasks rpc_wake_up_task rpc_wake_up_queued_task spin_lock(tk_waitqueue == NULL) BUG() rpc_sleep_on spin_lock(&q->lock) __rpc_sleep_on task->tk_waitqueue = q Signed-off-by: Stanislav Kinsbursky Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman :04 04 91b88f0611c9ff1cf2691d9d65ec13c652a554ac e23b6d459a8bef93de6ea4821754e2f51e3ad32f Mnet which seems completely bogus to me (I don't use nfs). BTW, the bug is still present with 2.6.38.3 and seems more frequent with it. Another detail is it occurs only one time during a session. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36554] Amnesia game causes black screen or kernel locks
https://bugs.freedesktop.org/show_bug.cgi?id=36554 --- Comment #3 from Hicham HAOUARI 2011-04-26 15:49:17 PDT --- (In reply to comment #2) > This is probably hardware specific, I haven't had any problems with Amnesia on > my RV570. What kernel version do you have ? The game runs fine for me on Fedora 14, while on Fedora 15, I used to have Scott's issues. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #1 from Ernst Sjöstrand 2011-04-26 21:35:31 PDT --- I was in a hurry but I thought it was better with a quick bugreport than no report at all. :-) This was with Ubuntu Natty's 2.6.38 kernel + xorg-edgers 20110422. Can't remember exactly what I did, some window management operation. Hasn't happened since. Attached to compiz with gdb from the console and got the backtrace when this happened. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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: weird display issues using radeon HDMI output
On Mon, Apr 25, 2011 at 9:13 PM, Shane O'Connell wrote: > Hi all, > I'm having problems getting the HDMI output of my motherboard working > with a Samsung TV. The motherboard is an MSI 785GM-P45 with an AMD > 785G chipset with an onboard Radeon HD 4200. I can see the desktop on > the TV, but the edges are cut off and the colours are weird. Your TV is overscanning hdmi. You can either disable overscan in your TV's configuration, or enable underscan in the radeon driver (xrandr --output HDMI-0 --set underscan on). As for the color problems, try disabling hdmi audio (using kernel 2.6.38 or newer, boot with radeon.audio=0 on the kernel command line in grub. > Strangely, another computer connected to the same TV using VGA is > working fine. > I've looked over the Xorg.0.log file for the computer using HDMI and > the one using VGA, and it looks like they get slightly different EDID > information from the TV. I don't know enough about it though to know > if it's related to my problem. Here's a couple of key lines from the > logs where they seem to differ (I've attached the complete log files > as well, there's another few places where they don't match but these > seem the most notable to me): The TV treats the VGA and HDMI inputs differently. Alex > > VGA: > [ 10.808] (II) intel(0): EDID for output VGA1 > [ 10.808] (II) intel(0): Manufacturer: SAM Model: 666 Serial#: 0 > [ 10.808] (II) intel(0): Year: 2009 Week: 47 > > HDMI: > [ 1026.636] (II) RADEON(0): EDID for output HDMI-0 > [ 1026.636] (II) RADEON(0): Manufacturer: SAM Model: 667 Serial#: 1 > [ 1026.636] (II) RADEON(0): Year: 2009 Week: 47 > > > VGA: > [ 10.809] (II) intel(0): Ranges: V min: 60 V max: 75 Hz, H min: 30 > H max: 81 kHz, PixClock max 175 MHz > > HDMI: > [ 1026.636] (II) RADEON(0): Ranges: V min: 24 V max: 75 Hz, H min: 26 > H max: 81 kHz, PixClock max 235 MHz > > > VGA: > [ 10.809] (II) intel(0): EDID (in hex): > [ 10.809] (II) intel(0): 00004c2d6606 > [ 10.809] (II) intel(0): 2f130103685832782aee91a3544c9926 > [ 10.809] (II) intel(0): 0f5054bdef80714f8100814081809500 > [ 10.809] (II) intel(0): 950fb300a940023a801871382d40582c > [ 10.809] (II) intel(0): 450076f2311e662150b051001b30 > [ 10.809] (II) intel(0): 4070360076f2311e00fd003c > [ 10.809] (II) intel(0): 4b1e5111000a20202020202000fc > [ 10.809] (II) intel(0): 0053414d53554e470a20202020200053 > [ 10.809] (II) intel(0): EDID vendor "SAM", prod id 1638 > [ 10.809] (II) intel(0): Using EDID range info for horizontal sync > [ 10.809] (II) intel(0): Using EDID range info for vertical refresh > > HDMI: > [ 1026.636] (II) RADEON(0): EDID (in hex): > [ 1026.636] (II) RADEON(0): 00004c2d67060100 > [ 1026.636] (II) RADEON(0): 2f130103801009780aee91a3544c9926 > [ 1026.636] (II) RADEON(0): 0f5054bdef80714f8100814081809500 > [ 1026.636] (II) RADEON(0): 950fb300a940023a801871382d40582c > [ 1026.636] (II) RADEON(0): 4500a05a001e662150b051001b30 > [ 1026.636] (II) RADEON(0): 40703600a05a001e00fd0018 > [ 1026.636] (II) RADEON(0): 4b1a5117000a20202020202000fc > [ 1026.636] (II) RADEON(0): 0053414d53554e470a20202020200129 > [ 1026.636] (II) RADEON(0): 020322f1469004050320222309070783 > [ 1026.636] (II) RADEON(0): 01e2000fe305030167030c002000 > [ 1026.636] (II) RADEON(0): b82d011d007251d01e206e285500a05a > [ 1026.636] (II) RADEON(0): 001e011d8018711c1620582c2500 > [ 1026.636] (II) RADEON(0): a05a009e8c0ad08a20e02d10103e > [ 1026.636] (II) RADEON(0): 9600a05a0018 > [ 1026.636] (II) RADEON(0): > [ 1026.636] (II) RADEON(0): 00df > > > Does anybody know where I should go from here? Is there anything else > I can try? My thinking is somehow maybe the EDID information received > over HDMI is incorrect, if so does that mean a quirk can be added for > this TV so that it works properly? > > Thanks! > -Shane O'Connell > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Send pending vblank events before disabling vblank.
From: Christopher James Halse Rogers
This is the least-bad behaviour. It means that we signal the
vblank event before it actually happens, but since we're disabling
vblanks there's no guarantee that it will *ever* happen otherwise.
This prevents GL applications which use WaitMSC from hanging
indefinitely.
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/drm_irq.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 741457b..a1f12cb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -932,11 +932,34 @@ EXPORT_SYMBOL(drm_vblank_put);
void drm_vblank_off(struct drm_device *dev, int crtc)
{
+ struct drm_pending_vblank_event *e, *t;
+ struct timeval now;
unsigned long irqflags;
+ unsigned int seq;
spin_lock_irqsave(&dev->vbl_lock, irqflags);
vblank_disable_and_save(dev, crtc);
DRM_WAKEUP(&dev->vbl_queue[crtc]);
+
+ /* Send any queued vblank events, lest the natives grow disquiet */
+ seq = drm_vblank_count_and_time(dev, crtc, &now);
+ list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
+ if (e->pipe != crtc)
+ continue;
+ DRM_DEBUG("Sending premature vblank event on disable: \
+ wanted %d, current %d\n",
+ e->event.sequence, seq);
+
+ e->event.sequence = seq;
+ e->event.tv_sec = now.tv_sec;
+ e->event.tv_usec = now.tv_usec;
+ drm_vblank_put(dev, e->pipe);
+ list_move_tail(&e->base.link, &e->base.file_priv->event_list);
+ wake_up_interruptible(&e->base.file_priv->event_wait);
+ trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
+e->event.sequence);
+ }
+
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
EXPORT_SYMBOL(drm_vblank_off);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: Warn if vblank state has become inconsistent.
From: Christopher James Halse Rogers After emitting all the waiting vblank events no-one should hold a vblank reference. Emit a warning if this is not the case. Signed-off-by: Christopher James Halse Rogers --- drivers/gpu/drm/drm_irq.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index a1f12cb..72407fa 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -960,6 +960,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc) e->event.sequence); } + WARN_ON(atomic_read(&dev->vblank_refcount[crtc]) != 0); spin_unlock_irqrestore(&dev->vbl_lock, irqflags); } EXPORT_SYMBOL(drm_vblank_off); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: Factor-out drm_emit_vblank_event code.
From: Christopher James Halse Rogers
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/drm_irq.c | 39 ---
1 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 72407fa..485714b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -930,6 +930,18 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
}
EXPORT_SYMBOL(drm_vblank_put);
+static void drm_emit_vblank_event (struct drm_pending_vblank_event *e,
+ unsigned int seq, struct timeval *now)
+{
+ e->event.sequence = seq;
+ e->event.tv_sec = now->tv_sec;
+ e->event.tv_usec = now->tv_usec;
+ list_move_tail(&e->base.link, &e->base.file_priv->event_list);
+ wake_up_interruptible(&e->base.file_priv->event_wait);
+ trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
+e->event.sequence);
+}
+
void drm_vblank_off(struct drm_device *dev, int crtc)
{
struct drm_pending_vblank_event *e, *t;
@@ -950,14 +962,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
wanted %d, current %d\n",
e->event.sequence, seq);
- e->event.sequence = seq;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
drm_vblank_put(dev, e->pipe);
- list_move_tail(&e->base.link, &e->base.file_priv->event_list);
- wake_up_interruptible(&e->base.file_priv->event_wait);
- trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
-e->event.sequence);
+ drm_emit_vblank_event(e, seq, &now);
}
WARN_ON(atomic_read(&dev->vblank_refcount[crtc]) != 0);
@@ -1103,18 +1109,11 @@ static int drm_queue_vblank_event(struct drm_device
*dev, int pipe,
vblwait->request.sequence);
e->event.sequence = vblwait->request.sequence;
+ list_add_tail(&e->base.link, &dev->vblank_event_list);
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
- e->event.sequence = seq;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
drm_vblank_put(dev, pipe);
- list_add_tail(&e->base.link, &e->base.file_priv->event_list);
- wake_up_interruptible(&e->base.file_priv->event_wait);
- vblwait->reply.sequence = seq;
- trace_drm_vblank_event_delivered(current->pid, pipe,
-vblwait->request.sequence);
+ drm_emit_vblank_event(e, seq, &now);
} else {
- list_add_tail(&e->base.link, &dev->vblank_event_list);
vblwait->reply.sequence = vblwait->request.sequence;
}
@@ -1248,14 +1247,8 @@ void drm_handle_vblank_events(struct drm_device *dev,
int crtc)
DRM_DEBUG("vblank event on %d, current %d\n",
e->event.sequence, seq);
- e->event.sequence = seq;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
drm_vblank_put(dev, e->pipe);
- list_move_tail(&e->base.link, &e->base.file_priv->event_list);
- wake_up_interruptible(&e->base.file_priv->event_wait);
- trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
-e->event.sequence);
+ drm_emit_vblank_event(e, seq, &now);
}
spin_unlock_irqrestore(&dev->event_lock, flags);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau: Use pci_dma_mapping_error()
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 4bce801..b038de9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -42,7 +42,8 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned long
num_pages,
nvbe->nr_pages = 0;
while (num_pages--) {
- if (dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE) {
+ if (pci_dma_mapping_error(dev->pdev,
+ dma_addrs[nvbe->nr_pages])) {
nvbe->pages[nvbe->nr_pages] =
dma_addrs[nvbe->nr_pages];
nvbe->ttm_alloced[nvbe->nr_pages] = true;
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: Use pci_dma_mapping_error()
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 8a955bb..d96f5ea 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -183,7 +183,7 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned
offset,
for (i = 0; i < pages; i++, p++) {
/* On TTM path, we only use the DMA API if TTM_PAGE_FLAG_DMA32
* is requested. */
- if (dma_addr[i] != DMA_ERROR_CODE) {
+ if (pci_dma_mapping_error(rdev->pdev, dma_addr[i])) {
rdev->gart.ttm_alloced[p] = true;
rdev->gart.pages_addr[p] = dma_addr[i];
} else {
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] New: Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Summary: Hierarchical Z support for R600 Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: pelloux at gmail.com Add Hierarchical Z (HiZ) support for r600g driver. I'm attaching my work-in-progress patchs to this bug report to keep track of comments. This patch adds 3 new env vars : - R600_EARLYZ : controls whether EarlyZ functionnality is used (DB_SHADER_CONTROL register) - R600_HIZ : HiZ enabled/disabled - R600_HIZ_READ_HACK : this one is a quick hack for debugging HiZ data buffer. If set, data will be read from HiZ bo instead of depth buffer bo when calling glReadPixels( ... GL_DEPTH_COMPONENT ...) General notes on HiZ on r600 : (all testing done using : ATI Technologies Inc RV770 [Radeon HD 4850]) * HiZ buffer is made of DWORD entries. Each DWORD represents one tile (4x4 or 8x8 pixels depending DB_HTILE_SURFACE register fields) * HiZ buffer does not need to be manually cleared by the driver * DB_RENDER_CONTROL:RESUMMARIZE_ENABLE bit is not necessary to get it working - but if enabled it slows things down * application performance are roughly the same using R600_EARLYZ or R600_HIZ Know problems : * Hierarchical Stencil has not been tested * HiZ buffer data layout is still unclear. As an example : using 640x640 window and 8x8 tiles. HiZ buffer should contain (640/8)*(640/8) = 6400 entries. When reading it back using the above hack, it contains 6400 entries but spread on the 7680 first dwords of the buffer. Therefore HiZ bo if largely oversized for now (ie = depth buffer size) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #1 from Pierre-Eric 2011-04-26 00:59:16 PDT --- Created an attachment (id=46081) View: https://bugs.freedesktop.org/attachment.cgi?id=46081 Review: https://bugs.freedesktop.org/review?bug=36602&attachment=46081 Hiz bo deletion patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #2 from Pierre-Eric 2011-04-26 00:59:59 PDT --- Created an attachment (id=46082) View: https://bugs.freedesktop.org/attachment.cgi?id=46082 Review: https://bugs.freedesktop.org/review?bug=36602&attachment=46082 HiZ initial patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #3 from Pierre-Eric 2011-04-26 01:01:54 PDT --- Created an attachment (id=46083) View: https://bugs.freedesktop.org/attachment.cgi?id=46083 Review: https://bugs.freedesktop.org/review?bug=36602&attachment=46083 kernel side patch to handle TILE_SURFACE commands (patch built against linux 2.6.38.3) This one is minimum, and is lacking hiz bo size checks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 Riccardo Angelino changed: What|Removed |Added CC||rikyinformation at gmail.com --- Comment #3 from Riccardo Angelino 2011-04-26 09:31:02 --- njin thanks for report. (In reply to comment #1) > Please attach your dmesg output and xorg log. Is this a laptop with hybrid > graphics? Hello Alex not is a laptop but a pc desktop with hybrid graphics. My graphic card is ATI Radeon HD 3450. I attach the xorg log file and the file of my hardware, so you can check. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 --- Comment #4 from Riccardo Angelino 2011-04-26 09:32:03 --- Created an attachment (id=55532) --> (https://bugzilla.kernel.org/attachment.cgi?id=55532) xorg log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 --- Comment #5 from Riccardo Angelino 2011-04-26 09:33:26 --- Created an attachment (id=55542) --> (https://bugzilla.kernel.org/attachment.cgi?id=55542) My hardware components -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33942] WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]()
https://bugzilla.kernel.org/show_bug.cgi?id=33942 Riccardo Angelino changed: What|Removed |Added Attachment #55542|My hardware components |hardware components description|| -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] drm: add overlays as first class KMS objects
> I was planning on adding a new fb ioctl to allow us to create fbs with
> specific surface format types. We could either enumerate all of the
> ones we support (a list which will grow as drivers and devices are
> added) or try to factor out commit bits into a separate surface struct:
>
> struct drm_mode_surface {
> enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
> int depth;
> enum packing; /* some list of packing types? */
> ...
> };
Any reason for not just using the Video4Linux 2 formats here, they've
been enumerating video formats for some time already.
[RFC] drm: add overlays as first class KMS objects
> A lot of older hardware had one overlay that could be sourced to any > crtc, just not simultaneously. The tricky part is the formats and > capabilities: alpha blending, color/chromakey, gamma correction, etc. > Even the current crtc gamma stuff is somewhat lacking in in terms of > what hardware is capable of (PWL vs. LUT, user defined conversion > matrices, gamut remapping, etc.). Rather than re-inventing enough wheels to run a large truck would it not make sense to make hardware sourced overlays Video4Linux objects in their entirity so you can just say "attach V4L object A as overlay B" That would provide format definitions, provide control interfaces for the surface (eg for overlays of cameras such as on some of the Intel embedded and non PC devices), give you an existing well understood API. For some hardware you are going to need this integration anyway so that you can do things like move a GEM object which is currently a DMA target of a capture device (as well as to fence it). For a software surface you could either expose it as a V4L object that is GEM or fb memory backed or at least use the same descriptions so that the kernel has a consistent set of descriptions for formats and we don't have user libraries doing adhoc format translation crap. A lot of capture hardware would map very nicely onto GEM objects I suspect and if you want to merge live video into Wayland it seems a logical path ? Alan
[Bug 36525] Enemy territory freezes system with r600g.
https://bugs.freedesktop.org/show_bug.cgi?id=36525 Michel D?nzer changed: What|Removed |Added Product|DRI |Mesa Version|unspecified |git Component|DRM/Radeon |Drivers/Gallium/r600 CC||fredrik at kde.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36598] [RS880] Slow resume from suspend generates kernel warning
https://bugs.freedesktop.org/show_bug.cgi?id=36598 Alex Deucher changed: What|Removed |Added Summary|[RS880] Slow resume from|[RS880] Slow resume from |suspend generates kernel|suspend generates kernel |oops|warning --- Comment #1 from Alex Deucher 2011-04-26 06:39:28 PDT --- This is not an oops it's just a warning that it took longer than 10 seconds. If it works fine after resume there's nothing to worry about. Is the warning a regression from a previous kernel? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] drm: add overlays as first class KMS objects
On Mon, Apr 25, 2011 at 8:33 PM, Jesse Barnes
wrote:
> On Mon, 25 Apr 2011 20:28:20 -0400
> Alex Deucher wrote:
>
>> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
>> wrote:
>> > On Mon, 25 Apr 2011 16:16:18 -0700
>> > Keith Packard wrote:
>> >
>> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > >> virtuousgeek.org> wrote:
>> >>
>> >> > Overlays are a bit like half-CRTCs. ?They have a location and fb, but
>> >> > don't drive outputs directly. ?Add support for handling them to the core
>> >> > KMS code.
>> >>
>> >> Are overlays/underlays not associated with a specific CRTC? To my mind,
>> >> overlays are another scanout buffer associated with a specific CRTC, so
>> >> you'd create a scanout buffer and attach that to a specific scanout slot
>> >> in a crtc, with the 'default' slot being the usual graphics plane.
>> >
>> > Yes, that matches my understanding as well. ?I've deliberately made the
>> > implementation flexible there though, under the assumption that some
>> > hardware allows a plane to be directed at more than one CRTC (though
>> > probably not simultaneously).
>>
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. ?The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stuff is somewhat lacking in in terms of
>> what hardware is capable of (PWL vs. LUT, user defined conversion
>> matrices, gamut remapping, etc.).
>
> Right, this implementation allows an overlay to be tied to any crtc
> listed in the possible_crtcs mask (matching the other possible_*
> fields), but only one at a time. ?I think that's fairly common.
>
> Agree about formats and capabilities. ?I think enumerating available
> formats is best, perhaps making that a driver specific array if we
> can't agree on a common set.
I would rather have format be common to all hardware, rather than
having a list per hardware. uint32_t would give enough room to add all
formats even if one format is only supported by one hardware only (at
one point in time). Also this would allow to have second dumb way to
allocate scanout buffer in non driver specific way. Maybe we need
another ioctl to query support format somethings like :
struct drm_format_supported {
uint32_t nformats;
uint32_t __user *formats;
};
Userspace supply an array of format and driver overwritte entry that
are not supported with 0, 0 would be a special INVALID format.
> Dealing with color correction could also be driver specific; once
> the client has an overlay id it can use driver specific ioctls to
> get/set specifics.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
Is there that many different way to do color corrections ?
Cheers,
Jerome
[RFC] drm: add overlays as first class KMS objects
> having a list per hardware. uint32_t would give enough room to add all > formats even if one format is only supported by one hardware only (at It would indeed. A point realised by the Amiga designers in 1985 and turned into a standard of sorts with a registry and process and adopted by folks like Apple and Microsoft. See www.fourcc.org. 4CC is already used by the kernel for Video4Linux.
[Bug 36608] New: Corrupt GL rendering
https://bugs.freedesktop.org/show_bug.cgi?id=36608 Summary: Corrupt GL rendering Product: Mesa Version: git Platform: IA64 (Itanium) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: emeric.maschino at gmail.com Created an attachment (id=46090) --> (https://bugs.freedesktop.org/attachment.cgi?id=46090) Screenshot showing corrupt GL rendering in glxgears as an example Hi, I was asked there (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622299#67) to report this bug upstream. GL rendering is currently corrupt on IA-64 with Gallium r300 driver (cf. attached screenshot with running glxgears as an example). Classic driver renders display correctly. Regards, ?meric -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] drm: add overlays as first class KMS objects
On Tue, Apr 26, 2011 at 10:16 AM, Alan Cox wrote: >> having a list per hardware. uint32_t would give enough room to add all >> formats even if one format is only supported by one hardware only (at > > It would indeed. A point realised by the Amiga designers in 1985 and > turned into a standard of sorts with a registry and process and adopted > by folks like Apple and Microsoft. > > See www.fourcc.org. 4CC is already used by the kernel for Video4Linux. > I think 4cc it bit useless with RGB stuff (or maybe i just don't understand 4cc). For instance i think we want uniq different id for RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says rgb and than rely on additional informations for color order or components size. Cheers, Jerome
[RFC] drm: add overlays as first class KMS objects
On Tue, 26 Apr 2011 11:01:30 +0100 Alan Cox wrote: > > A lot of older hardware had one overlay that could be sourced to any > > crtc, just not simultaneously. The tricky part is the formats and > > capabilities: alpha blending, color/chromakey, gamma correction, etc. > > Even the current crtc gamma stuff is somewhat lacking in in terms of > > what hardware is capable of (PWL vs. LUT, user defined conversion > > matrices, gamut remapping, etc.). > > Rather than re-inventing enough wheels to run a large truck would it not > make sense to make hardware sourced overlays Video4Linux objects in their > entirity so you can just say "attach V4L object A as overlay B" > > That would provide format definitions, provide control interfaces for > the surface (eg for overlays of cameras such as on some of the Intel > embedded and non PC devices), give you an existing well understood API. > > For some hardware you are going to need this integration anyway so that > you can do things like move a GEM object which is currently a DMA target > of a capture device (as well as to fence it). > > For a software surface you could either expose it as a V4L object that > is GEM or fb memory backed or at least use the same descriptions so that > the kernel has a consistent set of descriptions for formats and we don't > have user libraries doing adhoc format translation crap. > > A lot of capture hardware would map very nicely onto GEM objects I > suspect and if you want to merge live video into Wayland it seems a > logical path ? Thanks Alan, of course that's a good idea, I'll see about integrating the two. -- Jesse Barnes, Intel Open Source Technology Center
[RFC] drm: add overlays as first class KMS objects
> I think 4cc it bit useless with RGB stuff (or maybe i just don't > understand 4cc). For instance i think we want uniq different id for > RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says > rgb and than rely on additional informations for color order or > components size. Yes - grep "fourcc" include/linux/videodev2.h plus see the docs - I think its sufficient for pretty much all of it we would end up needing except maybe a few texture formats like S3TC (which are of course 4CC codes too) Alan
[RFC] drm: add overlays as first class KMS objects
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote: > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes virtuousgeek.org> wrote: > > > Overlays are a bit like half-CRTCs. They have a location and fb, but > > don't drive outputs directly. Add support for handling them to the core > > KMS code. > > Are overlays/underlays not associated with a specific CRTC? To my mind, > overlays are another scanout buffer associated with a specific CRTC, so > you'd create a scanout buffer and attach that to a specific scanout slot > in a crtc, with the 'default' slot being the usual graphics plane. And what if you don't have a "default" plane as such. For example, OMAP3 has one graphics plane and two video planes, and two output paths. Each of the planes can be assigned to zero or one outputs. To accomodate this, the design should allow for CRTCs without any scanout buffers. Also a glance at DirectFB and OpenWF Display APIs might be helpful. -- Ville Syrj?l? syrjala at sci.fi http://www.sci.fi/~syrjala/
[RFC] drm: add overlays as first class KMS objects
On Tue, 26 Apr 2011 18:20:03 +0300 Ville Syrj?l? wrote: > On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote: > > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > virtuousgeek.org> wrote: > > > > > Overlays are a bit like half-CRTCs. They have a location and fb, but > > > don't drive outputs directly. Add support for handling them to the core > > > KMS code. > > > > Are overlays/underlays not associated with a specific CRTC? To my mind, > > overlays are another scanout buffer associated with a specific CRTC, so > > you'd create a scanout buffer and attach that to a specific scanout slot > > in a crtc, with the 'default' slot being the usual graphics plane. > > And what if you don't have a "default" plane as such. For example, OMAP3 > has one graphics plane and two video planes, and two output paths. Each > of the planes can be assigned to zero or one outputs. To accomodate this, > the design should allow for CRTCs without any scanout buffers. > > Also a glance at DirectFB and OpenWF Display APIs might be helpful. The current drm crtc code ties together a crtc and fb, but it wouldn't be too hard to split it out a little (such that passing a null fb on a mode set wouldn't disable the crtc, or attaching a new scanout surface to a crtc would enable it) to support something like that. -- Jesse Barnes, Intel Open Source Technology Center
[RFC] drm: add overlays as first class KMS objects
> And what if you don't have a "default" plane as such. For example, OMAP3 > has one graphics plane and two video planes, and two output paths. Each > of the planes can be assigned to zero or one outputs. To accomodate this, > the design should allow for CRTCs without any scanout buffers. Some TV type stuff is a bit like that - well there may be a scanout buffer but its on a protected hardware path and no part of the system except certain bits of hardware can touch it from decrypt to output connector. Clearly a scanout buffer isn't the only way to describe what a crtc is outputting and you need a somewhat more flexible handle including one you can acquire somehow to represent other objects like capture buffers, protected planes and live video merges. Alan
[PATCH] drm/radeon/kms: add missing safe regs for 6xx/7xx
needed for HiS in mesa. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/reg_srcs/r600 |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/r600 b/drivers/gpu/drm/radeon/reg_srcs/r600 index af0da4a..92f1900 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/r600 +++ b/drivers/gpu/drm/radeon/reg_srcs/r600 @@ -708,6 +708,7 @@ r600 0x9400 0x00028D0C DB_RENDER_CONTROL 0x00028D10 DB_RENDER_OVERRIDE 0x0002880C DB_SHADER_CONTROL +0x00028D28 DB_SRESULTS_COMPARE_STATE0 0x00028D2C DB_SRESULTS_COMPARE_STATE1 0x00028430 DB_STENCILREFMASK 0x00028434 DB_STENCILREFMASK_BF -- 1.7.1.1
[PATCH] drm/radeon/kms: add info query for tile pipes
needed by mesa for htile setup.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 13 +
include/drm/radeon_drm.h|1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index bf7d4c0..871df03 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -221,6 +221,19 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_NUM_TILE_PIPES:
+ if (rdev->family >= CHIP_CAYMAN)
+ value = rdev->config.cayman.max_tile_pipes;
+ else if (rdev->family >= CHIP_CEDAR)
+ value = rdev->config.evergreen.max_tile_pipes;
+ else if (rdev->family >= CHIP_RV770)
+ value = rdev->config.rv770.max_tile_pipes;
+ else if (rdev->family >= CHIP_R600)
+ value = rdev->config.r600.max_tile_pipes;
+ else {
+ return -EINVAL;
+ }
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 3bce1a4..7aa5ddd 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -909,6 +909,7 @@ struct drm_radeon_cs {
#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
#define RADEON_INFO_NUM_BACKENDS 0x0a /* DB/backends for r600+ - need
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
struct drm_radeon_info {
uint32_trequest;
--
1.7.1.1
[Bug 36611] New: [wine] The Witcher: Crash in u_vbuf_mgr_draw_begin
https://bugs.freedesktop.org/show_bug.cgi?id=36611 Summary: [wine] The Witcher: Crash in u_vbuf_mgr_draw_begin Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se Created an attachment (id=46094) --> (https://bugs.freedesktop.org/attachment.cgi?id=46094) Backtrace The game The Witcher (running in Wine) crashes shortly after start: u_vbuf_mgr_draw_begin+0x198(mgrb=0x7c5937c0, info=0x1c6ec5c, buffers_updated="?`?d|", uploader_flushed="") [/home/sa/Programming/gfx/mesa/mesa/src/gallium/auxiliary/util/u_vbuf_mgr.c:549] in r300_dri.so (0x01c6e9f4) This does not happen in 7.10. Bisecting leads to this commit: c95bc1224a4b20b9470ddcb37b5f78975991073b is the first bad commit commit c95bc1224a4b20b9470ddcb37b5f78975991073b Author: Marek Ol??k Date: Mon Feb 7 02:00:44 2011 +0100 r300g: use the new vertex buffer manager :04 04 4be08dc19f4fa4e1de6b1b259c6bd481b2fc33e5 28f8c721e519137890b5082fdff66671dbcfacb0 Msrc I'm attaching a backtrace, but I'm not sure how helpful it is, as getting it from Wine was quite tricky. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915 completely unusable in 2.6.38.x
* Melchior FRANZ -- Tuesday 26 April 2011:
> [https://bugzilla.kernel.org/show_bug.cgi?id=31522]
I've replied to this error message, but here again for this audience:
The commit that broke all 2.6.38.* releases for my machine is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba3820ade317ee36e496b9b40d2ec3987dd4aef0
(Takashi Iwai: "drm/i915: Revive combination mode for backlight
control").
In 'is_backlight_combination_mode()' INTEL_INFO(dev)->gen
equals 4, and the function returns 0x4000 in "combination mode".
In 'intel_panel_get_backlight()' this happens:
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK; // val = 0x0b4a
if (IS_PINEVIEW(dev)) // false
val >>= 1;
if (is_backlight_combination_mode(dev)){
u8 lbpc;
val &= ~1;// val = 0x0b4a
pci_read_config_byte(dev->pdev, PCI_LBPC, &lbpc); // lbpc = 0
val *= lbpc; // val = 0
}
The backlight remains off and does also not react to the "brighter" key
event.
Reverting the patch fixes my system, obviously.
m.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #4 from Alex Deucher 2011-04-26 11:53:25 PDT --- Thanks for starting on this. I've provided an overview of of how HiZ and HiS work on 6xx+ hw and some relevant drm patches here: http://people.freedesktop.org/~agd5f/htile/ ping me on irc (agd5f) if you have any questions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35935] since 2.6.38.1, screen become garbled after some times (RV770)
https://bugs.freedesktop.org/show_bug.cgi?id=35935 --- Comment #5 from Mjules 2011-04-26 14:20:30 PDT --- The result of the bisection is : ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 is the first bad commit commit ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 Author: Stanislav Kinsbursky Date: Thu Mar 17 18:54:23 2011 +0300 RPC: killing RPC tasks races fixed commit 8e26de238fd794c8ea56a5c98bf67c40cfeb051d upstream. RPC task RPC_TASK_QUEUED bit is set must be checked before trying to wake up task rpc_killall_tasks() because task->tk_waitqueue can not be set (equal to NULL). Also, as Trond Myklebust mentioned, such approach (instead of checking tk_waitqueue to NULL) allows us to "optimise away the call to rpc_wake_up_queued_task() altogether for those tasks that aren't queued". Here is an example of dereferencing of tk_waitqueue equal to NULL: CPU 0 CPU 1CPU 2 --- nfs4_run_open_task rpc_run_task rpc_execute rpc_set_active rpc_make_runnable (waiting) rpc_async_schedule nfs4_open_prepare nfs_wait_on_sequence nfs_umount_begin rpc_killall_tasks rpc_wake_up_task rpc_wake_up_queued_task spin_lock(tk_waitqueue == NULL) BUG() rpc_sleep_on spin_lock(&q->lock) __rpc_sleep_on task->tk_waitqueue = q Signed-off-by: Stanislav Kinsbursky Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman :04 04 91b88f0611c9ff1cf2691d9d65ec13c652a554ac e23b6d459a8bef93de6ea4821754e2f51e3ad32f Mnet which seems completely bogus to me (I don't use nfs). BTW, the bug is still present with 2.6.38.3 and seems more frequent with it. Another detail is it occurs only one time during a session. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36554] Amnesia game causes black screen or kernel locks
https://bugs.freedesktop.org/show_bug.cgi?id=36554 --- Comment #3 from Hicham HAOUARI 2011-04-26 15:49:17 PDT --- (In reply to comment #2) > This is probably hardware specific, I haven't had any problems with Amnesia on > my RV570. What kernel version do you have ? The game runs fine for me on Fedora 14, while on Fedora 15, I used to have Scott's issues. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #1 from Ernst Sj?strand 2011-04-26 21:35:31 PDT --- I was in a hurry but I thought it was better with a quick bugreport than no report at all. :-) This was with Ubuntu Natty's 2.6.38 kernel + xorg-edgers 20110422. Can't remember exactly what I did, some window management operation. Hasn't happened since. Attached to compiz with gdb from the console and got the backtrace when this happened. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
