[git pull] drm v2.6.31 merge (part 1)
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains the Intel tree merge (merged properly I haven't rebased or touched it), which contains numerous GEM bugfixes + support for a new chipset. AMD patches for new r600 chipset support. A more flexible drm debugging system to decrease the firehose effect enabling drm debugging has, it also contains some paving the way patches for part 2 of the merge. It also contains one AGP patch for supporting those new chips, and a PNP patch to add a new interface that intel kms relies on now, all the signoffs for the pnp code should be correct. Part 2 will contains an initial radeon KMS driver and the TTM memory manager, its quite large so I don't want to include it all in this pull. The initial radeon KMS code enable switch will hide under staging for now for one driver release while we stabilise it in-tree, its not in a bad state but its a lot of new code and we'd hate for anyone to fall over it my accident. Its quite well separated from the old radeon code so shouldn't fall over too much. I'll send the part 2 pull early next week. Dave. drivers/char/agp/intel-agp.c | 16 +- drivers/gpu/drm/drm_bufs.c |3 +- drivers/gpu/drm/drm_edid.c | 74 + drivers/gpu/drm/drm_gem.c |2 +- drivers/gpu/drm/drm_hashtab.c |4 + drivers/gpu/drm/drm_mm.c | 165 +++-- drivers/gpu/drm/drm_modes.c| 18 +- drivers/gpu/drm/drm_stub.c | 15 + drivers/gpu/drm/i915/i915_dma.c| 67 ++-- drivers/gpu/drm/i915/i915_drv.h| 48 ++- drivers/gpu/drm/i915/i915_gem.c| 156 ++--- drivers/gpu/drm/i915/i915_gem_tiling.c | 152 drivers/gpu/drm/i915/i915_irq.c| 190 +- drivers/gpu/drm/i915/i915_reg.h| 616 ++- drivers/gpu/drm/i915/i915_suspend.c| 20 + drivers/gpu/drm/i915/intel_bios.c | 86 +- drivers/gpu/drm/i915/intel_bios.h | 101 +- drivers/gpu/drm/i915/intel_crt.c | 76 - drivers/gpu/drm/i915/intel_display.c | 645 ++-- drivers/gpu/drm/i915/intel_fb.c| 26 +- drivers/gpu/drm/i915/intel_hdmi.c | 33 ++- drivers/gpu/drm/i915/intel_lvds.c | 151 ++-- drivers/gpu/drm/i915/intel_sdvo.c | 110 -- drivers/gpu/drm/i915/intel_tv.c|3 + drivers/gpu/drm/radeon/r600_cp.c | 42 ++- drivers/gpu/drm/radeon/radeon_cp.c |2 +- drivers/gpu/drm/radeon/radeon_drv.h|1 + drivers/gpu/drm/via/via_dmablit.c |6 +- drivers/pnp/resource.c | 18 + include/drm/drmP.h | 126 --- include/drm/drm_hashtab.h |2 + include/drm/drm_mm.h | 90 + include/drm/drm_pciids.h |9 + include/linux/pnp.h|2 + 34 files changed, 2677 insertions(+), 398 deletions(-) create mode 100644 include/drm/drm_mm.h commit 3c24475c1e4e8d10e50df161d8c4f1d382997a7c Author: Jerome Glisse Date: Wed Apr 8 18:34:28 2009 +0200 drm: include kernel list header file in hashtab header Signed-off-by: Dave Airlie commit f2cb5d86e1af175a9b210241800f03a447f92621 Author: Jerome Glisse Date: Wed Apr 8 17:16:24 2009 +0200 drm: Export hash table functionality. add exports so TTM module can use these functions. Signed-off-by: Thomas Hellstrom Signed-off-by: Dave Airlie commit 249d6048ca98b5452105b0824abac1275661b8e3 Author: Jerome Glisse Date: Wed Apr 8 17:11:16 2009 +0200 drm: Split out the mm declarations in a separate header. Add atomic operations. this is a TTM preparation patch, it rearranges the mm and add operations needed to do mm operations in atomic context. Signed-off-by: Thomas Hellstrom Signed-off-by: Dave Airlie commit 715cbb05c935e8a4306a730d14a72d5af881523e Author: Alex Deucher Date: Fri Jun 12 15:55:44 2009 +1000 drm/radeon: add support for RV790. This adds the PCI IDs for the rv790 which are equiv to the rv770. Signed-off-by: Dave Airlie commit 2a71ebcd85bcc4d6607f577f23a491f796c30e82 Author: Alex Deucher Date: Fri Jun 12 15:53:10 2009 +1000 drm/radeon: add rv740 drm support. This adds drm support for the RV740 family of chips to the r600 support code. Signed-off-by: Dave Airlie commit fbe0efb869efde8d847ede3a925230ef88910086 Author: Kristian Høgsberg Date: Tue Jun 9 01:50:41 2009 +1000 drm_calloc_large: check right size, check integer overflow, use GFP_ZERO Previously we would check size instead of size * nmemb, and so would never hit the vmalloc path. Also add integer overflow check as in kcalloc, and allocate GFP_ZERO pages instead of memset()ing them. Signed-off-by: Kristian Høgsberg
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote: | On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin wrote: | > On the other hand, if there's no mechanism for implicitly flushing the | > GL command stream on window teardown, then whatever problems this error | > is designed to address can happen every time a window is closed. I | > would expect to find something in the spec that says "You must execute | > (SwapBuffers|Flush|Finish...) before destroying a bound window or | > such-and-such bad things can happen." Trivial test programs would have | > been failing since day one. | | Well usually when the window is torndown, we exit straight away afterwards, | normally you don't keep going... I don't think you have to keep going -- all you have to do is destroy the window when there are still GL commands that haven't been flushed. It looks like the same (or very similar) problem to me; what do you do with those commands that have been queued up for a now-nonexistent window? |... however the glean test case does another | test which opens a new window and rendering context and calls MakeCurrent | on it, thereby triggering the above failure case. esp after it has | done rendering | on the previous context and then blown away the window without flushing or | swapbuffers. I didn't trace the test, so I'm not fully confident about this, but it looks to me like this is the sequence of commands: Create window. Create rendering contexts. Make an RC current. Clear the buffer. Query the clear color. ReadPixels() to get the contents of the buffer. Destroy rendering contexts. (one RC is still current, so its destruction is postponed) Destroy window. ... A subsequent test does a MakeCurrent, which triggers the error. The ReadPixels() does an implicit flush. Since it's the last operation before the MakeCurrent, and it's synchronous, there should be no other commands remaining in the GL stream at the time of the MakeCurrent. If that's correct, it explains why this problem has never been detected before, and it suggests that there might still be an implementation bug to be tracked down. What's left in the queue, or is it marked nonempty even though it's really empty? I'm persuaded that the test should be changed, though. It's not reasonable to depend on the flushing behavior of ReadPixels to meet the requirements of the spec, since a minor modification of the test could cause things to start failing mysteriously. | > What happens when one X client destroys a window that another one is | > using for GL rendering? The destruction of the window has to be | > postponed until it's no longer bound to an RC, or the GL command queue | > has to be redirected to a black hole, or GL rendering has to be | > terminated by error somehow. Or something else. | | If the window is destroyed the app normally gets a SIGPIPE and dies soon | after. Really? That surprises me. For normal X apps, I would think it would just get an error delivered via the X protocol the next time it attempts to use the window ID. The GL case seems messier. Allen -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21864] Flightgear still asserts due to RADEON_MAX_TEXTURE_LEVELS on radeon-rewrite as of today
http://bugs.freedesktop.org/show_bug.cgi?id=21864 --- Comment #3 from Dave Airlie 2009-06-11 18:41:48 PST --- can you test with mesa master? (I merged rewrite and fixed this afterwards.) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
On Tue, 2009-06-09 at 18:46 -0700, Jesse Barnes wrote: > On Wed, 10 Jun 2009 09:06:47 +0800 > yakui_zhao wrote: > > > On Wed, 2009-06-10 at 06:35 +0800, Jesse Barnes wrote: > > > On Tue, 09 Jun 2009 15:16:53 -0700 > > > Eric Anholt wrote: > > > > > > > On Mon, 2009-06-08 at 08:52 +0800, yakui_zhao wrote: > > > > > On Fri, 2009-06-05 at 19:11 +0800, Eric Anholt wrote: > > > > > > On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote: > > > > > > > It is useful to get the register snapshot. > > > > > > > Add a debugfs I/F named "i915_reg" to dump the I915 register > > > > > > > snapshot. And this is created under the dri/0/ of debugfs. > > > > > > > The output format is similar to what we have done in UMS > > > > > > > mode. > > > > > > > > > > > > I don't think that all the decode and formatting of these > > > > > > registers should be in the kernel. Every time I've had to > > > > > > mess with register decode stuff for investigation, I've > > > > > > needed to extend the decode. Instead, we should expose the > > > > > > raw register values and make intel_reg_dumper in > > > > > > intel-gpu-tools that does the decode of actual meaning. > > > > > Sometimes we can see the register snapshot without using the > > > > > intel-gpu-tools. For example: in UMS mode we often get the > > > > > register snapshot several times in starting X. > > > > > > > > > > It will be good that we expose the raw register values and then > > > > > they are parsed by intel-gpu-tools if we need to extend the > > > > > decode. > > > > > > > > > > How about adding two debugfs I/F? One is to dump the raw > > > > > register snapshot(without decode and format). Another is what I > > > > > have done in the patch. > > > > > > > > No, I won't pull something that puts the decode in the kernel > > > > without a really good argument. Expose the register names and > > > > values. > > > > > > > > > > Yakui, have you experimented with just dumping the whole mmio range? > > > If that works ok we could just make intel-gpu-tools programs to > > > interpret the data in a chipset specific way... > > It seems that this is a good point. > > In this patch only the registers related with modesetting are dumped. > > > > Is it ok that the whole mmio range is divided into several parts? > > a. memory interface, instruction and interrupt control registers > > b. 3d debug registers > > c. modeset registers(display,pipe, etc). > > Yeah that would be ok too... At this point, bgamari's patch for debugfs register dumping looks good to me. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin wrote: > On Fri, Jun 12, 2009 at 06:58:44AM +1000, Dave Airlie wrote: > | All I've got is the glXMakeCurrent error to go on, > | GLXBadCurrentWindow is generated if there are pending GL commands for > | the previous context and the current drawable is a window that is > no > | longer valid. > > I'm unsure what the intent was there, because the GLX spec never defines > "valid" and uses it in several different ways. (For example, "valid" > PBuffers are different from "valid" windows are different from windows > with "valid" XIDs.) > > | Now if something was meant to implicitly flush the command stream on > | window teardown then how would this ever happen. > > On the other hand, if there's no mechanism for implicitly flushing the > GL command stream on window teardown, then whatever problems this error > is designed to address can happen every time a window is closed. I > would expect to find something in the spec that says "You must execute > (SwapBuffers|Flush|Finish...) before destroying a bound window or > such-and-such bad things can happen." Trivial test programs would have > been failing since day one. Well usually when the window is torndown, we exit straight away afterwards, normally you don't keep going, however the glean test case does another test which opens a new window and rendering context and calls MakeCurrent on it, thereby triggering the above failure case. esp after it has done rendering on the previous context and then blown away the window without flushing or swapbuffers. I'm not sure how many apps regularly teardown windows and contexts and restart them. In fact its been broken in the X server for a while (it would crash) and the only think I can make it happen with is the glean test case :) > What happens when one X client destroys a window that another one is > using for GL rendering? The destruction of the window has to be > postponed until it's no longer bound to an RC, or the GL command queue > has to be redirected to a black hole, or GL rendering has to be > terminated by error somehow. Or something else. If the window is destroyed the app normally gets a SIGPIPE and dies soon after. Dave. > > So my guess would still be that a mechanism has to exist, but maybe I've > missed the key phrases in the spec. > > Ian, your knowledge of this stuff is a lot more recent than mine . Any > advice? > > Allen > -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
On Fri, Jun 12, 2009 at 06:58:44AM +1000, Dave Airlie wrote: | All I've got is the glXMakeCurrent error to go on, | GLXBadCurrentWindow is generated if there are pending GL commands for |the previous context and the current drawable is a window that is no |longer valid. I'm unsure what the intent was there, because the GLX spec never defines "valid" and uses it in several different ways. (For example, "valid" PBuffers are different from "valid" windows are different from windows with "valid" XIDs.) | Now if something was meant to implicitly flush the command stream on | window teardown then how would this ever happen. On the other hand, if there's no mechanism for implicitly flushing the GL command stream on window teardown, then whatever problems this error is designed to address can happen every time a window is closed. I would expect to find something in the spec that says "You must execute (SwapBuffers|Flush|Finish...) before destroying a bound window or such-and-such bad things can happen." Trivial test programs would have been failing since day one. What happens when one X client destroys a window that another one is using for GL rendering? The destruction of the window has to be postponed until it's no longer bound to an RC, or the GL command queue has to be redirected to a black hole, or GL rendering has to be terminated by error somehow. Or something else. So my guess would still be that a mechanism has to exist, but maybe I've missed the key phrases in the spec. Ian, your knowledge of this stuff is a lot more recent than mine . Any advice? Allen -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 19763] ATI X1950Pro (R500). 3D Textures don't work
http://bugs.freedesktop.org/show_bug.cgi?id=19763 --- Comment #3 from Tormod Volden 2009-06-11 14:18:03 PST --- These messages will likely disappear if you update to latest git. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Switch suitable directRenderingType checks to have_gem instead
For operations requiring GEM interfaces in the kernel, and which do not
depend on whether the driver offers DRI2 to X applications.
I think I got all of the right tests, but additional eyeballs would be
appreciated here.
Signed-off-by: Keith Packard
---
src/i830_accel.c |2 +-
src/i830_display.c |2 +-
src/i830_memory.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/i830_accel.c b/src/i830_accel.c
index b365e3f..e9a4439 100644
--- a/src/i830_accel.c
+++ b/src/i830_accel.c
@@ -233,7 +233,7 @@ I830AccelInit(ScreenPtr pScreen)
pI830->accel_max_y = 2048;
}
/* Bump the pitch so that we can tile any pixmap we create. */
-if (pI830->directRenderingType >= DRI_DRI2)
+if (pI830->have_gem)
pI830->accel_pixmap_pitch_alignment = 512;
switch (pI830->accel) {
diff --git a/src/i830_display.c b/src/i830_display.c
index a7eafb9..6cacbe8 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -1045,7 +1045,7 @@ static void i830_modeset_ctl(xf86CrtcPtr crtc, int pre)
I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
struct drm_modeset_ctl modeset;
-if (pI830->directRenderingType <= DRI_NONE)
+if (!pI830->have_gem)
return;
modeset.crtc = intel_crtc->pipe;
diff --git a/src/i830_memory.c b/src/i830_memory.c
index 5e07213..b768cf7 100644
--- a/src/i830_memory.c
+++ b/src/i830_memory.c
@@ -410,7 +410,7 @@ i830_allocator_init(ScrnInfoPtr pScrn, unsigned long size)
* 5.4 or newer so we can rely on the lock being held after DRIScreenInit,
* rather than after DRIFinishScreenInit.
*/
-if (pI830->directRenderingType == DRI_DRI2) {
+if (pI830->have_gem) {
int mmsize;
/* Take over all of the graphics aperture minus enough to for
--
1.6.3.1
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17098] 3D textures don't work on R300/R400/R500 DRI
http://bugs.freedesktop.org/show_bug.cgi?id=17098 Aditya Kadambi changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Aditya Kadambi 2009-06-11 14:03:49 PST --- Fixed in F11 Mesa 7.5-Devel -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 19763] ATI X1950Pro (R500). 3D Textures don't work
http://bugs.freedesktop.org/show_bug.cgi?id=19763 --- Comment #2 from Aditya Kadambi 2009-06-11 14:03:00 PST --- Just got F11 and tested it. It has Mesa 7.5-devel and 3D textures work. I just see this output. I assume this is just debug output for developers? I see this for any OpenGL code: Even for all mesa demo programs. So, if I don't hear otherwise, I will go ahead and mark this as fixed? CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
On Fri, Jun 12, 2009 at 5:33 AM, Allen Akin wrote: > On Thu, Jun 11, 2009 at 11:58:41AM -0600, Brian Paul wrote: > | Dave Airlie wrote: > | > The other open question is whether the glFinish in the glean test case > | > is actually necessary, > | > from reading the glXMakeCurrent manpage is appears it might be, or > something > | > else needs to make sure outstanding GL commands on the context are > | > flushed before > | > the window is destroyed. > | > | Do you have a patch for glean? Off-hand, I don't think adding a > | glFinish() would contradict the intention of the makeCurrent test - so > | the change sounds OK to me. > > I took a quick look at the docs and the test. > > The X and GL command streams aren't synchronized, so executing a > glFinish() isn't enough to guarantee that a drawable isn't shot down > while there are still GL commands pending. And any X client can destroy > the drawable independently, regardless of the GL commands in the queues > of other clients. > > If a glFinish() were required, in general, before destroying a drawable > or an RC, then that would be compelling. But I don't see any evidence > in the specs that that's the case. Thanks Allen. All I've got is the glXMakeCurrent error to go on, GLXBadCurrentWindow is generated if there are pending GL commands for the previous context and the current drawable is a window that is no longer valid. Now if something was meant to implicitly flush the command stream on window teardown then how would this ever happen. Things that marked GL as flushed in the X code are CopyContext SwapBuffers CopySubBuferMESA Flush Finish so destroying a window without calling one of these and then expecting to make current without an error seems to be what would throw those errors. However I'm not sure if there is some other operations we need to be setting the commands as flushed on. Dave. > > So a call to glFinish() in the test shouldn't be needed. It's not > sufficient by itself, and historically it doesn't seem to have been > necessary. Some other mechanism needs to be in place to make sure the > GL command queue is flushed. > > Of course I'm jumping in here, so I may have missed the point, in which > case my apologies. > > Allen > -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
On Thu, Jun 11, 2009 at 11:58:41AM -0600, Brian Paul wrote: | Dave Airlie wrote: | > The other open question is whether the glFinish in the glean test case | > is actually necessary, | > from reading the glXMakeCurrent manpage is appears it might be, or something | > else needs to make sure outstanding GL commands on the context are | > flushed before | > the window is destroyed. | | Do you have a patch for glean? Off-hand, I don't think adding a | glFinish() would contradict the intention of the makeCurrent test - so | the change sounds OK to me. I took a quick look at the docs and the test. The X and GL command streams aren't synchronized, so executing a glFinish() isn't enough to guarantee that a drawable isn't shot down while there are still GL commands pending. And any X client can destroy the drawable independently, regardless of the GL commands in the queues of other clients. If a glFinish() were required, in general, before destroying a drawable or an RC, then that would be compelling. But I don't see any evidence in the specs that that's the case. So a call to glFinish() in the test shouldn't be needed. It's not sufficient by itself, and historically it doesn't seem to have been necessary. Some other mechanism needs to be in place to make sure the GL command queue is flushed. Of course I'm jumping in here, so I may have missed the point, in which case my apologies. Allen -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
Dave Airlie wrote: >> So glXMakeCurrent says >> >> GLXBadCurrentWindow is generated if there are pending GL commands for >> the previous context and the current drawable is a window that is no >> longer valid. >> >> This appears to be true, we don't seem to have cleared all the pending >> GL commands >> before, so we get this error. >> >> Adding a glFinish into the glean test exit path, gets it past this, >> but I've no idea if this is correct. >> >> I then hit a GLXBadContext soon afterwards which suggest something >> more is going wrong. >> >> Probably need someone with some knowledge of GLX to tell me more. > > Okay attached two patches (one is a resend of some previous work - its > in radeon-rewrite). > > With these in mesa and a glFinish in the tbinding.cpp glean no longer > dies in the > makeCurrent test case. > > However Brian you had a comment in dri_util.c about not unbinding > things properly > due to swapbuffers on an unbound window, can you put a glean test > together for that? Hmmm, that comment is from a long time ago and I don't remember the details. I'm not sure glean's infrastructure will support testing swapbuffers on an unbound window. I don't have time right now to dig into it. One of the mesa/progs/xdemos/* examples might be hacked to test that. > so we can test it properly, as the hack that was in place seems to not > be the best idea. > Holding a pointer to a drawable object with no reference on it is > definitely a path to > accessing freed memory. > > The other open question is whether the glFinish in the glean test case > is actually necessary, > from reading the glXMakeCurrent manpage is appears it might be, or something > else needs to make sure outstanding GL commands on the context are > flushed before > the window is destroyed. Do you have a patch for glean? Off-hand, I don't think adding a glFinish() would contradict the intention of the makeCurrent test - so the change sounds OK to me. Otherwise, your patches look OK to me. Thanks! -Brian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21785] [945gm]X crash when enable or disable compiz
http://bugs.freedesktop.org/show_bug.cgi?id=21785 --- Comment #4 from Gordon Jin 2009-06-11 10:16:11 PST --- Haien, does this still exist? How about 7.5 branch? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ 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 yury changed: What|Removed |Added CC||ury...@gmail.com --- Comment #12 from yury 2009-06-11 16:09:49 --- confirmed for 2.6.30 acer travelmate 4051, intel 855GM -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22195] app crashed to desktop with Radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=22195 --- Comment #5 from Tormod Volden 2009-06-11 03:42:23 PST --- > I will also try 2.6.30, as far as i can tell, that drm patch was incorporated into 2.6.30 right? Yes, in 2.6.30 final, but not in the release candidates. So you will have to wait for the Ubuntu version 2.6.30-9.10 (or use an up to date kernel from somewhere else). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22195] app crashed to desktop with Radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=22195 --- Comment #4 from Tormod Volden 2009-06-11 03:28:06 PST --- > so what do i install? or do i install all of them? You only have to replace the packages which you already have installed, adding the PPA repository and an "software update" should do this for you. (The packages in question are also listed in the "Uninstalling" section of the PPA page.) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22195] app crashed to desktop with Radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=22195 --- Comment #3 from dre 2009-06-11 01:48:09 PST --- ok , i will run from a terminal and post output. I will also try 2.6.30, as far as i can tell, that drm patch was incorporated into 2.6.30 right? For radeon-rewrite, do you mean this: https://launchpad.net/~xorg-edgers/+archive/radeon I read through https://help.launchpad.net/Packaging/PPA#Adding%20a%20PPA%20to%20your%20Ubuntu%20repositories but im still a little unsure of what *exactly* to install, there seem to be many .deb packages, for example: libgl1-mesa-swx11-dbg_7.6.0 libgl1-mesa-swx11_7.6.0 libosmesa6-dev_7.6.0 so what do i install? or do i install all of them? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #5 from Alex Bennee 2009-06-11 01:11:36 PST --- Correction: The monitor is attached to TMDS-1, VGA is connected but turned off 09:03 a...@danny/x86_64 [video_freeze.report] >xrandr Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 2048 x 2048 VGA connected (normal left inverted right x axis y axis) 1440x900 59.9 + 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 TMDS-1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 459mm x 296mm 1680x1050 59.9*+ 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22226] New: [945] DRI memory manager reports 18014398509481940 kB
http://bugs.freedesktop.org/show_bug.cgi?id=6 Summary: [945] DRI memory manager reports 18014398509481940 kB Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Intel AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: a...@store20.com Xorg.0.log: [snip] (II) AIGLX: Resuming AIGLX clients after VT switch (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x-0x4fff: DRI memory manager (18014398509481940 kB) (II) intel(0): 0x:end of aperture (II) intel(0): BO memory allocation layout: (II) intel(0): 0x:start of memory manager (II) intel(0): 0x00c0-0x00ff: front buffer (4096 kB) X tiled (II) intel(0): 0x00b0-0x00b09fff: HW cursors (40 kB) (II) intel(0): 0x5000:end of memory manager [/snip] Chipset: 945GM (--) PCI:*(0...@0:2:0) Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xee10/524288, 0xd000/268435456, 0xee20/262144, I/O @ 0x1800/8 (--) PCI: (0...@0:2:1) Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xee18/524288 Kernel: 2.6.30 Arch: x86_64 Distro: Gentoo Machine: Lenovo x60s (Thinkpad) x11-libs/libdrm-2.4.11 media-libs/mesa-7.4.2 x11-base/xorg-server-1.6.1.901-r3 x11-drivers/xf86-video-intel-2.7.1 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 Alex Bennee 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. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #4 from Alex Bennee 2009-06-11 01:04:46 PST --- Created an attachment (id=26662) --> (http://bugs.freedesktop.org/attachment.cgi?id=26662) Backtrace of hung X session It looks like the ioctl is not completing. I assume the fact the address is post ioctl when I use GDB is because the ioctl does exit with EAGAIN and libc will re-attempt the ioctl when restarted. I'm afraid I didn't have debug symbols at the time. I'll try and re-create once I've rebuilt the DRM component. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #3 from Alex Bennee 2009-06-11 01:01:12 PST --- Created an attachment (id=26661) --> (http://bugs.freedesktop.org/attachment.cgi?id=26661) Full lscpi output for my system -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #2 from Alex Bennee 2009-06-11 01:00:48 PST --- Created an attachment (id=26660) --> (http://bugs.freedesktop.org/attachment.cgi?id=26660) intel gpu dump, post freeze I'm afraid I had to bzip2 this as it's too big for bugzilla -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 --- Comment #1 from Alex Bennee 2009-06-11 00:59:24 PST --- Created an attachment (id=26659) --> (http://bugs.freedesktop.org/attachment.cgi?id=26659) dmesg output -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22225] New: [945G/GZ KMS] Xorg hangs when video is full-screened
http://bugs.freedesktop.org/show_bug.cgi?id=5 Summary: [945G/GZ KMS] Xorg hangs when video is full-screened Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: bugzi...@bennee.com Created an attachment (id=26658) --> (http://bugs.freedesktop.org/attachment.cgi?id=26658) Xorg log with Mode Debug enabled Running with KMS enabled X will hang when I attempt to fullscreen an mplayer/totem video playing. It seems to be stuck in an ioctl in libdrm. -- chipset: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) -- system architecture: x86_64 -- xf86-video-intel: 2.7.1 -- xserver: 1.6.1.901-r3 -- mesa: 7.4.2 -- libdrm: 2.4.11 -- kernel: 2.6.30-rc8-intel-drm-00023-g34c8638 (intel-drm-next tree) -- Linux distribution: Gentoo -- Machine or mobo model: Efficient PC ASUS (ICH7) -- Display connector: LVDS/DVI Reproducing steps: Play a video with mplayer and hit "f" to full screen the display Additional info: I noticed that the GDM start-up looks a little odd. While full screen is enabled the graphics only fit in the top left 3/4s of the screen as though GDM is confused about the screen resolution. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22195] app crashed to desktop with Radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=22195 Michel Dänzer changed: What|Removed |Added AssignedTo|xorg-driver-...@lists.x.org |dri- ||de...@lists.sourceforge.net Component|Driver/Radeon |Drivers/DRI/r300 Product|xorg|Mesa QAContact|xorg-t...@lists.x.org | --- Comment #2 from Michel Dänzer 2009-06-11 00:30:38 PST --- (In reply to comment #1) > Does the drm patch in bug 21849 help? That's about lockups, but this sounds like just an app / GL driver crash... Andreas, we need more information about the crash, ideally a backtrace, but at least any output from the game / Wine. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
