Goyo Roth wrote:
Keith Whitwell wrote:
Goyo Roth wrote:
Mesa has moved some files around. Notably the arb* files that used to
reside in src/mesa/main. They have all been moved to src/mesa/shader
and the arbparse* files have been renamed as well. It's a simple
Imakefile update I think
Goyo Roth wrote:
Mesa has moved some files around. Notably the arb* files that used to
reside in src/mesa/main. They have all been moved to src/mesa/shader
and the arbparse* files have been renamed as well. It's a simple
Imakefile update I think. Additional caveats are the grammar.h
Mike A. Harris wrote:
On Fri, 26 Mar 2004, Mike A. Harris wrote:
In XFree86 4.3.0, and also in current X.org X11, in the file:
xc/lib/GL/mesa/src/drv/r200/r200_pixel.c
[SNIP]
I'm unfamiliar with this particular code, however it seems that
the same calculation being done in
Thomas Hellstrom wrote:
Hi!
I've now implemented the DRM os-abstraction macros from drm_os_linux.h
throughout the driver and, from what I can see, there is no linux
specific stuff left.
My idea is therefore to check in the driver under shared, but update
only the linux makefiles until *BSD
Felix Kühling wrote:
Hi Marcin,
Also CCing to Alex, he probably knows more about this.
Currently the driver looks like it's not supposed to render to the front
buffer at all. When single buffering is used, the driver draws to the
back buffer and copies it over to the front buffer after
Brian Paul wrote:
You don't have to copy from the back buffer to the front buffer until
glFlush() or glFinish() are called. That's assuming that
glReadBuffer(GL_FRONT); glReadPixels(...) grabs pixels from the back
color buffer. If that's not true, you'd have to do the buffer copy
before each
ajax wrote:
... The i810 error is not a build failure but a
runtime failure with glxgears:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 144 (XFree86-DRI)
Minor opcode of failed request: 5 ()
Value in failed
ajax wrote:
On Wednesday 17 March 2004 14:06, ajax wrote:
No problem. I split the branches into current, sleeping, merged, and
obsolete, and added a note about the DRM changes. I'll be adding more to
that list shortly.
Added a few to the list, mostly things I've had trouble with while
Alex Deucher wrote:
Hi!
I've now checked out the new cvs drm module and the via patch I sent
previously applies cleanly with
patch -p1
in drm/linux.
Also compiles cleanly under both 2.4 and 2.6
Is anyone averse to giving Thomas cvs commit access?
No. Let's pester Daniel again...
Keith
Thomas Hellstrom wrote:
Hi!
Here comes the via drm module patch against current (at least as of
today :-) CVS
(/usr/local/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm)
What we've done is the following:
1. Base. Via:s drm Module 0038.
2. Added vblank_wait IOCTL support
Thomas Hellstrom wrote:
Hi!
Here comes the via drm module patch against current (at least as of
today :-) CVS
(/usr/local/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm)
What we've done is the following:
1. Base. Via:s drm Module 0038.
2. Added vblank_wait IOCTL support
Alex Deucher wrote:
--- Thomas Hellstrom [EMAIL PROTECTED] wrote:
Hi!
Via have, some time ago, released a drm module which seems quite
clean
and a dri / OpenGL implementation which Alan Cox fixed up some time
ago
and which is downloadable from your site. I don't think it has been
ported to be
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the
drm tree
You will also need to fix
Ian Romanick wrote:
I spent some time today pulling the DRI interface structures and
function prototypes out of glxclient.h. I came across one snag that I
missed before. It turns out that the bindContext2 and unbindContext2
methods in __DRIcontextRec are passed pointers to GLXContext
Michel Dnzer wrote:
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote:
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
There also seem to be some issues with drivers using CARD32. That
type comes from X, so it should probably be replaced with something
window-system agnostic. Would int32_t work for everyone?
I think this is the best we can do
ajax wrote:
On Wednesday 17 March 2004 05:12, Felix Kühling wrote:
dri branches will also need to apply this patch
I don't like that. Can branches still keep their own copy of the old
DRM? I'm particulary thinking of the s3virge branch which is
unmaintained at the moment. I'm not sure if it even
Daniel Stone wrote:
On Mon, Mar 15, 2004 at 07:24:50PM +, Keith Whitwell wrote:
Jon Smirl wrote:
Could someone with admin privs at fd.o please make a new project and put
the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two
Jon Smirl wrote:
I don't think they are necessary so the _SOLO defines could be extended. Keith
wrote the code so I'm not sure what he intentions were.
--- Dave Airlie [EMAIL PROTECTED] wrote:
The current miniglx fakes up some DDX version numbers but these only work
for the radeon drivers, (4.0)
Michel Dnzer wrote:
On Sun, 2004-03-14 at 07:14, Jon Smirl wrote:
This is a first pass at the three new IOCTL patch.
It is against the DRM copy in the Mesa tree.
And exactly why does that still exist? I know you don't listen to me,
but I don't think you can ignore Keith.
If there's any reason
Jon Smirl wrote:
Could someone with admin privs at fd.o please make a new project and put the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there.
Right now the mesa and dri versions are identical so it
Michel Dnzer wrote:
On Fri, 2004-03-12 at 11:25, Dave Airlie wrote:
It shouldn't be very hard to do this for:
sis, tdfx, i810, i830, savage, gamma
so are we making the Mesa tree the DRM master repo as opposed to the DRI
tree? I don't remember much discussion on this either way,
Indeed, and I
Andy Isaacson wrote:
On Mon, Mar 08, 2004 at 12:29:05PM -0800, Keith Packard wrote:
Stablizing the tree and getting something shipping that people can
distribute is the first priority. I'm sure lots of people would like to
see Mesa/DRI development more closely tied to X driver development so
Mike A. Harris wrote:
On Mon, 1 Mar 2004, Alan Cox wrote:
On Llu, 2004-03-01 at 16:28, Michel Dnzer wrote:
For my part, I'd certainly prefer staying clear of the silly new
license. In the long run, I'd vote for moving the DRI X server code to a
freedesktop.org X server tree and the libGL code
Lots of junk trash talk in here...
Keith
[EMAIL PROTECTED] wrote:
diff -urN /tmp/wiki.zQSGlf/wiki/text/BadGuy /home/groups/d/dr/dri/wiki/text/BadGuy
--- /tmp/wiki.zQSGlf/wiki/text/BadGuy 1969-12-31 16:00:00.0 -0800
+++ /home/groups/d/dr/dri/wiki/text/BadGuy 2004-02-26 09:11:42.0
Keith Whitwell wrote:
Lots of junk trash talk in here...
I see Michel spotted this yesterday. I'm not really clued up enough on wiki's
to know how to revert the edits, but it looks like they're still there.
Keith
---
SF.Net is sponsored
Erdi Chen wrote:
This is a patch to call the context handles destructors and free the
context bitmap entries when a process does not destroy its contexts
before it exits. It saves context handles in a linked list in the
drm_device struct. I decided to use per device list instead of a per
file
Erdi Chen wrote:
This is a patch to call the context handles destructors and free the
context bitmap entries when a process does not destroy its contexts
before it exits. It saves context handles in a linked list in the
drm_device struct. I decided to use per device list instead of a per
file
Dieter Nützel wrote:
Cheers,
Dieter
Probably worth posting this on Mesa lists as it is likely to pertain to the
changes Brian's made recently to the fog code.
Keith
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build
Daniel, Eric -- any ideas?
José Fonseca wrote:
I've put the Doxygen documentation of the DRM work I have done till now
at http://jrfonseca.dyndns.org/misc/drafts/newdrm/. The most
interesting tidbits are the new DMA buffer API described in
Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed that the radeon and r200
Dave Airlie wrote:
So should we just work on getting everything running on newtree then and not
worry about the security issues for now?
Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only issue is though should there be something in
the DRM
Am I missing something -- isn't this setting the appropriate blend
modes? Is the constant color not getting updated correctly?
Yes, exactly, the constant color isn't updated at all (so the color is
_really_ constant ;-)). Mesa would call ctx-Driver.BlendColor to inform
the driver of the
Roland Scheidegger wrote:
Keith Whitwell wrote:
Am I missing something -- isn't this setting the appropriate blend
modes? Is the constant color not getting updated correctly?
Yes, exactly, the constant color isn't updated at all (so the color
is _really_ constant ;-)). Mesa would call ctx
Roland Scheidegger wrote:
Keith Whitwell wrote:
ok, I'll try to implement it. This register is just before the
ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for
the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately
requires a drm change, and unfortunately
Roland Scheidegger wrote:
There's a buffer overflow in XFree86 allowing local attackers to gain
root privileges. Here's the patch,
ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/fontfile.diff the advisory
http://www.idefense.com/application/poi/display?id=72type=vulnerabilitiesflashstatus=false
Mike Mestnik wrote:
--- Roland Scheidegger [EMAIL PROTECTED] wrote:
copypaste job, I didn't touch anything in the code at all (except
replacing r200 with radeon a couple of times...). That said, I
I'v heard this alot so I just thought I'd say even thought it's not my place. Don't
you think
Roland Scheidegger wrote:
Now that I've commited the lighting changes for r200 (still has the
material fallback though), I've wanted to commit the same changes (well
not exactly the same of course ;-)) to the radeon driver too (some brief
testing showed it worked just fine). But I'm a bit
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in the
tnl code? The crashes sometimes are predictable (for instance in the old
ut it'll always crash in the intro when the announcer says in
twenty-two ninety- segfault!)
gdb says this:
Program received
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll
Keith Whitwell wrote:
Dave Airlie wrote:
I think I'll give up for today and go at it again later, perhaps the
i810
just can't do this in hardware and I need to fallback or perhaps the
number of vertices being output is out by one .. who knows :-)
Okay I found it and checked in the fixes
Dave Airlie wrote:
track him down at some point, but for now I'd like to bring the current
branch up to the top of tree at least,
So should I use the mesa tip and start a new mach64 branch on the DRI tree
or should I make a branch on both trees?
oh yeah I'm unsure who brought it up on IRC so if
Roland Scheidegger wrote:
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Roland
(btw sorry if this appears twice on
Roland Scheidegger wrote:
Ronny V. Vindenes wrote:
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are
Michel Dnzer wrote:
On Mon, 2004-02-02 at 23:11, Alan Hourihane wrote:
On Mon, Feb 02, 2004 at 11:09:57PM +0100, Michel Dnzer wrote:
On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote:
On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel Dnzer wrote:
About keeping track of your patches: I wonder
Dave Airlie wrote:
Since Keith's tnl_dd_dmatmp.h patches on the 11 Dec last year, the
poor i810 has been seriously fubar, I've just gotten time to look at it
now (well I've been staring at it on and off for weeks with a blank)
The fix is up at
http://freedesktop.org/~airlied/i810_render_fix.diff
Roland Scheidegger wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
Ronny V. Vindenes wrote:
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without
Roland Scheidegger wrote:
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
This patch causes the driver to no longer use the PREMULT lighting,
instead it will
In driCalculateTextureFirstLastLevel, there's this bit of code:
if (tObj-MinFilter == GL_NEAREST || tObj-MinFilter == GL_LINEAR) {
/* GL_NEAREST and GL_LINEAR only care about GL_TEXTURE_BASE_LEVEL.
*/
firstLevel = lastLevel = tObj-BaseLevel;
}
else {
Ian Romanick wrote:
Keith Whitwell wrote:
I'm wondering if this has been thought through. For the test to work,
this code fragement will have to be re-evaluated whenever
tObj-MinFilter changes, or at least whenever it changes to/from
NEAREST or LINEAR.
I don't think the drivers do
Roland Scheidegger wrote:
(since the original email never made it to the list, a new one - it's
not a resend though)
texrect is broken here (and I've no idea why it works for other people
;-)).
There are 2 problems in the driver which cause this:
First, if glGenTextures is called, there is no
Ian Romanick wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
@@ -888,9 +1070,9 @@
_mesa_lookup_enum_by_nr( pname ) );
}
- if ( ( target != GL_TEXTURE_2D )
+/* if ( ( target != GL_TEXTURE_2D )
( target != GL_TEXTURE_1D ) )
- return;
+ return
Felix Kühling wrote:
I was wrestling with the Mesa build process for a while. Maybe I should
have RTFM. ;-) Anyway, I do get the same error with seccolor.
OK, Ive committed something which should help...
Keith
---
The SF.Net email is
Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
This is a good time to remind people/establish the principle that driver
bug fixes should be propogated to the mesa-6_0_branch of the Mesa
repository. Brian's always done a good job of making sure core mesa
Alan Hourihane wrote:
What I'd really like to be able to do now is build the dri drivers directly
out of the Mesa tree.
Definately. Slate that up for 6.1, I'll certainly work on that issue.
It's not too hard - I had it working on the embedded branch a while ago.
In general, the Mesa make
David Dawes wrote:
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.
Has anyone followed them up?
how should I reproduce the problem?
Start any textured app (e.g. the xscreensaver lament hack) with current
libGL from DRI CVS and current r200 driver from Mesa CVS.
Sorry if I'm being slow about this -- we've had bad mail problems here for the
last few days, so I've been losing mail all over
Michel Dnzer wrote:
On Mon, 2004-01-26 at 10:28, Keith Whitwell wrote:
how should I reproduce the problem?
Start any textured app (e.g. the xscreensaver lament hack) with current
libGL from DRI CVS and current r200 driver from Mesa CVS.
Sorry if I'm being slow about this -- we've had bad mail
Dave Airlie wrote:
Well I've traced this a bit, an operation appears to be hanging the
chipset,
Keith, maybe you can tell me, in i830_span.c you no longer have a HW_LOCK
or HW_UNLOCK defined for the i830 has something happened elsewhere that
makes these unnecessary,
There are the
Felix Kühling wrote:
On Thu, 22 Jan 2004 00:16:52 +0100
Roland Scheidegger [EMAIL PROTECTED] wrote:
[snip]
xdemos/glthreads: I didn't have the courage to test this (I just didn't
feel like rebooting ;-)) - in the past it always locked up immediately
when at least 33 threads were specified, or
Michel Dnzer wrote:
I'm using your http://penguinppc.org/~daenzer/DRI/r200-attenuation-2.diff
patch
So am I; BTW, does everyone agree it's better than the first cut?
Yep.
Index: r200_state.c
===
RCS file:
Roland Scheidegger wrote:
This one-byte patch fixes the endgame xscreensaver (both version 4.05
and 4.14).
Don't know if it's actually correct, but after looking at endgame with
gdb it looked like some likely necessary state updates were omitted.
Reversing the condition when to call the update
Dave Airlie wrote:
Does the r100 support the rectangle textures extension?
or is the driver borked? I have a CVS from a week or so ago and texrect
seems to now function correctly... is this a chip limitation or driver
bug?
The chip supports it, the extension was added fairly recently to the
Dave Airlie wrote:
in the i810/5 manual I have, it mentions bit 31 of dword 2 the MAP_INFO
register allows non power of dimensions, and bit 14 of MAP_COORD_SETS is
whether the set is normalized or not ..
does anyone know if this is possible? I've hacked together
NV_texture_rectangle support but it
I've just committed a change to move the i830 driver to the new t_vertex.[ch]
mechanism for specifying and emitting hardware vertices.
One of the nice things about this mechanism is how easy it is to support a
wide variety of vertex formats -- the intention is that anything you can tell
the
Ronny V. Vindenes wrote:
On Mon, 2004-01-19 at 11:49, Keith Whitwell wrote:
I've just committed a change to move the i830 driver to the new t_vertex.[ch]
mechanism for specifying and emitting hardware vertices.
I had to apply this patch against dri cvs to get it compiling again.
Sorry, forgot
Roland Scheidegger wrote:
Ian Romanick wrote:
I know this is a breach of protocol, but I'd like to discuss the patch
that I have for this before attaching it to the bug report or
committing it.
In both the client-side and the server-side g_render.c I have created
some template macros for
Michel Dnzer wrote:
On Tue, 2004-01-13 at 20:56, Keith Whitwell wrote:
Michel Dnzer wrote:
What makes the difference is calling _mesa_lookup_enum_by_nr() at the
beginning of r200Enable(), probably due to the delay. Granted, it
doesn't help with the reflections, and if those are disabled
Michel Dnzer wrote:
On Wed, 2004-01-14 at 11:33, Keith Whitwell wrote:
What's going on here - is there something the hw can't handle?
+ if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) {
+/* Can't do even constant attenuation, disable */
+icmd[idx
Michel Dnzer wrote:
On Tue, 2004-01-13 at 14:51, Felix Khling wrote:
On Tue, 13 Jan 2004 14:38:37 +0100
Michel Dnzer [EMAIL PROTECTED] wrote:
On Mon, 2004-01-12 at 17:44, Michel Dnzer wrote:
There are still minor problems, e.g. in the xscreensaver endgame hack,
but those might be related to
Roland Scheidegger wrote:
Based on the idea of Felix Kühling that the order in which state atoms
are emitted might be important on the radeon, I thought maybe it might
be important on the r200 as well, even though there are no lockups.
With the attached patch indeed the random color flashings
Michel Dnzer wrote:
I've no idea if the order is really important or if this just hides
another problem, maybe someone with databooks could answer that.
I don't remember seeing any clear information about this in the docs I
have, but your patch is proof enough for me that it does matter. :)
Keith Whitwell wrote:
Keith Whitwell wrote:
Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as
it should.
(projtex is broken somehow on r200, even with only 2 TMUs
Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
(projtex is broken somehow on r200, even with only 2 TMUs)
The patches look ok. I've actually been working
Keith Whitwell wrote:
Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as
it should.
(projtex is broken somehow on r200, even with only 2 TMUs)
The patches look ok
Felix Kühling wrote:
Hi,
this is referring to the a very reproducable lockup that occurred with
glaxium on r100 hardware. Several months ago I tracked it down to
emission of state changes and introduced a workaround that waits for 3D
idle before state changes. Now I had a new idea about a
Ian Romanick wrote:
Ian Romanick wrote:
Log message:
All of the libglx.a and libGLcore.a code now uses __GLcontextModes to
track FBconfigs / visuals.
Just a heads up. The next step will be to enable fake support for
SGIX_fbconfig on the server-side. Basically, I will just assign an
Felix Kühling wrote:
Hi,
I was wondering why flightgear was so slow so I did some profiling and
debugging. And I found out that apperently the entire vtxfmt code path
is not working. I believe the root cause is that radeonNotifyBegin is
never called with current Mesa. So the driver's own vtxfmt
Felix Kühling wrote:
Hi,
I believe I got it right this time. :) I attached three small patches
that re-enabled the vtxfmt paths in the radeon and r200 drivers. One is
for _tnl_Begin to call the driver's NotifyBegin callback again.
Alternatively, if the drivers are supposed to work correctly
Michel Dnzer wrote:
On Mon, 2003-12-29 at 02:45, Jon Smirl wrote:
Would this also be a good time to move the DRM modules into the Mesa tree?
Has it even been decided that's a good idea? I'm not sure it is; their
being separate might help prevent compatibility problems with their
interface, or
Jon Smirl wrote:
The rework of of the dri drivers that I am doing is also dependent on parallel
changes being made in the DRM drivers. I'd like to have them in the same cvs
system so that I can keep things in sync. What the point of keeping them in the
DRI tree if the only client of them now lives
Could this be a problem for r200 (see my VTK problems), too?
But I couldn't find the right place in the r200 code.
You're right, this code is missing in the r200. I've added it in and
committed it.
I've fixed this in _mesa_allow_light_in_model().
Do you have committed?
Yep. Are you having
Felix Kühling wrote:
Here is the patch. :)
On Fri, 26 Dec 2003 19:44:50 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
I fixed two TCL bugs on radeon that appeared after the move to
Mesa-newtree. A patch is attached.
The light_model_cntl thing looks almost like a copy-paste from R200.
This
Felix Kühling wrote:
I recompiled a static Xserver so that could get a backtrace inside the
driver. This is the result:
Program received signal SIGSEGV, Segmentation fault.
0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1,
rop=0xb728) at savage_accel.c:758
758
Felix Kühling wrote:
On Sat, 20 Dec 2003 08:01:07 -0500
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
while working on the savage driver I found two problems. One with
tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both started
since I use different hardware
Keith Whitwell wrote:
Felix Kühling wrote:
On Sat, 20 Dec 2003 08:01:07 -0500
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
while working on the savage driver I found two problems. One with
tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both
started
since I use
Felix Kühling wrote:
On Sun, 21 Dec 2003 09:52:32 -0500
Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Felix Kühling wrote:
On Sat, 20 Dec 2003 08:01:07 -0500
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
while working on the savage driver I found two
Felix Kühling wrote:
Hi,
while working on the savage driver I found two problems. One with
tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both started
since I use different hardware primitives for quads and
triangles/polygons.
TAG(quad) in t_dd_tritmp.h calls RASTERIZE( GL_TRIANGLES
Felix Kühling wrote:
Hi,
after Dieter's last mail I wonder why the environment variable
R200_NO_TCL was revived. I didn't notice this before so I assume this
slipped in during the move to Mesa CVS. Since environment variables can
be used to override configuration options this is really no longer
Felix Kühling wrote:
On Tue, 09 Dec 2003 17:53:14 -0600
David D. Hagood [EMAIL PROTECTED] wrote:
Alan Hourihane wrote:
I'm going to merge the newmesa branch to the trunk in a few moments.
I've giving people a heads up that I'm going to delete the xc/extras/Mesa
directory and insist on people
Felix Kühling wrote:
Hi,
I briefly tried the DRI trunk after the newmesa merge last night. In
flightgear with TCL enabled the old lighting problem seems to be back.
Everything is too dark, but banking to one side makes things brighter.
Can you remember what changed to fix that problem last time?
Jon Smirl wrote:
My current thinking on this is to do it the DRM driver but store the allocation
data in normal system RAM. This would allow the allocation routines to function
without touching the framebuffer.
I would really like to make sure that DRM drivers can function without having to
map
Alan Hourihane wrote:
I'm going to merge the newmesa branch to the trunk in a few moments.
I've giving people a heads up that I'm going to delete the xc/extras/Mesa
directory and insist on people checking out a copy of Mesa's newtree and
people setting that in their xc/config/cf/host.def file to
Jon Smirl wrote:
--- Alan Hourihane [EMAIL PROTECTED] wrote:
So Mesa/newtree is going to be the master copy of the dri drivers, including the
ones in mesa/dri/drivers? I'm all for that after doing the merge a couple of
times.
Yes.
I've giving people a heads up that I'm going to delete the
Jon Smirl wrote:
Did the DRM device drivers get moved too? They generally have to be changed in
tandem with the 3D drivers.
Not yet. Let's just get what we've done working tested.
The DRM drivers have a proper, versioned interface to the driver, so a lot of
the arguments about co-evolution
Alan Hourihane wrote:
On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote:
I'll look at at least the r200 and i830 drivers today.
Keith,
I've done the i830 driver now.
I've also moved over the easy parts of the radeon and r200 drivers, but
there's some significant changes in some
Alan Hourihane wrote:
On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote:
I'll look at at least the r200 and i830 drivers today.
Keith,
I've done the i830 driver now.
I've also moved over the easy parts of the radeon and r200 drivers, but
there's some significant changes in some
Alan Hourihane wrote:
On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote:
I'll look at at least the r200 and i830 drivers today.
Keith,
I've done the i830 driver now.
I've also moved over the easy parts of the radeon and r200 drivers, but
there's some significant changes in some
Alan Hourihane wrote:
On Mon, Dec 08, 2003 at 12:32:00PM +, Keith Whitwell wrote:
Alan Hourihane wrote:
On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote:
I'll look at at least the r200 and i830 drivers today.
Keith,
I've done the i830 driver now.
I've also moved over
Keith Whitwell wrote:
Alan Hourihane wrote:
On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote:
I'll look at at least the r200 and i830 drivers today.
Keith,
I've done the i830 driver now.
I've also moved over the easy parts of the radeon and r200 drivers, but
there's some
401 - 500 of 1368 matches
Mail list logo
