I have an OpenGL (Mesa) application that works fine except when I attempt to render
the same texture objects in more than one window (GLX windows) at the same time, in
which
case the textures are incorrect and I get the following error message:
Couldn't alloc placeholder sz 4 ofs
Well, it seems that the problem is indeed hardware. I had tried setting
my bios settings to fail safe but that still left the memory at
133MHZ. Setting it to 100mhz alleviates the problem. So DRI just
aggravates an existing hardware issue. All things considered. With the
performance hit
The problem:
The agpgart usage model is not well suited for UMA architectures because
each gart user is expected to allocate memory and only bind it into
the gart while it is active. Therefore on systems where all graphics
memory is obtained from the gart a huge amount of system memory is
OpenGL applications successfully use DRI, e.g. glxgears gets 628 fps vs.
220 fps without DRI. I added /dev/dri/card0 to /etc/logindevperm, so xdm
would chown-chmod the device to $USER 600 at login, and root 600 when the
session ends. Users can log in, but when they log out the system
On Thu, Jan 24, 2002 at 09:13:40PM -0700, Jens Owen wrote:
Ian Romanick wrote:
I've been going through the DRI code and documents trying to figure out how
all this stuff works. I decided to start at the start, so I've been looking
at the driver initialization process.
You and Brian
Can someone provide me with a deeper explaination of the SAREA? I
understand that it is a block of shared memory that is used to store
internal, device specific state. However, by whom is it shared? Who can
update it? When? How?
--
Tell that to the Marines!
I've been watching this thread for awhile now, and I think it's time for me
to inject my $0.02 worth. First, let me make sure that I've got things
straight here.
Changes have been made to the 2D X driver to support video capture on Radeon
cards. To support this change, the way that video
The problem is that Mesa 3.4 only supported two texture units (there were
some bitfields that didn't have room for more bits). In Mesa 3.5 and
later the limit is eight. It shouldn't be hard to enable the third unit
on the mesa-4-0 branch.
Just to forewarn everyone, I'd like to
What follows is my understanding of the texture management system in the
DRI. This is all based on the Radeon driver in the 11-Feb-2002 CVS of the
mesa-4-0-branch. While it is based on the Radeon code, all drivers except
gamma and tdfx seem to use the same scheme (and virtually identical code).
On Tue, Feb 12, 2002 at 12:35:55PM -0800, Allen Akin wrote:
Just a side comment on Ian's excellent summary...
On Tue, Feb 12, 2002 at 11:45:58AM -0800, Ian Romanick wrote:
| - If an allocation (via the memHeap_t) fails when texture space is allocated
| (radeonUploadTexImages in lib/GL
On Tue, Feb 12, 2002 at 09:03:55PM +, Keith Whitwell wrote:
The Utah drivers detected thrashing switched from a LRU to MRU replacement
strategy. The dri drivers could/should but don't do the same...
Interesting. What sort of a metric was used and what sort of extra data was
needed?
--
On Wed, Feb 13, 2002 at 01:18:43AM +, Michael wrote:
Here's a first stab at the Radeon 3rd texture unit for testing, comments,
flames etc.
Congrats! Nice to see come cool stuff done. :)
--- radeon_context.c 6 Nov 2001 16:47:17 - 1.6.6.4
+++ radeon_context.c 13 Feb 2002
On Wed, Feb 13, 2002 at 03:23:40AM +, Michael wrote:
On Tue, Feb 12, 2002 at 07:32:27PM -0700, Brian Paul wrote:
I've updated the Mesa/demos/multiarb.c demo to exercise up to 8 texture
units. It's nothing too fancy, but give it a try (grab it from Mesa CVS).
Cool. Thanks, that works
On Tue, Feb 19, 2002 at 10:01:52AM +0100, Timothee Besset wrote:
A quick note:
When you guys encounter bugs with DRI drivers on Id games, you can
certainly get some help from me :-)
Then perhaps you can answer this question for us. Do either Q3 or RtCW use
the 3rd texture unit on Radeon
On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote:
What is the name of the extension? Since it's not implemented in the DRI,
I can tell for sure that it's not used on linux, and it's likely not used
on win32 either (at least for Q3, the number of extensions used was
restricted
On Tue, Feb 19, 2002 at 07:28:54PM +0100, Malte Cornils wrote:
Jose Fonseca wrote:
No, there's no need. You probably just have to change the order on which
/usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and
run '/sbin/ldconfig'
Unfortunately, /usr/lib is *always*
Since the G550 is, basically, just a slightly enhanced G400/G450, it is
supported by the DRI, right? If so, then does anyone have any information
about the partial TL support in the G550? Now that we've got some TL
support for the Radeon, it might be nice to look at this card, too.
I suppose
On Wed, Feb 20, 2002 at 10:32:31PM +, Keith Whitwell wrote:
Ian Romanick wrote:
Since the G550 is, basically, just a slightly enhanced G400/G450, it is
supported by the DRI, right? If so, then does anyone have any information
about the partial TL support in the G550? Now that we've
Which branch merges are complete? If the mesa-4-0-branch to trunk merge is
complete, is the branch dead?
--
Tell that to the Marines!
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Fri, Feb 22, 2002 at 01:32:23PM -0500, Adam K Kirchhoff wrote:
On Fri, 22 Feb 2002, Keith Whitwell wrote:
Adam K Kirchhoff wrote:
So, even though I'm pretty sure the Mobility chips don't even have
the TCL functionality to begin with, I thought I'd test the new Radeon
On Fri, Feb 22, 2002 at 09:59:01PM +, Keith Whitwell wrote:
But can't we assume that the user is upgrading from a stable XFree 4.2.0
installation?
No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will
be Mesa 4.0.x based. A MAJOR update!
I think we have
On Mon, Mar 04, 2002 at 05:56:50PM +, Keith Whitwell wrote:
Ian Romanick wrote:
On Mon, Mar 04, 2002 at 05:33:30PM +, Keith Whitwell wrote:
I'm using nfs to get executables from devel to test boxes, but I'd like
something less insecure...
In other projects I have found
On Thu, Mar 07, 2002 at 09:38:30PM -0800, Gareth Hughes wrote:
Leif Delgass wrote:
In looking at the docs, I realized that the mach64 seems not to support
mipmapping on the secondary texture, as there is only one register for a
secondary texture offset, as opposed to the 11 for the
On Mon, Mar 11, 2002 at 09:45:20PM +0100, Timothee Besset wrote:
Q3A and RTCW don't take advantage of SMP on Linux yet. I have some patches
that need to be applied and a bit of testing to do first. Things got
delayed, but I'm still planning on releasing this.
Heh...people have been waiting
The other day I upgraded to Quake 3 1.31. I was pretty irritated to realize
that none of the old demos worked with the new version. I was even more
irritated when I couldn't find any good demos (like crusher) to use for
testing. So, I set out to create some. In the process I created some
On Wed, Mar 13, 2002 at 01:59:02AM +, José Fonseca wrote:
I was making some research on the texture compression issue and decided to
take a look on the stuff I had downloaded from ATI developer home.
I came across this document http://www.ati.com/developer/ravesupt.html
which
On Wed, Mar 13, 2002 at 07:56:02AM +, Brendan Black wrote:
Ian Romanick wrote:
The other day I upgraded to Quake 3 1.31. I was pretty irritated to realize
that none of the old demos worked with the new version. I was even more
irritated when I couldn't find any good demos (like
There was some talk awhile back about adding support for AGP texturing in
the Radeon driver. Whatever happened with that?
--
Tell that to the Marines!
___
Dri-devel mailing list
[EMAIL PROTECTED]
On Wed, Mar 20, 2002 at 10:17:26PM +0100, Andreas Stenglein wrote:
so maybe shouldnt it be deleted from gl.h?
If I understand Brian correctly, gl.h (which has glSamplePass) is correct,
but the library (which has glSamplePassARB) is not correct.
--
Tell that to the Marines!
On Wed, Mar 20, 2002 at 09:44:22PM +, Keith Whitwell wrote:
Daryll Strauss wrote:
On Wed, Mar 20, 2002 at 12:26:41PM -0800, Ian Romanick wrote:
There was some talk awhile back about adding support for AGP texturing in
the Radeon driver. Whatever happened with that?
I've
On Wed, Mar 20, 2002 at 11:27:39PM +, Michael wrote:
On Wed, Mar 20, 2002 at 01:51:06PM -0800, Ian Romanick wrote:
Michael also implemented agp support for radeon with a similar simplistic
strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think
these turned out
I don't have the G400 documentation, so I can't just look this up. I'm just
curious, what are TF_{min,mag}filter_cnst supposed to do? I modified the
driver to use them just to see what they did, and it's not exactly clear
what they do! It looks like it just makes the hardware to an unweighted
On Wed, Mar 27, 2002 at 03:17:56PM -0500, Leif Delgass wrote:
In the code to set MaxTextureLevels in the Rage128 and Radeon drivers,
4 bytes/texel is assumed when calculating for the max texture size. If we
always convert to 2 bytes/texel for a 16bpp screen when choosing texture
formats,
On Wed, Mar 27, 2002 at 10:53:48PM +, Keith Whitwell wrote:
Actually I think the test is correct, and that I was thinking of 16 bit
textures plus a full set of mipmaps at the time. Thus the numbers should be
doubled in the 32 bit case, rather than halved for 16 as Leif was suggesting.
On Thu, Mar 28, 2002 at 12:53:06PM -0800, Ian Romanick wrote:
#0 0x4309fb0a in CreateContext (dpy=0x8075708, vis=0x0, shareList=0x0,
allowDirect=1, contextID=0) at glxcmds.c:165
#1 0x4309fc5d in glXCreateContext (dpy=0x8075708, vis=0x0, shareList=0x0,
allowDirect=1) at glxcmds.c
On Sun, Mar 31, 2002 at 01:40:44AM +0100, Kai Schutte wrote:
Hello, Master Paul :)
I'm trying to get a few programs running which require the ARB_multitexture
extension, while using hardware acceleration.
Which hardware?
I meant direct rendering using the mga driver... I'm running
On Sat, Mar 30, 2002 at 08:11:31AM -0700, Jens Owen wrote:
Ian Romanick wrote:
On Thu, Mar 28, 2002 at 12:53:06PM -0800, Ian Romanick wrote:
#0 0x4309fb0a in CreateContext (dpy=0x8075708, vis=0x0, shareList=0x0,
allowDirect=1, contextID=0) at glxcmds.c:165
#1 0x4309fc5d
I'm using the Radeon TCL CVS from this morning, and q3tourney4 is not
rendering properly. It looks like the bumpmaps are not being used. I'm
using Q3A v1.31.
Also, when the head of Stripe is displayed in the upper right, the texture
rolls (like it's lost vertical hold).
I have't yet done more
On Sat, Mar 30, 2002 at 08:11:31AM -0700, Jens Owen wrote:
Ian Romanick wrote:
The bad news is that it dies shortly thereafter with an assertion failure in
Mesa. The only seems to happen when I re-size the window. Maya seems to
expect 1280x1024, but I'm running @ 1152x864. If I hit
On Wed, Apr 03, 2002 at 01:28:46PM +0200, Timothee Besset wrote:
Not sure if that's related, but Q3 shaders don't do any bump mapping.
TTimo
Hrm..ok, so then it's not the bumpmaps that are missing. :) In any case,
the walls look perfectly smooth, and they didn't used to. I'll send a
On Thu, Apr 04, 2002 at 09:30:39PM -0800, Raystonn wrote:
OK - so a factor 70 in CPU growth and a factor of 16 in RAM speed.
No, in this 5 year period, processor clockspeed has moved from approximately
200MHz to over 2GHz. This is a factor of 10 in CPU growth and 16 in memory
bandwidth.
On Fri, Apr 05, 2002 at 12:02:45PM +0200, Daniel Kulesz wrote:
So I thought this had to do with the incompatibility between the chipset
and the radeon. But i would really love to use a radeon in my board, cause
the only alternative to it would be a voodoo4 which is by far slower and
doesnt
I'm sending this as an HTML attachment. If this causes anybody problems,
let me know and I can re-send as plain text.
--
Tell that to the Marines!
Title: drmcommand-0-0-1-branch on G400 Test Results
All driver combinations were tested with glxinfo, gears, and my Quake3 tests.
The Quake3
On Mon, Apr 08, 2002 at 07:03:34PM -0400, Mike A. Harris wrote:
On Mon, 8 Apr 2002, Ian Romanick wrote:
I'm sending this as an HTML attachment. If this causes anybody problems,
let me know and I can re-send as plain text.
Doesn't cause any problems.. just can't read it. ;o)
D'oh...I
On Sat, Apr 06, 2002 at 09:42:36AM -0700, Brian Paul wrote:
Ian Romanick wrote:
Also, I just noticed that when Maya starts up it logs the following message
in its script editor windows. It repeats four times.
// Warning: Unable to get OpenGL visual with a depth buffer, trying
Wow. I just get to be the bearer of bad news today!
After doing some cursory Maya testing, I decided to put the TCL branch up
against glean, and glean won. It consistently explodes in one of the
blendFunc tests. This is with the latest glean CVS trunk and DRI TCL branch
as of the morning of
On Tue, Apr 09, 2002 at 09:00:44PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
In other news, I tried (using CVS as of the morning of 4/9) running in
1152x864 and maximizing the Maya (so that it would fit) and running in
Maya's expected 1280x1024. In both cases, I hit the following
I just submitted bug #541782. There is a rendering error on the Radeon in
Quake 3 when cg_shadows is 2. The bug does *not* happen with it is set to
3. The problem seems to be related to alpha blending, primarilly in weapon
effects. There is a screen shot with the bug report.
--
Tell that to
On Tue, Apr 09, 2002 at 05:54:55PM -0600, Jens Owen wrote:
Ian Romanick wrote:
On Tue, Apr 09, 2002 at 09:00:44PM +0100, Keith Whitwell wrote:
I committed a fix for a similar-sounding problem today - it would be
interesting to see if this has changed.
I checked CVS with 'cvs -z3
On Tue, Apr 09, 2002 at 03:24:36PM -0700, Ian Romanick wrote:
I just submitted bug #541782. There is a rendering error on the Radeon in
Quake 3 when cg_shadows is 2. The bug does *not* happen with it is set to
3. The problem seems to be related to alpha blending, primarilly in weapon
On Tue, Apr 09, 2002 at 06:13:30PM -0600, Brian Paul wrote:
Ian Romanick wrote:
The issue is that Maya is requesting at least 23-bits of Z-buffer. In
16-bit mode, we only have 16-bits of Z-buffer, so it can't find a visual.
Just for grins you could hack glXChooseVisual so that a 16-bit
On Tue, Apr 09, 2002 at 06:29:54PM -0700, Raystonn wrote:
First off, current market leaders began their hardware designs back when the
main CPU was much much slower. They have an investment in this technology
and likely do not want to throw it away. Back when these companies were
founded,
On Mon, Apr 08, 2002 at 04:08:44PM -0700, Ian Romanick wrote:
1. dribench002.dm_67 hung on the texthrash.cfg setting. The X server
could be killed, but not restarted. System had to be rebooted. In this
case, the ultramax.cfg setting was not tested.
I am now able to reliably reproduce
On Fri, Apr 19, 2002 at 01:26:40PM +0100, Major A wrote:
I'm using DRI on a G400 card with 16MB video RAM. When using graphics
extensively (FlightGear) in a high-resolution set-up (1600x1200,
16bpp), the X server hangs after a few minutes of starting the
program. On 1280x1024, 16bpp, it can
On Fri, Apr 19, 2002 at 08:29:59PM +0100, Major A wrote:
I sent an e-mail to the list a few days ago explaining how to reproduce this
problem with Quake 3. In that mail there were some instructions for
enabling debug messages in the MGA driver. Could you please follow those
steps
On Fri, Apr 19, 2002 at 12:53:54PM -0700, Ian Romanick wrote:
I filed a bug report with all the text from the message. The bug is #546281.
http://sourceforge.net/tracker/index.php?func=detailaid=546281group_id=387atid=100387
This may also be the same as #442693 #522096/515182
On Tue, Apr 23, 2002 at 10:19:32PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
On Tue, Apr 23, 2002 at 09:39:14PM +0100, Michael wrote:
On Mon, Apr 22, 2002 at 12:28:07PM +0100, Keith Whitwell wrote:
Can people with outstanding problems wrt. the tcl branch please let me know
On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
Well, you're doing something you're not supposed to do as a result
glXGetProcAddress isn't working right.
Do you really need to call your symbol glBegin? How about xyzBegin or
similar?
I have managed to solve this problem
On Wed, Apr 24, 2002 at 06:42:21PM +0100, Jose Fonseca wrote:
On Wed, 2002-04-24 at 14:13, Jens Owen wrote:
I believe the r128 driver's PCI support still utilizes GART
functionality to allow non-contiguous memory to be utilized. Your
driver may be the first to need true PCI support, and
On Fri, Apr 26, 2002 at 03:09:46AM +0200, Smitty wrote:
I'm not the most qualified to answer this, but I think most of the more
qualified people are pretty busy adding some of these features. :)
ATI R100 (Radeon)
=
Anti-aliasing
=
Full Screen No
On Wed, Apr 24, 2002 at 04:49:34PM -0600, Brian Paul wrote:
Brian Paul wrote:
Perhaps you should try out this change before I commit it to the DRI.
Try editing build/xc/lib/GL/GL/Makefile, look for the line that has the
string -Wl,-soname and replace it with -Wl,-Bsymbolic,-soname.
On Mon, Apr 29, 2002 at 04:40:21AM +0200, Smitty wrote:
Added:
Pixel shader
Programmable texture blending modes - Yes. EXT_texture_env_combine is
supported, and ARB_texture_env_combine
and
On Fri, May 03, 2002 at 01:14:21AM +0200, Peter Andersson wrote:
Michel Dänzer wrote:
On Wed, 2002-05-01 at 19:30, Peter Andersson wrote:
Michael, have you got hold of the screenshot or would you like me to re
send it to you?
I've seen it now, thanks.
I realized that Doom was an 8
On Sun, May 12, 2002 at 11:08:47PM +0200, German Gomez Garcia wrote:
I would like to know if anybody was able to run Maya 4 on a
Matrox G400
using DRI, it seems that Maya only support 3DLabs and nVidia cards. Any
clue
about running it on a G400?
I believe that Maya also
On Sun, May 12, 2002 at 06:18:58PM -0400, Leif Delgass wrote:
In working on AGP texturing for mach64, I'm starting from the Rage128
code, which seems to have some problems (though the texture aging problem
could affect other drivers). My understanding is that textures in the
global LRU are
On Mon, May 13, 2002 at 02:29:18AM +, Greg T Hill wrote:
I posted this last month on the dri-users list in hopes that I was doing
something wrong and would find out how to fix it. I eventually did fix it by
installing a matrox g450, and everything works. This pretty well rules out
On Mon, May 13, 2002 at 04:06:53PM -0400, Leif Delgass wrote:
On Mon, 13 May 2002, Ian Romanick wrote:
On Sun, May 12, 2002 at 06:18:58PM -0400, Leif Delgass wrote:
In working on AGP texturing for mach64, I'm starting from the Rage128
code, which seems to have some problems (though
On Wed, May 15, 2002 at 12:33:46AM +0100, José Fonseca wrote:
I've been making some tests to the bus mastering in Mach64 chip as I told
yesterday on IRC. Since this was discussed pretty late I would like to
briefly document to the others DRI developers what I'm trying to do:
Since
So, I've run into an interesting situation, and I'm wondering what should
theoretically happen.
The FireGL driver (closed source, from ATI) seems to be the only DRI based
hardware driver that supports overlays. When running apps on the localhost,
everything works fine.
The catch is when an app
On Mon, May 27, 2002 at 11:45:44AM -0600, Brian Paul wrote:
Ian, if you run 'xprop -root | grep SERVER_OVERLAY_VISUALS' is anything
found?
Nothing. I'll have to check that the person that originally hit this is
running the same versions that I am.
--
Tell that to the Marines!
On Wed, May 29, 2002 at 09:16:36AM -0700, Ian Romanick wrote:
On Mon, May 27, 2002 at 11:45:44AM -0600, Brian Paul wrote:
Ian, if you run 'xprop -root | grep SERVER_OVERLAY_VISUALS' is anything
found?
Nothing. I'll have to check that the person that originally hit this is
running
On Fri, Jun 07, 2002 at 09:42:22AM -0400, Al Tobey wrote:
Here's the idea: would it be beneficial to convert a texture to a
low-quality jpeg, then back again to take advantage of some of the
inherent lossiness? It, in theory, should reduce the size of the
texture without effecting the bit
On Fri, Jun 07, 2002 at 06:10:55PM +0100, Michael wrote:
On Fri, Jun 07, 2002 at 09:42:08AM -0700, Ian Romanick wrote:
It's an interesting idea, BUT unless you can get help from the card
decompressing the JPEG on upload (perhaps the Radeon iDCT unit could help?)
-or- you come up with some
On Fri, Jun 07, 2002 at 01:31:59PM -0400, Al Tobey wrote:
So, I'm guessing that textures aren't loaded into memory before starting
the rendering? I don't really mind waiting a few more seconds for
textures to load (if they're all loaded up front) if my app/game will
run faster as a result.
On Tue, Jun 18, 2002 at 12:09:02AM +0100, José Fonseca wrote:
On 2002.06.17 23:19 Keith Whitwell wrote:
We could overcome the GLX difficulties in the same way we do now in
libGL with the direct rendering.
But I still don't understand why vertex arrays would be such a problem
I noticed that some code from Mesa was recently folded into DRI to support
APPLE_client_storage. What does it take to enable that in a driver? Is it
like SGIS_generate_mipmaps in that the driver just needs to enable it?
On a related note, some time ago (on an IRC meeting, I think) there was
Here is a patch that will enable the 3rd texture unit in the Radeon
R100/RV200 driver. I have tested it using multiarb on a Radeon classic
DDR and a Radeon M6 (AGP developer board). There are a few issues that I
came across that should be resolved before applying.
- How should we calculate the
On Thu, Aug 22, 2002 at 11:19:49AM -0700, Ian Romanick wrote:
Unless somebody knows another way, I believe that we need a sw fallback if
texUnit-CombineModeRGB == GL_DOT3_RGB_ARB
texUnit-CombineScaleShiftRGB != 1. My guess is that radeonUpdateTextureEnv
should be modified to return false
On Thu, Sep 26, 2002 at 03:00:02AM +0200, Michel Dänzer wrote:
I've been wondering for some time why at least the Quake 2 engine is
very slow with multitexturing enabled, i.e. with
set gl_ext_multitexture 1
in ~/.quake2/baseq2/config.cfg, it crawls on stuff like explosions.
Change that
On Thu, Sep 26, 2002 at 11:04:36AM -0400, Bobakitoo wrote:
I've been wondering for some time why at least the Quake 2 engine is
very slow with multitexturing enabled, i.e. with
set gl_ext_multitexture 1
in ~/.quake2/baseq2/config.cfg, it crawls on stuff like explosions.
Attached is a patch to fix the
drmRadeonCmdBuffer: -22
problem in the SW TCL path (used on Radeon VE M6 cards) in the Radeon
driver. It turns out that not every place in the code was using the right
packet sizes. I believe that this was the only missed place. I have tested
with with a Q3
On Thu, Sep 26, 2002 at 04:51:37PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
I guess my problem is, should values other than [GL_TEXTURE0, GL_TEXTURE0 +
MAX_TEXTURE_UNITS] ever get this far in the pipeline?
This far
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
from overwriting normalptr and floatcolorptr. :) In actuality, should this
be expanded anyway? How was the value 15 arrived at?
Yes, you need a bigger maximum for the extra texture coord.
Okay. It should be changed to 19,
Hello all.
I noticed that NV_texture_rectangle appeared in the R100 driver string after
then recent R200 merge. I did some looking around, and found that it is
explicitly enabled in the R200 driver and has code to support rectangular
textures. It seems that it is enabled by default in Mesa.
On Mon, Sep 30, 2002 at 09:22:00AM -0600, Brian Paul wrote:
Ian Romanick wrote:
Hello all.
I noticed that NV_texture_rectangle appeared in the R100 driver string after
then recent R200 merge. I did some looking around, and found that it is
explicitly enabled in the R200 driver
On Mon, Sep 30, 2002 at 05:07:39PM -0600, Brian Paul wrote:
This was a topic on today's IRC session. Here's a very rough list of issues
and goals to consider. After we get a good list we can move onto implementation
proposals. If we're really going to do this, let's be sure we do it right.
On Wed, Oct 02, 2002 at 04:35:16PM -0600, Jens Owen wrote:
Ian Romanick wrote:
Really there are 3 places the texture data can be duplicated: in the app, in
libGL, and on-card / AGP. This can either be done by exposing some sort of
allocate AGP memory extension
On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
- Do we really need the 3 in radeon_vtxfmt_c.c:
static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
{
- GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)1];
+ GLfloat
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
One option is to have the kernel actually do the fixup of the buffers when
they are submitted by the client, so the driver never knows really where it's
textures are, but talks about them via. some indirection.
I've been
Here is the texmem patch that I talked about at last week's (sorry for the
massive delay!) IRC meeting. There's a patch file and a couple new files.
Also, mga/mgatexcnv.c should be removed. I'm not sure how to specify
removing a file in a patch. :)
In any case, I'm primarilly sending this out
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
I have recently created and commited the first batch of code to the
texmem-0-0-1 branch. The purpose of this branch is to refactor the
client-side texture management code to a single place and port all (or
nearly all) drivers to use that code. The new texture management code is in
On Sun, Oct 13, 2002 at 07:48:22PM +0200, Felix Kühling wrote:
Appart from that, I think that radeonUpdateViewportOffset is buggy. The
aliasing of int and float is inconsistent. The comparison is done
without aliasing, in the subsequent assignment the floats are aliased to
ints. I attached a
On Tue, Oct 08, 2002 at 04:30:58PM +0200, Mourad De Clerck wrote:
mga_get_buffer_ioctl: flush ret=-22
Do you still see this bug with the latest trunk CVS?
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is
This is just a friendly reminder that the weeking dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or
5:00PM EDT or 2:00PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
On Wed, Oct 16, 2002 at 01:07:16AM +0200, Michel Dänzer wrote:
On Die, 2002-10-15 at 20:30, Ian Romanick wrote:
Warning: ignorant questions on the way...
I've gotten some questions from a couple of people about backing store with
DRI, on the R100 driver specifically. Because my
On Wed, Oct 23, 2002 at 09:22:05PM +0200, Felix Kühling wrote:
Hi,
after upgrading to the merged XFree89 4.2.99.2 XFree86.0.log contains
this:
(**) RADEON(0): Display dimensions: (315, 236) mm
(**) RADEON(0): DPI set to (154, 154)
xdpyinfo still shows the correct 92 DPI:
dimensions:
I sent this message once, but I accidentally just sent it to Brian, so here
goes...
On Thu, Oct 17, 2002 at 01:16:13PM -0600, Brian Paul wrote:
In the DRI drivers we keep a bitfield to determine if/why we need a software
fallback. I suppose IsFast() could return a similar bitfield but coming
This is just a friendly reminder that the weeking dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or
5:00PM EDT or 2:00PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
On Tue, Oct 22, 2002 at 11:31:00AM +0100, José Fonseca wrote:
On Tue, Oct 22, 2002 at 10:34:58AM +0100, Alan Hourihane wrote:
I'm about to start a merge of the XFree86 CVS and bring that into
the DRI CVS trunk. No doubt with the trees diverging quite a bit, that
there will undoubtably be some
1 - 100 of 1168 matches
Mail list logo
