[rfc] cache flush avoidance..
So in an attempt to avoid flushes on remap etc, I've attempt to avoid doing anymore than 1 cache flush per batchbuffer.. http://people.freedesktop.org/~airlied/i915-hack-cacheflush.txt I allocate the batchbuffers CACHED and then flush the cache for those pages post relocating.. I need to checkout the speedups on SMP machines as the ipi overheards are much worse there... this code is a dirty hack as it does x86 specifics in the drm, but I'm just throwing the idea out there.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Initial 915 superioctl patch.
Dave Airlie wrote: On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: Neither 42 nor 256 are very good - the number needs to be dynamic. Think about situations where an app has eg. one glyph per texture and is doing font rendering... Or any reasonably complex game might use 256 textures in a frame. So maybe the buffer count should be part of the execbuffer request object? Or does it have to be a separate settable parameter? I would think the kernel needs to limit this in some way... as otherwise we are trusting a userspace number and allocating memory according to it... So I'll make it dynamic but I'll have to add a kernel limit.. keithw: btws poulsbo uses 256 I think also.. Hmm, yes. Although that has been bumped recently it could be changed to dynamic, though, but as Dave says, we need to impose some kind of limit to avoid DOS. Poulsbo is still using a buffer list from user-space, and there's an internal kernel array that imposes this limit. What's a bit different, though, is that the number of relocs is fixed (by user space using a fixed-size shared memory buffer for the relocs). This is based on the assumption that user space will know how many relocs a code-block will issue, and if the limit is going to be hit, it can flush its command buffers. While I believe this is OK for Poulsbo (although complicating things), what about i915 zone rendering? Keith? /Thomas Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo weird error, please help
On Tue, 2007-10-09 at 00:07 +0800, Alec Liu wrote: glxinfo: ../common/xmlconfig.c:110: findOption: Assertion `i size' failed. Aborted Can you run in gdb and get a backtrace? Preferably with debugging symbols. As pointed out by Jérôme, please provide any /etc/drirc and/or ~/.drirc files. Does it also happen if you start X with only one screen section enabled in xorg.conf? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] post superioctl inteface removal.
Dave Airlie wrote: Hi, Once the 915 super ioctl is merged, the patch attached removes the unused interfaces left behind... Are any of these worth saving? Dave. Dave, As mentioned previously to Eric, I think we should keep the single buffer validate interface with the exception that the hint DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin interface. We can perhaps rename it to drmBOSetStatus or something more suitable. This will get rid of the user-space unfenced list access (which I believe was the main motivation behind the set pin interface?) while keeping the currently heavily used (at least in Poulsbo) functionality to move out NO_EVICT scanout buffers to local memory before unpinning them, (to avoid VRAM and TT fragmentation, as DRI clients may still reference those buffers, so they won't get destroyed before a new one is allocated). It would also allow us to specify where we want to pin buffers. If we remove the memory flag specification from drmBOCreate there's no other way to do that, except running the buffer through a superioctl which isn't very nice. Also it would make it much easier to unbreak i915 zone rendering and derived work. If we can agree on this, I'll come up with a patch. /Thomas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12731] dri is disabled with i915 driver
http://bugs.freedesktop.org/show_bug.cgi?id=12731 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12731] dri is disabled with i915 driver
http://bugs.freedesktop.org/show_bug.cgi?id=12731 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12749] New: ATI X1650 pro
http://bugs.freedesktop.org/show_bug.cgi?id=12749 Summary: ATI X1650 pro Product: DRI Version: XOrg CVS Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] saphire Ati x1650 or X1650 pro is not dected on suse linux 10.2 - 10.3 suse keeps on finding it as frame buffer graphics. Is there a way to fix this if so can you send me the Repository if there is one -- Configure bugmail: http://bugs.freedesktop.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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Initial 915 superioctl patch.
[updated patch attached]
Hmm, yes. Although that has been bumped recently it could be changed to
dynamic, though, but as Dave says,
we need to impose some kind of limit to avoid DOS.
Poulsbo is still using a buffer list from user-space, and there's an
internal kernel array that imposes this limit.
Okay the attached patch lets it dynamic up to 4096, and in theory we could
make it a module parameter or settable via /sys, and possibly add a
getparam for userspace to figure out what the limit is...
What's a bit different, though, is that the number of relocs is fixed
(by user space using a fixed-size
shared memory buffer for the relocs).
What I've done for the reloc numbers is allowed for one reloc per 4-dwords
in a batchbuffer in my Mesa code, and allocated that side.. granted it may
not be that accurate it was just a rough heuristic..
However I have allowed for chaining reloc buffers in the interface if not
in the implementation, if you look are relocation buffer header, the first
word is the relocation count and type of relocation and the second word is
the buffer handle for another buffer of relocations... if this word
contains !zero the code will look it another buffer of relocations.. I
originally meant this for having different types of relocations but I
could see how userspace could abuse this to get what you mentioned..
Dave.diff --git a/linux-core/drm_bo.c b/linux-core/drm_bo.c
index 4e73577..27bca52 100644
--- a/linux-core/drm_bo.c
+++ b/linux-core/drm_bo.c
@@ -1563,7 +1563,6 @@ int drm_bo_handle_validate(struct drm_file * file_priv,
uint32_t handle,
*bo_rep = bo;
else
drm_bo_usage_deref_unlocked(bo);
-
return ret;
}
EXPORT_SYMBOL(drm_bo_handle_validate);
diff --git a/linux-core/i915_buffer.c b/linux-core/i915_buffer.c
index 75763e7..f3ba7ce 100644
--- a/linux-core/i915_buffer.c
+++ b/linux-core/i915_buffer.c
@@ -42,7 +42,7 @@ int i915_fence_types(struct drm_buffer_object *bo,
uint32_t * fclass,
uint32_t * type)
{
- if (bo-mem.flags (DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE))
+ if (bo-mem.mask (DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE))
*type = 3;
else
*type = 1;
diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c
index 3a9ecab..eeb6085 100644
--- a/shared-core/i915_dma.c
+++ b/shared-core/i915_dma.c
@@ -147,6 +147,10 @@ static int i915_initialize(struct drm_device * dev,
return -EINVAL;
}
+#ifdef I915_HAVE_BUFFER
+ dev_priv-max_validate_buffers = I915_MAX_VALIDATE_BUFFERS;
+#endif
+
dev_priv-sarea_priv = (drm_i915_sarea_t *)
((u8 *) dev_priv-sarea-handle + init-sarea_priv_offset);
@@ -725,6 +729,344 @@ static int i915_cmdbuffer(struct drm_device *dev, void
*data,
return 0;
}
+struct i915_relocatee_info {
+ struct drm_buffer_object *buf;
+ unsigned long offset;
+ u32 *data_page;
+ unsigned page_offset;
+ struct drm_bo_kmap_obj kmap;
+ int is_iomem;
+};
+
+static void i915_dereference_buffers_locked(struct drm_buffer_object **buffers,
+ unsigned num_buffers)
+{
+ while (num_buffers--)
+ drm_bo_usage_deref_locked(buffers[num_buffers]);
+}
+
+int i915_apply_reloc(struct drm_file *file_priv, int num_buffers,
+struct drm_buffer_object **buffers,
+struct i915_relocatee_info *relocatee,
+uint32_t *reloc)
+{
+ unsigned index;
+ unsigned long new_cmd_offset;
+ u32 val;
+ int ret;
+
+ if (reloc[2] = num_buffers) {
+ DRM_ERROR(Illegal relocation buffer %08X\n, reloc[2]);
+ return -EINVAL;
+ }
+
+ new_cmd_offset = reloc[0];
+ if (!relocatee-data_page ||
+ !drm_bo_same_page(relocatee-offset, new_cmd_offset)) {
+ drm_bo_kunmap(relocatee-kmap);
+ relocatee-offset = new_cmd_offset;
+ ret = drm_bo_kmap(relocatee-buf, new_cmd_offset PAGE_SHIFT,
+ 1, relocatee-kmap);
+ if (ret) {
+ DRM_ERROR(Could not map command buffer to apply
relocs\n %08lx, new_cmd_offset);
+ return ret;
+ }
+
+ relocatee-data_page = drm_bmo_virtual(relocatee-kmap,
+ relocatee-is_iomem);
+ relocatee-page_offset = (relocatee-offset PAGE_MASK);
+ }
+
+ val = buffers[reloc[2]]-offset;
+ index = (reloc[0] - relocatee-page_offset) 2;
+
+ /* add in validate */
+ val = val + reloc[1];
+
+ relocatee-data_page[index] = val;
+ return 0;
+}
+
+int i915_process_relocs(struct drm_file *file_priv,
+ uint32_t buf_handle,
+ uint32_t *reloc_buf_handle,
+
Re: [patch] post superioctl inteface removal.
Dave, As mentioned previously to Eric, I think we should keep the single buffer validate interface with the exception that the hint DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin interface. We can perhaps rename it to drmBOSetStatus or something more suitable. This will get rid of the user-space unfenced list access (which I believe was the main motivation behind the set pin interface?) while keeping the currently heavily used (at least in Poulsbo) functionality to move out NO_EVICT scanout buffers to local memory before unpinning them, (to avoid VRAM and TT fragmentation, as DRI clients may still reference those buffers, so they won't get destroyed before a new one is allocated). It would also allow us to specify where we want to pin buffers. If we remove the memory flag specification from drmBOCreate there's no other way to do that, except running the buffer through a superioctl which isn't very nice. Also it would make it much easier to unbreak i915 zone rendering and derived work. If we can agree on this, I'll come up with a patch. I'm quite happy to have this type of interface I can definitely see its uses.. we also need to investigate some sort of temporary NO_MOVE like interface (the NO_MOVE until next fencing...) in order to avoid relocations, but it might be possible to make this driver specific.. Keith P also had an idea for relocation avoidance in the simple case which I've allowed for in my interface, we could use the 4th uint32_t in the relocation to pass in the value we've already written and only relocate it if the buffers location changes, so after doing one superioctl, the validated offsets would be passed back to userspace and used by it and we only have to relocate future buffers if the buffers move.. Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] post superioctl inteface removal.
Dave Airlie wrote: Dave, As mentioned previously to Eric, I think we should keep the single buffer validate interface with the exception that the hint DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin interface. We can perhaps rename it to drmBOSetStatus or something more suitable. This will get rid of the user-space unfenced list access (which I believe was the main motivation behind the set pin interface?) while keeping the currently heavily used (at least in Poulsbo) functionality to move out NO_EVICT scanout buffers to local memory before unpinning them, (to avoid VRAM and TT fragmentation, as DRI clients may still reference those buffers, so they won't get destroyed before a new one is allocated). It would also allow us to specify where we want to pin buffers. If we remove the memory flag specification from drmBOCreate there's no other way to do that, except running the buffer through a superioctl which isn't very nice. Also it would make it much easier to unbreak i915 zone rendering and derived work. If we can agree on this, I'll come up with a patch. I'm quite happy to have this type of interface I can definitely see its uses.. we also need to investigate some sort of temporary NO_MOVE like interface (the NO_MOVE until next fencing...) in order to avoid relocations, but it might be possible to make this driver specific.. Keith P also had an idea for relocation avoidance in the simple case which I've allowed for in my interface, we could use the 4th uint32_t in the relocation to pass in the value we've already written and only relocate it if the buffers location changes, so after doing one superioctl, the validated offsets would be passed back to userspace and used by it and we only have to relocate future buffers if the buffers move.. Theoretically the kernel could keep the relocation lists for each buffer hanging around after use and do this automatically if a buffer is reused, and the buffers that its relocations point to have been moved. That would be a good approach for one sort of buffer reuse, ie persistent state object buffers that are reused over multiple frames but contain references to other buffers. Note that it only makes sense to reuse relocations in situations where those relocations target a small number of buffers - probably other command buffers or buffers containing state objects which themselves make no further reference to other buffers. Trying to go beyond that, eg to reuse buffers of state objects that contain references to texture images, can lead to a major waste of resources. If you think about a situation with a buffer of 50 texture state objects, each referencing 4 texture images, and you just want to reuse one of those state objects -- you will emit a relocation to that state buffer, which will need to be validated and then should recursively require all 200 texture images to be validated, even if you only needed access to 4 of them... The pre-validate/no-move/whatever thing is a useful optimization, but it only makes sense up to a certain level - a handful of command, indirect state and/or vertex buffers is pretty much it. Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] cache flush avoidance..
Dave Airlie wrote: So in an attempt to avoid flushes on remap etc, I've attempt to avoid doing anymore than 1 cache flush per batchbuffer.. http://people.freedesktop.org/~airlied/i915-hack-cacheflush.txt I allocate the batchbuffers CACHED and then flush the cache for those pages post relocating.. I need to checkout the speedups on SMP machines as the ipi overheards are much worse there... this code is a dirty hack as it does x86 specifics in the drm, but I'm just throwing the idea out there.. Dave. Dave, I like the idea of moving over to clflush, but I still think we shouldn't use TT drmBOs for batch buffers and buffers with similar use. (i915tex uses a sub-allocator for batch buffers, which avoids the cache flushes completely during normal rendering). I think something similar should be used from the X server. /Thomas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] cache flush avoidance..
Dave, I like the idea of moving over to clflush, but I still think we shouldn't use TT drmBOs for batch buffers and buffers with similar use. (i915tex uses a sub-allocator for batch buffers, which avoids the cache flushes completely during normal rendering). I think something similar should be used from the X server. However you weren't doing in-kernel relocations.. ioremap/iounmap are both causing flushes... so we would need to keep ioremapped cached copies of the batchbuffer bo around.. which wastes vmalloc space.. or use kmap and flush once per buffer.. my previous attempts to use kmap without flushing failed badly.. Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] cache flush avoidance..
Dave Airlie wrote:
Dave,
I like the idea of moving over to clflush, but I still think we
shouldn't use TT drmBOs for batch buffers and buffers with similar use.
(i915tex uses a sub-allocator for batch buffers, which avoids the cache
flushes completely during normal rendering).
I think something similar should be used from the X server.
However you weren't doing in-kernel relocations.. ioremap/iounmap are
both causing flushes... so we would need to keep ioremapped cached
copies of the batchbuffer bo around.. which wastes vmalloc space.. or
use kmap and flush once per buffer.. my previous attempts to use kmap
without flushing failed badly..
Dave.
Ah, OK. I see what you mean.
So I know the Intel docs states that you must not access GART-mapped
pages in CMA mode, but they don't say why.
Are you using this mode for the kmap / flush mode?
Since Poulsbo is CMA, to avoid the SMP ipi issue, it should be possible
to enclose the whole reloc fixup within a spinlock and use
kmap_atomic which should be faster than kmap.
Since within a spinlock, also preemption is disabled we can guarantee
that a batchbuffer write followed by a clflush executes on the same
processor = no need for ipi, and the clflush can follow immediately
after a write.
We've used this technique in psb_mmu.c, although we're using
preempt_disable() / preempt_enable() to collect per-processor clflushes.
So, basically something like the following should be a fast ipi-free way
to do this:
spin_lock()
while(more_relocs_to_do) {
kmap_atomic(dst_buffer); // Reuse old map if same page
apply_reloc():
clflush(newly_written_address);
kunmap_atomic(dst_buffer);
}
spin_unlock();
/Thomas
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo weird error, please help
On Mon, 08 Oct 2007 19:15:49 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: Alec Liu wrote: i am using the gentoo i did compile everything (...) I would say reemerge mesa but i don't know gentoo you would better ask gentoo people on irc on others place where they give support. Alec, could you send us the output of : emerge -p xorg-server mesa In the meantime, you can try recompiling those two things : emerge mesa emerge xorg-server BTW gentoo support is at https://bugs.gentoo.org/ :) Cheers khaqq - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo weird error, please help
emerge -p xorg-server mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-7.0.1 [ebuild R ] x11-base/xorg-server-1.4-r2 On 10/10/07, khaqq [EMAIL PROTECTED] wrote: On Mon, 08 Oct 2007 19:15:49 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: Alec Liu wrote: i am using the gentoo i did compile everything (...) I would say reemerge mesa but i don't know gentoo you would better ask gentoo people on irc on others place where they give support. Alec, could you send us the output of : emerge -p xorg-server mesa In the meantime, you can try recompiling those two things : emerge mesa emerge xorg-server BTW gentoo support is at https://bugs.gentoo.org/ :) Cheers khaqq - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8292] i915: texture crossbar
http://bugs.freedesktop.org/show_bug.cgi?id=8292 --- Comment #7 from [EMAIL PROTECTED] 2007-10-09 17:06 PST --- (In reply to comment #1) Created an attachment (id=7002) -- (http://bugs.freedesktop.org/attachment.cgi?id=7002action=view) [details] i915 texture crossbar patch How do I apply this patch? -- Configure bugmail: http://bugs.freedesktop.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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
