[Bug 23620] New: [i915 i965 bisected] 3 glean cases and 2 OGLC cases impacted
http://bugs.freedesktop.org/show_bug.cgi?id=23620 Summary: [i915 i965 bisected] 3 glean cases and 2 OGLC cases impacted Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: major Priority: high Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: shuang...@intel.com System Environment: -- Arch i386 Platform G45 945GM Libdrm: (master)73b59c894380995a2889b98e79acadd2da0bb237 Mesa: (master)241c3a1d8001fc5a30e2af4b4636b48e6f99690a Xserver: (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2 Xf86_video_intel: (master)7c48c21b22bf5862c5a35bda1635753cc5a7197c Bug detailed description: - This issue happens on both i965 and i915 platforms. The following test cases have been impacted glean/logicOp PASS-FAIL on both G45 and 945GM oglc/depth-tex.c PASS-FAIL on both G45 and 945GM glean/coloredTexPerf2 PASS-NSPT on G45, which is due to exactRGBA failed glean/coloredLitPerf2 PASS-NSPT on G45, which is due to exactRGBA failed oglc/volume-tex.c FAIL-TIMEOUT_with_fail on both G45 and 945GM, may also be related to this. This is caused by following commit: commit 00413d87426f14df47d90ba3c995e1889e9f88ca Author: Eric Anholt e...@anholt.net Date: Fri Aug 28 15:01:56 2009 -0700 i965: Use VBOs in the VBO module on 965, now that we have ARB_map_buffer_range. This looks like it's a small win on blender. Reproduce steps: 1.xinit 2. run glean/oglc case -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? The hw does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? /Thomas That said, if someone achieves a generic ioctl that can do this, I have nothing against it. It's just that it seems to be a lot of work for little benefit (IMO). Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23621] New: Draw on Front buffer doesn't work.
http://bugs.freedesktop.org/show_bug.cgi?id=23621 Summary: Draw on Front buffer doesn't work. Product: Mesa Version: 7.5 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: pierre.la...@scilab.org Created an attachment (id=29060) -- (http://bugs.freedesktop.org/attachment.cgi?id=29060) c test file On Linux 2.6.29.6-217.2.16.fc11.i686.PAE i686 i386 GNU/Linux With : OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20090114 x86/MMX/SSE2 OpenGL version string: 2.1 Mesa 7.5-devel OpenGL shading language version string: 1.20 And lsmod | grep i915 i915 147340 2 drm 166512 2 i915 i2c_algo_bit4804 1 i915 i2c_core 18016 4 i2c_i801,i915,drm,i2c_algo_bit video 17344 1 i915 Using glDrawBuffer(GL_FRONT) with JOGl or with C++/OpenGl result to a drawing on the upper-left part of the screen instead of the GL window. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23621] Draw on Front buffer doesn't work.
http://bugs.freedesktop.org/show_bug.cgi?id=23621 --- Comment #1 from Pierre LANDO pierre.la...@scilab.org 2009-09-01 02:27:01 PST --- Created an attachment (id=29061) -- (http://bugs.freedesktop.org/attachment.cgi?id=29061) screenshot of a C test program -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23621] Draw on Front buffer doesn't work.
http://bugs.freedesktop.org/show_bug.cgi?id=23621 --- Comment #2 from Pierre LANDO pierre.la...@scilab.org 2009-09-01 02:29:27 PST --- Created an attachment (id=29062) -- (http://bugs.freedesktop.org/attachment.cgi?id=29062) screenshot of a scilab witch use JOGL AWTcanvas. When Scilab use AWT GLCanvas, the zoom rectangle is draw out of the window. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23621] Draw on Front buffer doesn't work.
http://bugs.freedesktop.org/show_bug.cgi?id=23621 --- Comment #3 from Pierre LANDO pierre.la...@scilab.org 2009-09-01 02:31:21 PST --- Rem : when scilab use SWIG GLJPanel no bugs append, but on Intel Graphics, GLJPanel don't work must of the time, it's why we prefer to use AWT canvas. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? The hw does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? I'm coming to this late, but if the only difference between hw-specific and hw-independent interfaces is which formats are supported, that surely shouldn't be too hard to abstract? Just have an enum which gets expanded with new format names and query for supported formats in the API. Keith -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/9/1 Keith Whitwell kei...@vmware.com: On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? The hw does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? I'm coming to this late, but if the only difference between hw-specific and hw-independent interfaces is which formats are supported, that surely shouldn't be too hard to abstract? Just have an enum which gets expanded with new format names and query for supported formats in the API. As I said, if my hw overlay only does YUY2 and I want to expose YV12/I420 (because that's what everyone wants), I get to do the conversion myself. Now in the old case I could do it in the driver, but now you can either: - remove it and players stop using the overlay altogether (because few players will convert YV12 to YUY2 themselves) or - do a conversion layer between the formats which gets annoying fast So in the end I will still write a card-specific ioctl. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, Sep 01, 2009 at 12:10:20PM +0200, Stephane Marchesin wrote: As I said, if my hw overlay only does YUY2 and I want to expose YV12/I420 (because that's what everyone wants), I get to do the conversion myself. Now in the old case I could do it in the driver, but now you can either: - remove it and players stop using the overlay altogether (because few players will convert YV12 to YUY2 themselves) What kind of crappy players are you using? -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 --- Comment #1 from Krzysztof Sobiecki sob...@wp.pl 2009-09-01 06:37:11 PST --- Created an attachment (id=29069) -- (http://bugs.freedesktop.org/attachment.cgi?id=29069) Output of RADEON_DEBUG=ioctl with fbotexture -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 Krzysztof Sobiecki sob...@wp.pl changed: What|Removed |Added OS/Version|All |Linux (All) Platform|Other |x86-64 (AMD64) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 --- Comment #3 from Krzysztof Sobiecki sob...@wp.pl 2009-09-01 06:40:10 PST --- Created an attachment (id=29071) -- (http://bugs.freedesktop.org/attachment.cgi?id=29071) Output of RADEON_DEBUG=ioctl with progs/samples/stencil -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 --- Comment #4 from Krzysztof Sobiecki sob...@wp.pl 2009-09-01 06:40:39 PST --- Created an attachment (id=29072) -- (http://bugs.freedesktop.org/attachment.cgi?id=29072) Output of RADEON_DEBUG=all with progs/samples/stencil -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 --- Comment #2 from Krzysztof Sobiecki sob...@wp.pl 2009-09-01 06:38:36 PST --- Created an attachment (id=29070) -- (http://bugs.freedesktop.org/attachment.cgi?id=29070) Output of RADEON_DEBUG=all with fbotexture -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] New: On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 Summary: On 64bit kernel 32bit OpenGL application doesn't work Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: sob...@wp.pl Created an attachment (id=29068) -- (http://bugs.freedesktop.org/attachment.cgi?id=29068) Output of 32bit glxinfo While running 64bit kernel with enabled Radeon KMS(patched to even enable compat ioctls like michel wrote: https://bugs.freedesktop.org/show_bug.cgi?id=22271#c5 ) I'm unable tu run any 32bit OpenGL program. All I got is drmRadeonCmdBuffer: -14 ./fbo_firecube Allocating 512 x 512 radeon RBO (pitch 512) Depth renderbuffer size = 16 bits drmRadeonCmdBuffer: -14 Kernel:adda766193ea1cf3137484a9521972d080d0b7af Mesa:836a9f0ae6e03d2f92dc024703015c25a5b3c353 If needed I'm willing to provide drm debug=1 log. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Stephane Marchesin skrev: 2009/9/1 Keith Whitwell kei...@vmware.com: On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? The hw does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? I'm coming to this late, but if the only difference between hw-specific and hw-independent interfaces is which formats are supported, that surely shouldn't be too hard to abstract? Just have an enum which gets expanded with new format names and query for supported formats in the API. As I said, if my hw overlay only does YUY2 and I want to expose YV12/I420 (because that's what everyone wants), I get to do the conversion myself. Now in the old case I could do it in the driver, but now you can either: - remove it and players stop using the overlay altogether (because few players will convert YV12 to YUY2 themselves) or - do a conversion layer between the formats which gets annoying fast So in the end I will still write a card-specific ioctl. But what stops you from, following Keith's suggestion, exposing _any_ awkward format in a generic ioctl and do format conversion in user-space? The actual struct describing the format will be format-specific, and that way we neither get too restrictive nor too generic? /Thomas -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/9/1 Thomas Hellström tho...@shipmail.org: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? The hw does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? I'm failing to see why we need an overlay ioctl at all. You end up pulling a relatively large amount of state setup into the drm. Why not treat the overlay like EXA or textured video or 3D? The overlay regs are pipelined on most chips so you can program them from command buffers. Just convert the overlay code in the ddx to use gem/ttm and build an appropriate command buffer or in the case of gallium add overlay support in the device specific code and use gem/ttm, etc.. You could even use it to support GL overlays. Alex /Thomas That said, if someone achieves a generic ioctl that can do this, I have nothing against it. It's just that it seems to be a lot of work for little benefit (IMO). Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13683] Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
http://bugzilla.kernel.org/show_bug.cgi?id=13683 Jan Kreuzer kontrolla...@gmx.de changed: What|Removed |Added Kernel Version|2.6.31-rc7-git1 |2.6.31-rc8 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23621] Draw on Front buffer doesn't work.
http://bugs.freedesktop.org/show_bug.cgi?id=23621 Chris Wilson ch...@chris-wilson.co.uk changed: What|Removed |Added Attachment #29060|text/x-csrc |text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23621] Draw on Front buffer doesn't work.
http://bugs.freedesktop.org/show_bug.cgi?id=23621 Eric Anholt e...@anholt.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #4 from Eric Anholt e...@anholt.net 2009-09-01 09:04:52 PST --- The SwapBuffers swaps the back on top of the frontbuffer rendering you did. Remove it, and your demo app works. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23474] xrandr doesn't pick up on 1600x1200 modeline
http://bugs.freedesktop.org/show_bug.cgi?id=23474 --- Comment #2 from Alex Deucher ag...@yahoo.com 2009-09-01 09:27:46 PST --- The edid appears to have the 1600x1200 mode: (II) RADEON(0): Modeline 1600x1200x0.0 202.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (93.8 kHz) You should be able to select it using xrandr or by setting it as your preferred mode in your xorg.cong. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22964] double free for r600 context
http://bugs.freedesktop.org/show_bug.cgi?id=22964 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23037] R600 render can cause recrusive call to rcommonFlushCmdBuf if using large VBO object
http://bugs.freedesktop.org/show_bug.cgi?id=23037 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Alex Deucher ag...@yahoo.com 2009-09-01 09:34:53 PST --- This should be fixed. please reopen if it's still a problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23474] xrandr doesn't pick up on 1600x1200 modeline
http://bugs.freedesktop.org/show_bug.cgi?id=23474 --- Comment #3 from Michael de Lang kingo...@gmail.com 2009-09-01 10:16:38 PST --- But that's the problem, I can't select it in xrandr unless I add the mode first. Haven't tried the preferred mode though. Will do that. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23626] On 64bit kernel 32bit OpenGL application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=23626 --- Comment #5 from Krzysztof A. Sobiecki sob...@wp.pl 2009-09-01 10:46:08 PST --- In dmesg I have this: [21491.327145] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! [21493.161548] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! [21494.806706] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! [21496.105809] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! [21497.345617] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote: I'm failing to see why we need an overlay ioctl at all. You end up pulling a relatively large amount of state setup into the drm. Why not treat the overlay like EXA or textured video or 3D? The overlay regs are pipelined on most chips so you can program them from command buffers. Just convert the overlay code in the ddx to use gem/ttm and build an appropriate command buffer or in the case of gallium add overlay support in the device specific code and use gem/ttm, etc.. You could even use it to support GL overlays. Actually that seems to be the original idea, at least there was already some infrastructure in the driver to support this path. The problem is that at least on intel, the overlay hw is _very_ fragile and you can easily hang the complete chip. To prevent this a delicate dance is needed, carefully sync with the crtc output state. So at least on intel, some overlay support on the kernel side is needed to at least prevent race conditions that may hang the chip. Alex Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: 079 365 57 48 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Mon, Aug 31, 2009 at 02:58:15PM +0200, Thomas Hellström wrote: ... Is this some new (embedded) hw support your working on (that supports gallium), Thomas? Or why do you think gallium needs overlay support? I must stress this is not Gallium. It's the Xorg state-tracker that uses Gallium for acceleration and KMS for modesetting. We want to leverage that to a usable state for an application where we probably can't drop previous (overlay) capabilities. Textured Xv adaptors of course goes through Gallium, Overlay needs to go through KMS. That's what I've ment, I've just phrased it badly. The other possible use I can see is for embedded devices where power is a big concern, but that's nothing we're involved in ATM. I do think, however, that overlays are going to live on for a while in those devices. IMHO we need a video pipe object in gallium anyway to support all the special power efficient hw in embedded devices. In combination with a gallium video state tracker for a modern api this should give us awesome video on embedded devices /wishful dreaming Given the fact that Xv and various virtual device overlay support implementations exist, I assume there *must* be a way to do this generically. Perhaps not in the interest of sharing kernel code, but in the interest of a single user-space interface and a single user-space implementation supporting multiple hardware drivers. I've looked at this before, and you basically end up adding something similar to the Xv API in the kernel (for handling pixel formats, size pitch limitations, vsyncing, ...). I'm not sure it's worth it, especially since overlays are doomed. Of course overlays are faster than textured/blitter video so it's worth implementing, but I'd keep this as a device-specific ioctl. Stephane The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Nope, Xv has one fixed format with stride == line length. Atm, the intel driver unconditionally copies the planes from a userspace buffer into a bo (with correct stride, rotation applied, ...). That's also why I think Xv is not really worth too much trouble because it hands memory pointers and not bo's to the driver. (Which btw results in some _very_ ugly hacks to achieve zero-copy XvMC by assuming that the pointer handed in by the client-side libXvMC is just a GART offset ... This obviously doesn't work with bo relocating/kms) b) one fixed format. If it does not fit, just copy the stuff in the right format into a new bo. This is what the intel Xv driver does at the moment. I don't think this belongs into the kernel. Agreed. It's not a problem to implement this in a generic user-space driver. As I've already said I think the way forward is gallium-video state tracker (and not Xv). This way we can ensure that the draw module (via shaders/software) or the hw render the frames with the right constrains directly into bo's. This way we can omit the atm inevitable copy that the Xv api forces upon drivers. This should also be usable for embedded devices with low-power overlay and dedicated video pipelines. One small thing to keep in mind: To make this video state tracker on gallium thing work we probably need to extend the DRI2 proto such that X can work as an arbiter for the overlay. ... btw: I don't think we can sketch out a common interface before we have a second implementation to go pattern hunting. OK. We're probably some time away on this. Fine. I'll just push this then as a device ioctl to bring usable video on 8xx to kms. Thanks, /Thomas Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: 079 365 57 48 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i965 support broken
Added CC. Hi, I have just updated graphics stack on my i965 based system. Now, I notice that in many 3d applications, (I test few games) screen flashes and I see for a moment few garbage triangles. ppracer flashes its main screen in above way, suspetuxkart shows that issue, after few minutes of playing, etc... a quick bisect revealed unfortunately that last *good* commit is 20d9204fbd71aebf870834b612579419d2c278b5 radeon: fix max indx/vertex emission due to state checker After that, 3d output went completely black, and I didn't yet traced it back when it started working again, the way it does in head. commit d6b8664e3cd37c081cb1dd3d6cd5ffdac1813dac swrast: minor code consolidation still shows black output master commit on my system is c4a3e036ed1c755a291018251c4f55c45ac17079 could you also look at https://bugs.freedesktop.org/show_bug.cgi?id=23254 pretty much even now, if I revert commit 0f328c90dbc893e15005f2ab441d309c1c176245 i965: Fall back or appropriately adjust offsets of drawing to tiled regions. Then and only then, suspendresume works just fine with compiz running, otherwise, compiz is broken on resume Best regards, Maxim Levitsky -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23585] Textures in certain applications are only 1/2 visible on the diagonal in direct mode on r600
http://bugs.freedesktop.org/show_bug.cgi?id=23585 John Bridgman john.bridg...@amd.com changed: What|Removed |Added CC||john.bridg...@amd.com --- Comment #3 from John Bridgman john.bridg...@amd.com 2009-09-01 15:25:33 PST --- Not sure if it's the same problem, but mesa/progs/redbook/texsub also shows the same behaviour (works with indirect or software rendering, doesn't work with direct rendering) and may be easier to debug. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Use RADEON_GPU_PAGE_SIZE instead of hardcoded 4096
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Matt Turner matts...@gmail.com
---
drivers/gpu/drm/radeon/r100.c |2 +-
drivers/gpu/drm/radeon/r300.c |4 ++--
drivers/gpu/drm/radeon/r600.c |4 ++--
drivers/gpu/drm/radeon/radeon.h |2 ++
drivers/gpu/drm/radeon/radeon_benchmark.c |4 ++--
drivers/gpu/drm/radeon/radeon_display.c |4 ++--
drivers/gpu/drm/radeon/radeon_gart.c | 20 ++--
drivers/gpu/drm/radeon/radeon_test.c |6 +++---
drivers/gpu/drm/radeon/rv770.c|4 ++--
9 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 639d5b2..96f3046 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -364,7 +364,7 @@ int r100_wb_init(struct radeon_device *rdev)
int r;
if (rdev-wb.wb_obj == NULL) {
- r = radeon_object_create(rdev, NULL, 4096,
+ r = radeon_object_create(rdev, NULL, RADEON_GPU_PAGE_SIZE,
true,
RADEON_GEM_DOMAIN_GTT,
false, rdev-wb.wb_obj);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 482d6b2..b91243b 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -113,7 +113,7 @@ int rv370_pcie_gart_enable(struct radeon_device *rdev)
tmp = RADEON_PCIE_TX_GART_UNMAPPED_ACCESS_DISCARD;
WREG32_PCIE(RADEON_PCIE_TX_GART_CNTL, tmp);
WREG32_PCIE(RADEON_PCIE_TX_GART_START_LO, rdev-mc.gtt_location);
- tmp = rdev-mc.gtt_location + rdev-mc.gtt_size - 4096;
+ tmp = rdev-mc.gtt_location + rdev-mc.gtt_size - RADEON_GPU_PAGE_SIZE;
WREG32_PCIE(RADEON_PCIE_TX_GART_END_LO, tmp);
WREG32_PCIE(RADEON_PCIE_TX_GART_START_HI, 0);
WREG32_PCIE(RADEON_PCIE_TX_GART_END_HI, 0);
@@ -917,7 +917,7 @@ static inline void r300_cs_track_clear(struct r300_cs_track
*track)
unsigned i;
track-num_cb = 4;
- track-maxy = 4096;
+ track-maxy = RADEON_GPU_PAGE_SIZE;
for (i = 0; i track-num_cb; i++) {
track-cb[i].robj = NULL;
track-cb[i].pitch = 8192;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 538cd90..4069fa0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -54,10 +54,10 @@ int r600_mc_init(struct radeon_device *rdev)
* discard unmapped mc request
*/
/* FIXME: disable out of gart access */
- tmp = rdev-mc.gtt_location / 4096;
+ tmp = rdev-mc.gtt_location / RADEON_GPU_PAGE_SIZE;
tmp = REG_SET(R600_LOGICAL_PAGE_NUMBER, tmp);
WREG32(R600_MC_VM_SYSTEM_APERTURE_LOW_ADDR, tmp);
- tmp = (rdev-mc.gtt_location + rdev-mc.gtt_size) / 4096;
+ tmp = (rdev-mc.gtt_location + rdev-mc.gtt_size) /
RADEON_GPU_PAGE_SIZE;
tmp = REG_SET(R600_LOGICAL_PAGE_NUMBER, tmp);
WREG32(R600_MC_VM_SYSTEM_APERTURE_HIGH_ADDR, tmp);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1041a7c..83542aa 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -301,6 +301,8 @@ union radeon_gart_table {
struct radeon_gart_table_vram vram;
};
+#define RADEON_GPU_PAGE_SIZE 4096
+
struct radeon_gart {
dma_addr_t table_addr;
unsignednum_gpu_pages;
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 2e938f7..10bd50a 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -63,7 +63,7 @@ void radeon_benchmark_move(struct radeon_device *rdev,
unsigned bsize,
if (r) {
goto out_cleanup;
}
- r = radeon_copy_dma(rdev, saddr, daddr, size / 4096, fence);
+ r = radeon_copy_dma(rdev, saddr, daddr, size /
RADEON_GPU_PAGE_SIZE, fence);
if (r) {
goto out_cleanup;
}
@@ -88,7 +88,7 @@ void radeon_benchmark_move(struct radeon_device *rdev,
unsigned bsize,
if (r) {
goto out_cleanup;
}
- r = radeon_copy_blit(rdev, saddr, daddr, size / 4096, fence);
+ r = radeon_copy_blit(rdev, saddr, daddr, size /
RADEON_GPU_PAGE_SIZE, fence);
if (r) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index af03560..4e91d25 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -633,8 +633,8 @@ int radeon_modeset_init(struct radeon_device *rdev)
[PATCH] libdrm_intel: add new pci ids
Make sure we don't need to count fence also on new chips. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- libdrm/intel/intel_chipset.h |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/libdrm/intel/intel_chipset.h b/libdrm/intel/intel_chipset.h index 0b3af02..6b90095 100644 --- a/libdrm/intel/intel_chipset.h +++ b/libdrm/intel/intel_chipset.h @@ -48,7 +48,9 @@ (dev)-pci_device == 0x2A42 || \ (dev)-pci_device == 0x2E02 || \ (dev)-pci_device == 0x2E12 || \ - (dev)-pci_device == 0x2E22) + (dev)-pci_device == 0x2E22 || \ + (dev)-pci_device == 0x0042 || \ + (dev)-pci_device == 0x0046) #define IS_I965GM(dev) ((dev)-pci_device == 0x2A02) -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Use RADEON_GPU_PAGE_SIZE instead of hardcoded 4096
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Matt Turner matts...@gmail.com
---
drivers/gpu/drm/radeon/r100.c |2 +-
drivers/gpu/drm/radeon/r300.c |4 ++--
drivers/gpu/drm/radeon/r600.c |4 ++--
drivers/gpu/drm/radeon/radeon.h |2 ++
drivers/gpu/drm/radeon/radeon_benchmark.c |4 ++--
drivers/gpu/drm/radeon/radeon_gart.c | 20 ++--
drivers/gpu/drm/radeon/radeon_test.c |6 +++---
drivers/gpu/drm/radeon/rv770.c|4 ++--
8 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 639d5b2..96f3046 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -364,7 +364,7 @@ int r100_wb_init(struct radeon_device *rdev)
int r;
if (rdev-wb.wb_obj == NULL) {
- r = radeon_object_create(rdev, NULL, 4096,
+ r = radeon_object_create(rdev, NULL, RADEON_GPU_PAGE_SIZE,
true,
RADEON_GEM_DOMAIN_GTT,
false, rdev-wb.wb_obj);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 482d6b2..b91243b 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -113,7 +113,7 @@ int rv370_pcie_gart_enable(struct radeon_device *rdev)
tmp = RADEON_PCIE_TX_GART_UNMAPPED_ACCESS_DISCARD;
WREG32_PCIE(RADEON_PCIE_TX_GART_CNTL, tmp);
WREG32_PCIE(RADEON_PCIE_TX_GART_START_LO, rdev-mc.gtt_location);
- tmp = rdev-mc.gtt_location + rdev-mc.gtt_size - 4096;
+ tmp = rdev-mc.gtt_location + rdev-mc.gtt_size - RADEON_GPU_PAGE_SIZE;
WREG32_PCIE(RADEON_PCIE_TX_GART_END_LO, tmp);
WREG32_PCIE(RADEON_PCIE_TX_GART_START_HI, 0);
WREG32_PCIE(RADEON_PCIE_TX_GART_END_HI, 0);
@@ -917,7 +917,7 @@ static inline void r300_cs_track_clear(struct r300_cs_track
*track)
unsigned i;
track-num_cb = 4;
- track-maxy = 4096;
+ track-maxy = RADEON_GPU_PAGE_SIZE;
for (i = 0; i track-num_cb; i++) {
track-cb[i].robj = NULL;
track-cb[i].pitch = 8192;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 538cd90..4069fa0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -54,10 +54,10 @@ int r600_mc_init(struct radeon_device *rdev)
* discard unmapped mc request
*/
/* FIXME: disable out of gart access */
- tmp = rdev-mc.gtt_location / 4096;
+ tmp = rdev-mc.gtt_location / RADEON_GPU_PAGE_SIZE;
tmp = REG_SET(R600_LOGICAL_PAGE_NUMBER, tmp);
WREG32(R600_MC_VM_SYSTEM_APERTURE_LOW_ADDR, tmp);
- tmp = (rdev-mc.gtt_location + rdev-mc.gtt_size) / 4096;
+ tmp = (rdev-mc.gtt_location + rdev-mc.gtt_size) /
RADEON_GPU_PAGE_SIZE;
tmp = REG_SET(R600_LOGICAL_PAGE_NUMBER, tmp);
WREG32(R600_MC_VM_SYSTEM_APERTURE_HIGH_ADDR, tmp);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1041a7c..83542aa 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -301,6 +301,8 @@ union radeon_gart_table {
struct radeon_gart_table_vram vram;
};
+#define RADEON_GPU_PAGE_SIZE 4096
+
struct radeon_gart {
dma_addr_t table_addr;
unsignednum_gpu_pages;
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 2e938f7..10bd50a 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -63,7 +63,7 @@ void radeon_benchmark_move(struct radeon_device *rdev,
unsigned bsize,
if (r) {
goto out_cleanup;
}
- r = radeon_copy_dma(rdev, saddr, daddr, size / 4096, fence);
+ r = radeon_copy_dma(rdev, saddr, daddr, size /
RADEON_GPU_PAGE_SIZE, fence);
if (r) {
goto out_cleanup;
}
@@ -88,7 +88,7 @@ void radeon_benchmark_move(struct radeon_device *rdev,
unsigned bsize,
if (r) {
goto out_cleanup;
}
- r = radeon_copy_blit(rdev, saddr, daddr, size / 4096, fence);
+ r = radeon_copy_blit(rdev, saddr, daddr, size /
RADEON_GPU_PAGE_SIZE, fence);
if (r) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2977539..bc54501 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -133,15 +133,15 @@ void radeon_gart_unbind(struct radeon_device *rdev,
unsigned offset,
WARN(1, trying to unbind memory to unitialized GART !\n);
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On 09/01/2009 02:06 PM, Daniel Vetter wrote: On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote: I'm failing to see why we need an overlay ioctl at all. You end up pulling a relatively large amount of state setup into the drm. Why not treat the overlay like EXA or textured video or 3D? The overlay regs are pipelined on most chips so you can program them from command buffers. Just convert the overlay code in the ddx to use gem/ttm and build an appropriate command buffer or in the case of gallium add overlay support in the device specific code and use gem/ttm, etc.. You could even use it to support GL overlays. This. This so hard it hurts. Actually that seems to be the original idea, at least there was already some infrastructure in the driver to support this path. The problem is that at least on intel, the overlay hw is _very_ fragile and you can easily hang the complete chip. To prevent this a delicate dance is needed, carefully sync with the crtc output state. So at least on intel, some overlay support on the kernel side is needed to at least prevent race conditions that may hang the chip. Then have an Intel-specific bit of code. Do a batchbuffer checker/relocator/munger; we've got one for Radeons, and I'm sure you guys need to do something similar for relocating BOs. ~ C. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
