Re: Initial 915 superioctl patch.
On Thursday, October 4, 2007 8:55 pm Dave Airlie wrote:
Overall, looks nice.
At a high level, I'm wondering if something like this could be made more
generic... It seems like other GPUs will need similar relocation processing
so maybe the DRM should grow some generic reloc processing code? Much of
this stuff seems fairly generic, so maybe it wouldn't be that hard, and it
would keep us from adding yet another driver specific ioctl...
+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 %08x, 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;
+}
+
+#define RELOC_START_OFFSET 2
+#define RELOC_NUM_INTS 3
These seem unused?
+int i915_process_relocs(struct drm_file *file_priv,
+ uint32_t buf_handle,
+ uint32_t *reloc_buf_handle,
+ struct i915_relocatee_info *relocatee,
+ struct drm_buffer_object **buffers,
+ uint32_t num_buffers)
+{
+ struct drm_device *dev = file_priv-head-dev;
+ struct drm_buffer_object *reloc_list_object;
+ int ret;
+ uint32_t cur_handle = *reloc_buf_handle;
+ uint32_t num_relocs;
+ struct drm_bo_kmap_obj reloc_kmap;
+ uint32_t *reloc_page;
+ int reloc_is_iomem;
+ uint32_t reloc_offset, reloc_end, reloc_page_offset, next_offset;
+ int reloc_stride;
+ uint32_t cur_offset;
gcc probably takes care of this, but it's still nice to order your automatic
variables from large to small just to make sure you get good alignment.
+
+ memset(reloc_kmap, 0, sizeof(reloc_kmap));
+
+ reloc_list_object = drm_lookup_buffer_object(file_priv, cur_handle, 1);
+ if (!reloc_list_object)
+ return -EINVAL;
+
+ ret = drm_bo_kmap(reloc_list_object, 0, 1, reloc_kmap);
+ if (ret) {
+ DRM_ERROR(Could not map relocation buffer.\n);
+ goto out;
+ }
+
+ reloc_page = drm_bmo_virtual(reloc_kmap, reloc_is_iomem);
+ num_relocs = reloc_page[0] 0x;
+
+ if ((reloc_page[0] 16) 0x) {
+ DRM_ERROR(Unsupported relocation type requested\n);
+ goto out;
+ }
+
+ /* get next relocate buffer handle */
+ *reloc_buf_handle = reloc_page[1];
+ reloc_stride = 4; /* may be different for other types of relocs */
+
+ DRM_DEBUG(num relocs is %d, next is %08X\n, num_relocs,
reloc_page[1]);
+
+ reloc_page_offset = 0;
+ reloc_offset = 4 * sizeof(uint32_t);
+ reloc_end = reloc_offset + (num_relocs * reloc_stride *
sizeof(uint32_t));
So the first 32 bits of the reloc_page contains the reloc count and type, and
the next bits contain the actual info required, right? It might be nice to cast
them into reloc_info and reloc_arg structures of some kind. That way if new
reloc types were added later things would be a little clearer (and this code
would be a little more straightforward I think too). Would that make sense?
+static int i915_execbuffer(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
+ drm_i915_sarea_t *sarea_priv = (drm_i915_sarea_t *)
+ dev_priv-sarea_priv;
+ struct drm_i915_execbuffer *exec_buf = data;
+ struct _drm_i915_batchbuffer *batch = exec_buf-batch;
+ struct drm_fence_arg *fence_arg = exec_buf-fence_arg;
+ int num_buffers;
+ int ret;
+ struct drm_fence_object *fence;
Should data be __user? Oh no, I see it's already been copied in
drm_ioctl()...
+ if (!dev_priv-allow_batchbuffer) {
+
i915 state report
Hi, developers ! I had update git drm and Mesa-devel git drm and libdrm is working nice. But latest Mesa-git, give me this undefined symbol: ALIGN #LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.9.0 i915 (screen 0) libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so libGL error: dlopen /usr/lib/dri/i915_dri.so failed (/usr/lib/dri/i915_dri.so: undefined symbol: ALIGN) libGL error: unable to load driver: i915_dri.so display: :0 screen: 0 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature - 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: G33 graphics broken after 2.6.23-rc6
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote: It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through 2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't start up, and I get this at the end of my Xorg.log: AOL. And I was in the middle of watching a bloody movie too. commit f443675affe3f16dd428e46f0f7fd3f4d703eeab Author: Zhenyu Wang [EMAIL PROTECTED] Date: Tue Sep 11 15:23:57 2007 -0700 intel_agp: fix stolen mem range on G33 G33 GTT stolen memory is below graphics data stolen memory and be seperate, so don't subtract it in stolen mem counting. Signed-off-by: Zhenyu Wang [EMAIL PROTECTED] Acked-by: Dave Airlie [EMAIL PROTECTED] Cc: Dave Jones [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] Looks to be the commit that breaks things. Regards, Kyle M. - 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: G33 graphics broken after 2.6.23-rc6
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote: commit f443675affe3f16dd428e46f0f7fd3f4d703eeab intel_agp: fix stolen mem range on G33 G33 GTT stolen memory is below graphics data stolen memory and be seperate, so don't subtract it in stolen mem counting. Found it, without this corresponding change to xf86-video-intel, this breaks utterly: commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca Author: Zhenyu Wang [EMAIL PROTECTED] Date: Wed Sep 5 14:52:56 2007 +0800 Fix G33 GTT stolen mem range G33 GTT table lives in seperate stolen mem with graphics data stolen mem. I think this should be reverted for 2.6.23, it certainly doesn't seem to have been appropriate for 2.6.23-rc6. Cheers, Kyle M. - 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
Revert intel_agp: fix stolen mem range on G33
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
drivers/char/agp/intel-agp.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index a5d0e95..141ca17 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,11 +506,6 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
- /* G33's GTT stolen memory is separate from gfx data
-* stolen memory.
-*/
- if (IS_G33)
- size = 0;
switch (gmch_ctrl I855_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
--
1.5.3.3
On Sat, Oct 06, 2007 at 01:34:10AM -0400, Kyle McMartin wrote:
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
intel_agp: fix stolen mem range on G33
G33 GTT stolen memory is below graphics data stolen memory and be
seperate,
so don't subtract it in stolen mem counting.
Found it, without this corresponding change to xf86-video-intel, this
breaks utterly:
commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca
Author: Zhenyu Wang [EMAIL PROTECTED]
Date: Wed Sep 5 14:52:56 2007 +0800
Fix G33 GTT stolen mem range
G33 GTT table lives in seperate stolen mem with
graphics data stolen mem.
I think this should be reverted for 2.6.23, it certainly doesn't seem to have
been appropriate for 2.6.23-rc6.
Cheers,
Kyle M.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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
