I've fixed the FXT support but DXT1 RGB is still knackered and probably
won't be fixed...
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Roland can you update your patch with this verson?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at
Ian Romanick wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns
a pointer to a dispatch function. If you request an unknown function,
it will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const GLubyte*)glThisFunctionDoesntExist);.
Hello list,
I have a big problem, because the compilation of the mach64 module runs into
some errors.
Here is the output of make using this command: make
LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES=mach64 2 error.log
content of the error.log:
In file included from
--- Stephane Marchesin [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns
a pointer to a dispatch function. If you request an unknown function,
it will dynamically generate a dispatch for it. Try calling
In r200_lock.c r200UpdatePageFlipping:
rmesa-pClipRects[0].x2 seams to allways have the correct value while x1
dose not. Here is the code I added.
if ( rmesa-numClipRects == 1 )
{
printf(%d\n, rmesa-pClipRects[0].x1);
}
Here is the output I got...
930 --- Move
779 ---
Why do the drivers need to look this up instead of linking straight to
_gl_context_modes_create() in common?
create_context_modes = (PFNGLXCREATECONTEXTMODES)
glXGetProcAddress( (const GLubyte *) __glXCreateContextModes );
Direct linking would get rid of the last GLX reference in
On Sul, 2004-06-06 at 05:34, Alex Deucher wrote:
at http://www.cirrus.com/ftp/pub/gd5465trm.pdf. Since it used to be
publicly available, perhaps you could just ask the nice folks at
Cirrus
Logic for it?
You might also still be able to get it on the internet archive.
Cirrus pulled
The mach64 driver includes Xarch.h. In the mesa-solo model it can't do this
since there is no X around. Is there some other way to achive the correct byte
ordering without relying on X include files?
#include X11/Xarch.h
#if X_BYTE_ORDER == X_LITTLE_ENDIAN
=
Jon Smirl
[EMAIL PROTECTED]
On Gwe, 2004-06-04 at 01:10, Dave Airlie wrote:
Do you know if the VIA DRM is considered secure with respect to DMA
buffers and the like? I've been thinking of pushing it to Linus,
It certainly needs further review. As I understand it the VIA one should
be ok, but the S3 one that went over the
I have a big problem, because the compilation of the mach64 module runs into
some errors.
Here is the output of make using this command: make
LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES=mach64 2 error.log
have you actually build the kernel? it you built the kernel using
I've changed it to include /usr/include/endian.h rather than Xarch, it
should work... but I can't test it until I get back to my laptop...
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
The mach64 driver includes Xarch.h. In the mesa-solo model it can't do this
since there is no X around. Is
On Mon, 2004-06-07 at 00:32 +0100, Dave Airlie wrote:
I've changed it to include /usr/include/endian.h rather than Xarch, it
should work...
I'm afraid that's glibc specific.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
I'm afraid that's glibc specific.
If I use sys/endian.h on FreeBSD can I do the same thing?
it'll look messy but to avoid the X includes we should do it ..
#ifdef __linux__
#include endian.h
#else
#include sys/endian.h
#define __BYTE_ORDER BYTE_ORDER
#define __LITTLE_ENDIAN LITTLE_ENDIAN
Dave Airlie wrote:
I have a big problem, because the compilation of the mach64 module runs
into
some errors.
Here is the output of make using this command: make
LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES=mach64 2 error.log
have you actually build the kernel? it you built the kernel
How about a copy/rename of teh X include and then s/X/dri/ it till it's
good to go. This would make (re)porting a no task task.
--- Dave Airlie [EMAIL PROTECTED] wrote:
I'm afraid that's glibc specific.
If I use sys/endian.h on FreeBSD can I do the same thing?
it'll look messy but to
I see use of MESA_BIG_ENDIAN in the other drivers, could you use that instead?
mach64 is the only driver using the X headers.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
On Mon, 2004-06-07 at 00:52 +0100, Dave Airlie wrote:
I'm afraid that's glibc specific.
If I use sys/endian.h on FreeBSD can I do the same thing?
it'll look messy but to avoid the X includes we should do it ..
#ifdef __linux__
#include endian.h
#else
#include sys/endian.h
#define
CPU_TO_LE32() etc seems to already be defined in mesa/main/glheader.h. Should
mach64 be using that version?
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Can you fix the 500 compiler warnings while you're in there?
--- Dave Airlie [EMAIL PROTECTED] wrote:
okay I'll have a go and making the m64 use the Mesa stuff tonight if I can
drag myself away from nwn :-)
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
CPU_TO_LE32() etc seems to
Can you fix the 500 compiler warnings while you're in there?
I actually have the fixes for all those warnings in a tree already,
however they defo require testing as they are to do with building the
vertex info for sending to the card..
Dave.
--- Dave Airlie [EMAIL PROTECTED] wrote:
A minor issue which has been bugging me for a while is the radeon
kernel module is not setting the dev-devname for display in
/proc/interrupts (under Linux). Instead NULL is shown.
The dev-devname being passed to request_irq in drm_irq.h is null.
With the old DRM interface, the devname was set
but with the current DRM interface =1.1 the devname is not being
set in DRM(set_busid).
Attached is patch to fix.
thanks applied to CVS, I'll push to bitkeeper for Linus inclusion later..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
I found that rb3d_coloroffset:0x1c40 gets emited in both the [1]client
and the [2]DRM.
1. At init time and 3 other places.
2. At emit state from the ctx.
I was wondering how I should procede in making changes to the way this reg
gets used(how to set it to a diffrent value, globaly). I think the
Jon Smirl wrote:
Why do the drivers need to look this up instead of linking straight to
_gl_context_modes_create() in common?
create_context_modes = (PFNGLXCREATECONTEXTMODES)
glXGetProcAddress( (const GLubyte *) __glXCreateContextModes );
Direct linking would get rid of the last
Alex Deucher wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Some creative googling revealed that the document *used to be*
available
at http://www.cirrus.com/ftp/pub/gd5465trm.pdf. Since it used to be
publicly available, perhaps you could just ask the nice folks at
Cirrus
Logic for it?
You
--- Ian Romanick [EMAIL PROTECTED] wrote:
There are still other places where the drivers use glXGetProcAddress.
That one isn't going to go away. If I had it to do over again, I
probably would have picked a different name for the GetProcAddress
function used by the drivers. Probably
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
There are still other places where the drivers use glXGetProcAddress.
That one isn't going to go away. If I had it to do over again, I
probably would have picked a different name for the GetProcAddress
function used by the drivers.
27 matches
Mail list logo
