Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa
Linus Torvalds wrote:
Have others seen this? Current DRI CVS tree, current 2.5.x kernel (which
is pretty current kernel-module-wise, the only difference to the current
DRI tree _seems_ to be the documentation updates).
Same thing happens with an older DRI CVS tree too (with new kernel
modules),
Linus Torvalds wrote:
On Fri, 30 May 2003, Linus Torvalds wrote:
Modulo that, X is happy, with no error messages apart from a mention of
the irq issue in the logs up until the lockup:
(II) RADEON(0): [drm] failure adding irq handler, there is a device already
using that irq
[drm]
I haven't released 5.1 (devel release) yet so 5.2 (stable release) won't
be coming for a while. 5.1 is in pretty good shape though. I'm trying
to decide if I should do the directory re-org before or after the 5.1
release. Thoughts?
I don't see any reason to delay...
Keith
Alex Deucher wrote:
I've been thinking of trying to implement an XV adapter using OpenGL
and MESA_ycbcr_texture for YUV or regular RGB textures for RGB video.
This would not only provide a default Xv adapter (in the event that the
hw didn't have one) or it would provide hw accelerated video
Keith Whitwell wrote:
Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
approaches to doing the re-org:
1. Use the usual cvs add/remove/commit commands to move everything
Linus Torvalds wrote:
On Mon, 2 Jun 2003, Keith Whitwell wrote:
Under what circumstances does this actually happen? First 3d app run? Even
something like 'glinfo'?
I don't even get a desktop - the thing hangs at initialization time
(probably when clearing the screen.
My hardware may
Matt Sealey wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Michel Dänzer
Sent: Tuesday, June 03, 2003 12:42 AM
To: Alex Deucher
Cc: Keith Whitwell; [EMAIL PROTECTED]
Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
On Tue, 2003
Nicholas Wourms wrote:
Keith Whitwell wrote:
[SNIP]
Boy, this looks interesting. Unfortunately I'm about to leave on a
week's holidays so I won't be able to properly read the patch or
comment until I get back. I'm broadly in favour of applying this but
would love to participate
Nicholas Wourms wrote:
Keith Whitwell wrote:
[SNIP]
Boy, this looks interesting. Unfortunately I'm about to leave on a
week's holidays so I won't be able to properly read the patch or
comment until I get back. I'm broadly in favour of applying this but
would love to participate
Adam K Kirchhoff wrote:
For the past 24 hours, I've been having build problems with the cvs trunk:
make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common'
cleaning in lib/GL/mesa/src/drv/r200...
make[5]: Entering directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200'
Makefile:8:
Adam K Kirchhoff wrote:
Well, it doesn't seem to be a false alarm any more. I found out that the
problem with the kernel build is a known issue between gcc 3.3 and 2.4.20.
In addition, I have been able to successfully compile XFree86 4.3.0,
without any problems...
So, anyone else have any ideas
Felix Kühling wrote:
How are performance boxes enabled in the radeon driver? Apperently
setting rmesa-boxes to 1 is not enough. There is a variable
dev_priv-do_boxes in the kernel driver. But it is initialized to 0 in
radeon_do_init_cp and not changed anywhere else. Am I missing something?
No -
Felix Kühling wrote:
On Fri, 30 May 2003 22:03:20 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
How are performance boxes enabled in the radeon driver? Apperently
setting rmesa-boxes to 1 is not enough. There is a variable
dev_priv-do_boxes in the kernel driver
Ian Romanick wrote:
Felix Kühling wrote:
It's not that I need performance boxes. I just came across this
converting environment variables to configuration options in the radeon
driver. There are two more environment variables that don't seem to
refer to working code: RADEON_COMPAT (assertion
Ian Romanick wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
The bottom line is that with a 2.5 kernel, sched_yield() will discard
the time slice of the process, so misuse of it will cause bad
performance.
I guess it's possible that this could be a problem. The yield is
there to allow two
Jens Owen wrote:
My apologies for sending my first reply to dri-devel. This is really a
dri-users configuration issue. However, there is one aspect to this
posting that may be very relevant to dri-devel.
Jens Owen wrote:
I remember a recent change to support a 32 bit depth buffer and I
Jens Owen wrote:
Keith Whitwell wrote:
Jens Owen wrote:
My apologies for sending my first reply to dri-devel. This is really
a dri-users configuration issue. However, there is one aspect to
this posting that may be very relevant to dri-devel.
Jens Owen wrote:
I remember a recent change
Philip Brown wrote:
On Fri, Apr 04, 2003 at 08:43:31AM -0700, Jens Owen wrote:
Possible
Future: Mesa Tree -+-- XFree86 Tree
- API Focus|- X/3D Integration
- 3D HW Focus |- Complete Window System Focus
|
+--
José Fonseca wrote:
On Fri, Apr 04, 2003 at 08:48:35AM -0700, Brian Paul wrote:
In general, this sounds reasonable but you also have to consider
performance.
The glVertex, Color, TexCoord, etc commands have to be simple and fast. As
it is now, glColor4f (for example) (when implemented in X86
Philip Brown wrote:
On Fri, Apr 04, 2003 at 10:09:00PM +0100, Keith Whitwell wrote:
Philip Brown wrote:
Are you perhaps envisioning pushing Mesa to evolve into something
like the nvidia UDA API? Where there is suddenly a single, unified
cross-hardware/OS platform for all 3d-accel hardware
Philip Brown wrote:
On Fri, Apr 04, 2003 at 10:34:05PM +0100, Keith Whitwell wrote:
[Philip Brown writes]
So to truely create something akin to nvidia's UDA libs/interface, would
involve porting support for 3d hardware currently handled by DRI, over to
Mesa, and making mesa capable of using
The things I found more interesting in the issue of applting the TCL
operations on all the vertices at once, or a vertice at each time. From
previous discussions on this list it seems that nowadays most
of CPU performace is dictated by the cache, so it really seems the later
option is more
Brian Paul wrote:
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system
are very mismatched, the immediate API already has an
Ian Romanick wrote:
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
In principle, I think the producer/consumer idea is good. Why not
implement known optimizations in it from the start? We already
having *working code* to build formated vertex data (see the
Ian Romanick wrote:
Before going down that road we'd want to sit down with oprofile and a
bunch of applications to decide which sets of state we wanted to tune
for. IMHO, we'd be better to spend our time writing a highly optimized
just-in-time compiler for ARB_vertex_program. Then we could
So, this is fixed in current DRI CVS trunk -- how should this be
indicated/handled?
Keith
[EMAIL PROTECTED] wrote:
[This e-mail has been automatically generated.]
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=25
[EMAIL PROTECTED] changed:
What|Removed
Dave Airlie wrote:
I've noticed the i830 drivers have a unified memory allocation scheme for
2d and 3d, is there any reason this couldnt be used on the i810?
Is there any major reasons the i830 driver couldn't be usd on the i810
with the functionality it doesn't need turned off?
I'm just wondering
Andreas,
Looking at the code, the FPCOLOR/FPALPHA elements are only turned on when
colormaterial is used -- in all other cases we use a ubyte 'PKCOLOR'
representation.
If we're using FPCOLOR, I don't think that it would be so bad to always turn
on FPALPHA too, as it seems like the current
Linus Torvalds wrote:
I just finished a merge of the current DRI CVS tree kernel parts into
2.5.x. I've not done one of these in a while, so sadly the merge ends up
being several totally unrelated things (i830 irq updates, the lock context
fixes, and various random smaller things).
I've pushed
Linus Torvalds wrote:
On Sat, 29 Mar 2003, Linus Torvalds wrote:
I tested on radeon, and tested by compiling all the drivers into the
kernel. Looked good as far as I can tell. Although I have to say that the
current DRI CVS tree has a lot of flashing textures on the commercial
tuxracer thing.
I
Leif Delgass wrote:
On Thu, 27 Mar 2003, Keith Whitwell wrote:
Leif Delgass wrote:
I removed the alpha component from the visuals because the 32 bit span
read function in i830_span.c doesn't read alpha from the framebuffer (it
always returns 255). There's a comment there saying that it should
The use of 'minimum = 1' is definitely correct for GL_LINES.
It sounds like what's actually happening is that the stride of the vertex
arrays isn't being taken correctly into account when chopping the large arrays
into bite-sized chunks...
Keith
---BeginMessage---
Bugs item #677007, was opened
Leif Delgass wrote:
I removed the alpha component from the visuals because the 32 bit span
read function in i830_span.c doesn't read alpha from the framebuffer (it
always returns 255). There's a comment there saying that it should work
but doesn't. I think that should be fixed before advertising
Leif Delgass wrote:
On Thu, 27 Mar 2003, Keith Whitwell wrote:
Leif Delgass wrote:
I removed the alpha component from the visuals because the 32 bit span
read function in i830_span.c doesn't read alpha from the framebuffer (it
always returns 255). There's a comment there saying that it should
Ian Romanick wrote:
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 11:27:17PM +, Keith Whitwell wrote:
Alan Hourihane wrote:
If there's any architectural reason why we can't use XFree86's module
loader for OS indepence here ?
The whole point of the drmCommand*() interface is that it's
The current memory management system looks like this:
Core X routines
|
V
Coarse grained, block oriented cache / paged memory system
|
V
Keith's mmHeap_t code
Actually that's not my code at all, if you're talking about the stuff in
Andreas Ehliar wrote:
On Wed, Mar 26, 2003 at 07:23:09PM +, Keith Whitwell wrote:
Actually that's not my code at all, if you're talking about the stuff in
common/mm.[ch]. I know it's ended up with my name on it, but that's bogus.
I can't remember who's it is, but it's lifted from Utah so
:12 +0100 schrieb(en) Keith Whitwell:
Andreas Stenglein wrote:
this patch helps for the demo.
but someone more familiar with radeon_vtxfmt should
check if it really fixes all cases...
I think in case of GL_QUAD_STRIP we should check
for 0, too.
(and maybe for 1?)
--- radeon_vtxfmt.c_origFri Mar
Allen Akin wrote:
On Sat, Mar 22, 2003 at 07:24:15PM +, José Fonseca wrote:
| Also, I can't help thinking that some of these tricks wouldn't be
| necessary if the OpenGL standard had chosen to pass opaque pointers
| (i.e., handles) to contexts and textures, instead of using concepts such
| as
Andreas,
Does this work for you?
Keith
--- radeon_vtxfmt.c 4 Mar 2003 01:02:33 - 1.10
+++ radeon_vtxfmt.c 25 Mar 2003 09:56:06 -
@@ -312,13 +312,20 @@
return 2;
}
case GL_TRIANGLE_STRIP:
- ovf = MIN2( nr-1, 2 );
+ switch (nr) {
+ case 0:
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 06:52:57AM -0700, Brian Paul wrote:
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 01:40:57AM +, Alan Hourihane wrote:
I'll finish up tomorrow, sorry for the build bustage for now.
O.k. there's another issue here. I think I remember Ian
I'm not averse to changing this policy for this merge (as opposed to
backing these changes out bringing something else in).
I'll stop the merge for now, until we get a consensus on how to continue.
I'll defer to Brian on this.
Keith
---
Ian Romanick wrote:
As many of you know, I've been doing a lot of thinking lately about the
GLX part of XFree86 DRI. In that process I've come across a few
stumbling blocks. A few things that make forward progress more
difficult. To this point my efforts have been focused on the
Gareth Hughes wrote:
Keith Whitwell wrote:
Yes, very nice.
Utah did have some stuff going for it. It was designed as a
server-side-only accelerated indirect renderer. My innovation was
to figure out that the client could pretty easily play a few linker
tricks load that server module
Hmmm, this looks very much like it could be the reason for the problems I
reported the other day: http://cpbotha.net/thingies/dri_scapula.png
That scapula consists mostly out of triangle strips. :)
Yep. This is the vertex copying code. It isn't explained then why turning
off the VTXFMT code
My impression is that a patch trying to add a dlopen() call to one of
the xfree86 hosted ddx drivers would be rejected.
Last I looked at the XF86 loader, it had some stuff in it that implied
to me that it couldn't simply be treated as a wrapper for dlopen(),
dlsym(), etc.
I don't remember
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 10:51:05PM +, Keith Whitwell wrote:
Gareth Hughes wrote:
Keith Whitwell wrote:
Yes, very nice.
Utah did have some stuff going for it. It was designed as a
server-side-only accelerated indirect renderer. My innovation was
to figure out
Gareth Hughes wrote:
Andreas Stenglein wrote:
Yes, at least the part with GL_TRIANGLE_STRIP.
In case of 0 you can just return 0, no copying is needed.
case 0: return 0; break;
You're going to do that, just in a slightly different manner:
switch (nr) {
case 0: ovf = 0; break;
case
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 11:18:45PM +, Keith Whitwell wrote:
My impression is that a patch trying to add a dlopen() call to one of
the xfree86 hosted ddx drivers would be rejected.
Last I looked at the XF86 loader, it had some stuff in it that implied
to me
Dave Airlie wrote:
I've just had the misfortune of having my NFSROOT system (lots of network
interrupts), have its card sharing interrupts with the i810 graphics..
once I run anything 3d the kernel oops..
The attached patch contains the quick fix which is to check in thr irq
handler if
It looks fine to me, though I can't test it myself. Even if it doesn't
completely fix the problem, I think it's the 'Right Thing' to do. I've
committed the i810/i830_dri.c fix to the DRI trunk (I also added the
drmCtlUninstHandler symbol to the referenced symbol list in
i810_driver.c). If
Andreas Stenglein wrote:
this patch helps for the demo.
but someone more familiar with radeon_vtxfmt should
check if it really fixes all cases...
I think in case of GL_QUAD_STRIP we should check
for 0, too.
(and maybe for 1?)
--- radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003
+++ radeon_vtxfmt.c
Alan Hourihane wrote:
I'm going to start the 4.3.0 merge. Be prepared for breakage.
I'll post another followup when I'm finished.
Thanks for doing this, Alan.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Charl P. Botha wrote:
Dear list,
http://cpbotha.net/thingies/dri_scapula.png shows a surface-rendering of a
human scapula (shoulder blade). Notice the strange extra edges that I've
indicated with grotesque red arrows.
http://cpbotha.net/thingies/dri_scapula_wireframe.png is a wireframe
rendering
MichaelM wrote:
I just checked the logs, and there was no such message, even though what you
descibed seems the most logical reason.
The problem doesn't bother me (i can play games now =) ), but the fact that's
its there may be of concern for others ...
Hmm. Just to doublecheck, can you post
MichaelM wrote:
Here's a stack trace. It looks like the problem is with the pageflipping code.
I think I'll disable it for now, unless it's only gears that gets hurt by it.
Program received signal SIGINT, Interrupt.
0x401e47b1 in nanosleep () from /lib/libc.so.6
(gdb) backtrace
#0 0x401e47b1 in
Brian Paul wrote:
OK, I'm getting caught up on email and have read through this thread.
Comments follow, and in subsequent messages...
José Fonseca wrote:
As I've been writing the Mesa C++ wrappers I've come across some
dificulties posed by the way the interfaces are exported. As I
progressed I
José Fonseca wrote:
On Sat, Mar 22, 2003 at 06:55:08PM +, Keith Whitwell wrote:
Brian Paul wrote:
Unfortunately, we can't change this without breaking the current libGL /
driver ABI. I'm _really_ hesitant to go there.
Oh wow, I missed this. (I've been sleeping really badly lately
José Fonseca wrote:
As I've been writing the Mesa C++ wrappers I've come across some
dificulties posed by the way the interfaces are exported. As I
progressed I started to realize I was loosing too much time and effort
trying to fight the system, and the system in this case - Mesa - needs
not to
José Fonseca wrote:
On Fri, Mar 21, 2003 at 08:29:02PM +, Keith Whitwell wrote:
José Fonseca wrote:
That is, instead of Mesa acting as the middle man, it should act more as
a library. This specificaly means that, instead of (phony names):
userapp.c: glEnable(GL_TEXTURE);
mesa.c
José Fonseca wrote:
No DRI developer expressed his interest or opposition, probably because
there isn't opposition, or simply no interest. In either case I see no
reasons why not proceed, so I'll open a bug to address this. I'll ask
that [EMAIL PROTECTED] (the same addressed used on SF BT
system)
Or, someone could just leave it as is, disable it and forget
about it because sourceforge's bug tracking system sucks. [1]
I don't think we ever found out how to disable it. Just another aspect of its
suckage - you can't turn it off.
Keiht
Ian Romanick wrote:
I forgot to include the log. Sorry.
While I'm waiting to merge the texmem-0-0-1 branch into the trunk,
I've been looking into the problems with Unreal Tournament 2003 on the
R200 driver.
Here's how I've set up my debug environment, in case anyone wants to
reproduce what
XFree86 BOD wrote:
It has been brought to the attention of the XFree86 Core Team that one
of its members, Keith Packard, has been actively (but privately) seeking
out support for a fork of XFree86 that would be led by himself. He is
also in the process of forming a by-invitation-only group of
Keith Whitwell wrote:
XFree86 BOD wrote:
It has been brought to the attention of the XFree86 Core Team that one
of its members, Keith Packard, has been actively (but privately) seeking
out support for a fork of XFree86 that would be led by himself. He is
also in the process of forming
Alan Hourihane wrote:
On Thu, Mar 20, 2003 at 11:37:34 +, Keith Whitwell wrote:
XFree86 BOD wrote:
It has been brought to the attention of the XFree86 Core Team that one
of its members, Keith Packard, has been actively (but privately) seeking
out support for a fork of XFree86 that would
- Extend CVS access to regular contributors. Use scripts or
whatever to control access to subtrees if you want.
This comes up from time to time, and I'm sure will get discussed even more.
I know there have been offers to others for CVS commit access, and some
have refused and some have
Keith Whitwell wrote:
Ben Atkin wrote:
I just bought a Radeon 9000, for the main intention of using it on
Linux. Unfortunately, I didn't take the specific chipset into account,
and it appears the card doesn't have the greatest compatibility with
linux. I installed XFree 4.3.0 and got DRI
Michel Dänzer wrote:
On Mon, 2003-03-17 at 06:15, Jonathan Thambidurai wrote:
On Sun, 2003-03-16 at 19:59, Michel Dänzer wrote:
On Mon, 2003-03-17 at 01:36, Jonathan Thambidurai wrote:
When playing Serious Sam: The Second Encounter, the game (and maybe the
system, or just the input)
Eric Anholt wrote:
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.
I don't think so. There are some gimmick statistics that come out
[EMAIL PROTECTED] wrote:
Hello,
I do linux ports of Torque engine games from www.garagegames.com. The
Torque engine is based on the Tribes 2 engine.
From user reports, it seems like the engine has problems with DRI-based
cards. I've received reports of problems from users with Voodoo3, Matrix
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 anyone got any objections to merging it to the
trunk?
Eric, do you think this will be impossible to support on bsd
Philip Brown wrote:
I'm reading through http://dri.sourceforge.net/doc/drm_low_level.html
int drmDMA(int fd, drmDMAReqPtr request)
drmDMA can be used to reserve DMA buffers and to dispatch previously
reserved DMA
Philip Brown wrote:
http://dri.sourceforge.net/doc/drm_low_level.html
should be updated with a functional description of
drmScatterGatherAlloc()
[and probably a few other drmXXXYYY() routines that have appeared
since 1999 ;-) ]
Patches welcome... :-)
Keith
Keith Whitwell wrote:
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think
that
the DRI kernel modules keep some history
OK, now that the recycle lockup has been found fixed, I don't see any
problems with this patch. Has anyone got any objections to merging it to the
trunk?
Eric, do you think this will be impossible to support on bsd? It seems to fix
some fundamental braino's in the orignal drm...
Keith
Mike A. Harris wrote:
On Wed, 12 Mar 2003, Philip Brown wrote:
[]
IMHO, the names of functions and the file they are located in
should be based on the functionality that they are providing, and
should be grouped based on similar functionality and not based on
similarities in portions of
Michel Dänzer wrote:
On Mit, 2003-03-12 at 12:29, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl =
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0
Charl P. Botha wrote:
Dear list,
I've attached a wxPython + VTK example (just the
wxVTKRenderWindowInteractor.py slightly modified) to illustrate the
drmCmdBuffer: -22 bug that I'm actually seeing. It seems my glthreads.c
attempts were off the track.
In anycase, if you have wxPython and VTK with
Gabriel Dos Reis wrote:
Keith Whitwell [EMAIL PROTECTED] writes:
[...]
| struct function_table {
|...
|void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
|...
| } driver;
| and
| class Context {
|...
|void BlendFunc(GLenum sfactor, GLenum dfactor
Charl P. Botha wrote:
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
Charl P. Botha wrote:
In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example. Manipulate the 3D cone in both
windows and then close the one window. Manipulating
Keith Whitwell wrote:
Charl P. Botha wrote:
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
Charl P. Botha wrote:
In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example. Manipulate the 3D cone
in both
windows and then close the one
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think that
the DRI kernel modules keep some history around
Guido Landra wrote:
Hi all,
This is my first post, be patient, please! :)
I'm reading radeon code on CVS.
In radeon_drm.h, on kernel side, I can see a lot of data structures
already defined on client side in radeon_sarea.h.
They are about shared area, but also about data types used by IOCTLs
José Fonseca wrote:
I'm just giving a quick update of the Mesa C++ wrappers, in case anybody
wants to discuss it a little in today's meeting.
Wrappers C functions to all the GL context callbacks are already in
place at http://jrfonseca.dyndns.org/projects/dri/cpp/mesa.cxx . (These
were first
José Fonseca wrote:
On Mon, Mar 10, 2003 at 08:32:18PM +, Keith Whitwell wrote:
José Fonseca wrote:
Once textures are finished, the most tricky will be the software
rasterizer and the TnL module. For these my idea is to make the
driver
able to switch rasterizers and/or TnL modules in real
José Fonseca wrote:
On Mon, Mar 10, 2003 at 09:11:06PM +, Keith Whitwell wrote:
José Fonseca wrote:
What disptach table would you be referring to, glapi or the TnL
one? The
problem with disptach tables is that they completely break the OOP
concept as they work with regular functions instead
José Fonseca wrote:
On Mon, Mar 10, 2003 at 10:36:21PM +, Keith Whitwell wrote:
No, because one of the things C++ does is pass around an extra parameter --
namely the 'self' pointer. The 'real' prototype looks something like:
void Context::BlendFunc( Context *self, GLenum sfactor, GLenum
Felix Kühling wrote:
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
As I said above this can be done in C++, and without damage to
efficiency.
Imagine you have a TnL abstract class:
class TNL {
// A OpenGL function
virtual void Coord3f(GLfloat x, GLfloat y,
Marcelo E. Magallon wrote:
On Mon, Mar 10, 2003 at 10:23:07PM +, José Fonseca wrote:
struct function_table {
...
void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
...
} driver;
and
class Context {
...
void BlendFunc(GLenum sfactor, GLenum
Jon Smirl wrote:
--- José Fonseca [EMAIL PROTECTED]
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract Context *, but actually a non-abstract
RadeonContext *.
It works for virtual methods
Marcelo E. Magallon wrote:
On Mon, Mar 10, 2003 at 11:08:23PM +, José Fonseca wrote:
But the function I put in the table _was_ an ordinary function, and
not a C++ method, and no redirection call would take place with
inlining. That was the point of the explanation...
Uhm... how do you
José Fonseca wrote:
On Tue, Mar 11, 2003 at 12:01:16AM +, Keith Whitwell wrote:
Jon Smirl wrote:
--- José Fonseca [EMAIL PROTECTED]
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think that
the DRI kernel modules keep some history around that they shouldn't. And
maybe the
Jonathan Thambidurai wrote:
I was looking at the source for the radeon driver and noticed that the
depth buffer is always set to 32 bits if a 24 bpp color depth is
selected. Is this a hardware limitation, or might it be possible to
change it to 16 bpp?
It's possible to do this with a
Felix Kühling wrote:
On Fri, 07 Mar 2003 08:30:56 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Jonathan Thambidurai wrote:
I was looking at the source for the radeon driver and noticed that the
depth buffer is always set to 32 bits if a 24 bpp color depth is
selected
So it's now fairly easy to build either a regular DRI driver, or an
fbdev/miniglx driver for the classic radeon on this branch.
Check out the branch, and look in Mesa/Makefile.include for configuration
options. People on this list probably aren't interested in the subsetted driver.
It's
701 - 800 of 1368 matches
Mail list logo
