On Tue, 2003-11-04 at 13:47, Otto Solares wrote:
> On Tue, Nov 04, 2003 at 01:19:54PM -0800, Jon Smirl wrote:
> > --- Eric Anholt <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2003-11-04 at 12:25, Otto Solares wrote:
> > > > On Mon, Nov 03, 2003 at 09:09:58PM
ding of
additional maps of the same offset/size doing the same (not necessary,
it was my first attempt). When I get back from class I'll try to clean
it up, port, and commit unless there are issues.
This makes me wonder how difficult it would be to get two servers to
cooperatively share
test DRM changes?
It should be fixed now. The 2nd server, by addmapping the SAREA, was
setting dev->lock.hw_lock to its SHM area and breaking the 1st server's
locking. Now, the addmap attept by the 2nd server will fail, and that
server will not initialize th
>start;
> r->start = 0;
> }
> /* This will disable and set address to unassigned */
> pci_write_config_dword(dev->pdev, dev->pdev->rom_base_reg, 0);
>
> DRM_COPY_TO_USER_IOCTL( (drm_radeon_getbios_t *)data, gb, sizeof(gb) );
&
plus 100Mb of permanent storage per-branch for the local
> CVS checkout. The latter can be ignored, since the repository is on the
> same machine, but the rest is not such a small deal for a machine which
> appears to be dedicated for web and CVS hosting...
I
ld the dri wiki do this? (Note: I'm
not plugging the fd.o wiki here. It has its own set of very annoying
features).
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
ing right now is making an ExpatLibrary definition 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]
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/confi
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
mirroring. I think this is going to get more annoying
as we've moved the DRI driver development to Mesa. Plus, we'd get cvsup
if we moved.
I think the switchover this time wouldn't be so horribly painful, as
I've learned the lesson to just make the switch and bring peoples&
ll have testing 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:
nd pointing the
define in config/cf/host.def at it these days.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IBM
-rel-suffix
*default compress
mesa
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an exp
e
there, or remove it and have XFree86 merge from two different trees?
Actually, I'm 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 PRO
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'
the
> Mesa release include the DRI driver sources?
I'd love to see releases start including DRI driver sources. Then I can
use the official tarballs for the dri package in FreeBSD and give us a
non-ancient "stable" driver set.
--
Eric Anholt[
rapped originally because there was a bunch of
debugging and statistics code for memory allocation. That's been axed
because nobody actually used it, so now they're just left as functions
wrapping the OS's malloc/free.
--
Eric Anholt[EMAIL PROTECT
o clear the back/depth buffers when they got
created, 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]
e files are checked out again, though (just a "cvs up" didn't do
it for me).
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
T
raded the debian cvs package on pdx, overwriting the
local cvs setup. I think. We're working on fixing it. cvsup and
developers' cvs access should work in the meantime.
--
Eric Anholt[EMAIL PR
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 PROT
leaving for 3 months 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
update: Updating Mesa
> cvs update: failed to create lock 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 n
?
These headers being discussed are what define the interface between
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://
, rather than just putting them up as the last
transformation to be applied to the screen before display, as the
overlay scaler would do. I've found that the 3d hardware solves the XV
problem pretty well in Xati (and gives you as many XV ports as you
want), though it lacks the controls typic
I had forgotten that we
maintained separate *_common.h and *_sarea.h. It seems like a waste to
me.
The one thing I ask, for portability, is to use uint32_t and friends,
instead of u32/__u32. It sounds we shouldn't have anything that
requires a pointer (64-bit) to be passed between kerne
version. The DRM changes its behavior accordingly (busid
handling was the first change). Returns EINVAL if unsuccessful, and
returns the actual version numbers of the DRM DI/DD interface, either
way. Request -1.-1 version to just get the version number of an
interface without changing a
est at the end won't 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/
t; BUT nothing uses it. Since it's broken, I'd like 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 v
ve got a change here to
fix it and use fixed-size types in the interface, only in the process I
rewrote the whole thing and axed ~350 lines of code. I'm going to test
when I get back from camping (Tuesday). I bet the same thing I'm doing
for sis could be done
> the problem?
SF Site status:
http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
n FreeBSD 5.x
> because p is a struct thread, not a struct proc.
This was already done in bsd-4-0-0-branch, which I'm hoping to merge to
trunk soon. Sorry for the duplication of work.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.o
ith the change.
The diff from trunk as of a few days ago was:
http://people.freebsd.org/~anholt/dri/files/bsd-4-0-0-diff
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
On Sat, 2003-02-08 at 17:46, Eric Anholt wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/lib/GL/dri/drm/
> Changes by: anholt@sc8-pr-cvs1. 03/02/08 17:46:32
>
> Log message:
> Use the right subdirs for NetBSD.
>
> Modified files:
&
On Wed, 2003-02-12 at 04:23, Adam K Kirchhoff wrote:
> Hey folks,
>
> I'm trying to find out the branch to use for NetBSD. I know that
> Eric Anholt posted it here in the not-too-distant past, but I can't seem
> to find the e-mail from him anywhere (an
lly (much of this stuff is
mechanical changes), and then hopefully provide something pretty to
review for pci_alloc_consistent.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
--
he remainder of the attached patch is trivial additions of
> DRM_ERR, DRM_CURRENTPID, etc. and a couple of whitespace tweaks.
Looks good to me.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
-
I'm currently working on merging bsd-4-0-0-branch to trunk, starting
with the merge to the branch. If things stay quiet on the trunk, that
would be wonderful.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROT
On Thu, 2003-02-20 at 16:30, Eric Anholt wrote:
> I'm currently working on merging bsd-4-0-0-branch to trunk, starting
> with the merge to the branch. If things stay quiet on the trunk, that
> would be wonderful.
Been a busy night and cvs conflicts have been troubling me. I&#
ort on bsd? It seems to fix
> some fundamental braino's in the orignal drm...
It's the second thing on my list, after some mopup after the XFree86
4.3.0 update. I haven't looked at it seriously enough yet. Please give
me a few days to get it at leas
On Thu, 2003-03-13 at 00:51, Keith Whitwell wrote:
> Eric Anholt wrote:
> > On Wed, 2003-03-12 at 05:57, Keith Whitwell wrote:
> >
> >>OK, now that the recycle lockup has been found & fixed, I don't see any
> >>problems with this patch. Has anyo
Does anything use read/write/poll on the DRM? The drm-filp changes will
touch all of the device entry points for BSD, and I was wondering if
these functions are still used/useful in the current state of things.
--
Eric Anholt[EMAIL PROTECTED]
http
most of my questions has been
impossible.
At this point, I'm the only one who knows about the FreeBSD DRM who is
willing to work on it. Because it's DRI related I have been granted DRI
CVS access and can do work there. But if I had been working on
something like this through
that this prevents interrupts from being
reenabled on server reset before the irq handler is readded. But why
does this cause a hang?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
-
e problem I was seeing, if you
were trying to say that. Once in a while after moving the window the
gears would continue spinning at the same offset in the screen as
before, just with the window in a different place. I'll take a look at
that, though.
Another question: the adv
es with
> > the BSDs - Eric?
>
> It should be pretty portable, since it handles any kind of irq return
> value - whether void or not. So the BSD's should be happy with it too.
Looks fine with me. Shouldn't clash with anything.
--
Eric Anho
GIX=glXChooseFBConfig \
> --defsym glXGetVisualFromFBConfigSGIX=glXGetVisualFromFBConfig
>
> That would work, but would it be acceptable?
Or use
static void bar(int) __attribute__ ((alias("foo")));
?
gcc-specific, but probably not worse than doing it with ld.
--
Eric Anh
On Mon, 2003-08-25 at 17:45, Eric Anholt wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/lib/GL/mesa/src/drv/common/
> Changes by: [EMAIL PROTECTED] 03/08/25 17:45:05
>
> Log message:
> Fix config-0-0-1-branch on FreeBSD: expat is loca
d not CVS because I absolutely hate working on branches in CVS. I've
made about 100 commits to sis in my sis branch, which none of you would
have wanted to watch anyway.
--
Eric Anholt[EMAIL PROTECTED]
On Tue, 2003-08-26 at 03:46, Felix Kühling wrote:
> On Mon, 25 Aug 2003 17:58:41 -0700
> Eric Anholt <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2003-08-25 at 17:45, Eric Anholt wrote:
> > > CVSROOT: /cvsroot/dri
> > > Module name: xc
> > > Re
at wasn't done.
I hope nobody minds me making massive style changes on the sis DRM
code. I find it quite ugly at the moment.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/
macro in the mach64, and I'll let someone fix this
> include..
>
> Dave.
Go for it. FreeBSD doesn't even have any big-endian platforms supported
yet.
--
Eric Anholt[EMAIL PROTECTED]
http://peop
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.
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
we
> are missing 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 conformanc
system pars for the ':' and try each 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, woul
(How
> > do we want to do 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.f
tree, at least from our end. I remember there were concerns with
idr being able to commit to the new tree due to IBM policy, though. Any
updates on that?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
be we don't want to use a branch. Here's the idea: We
make the DevelDRIDrivers define in imake include all these new,
insecure, not-guaranteeing-backwards-compatibility drivers, and they're
only turned on when we add #define BuildDevelDRIDrivers YES. For the
D
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/
ript, which I think would 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
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 Mes
more. 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.
--
Eric Anholt[EMAIL PROTECTED]
http://people.
On Thu, 2004-07-22 at 23:00, Adam Jackson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Friday 23 July 2004 00:04, Eric Anholt wrote:
> > The point is that the DRI is merging into X.Org and there won't be a
> > separate tree any more. I still
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 appropria
doesn't compile
>
> give me errors on savage_video.c
> see error.txt for more details .
As I said in the message quoted, someone will need to go to the savage
driver, cvs up -jDRI-XFree86-4_3_99_12-merge -jDRI, resolve conflicts,
place the new code under a BuildDevelDRIDrive
I'm more familiar with).
Once the flames die down in X.Org I'll isolate the diff from my very
dirty local drm tree and post it again.
I'm hoping that most of the general DRM fixes will be replacing longs
with fixed-size types that are the same on
On Sat, 2004-07-31 at 02:54, Arjan van de Ven wrote:
> On Sat, 2004-07-31 at 11:32, Eric Anholt wrote:
> > As long as you don't use the linux-y
> > "u32"-type types, BSD should be happy with the changes.
>
> can you explain why u32 would be outlawed? Surely it
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[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
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 PROT
perhaps best 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
o it after the composite fires are put out.
(also note that dri developers can do this :)
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
SF.Net emai
work (root, regular user checked). Any ideas
> would be greatly appreciated. Maybe some patching need to done in DRI
> support from X server side WRT i915 support?
>
> Thanks. Just for reference, my Xorg.0.log attached.
You'll need to use the DDX (i810_drv.o -- the 2d driver)
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 shou
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 shou
x27;t blessed as a release.
I would like to continue using the current codebase, though we should
probably make it clear in glxinfo (for example) that this is a
development branch we're using. That is, unless a release were to
happen from the head b
inion, the EnterServer for Radeon should
be resetting some of the 2d state that it depends on, as well. As it
is, it looks like if someone wanted to set things like the default
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
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ö
s to move to the fb-ified DRM and it's going to become
the stable version, I would say let's deal with those issues then. Or
just stick your GPL code in drm/linux and not worry about BSD, if it can
be developed in head without disrupting (Linux) users.
--
Eric Anholt
there
are major differences, and people on 4-stable generally just grab the
DRM code from -current since I maintain source-level compatibility.
So this is why you don't really hear complaints from BSD users on
dri-devel. But there are quite a number from them. I've certainly
heard fro
buffers depending on which has
been set up.
But I see nothing in this issue that requires all the drivers live in
one module together, which would only make life a little more convenient
for some developers, at the expense of all the users who don't want all
of those driv
und to dealing with the issue (if ever),
i.e. when we've got accelerated graphics layers for console, I'm quite
sure we'll follow the same model of a relatively generic lock in the
kernel which all graphics clients will use to arbitrate hardware
access).
Please, stop trotting out Lo
ces. 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[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
-
eresting apps besides glxgears handy to benchmark with. Any
thoughts on this? If people think it's a good idea, I'll do it for
radeon as well.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/
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
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
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
> > > >
> > >
ts purposes as the kernel part
of the DRI -- the 3d bits, not the i2c bits or whatever other linux
bits, as long as X.Org and the DRI/DRM (drm/shared) remains portable to
other platforms without depending on the GPLed bits, which I don't think
is on the horizon at all.
--
Eric
E? What about BSD?
On FreeBSD we just use a convenient little sysctl to pull out whether
there's SSE and the kernel supports it.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
--
ect this would 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 guaran
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
had posted 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/
hat things get
emitted less often. Moving the eye emit to the end mostly fixed
neverball's intro screen for me except for occasional flicker, and
in-game seemed OK. Patch attached. Do we have any systematic way to
figure this stuff out?
R100 seems OK with neverball.
--
Eric An
reen issues. Of those intro
screen issues, all but the eye seemed to be related to the backup emit,
and all seem tcl-related.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
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
>
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/~
f);-)))
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[EMAI
e is nowhere near 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:
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 al
read isn't necessary any more. Just throwing
this out there.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT
201 - 300 of 561 matches
Mail list logo
