[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.
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 = 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.
[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
> 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
[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
[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.
[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 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(>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.
[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
[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
[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.
[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
> 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 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.
[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
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
[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
[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 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
[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
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
[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.
[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.
[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 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=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 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=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] 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.
multiple framebuffer drm maps
In commit 41c2e75e60200a860a74b7c84a6375c105e7437f "drm: Make drm_local_map use a resource_size_t offset" [1] the support for multiple _DRM_FRAMEBUFFER maps per device was taken away. This change made the savage drivers upset, since these cards have several apertures (the layout is different between card families) for which the kernel drm driver sets up maps. And these maps are now mixed up into one broken one. The drivers (drm, ddx, mesa) for instance expects a framebuffer map and a tiled aperture map, and the broken maps show up as rendering corruption [2] and allocation failures. I have tried to come up with userland workarounds but it seems impossible since the kernel will only return the handle to a broken map and there is no way to remap it correctly. Would it be possible to reintroduce this support? One solution could be a new flag _DRM_IGNORE_FB_OFFSET that can be used by those drivers that need it, or the other way around, a _DRM_CHECK_FB_OFFSET to be added by the savage drivers and others in the same situation. I can of course try to write a patch if people think this is a good idea. Best regards, Tormod [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=41c2e75e60200a860a74b7c84a6375c105e7437f [2] https://bugs.freedesktop.org/show_bug.cgi?id=32511
[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 pell...@gmail.com 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=36602attachment=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 pell...@gmail.com 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=36602attachment=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 pell...@gmail.com 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=36602attachment=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 rikyinformat...@gmail.com changed: What|Removed |Added CC||rikyinformat...@gmail.com --- Comment #3 from Riccardo Angelino rikyinformat...@gmail.com 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 rikyinformat...@gmail.com 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 rikyinformat...@gmail.com 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 rikyinformat...@gmail.com 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 mic...@daenzer.net 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 ag...@yahoo.com 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 ag...@yahoo.com 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 jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
jbar...@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
___
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 a...@lxorguk.ukuu.org.uk 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 a...@lxorguk.ukuu.org.uk 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 jbar...@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ä 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ä syrj...@sci.fi 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 jbar...@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 ___ 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 alexdeuc...@gmail.com --- 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 alexdeuc...@gmail.com
---
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 mar...@gmail.com 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 ag...@yahoo.com 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 mjulie...@gmail.com 2011-04-26 14:20:30 PDT --- The result of the bisection is : ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 is the first bad commit commit ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 Author: Stanislav Kinsbursky skinsbur...@parallels.com 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 skinsbur...@openvz.org Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com Signed-off-by: Greg Kroah-Hartman gre...@suse.de :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 hicham.haou...@gmail.com 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 ern...@gmail.com 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 sh...@oconnell.cc 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
