On Sun, 2005-06-26 at 21:25 -0400, Jon Smirl wrote:
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
Are you saying this:
if ((offset=dev_priv-fb_location)
(offsetdev_priv-gart_vm_start)) return 0;
is more readable than:
if ((offset = dev_priv-fb_location
it was with and without old-dma, and also with
ForcePCIDMA.
The diff is about +190, -390 lines. Anyone want to review it first,
since I have a tendency to under-test on linux?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
address space, like you do for color/depth offsets, right?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy
On Tue, 2005-06-21 at 16:56 -0400, Vladimir Dergachev wrote:
On Tue, 21 Jun 2005, Eric Anholt wrote:
On Tue, 2005-06-21 at 14:57 -0400, Vladimir Dergachev wrote:
/* Texture offset is dangerous and needs more checking */
ADD_RANGE(R300_TX_OFFSET_0, 16);
I don't
concerned by the handwaving involved in how apps are going to
interact with mode setting (yes, I do want to be able to have my video
game switch to 1280x1024), but I have nothing concrete to offer either.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org
for review first? I've got a patch
to clean up map handling that I'm working on, and I'd like to avoid more
mess. I'm not clear on why you need a new map type, if it's going to be
treated like DRM_SHM everywhere.
--
Eric Anholt [EMAIL PROTECTED]
http
files:
drm/linux-core/:
Makefile.kernel
drm/shared-core/:
radeon_cp.c radeon_drv.h
Removed files:
drm/linux-core/:
radeon_i2c.c radeon_i2c.h
Thank you!
--
Eric Anholt [EMAIL PROTECTED]
http
wrong, which OOM killing this hypothetical small daemon
certainly should qualify as.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF.Net email
find
interesting.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
launches of GL apps.
I see this on my R200 on amd64, as well.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
with it, check and see
if the app caused a copy on write, if so free the page, else just
remove the COW flag.
Is there evidence that this is/would be in fact faster?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
is the reason for DRI not supported?
This is SiS 315-series hardware, which we have no 3d information on.
I've certainly looked and tried to get it.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
On Wed, 2005-01-05 at 17:04 +0100, Roland Scheidegger wrote:
Keith Whitwell wrote:
It's a little tricky - I guess you'll need some way of informing the
kernel which way it is supposed to calculate crtc1_base, either by a new
call to the SET_PARAMETER ioctl, or via the ABI version setting
is slower than software indirect GLX, if I
remember right.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
Mesa CVS is back in place thanks to Keith. Now someone needs to review
dri/drm for changes.
/me returns to homework
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Thank goodness for the 22nd
Just a heads up -- it appears that fd.o was compromised as of about two
days ago. Daniel has taken it down while he and a few others check out
the extent of the damage and verify that nothing nastier than assisting
in the distribution of spam happened. Sorry for the troubles. :(
--
Eric Anholt
One of our developers who is working with a non-gcc compiler has asked
if we could convert __FUNCTION__ usage in the drm to __func__. __func__
has the benefits of being shorter, being c99, and still being just fine
for gcc 2.95. Any opposition?
--
Eric Anholt
On Sat, 2004-11-06 at 16:27, Randy.Dunlap wrote:
Eric Anholt wrote:
One of our developers who is working with a non-gcc compiler has asked
if we could convert __FUNCTION__ usage in the drm to __func__. __func__
has the benefits of being shorter, being c99, and still being just fine
. This is CVS, you don't rename,
sorry. The names aren't that bad, though.
I've made some progress on converting BSD, but when I got to the linux
code added to the shared radeon driver code, I lost motivation.
Hopefully I'll get back to it soon, but it's pretty frustrating to work
on.
--
Eric
? That would let you
sleep waiting for them (rather than spinning, a win in itself) and you
wouldn't have to hold the hardware lock.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
the register before the commit of the ring write pointer,
supposedly due to some PCI write posting interaction that caused hangs.
Might be related to this issue, might not, or it might have been some
other issue and that extra read isn't necessary any more. Just throwing
this out there.
--
Eric
as thoroughly tested as previous ones. YMMV.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide
On Tue, 2004-10-12 at 15:18, Roland Scheidegger wrote:
Eric Anholt wrote:
This one is nowhere near as thoroughly tested as previous ones. YMMV.
Certain textures in ut2k3/ut2k4 are still broken (all ground textures in
dm-antalus). Water reflection in the same map is also broken
in r200-projtex-6.diff);-)))
Those two exit errors (which also happen in quake3) are due to my broken
hack to disable vtxformat. My next step with this is to figure out what
exactly to do to vtxformat to make things happy again (and hopefully
swtcl projtex, too).
--
Eric Anholt
On Sun, 2004-10-10 at 10:13, Andreas Stenglein wrote:
Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt:
http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff
#4 had broken nontcl quite significantly. I'm thinking I just stomped
some of my changes with another editor window
On Sun, 2004-10-10 at 13:50, Dieter Nützel wrote:
Am Sonntag, 10. Oktober 2004 21:56 schrieb Eric Anholt:
On Sun, 2004-10-10 at 10:13, Andreas Stenglein wrote:
Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt:
http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff
#4 had
other things, trying to initialize it with r100 or r200 microcode
will probably make it explode in your face. Now, if this was part of an
attempt at getting http://r300.sf.net/ stuff working on FreeBSD, that'd
be another thing :)
--
Eric Anholt[EMAIL PROTECTED
;-)
It's working for myself and Roland. What build system are you using? I
only added the USE_EXTERNAL_DXTN_LIB=1 define in Mesa linux-dri (and
therefore linux-dri-x86) target. If you're using something else, you'll
have to add the define to whatever CFLAGS there.
--
Eric Anholt
On Fri, 2004-10-08 at 13:40, Marcello Maggioni wrote:
On Fri, 08 Oct 2004 13:23:03 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
On Fri, 2004-10-08 at 08:41, Dieter Nützel wrote:
Am Freitag, 8. Oktober 2004 17:37 schrieb Felix Kühling:
On Fri, 8 Oct 2004 17:10:35 +0200
Dieter Nützel
On Fri, 2004-10-08 at 15:14, Mikhail Teterin wrote:
Eric Anholt wrote:
On Fri, 2004-10-08 at 11:17, Mikhail Teterin wrote:
Hi, Eric!
Can this be assigned back to you? I have another pair of PCI IDs,
BTW, and I am sure, there are people with shiny new Radeon-9800 out
there too
-with-fog? You won't end up doing the
install_attrs again like you want. For Rage 128, I just stored the
index in the context and checked if that had changed, instead of the
vertex format register's value.
--
Eric Anholt[EMAIL PROTECTED]
http
and maybe getting code that's about as good for their particular
machine (if they get lucky).
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net
field. I should
get some sleep before I trying to fix any more bugs.
Ouch. Indeed. I wonder how expensive tnl_install_attrs is -- might we
want to just always do it?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL
.
I would really like this.
BTW, r128_vb.h is now an empty file. Couldn't it be removed?
Yeah, it was left over from applying patch and forgetting to cvs rm.
Done now. Thanks!
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt
debug functions? I would be
inclined to see them go away.
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide
in the kernel that we've been saying was necessary
anyway and avoid unconditionally requiring AGP.
I would prefer to see the changes for the core live in shared/ like
always and have the current directories disappear, but it's not a big
deal.
--
Eric Anholt[EMAIL PROTECTED
be
good to see this disappear.
Though the drivers don't rely on it, I don't know if the server-side code
persists in setting it up regardless, which might make it hard to get rid of.
SiS relies on context ctor/dtor (dtor only, when I'm done) for its
kernel memory manager.
--
Eric Anholt
this isn't helping in my tests, but I've got a patch
locally to fix it that'll go in. Reordering state emits seems to slowly
but surely be fixing neverball's intro screen issues. Of those intro
screen issues, all but the eye seemed to be related to the backup emit,
and all seem tcl-related.
--
Eric
it before, and don't
remember at this point, so I'm hoping someone could give it a once-over
before I commit.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
we have any systematic way to
figure this stuff out?
R100 seems OK with neverball.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Index: r200_cmdbuf.c
be legal, note that r200Flush is called from
FIREVERTICES, so that emit state that's happening is probably
necessary. I had noted this with r200Clear, which depends on state
being (semi-?) current at the time of the clear ioctl, and FIREVERTICES
and the racefixes should guarantee that.
--
Eric Anholt
Same thing as for r200, but for r100. Effects are even better,
according to ipers. Anyone want to do some testing before I commit?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Index: radeon_compat.c
On Tue, 2004-09-21 at 22:42, Eric Anholt wrote:
On Tue, 2004-09-21 at 10:41, Dieter Nützel wrote:
Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
On Mon, 2004-09-20 at 12:58, Dieter Nützel wrote:
But got
progs/demos IperS V1.0
Written by David Bucciarelli ([EMAIL
/shared) remains portable to
other platforms without depending on the GPLed bits, which I don't think
is on the horizon at all.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
supports it.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod
On Mon, 2004-09-20 at 15:00, Roland Scheidegger wrote:
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying
On Tue, 2004-09-21 at 10:41, Dieter Nützel wrote:
Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
On Mon, 2004-09-20 at 12:58, Dieter Nützel wrote:
Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel:
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt
)
NOT S3TC related ;-)
About a third of that loss (5% overall), I'd say, is due to my fixes for
the r200 and r100 races. I've got an idea for how to avoid those costs
while also avoiding those races, but I won't be getting to it for a
little while, at least.
--
Eric Anholt
a little more convenient
for some developers, at the expense of all the users who don't want all
of those drivers necessarily.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
(Linux) users.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer
a number from them. I've certainly
heard from over a hundred, and of course that's a tiny fraction of the
total number.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
On Mon, 2004-08-23 at 22:58, Thomas Hellström wrote:
Hi!
Mike Mestnik wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2004-08-23 at 15:24, Ian Romanick wrote:
Thomas Hellström wrote:
As some of you might have read on another thread
offset in the 3d driver, they'd have to update the 2d driver to reset it
when grabbing the lock, bump the DDX version, and check for that version
in the 3d driver and deal with it appropriately.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org
On Fri, 2004-08-13 at 01:45, Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 02:40:19AM -0700, Eric Anholt wrote:
You'll need to use the DDX (i810_drv.o -- the 2d driver) from X.Org CVS
to get the i915 support. Note that the next X.Org release should be out
in two weeks.
Hmm
. That is, unless a release were to
happen from the head branch the next couple of days.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF.Net email is sponsored
X.Org release should be out
in two weeks.
You might get lucky by using mine:
http://people.freebsd.org/~anholt/X/i810_drv.o
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
On Thu, 2004-08-12 at 03:57, Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 02:40:19AM -0700, Eric Anholt wrote:
You'll need to use the DDX (i810_drv.o -- the 2d driver) from X.Org CVS
to get the i915 support. Note that the next X.Org release should be out
in two weeks.
You might
option. The alternate route
is to just port the i810 driver as-is.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF.Net email is sponsored
.
(also note that dri developers can do this :)
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF.Net email is sponsored by Shop4tech.com-Lowest price
Sorry for not telling you when ssh went down/why. My impression was
that it would be back quickly, and I forget that I'm basically the link
between the real admins and dri/mesa. Anyway, it should be back now.
Sorry for the pain.
--
Eric Anholt[EMAIL PROTECTED
replaced it and made it smaller
in terms of code and binary size, 64-bit clean, and (I think) much more
readable. I'm going to take a look at committing it once I can drag
myself away from X.Org, at which point someone with via hardware could
do the same for theirs.
--
Eric Anholt
will be replacing longs
with fixed-size types that are the same on x86, but I haven't looked at
Egbert's diffs yet, unfortunately. As long as you don't use the linux-y
u32-type types, BSD should be happy with the changes.
--
Eric Anholt[EMAIL PROTECTED]
http
-jDRI-XFree86-4_3_99_12-merge -jDRI, resolve conflicts,
place the new code under a BuildDevelDRIDrivers ifdef (see the via
driver), and test. This is what it will take to merge the savage
driver.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org
On Fri, 2004-07-23 at 01:56, Sérgio M. Basto wrote:
On Fri, 2004-07-23 at 05:04, Eric Anholt wrote:
I still need to merge the development drivers
(mach64, savage), but my testbox is down due to a bad floppy and I do
want to test these merges on the appropriate hardware.
yes , I had
be pretty nice to have.
The advantage of the tinderbox route is that we get a pretty nifty way
to look at the logs when the build fails, and better knowledge of just
when the build began failing, should development become active enough
that nailing breakages down within the day is useful.
--
Eric
On Thu, 2004-07-22 at 00:47, Donnie Berkholz wrote:
On Thu, 2004-07-22 at 03:21, Eric Anholt wrote:
OK, so current DRI sources have been merged. Sorry for the CVS logs not
being clear on the mailing list, but what happened was that after I
noticed that the Mesa log was huge I went
(mach64, savage), but my testbox is down due to a bad floppy and I do
want to test these merges on the appropriate hardware.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
I've added the DRI developers that weren't in x.org's list already to
the xorg group so that they'll be able to commit after the next merge
happens.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
ensure that we continue covering compiling of
both paths in trunk by using the tinderbox.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.Net
due to IBM policy, though. Any
updates on that?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.Net email is sponsored by BEA Weblogic
that?)
that .90 numbering is hideous. whats wrong with -preX ?
Yeah, here's a vote for that, as well. And for tarring a snapshot at
this point, if we could.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
one.
That solution sounds worse than the problem -- break all new DDX vs old
libGL for the sake of one (questionable, IMO) DDX's requirement that
could be handled easier with a symlink.
The thing to do, if this feature were really desired, would be to extend
the XF86DRI protocol.
--
Eric Anholt
On Sat, 2004-06-12 at 08:40, Alex Deucher wrote:
On Sat, 12 Jun 2004 16:44:43 +0200, Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote:
I would like to see a merge from DRI CVS to X.Org in the near future.
Is there any opposition
On Sat, 2004-06-12 at 07:44, Michel Dänzer wrote:
On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote:
I would like to see a merge from DRI CVS to X.Org in the near future.
Is there any opposition to this?
No opposition, but a concern: Where are we going to integrate the DRI
is pbuffer support in the mesa hw drivers and some support for
multi-head mode setting. In the xserver on OpenGL model XAA disappears.
--- Eric Anholt [EMAIL PROTECTED] wrote:
I'm working on the Render acceleration -- there were some conformance
issues in the ATI patch that I'm working
someone fix this
include..
Dave.
Go for it. FreeBSD doesn't even have any big-endian platforms supported
yet.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
to remove all traces
of it (from both user mode and kernel mode). Is there any reason not
to? If we need that functionality later, we can design a better
interface for it that will less fragile.
Here's my vote for the axe. I've never seen drmstat.c used.
--
Eric Anholt
do the _tnl_install_attrs because v0 is the same
as it was before, even though the tnl code would have changed to emit
the specular instead of the pad.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
of an
interface without changing anything.
This was part of working to allow removal of old DRM code/features,
which I've been completey distracted from.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
pretty well in Xati (and gives you as many XV ports as you
want), though it lacks the controls typically associated with YUV
conversion using the overlay scaler, like brightness/saturation.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt
, so
setting things to int32s should be fine. I know SiS is an exception,
which I'll fix soon.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
userland and kernel, and nothing else. They are included by both
userland (libdrm, statically linked in the 3d drivers and in the X
server) and kernel.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
directory for `/cvs/mesa/Mesa'
(/cvs/mesa/Mesa/#cvs.lock): Permission denied
cvs update: failed to obtain dir lock in repository `/cvs/mesa/Mesa'
cvs [update aborted]: read lock failed - giving up
Should be fixed now.
--
Eric Anholt[EMAIL PROTECTED]
http
and won't be doing much any DRI work.
Feel free to commit the changes in there, and make any other changes
necessary -- I hoped for this copy of the snapshots scripts to be shared
enough that any DRI folks could fix problems.
--
Eric Anholt[EMAIL PROTECTED
. The cronjob is run from my account, but if you need to turn
that off or otherwise modify it while I'm gone, an admin like keithp or
DanielS should be able to do it.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
. We're working on fixing it. cvsup and
developers' cvs access should work in the meantime.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
The SF.Net
the permissions of the RCS file directly in
the repository. Meta data like permissions is (unfortunately) not under
version control in CVS.
Fixed by chmod a+x /cvs/mesa/Mesa/bin/mklib*. It may not take effect
until the files are checked out again, though (just a cvs up didn't do
it for me).
--
Eric
, but it was decided later that the server didn't need to be
responsible for that and the client driver would do it. So, it's
generally been commented out or disabled.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
wrapping the OS's malloc/free.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast
thinking of just moving the DRM out to a separate module
in the DRI's CVSROOT.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email
On Sun, 2003-12-28 at 21:06, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
don't think Mesa makes any more sense as a home than DRI, since both are
consumers (and the freedesktop.org X Server is now a consumer, too). If
There aren't three consumers: Mesa, xserver and DRI
.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills
that r128 diff on my TODO, sorry for
not trying it yet.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IBM Linux Tutorials
in
Imake.tmpl that is used in the drivers build. It's overridden for
non-FreeBSD in host.def.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net
On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote:
On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote:
On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote:
CVSROOT: /cvs/dri
Module name: xc
Repository: xc/xc/config/cf/
Changes by: [EMAIL PROTECTED] 03
On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote:
On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote:
On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote:
On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote:
On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote:
CVSROOT
of the
latest tree.
Might also be an opportunity to make Mesa-newtree Mesa again :-)
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net
features).
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you
26% /
/dev/cciss/c0d0p8 146897 12940133958 9% /home
/dev/cciss/c0d0p1 19329 155 16% /boot
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
there are issues.
This makes me wonder how difficult it would be to get two servers to
cooperatively share a DRM instance (both of them holding the DRM open,
rather than the reinit thing done before).
--
Eric Anholt[EMAIL PROTECTED]
http
301 - 400 of 515 matches
Mail list logo
