[Bug 12731] New: dri is disabled with i915 driver
http://bugs.freedesktop.org/show_bug.cgi?id=12731 Summary: dri is disabled with i915 driver Product: Mesa Version: CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: highest Component: Drivers/DRI/i915 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: dri-devel@lists.sourceforge.net Dri is disabled with i915 driver. glxinfo reports dri is disabled and glxgears gives very low FPS(75-85FPS). This bug was introduced by commit: commit 77e0523fb7769df4bf43747e136b1653b2421b97 Author: Eric Anholt [EMAIL PROTECTED] Date: Thu Oct 4 12:07:25 2007 -0700 [965] Replace various alignment code with a shared ALIGN() macro. In the process, fix some alignment issues: - Scratch space allocation was aligned into units of 1KB, while the allocati wanted units of bytes, so we never allocated enough space for scratch. - GRF register count was programmed as ALIGN(val - 1, 16) / 16 instead of ALIGN(val, 16) / 16 - 1, which overcounted for val != 16n+1. -- 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
glxinfo weird error, please help
Please Help, thank you very much!! Code: $ export LIBGL_DEBUG=verbose $ glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) libGL: OpenDriver: trying /usr/lib/dri/tls/radeon_dri.so libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so libGL: XF86DRIGetClientDriverName: 1.8.0 i965 (screen 1) libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::04:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::00:02.0 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::04:00.0 libGL warning: 3D driver claims to not support visual 0x93 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenByBusid: drmOpenMinor returns 5 drmOpenByBusid: drmGetBusid reports pci::00:02.0 glxinfo: ../common/xmlconfig.c:110: findOption: Assertion `i size' failed. Aborted Code: $ oowriter libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) libGL: OpenDriver: trying /usr/lib/dri/tls/radeon_dri.so libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so libGL: XF86DRIGetClientDriverName: 1.8.0 i965 (screen 1) libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci::04:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci::00:02.0 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci::04:00.0 libGL warning: 3D driver claims to not support visual 0x93 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci::00:02.0 soffice.bin: ../common/xmlconfig.c:110: findOption: Assertion `i size' failed. /usr/lib/openoffice/program/soffice: line 236: 21963 Aborted $sd_prog/$sd_binary $@ Code: lspci -v 00:00.0 Host bridge: Intel Corporation Memory Controller Hub (rev 02) Subsystem: Dell Unknown device 01da Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:01.0 PCI bridge: Intel Corporation PCI Express Root Port (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: dfc0-dfcf Capabilities: [88] Subsystem: Dell Unknown device 01da Capabilities: [80] Power Management version 3 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [a0] Express Root Port (Slot+) IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [140] Unknown (5) 00:02.0 VGA compatible controller: Intel Corporation Integrated Graphics Controller (rev 02) (prog-if 00 [VGA]) Subsystem: Dell Unknown device 01da Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at dfe0 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=256M] I/O ports at ecb8 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corporation Integrated Graphics Controller (rev 02) Subsystem: Dell Unknown device 01da Flags: bus master, fast devsel, latency 0 Memory at dff0 (32-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 2 00:1a.0 USB Controller: Intel Corporation USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell Unknown device 01da Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at ff20 [size=32] 00:1a.1 USB Controller: Intel Corporation USB UHCI Controller #5 (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell Unknown device 01da Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at ff00 [size=32] 00:1a.7 USB Controller: Intel Corporation USB2 EHCI Controller #2 (rev 02) (prog-if 20 [EHCI]) Subsystem: Dell
Re: Initial 915 superioctl patch.
On Sunday, October 7, 2007 4:26 pm Dave Airlie wrote:
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...
You'd think that, and some parts maybe later could be generalised
internally in the kenrel, but the ioctl needs to remain driver
specific otherwise we won't be able to optimise use-cases for
specific drivers.. Thomas's original code attempted to make parts of
this generic in libdrm but once I started experimenting with it I
found it limited what I could do.. the i915 has different
requirements to the poulsbo which are the only two example
superioctls in the wild at the moment..
Ah ok, we don't want to give up on optimizing for specific devices, so
if poulsbo and i915 already have different characteristics we'd better
keep the ioctls driver specific.
+ 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.
Damn ia64 hackers...
:) Don't forget that unaligned accesses on x86 cost a lot too, you just
don't take an interrupt for them...
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?
Yeah I thought about doing that, it's what poulsbo does pretty much,
then I also thought for future different relocs type you really just
want stride and pointer..
Yeah, up to you. If you don't end up with a separate struct though, it
would be good to add a comment describing the layout.
+ if (!dev_priv-allow_batchbuffer) {
+ DRM_ERROR(Batchbuffer ioctl disabled\n);
+ return -EINVAL;
+ }
Why would userspace turn this off? Looks like current code turns
the feature on at least...
We can probably remove thse later when we do init in-kernel.
Cool (my first reaction to anything configurable is oh no, not another
config option, so I had to ask :).
+#define DRM_IOCTL_I915_EXECBUFFER DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_EXECBUFFER, struct drm_i915_execbuffer)
I know it's not in keeping with DRM tradition, but a short blurb
about how this ioctl works (i.e. data structures and how to submit
them) would be nice... :)
I'll have userspace example code in my mesa tree.. I can't see there
being many users beyond Mesa and the DDX..
Sounds good.
+ struct _drm_i915_batchbuffer batch;
+ uint64_t ops_list;
+ struct drm_fence_arg fence_arg;
+};
Why the _ prefixed version here? In my tree there's no
_drm_i915_batchbuffer, just drm_i915_batchbuffer...
I was starting to dump some typedefs...
Yeah, I noticed the massive removal in the DRM tree, looks really nice.
I guess there's just some driver specific stuff left...
+#ifdef I915_HAVE_BUFFER
+#define I915_NUM_VALIDATE_BUFFERS 256
+#endif
Why 256?
It was larger than 42.. I suppose I could use getparam to report this
to userspace so we could change it in theory later..
I don't know if 42 is better than 256... do we have any measurements
that would help us pick a good number or that would tell us we need to
make it a runtime option? Or maybe just part of the argument structure
that's passed in?
Jesse
-
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: DRM_READ/WRITE* vs. byte swapping (Re: drm: Branch 'master')
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: On Wed, 2007-10-03 at 14:08 -0700, Ian Romanick wrote: diff --git a/linux-core/xgi_cmdlist.c b/linux-core/xgi_cmdlist.c index 261f4e1..35f7e1b 100644 --- a/linux-core/xgi_cmdlist.c +++ b/linux-core/xgi_cmdlist.c @@ -45,7 +45,7 @@ static inline void dwWriteReg(struct drm DRM_INFO(mmio_map-handle = 0x%p, addr = 0x%x, data = 0x%x\n, map-handle, addr, data); #endif -DRM_WRITE32(map, addr, data); +DRM_WRITE32(map, addr, cpu_to_le32(data)); These look odd - DRM_READ/WRITE* already swap bytes. Does the device's MMIO aperture swap bytes on its own? If so, and you can't or don't want to disable that, maybe we need new macros using __raw_read/write* on Linux. Hmm...I didn't realize that those functions had a built-in byte-swap. I'm having some issues getting XP10 working properly on PPC, and a liberal sprinkling of cpu_to_le32 and le32_to_cpu made things better. I'll continue investigating. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHCmMPX1gOwKyEAw8RApB/AKCa0BacjZSD7eynwgOVAfI4Gz/YGwCeJqc/ aUEPIxI064kjOqjHyTw+3eM= =zxPL -END PGP 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: Initial 915 superioctl patch.
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. Sorry for topposting -- webmail. Keith - Original Message From: Jesse Barnes [EMAIL PROTECTED] To: Dave Airlie [EMAIL PROTECTED] Cc: dri-devel@lists.sourceforge.net Sent: Monday, October 8, 2007 6:04:42 PM Subject: Re: Initial 915 superioctl patch. I don't know if 42 is better than 256... do we have any measurements that would help us pick a good number or that would tell us we need to make it a runtime option? Or maybe just part of the argument structure that's passed in? Jesse - 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
Alec Liu wrote: i am using the gentoo i did compile everything please help me to local the badly compiled library thank you ! On 10/9/07, Jerome Glisse [EMAIL PROTECTED] wrote: Alec Liu wrote: Please Help, thank you very much!! Code: $ export LIBGL_DEBUG=verbose $ glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) libGL: OpenDriver: trying /usr/lib/dri/tls/radeon_dri.so libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so libGL: XF86DRIGetClientDriverName: 1.8.0 i965 (screen 1) libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::04:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::00:02.0 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::04:00.0 libGL warning: 3D driver claims to not support visual 0x93 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenByBusid: drmOpenMinor returns 5 drmOpenByBusid: drmGetBusid reports pci::00:02.0 glxinfo: ../common/xmlconfig.c:110: findOption: Assertion `i size' failed. Aborted Code: $ oowriter libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) libGL: OpenDriver: trying /usr/lib/dri/tls/radeon_dri.so libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so libGL: XF86DRIGetClientDriverName: 1.8.0 i965 (screen 1) libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci::04:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci::00:02.0 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci::04:00.0 libGL warning: 3D driver claims to not support visual 0x93 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci::00:02.0 soffice.bin: ../common/xmlconfig.c:110: findOption: Assertion `i size' failed. /usr/lib/openoffice/program/soffice: line 236: 21963 Aborted $sd_prog/$sd_binary $@ This is likely due to badly compiled library or picking the wrong one. Did you compile yourself anythings ? If you are using only distrib package then ask your distribution to fix this. Cheers, Jerome Glisse 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. Cheers, Jerome Glisse - 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: fix undefined symbol: ALIGN on /usr/lib/dri/i915_dri.so
On Mon, 2007-10-08 at 01:16 +0100, Sergio Monteiro Basto wrote:
Hi,
this patch fix my problem ,
--- a/src/mesa/drivers/dri/intel/intel_tex_layout.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_layout.c
@@ -33,6 +33,7 @@
#include intel_mipmap_tree.h
#include intel_tex_layout.h
#include macros.h
+#include intel_context.h
GLuint intel_compressed_alignment(GLenum internalFormat)
{
Thanks,
Committed. Apparently I failed to check again after my first nm and fix
on i915.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
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 --- Comment #1 from [EMAIL PROTECTED] 2007-10-08 12:45 PST --- Already fix on git master : Commit: 4599683b480d295e407725e0fe99c357a0086092 i915: Fix undefined ALIGN symbol from 77e0523fb7769df4bf43747e136b1653b2421b97. you may close the bug ! -- 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
Re: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)
Hi, I tried to check the timing stuff but (as I'm not a real developper) I don't know how to test my timings easily. Until now, I did several tries with no luck... In fact, for each try, I have to compile the module, load it, check what's going on and the reboot. I must reboot because the modesetting-101 branch does not support rmmod. I would like to know if there is some sample code I can borrow to check the i2c (initiate queries, ...) in order to try to find the appropriate timing. Thank you 2007/10/2, Jesse Barnes [EMAIL PROTECTED]: On Tuesday, October 2, 2007 10:49 am Philippe Gaultier wrote: 2007/10/2, Jesse Barnes [EMAIL PROTECTED]: On Tuesday, October 2, 2007 8:28 am Philippe Gaultier wrote: Oct 2 00:32:18 coreduo i2c-adapter i2c-4: sendbytes: error - bailout. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read EDID block. Oct 2 00:32:19 coreduo i915 :00:02.0: TMDS-1: no EDID data This is probably the first thing to fix. Can you play with the i2c timings and see if you can get it to return some EDID data? The X server has some i2c code you can look at, as does the Intel DDX driver. It's probably a timing issue, but may also be an i2c setup problem in intel_sdvo.c (check against the DDX driver's i830_sdvo.c file to see what might be missing). Can you tell me which file I should check in order to not break the whole drm-modesetting driver ? I think it should be : - intel_i2c.c - drm_edid.c and perhaps - drm_crtc.c but I need your advice on this. intel_i2c.c has the i2c timings and get/set routines, so it's a good start. drm_edid.c probably isn't very interesting in this case--it just takes the EDID blob and turns it into its constituent modes and monitor info structures. Likewise, drm_crtc.c probably won't help in this case, it just handles all the metadata allocation and initialization. So your best bet is intel_i2c.c and intel_sdvo.c since you have an HDMI attached display. Jesse - 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.
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.. 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: Initial 915 superioctl patch.
On Monday, October 8, 2007 2:14 pm 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.. Yeah, definitely need a kernel limit of some kind, settable by the DRM master presumably? Jesse - 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: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)
On Monday, October 8, 2007 2:00 pm Philippe Gaultier wrote: Hi, I tried to check the timing stuff but (as I'm not a real developper) I don't know how to test my timings easily. Until now, I did several tries with no luck... In fact, for each try, I have to compile the module, load it, check what's going on and the reboot. I must reboot because the modesetting-101 branch does not support rmmod. It should rmmod correctly if you unbind the drm console driver (echo 0 /sys/class/vtconsole/vtcon1/bind or similar). I would like to know if there is some sample code I can borrow to check the i2c (initiate queries, ...) in order to try to find the appropriate timing. The X server has some i2c code with timings and different access methods you could look at. It seems to be slightly more reliable (but still not 100%) than the kernel code. Jesse - 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.. Yes but I suspect we'll need to increase or make it dynamic before we're done. As with most hard limits, you can work around it by flushing prematurely, but there is a cost to that, one way or another. 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
driver fence_type function
Hi Thomas (any anyone else :-) drm_buffer_object_validate gets passed new and old flags (using bo-mem.mask/bo-mem.flags) but when it calls the i915 fence_type function it only uses flags to check the fence type, now if this buffer is getting validated RW when it wasn't before, it will get the wrong fence type back.. I've changed this in my tree to (bo-mem.mask | bo-mem.flags) which or's the old and new types together but I wonder should it just be checking the mask and not flags at all? 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
[patch] post superioctl inteface removal.
Hi,
Once the 915 super ioctl is merged, the patch attached removes the unused
interfaces left behind...
Are any of these worth saving?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
From 5bb96b72c503953ae83e5fc12a4864f338189186 Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Tue, 9 Oct 2007 15:45:06 +1000
Subject: [PATCH] ttm: remove unused interface post-superioctl for 915
---
libdrm/xf86drm.c | 400 +-
libdrm/xf86mm.h | 40 +-
linux-core/drm_bo.c | 76 -
linux-core/drm_drv.c |2 -
linux-core/drm_fence.c | 39 -
linux-core/drm_objects.h |3 -
shared-core/drm.h| 12 --
7 files changed, 2 insertions(+), 570 deletions(-)
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index dc18d6f..1b9c889 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -2364,32 +2364,7 @@ int drmFenceCreate(int fd, unsigned flags, int
fence_class, unsigned type,
fence-signaled = 0;
return 0;
}
-
-/*
- * Valid flags are
- * DRM_FENCE_FLAG_SHAREABLE
- * DRM_FENCE_MASK_DRIVER
- */
-
-int drmFenceBuffers(int fd, unsigned flags, uint32_t fence_class, drmFence
*fence)
-{
-drm_fence_arg_t arg;
-
-memset(arg, 0, sizeof(arg));
-arg.flags = flags;
-arg.fence_class = fence_class;
-
-if (ioctl(fd, DRM_IOCTL_FENCE_BUFFERS, arg))
- return -errno;
-fence-handle = arg.handle;
-fence-fence_class = arg.fence_class;
-fence-type = arg.type;
-fence-flags = arg.flags;
-fence-sequence = arg.sequence;
-fence-signaled = 0;
-return 0;
-}
-
+
int drmFenceDestroy(int fd, const drmFence *fence)
{
drm_fence_arg_t arg;
@@ -2541,144 +2516,6 @@ int drmFenceWait(int fd, unsigned flags, drmFence
*fence, unsigned flush_type)
return 0;
}
-static int drmAdjustListNodes(drmBOList *list)
-{
-drmBONode *node;
-drmMMListHead *l;
-int ret = 0;
-
-while(list-numCurrent list-numTarget) {
- node = (drmBONode *) malloc(sizeof(*node));
- if (!node) {
- ret = -ENOMEM;
- break;
- }
- list-numCurrent++;
- DRMLISTADD(node-head, list-free);
-}
-
-while(list-numCurrent list-numTarget) {
- l = list-free.next;
- if (l == list-free)
- break;
- DRMLISTDEL(l);
- node = DRMLISTENTRY(drmBONode, l, head);
- free(node);
- list-numCurrent--;
-}
-return ret;
-}
-
-void drmBOFreeList(drmBOList *list)
-{
-drmBONode *node;
-drmMMListHead *l;
-
-l = list-list.next;
-while(l != list-list) {
- DRMLISTDEL(l);
- node = DRMLISTENTRY(drmBONode, l, head);
- free(node);
- l = list-list.next;
- list-numCurrent--;
- list-numOnList--;
-}
-
-l = list-free.next;
-while(l != list-free) {
- DRMLISTDEL(l);
- node = DRMLISTENTRY(drmBONode, l, head);
- free(node);
- l = list-free.next;
- list-numCurrent--;
-}
-}
-
-int drmBOResetList(drmBOList *list)
-{
-drmMMListHead *l;
-int ret;
-
-ret = drmAdjustListNodes(list);
-if (ret)
- return ret;
-
-l = list-list.next;
-while (l != list-list) {
- DRMLISTDEL(l);
- DRMLISTADD(l, list-free);
- list-numOnList--;
- l = list-list.next;
-}
-return drmAdjustListNodes(list);
-}
-
-static drmBONode *drmAddListItem(drmBOList *list, drmBO *item,
-unsigned long arg0,
-unsigned long arg1)
-{
-drmBONode *node;
-drmMMListHead *l;
-
-l = list-free.next;
-if (l == list-free) {
- node = (drmBONode *) malloc(sizeof(*node));
- if (!node) {
- return NULL;
- }
- list-numCurrent++;
-}
-else {
- DRMLISTDEL(l);
- node = DRMLISTENTRY(drmBONode, l, head);
-}
-node-buf = item;
-node-arg0 = arg0;
-node-arg1 = arg1;
-DRMLISTADD(node-head, list-list);
-list-numOnList++;
-return node;
-}
-
-void *drmBOListIterator(drmBOList *list)
-{
-void *ret = list-list.next;
-
-if (ret == list-list)
- return NULL;
-return ret;
-}
-
-void *drmBOListNext(drmBOList *list, void *iterator)
-{
-void *ret;
-
-drmMMListHead *l = (drmMMListHead *) iterator;
-ret = l-next;
-if (ret == list-list)
- return NULL;
-return ret;
-}
-
-drmBO *drmBOListBuf(void *iterator)
-{
-drmBONode *node;
-drmMMListHead *l = (drmMMListHead *) iterator;
-node = DRMLISTENTRY(drmBONode, l, head);
-return node-buf;
-}
-
-
-int drmBOCreateList(int numTarget, drmBOList *list)
-{
-DRMINITLISTHEAD(list-list);
-DRMINITLISTHEAD(list-free);
-list-numTarget = numTarget;
-list-numCurrent = 0;
-list-numOnList = 0;
-return drmAdjustListNodes(list);
-}
-
static void drmBOCopyReply(const struct
