Re: TTM merging?
On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote: Static wc-d maps into fairly static objects like scanout buffers or buffer pools are not inefficient. They provide the by far highest throughput for writing (even beats cache-coherent). But they may take some time to set up or tear down, which means you should avoid that as much as possible. Yeah, the 2D driver uses the GTT mapping for drawing to the front buffer. Otherwise, tiling is way too much work as the code isn't neatly wrapped up like the Mesa swrast. For that, I just added detiling code. I'm not sure how I'd manage objects that can move or be evicted though; perhaps some page table tricks could be used to avoid locking objects to the GTT in a way visible to the user application. The current implementation of GEM that doesn't allow overloading of the core GEM functions blocked the possibility to set up such mappings. This is about to change, and I'm happy with that. The requirement is that GEM provide the interfaces used by drivers; if a driver needs some new functionality, we'd naturally work out how to incorporate that. Right now, our 3D drivers don't care about GTT maps, but I suspect our 2D ones will as I don't really want to try to deal with tiling from all of the X server drawing code. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM merging?
Keith Packard wrote: On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote: Static wc-d maps into fairly static objects like scanout buffers or buffer pools are not inefficient. They provide the by far highest throughput for writing (even beats cache-coherent). But they may take some time to set up or tear down, which means you should avoid that as much as possible. Yeah, the 2D driver uses the GTT mapping for drawing to the front buffer. Otherwise, tiling is way too much work as the code isn't neatly wrapped up like the Mesa swrast. For that, I just added detiling code. I'm not sure how I'd manage objects that can move or be evicted though; perhaps some page table tricks could be used to avoid locking objects to the GTT in a way visible to the user application. Yes, TTM does this by killing user-space mappings when an object is evicted. When they are again accessed by the app, they are simply faulted back mapping the new location wherever that is, changing caching policy if necessary. That approach is in principle reusable for a GEM implementation but I think not with the shmem backing objects, since we cannot overload the SHMEM fault() method, but that's only a limitiation of the current GEM implementation, not of the API design. One way to implement this in the GEM context I'd use the (small) part of drmBOs that deals with this, and use that as base GEM objects instead of SHMEMFS objects. Each GEM object would also always hold a page list. When the object has real pages attached to it (Like UMA objects) it would be populated with pages. When the object points to a place in VRAM, it holds swap_entry references (To reserve swap space used at suspend). If a GEM object, at creation, fails to allocate either pages or swap entries, object creation should fail to avoid failures later at unpredictable points. With this approach the GEM driver needs to decide when to push a GEM object's pages to the swap cache and when to reclaim them. It doesn't happen automatically as with the SMEMFS objects, but OTOH that puts the GEM driver in control on how much memory it will pin. That will avoid bad SHMEMFS decisions. The current implementation of GEM that doesn't allow overloading of the core GEM functions blocked the possibility to set up such mappings. This is about to change, and I'm happy with that. The requirement is that GEM provide the interfaces used by drivers; if a driver needs some new functionality, we'd naturally work out how to incorporate that. Right now, our 3D drivers don't care about GTT maps, but I suspect our 2D ones will as I don't really want to try to deal with tiling from all of the X server drawing code. Sounds good to me. Modesetting people will also be happy. /Thomas. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM merging?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Packard wrote: | On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote: | | As you've previously mentioned, this requires caching policy changes and | it needs to be used with some care. | | I did't need that in my drivers as GEM handles the WB - GPU object | transfer already. | | Object mapping is really the least important part of the system; it | should only be necessary when your GPU is deficient, or your API so | broken as to require this inefficient mechanism. I suspect we'll be | tracking 965 performance as we work to eliminate mapping, we should see | a steady increase until we're no longer mapping anything that the GPU | uses into the application's address space. Er...what about glMapBuffer? Are we now going to force drivers to implement that via copies? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFILGzGX1gOwKyEAw8RAhYRAJsF4k9TjewdZseLAvXPlibJdKChrwCgih0p L/D5WQlfEpN+DyDgYvOUA20= =wYa/ -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM merging?
On Thu, 2008-05-15 at 10:03 -0700, Ian Romanick wrote: Er...what about glMapBuffer? Are we now going to force drivers to implement that via copies? No, we'll support it, and make it as fast as possible. The goal is to not use it inside the driver, not to break GL apps. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM merging?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt schrieb: No. Gem can't coop with it. Let's say you have a 512M system with two 1G video cards, 4G swap space, and you want to fill both card's videoram with render-and-forget textures for whatever purpose. Who's selling that system? Who's building that system at home? Video game consoles? According to Wikipedia PS3 has 256 MB of RAM vs 256 MB of VRAM. Philipp P.S.: Even my ColecoVision, has 1 KB of RAM vs 16 KB of VRAM. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILHQVbtUV+xsoLpoRAsaLAJ0fXyrk1n4TE0m/egvm10uACnIxLwCgqjl3 BE0DdbGE1R61oBsbf/zi8cU= =nq1l -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #7 from Jie Luo [EMAIL PROTECTED] 2008-05-14 20:31:47 PST --- Created an attachment (id=16546) -- (http://bugs.freedesktop.org/attachment.cgi?id=16546) reg dump after resume -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #8 from Jie Luo [EMAIL PROTECTED] 2008-05-14 20:33:06 PST --- Created an attachment (id=16547) -- (http://bugs.freedesktop.org/attachment.cgi?id=16547) reg dump after resume and reload i915 kernel module -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #9 from Jie Luo [EMAIL PROTECTED] 2008-05-14 20:39:15 PST --- From the regdump, it seems some register not restore properly during resume. This maybe the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15945] New: [AvP1 Alien Demo (wine)] flickering artifacts
http://bugs.freedesktop.org/show_bug.cgi?id=15945 Summary: [AvP1 Alien Demo (wine)] flickering artifacts Product: Mesa Version: unspecified Platform: x86 (IA32) URL: http://bugs.winehq.org/show_bug.cgi?id=12944 OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Hi there, I'm referring to bug 12944 in the wine bugtracker. Please also see the URL for that. Problem is a flickering artifact during the intro sequence of the AvP1 Alien Demo. You can find a download link in the wine bugreport. This does not seem to be related to wine's D3D translation. It does NOT appear on nvidia cards (binary blob) and not with LIBGL_ALWAYS_INDIRECT=1 (software rendering). I could reproduce it on both a i915 chip with mesa GIT (and i915tex driver) and a i945 with mesa 6.5.2. The problem is nearly the same. On the i915 the artifacts shows only for a short time (see wine bugreport) and on the i945 during the full intro sequence. The problem also depends on how RenderTargetLockMode in wine it set. This dictates how wine modifies the framebuffer. I can only modify the i915 system, since I've no root access to the i945 system. Greetings, Tobias Jakobi -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] handling panic under X
The attached patches, which depend on kernel mode setting, will allow us to
see some kernel messages even if a panic occurs while X is running.
I think the approach is fairly sound (using a notifier to let mode setting
drivers switch the front buffer), but there are some details to be worked out
still:
- the console needs to be switched earlier on, probably in panic(), so we
don't lose messages (the current code will print stuff to VT8 until the
notifier gets called, so we lose the early stuff), but that should be easy
- abusing KD_TEXT for this purpose probably isn't right, I think we'll want
some smarts under KD_KERNEL_GRAPHICS for this (console layer hacking for
the above could be under a KD_KERNEL_GRAPHICS test)
- we definitely don't wait to wait on VT switch in the notifier, this means
more exporting of stuff from the console core and smarter handling
- the switch in the notifier should be more robust; we have some smarts in
the mode setting code to avoid a full mode reprogram, but we can
definitely be better about it so we don't rely on as much state being
preserved
Anyone have good thoughts on the above or approaches they think will work?
That said, it's pretty neat to insert a panic module, see the switch, then see
printks from the notifier...
One interesting side effect of running X in KD_TEXT mode is that messages
still get printed to the hidden fbcon, which means things like the root weave
paint run *really* slow if you're running the DRM modules in debug mode.
Jesse
diff --git a/src/i830_driver.c b/src/i830_driver.c
index 4109d88..436345c 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -174,10 +174,13 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include sys/mman.h
#include errno.h
+#include linux/kd.h
+
#include xf86.h
#include xf86_OSproc.h
#include xf86Resources.h
#include xf86RAC.h
+#include xf86Priv.h
#include xf86cmap.h
#include compiler.h
#include mibstore.h
@@ -1068,6 +1071,8 @@ static Bool i830_kernel_mode_enabled(ScrnInfoPtr pScrn)
if (ret)
return FALSE;
+ ioctl(xf86Info.consoleFd, KDSETMODE, KD_TEXT);
+
return TRUE;
}
#else
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index fa1ffbf..f53336f 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2401,6 +2401,7 @@ int set_console(int nr)
return 0;
}
+EXPORT_SYMBOL(set_console);
struct tty_driver *console_driver;
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 3211afd..395f2ab 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -26,6 +26,7 @@
#include linux/consolemap.h
#include linux/signal.h
#include linux/timex.h
+#include linux/module.h
#include asm/io.h
#include asm/uaccess.h
@@ -1203,6 +1204,7 @@ int vt_waitactive(int vt)
__set_current_state(TASK_RUNNING);
return retval;
}
+EXPORT_SYMBOL(vt_waitactive);
#define vt_wake_waitactive() wake_up(vt_activate_queue)
diff --git a/include/linux/kd.h b/include/linux/kd.h
index 15f2853..6fe4598 100644
--- a/include/linux/kd.h
+++ b/include/linux/kd.h
@@ -45,6 +45,7 @@ struct consolefontdesc {
#define KD_GRAPHICS 0x01
#define KD_TEXT0 0x02 /* obsolete */
#define KD_TEXT1 0x03 /* obsolete */
+#define KD_KERNEL_GRAPHICS 0x4 /* kernel will print panics, etc. */
#define KDGETMODE 0x4B3B /* get current mode */
#define KDMAPDISP 0x4B3C /* map display into address space */
diff --git a/linux-core/intel_fb.c b/linux-core/intel_fb.c
index 9934e3a..a43319d 100644
--- a/linux-core/intel_fb.c
+++ b/linux-core/intel_fb.c
@@ -566,6 +566,31 @@ int intelfb_resize(struct drm_device *dev, struct drm_crtc *crtc)
}
EXPORT_SYMBOL(intelfb_resize);
+static struct fb_info *panic_fb;
+
+extern int set_console(int nr);
+extern int vt_waitactive(int vt);
+
+int intelfb_panic(struct notifier_block *n, unsigned long ununsed,
+ void *panic_str)
+{
+ /* Force a switch back to our FB console */
+ panic_fb-var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
+ fb_set_var(panic_fb, panic_fb-var);
+
+ set_console(0);
+ vt_waitactive(0);
+
+ printk(KERN_ERR panic! switched back to text console\n);
+
+ return 0;
+}
+EXPORT_SYMBOL(intelfb_panic);
+
+static struct notifier_block paniced = {
+ .notifier_call = intelfb_panic,
+};
+
int intelfb_probe(struct drm_device *dev, struct drm_crtc *crtc, struct drm_output *output)
{
struct fb_info *info;
@@ -763,6 +788,11 @@ int intelfb_probe(struct drm_device *dev, struct drm_crtc *crtc, struct drm_outp
printk(KERN_INFO fb%d: %s frame buffer device\n, info-node,
info-fix.id);
+
+ /* Switch back to kernel console on panic */
+ panic_fb = info;
+ atomic_notifier_chain_register(panic_notifier_list, paniced);
+
return 0;
}
EXPORT_SYMBOL(intelfb_probe);
@@ -783,6 +813,9 @@ int intelfb_remove(struct drm_device *dev, struct drm_framebuffer *fb)
drm_framebuffer_destroy(fb);
framebuffer_release(info);
}
+
+ panic_fb = NULL;
+ atomic_notifier_chain_unregister(panic_notifier_list, paniced);
leaks in git mesa master
Hi, I encountered huge-grown memory leak in recently update and investigated by
valgrind.
The leak found in _tnl_UpdateFixedFunctionProgram that was 'state_key key' keep
created always.
==5636== 1,319,960 bytes in 32,999 blocks are definitely lost in loss record 63
of 65
==5636==at 0x4005B0E: calloc (vg_replace_malloc.c:397)
==5636==by 0x452ADD4: _mesa_calloc (imports.c:78)
==5636==by 0x458BF3A: _tnl_UpdateFixedFunctionProgram (t_vp_build.c:122)
==5636==by 0x44D9485: r300UpdateShaders (r300_state.c:2115)
==5636==by 0x44DCB38: r300RunTCLRender (r300_render.c:407)
==5636==by 0x4577262: _tnl_run_pipeline (t_pipeline.c:158)
==5636==by 0x45777E0: _tnl_draw_prims (t_draw.c:402)
==5636==by 0x4576594: vbo_save_playback_vertex_list (vbo_save_draw.c:220)
==5636==by 0x450CDC2: execute_list (dlist.c:5757)
==5636==by 0x451017D: _mesa_CallList (dlist.c:6841)
==5636==by 0x4565BBB: neutral_CallList (vtxfmt_tmp.h:298)
==5636==by 0x8049CC8: do_draw (in /usr/bin/glxgears)
diff --git a/src/mesa/tnl/t_vp_build.c b/src/mesa/tnl/t_vp_build.c
index 2b1eefe..e83d842 100644
--- a/src/mesa/tnl/t_vp_build.c
+++ b/src/mesa/tnl/t_vp_build.c
@@ -1573,6 +1573,9 @@ void _tnl_UpdateFixedFunctionProgram( GLcontext *ctx )
_mesa_reference_vertprog(ctx, ctx-VertexProgram._TnlProgram,
newProg);
}
+ else {
+ FREE(key);
+ }
_mesa_reference_vertprog(ctx, ctx-VertexProgram._TnlProgram, newProg);
_mesa_reference_vertprog(ctx, ctx-VertexProgram._Current, newProg);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10709] 2.6.26-rc2 hosed X?
http://bugzilla.kernel.org/show_bug.cgi?id=10709 --- Comment #1 from [EMAIL PROTECTED] 2008-05-15 22:57 --- In my email from above I mentioned that X behaves strangly and suspend/resume does not work. The latter seems to be solved with the patch from http://lkml.org/lkml/2008/5/13/188, the former with the patch as given above. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
