Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Wed, 2009-04-29 at 18:02 -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Is there a mechanism for choosing the CRTC to sync to in ambiguous cases? E.g. either a driconf option (allowing per application configuration) or a RandR property (allowing global configuration) would be nice I think. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] mklib: let static library building ignore ld options
From: Tormod Volden debian.tor...@gmail.com
Dan Nicholson wrote:
Is there any reason not to just use a case statement instead of forking expr?
No, that was just copied from another part of the script.
Tormod
---
Prepend -Wl, to linking options and let mklib ignore -Wl options
inside the object list when building static libraries
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
bin/mklib| 15 +++
src/gallium/winsys/egl_xlib/Makefile |2 +-
src/gallium/winsys/xlib/Makefile |2 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/bin/mklib b/bin/mklib
index a3e826a..86aa80f 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -175,6 +175,21 @@ if [ ${ARCH} = auto ] ; then
ARCH=`uname`
fi
+if [ $STATIC = 1 ]; then
+# filter out linker options inside object list
+NEWOBJECTS=
+for OBJ in $OBJECTS ; do
+ case $OBJ in
+ -Wl,*)
+ echo mklib: warning: ignoring $OBJ for static library
+ ;;
+ *)
+ NEWOBJECTS=$NEWOBJECTS $OBJ
+ ;;
+ esac
+done
+OBJECTS=$NEWOBJECTS
+fi
#
# Error checking
diff --git a/src/gallium/winsys/egl_xlib/Makefile
b/src/gallium/winsys/egl_xlib/Makefile
index 02ac47c..8646ee3 100644
--- a/src/gallium/winsys/egl_xlib/Makefile
+++ b/src/gallium/winsys/egl_xlib/Makefile
@@ -60,7 +60,7 @@ $(TOP)/$(LIB_DIR)/$(DRIVER_NAME): $(WINSYS_OBJECTS) $(LIBS)
-noprefix \
-install $(TOP)/$(LIB_DIR) \
$(MKLIB_OPTIONS) $(WINSYS_OBJECTS) \
- --whole-archive $(LIBS) --no-whole-archive
+ -Wl,--whole-archive $(LIBS) -Wl,--no-whole-archive
depend: $(ALL_SOURCES)
diff --git a/src/gallium/winsys/xlib/Makefile b/src/gallium/winsys/xlib/Makefile
index bb187cc..04309e6 100644
--- a/src/gallium/winsys/xlib/Makefile
+++ b/src/gallium/winsys/xlib/Makefile
@@ -74,7 +74,7 @@ $(TOP)/$(LIB_DIR)/gallium/$(GL_LIB_NAME):
$(XLIB_WINSYS_OBJECTS) $(LIBS) Makefil
-major $(GL_MAJOR) -minor $(GL_MINOR) -patch $(GL_TINY) \
-install $(TOP)/$(LIB_DIR)/gallium \
$(MKLIB_OPTIONS) $(XLIB_WINSYS_OBJECTS) \
- --start-group $(LIBS) --end-group $(GL_LIB_DEPS)
+ -Wl,--start-group $(LIBS) -Wl,--end-group $(GL_LIB_DEPS)
depend: $(XLIB_WINSYS_SOURCES)
--
1.6.0.4
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Determine type before initialising connector
drm_connector_init sets both the connector type and the connector type_id
on the newly initialised connector. As the connector type_id is coupled to
the connector type, the connector type cannot simply be modified on an
initialised connector.
This patch changes the order of operations on intel_sdvo_init so that the
type is determined before the connector is intialised.
This fixes a bug whereby the name card0-VGA-1 would be allocted to both a
CRT and an SDVO connector since the SDVO connector would be initialised
with type 'unknown' and hence have its type_id assigned from the wrong pool.
Signed-off-by: Jonas Bonn jo...@southpole.se
---
drivers/gpu/drm/i915/intel_sdvo.c | 29 ++---
1 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 9913651..605b402 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1676,17 +1676,9 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
return false;
}
- connector = intel_output-base;
-
- drm_connector_init(dev, connector, intel_sdvo_connector_funcs,
- DRM_MODE_CONNECTOR_Unknown);
- drm_connector_helper_add(connector, intel_sdvo_connector_helper_funcs);
sdvo_priv = (struct intel_sdvo_priv *)(intel_output + 1);
intel_output-type = INTEL_OUTPUT_SDVO;
- connector-interlace_allowed = 0;
- connector-doublescan_allowed = 0;
-
/* setup the DDC bus. */
if (output_device == SDVOB)
i2cbus = intel_i2c_create(dev, GPIOE, SDVOCTRL_E for SDVOB);
@@ -1694,7 +1686,7 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
i2cbus = intel_i2c_create(dev, GPIOE, SDVOCTRL_E for SDVOC);
if (!i2cbus)
- goto err_connector;
+ goto err_inteloutput;
sdvo_priv-i2c_bus = i2cbus;
@@ -1710,7 +1702,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
intel_output-i2c_bus = i2cbus;
intel_output-dev_priv = sdvo_priv;
-
/* Read the regs to test if we can talk to the device */
for (i = 0; i 0x40; i++) {
if (!intel_sdvo_read_byte(intel_output, i, ch[i])) {
@@ -1729,7 +1720,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else
sdvo_priv-controlled_output = SDVO_OUTPUT_TMDS1;
- connector-display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_TMDS;
connector_type = DRM_MODE_CONNECTOR_DVID;
@@ -1747,7 +1737,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else if (sdvo_priv-caps.output_flags SDVO_OUTPUT_SVID0)
{
sdvo_priv-controlled_output = SDVO_OUTPUT_SVID0;
- connector-display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_TVDAC;
connector_type = DRM_MODE_CONNECTOR_SVIDEO;
sdvo_priv-is_tv = true;
@@ -1756,28 +1745,24 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else if (sdvo_priv-caps.output_flags SDVO_OUTPUT_RGB0)
{
sdvo_priv-controlled_output = SDVO_OUTPUT_RGB0;
- connector-display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_DAC;
connector_type = DRM_MODE_CONNECTOR_VGA;
}
else if (sdvo_priv-caps.output_flags SDVO_OUTPUT_RGB1)
{
sdvo_priv-controlled_output = SDVO_OUTPUT_RGB1;
- connector-display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_DAC;
connector_type = DRM_MODE_CONNECTOR_VGA;
}
else if (sdvo_priv-caps.output_flags SDVO_OUTPUT_LVDS0)
{
sdvo_priv-controlled_output = SDVO_OUTPUT_LVDS0;
- connector-display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_LVDS;
connector_type = DRM_MODE_CONNECTOR_LVDS;
}
else if (sdvo_priv-caps.output_flags SDVO_OUTPUT_LVDS1)
{
sdvo_priv-controlled_output = SDVO_OUTPUT_LVDS1;
- connector-display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_LVDS;
connector_type = DRM_MODE_CONNECTOR_LVDS;
}
@@ -1795,9 +1780,16 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
goto err_i2c;
}
+ connector = intel_output-base;
+ drm_connector_init(dev, connector, intel_sdvo_connector_funcs,
+ connector_type);
+ drm_connector_helper_add(connector, intel_sdvo_connector_helper_funcs);
+
[Bug 21223] OpenGL screensaver 'lattice' provokes driver crash
http://bugs.freedesktop.org/show_bug.cgi?id=21223 --- Comment #3 from Øyvind Stegard oyvi...@ifi.uio.no 2009-04-30 00:34:31 PST --- (In reply to comment #1) It should be fixed in current master, can you confirm? Is there any easy way of testing this without screwing up my default Ubuntu Jaunty installation :) ? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM/i915 Kernel Warning
With 2.6.30-rc4 I get the following warning: WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xcf/0xe6() Hardware name: P5K-VM sysfs: cannot create duplicate filename '/devices/pci:00/:00:02.0/drm/ca rd0/card0-VGA-1' Pid: 578, comm: work_for_cpu Not tainted 2.6.30-rc4-jonas #79 Call Trace: [81057fb5] warn_slowpath+0xce/0x102 [814c8b64] ? thread_return+0x41/0xbb [8104b2ae] ? resched_task+0x27/0x6e [81241421] ? idr_get_empty_slot+0x169/0x24d [8124762f] ? string+0x3f/0xa2 [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cbd5] sysfs_add_one+0xcf/0xe6 [8112d200] create_dir+0x58/0x93 [8112d273] sysfs_create_dir+0x38/0x4f [81242457] ? kobject_get+0x1a/0x22 [8124260c] kobject_add_internal+0x131/0x20d [81248676] ? delay_tsc+0x2c/0x60 [812427c0] kobject_add_varg+0x41/0x4e [812428d2] kobject_add+0x89/0x8b [81242776] ? kobject_set_name_vargs+0x4f/0x58 [81242457] ? kobject_get+0x1a/0x22 [812fa80e] device_add+0x144/0x5bc [81241786] ? idr_get_new_above+0x11/0x31 [812420b3] ? kobject_init+0x43/0x83 [812fac9f] device_register+0x19/0x1e [812d0653] drm_sysfs_connector_add+0xb6/0x1a2 [812eb238] intel_sdvo_init+0x3c1/0x5a7 [812d038f] ? drm_sysfs_hotplug_event+0x53/0x5a [812e78a3] intel_modeset_init+0x4c2/0x77b [812dadbe] i915_driver_load+0x931/0x99a [812ce2ae] drm_get_dev+0x333/0x3fc [810525ae] ? default_wake_function+0xd/0xf [81067e98] ? do_work_for_cpu+0x0/0x26 [814bbc14] i915_pci_probe+0x10/0x12 [81259e93] local_pci_probe+0x12/0x16 [81067eab] do_work_for_cpu+0x13/0x26 [8106b168] kthread+0x56/0x83 [8102ac0a] child_rip+0xa/0x20 [8106b112] ? kthread+0x0/0x83 [8102ac00] ? child_rip+0x0/0x20 and kobject_add_internal failed for card0-VGA-1 with -EEXIST, don't try to register things with the same name in the same directory. Pid: 578, comm: work_for_cpu Tainted: GW 2.6.30-rc4-jonas #79 Call Trace: [812421ba] ? kobject_put+0x47/0x4b [812426b6] kobject_add_internal+0x1db/0x20d [81248676] ? delay_tsc+0x2c/0x60 [812427c0] kobject_add_varg+0x41/0x4e [812428d2] kobject_add+0x89/0x8b [81242776] ? kobject_set_name_vargs+0x4f/0x58 [81242457] ? kobject_get+0x1a/0x22 [812fa80e] device_add+0x144/0x5bc [81241786] ? idr_get_new_above+0x11/0x31 [812420b3] ? kobject_init+0x43/0x83 [812fac9f] device_register+0x19/0x1e [812d0653] drm_sysfs_connector_add+0xb6/0x1a2 [812eb238] intel_sdvo_init+0x3c1/0x5a7 [812d038f] ? drm_sysfs_hotplug_event+0x53/0x5a [812e78a3] intel_modeset_init+0x4c2/0x77b [812dadbe] i915_driver_load+0x931/0x99a [812ce2ae] drm_get_dev+0x333/0x3fc [810525ae] ? default_wake_function+0xd/0xf [81067e98] ? do_work_for_cpu+0x0/0x26 [814bbc14] i915_pci_probe+0x10/0x12 [81259e93] local_pci_probe+0x12/0x16 [81067eab] do_work_for_cpu+0x13/0x26 [8106b168] kthread+0x56/0x83 [8102ac0a] child_rip+0xa/0x20 [8106b112] ? kthread+0x0/0x83 [8102ac00] ? child_rip+0x0/0x20 This happens because the type of connector in intel_sdvo_init is intially set to Unknown. The 'type_id' of the connector is thus selected from the ID pool for connectors of type Unknown. When the connector type is subsequently changed, the type_id is wrong as it hasn't been taken from the right pool. The attached patch resolves this by determing the connector type before initializing the connector. It should be noted that the connector_type should not be changed after the connector has been initialized. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21223] OpenGL screensaver 'lattice' provokes driver crash
http://bugs.freedesktop.org/show_bug.cgi?id=21223 --- Comment #4 from Øyvind Stegard oyvi...@ifi.uio.no 2009-04-30 00:37:52 PST --- (In reply to comment #3) (In reply to comment #1) It should be fixed in current master, can you confirm? Is there any easy way of testing this without screwing up my default Ubuntu Jaunty installation :) ? I'm asking because the affected hardware is actually my work/coding laptop, so I cannot afford to mess too much with it timewise. Is it only necessary to install a newer set of radeon.ko/drm.ko or do I need to update libs as well ? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21223] OpenGL screensaver 'lattice' provokes driver crash
http://bugs.freedesktop.org/show_bug.cgi?id=21223 --- Comment #5 from Michel Dänzer mic...@daenzer.net 2009-04-30 01:22:04 PST --- No need to install anything, just set LIBGL_DRIVERS_PATH to the directory containing the self-built r300_dri.so. You can also set LIBGL_DEBUG=verbose to verify the right one is getting picked up. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Wed, Apr 29, 2009 at 06:02:59PM -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Your interval handling seems to be too harsh. In case you wanted something that can implement GLX_SGI_swap_control then AFAICS the interval should only specify the minimum number of frames that must pass between two swaps. Your code appears to always delay the flip by exactly interval frames. Also it seems that the cases where you have more than one back buffer were not yet fully considered. I can see two use cases for this: 1) Triple buffering with the purpose of going faster than the monitor refresh rate w/o tearing. Here you would never wait for any flips and if a new flip is scheduled before the previous was completed then the previous flip should be considered immediately complete so the buffer can be reused. 2) Scheduling multiple flips in advance while maintaining the swap interval. This way the application could render several frames in advance and just queue the flips in the driver to gain a little more breathing room for the rendering. And as a final missing piece I would mention interlaced output with proper field parity, but I'm not sure if you're interested in such things for this API. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21223] OpenGL screensaver 'lattice' provokes driver crash
http://bugs.freedesktop.org/show_bug.cgi?id=21223 --- Comment #6 from Øyvind Stegard oyvi...@ifi.uio.no 2009-04-30 03:11:09 PST --- (In reply to comment #5) No need to install anything, just set LIBGL_DRIVERS_PATH to the directory containing the self-built r300_dri.so. You can also set LIBGL_DEBUG=verbose to verify the right one is getting picked up. Very nice approach indeed, I'll get this tested. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] libdrm: introduce drmLoadKernelModule() to reduce duplicate code
drmOpenByName() is called only by drmOpen(), so it's enough to
call drmLoadKernelModule() only in drmOpen().
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
libdrm/xf86drm.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
--- drm.orig/libdrm/xf86drm.c
+++ drm/libdrm/xf86drm.c
@@ -439,6 +439,29 @@ int drmAvailable(void)
return retval;
}
+static int drmLoadKernelModule(const char *name)
+{
+if (drmAvailable())
+ return 0;
+
+if (name == NULL) {
+ drmMsg([drm] null kernel module name\n);
+ return -1;
+}
+
+if (!drm_server_info) {
+ drmMsg([drm] too early to be able to load kernel module\n);
+ return -1;
+}
+
+/* try to load the kernel module now */
+if (drm_server_info-load_module(name))
+ return 0;
+
+drmMsg([drm] failed to load kernel module \%s\\n, name);
+return -1;
+}
+
/**
* Open the device by bus ID.
@@ -506,19 +529,6 @@ static int drmOpenByName(const char *nam
drmVersionPtr version;
char *id;
-if (!drmAvailable()) {
- if (!drm_server_info) {
- return -1;
- }
- else {
- /* try to load the kernel module now */
- if (!drm_server_info-load_module(name)) {
- drmMsg([drm] failed to load kernel module \%s\\n, name);
- return -1;
- }
- }
-}
-
/*
* Open the first minor number that matches the driver name and isn't
* already in use. If it's in use it will have a busid assigned already.
@@ -598,13 +608,8 @@ static int drmOpenByName(const char *nam
*/
int drmOpen(const char *name, const char *busid)
{
-if (!drmAvailable() name != NULL drm_server_info) {
- /* try to load the kernel */
- if (!drm_server_info-load_module(name)) {
- drmMsg([drm] failed to load kernel module \%s\\n, name);
+if (drmLoadKernelModule(name))
return -1;
- }
-}
if (busid) {
int fd = drmOpenByBusid(busid);
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Thu, 30 Apr 2009 08:08:36 +0200 Michel Dänzer mic...@daenzer.net wrote: On Wed, 2009-04-29 at 18:02 -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Is there a mechanism for choosing the CRTC to sync to in ambiguous cases? E.g. either a driconf option (allowing per application configuration) or a RandR property (allowing global configuration) would be nice I think. The kernel is supposed to handle it and reject flips on disabled CRTCs so I was hoping it wouldn't be necessary. But the 2D driver controls which CRTC id is passed to the kernel, so it could be exposed as an xrandr option possibly. -- Jesse Barnes, Intel Open Source Technology Center -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Thu, 2009-04-30 at 08:39 -0700, Jesse Barnes wrote: On Thu, 30 Apr 2009 08:08:36 +0200 Michel Dänzer mic...@daenzer.net wrote: On Wed, 2009-04-29 at 18:02 -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Is there a mechanism for choosing the CRTC to sync to in ambiguous cases? E.g. either a driconf option (allowing per application configuration) or a RandR property (allowing global configuration) would be nice I think. The kernel is supposed to handle it and reject flips on disabled CRTCs so I was hoping it wouldn't be necessary. That's not an ambiguous case. Ambiguous cases are when parts of the window are visible on both CRTCs. But the 2D driver controls which CRTC id is passed to the kernel, so it could be exposed as an xrandr option possibly. Sounds good. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Thu, 30 Apr 2009 11:36:55 +0300 Ville Syrjälä syrj...@sci.fi wrote: On Wed, Apr 29, 2009 at 06:02:59PM -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Your interval handling seems to be too harsh. In case you wanted something that can implement GLX_SGI_swap_control then AFAICS the interval should only specify the minimum number of frames that must pass between two swaps. Your code appears to always delay the flip by exactly interval frames. The completion won't happen until at least 'interval' frames have passed since the flip was queued, so I think the semantics match? Also it seems that the cases where you have more than one back buffer were not yet fully considered. I can see two use cases for this: 1) Triple buffering with the purpose of going faster than the monitor refresh rate w/o tearing. Here you would never wait for any flips and if a new flip is scheduled before the previous was completed then the previous flip should be considered immediately complete so the buffer can be reused. 2) Scheduling multiple flips in advance while maintaining the swap interval. This way the application could render several frames in advance and just queue the flips in the driver to gain a little more breathing room for the rendering. Yeah, I intended for the DRI2 protocol I added to handle this case, but there's no code for it yet. I think it could be done purely in the 2D driver though. I think case (2) is probably the most important here, but (1) is pretty easy to do as well. And as a final missing piece I would mention interlaced output with proper field parity, but I'm not sure if you're interested in such things for this API. We could treat the 'interval' as meaning odd/even in that case. I.e. an interval of 1 would mean 'next field' and 2 would mean 'start of next frame', but yeah there's not much support for interlacing in the kernel atm. -- Jesse Barnes, Intel Open Source Technology Center -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Thu, 30 Apr 2009 17:48:08 +0200 Michel Dänzer mic...@daenzer.net wrote: On Thu, 2009-04-30 at 08:39 -0700, Jesse Barnes wrote: On Thu, 30 Apr 2009 08:08:36 +0200 Michel Dänzer mic...@daenzer.net wrote: On Wed, 2009-04-29 at 18:02 -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Is there a mechanism for choosing the CRTC to sync to in ambiguous cases? E.g. either a driconf option (allowing per application configuration) or a RandR property (allowing global configuration) would be nice I think. The kernel is supposed to handle it and reject flips on disabled CRTCs so I was hoping it wouldn't be necessary. That's not an ambiguous case. Ambiguous cases are when parts of the window are visible on both CRTCs. Ah ok, yeah I'd expect that to be up to the 2D driver as well. The display manager will get a swapbuffers request for a given drawable, and it's up to the 2D driver to figure out what to do with it. If the buffer spans the whole X screen, this code queues a flip in the kernel on every CRTC that has that buffer. If the request is just for a window, the driver could queue blits on each CRTC separately, or do scanline waits on one or each CRTC during the copy operation. But in this code we just punt on anything non-fullscreen and let CopyRegion handle it (which currently doesn't sync). The best solution would probably be to add code to CopyRegion that looks like what we have in intelWindowMoved, picking the best CRTC to sync on (though maybe with an override option like you suggest). -- Jesse Barnes, Intel Open Source Technology Center -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12861] Xorg fails to start Failed to allocate space for kernel memory manager
http://bugzilla.kernel.org/show_bug.cgi?id=12861 --- Comment #30 from Emil Karlson jkarl...@cc.hut.fi 2009-04-30 17:27:00 --- Bug is still present in linux-2.6.30-rc4. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13214] New: Blank internal Display on Notebook with Intel GPU (855GM)
http://bugzilla.kernel.org/show_bug.cgi?id=13214 Summary: Blank internal Display on Notebook with Intel GPU (855GM) Product: Drivers Version: 2.5 Kernel Version: 2.6.30-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: djen...@freenet.de Regression: No Created an attachment (id=21171) -- (http://bugzilla.kernel.org/attachment.cgi?id=21171) Kernel log Notebook: Acer TravelMate 660, Intel 855GM GPU, internal 15 1400x1050 LCD. This behavior can be seen with or without building the kernel with internal KMS support. Tested Kernel was mainline 2.6.30-rc2 and -rc3. Both scenario are without X, just multi-user (rl 3, console) on Archlinux. Arch-Kernel 2.6.29 also show this issue. With builtin KMS: start up the maschine you see some kernel messages. When drm/i915 is loaded/started the internal display goes blank. Backlight however is on. Without builtin KMS: start up the maschine you see all kernel messages and can login normally on the console. After that I do: $ modprobe drm debug=1 $ modprobe i915 modeset=1 (please see attached kernel.log) Here the display goes blank but you can still fly blind, so system still is working (same as with builtin KMS). If you have attached an external display, that one is working as expected. KMS/drm/i915 switches the resolution and you have the console output on the external display but still no internal display. With attached external display you can start xserver and it is working as expected, but output on external display only. If you need more info/log files please let my know. I would be also able to test patches if there are any. --- Comment #1 from Stefan Glasenhardt ste...@glasen-hardt.de 2009-04-30 18:12:32 --- Created an attachment (id=21172) -- (http://bugzilla.kernel.org/attachment.cgi?id=21172) Kernel-log with activated KMS, no external display I've exact the same problem with my notebook (Dell Latitude D505, Intel 855GM). If i attach an external monitor (VGA or DVI) KMS works perfectly. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13214] Blank internal Display on Notebook with Intel GPU (855GM)
http://bugzilla.kernel.org/show_bug.cgi?id=13214 --- Comment #3 from djen...@freenet.de 2009-04-30 18:57:09 --- OK, original Post (bug report) from February but no solution yet. Thanks for pointing it out Bruno (Sorry, I did not find it). Any chance to get this fixed. ;) btw. As you correctly stated (in your bug report) it doesn't seem to be a xorg related Problem. Up to console, xorg is nowhere involved here, it's just kernel (drm/i915/KMS). Should I mark this as duplicate? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13214] Blank internal Display on Notebook with Intel GPU (855GM)
http://bugzilla.kernel.org/show_bug.cgi?id=13214 --- Comment #4 from Bruno bonbon...@internet.lu 2009-04-30 19:18:28 --- Don't think you can mark it as duplicate against a bug from external bugzilla (looks like verified/moved would be more appropriate) What you should definitely do is post a link to this bug on http://bugs.freedesktop.org/show_bug.cgi?id=20115 so bidirectional link exists and add yourself to the CC. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] mklib: cosmetic: use case instead of expr match
From: Tormod Volden debian.tor...@gmail.com
Saves forking an expr for every object.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
On Thu, Apr 30, 2009 at 8:37 AM, Tormod Volden wrote:
Dan Nicholson wrote:
Is there any reason not to just use a case statement instead of forking expr?
No, that was just copied from another part of the script.
And to save the trees, here is an additional patch to fix the part I had copied
from.
Cheers,
Tormod
--
bin/mklib | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/bin/mklib b/bin/mklib
index 86aa80f..6331f5a 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -279,18 +279,21 @@ case $ARCH in
# expand any .a objects into constituent .o files.
NEWOBJECTS=
DELETIA=
- for OBJ in ${OBJECTS} ; do
- if [ `expr match $OBJ '.*\.a'` -gt 0 ] ; then
- # extract the .o files from this .a archive
- FILES=`ar t $OBJ`
- ar x $OBJ
- NEWOBJECTS=$NEWOBJECTS $FILES
- # keep track of temporary .o files and delete them below
- DELETIA=$DELETIA $FILES
- else
- # ordinary .o file
- NEWOBJECTS=$NEWOBJECTS $OBJ
- fi
+ for OBJ in $OBJECTS ; do
+ case $OBJ in
+ *.a)
+ # extract the .o files from this .a archive
+ FILES=`ar t $OBJ`
+ ar x $OBJ
+ NEWOBJECTS=$NEWOBJECTS $FILES
+ # keep track of temporary .o files and delete them below
+ DELETIA=$DELETIA $FILES
+ ;;
+ *)
+ # ordinary .o file
+ NEWOBJECTS=$NEWOBJECTS $OBJ
+ ;;
+ esac
done
# make lib
--
1.6.0.4
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: save/restore fence registers across suspend/resume
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/Makefile|1 -
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/i915_suspend.c | 24
drivers/gpu/drm/i915/intel_display.c |4 ++--
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 184b8bf..51c5a05 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -13,7 +13,6 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_crt.o \
intel_lvds.o \
intel_bios.o \
- intel_dp.o \
intel_hdmi.o \
intel_sdvo.o \
intel_modes.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d7471fe..6c399e8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,7 @@ typedef struct drm_i915_private {
u8 saveAR[21];
u8 saveDACMASK;
u8 saveCR[37];
+ uint64_t saveFENCE[16];
struct {
struct drm_mm gtt_space;
@@ -712,6 +713,12 @@ extern void intel_modeset_cleanup(struct drm_device *dev);
writel(upper_32_bits(val), dev_priv-regs + \
(reg) + 4))
#endif
+#ifdef readq
+#define I915_READ64(reg) readq(dev_priv-regs + (reg))
+#else
+#define I915_READ64(reg, val) (((uint64_t) readl(dev_priv-regs + (reg))) | \
+((uint64_t) readl(dev_priv-regs + (reg) + 4)
32))
+#endif
#define POSTING_READ(reg) (void)I915_READ(reg)
#define I915_VERBOSE 0
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index d669cc2..8727894 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -349,6 +349,18 @@ int i915_save_state(struct drm_device *dev)
for (i = 0; i 3; i++)
dev_priv-saveSWF2[i] = I915_READ(SWF30 + (i 2));
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ dev_priv-saveFENCE[i] = I915_READ64(FENCE_REG_965_0 +
(i * 8));
+ } else {
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i] = I915_READ(FENCE_REG_830_0 + (i
* 4));
+
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i+8] =
I915_READ(FENCE_REG_945_8 + (i * 4));
+ }
i915_save_vga(dev);
return 0;
@@ -371,6 +383,18 @@ int i915_restore_state(struct drm_device *dev)
/* Display arbitration */
I915_WRITE(DSPARB, dev_priv-saveDSPARB);
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ I915_WRITE64(FENCE_REG_965_0 + (i * 8),
dev_priv-saveFENCE[i]);
+ } else {
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_830_0 + (i * 4),
dev_priv-saveFENCE[i]);
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_945_8 + (i * 4),
dev_priv-saveFENCE[i+8]);
+ }
+
/* Pipe plane A info */
/* Prime the clock */
if (dev_priv-saveDPLL_A DPLL_VCO_ENABLE) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b6bedd9..761567f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1278,8 +1278,8 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
/* The Display Port M/N ratio needs to be set before the DPLL is enabled
*/
- if (is_dp)
- intel_dp_set_m_n(crtc, mode, adjusted_mode);
+// if (is_dp)
+// intel_dp_set_m_n(crtc, mode, adjusted_mode);
I915_WRITE(fp_reg, fp);
I915_WRITE(dpll_reg, dpll);
--
1.6.2.4
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2]: the patch set to weaken the dependency between ACPI video driver and i915 driver
(cc dri-devel) On Thu, 23 Apr 2009 15:56:24 -0400 (EDT) Len Brown l...@kernel.org wrote: applied thanks, Len Brown, Intel Open Source Technology Center On Wed, 15 Apr 2009, Matthew Garrett wrote: How about we just replace these with the following? diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3a22eb9..cf7e7c2 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -71,6 +71,7 @@ config DRM_I915 select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT select FB + select ACPI_VIDEO if ACPI tristate i915 driver help Choose this option if you have a system that has Intel 830M, 845G, You applied this a week ago, but it isn't in mainline or linux-next. We La described it as fixing a regression and David John said : Can you forward this patch to Linus? This regression breaks quite a : few configs where ACPI Video is compiled as a module and i915 is built : in. This should have been in stable, but I guess it's too late now. So... wazzup? -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: save/restore fence registers across suspend/resume
On Thu, Apr 30, 2009 at 1:26 PM, Keith Packard kei...@keithp.com wrote:
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard kei...@keithp.com
No comments on the meat of the patch, but...
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_suspend.c | 24
drivers/gpu/drm/i915/intel_display.c | 4 ++--
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 184b8bf..51c5a05 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -13,7 +13,6 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_crt.o \
intel_lvds.o \
intel_bios.o \
- intel_dp.o \
intel_hdmi.o \
intel_sdvo.o \
intel_modes.o \
I don't think you meant to include this.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d7471fe..6c399e8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,7 @@ typedef struct drm_i915_private {
u8 saveAR[21];
u8 saveDACMASK;
u8 saveCR[37];
+ uint64_t saveFENCE[16];
struct {
struct drm_mm gtt_space;
@@ -712,6 +713,12 @@ extern void intel_modeset_cleanup(struct drm_device
*dev);
writel(upper_32_bits(val), dev_priv-regs + \
(reg) + 4))
#endif
+#ifdef readq
+#define I915_READ64(reg) readq(dev_priv-regs + (reg))
+#else
+#define I915_READ64(reg, val) (((uint64_t) readl(dev_priv-regs + (reg))) |
\
+ ((uint64_t) readl(dev_priv-regs + (reg) +
4) 32))
+#endif
I don't think you want the val argument for the fallback I915_READ64.
I'm sure this was just a copy-paste-o.
#define POSTING_READ(reg) (void)I915_READ(reg)
#define I915_VERBOSE 0
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index d669cc2..8727894 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -349,6 +349,18 @@ int i915_save_state(struct drm_device *dev)
for (i = 0; i 3; i++)
dev_priv-saveSWF2[i] = I915_READ(SWF30 + (i 2));
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ dev_priv-saveFENCE[i] = I915_READ64(FENCE_REG_965_0
+ (i * 8));
+ } else {
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i] = I915_READ(FENCE_REG_830_0 +
(i * 4));
+
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i+8] =
I915_READ(FENCE_REG_945_8 + (i * 4));
+ }
i915_save_vga(dev);
return 0;
@@ -371,6 +383,18 @@ int i915_restore_state(struct drm_device *dev)
/* Display arbitration */
I915_WRITE(DSPARB, dev_priv-saveDSPARB);
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ I915_WRITE64(FENCE_REG_965_0 + (i * 8),
dev_priv-saveFENCE[i]);
+ } else {
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_830_0 + (i * 4),
dev_priv-saveFENCE[i]);
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_945_8 + (i * 4),
dev_priv-saveFENCE[i+8]);
+ }
+
/* Pipe plane A info */
/* Prime the clock */
if (dev_priv-saveDPLL_A DPLL_VCO_ENABLE) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b6bedd9..761567f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1278,8 +1278,8 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
/* The Display Port M/N ratio needs to be set before the DPLL is
enabled
*/
- if (is_dp)
- intel_dp_set_m_n(crtc, mode, adjusted_mode);
+// if (is_dp)
+// intel_dp_set_m_n(crtc, mode, adjusted_mode);
I915_WRITE(fp_reg, fp);
I915_WRITE(dpll_reg, dpll);
Pretty sure you didn't want this part, either. :)
--
Dan
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an
Re: [Intel-gfx] [PATCH] drm/i915: save/restore fence registers across suspend/resume
On Thu, 2009-04-30 at 13:45 -0700, Dan Nicholson wrote: I don't think you meant to include this. oops. wrong branch. Correct patch coming in a moment. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: save/restore fence registers across suspend/resume
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/i915_suspend.c | 24
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2506592..aa90884 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,7 @@ typedef struct drm_i915_private {
u8 saveAR[21];
u8 saveDACMASK;
u8 saveCR[37];
+ uint64_t saveFENCE[16];
struct {
struct drm_mm gtt_space;
@@ -712,6 +713,12 @@ extern void intel_modeset_cleanup(struct drm_device *dev);
writel(upper_32_bits(val), dev_priv-regs + \
(reg) + 4))
#endif
+#ifdef readq
+#define I915_READ64(reg) readq(dev_priv-regs + (reg))
+#else
+#define I915_READ64(reg, val) (((uint64_t) readl(dev_priv-regs + (reg))) | \
+((uint64_t) readl(dev_priv-regs + (reg) + 4)
32))
+#endif
#define POSTING_READ(reg) (void)I915_READ(reg)
#define I915_VERBOSE 0
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index d669cc2..8727894 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -349,6 +349,18 @@ int i915_save_state(struct drm_device *dev)
for (i = 0; i 3; i++)
dev_priv-saveSWF2[i] = I915_READ(SWF30 + (i 2));
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ dev_priv-saveFENCE[i] = I915_READ64(FENCE_REG_965_0 +
(i * 8));
+ } else {
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i] = I915_READ(FENCE_REG_830_0 + (i
* 4));
+
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i+8] =
I915_READ(FENCE_REG_945_8 + (i * 4));
+ }
i915_save_vga(dev);
return 0;
@@ -371,6 +383,18 @@ int i915_restore_state(struct drm_device *dev)
/* Display arbitration */
I915_WRITE(DSPARB, dev_priv-saveDSPARB);
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ I915_WRITE64(FENCE_REG_965_0 + (i * 8),
dev_priv-saveFENCE[i]);
+ } else {
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_830_0 + (i * 4),
dev_priv-saveFENCE[i]);
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_945_8 + (i * 4),
dev_priv-saveFENCE[i+8]);
+ }
+
/* Pipe plane A info */
/* Prime the clock */
if (dev_priv-saveDPLL_A DPLL_VCO_ENABLE) {
--
1.6.2.4
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: save/restore fence registers across suspend/resume
On Thu, Apr 30, 2009 at 1:58 PM, Keith Packard kei...@keithp.com wrote:
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_suspend.c | 24
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2506592..aa90884 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,7 @@ typedef struct drm_i915_private {
u8 saveAR[21];
u8 saveDACMASK;
u8 saveCR[37];
+ uint64_t saveFENCE[16];
struct {
struct drm_mm gtt_space;
@@ -712,6 +713,12 @@ extern void intel_modeset_cleanup(struct drm_device
*dev);
writel(upper_32_bits(val), dev_priv-regs + \
(reg) + 4))
#endif
+#ifdef readq
+#define I915_READ64(reg) readq(dev_priv-regs + (reg))
+#else
+#define I915_READ64(reg, val) (((uint64_t) readl(dev_priv-regs + (reg))) |
\
+ ((uint64_t) readl(dev_priv-regs + (reg) +
4) 32))
+#endif
This still has an invalid val argument in the fallback READ64.
--
Dan
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: save/restore fence registers across suspend/resume
On Thu, 30 Apr 2009 13:58:06 -0700 Keith Packard kei...@keithp.com wrote: This makes software fallbacks not do tiling wrong on i965 and later after resume. It also should fix 945 performance reduction after resume which would have disabled tiling without causing any visible effect. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_drv.h |7 +++ drivers/gpu/drm/i915/i915_suspend.c | 24 2 files changed, 31 insertions(+), 0 deletions(-) krh and I were just talking about this yesterday. This is probably the simplest way to fix the issue, so Acked-by: Jesse Barnes jbar...@virtuousgeek.org Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: save/restore fence registers across suspend/resume
On Thu, Apr 30, 2009 at 01:26:58PM -0700, Keith Packard wrote: This makes software fallbacks not do tiling wrong on i965 and later after resume. It also should fix 945 performance reduction after resume which would have disabled tiling without causing any visible effect. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/Makefile|1 - drivers/gpu/drm/i915/i915_drv.h |7 +++ drivers/gpu/drm/i915/i915_suspend.c | 24 drivers/gpu/drm/i915/intel_display.c |4 ++-- 4 files changed, 33 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 184b8bf..51c5a05 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -13,7 +13,6 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \ intel_crt.o \ intel_lvds.o \ intel_bios.o \ - intel_dp.o \ intel_hdmi.o \ intel_sdvo.o \ intel_modes.o \ [...] diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b6bedd9..761567f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1278,8 +1278,8 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc, /* The Display Port M/N ratio needs to be set before the DPLL is enabled */ - if (is_dp) - intel_dp_set_m_n(crtc, mode, adjusted_mode); +// if (is_dp) +// intel_dp_set_m_n(crtc, mode, adjusted_mode); I915_WRITE(fp_reg, fp); I915_WRITE(dpll_reg, dpll); o/~ one of these is not like the other Cheers, Daniel signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Thu, Apr 30, 2009 at 08:49:12AM -0700, Jesse Barnes wrote: On Thu, 30 Apr 2009 11:36:55 +0300 Ville Syrjälä syrj...@sci.fi wrote: On Wed, Apr 29, 2009 at 06:02:59PM -0700, Jesse Barnes wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Your interval handling seems to be too harsh. In case you wanted something that can implement GLX_SGI_swap_control then AFAICS the interval should only specify the minimum number of frames that must pass between two swaps. Your code appears to always delay the flip by exactly interval frames. The completion won't happen until at least 'interval' frames have passed since the flip was queued, so I think the semantics match? Well I guess it satisfies the requirement that flips will never happen less than interval frames apart but if the application is flipping at a slower rate anyway you still delay each flip by interval frames even though there is no real need to do so. So it increases the latency a bit. Also if/when you add support for queueing multiple flips the code needs to be changed anyway to use the previous flip rather than when the current flip was queued as the reference. Also it seems that the cases where you have more than one back buffer were not yet fully considered. I can see two use cases for this: 1) Triple buffering with the purpose of going faster than the monitor refresh rate w/o tearing. Here you would never wait for any flips and if a new flip is scheduled before the previous was completed then the previous flip should be considered immediately complete so the buffer can be reused. 2) Scheduling multiple flips in advance while maintaining the swap interval. This way the application could render several frames in advance and just queue the flips in the driver to gain a little more breathing room for the rendering. Yeah, I intended for the DRI2 protocol I added to handle this case, but there's no code for it yet. I think it could be done purely in the 2D driver though. I think case (2) is probably the most important here, but (1) is pretty easy to do as well. Well, I consider 1 more important since it makes tear-free rendering w/o additional delays possible. But anyways both seem to have some value so ideally both should be supported. And as a final missing piece I would mention interlaced output with proper field parity, but I'm not sure if you're interested in such things for this API. We could treat the 'interval' as meaning odd/even in that case. I.e. an interval of 1 would mean 'next field' and 2 would mean 'start of next frame', but yeah there's not much support for interlacing in the kernel atm. What's needed is rather next top field or next bottom field. If you combine that with supporting interval (should be useful when queueuing up several frames using 3:2 pulldown sequence) then there seems to be a need for something more than just a single number. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Fri, 1 May 2009 00:25:54 +0300 Ville Syrjälä syrj...@sci.fi wrote: The completion won't happen until at least 'interval' frames have passed since the flip was queued, so I think the semantics match? Well I guess it satisfies the requirement that flips will never happen less than interval frames apart but if the application is flipping at a slower rate anyway you still delay each flip by interval frames even though there is no real need to do so. So it increases the latency a bit. Also if/when you add support for queueing multiple flips the code needs to be changed anyway to use the previous flip rather than when the current flip was queued as the reference. Ah yeah I see what you mean, so if the app renders a frame and then queues a flip to happen in two refreshes, but doesn't queue its next frame until one refresh after the last one, you'll get a stutter, with 2 refreshes between the first two frames, and 3 between the next two. If the app checks the frame count though, it could compensate and lower its frame frequency to something it can render at a fixed rate, as well as sending in a proper interval value. And as a final missing piece I would mention interlaced output with proper field parity, but I'm not sure if you're interested in such things for this API. We could treat the 'interval' as meaning odd/even in that case. I.e. an interval of 1 would mean 'next field' and 2 would mean 'start of next frame', but yeah there's not much support for interlacing in the kernel atm. What's needed is rather next top field or next bottom field. If you combine that with supporting interval (should be useful when queueuing up several frames using 3:2 pulldown sequence) then there seems to be a need for something more than just a single number. Ok. I'd better add whatever's needed to the ioctl now so we don't have to make a new one later. You think just an odd/even field flag would be sufficient? -- Jesse Barnes, Intel Open Source Technology Center -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/i915: x86 always has writeq. Add I915_READ64 for symmetry.
i386 has inline code for writeq and readq, so just use those instead of ugly macros which evaluate arguments multiple times. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_drv.h |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2506592..df08eb4 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -705,13 +705,8 @@ extern void intel_modeset_cleanup(struct drm_device *dev); #define I915_WRITE16(reg, val) writel(val, dev_priv-regs + (reg)) #define I915_READ8(reg)readb(dev_priv-regs + (reg)) #define I915_WRITE8(reg, val) writeb(val, dev_priv-regs + (reg)) -#ifdef writeq #define I915_WRITE64(reg, val) writeq(val, dev_priv-regs + (reg)) -#else -#define I915_WRITE64(reg, val) (writel(val, dev_priv-regs + (reg)), \ -writel(upper_32_bits(val), dev_priv-regs + \ - (reg) + 4)) -#endif +#define I915_READ64(reg) readq(dev_priv-regs + (reg)) #define POSTING_READ(reg) (void)I915_READ(reg) #define I915_VERBOSE 0 -- 1.6.2.4 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/i915: save/restore fence registers across suspend/resume
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_suspend.c | 24
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df08eb4..b47af07 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,7 @@ typedef struct drm_i915_private {
u8 saveAR[21];
u8 saveDACMASK;
u8 saveCR[37];
+ uint64_t saveFENCE[16];
struct {
struct drm_mm gtt_space;
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index d669cc2..8727894 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -349,6 +349,18 @@ int i915_save_state(struct drm_device *dev)
for (i = 0; i 3; i++)
dev_priv-saveSWF2[i] = I915_READ(SWF30 + (i 2));
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ dev_priv-saveFENCE[i] = I915_READ64(FENCE_REG_965_0 +
(i * 8));
+ } else {
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i] = I915_READ(FENCE_REG_830_0 + (i
* 4));
+
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ dev_priv-saveFENCE[i+8] =
I915_READ(FENCE_REG_945_8 + (i * 4));
+ }
i915_save_vga(dev);
return 0;
@@ -371,6 +383,18 @@ int i915_restore_state(struct drm_device *dev)
/* Display arbitration */
I915_WRITE(DSPARB, dev_priv-saveDSPARB);
+ /* Fences */
+ if (IS_I965G(dev)) {
+ for (i = 0; i 16; i++)
+ I915_WRITE64(FENCE_REG_965_0 + (i * 8),
dev_priv-saveFENCE[i]);
+ } else {
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_830_0 + (i * 4),
dev_priv-saveFENCE[i]);
+ if (IS_I9XX(dev))
+ for (i = 0; i 8; i++)
+ I915_WRITE(FENCE_REG_945_8 + (i * 4),
dev_priv-saveFENCE[i+8]);
+ }
+
/* Pipe plane A info */
/* Prime the clock */
if (dev_priv-saveDPLL_A DPLL_VCO_ENABLE) {
--
1.6.2.4
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: cache the EDID information of the LVDS
On Wed, 01 Apr 2009 12:29:04 -0700 Eric Anholt e...@anholt.net wrote: On Fri, 2009-03-27 at 22:01 -0700, Arjan van de Ven wrote: On Fri, 27 Mar 2009 16:08:18 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: return ret; I definitely like the idea of caching the LVDS EDID, but rather than adding it to the intel_output struct I'd rather see it stored with the rest of the LVDS stuff in i915_private (though that stuff should be pulled out into an output private at some point). We could also just open code the intel_ddc_get_modes stuff in intel_lvds_init, getting the EDID just once, storing the property once, and adding the mode list once. intel_lvds_get_modes would need to be fixed too... that gets a bit messy though, esp if other output types decide to also want to cache. Remember that some of this code gets called from DRM or even userland, so the edid will end up being stored in a generic structure Ack. SDVO LVDS and eDP would also want to do this, and i915_private then seems like the wrong place. Yeah after looking again (and fixing this issue myself having forgotten about this), I ack it. Wanna pull it in Eric? Acked-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] KMS: do a faster EDID
On Fri, 2009-03-27 at 16:08 -0700, Jesse Barnes wrote: On Mon, 23 Mar 2009 13:48:01 -0700 Arjan van de Ven ar...@infradead.org wrote: From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:37:20 -0700 Subject: [PATCH] KMS: do a faster EDID for some outputs (like LVDS), the current delays in the EDID reader are way overkill. This patch makes the EDID reader try twice; first with a 5x faster probe, and if that fails, it probes at the current speed. This reduces probe time on my LVDS panel significantly. Signed-off-by: Arjan van de Ven ar...@linux.intel.com Theoretically this should work fine, but there may be more savings to be had in the underlying EDID fetching code timing. I know our timings aren't as good as X yet, but we may be able to do something similar in the actual DDC probing as well (use fast timings first, then fall back to robust ones if that fails) and get a double benefit. Have you looked at that at all? Either way, this one looks ok, so I'm ok with it as long as Dave is. Acked-by: Jesse Barnes jbar...@virtuousgeek.org We need to just figure out how to use the GMBUS stuff successfully. It's what everyone else uses as far as I know. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mklib: cosmetic: use case instead of expr match
Thanks. I'll commit this and your prev patch after a bit more testing...
-Brian
Tormod Volden wrote:
From: Tormod Volden debian.tor...@gmail.com
Saves forking an expr for every object.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
On Thu, Apr 30, 2009 at 8:37 AM, Tormod Volden wrote:
Dan Nicholson wrote:
Is there any reason not to just use a case statement instead of forking
expr?
No, that was just copied from another part of the script.
And to save the trees, here is an additional patch to fix the part I had
copied from.
Cheers,
Tormod
--
bin/mklib | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/bin/mklib b/bin/mklib
index 86aa80f..6331f5a 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -279,18 +279,21 @@ case $ARCH in
# expand any .a objects into constituent .o files.
NEWOBJECTS=
DELETIA=
- for OBJ in ${OBJECTS} ; do
- if [ `expr match $OBJ '.*\.a'` -gt 0 ] ; then
- # extract the .o files from this .a archive
- FILES=`ar t $OBJ`
- ar x $OBJ
- NEWOBJECTS=$NEWOBJECTS $FILES
- # keep track of temporary .o files and delete them below
- DELETIA=$DELETIA $FILES
- else
- # ordinary .o file
- NEWOBJECTS=$NEWOBJECTS $OBJ
- fi
+ for OBJ in $OBJECTS ; do
+ case $OBJ in
+ *.a)
+ # extract the .o files from this .a archive
+ FILES=`ar t $OBJ`
+ ar x $OBJ
+ NEWOBJECTS=$NEWOBJECTS $FILES
+ # keep track of temporary .o files and delete them below
+ DELETIA=$DELETIA $FILES
+ ;;
+ *)
+ # ordinary .o file
+ NEWOBJECTS=$NEWOBJECTS $OBJ
+ ;;
+ esac
done
# make lib
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: add drm_mode_getconnector_current function
libdrm xf86-video-intel for this.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index ea11207..414a60a 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -353,10 +353,13 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t encoder_id)
* Connector manipulation
*/
-drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+static drmModeConnectorPtr doGetConnector(int fd, uint32_t connector_id,
+ int probe)
{
struct drm_mode_get_connector conn;
drmModeConnectorPtr r = NULL;
+ int cmd = probe ? DRM_IOCTL_MODE_GETCONNECTOR :
+ DRM_IOCTL_MODE_GETCONNECTOR_CURRENT;
conn.connector_id = connector_id;
conn.connector_type_id = 0;
@@ -369,7 +372,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
conn.count_encoders = 0;
conn.encoders_ptr = 0;
- if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, conn))
+ if (drmIoctl(fd, cmd, conn))
return 0;
if (conn.count_props) {
@@ -383,7 +386,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
if (conn.count_encoders)
conn.encoders_ptr = VOID2U64(drmMalloc(conn.count_encoders*sizeof(uint32_t)));
- if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, conn))
+ if (drmIoctl(fd, cmd, conn))
goto err_allocs;
if(!(r = drmMalloc(sizeof(*r {
@@ -420,6 +423,16 @@ err_allocs:
return r;
}
+drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+{
+ return doGetConnector(fd, connector_id, 1);
+}
+
+drmModeConnectorPtr drmModeGetConnectorCurrent(int fd, uint32_t connector_id)
+{
+ return doGetConnector(fd, connector_id, 0);
+}
+
int drmModeAttachMode(int fd, uint32_t connector_id, drmModeModeInfoPtr mode_info)
{
struct drm_mode_mode_cmd res;
diff --git a/libdrm/xf86drmMode.h b/libdrm/xf86drmMode.h
index 62304bb..98f9af1 100644
--- a/libdrm/xf86drmMode.h
+++ b/libdrm/xf86drmMode.h
@@ -337,6 +337,8 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t encoder_id);
*/
extern drmModeConnectorPtr drmModeGetConnector(int fd,
uint32_t connectorId);
+extern drmModeConnectorPtr drmModeGetConnectorCurrent(int fd,
+ uint32_t connectorId);
/**
* Attaches the given mode to an connector.
diff --git a/shared-core/drm.h b/shared-core/drm.h
index b97ba09..6ddcc5b 100644
--- a/shared-core/drm.h
+++ b/shared-core/drm.h
@@ -1107,7 +1107,7 @@ struct drm_gem_open {
#define DRM_IOCTL_MODE_GETFB DRM_IOWR(0xAD, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_ADDFB DRM_IOWR(0xAE, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_RMFB DRM_IOWR(0xAF, uint32_t)
-#define DRM_IOCTL_MODE_REPLACEFB DRM_IOWR(0xB0, struct drm_mode_fb_cmd)
+#define DRM_IOCTL_MODE_GETCONNECTOR_CURRENT DRM_IOWR(0xB0, struct drm_mode_fb_cmd)
/*...@}*/
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 15ffc29..08ce1a0 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -762,8 +762,8 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int num)
drmmode_output_private_ptr drmmode_output;
char name[32];
- koutput = drmModeGetConnector(drmmode-fd,
- drmmode-mode_res-connectors[num]);
+ koutput = drmModeGetConnectorCurrent(drmmode-fd,
+ drmmode-mode_res-connectors[num]);
if (!koutput)
return;
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: add drm_mode_getconnector_current function
This patch adds a get current info function for apps to use, probably
mostly at startup time when they just want to see what outputs are
available vs. detecting current status mode lists. Can help speed up
startup quite a bit in some configurations.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 94a7688..5d4732d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1209,24 +1209,31 @@ out:
}
/**
- * drm_mode_getconnector - get connector configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * do_mode_getconnector - get connector configuration
+ * @dev: DRM device
+ * @data: drm_mode_get_connector request
+ * @file_priv: file private
+ * @probe: probe for data?
*
* LOCKING:
- * Caller? (FIXME)
+ * Takes struct mutex.
*
* Construct a connector configuration structure to return to the user.
*
* Called by the user via ioctl.
*
+ * This will generally be called twice; once to get the count for the
+ * various structures and do probing, and then again to return the actual
+ * data.
+ *
+ * The @probe flag controls whether we should actually go probe all the
+ * outputs or just return the current data (e.g. from the last call).
+ *
* RETURNS:
* Zero on success, errno on failure.
*/
-int drm_mode_getconnector(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+static int do_mode_getconnector(struct drm_device *dev, void *data,
+ struct drm_file *file_priv, int probe)
{
struct drm_mode_get_connector *out_resp = data;
struct drm_mode_object *obj;
@@ -1270,7 +1277,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
}
}
- if (out_resp-count_modes == 0) {
+ if (out_resp-count_modes == 0 probe) {
connector-funcs-fill_modes(connector,
dev-mode_config.max_width,
dev-mode_config.max_height);
@@ -1355,6 +1362,46 @@ out:
return ret;
}
+/**
+ * drm_mode_getconnector - get connector configuration
+ * @dev: drm device
+ * @data: getconnector request structure
+ * @file_priv: file private
+ *
+ * LOCKING:
+ * None.
+ *
+ * Get connector information, by probing outputs.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_getconnector(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ return do_mode_getconnector(dev, data, file_priv, true);
+}
+
+/**
+ * drm_mode_getconnector_current - get current connector configuration
+ * @dev: DRM device
+ * @data: getconnector request structure
+ * @file_priv: file private
+ *
+ * LOCKING:
+ * None.
+ *
+ * Return connector data from the last probe.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_getconnector_current(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ return do_mode_getconnector(dev, data, file_priv, false);
+}
+
int drm_mode_getencoder(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c4ada8b..64bf784 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -137,6 +137,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_MASTER|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_MASTER|DRM_CONTROL_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR_CURRENT,
drm_mode_getconnector_current, DRM_MASTER|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl,
DRM_MASTER | DRM_CONTROL_ALLOW),
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 7cb50bd..75ba0b4 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -686,6 +686,7 @@ struct drm_gem_open {
#define DRM_IOCTL_MODE_GETFB DRM_IOWR(0xAD, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_ADDFB DRM_IOWR(0xAE, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_RMFBDRM_IOWR(0xAF, unsigned int)
+#define DRM_IOCTL_MODE_GETCONNECTOR_CURRENTDRM_IOWR(0xB0, struct
drm_mode_get_connector)
/**
* Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index
Re: [PATCH] mklib: cosmetic: use case instead of expr match
On Thu, Apr 30, 2009 at 3:57 PM, Brian Paul bri...@vmware.com wrote: Thanks. I'll commit this and your prev patch after a bit more testing... I have the other one queued up, I just didn't have time to give it a spin yet. If you can wait until tomorrow (later tonight actually), I'll push them. But if you're in a rush, I think they're safe to commit. -- Dan -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mklib: cosmetic: use case instead of expr match
Dan Nicholson wrote: On Thu, Apr 30, 2009 at 3:57 PM, Brian Paul bri...@vmware.com wrote: Thanks. I'll commit this and your prev patch after a bit more testing... I have the other one queued up, I just didn't have time to give it a spin yet. If you can wait until tomorrow (later tonight actually), I'll push them. But if you're in a rush, I think they're safe to commit. I found a few glitches with the static linux build but everything else seems OK. -Brian -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: do a faster EDID
On Tue, Mar 24, 2009 at 6:48 AM, Arjan van de Ven ar...@infradead.org wrote:
From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:37:20 -0700
Subject: [PATCH] KMS: do a faster EDID
for some outputs (like LVDS), the current delays in the EDID reader are way
overkill.
This patch makes the EDID reader try twice; first with a 5x faster probe, and
if that fails, it probes at the current speed. This reduces probe time on my
LVDS
panel significantly.
TBH I'd do DDC the first time with none of the setup crap in it.
Just call the DDC function.
If that fails then I'd go through all the sleeping path, which is mainly
for some bonghit monitors from the 90s.
So like the idea but I'd take it further.
Dave.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/drm_edid.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a839a28..069b189 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -588,20 +588,22 @@ static unsigned char *drm_ddc_read(struct i2c_adapter
*adapter)
{
struct i2c_algo_bit_data *algo_data = adapter-algo_data;
unsigned char *edid = NULL;
+ int divider = 5;
int i, j;
algo_data-setscl(algo_data-data, 1);
- for (i = 0; i 1; i++) {
+ for (i = 0; i 2; i++) {
/* For some old monitors we need the
* following process to initialize/stop DDC
*/
+
algo_data-setsda(algo_data-data, 1);
- msleep(13);
+ msleep(13 / divider);
algo_data-setscl(algo_data-data, 1);
for (j = 0; j 5; j++) {
- msleep(10);
+ msleep(10 / divider);
if (algo_data-getscl(algo_data-data))
break;
}
@@ -609,31 +611,33 @@ static unsigned char *drm_ddc_read(struct i2c_adapter
*adapter)
continue;
algo_data-setsda(algo_data-data, 0);
- msleep(15);
+ msleep(15 / divider);
algo_data-setscl(algo_data-data, 0);
- msleep(15);
+ msleep(15 / divider);
algo_data-setsda(algo_data-data, 1);
- msleep(15);
+ msleep(15 / divider);
/* Do the real work */
edid = drm_do_probe_ddc_edid(adapter);
algo_data-setsda(algo_data-data, 0);
algo_data-setscl(algo_data-data, 0);
- msleep(15);
+ msleep(15 / divider);
algo_data-setscl(algo_data-data, 1);
for (j = 0; j 10; j++) {
- msleep(10);
+ msleep(10 / divider);
if (algo_data-getscl(algo_data-data))
break;
}
algo_data-setsda(algo_data-data, 1);
- msleep(15);
+ msleep(15 / divider);
algo_data-setscl(algo_data-data, 0);
algo_data-setsda(algo_data-data, 0);
+
if (edid)
break;
+ divider = 1;
}
/* Release the DDC lines when done or the Apple Cinema HD display
* will switch off
--
1.6.0.6
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: 2.6.29.2 - AGP doesn't work anymore on my nforce2
On Thu, 30 Apr 2009 10:51:47 +0200
Karsten Mehrhoff kaw...@gmx.de wrote:
[1.]
PROBLEM: No more agp card functionality with the patch 2.6.29.2 of
'a/drivers/char/agp/generic.c'
[2.]
I compiled the kernel 2.6.29.2 with my .config of 2.6.29.1 and run into
problems with the speed of my ATI RADEON 9600 (rv350)
So we have a 2.6.29.1 - 2.6.29.2 regression.
...
Problematic patch:
//---
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -1226,7 +1226,7 @@ int agp_generic_alloc_pages(struct agp_bridge_data
*bridge, struct agp_memory *m
int i, ret = -ENOMEM;
for (i = 0; i num_pages; i++) {
-page = alloc_page(GFP_KERNEL | GFP_DMA32);
+page = alloc_page(GFP_KERNEL | GFP_DMA32 | __GFP_ZERO);
/* agp_free_memory() needs gart address */
if (page == NULL)
goto out;
@@ -1257,7 +1257,7 @@ void *agp_generic_alloc_page(struct agp_bridge_data
*bridge)
{
struct page * page;
-page = alloc_page(GFP_KERNEL | GFP_DMA32);
+page = alloc_page(GFP_KERNEL | GFP_DMA32 | __GFP_ZERO);
if (page == NULL)
return NULL;
---//
I reverted the patch back to 2.6.29.1, compiled and the kernel agian and agp
works ok.
Really? So reverting
: commit 59de2bebabc5027f93df999d59cc65df591c3e6e
: Author: Shaohua Li shaohua...@intel.com
: AuthorDate: Mon Apr 20 10:08:35 2009 +1000
: Commit: Dave Airlie airl...@redhat.com
: CommitDate: Mon Apr 20 10:08:35 2009 +1000
:
:agp: zero pages before sending to userspace
makes your AGP work properly?
That's really weird.
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon: fix front-buffer rendering
I have copied the changes from intel (to radeon) regarding
DRI2GetBuffersWithFormat. Patches for the ddx and mesa are attached. It
requires the xserver patch here
http://lists.x.org/archives/xorg-devel/2009-April/000779.html, as otherwise
I am getting white borders with compiz.
Together with the previous patches I sent, they should make radeon and dri2
work with master xserver. My test (compiz and glxgears) with new mesa, ddx,
but old xserver and dri2proto seemed to work fine as well (with the
exception of openarena locking up, but that was also happening with an older
server and none of my patches).
It needs 2 commits from master than radeon-rewrite doesn't have:
532716049249b4b8905ead7127c9aa2bcfc3f67e
7a95e4dd7d8377c964fe2ea79acb93fe612d8d0f
On Sat, Apr 25, 2009 at 11:48 AM, Joel Bosveld joel.bosv...@gmail.comwrote:
This fixes rendering when using dri2 (so, that means, radeon-rewrite and
radeon-gem-cs) and a near-master xserver (the front-buffer changes). It is
mostly just copied from the changes to intel.
One patch is for mesa, and the other for the ddx:
From 9e028a11b69361f82a3d578a2a3c14b3d7fc15fd Mon Sep 17 00:00:00 2001
From: Joel Bosveld joel.bosv...@gmail.com
Date: Sat, 25 Apr 2009 08:20:03 +0800
Subject: [PATCH] radeon: fix front-buffer rendering
---
src/mesa/drivers/dri/radeon/radeon_common.c| 27
.../drivers/dri/radeon/radeon_common_context.c |4 +++
.../drivers/dri/radeon/radeon_common_context.h | 16 +++
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c
b/src/mesa/drivers/dri/radeon/radeon_common.c
index dc281ee..9e5ea9d 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common.c
@@ -677,6 +677,7 @@ void radeon_draw_buffer(GLcontext *ctx, struct
gl_framebuffer *fb)
if (fb-_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT) {
rrbColor =
radeon_renderbuffer(fb-Attachment[BUFFER_FRONT_LEFT].Renderbuffer);
radeon-front_cliprects = GL_TRUE;
+radeon-front_buffer_dirty = GL_TRUE;
} else {
rrbColor =
radeon_renderbuffer(fb-Attachment[BUFFER_BACK_LEFT].Renderbuffer);
radeon-front_cliprects = GL_FALSE;
@@ -792,6 +793,12 @@ void radeonDrawBuffer( GLcontext *ctx, GLenum mode )
if (RADEON_DEBUG DEBUG_DRI)
fprintf(stderr, %s %s\n, __FUNCTION__,
_mesa_lookup_enum_by_nr( mode ));
+
+if (ctx-DrawBuffer-Name == 0) {
+radeonContextPtr radeon = RADEON_CONTEXT(ctx);
+
+radeon-is_front_buffer_rendering = (mode == GL_FRONT_LEFT);
+}
radeon_draw_buffer(ctx, ctx-DrawBuffer);
}
@@ -1005,6 +1012,26 @@ void radeonFlush(GLcontext *ctx)
if (radeon-cmdbuf.cs-cdw)
rcommonFlushCmdBuf(radeon, __FUNCTION__);
+
+if ((ctx-DrawBuffer-Name == 0) radeon-front_buffer_dirty) {
+__DRIscreen *const screen = radeon-radeonScreen-driScreen;
+
+if (screen-dri2.loader (screen-dri2.loader-base.version =
2)
+ (screen-dri2.loader-flushFrontBuffer != NULL)) {
+(*screen-dri2.loader-flushFrontBuffer)(radeon-dri.drawable,
+ radeon-dri.drawable-loaderPrivate);
+
+/* Only clear the dirty bit if front-buffer rendering is no
longer
+ * enabled. This is done so that the dirty bit can only be
set in
+ * glDrawBuffer. Otherwise the dirty bit would have to be set
at
+ * each of N places that do rendering. This has worse
performances,
+ * but it is much easier to get correct.
+ */
+if (radeon-is_front_buffer_rendering) {
+radeon-front_buffer_dirty = GL_FALSE;
+}
+}
+}
}
/* Make sure all commands have been sent to the hardware and have
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c
b/src/mesa/drivers/dri/radeon/radeon_common_context.c
index ba74c97..cfdf52c 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c
@@ -464,6 +464,10 @@ radeon_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
rb = draw-color_rb[0];
regname = dri2 front buffer;
break;
+case __DRI_BUFFER_FAKE_FRONT_LEFT:
+rb = draw-color_rb[0];
+regname = dri2 fake front buffer;
+break;
case __DRI_BUFFER_BACK_LEFT:
rb = draw-color_rb[1];
regname = dri2 back buffer;
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.h
b/src/mesa/drivers/dri/radeon/radeon_common_context.h
index d32e5af..0307c63 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.h
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.h
@@ -462,6 +462,22 @@ struct radeon_context {
