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
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
Here it is.
Looks okay to me.. check it in yourself..
Dave.
Maarten.
On 10/2/07, Maarten Maathuis [EMAIL PROTECTED] wrote:
You seem to be correct, i must have added the tmp variable in attempt
to solve something, that i ended up solving differently.
I will redo the patch and send
Okay this is my first public efforts at the i915 driver superioctl.
Please review and give out about anything I missed, I'm sure the error
handling needs some work. But I thought I'd get it out there..
I have a Mesa side to this in my personal mesa tree (i915-superioctl
branch) but I just
It should build against the last release of libdrm, not master, master
isn't released and when it gets released it'll be libdrm3 due to the
ttm api... if it can't build against that due to the missing TTM then
disable i915tex builds by default...
Now if there isn't a current release we
The preferred option at this point seems to be to add a new kernel
config option, e.g. CONFIG_DRM_MODESETTING or similar. Enabling the
option would prevent old X servers and Mesa from working with the DRM,
but they'd be otherwise unaffected. Disabling it would retain full
compatibility at
I've got a few issues using the git heads of Mesa, DRM and xf86-video-intel:
1. The Mesa 7.0.2 branch doesn't build with drm/master.
Compiling dri_bufmgr.c:
../common/dri_bufmgr.c: In function 'driFenceBuffers':
../common/dri_bufmgr.c:102: warning: passing argument 3 of
'drmFenceBuffers'
I'm about to merge the pre-superioctl branch but I've pushed it for a review
first.
There are a couple of fixes that shouldn't affect any ongoing super-ioctl
work, but then there also is some important changes.
a) A fence error member. The idea is that when we detect a lockup, we signal
On 9/17/07, Keith Whitwell [EMAIL PROTECTED] wrote:
I've been thinking about this a little more and wonder if we can get
away with slightly relaxed semantics compared to NO_MOVE in some cases
at least.
In the current SWZ branch, we're pre-validating one or two buffers (VB,
indirect state)
Dave,
I thought we agreed at the XDS to remove the libdrm list helpers, and
let the drivers themselves take care of this?
However before that's done, i915 needs a Superioctl, so we don't break
that driver.
Just confirming that's what we suggested :-), I have a i915 superioctl I
need to
I'm just looking at the list handling code in the TTM for libdrm,
and I really don't think we can just leave it as-is but making it generic
also doesn't look that easy (it would at least require adding destructor
paths for free list object contents)
Thomas, any ideas on how best to handle it?
What other info needed?
I'm seeing this on my 965gm chipset with Andi's clflush patches on x86
32-bit, it looks like an interaction with the agp code which does a big
bunch of change page attr to allocate the AGP aperture backed memory..
I think the code might have worked in a previous
Note the slab has a memory tracking feature that accounts memory to
callers of the allocator. IF that's not enough for you please help
improving the common code instead of inventing your own.
Christoph that code was written over 6-7 years ago, feel free to provide a
patch for it to use the
Hi,
I am a newbie whos trying to make to work a 945GM integrated card.
I have this problem with the last version of xf86-video-intel driver
(downloaded from git on 30/08/07..yesterday) where I can't run any 3D
application using DRI.
stop using intelfb would be a good starting point.
On Tue, 28 Aug 2007, Christoph Hellwig wrote:
On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote:
Hello,
As there are many places in drm code where drm_alloc + memset is used
this patch series introduces drm_zalloc and also makes use of drm_calloc
where
needed. Most of
On Tue, 28 Aug 2007, Keith Whitwell wrote:
Looks like we've got a slot at XDS to talk about all our adventures with
buffer management and plans for the future. It might make the session
more productive if we do a little groundwork first...
If you've been working with TTM and have things
I've scheduled a modesetting BoF at XDS and I've put a wiki page for
ppl to add ideas to be discussed at it..
http://www.x.org/wiki/Events/XDS2007/ModeSettingBoF
I'm hoping to have some work done on a preliminary API before XDS.
Dave.
Blame intel ;)
Any other ideas and suggestions?
Without knowing exactly what you are doing:
- Copies to uncached memory are very expensive on an x86 processor
(so it might be faster not to write and flush)
- Its not clear from your description how intelligent your transfer
system is.
Hi all,
I've started doing some work with using the new DRM memory manager
from TG for pixmaps in the X server using Intel 9xx series hardware.
The intel hardware pretty much requires pages to be uncached for the
GPU to access them. It can use cached memory for some operations but
it isn't very
hum ! If kernel 2.6.22 have it, I am missing something,
I had test with one kernel 2.6.22 and I am seeing one configuration of
kernel 2.6.23-git22 and I don't see any linux-agp-compat or it is
supposed be on AGP_INTEL ? .
It's in 2.6.21 and later, it is just a part of agp, nothing special
2nd - will linux-agp-compat enter in kernel main stream ?
It's been in the kernel for a while..
2.6.21 has it but I've no idea when it went in..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
DRM
Subject : wine locks up system
References : http://lkml.org/lkml/2007/7/17/128
Last known good : ?
Submitter : Charles Gagalac [EMAIL PROTECTED]
Caused-By : commit d4e2cbe9cb9219fc924191a6baa2369140cb5ea8
Dave Airlie [EMAIL PROTECTED
insertions(+), 312 deletions(-)
commit d4e2cbe9cb9219fc924191a6baa2369140cb5ea8
Author: Dave Airlie [EMAIL PROTECTED]
Date: Tue Jul 17 10:55:47 2007 +1000
drm: convert drawable code to using idr
This converts the code for allocating drawables to the Linux idr,
Fixes from: Michel D??nzer
I really think this or the previous tree is buggy.
I've got this to reproduce on my machine, this code came from DRM git and
has been okay in there for a few weeks, I'll do some digging it may be
something to do with the idr + context/drawable code..
Dave.
Trying to start any 3D client
Please pull the 'drm-patches' branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
Could you re-pull?
There are two patches, one fixes a missed typedef for Sis and one adds the
idr_init that fell out of the drawable changeset.. which should fix any
|6 +-
drivers/char/drm/via_verifier.c | 12 +-
drivers/char/drm/via_verifier.h |6 +-
76 files changed, 2444 insertions(+), 2173 deletions(-)
commit bd63cb52c05bbb154f539369cae4fb9c9b6277da
Author: Dave Airlie [EMAIL PROTECTED]
Date: Thu Jul 12 10:35:02 2007 +1000
drm
On 7/16/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Mon, 16 Jul 2007, Dave Airlie wrote:
Please pull the 'drm-patches' branch from the drm git tree.
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
This totally breaks for me.
CC
Linus has decreed the evil of typedefs in the kernel, and the DRM is
the proud winner of the HEY MA: I CAN USE TYPEDEF award,
So I've cleaned up most of the typedefs in the Linux drm core (I did
this in the kernel tree as I'd like to push it there first and
backport it to the hell of the DRM git
[drm:radeon_do_init_cp] *ERROR* Cannot use PCI Express without GART in FB
memory
when trying to use miniglx (running ./sample_server from a non-X ubuntu
environment), on my machine with a Mobile x600 Radeon PCI-Express card.
DRI radeon acceleration is working ok on my standard X-enabled
from the radeon DDX driver.
However I'm sure most of the pcie code made it over at one point but I may
not have published it.. and have probably since lost it..
Dave.
Tom.
On 6/28/07, Dave Airlie [EMAIL PROTECTED] wrote:
[drm:radeon_do_init_cp] *ERROR* Cannot use PCI Express without
cheers,
Kristian
Kristian,
This is OK with me. It will add an extra malloc / free for every buffer
object creation / destruction,
but will make it easier to maintain in the future, (and we can get rid
of the padding for future expansion).
Exactly, I took out the pad fields in
When I load the drm and radeon modules (I have a 9200SE on my box)
and start up X (Xorg 7.2.0) I see a series of calls to drmAddMap finishing
with the message added 8192 byte SAREA at 0xdf7c2000 then a call to
drmMap which fails because dma-pagelist is NULL because drmAddBufs has
never
| 26 +++
5 files changed, 110 insertions(+), 18 deletions(-)
commit 9b01bd5b284bbf519b726b39f1352023cb5e9e69
Author: Dave Airlie [EMAIL PROTECTED]
Date: Sun Jun 10 16:00:27 2007 +1000
drm: fix radeon setparam on 32/64 bit systems.
The alignment on 64-bit is different for 64
Anyone objections to pulling over the ttm interface ioctl changes?
These are going to be annoying no matter when I do it .. so I'd like
to get it out of the way..
Dave.
-
This SF.net email is sponsored by DB2 Express
On Thu, May 31, 2007 at 05:11:22PM +0800, Wu, Nian wrote:
Then I compiled DRM kernel module, it reported below error info:
Don't do this. Always use the in-kernel drm.
No don't listen to hch, I'll fix it..
hch, the in-kernel drm isn't much use for developers, they can't exactly
check code
On 5/22/07, Philipp Klaus Krause [EMAIL PROTECTED] wrote:
Benjamin Herrenschmidt schrieb:
In collaboration with the FB guys, we've been working on enhancing
the
kernel's graphics subsystem in an attempt to bring some sanity to the
Linux graphics world and avoid the situation we have now
On 5/9/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave Airlie wrote:
I'll try it out as soon as there is time.
I've just tested glxgears and a few mesa tests on it and it seems to
be working fine
We should probably think about pulling this over into the DRM sooner
rather than
Hellstrom thomas-at-tungstengraphics-dot-com
Date: Tue May 8 15:48:39 2007 +1000
via: Make sure we flush write-combining using a follow-up read.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit a0a6dd0b221260be1e3da725e6b49797e5fa7429
Author: Thomas Hellstrom thomas
On 5/7/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave Airlie wrote:
I've started a cleanup branch,
I've just checked in the mm_ioctl split out into separate parts, I'll
try and get fence and buffer done as well..
This will break compatiblity but to be honest, anyone who has
I'll try it out as soon as there is time.
I've just tested glxgears and a few mesa tests on it and it seems to
be working fine
We should probably think about pulling this over into the DRM sooner
rather than later, there are also some changes to the DDX
i830_driver.c compat code to deal
ce7dd06372058f9e3e57ee4c0aeba694a43a80ad
Author: Wang Zhenyu [EMAIL PROTECTED]
Date: Thu Apr 26 07:42:56 2007 +1000
drm/i915: Add 965GM pci id update
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 9e9c1326a592c677c94d730fcf4446d0e275aef4
Author: Dave Airlie [EMAIL PROTECTED]
Date
I've started a cleanup branch,
I've just checked in the mm_ioctl split out into separate parts, I'll
try and get fence and buffer done as well..
This will break compatiblity but to be honest, anyone who has deployed
this beyond embedded system work (i.e. TG and me), deserves what they
get for
I've started a cleanup branch,
I've just checked in the mm_ioctl split out into separate parts, I'll
try and get fence and buffer done as well..
This will break compatiblity but to be honest, anyone who has deployed
this beyond embedded system work (i.e. TG and me), deserves what they
get
update
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 9e9c1326a592c677c94d730fcf4446d0e275aef4
Author: Dave Airlie [EMAIL PROTECTED]
Date: Sat Mar 24 17:57:54 2007 +1100
drm: just use io_remap_pfn_range on all archs..
Move the sparc64 ifdef around to clean this up.
Signed-off
Dave, how did you generate this file? (Was it from an indirect buffer?)
http://www.skynet.ie/~airlied/dri/mypa.parsed
Magic and guess work produced that file...
Basically I used glxtest which works fine to dump the maps just actually
finding the IB is a lot more impossible.. I search for
The displacement of vertices is most likely caused by the fact that
r300 drivers swtcl path cheats and does vertex transformation in
hardware. That's also why arbvpwarpmesh fails to work when sw path is
active.
So do we need to do a completely separate swtcl path that doesn't do this?
As
I just started reading the X code about 6 months ago, and the learning
curve has been steep. My emails to dri-devel are answered now and
again, and that is kinda frustrating when you want an answer NOW.
You maybe have missed out on #dri-devel on freenode irc, it works
reasonably well for
1.) in how many files/ how big that driver (just OpenGL) is at the end?
(scitech OpenGL driver is one file, 800kb and thats all you need, beside
the OpenGL app you want to run)
No. we give you the source code, scitech seem to give you a binary. I
assume scitech isn't hardware accelerated
I'm running with it on an ASUS A7V333 motherboard and Fedora Core 6.
I am trying to use the 'radeon' driver that comes with Xorg. However,
X will not even start up -- the system hangs and I have to hard reset
typically.
Do you have any AGP related settings in the BIOS?
Dave.
--
David
Do you have any AGP related settings in the BIOS?
Dave.
Yes, there are several. Any recommendations on which ones I should
play with? I have played with a few different values for the aperture
size.
I can get you a list of all the settings available if needed.
Turn off anything like
I am curious if you would consider the machine freezing when the
aperture is set at 64MB to be a bug (didn't try any other setting).
Yeah that shouldn't happen...
Something is doing something wrong in that case..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied /
Okay the GART is working fine on the rs480 from my branch, however the
r300 driver causes a chip lockup, I've loaded fglrx and from what I can
see it disables the Vertex Shaders in hw and does that bit of the pipeline
in sw.. at least on the system I have...
If anyone else has an xpress 200
Okay I've got a bug reported before and now again about 4GB + radeon
blows up the DRM... on Intel hw...
What the drm currently does for the PCI GART table is it allocates a
chunk of memory (8MB) with vmalloc_32(), then when it decides to use
it it goes through every page of it calls
So when swiotlb happens, as you can guess it all falls apart as the
drm never calls sync functions at any stage...
You would have hit this on any platform that does caching
in the PCI controller as well.
We must not have a great intersect of radeon and such systems..
Coherent memory
On a 64-bit machine GFP_KERNEL can give me any memory... it all works
fine on 32-bit highmem kernel as I don't get highmem... I really need
__GFP_DMA32 memory but we don't have a generic allocator that gives
this out that I can see..
__get_free_pages(..., __GFP_DMA32) on 64bit or
It might explain why my machine hung when I tried to use
radeon with DRM on my sparc64 workstation :-) I have
investigating that on my todo list.
True, maybe the intersection is me + hw like that + radeon :-)
I don't know what to recommend to you, getting 8MB of linear memory
really just
Hi,
I've done a port of miniglx to a TTM-only system (no legacy buffers),
It's in the miniglx-ttm-only branch of my personal mesa repo..
http://gitweb.freedesktop.org/?p=users/airlied/mesa.git;a=shortlog;h=miniglx-ttm-only
It is just an example of how to use drmBOs to allocate the memory
Hi,
Yes it is certainly possible to take the changes into the DRI
source tree, it would need to be ported to the DRM git tree
http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary
and osol-core or solaris-core directory would be needed (unless the code
is close to the BSD or Linux
in the DRM tree this needs to be done in a backwards compatible fashion...
so in drm_compat.h we need to do
#ifndef IRQF_SHARED
#define IRQF_SHARED SA_SHIRQ
#endif
so we continue to build on older kernels..
Dave.
On Mon, 5 Mar 2007, Maarten Maathuis wrote:
Bump.
On 3/2/07, Maarten
I've stuck my initial unworking code into my git repos..
git://people.freedesktop.org/~airlied/drm.git on the rs480-0-0-1 branch
git://people.freedesktop.org/~airlied/xf86-video-ati.git on rs480-igp
Phillip if you get a chance to play around with it you might be able to
get something working..
only enough to map 512k... (Also, the addresses are stored in big endian.. I
think.) I might be interesting to actually look at what is in these
addresses.
That mght make sense on your card as you have actual RAM, the GART is
allocated dynamically by fglrx, so if you use a 3D app I'd
I'll have to look at your dump and compare. (Maybe we can find some size
differences).
The only thing that is really peculiar, is that when I look at the GART
table that 2c points to, it is MUCH too small.. Only 32*4 entries, which is
only enough to map 512k... (Also, the addresses are
Which would exactly fit between 0xCFFE - 0xCFFF. Yes this is an
assumption, but some of the DRI code mentions that PCI express allocates the
GART table at the end of the frame buffer, so that is why I was thinking it
worked this way.
Can you dump that memory area? see if it has a
I've added some info the wiki page on what I've found with the 200M so
far,
quick summary:
1. It should have a PCI GART, the regs work, but it doesn't seem to
function... bummer...
2. Attempts to move all things we currently allocate in GART into
framebuffer, seems to work fine for CP accel
work with the EGL demos. This is because I'd like to help out with EGL
+MESA development.
Now I'm totally stuck, and suppose I hit a few deeply-rooted problems
that I cannot solve without in-depth knowledge about DRM memory layout.
DRI/Mesa are fresh GIT checkouts, I also had this problem
How is your card configured?
No on-board RAM.. just UMA... 32MB setup by BIOS..
After looking at the debug output from the fglrx 8.32.5 driver, I think that
there is a GART table at the end of the 128M. (From 0x57fe-0x5800)
The CP is mapped at 0x5800. (In the GART space.)
what
I'm running a 2.6.20 kernel on my macbook. When running an openGL
application, if the opengl window's region is moved somewhere outside
the screen limits, then keyboard locks, I can only move the mouse,
nothing response. I can only reboot the box by pressing the power button
5 seconds.
06:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon
X300 (PCIE)] (prog-if 00 [VGA])
Subsystem: VISIONTEK Unknown device 0401
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF-
...
I did a little more digging on this. It really looks like the address of
ring.start is completely different than what is in RADEON_CP_RB_BASE. (I
realize that ring.start is a virtual address and RADEON_CP_RB_BASE is a bus
address. However, the drmAddMap call in RADEONDRIPciInit sets
7.2 and handled correctly by the 3D driver.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
I think if your X.org is too old and doesn't support the new drawable
code, you'll get lots of these in the logs if you try and use vblank?
Should we just remove the print?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX /
Does anbody know why drm is using vmalloc_32 instead of vmalloc when
allocating SHM maps?
I may be wrong but maybe for mixed 64/32-bit kernel/userspace systems, did
it ever use vmalloc?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux
Don't know really, but since drm AFAICT never cares about the physical
address of the
underlying pages, vmalloc should probably do just fine, or even better
vmalloc_user on newer kernels,
= we could skip the memset() i just added.
I'ts been there for ever
static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
{
drm_file_t *priv = filp-private_data;
drm_device_t *dev = priv-head-dev;
drm_i830_buf_priv_t *buf_priv = buf-dev_private;
drm_i830_private_t *dev_priv = dev-dev_private;
const struct
Hi,
I'd like to upstream the mach64 drm at some point, I believe the command
stream is now secure from having the client change it after submission,
however I'm not sure we are actually check the blit's are legal and not
doing anything...
I'll have to dig the datasheets out I suppose and
I was looking at the various options in the radeon man page and came
across the BusType option. I had tried both leaving that option out,
and setting the option to PCIE. This morning, I decided to try
setting it to PCI though, according to the man page, PCIE simply
falls back to PCI at the
: fd62459b11c39a58e5b45b8af30a8217d5ce0e1b libdrm-2.3.0.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.3.0.tar.bz2
MD5: 01a1e1ee0268a2403db42fa630036ab2 libdrm-2.3.0.tar.bz2
SHA1: af2e8d6e3ad6b906b4d6f1b2ada2d523188c28ea libdrm-2.3.0.tar.bz2
Dave Airlie:
libdrm: add support for server side
Does the DRM git tree work would also be interesting,...
I haven't merged up Michel's drawable/blank changes for 2.6.19 as they
were much too new for it, but do we have a backwards compat issue perhaps
or something similiar?
Dave.
On Wed, 18 Oct 2006, Keith Whitwell wrote:
This is all a
I thought I made it pick only one of the pipes. Did I mess up?
Your code looks fine to me, not sure how it ends up with both enabled...
Is there anything I can do to give further debug info?
strace the ioctl that your app is calling... see what it returns, see why
it returns twice...
Dave.
Is there anything I can do to give further debug info?
strace the ioctl that your app is calling... see what it returns, see why
it returns twice...
Do you use intelfb (just as an aside...)?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux
0x1002 0x4c42 0 3D Rage LT Pro AGP-133
0x1002 0x4c44 0 3D Rage LT Pro AGP-66
+0x1002 0x4759 0 Rage 3D IICATI 3D RAGE IIC AGP(A12/A13)
The formatting looks really strange.
Also Rage IIC doesn't have a setup engine so AFAIK it should not be
listed in the drm.
The bug has been open for a
On 9/22/06, Ryan Richter [EMAIL PROTECTED] wrote:
On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote:
Here is the bug I'm working from (includes hardware, software, etc.):
https://bugs.freedesktop.org/show_bug.cgi?id=6111
DRI will work if you set: Option BusType PCI
Obviously, we are interested in making use of the new DRM memory manager
on that hardware. Now if I understand how it works correctly, this new
memory manager allocates opaque handles which are not to be used as
offset in memory, because they are not. Therefore, a translation from
the handle
Did you build you kernel with CONFIG_DRM=y? if so don't.
to use DRM CVS you need to make sure in-kernel DRM isn't built-in.
If not I'm confused.
Dave.
On Tue, 25 Jul 2006, Michel D�nzer wrote:
Building DRM git against 2.6.17, I get:
Building modules, stage 2.
MODPOST
*** Warning:
I'm in the process of moving DRM CVS to git, can people avoid using CVS from
now on...
When I get the last admin help the repo will be (in a few hours):
git://anongit.freedesktop.org/git/mesa/drm
I've decided to put the drm under the mesa project on fd.o as the dri project
is pretty much
I have a question in mind that why we Are moving all to git ?
For me it has no good, i have to download everything from the buttom to the
top. The conversion I found on web is for the source that will be placed on
server only, no client site source conversion I can found.
For me it is bad
I just did this and fixed the SiS and Unichrome 3D drivers, bumping their
drm device driver majors. The fixes tend to be very small. The intel drivers
should also be OK.
Can we do this without upping the driver majors? we may have to add
setparam support... my problem is after this change,
Can we do this without upping the driver majors? we may have to add
setparam support... my problem is after this change, old 2D driver may
not work anymore with this DRM, so if I upgrade my kernel it will break
things that currently work... we managed to mostly avoid this with the
64-bit
I'd like to bring in the hashed map lookup from the drm-ttm-branch to CVS. It
changes the drmmap() map lookup from a linked list search to a hash lookup.
This means that the user_token that identifies the map in user space becomes
an arbitrary hash key in the range 0x1000 to 0x9000
While grep'ing through shared-core/drm_pciids.txt, I found out that there are
some duplicate entries for Intel chipsets. The attached patch remove the dups
and move the i915 section below the i810 and i830 sections. I'm not sure if
this is really important or not, but dropping a note will
Hi,
As the ATI driver lacks a clear maintainer and really wants to
live in git I've migrated it.
The git URL is
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
I'm awaiting admin intervention to do a few other things (non-admin
shouldn't try to migrate things it is too
New semantics:
The new manager always aligns to 16 bytes, except when it is bypassed by
the SiS fb module.
Yes you're right. The core functions support any alignment so the constraints
are device specific.
Just another question, could this code be used to replace all or
parts of
I'll have a look. However, I'd rather focus on getting the ttm branch in a
usable state and start moving drivers over to that functionality, eventually
obsoleting the code in drm_sman.c.
Oh no worries don't let me detract from the real problem, I just wondered
having looked in those files
Both i915 and radeon memory managers could probably be moved over to the new
code, but then only using the functionality in drm_mm.c and not drm_sman.c.
I'll have a look. However, I'd rather focus on getting the ttm branch in a
usable state and start moving drivers over to that
No.
and ATI hate you for trying :-)
see numerous archive posts about this..
Dave.
On Thu, 25 May 2006, Pekka Enberg wrote:
Hi,
I am running Ubuntu Linux on Intel-based iMac and was wondering if I
could use the r300 driver for 3D. The card is a PCI Express ATI Radeon
Mobility X1600
Is it PCI Express carD? if so suspend/resume is a fixed bug in Xorg CVS,
you need to get that stable ati driver and install it on Xorg7.0, if you
are running Fedora it should be in updates-testing I think and Ubuntu has
it in dapper..
Dave.
On Tue, 2 May 2006, curt manucredo (hansycm)
On 3/25/06, Luca Dionisi [EMAIL PROTECTED] wrote:
I'm having problems with Xorg built from cvs sources very recently.
I've also built from cvs sources libdrm and the latest kernel (2.6.16)
with the drm enabled for my card (radeon)
I don't know for sure, but I think my problem is with the
I think that's what drm_lock.c:drm_notifier is for.. block_all_signals is
only used by the DRM from what I can see just for this reason..
Dave.
On Mon, 20 Mar 2006, Keith Whitwell wrote:
I believe that on Linux, there is actually some code in the kernel to put on
hold various sorts of
Based on X300 but isn't... it doesn't work yet due to having a
different memory controller.. I've no idea how long it will take for
someone to fix that or for me to get one long enough to play with it..
Any possibility someone could enlighten me with ways to play around
with my 200M? I'd
I have a ATI radeon chipset based motherboard with vga
integrated based on X300 hardware. The ID of my card (vendor 0x1002, id
0x5a61) isn't yet in the drm_pciids.txt so I mail what I know about this
hardware:
Based on X300 but isn't... it doesn't work yet due to having a different
701 - 800 of 1423 matches
Mail list logo
