To test last features of DRI drives, you should need lastest drives of X
tree, but to test latest Mesa3D it self you don't need it latest X.
There is no DRI drivers in X tree anymore.. there is no Mesa in X tree
anymore... there is no X tree anymore..
Dave.
--
David Airlie, Software
tree (20060226). This now has the latest and greatest changes in Xorg
CVS that the monolithic tree did not have. Among other things this means
that i915 should now work again, with rotation support. It also has
Benjamin Herrenschmidt's memory mapping changes that should solve lockup
problems on
The kernel DRM has fixes for this I just haven't ported them back to CVS
yet...
Dave.
On Sat, 18 Feb 2006, Felix Kühling wrote:
Hi,
does anyone object to applying this patch to linux-core/drmP.h:
--- drmP.h2 Jan 2006 05:54:10 - 1.172
+++ drmP.h18 Feb 2006 18:46:54
1) The patch doesn't apply against DRM cvs (Feb 18th)
DRM CVS has the patch so patching is pointless..
Dave.
2) With current drm CVS: When starting Xgl I get
[4296305.078000] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset
failed range check (reg=4e28 sz=1)
[4296305.078000]
2) With current drm CVS: When starting Xgl I get
[4296305.078000] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset
failed range check (reg=4e28 sz=1)
[4296305.078000] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
and I may have missed a patch chunk.. should be fixed
Hi. New to hacking on the DRM so I may be seeing something wrong:
drm_bufs.c:drm_addbufs_pci doesn't set buf-bus_address. Is this correct or
a bug? If it's correct, what should I be using to pass the system memory
address to the card for DMA?
Try the attached patch, I haven't tested it
One can hope that despite the newness of X1600 chip some of the basics (like
video mode setup) would remain similar enough to have partially functioning 2d
driver.
The memory, PLL and 3d parts are pretty much the same, the 2D core is very
very different, I'll be getting one soon, expect some
libGL error: drmMap of framebuffer failed (Invalid argument)
libGL error: reverting to (slow) indirect rendering
I've been wondering about this, I mentioned it to Alan + Keith at XDC,
I've had to patch my libdrm to be okay with an 0 length mmap,
Something like I'm sure TG have done something
On 1/31/06, Dominik Brodowski [EMAIL PROTECTED] wrote:
Hi,
Something strange goes on when I try to switch more than two times between
gnome themes using gnome-theme-manager: the X server is killed -- that also
happens with 2.6.15, and that is surely an userspace bug, and the login
manager
This is due to snapshots building X.org drivers from the monolith tree,
the monolith tree is dead so no new devel is done in it.. TG commited
changes to the i810 driver for rotate which changed the size of rec...
re-doing snapshot to use the modular tree is a bit of work though..
Dave.
On Wed,
Dave Airlie [EMAIL PROTECTED]:
This is due to snapshots building X.org drivers from the monolith tree,
the monolith tree is dead so no new devel is done in it.. TG commited
changes to the i810 driver for rotate which changed the size of rec...
re-doing snapshot to use the modular tree
This is due to snapshots building X.org drivers from the monolith tree,
the monolith tree is dead so no new devel is done in it.. TG commited
changes to the i810 driver for rotate which changed the size of rec...
re-doing snapshot to use the modular tree is a bit of work though..
If
DRI, from Mesa CVS, still builds, but falls back to indirect rendering since
it needs DRM 1.22.x to run.
Isn't it possible to only make newer functionality in the DRI drivers depend
on newer DRM? This way, users stuck with a particular version of the DRM
still have functional DRI drivers,
Kay pointed out today that the drm code creates a dev file in sysfs,
yet doesn't tell the driver core about it. Normally this would be just
fine, as you are exporting the value in the proper style, but now there
are programs that are only watching the hotplug/uevent netlink messages
and not
Hmm is that a PCI card or AGP?? I just got a PCI 7000 and I checked the
fixes in to make it work into the kerne, must check they went into DRM
CVS..
Dave.
On Tue, 17 Jan 2006, Helge Hafting wrote:
For years, this card would simply hang the pc a few seconds after
starting up X with DRI:
dri enabled). Once it gets that far it seems perfectly stable to use,
including 3d.
does either
Option ColorTiling false
or
Option DynamicClocks false
help at all?
Dave.
More details are here:
http://bugs.debian.org/345729
I have update my kernel to 2.6.15-mm2 and installed udev.
I have agpgart compiled into the kernel while drm is a module.
The following two lines are the end of dmesg output, nothing else in
that output is related to agpgart or drm.
[drm:drm_fill_in_dev] *ERROR* Cannot initialize the
Hey all,
I took these register dumps from my Radeon Xpress 200M using the hw_script
program and the read_radeon_pcie.scp script. One is from a clean startup, and
the other one was taken from an X session. If there's anything else I can do,
let me know, I'm eager to help.
So these chips
Dave Airlie: Can we get those DRM changes pushed into 2.6.15 or is it
too late for that?
2.6.15 has been released yesterday.
D'oh!
Dave Airlie: Can we get those DRM changes pushed into 2.6.15.1 or are
the changes too big for that?
Way too big... they do a lot of things
Reverting that one change seems to have done the trick:
okay I reverted it in CVS..
Ben is going to come up with a better way to do this stuff..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
devices on the same PCI device...
I wanted to get myself linux kernel updated to latest DRI code, but I
don't know what to do to be generally productive, i.e. so those patchese
may be merged into kernel tree.
I figured that Dave Airlie is managing the kernel.org version of
drivers/char/drm
Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for
development work on this project. I have some kernel hacking/driver
development experience, but that was on a device with open specifications, so
I wanted to ask the following questions:
1) What do we currently
I have been working on adding vblank synchronization to the i915 driver and
I'm running into a performance problem. I was hoping someone that has done
this type of thing before might have run into this problem with another
driver.
You might like to take a look at
On a quick glance (though I'm not familiar with that driver), it looks to me
like introducing texture rectangle caused mipmaps to be disabled for
compressed textures.
oops, my bad.. I've checked in the fix.. thanks,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied /
I was just getting Xglx GLX support working again, Xglx builds it GLcore
using the USE_MGL_NAMESPACE, however my r300 driver was calling the GLcore
version of a the glapi functions and variables..
The patch below is required, the glapi.h changes are probably okay, the
glapi.c changes I'm not
As long as the texcoords at all four corners are being translated the same
amount, I wouldn't expect any differences in interpolation along the shared
edge for the two triangles.
If you've got a simple test program, perhaps some of us can test w/ different
hardware.
Still looking at small
Still looking at small test program.. but changing the GL_QUADS to two
GL_TRIANGLES seems to solve the problems.. mayve the M7 has some
degnerating problems..
Or maybe it doesn't support HW quads as ajax pointed out, and the sw quads
have some problems..
Dave.
--
David Airlie, Software
If you take a look at
http://www.skynet.ie/~airlied/butns.png
you'll see the same texture being drawn in two places, however the second
one is corrupt along the triangle join line...
the only difference between the two is the glTranslate called before them
moves the centre point to a different
No ctx-FragmentProgram._Current!!
drmRadeonCmdBuffer: -22 (exiting)
dmesg shows:
[drm] Loading R300 Microcode
[drm:r300_emit_carefully_checked_packet0] *ERROR* Register 4500 failed check
as flag=00
[drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
My bad, texrect needs a newer
I'm a bit rusty on the DRM but it looks like the changes are minor so
I may do the updates unless someone beats me to it, or indicates
there's a reason for things as they are.
I'm still catching up on email from the holiday weekend, but I plan to import
a new libdrm into the monolith
I like to upgrade mach64 driver for inclusion in kernel and
desire a datasheet.
You'll need to get ATI to give you it, off late ATI have been ignoring
most requests from individual developers
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Current cvs does not build as part of kernel. There are
major changes since in-kernel version. I want to
build in kernel space by kernel make together with other
drivers.
Get current CVS, don't worry about the kernel, you don't want to bother
20050718 snapshot is close and builds after
I made a fix to the locking code in main drm a couple of months ago.
The X server tries to get the DRM_QUIESCENT lock, but when the wait was
interrupted by a signal (like when you move a window around), the locking
function returned without error. This made the X server release other
Looks good.. but dude diff -u plz
I can't read context diffs to save my life...
Dave.
On Wed, 23 Nov 2005, vehemens wrote:
I appear to of eliminated my remaining lockups by also idling the 2D engine in
radeon_cp_indirect which is being called from the xserver. Here is my latest
patch.
Log message:
Fix cpu_to_le32 same as kernel not sure it is correct for ppc
Looks correct, but as the PCIe GART table is in the framebuffer, the
card's byte swapping needs to be disabled for this.
Yes thats what I wanted paulus/benh to check out, I was unsure how the
swappers were
As a side note, I wonder it it wouldn't be worth defining a dedicated
macro for this one DRM_INFO() call, as you seem to be willing to have
the very same format for all drivers.
You should really look at DRM CVS, where this code is cut down
considerably and is going to be pushed into the
I got a warning and while going to fix it, I discovered some issues with the
code (including raciness).
While compiling 2.6.14 for x86_64, I got:
CC [M] drivers/char/drm/drm_bufs.o
/home/paolo/Admin/kernel/6/VCS/linux-2.6.14/drivers/char/drm/drm_bufs.c: In
function `drm_addmap_ioctl':
The current CVS has changed the whole way this is called.. I'll be putting
that patch into git for 2.6.15 soon..
Dave.
On Fri, 28 Oct 2005, Jean Delvare wrote:
Hi David, all,
Looks like the PCI names database removal was done in a rush on the
drm front. I propose the following cleanup.
I guess I don't see a problem with putting it in libdrm. I had just
assumed that the user-mode portion would end up living in
src/mesa/driver/dri/common or some place similar. There are some
advantages to putting it in libdrm, though (e.g., easier for EXA to use it).
Well the X server (EXA
I've been thinking a bit about this, and while I think Ian's work on the
memory manager has merit I'm starting to think we are really putting the
cart before the horse in some ways
My thinking on this is that the memory manager needs to live in libdrm,
not like the current bits in Xorg DDX,
Does this patch help? It's somehwat overkill I guess always updating the
texture matrix when the _NEW_TEXTURE flag is set (though the r200 driver does
exactly that, not quite sure yet why), but I think currently the
update_texturematrix function may not get triggered if a texrect texture
Hi Roland,
Just to reconfirm what I said on IRC, I put my M7 back into my
machine and my internal application is defintely broken with the latest
radeon texrect changes...
I'll leave the M7 in for a few days and I'll have a look at the code if I
get a chance..
Dave.
--
David Airlie,
Thanks! I downloaded and compiled xorg and mesa from cvs today. Now if
I try to start X with dri active the computer locks up, and it's a
hard lock-up -- I can't ssh into the machine. Nothing special appears
in the syslog, and the xorg log does still say that dri is disabled
for some reason
I plan to release Mesa 6.4 fairly soon. That'll get imported into
the
X.org tree.
On http://dri.freedesktop.org/wiki/Building is write The Mesa drivers
now require libdrm to be installed.
This is correct for Mesa 6.4 or libdrm will stay only on Mesa HEAD ?
No both of them need
DXT apears very stable (does not crash/lockup) but I experience corruption
(dansing colored tiles) when (semi)transparency is used in a DXT game
Neverwinter Night.
http://megahurts.dk/rune/stuff/image_DXT_transparency_err.jpg
Yeah I've got NWN here.. must put in on my laptop at some
I think the single most important point is to explicitly disallow
vendor-supplied libGL binaries in the LSB. Every other LSB componenet
relies on a single backing implementation for a reason, and in practice
the Nvidia libGL just causes endless pain where people acceidentally
link against
is loaded before the radeon kernel module.
I get this error with linux-2.6.13 and 2.6.9 both with agpgart and
uninorth driver built in. The drm module is from cvs, and I've tried
with xorg-6.8.99.15 and cvs. I'm running on a powebook5,2 with r300
card. You can find some logs and
ok so this brings the question: how does naming it DRM_ARRAY_SIZE make
it more portable than naming it ARRAY_SIZE?
If *BSD doesn't have ARRAY_SIZE, then surely naming it ARRAY_SIZE is
easy for them to provide (after all they need to provide it already just
called DRM_ARRAY_SIZE); if they
I was talking to Ben on IRC about this and I realised I wasn't really sure
about this..
At the moment we allow the DRI client full r/w access to the framebuffer
if I'm not mistaken (for software fallbacks and the like)..
If I put the PCIE GART table into fb memory (which I've no choice in), the
drivers/char/drm/drmP.h defines a macro DRM_ARRAY_SIZE(x) for
determining the size of an array. kernel.h already provides one.
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Nak.
We have DRM_ for cross platform reasons in DRM, I could in theory get rid
of all of them in the kernel, but it
On Sun, 25 Sep 2005, Dieter Nützell wrote:
Worked for ages.
What shall I do, since I have a brand new Radeon 9550?
Yes, my system would be updated to SuSE 10.0 (2.6.13+), soon.
Can you try it now , I added __ATTR to the backwards compat header file...
it should build I think..
Dave.
--
Can you try it now , I added __ATTR to the backwards compat header file...
Where?
Sorry it should be in drm_compat.h now.. I hadn't noticed the commit
failed because my tree wasn't up to date..
Dave.
---
SF.Net email is sponsored by:
It doesn't have the intimate knowledge needed to properly configure
MTRR's and fails in many cases.
I don't think we can really just nuke support for them, maybe we should
fix the support if we can... the problem I have is removing them will
signiciantly slow down a lot of working systems..
Not sure what to do there.. have to ask the fb devel guys..
Ben ?
I'm not sure if Antonio Daplas is on this list.. they are all on
[EMAIL PROTECTED]
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
But the *fb drivers do provide a nomtrr option in many cases. (But I'd
like to remove it from them too :-) or at least default those to off)
Sounds sane. Nvidia posted some patches a while ago that seem to be
getting kicked around a bit again to add support for PAT (per page
attributes)
I should have some time next month.
Well, you get the idea - there is still much fun to be had with this
driver :)
Sure, much fun would come from a proper memory manager *if* it never gets
done.
I'm hoping to get s3tc/texrect support for r300 over the next while, the
texture
I was going to suggest that this might be related to Paul MacKerras'
texture upload fixes for r300 on big endian machines, but they don't
seem to be in DRM CVS yet. Are they only in the kernel yet? Which DRM
are you using?
They should be in DRM CVS, they came along with the r300 import,
Okay I've completed the PCIE support for the r3xx and r4xx radeon cards,
It needs a new DRM and DDX, as I've had to move the PCI GART table into
framebuffer RAM, so the DDX needed an update.
Also for normal non-PCIE radeons, this code should work to move the GART
table into FB as well which
I'm hoping I didn't break standard PCI GART on r128...
Can it be checked on plain AGP r128 card (with Option BusType PCI)?
Yes BusType on r128 should be good enough to check I didn't break it...
I didn't implement table in FB for r128... I've no idea if it would work
or not...
Table in
Hi!
Where can we get the new code?
Thanks!
X.org CVS and DRM CVS, the Mesa driver needed no work.
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
On Thu, 8 Sep 2005, Daniel Estévezz wrote:
El Jueves, 8 de Septiembre de 2005 00:38, escribió:
You should use David Airlie kernel DRM (which is in current Linus
git top of tree) along with the following patch in case it didn't
make it yet:
OK. I have downloaded the project
If other people has got to compile it, the problem should be in my
computer. Where could be the problem? hardware? compiler? kernel? a
corrupted file in my CVS tree? which one?
try this patch (works for me):
I've just checked this in to X.org tree..
Thanks,
Dave.
--
David Airlie,
Support for ATI_fs will be enabled automatically if texture_units is set
to 6 (there is simply no useful way to expose this with less units).
Are these really related? My understanding is that texture_units is
about the number of 'traditional' GL texture units exposed, and that
this is
With the root only/master split the flags looked ugly
Any objections to a cleanup along the lines of this patch?
Index: bsd-core/drmP.h
===
RCS file: /cvs/dri/drm/bsd-core/drmP.h,v
retrieving revision 1.68
diff -u -r1.68 drmP.h
At current count we need 6 ioctls for the memory manager. However,
there are only 5 available ioctl numbers available below 0x40. Is it
possible to use numbers above 0x79?
I count 0x08-0x0f, 0x1e-0x1f, 0x2d-0x2f, 0x3b-0x3f, or 18. While it
should be doable to use numbers 0x80 and up,
. Dave Airlie was working on it at one point however.
I've put it on hold for modularisation and memory manager work as it would
be much easier to get this done with some sort of memory management..
I don't really like the idea of reserving chunks of VRAM on the off chance
someone might use it..
I have
the allocation failures when the kernel
needs to back up the data. If the memory isn't pinned, it can get paged
out, and, apparently, the kernel can page-in user pages in the way that
we want. Dave Airlie made some comments about that, but I don't
remember exactly what he said.
I've thought
I found why my G5 was crashing when using the linux-2.6 version of the
DRM + git-drm.patch from 2.6.13-rc6-mm1, but not with the CVS DRM.
The reason was that dev-agp-cant_use_aperture wasn't getting set,
and the reason for that was that linux/version.h no longer gets
included and the #if
nope a working PCIEGART isn't the same as a working PCIGART, I have
all the information I think I need (though an R42x 2D programmers guide as
opposed to the R42x regref would help a bit), I just can't connect the
dots... I also suffer from the fact that fglrx doesn't work on my PCIE
My understanding of bus operation is that it's sole function is to
provide memory mapped IO, IO ports, and interrupt control, after these
features are configured -- by the BIOS -- software only has to worry
about the device at the other end... After this initial configuration,
so I thought,
In for a penny in for a pound, (old saying..) i.e. if I could do that I
would have working 3D... the CP crashes on startup...
I assume that you have a version of PCIGART working, right ? You can test this
using MMIO by doing bitblt from GART memory to video memory, for example.
nope
What I meant is to get 2d working using DRI driver (i.e. submitting commands
using CP engine, rather than MMIO registers as happens without DRM driver
loaded).
In for a penny in for a pound, (old saying..) i.e. if I could do that I
would have working 3D... the CP crashes on startup...
just
still works...
Define pure 64-bit. AFAIK, the only truly pure 64-bit system is that
Alpha, but I don't think that's what you mean. :) Do you mean 64-bit
kernel 64-bit X-server?
Well a 64-bit kernel and 64-bit X and 64-bit glxgears linked against
64-bit libGL with a 64-bit radeon_dri.so
Thanks for committing the fix but you missed few things. Additional
fix is attached. I am not sure this is right thing to do but it
seems to work.
I've talked to Eric and it isn't really clean, he wants to come up with a
better way .. we may need to add another DRM macro... personally I'd
I've just rebuilt everything from CVS on my x86_64 box:
- X starts with direct rendering enabled (it used to
crash just a few days before);
- The latest Mesa appears to be out of sync with DRM:
ERROR! sizeof(RADEONDRIRec) does not match passed size from device driver
- Using
If anyone has a pure 64-bit system with a working radeon DRI setup, I'd
really appreciate if they could test 2.6.13-rc5-mm1 and see if radeon
still works...
I'm getting a report that I would like verified, but I've got no 64-bit
systems so I rely on the people who do to help out if they want a
Hi all.
I've just checked into CVS, a patch from Egbert and Paul that
allows us to change the drm_handle size to 32-bits however I'm not sure
what to do with the BSD people...
We want to change the handle to unsigned int Should we just ifdef
around it for BSD?
Dave.
--
David
I suggest testing a 2.6.12 not a 2.6.13, i think something might be wrong with
2.6.13 (IIRC i see people complaining on lkml or on dri user) a change in API
a regression somewhere... But it could also be a 64bits issue not
seen before :)
I'd appreciate if someone could test with
DRI, and therefore hardware accelerated 3D, is *not* supported on Solaris.
^^
re-read and go back to xorg lists...
Dave.
Definetively not ? However, i don't readed this in the several .def and .cf
files of the
In this function there is a section in an if (IS_R300_VARIANT) which returns,
and later in the function there is another section setting display
priorities for IS_R300_VARIANT
something is wrong there...
Dave.
---
SF.Net email is Sponsored
Note, the r200 supports a lot more buffer formats, but these are the
only ones valid for scanout.
What does scanout mean?
the sending of a graphics buffer from VRAM to monitor via a CRTC... CRTCs
only support certain formats...
Dave.
--
David Airlie, Software Engineer
restricted to the first process that opens the DRM device. Of couse
that process may not be an Xserver.
Can people add notes about possible security problems with each of these?
You've missed all the driver ioctls.. please make a list of current driver
ioctls that need root as well..
I'm
I pinged daniel and he seems to have fixed it.. it is the same a/c you
us to work on xorg...
Dave.
On Sat, 30 Jul 2005, Vladimir Dergachev wrote:
I submitted a bug requesting CVS access a while ago, but it has not changed
since - could someone knowledgable take a look and let me know what
a) should it work? (given I don't really care about backwards compat)
b) do I still need to use glxMesaAllocateMemory and friends?
It'd probably work fine, it's still a bit of a hack though. Maybe it's time
to really do the work on a proper manager? I'm at a point where I can put a
bit
I'm definitely thinking we need to take Ian's DriMemoryManagerDesign
document and start thinking throught the issues.. it needs to be expanded
to be able to manage all graphics memory, VRAM and AGP, including
framebuffers and all that stuff, every driver using should allocate via
it, no more
Hi, (mainly KeithW)
I'm looking at the current i915 mem manager which shares the LRU texture
area with client side textures which would be useful in my system, as I
want to have the AGP texturing but also some client side textures...
a) should it work? (given I don't really care about backwards
So why can Doom 3 use R200 pixel shaders, and DRI can't?
And we currently don't implement the two extensions on r200 that Doom3
uses, I've still got a 90% finished ATI_fragment_shader done but I've
little time to pick it back up, and the only test code I had was doom3 and
unfortunately when I
I made an additional modification to the source: there is no
implementation of drm_device_is_pcie() for FreeBSD so I just put
dev_priv-flags |= CHIP_IS_PCIE into radeon_preinit(). I have tried both
with and without this patch and only the pure, clean CVS but nothing
works.
FreeBSD support
Egbert pointed out one of the r128 ioctls (getparam) is declared IOW when
it should be IOWR of course changing this would break userspace...
I've commited a fix which makes the old ioctl GETPARAM_OLD and makes a new
GETPARAM ioctl with the correct direction..
but after thinking about it this
Egbert pointed out one of the r128 ioctls (getparam) is declared IOW when
it should be IOWR of course changing this would break userspace...
I've commited a fix which makes the old ioctl GETPARAM_OLD and makes a new
GETPARAM ioctl with the correct direction..
but after thinking about it
Replace custom wait-queue usage with
wait_event_interruptible_timeout(). This required some more complex
return code evaluation, but simplifies the loop itself to one statement.
I need to know if this patch has been tested on real hardware, the i830
driver is in maintenace mode only, and I
I've made a patch against the DRM code in CVS adding a few pieces that
were missing.
The code works for me on both radeon and r128. I've also tried to test
mga however the mga code in CVS doesn't seem to work at all right now.
My guess would be idr's changes might need some compat work .. no
On Tue, 12 Jul 2005, Adam Jackson wrote:
http://people.freedesktop.org/~ajax/libdrm/libdrm-1.0.0.gz
I'll soon be switching Mesa to require this to build the DRI drivers and the
DRI-capable libGL. This means you need pkg-config.
This also means we can get rid of the copy of the drm source
Now my problem at the moment is I can't get fglrx to work on my X300 at
all either, it hangs... (XP works fine..), I'm going to install FC3 as
well as ubuntu just to get a second opinion :-)
Well all the latest pcie code is in r300.sf.net drm, it still doesn't work
for me, and I've ran
Okay I know the radeon has a slightly wierd 0..1 instead of 0..[wh],
why does this cause a fallback to non-tcl? can the hardware not do it or
are we missing something in Mesa to let it ...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux
On my x86 laptop I get
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 915GM Chipset.
agpgart: AGP aperture is 256M @ 0x0
This machine doesn't have an AGP card, just a PCI Express ATI Radeon
X300..
However when the DRM loads it attempts to setup an mtrr at 0, which of
The DRM has wrappers for these function due to it being used on other
OS'es (BSD mainly)
yes and? how about naming that wrapper kcalloc() instead which
would make the linux wrapper empty and the bsd wrapper just trivial
las well ?
drm_calloc doesn't have the same interface as
The DRM has wrappers for these function due to it being used on other
OS'es (BSD mainly)
However I will accept that the drm_calloc function should now just
called the kernel kcalloc function and this could probably be moved to
an inline in drm_memory.h
I'll code up something and put it my
There are three DRI drivers with no DRM. What is up with these?
gamma
s3v
trident
Well gamma did have one but its got hosed as it wasn't very pretty and
responsbile for a lot of pain.. but keeping the dri driver building isnt
too much hassle.. and you never know someone out there might want
Dave, if you cannot test this why do you want to port my code
to Paul's sceme - which seems to be much more error prone than
using my sceme?
As Pauls scheme was written from what I could see from a kernel
developers point of view, it is maintainable for other kernel developers..
reviewing it
801 - 900 of 1423 matches
Mail list logo
