This looks like it is missing from the driver:
/* Workaround for some hardware bugs */
if (info-ChipFamily CHIP_FAMILY_R200)
OUTREG(RADEON_AGP_CNTL, INREG(RADEON_AGP_CNTL) | 0x000e);
should be in drm IMHO...
Second one:
/* Initialize Radeon's AGP registers */
/* Workaround for some hardware bugs */
if (info-ChipFamily CHIP_FAMILY_R200)
OUTREG(RADEON_AGP_CNTL, INREG(RADEON_AGP_CNTL) | 0x000e);
should be in drm IMHO...
Do you want to add it and send it off to the kernel? or do you want me
to fix it in CVS?
Can you
you would just let it boot with default. Then in a script:
echo mode /sys/class/drm/card0/agpmode
Can we change the AGP mode dynamically at the moment, i.e. if I set it to
1 for default (because anything higher might not work) can I change it
later if I've already initialised the AGP layer..
No, you can quite validly do a sg alloc on an AGP card, you can also
legally run an AGP card in PCI-only mode something the current code allows
(as userspace sets it) but the new code actually stops as it detects it..
So how can I tell AGP from PCI in user space so I know whether to do
Does the following differences means that the
fglrx driver load another microcode ?
I've written a hw_script that reads back the microcode from fglrx,
I've already replaced my microcode to see if my issues were with it (they
weren't..)
I've added a hw_scripts directory to r300_driver with 3
Three tiers is fine with me and I've never been against it. But we've
only been talking about this for two years now and no one has stepped
up to fix 67 fbdev drivers - I'm sure not going to it. I don't want to
wait another two years to build Xegl so I'm trying to come up with
some way
I just think this is a giant amount of work to save 70K of memory (by
allowing a setup which avoids loading fbdev) on desktop x86 machines.
It is much simpler to just treat fbdev as the bottom layer and have
two tiers instead of three.
Wouldn't it be easier to just debug the 12 fbdev
Out of curiosity - who are the people that *need* intelfb ? (as opposed to
*want*).
Xegl people will need a kernel framebuffer driver (not necessarily running
the console) but something loaded to take care of X when it starts ...
also this memory manager has to go somewhere, and part of it
Why would layering the DRM on top of the fbdev driver break DirectFB? I
(think I) understand the issues with actually merging the drivers, but
the more I dig into, for example, MGA DRM, the more convenient it seems
to have DRM on top of fbdev.
It won't if you do it properly.. Jons was doing
I was going to delete the code that looks for fbdev and conditionally
takes control since it had been rejected. Should I leave it in?
I'd leave it in, no-one says DRM CVS has to be exactly what is in the
kernel, it is nice to know what happens when we own the PCI device vs
currently,
Dave.
the function and just
change the return values appropriately.
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
NAK: Dave Airlie [EMAIL PROTECTED]
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel
I'm working on changing DRM such that the master node does not need to
run as root and instead can be a normal user. Because of this I can't
leave AddMap the way it is. The security hole is that a normal user
could allocate multi/large shared areas, consume all of kernel VM
space and crash
I don't see this process adding huge amounts of code to the drivers,
I'm halfway through and I don't think I've added hardly any code at
all. Mostly I just rearrange what is already there.
Linux already has existing fbdev drivers for mode setting. I am
choosing to use those now since I
At the moment I'm having similiar issues with Radeon XvMC it initially
will require root as I'm not sure how to submit the command streams
outside of indirect buffers which are a root only thing...
Can't it be done the same way as for 3D commands, using specialized
ioctls?
Eventually
Eventually yes, but that VHA stuff sets a load of registers in indirect
buffer, fills up an indirect buffer and sends it the card... to do this
without indirect buffers would require a fair lot of sending commands
between blocks to make sure the card is back in a known state ...
I
Is anyone working on a stub driver ??
While you wait on the great stub debate to be settled (it has been
going on for about 18 months with no action) why not simply fix
intelfb to work right on the i915?
I've said this before I think, but intelfb is very broken, apart from the
fact it
bugzilla 943 on bugs.freedesktopp.org
Egbert is hoping to look at it again, I keep getting hopelessly lost in
types when I start looking at it.. I don't have the hardware to test it
on...
Egbert's patch has been updated and it's looking good.
I'd suggest committing it to CVS now for
I can also predict the probable outcome on kernel submission if we use
the stub to start building suspend/resume in two different places -
DRM and fbdev.
My stub isn't your totally fb in the stub, we are only going to put
initially interrupt handling, suspend/resume, PCI driver handling and
I was just a little perplexed (as I'm sure Egbert was too) that the bug #943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS for at least a little while to get
tested here.
Paul and Egbert discussed it on the bug at the time Paul
Looks like that Dave Airlie has pushed another set of patches
made by Paul Mackerras into the DRM code.
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Furthermore they have support
Dave, if you cannot test this why do you want to port my code
to Paul's sceme - which seems to be much more error prone than
using my sceme?
As Pauls scheme was written from what I could see from a kernel
developers point of view, it is maintainable for other kernel developers..
reviewing it
I had been hoping for some more comments from the senior DRI hackers.
Egbert's patch takes somewhat the opposite approach from mine; where I
extended the RADEONDRIRec structure to have space for 64-bit handles,
Egbert's patch unconditionally makes the drm_handle_t be 32-bit.
Which is fine if
Now I've hacked that code together in little over two hours (while
watching Raiders of the lost Ark) I don't see the advantage adding all the
macros will bring, once you've identified which structs/ioctls need work,
a quick editor macro can generate the code nearly... (granted I'm
Yes a bit of interest from idr, alanh and keithw might help us out here...
(and anyone else who knows this area)
Yes, sorry about this. As it stands I don't have a particularly good
understanding of the issues and will have to spend a bit of time getting up to
speed before I can
There are three DRI drivers with no DRM. What is up with these?
gamma
s3v
trident
Well gamma did have one but its got hosed as it wasn't very pretty and
responsbile for a lot of pain.. but keeping the dri driver building isnt
too much hassle.. and you never know someone out there might want
The DRM has wrappers for these function due to it being used on other
OS'es (BSD mainly)
However I will accept that the drm_calloc function should now just
called the kernel kcalloc function and this could probably be moved to
an inline in drm_memory.h
I'll code up something and put it my
The DRM has wrappers for these function due to it being used on other
OS'es (BSD mainly)
yes and? how about naming that wrapper kcalloc() instead which
would make the linux wrapper empty and the bsd wrapper just trivial
las well ?
drm_calloc doesn't have the same interface as
On my x86 laptop I get
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 915GM Chipset.
agpgart: AGP aperture is 256M @ 0x0
This machine doesn't have an AGP card, just a PCI Express ATI Radeon
X300..
However when the DRM loads it attempts to setup an mtrr at 0, which of
Okay I know the radeon has a slightly wierd 0..1 instead of 0..[wh],
why does this cause a fallback to non-tcl? can the hardware not do it or
are we missing something in Mesa to let it ...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux
Now my problem at the moment is I can't get fglrx to work on my X300 at
all either, it hangs... (XP works fine..), I'm going to install FC3 as
well as ubuntu just to get a second opinion :-)
Well all the latest pcie code is in r300.sf.net drm, it still doesn't work
for me, and I've ran
I've made a patch against the DRM code in CVS adding a few pieces that
were missing.
The code works for me on both radeon and r128. I've also tried to test
mga however the mga code in CVS doesn't seem to work at all right now.
My guess would be idr's changes might need some compat work .. no
On Tue, 12 Jul 2005, Adam Jackson wrote:
http://people.freedesktop.org/~ajax/libdrm/libdrm-1.0.0.gz
I'll soon be switching Mesa to require this to build the DRI drivers and the
DRI-capable libGL. This means you need pkg-config.
This also means we can get rid of the copy of the drm source
Replace custom wait-queue usage with
wait_event_interruptible_timeout(). This required some more complex
return code evaluation, but simplifies the loop itself to one statement.
I need to know if this patch has been tested on real hardware, the i830
driver is in maintenace mode only, and I
Egbert pointed out one of the r128 ioctls (getparam) is declared IOW when
it should be IOWR of course changing this would break userspace...
I've commited a fix which makes the old ioctl GETPARAM_OLD and makes a new
GETPARAM ioctl with the correct direction..
but after thinking about it this
Egbert pointed out one of the r128 ioctls (getparam) is declared IOW when
it should be IOWR of course changing this would break userspace...
I've commited a fix which makes the old ioctl GETPARAM_OLD and makes a new
GETPARAM ioctl with the correct direction..
but after thinking about it
I made an additional modification to the source: there is no
implementation of drm_device_is_pcie() for FreeBSD so I just put
dev_priv-flags |= CHIP_IS_PCIE into radeon_preinit(). I have tried both
with and without this patch and only the pure, clean CVS but nothing
works.
FreeBSD support
So why can Doom 3 use R200 pixel shaders, and DRI can't?
And we currently don't implement the two extensions on r200 that Doom3
uses, I've still got a 90% finished ATI_fragment_shader done but I've
little time to pick it back up, and the only test code I had was doom3 and
unfortunately when I
Hi, (mainly KeithW)
I'm looking at the current i915 mem manager which shares the LRU texture
area with client side textures which would be useful in my system, as I
want to have the AGP texturing but also some client side textures...
a) should it work? (given I don't really care about backwards
a) should it work? (given I don't really care about backwards compat)
b) do I still need to use glxMesaAllocateMemory and friends?
It'd probably work fine, it's still a bit of a hack though. Maybe it's time
to really do the work on a proper manager? I'm at a point where I can put a
bit
I'm definitely thinking we need to take Ian's DriMemoryManagerDesign
document and start thinking throught the issues.. it needs to be expanded
to be able to manage all graphics memory, VRAM and AGP, including
framebuffers and all that stuff, every driver using should allocate via
it, no more
I pinged daniel and he seems to have fixed it.. it is the same a/c you
us to work on xorg...
Dave.
On Sat, 30 Jul 2005, Vladimir Dergachev wrote:
I submitted a bug requesting CVS access a while ago, but it has not changed
since - could someone knowledgable take a look and let me know what
restricted to the first process that opens the DRM device. Of couse
that process may not be an Xserver.
Can people add notes about possible security problems with each of these?
You've missed all the driver ioctls.. please make a list of current driver
ioctls that need root as well..
I'm
Note, the r200 supports a lot more buffer formats, but these are the
only ones valid for scanout.
What does scanout mean?
the sending of a graphics buffer from VRAM to monitor via a CRTC... CRTCs
only support certain formats...
Dave.
--
David Airlie, Software Engineer
In this function there is a section in an if (IS_R300_VARIANT) which returns,
and later in the function there is another section setting display
priorities for IS_R300_VARIANT
something is wrong there...
Dave.
---
SF.Net email is Sponsored
DRI, and therefore hardware accelerated 3D, is *not* supported on Solaris.
^^
re-read and go back to xorg lists...
Dave.
Definetively not ? However, i don't readed this in the several .def and .cf
files of the
I suggest testing a 2.6.12 not a 2.6.13, i think something might be wrong with
2.6.13 (IIRC i see people complaining on lkml or on dri user) a change in API
a regression somewhere... But it could also be a 64bits issue not
seen before :)
I'd appreciate if someone could test with
Hi all.
I've just checked into CVS, a patch from Egbert and Paul that
allows us to change the drm_handle size to 32-bits however I'm not sure
what to do with the BSD people...
We want to change the handle to unsigned int Should we just ifdef
around it for BSD?
Dave.
--
David
If anyone has a pure 64-bit system with a working radeon DRI setup, I'd
really appreciate if they could test 2.6.13-rc5-mm1 and see if radeon
still works...
I'm getting a report that I would like verified, but I've got no 64-bit
systems so I rely on the people who do to help out if they want a
still works...
Define pure 64-bit. AFAIK, the only truly pure 64-bit system is that
Alpha, but I don't think that's what you mean. :) Do you mean 64-bit
kernel 64-bit X-server?
Well a 64-bit kernel and 64-bit X and 64-bit glxgears linked against
64-bit libGL with a 64-bit radeon_dri.so
Thanks for committing the fix but you missed few things. Additional
fix is attached. I am not sure this is right thing to do but it
seems to work.
I've talked to Eric and it isn't really clean, he wants to come up with a
better way .. we may need to add another DRM macro... personally I'd
I've just rebuilt everything from CVS on my x86_64 box:
- X starts with direct rendering enabled (it used to
crash just a few days before);
- The latest Mesa appears to be out of sync with DRM:
ERROR! sizeof(RADEONDRIRec) does not match passed size from device driver
- Using
What I meant is to get 2d working using DRI driver (i.e. submitting commands
using CP engine, rather than MMIO registers as happens without DRM driver
loaded).
In for a penny in for a pound, (old saying..) i.e. if I could do that I
would have working 3D... the CP crashes on startup...
just
In for a penny in for a pound, (old saying..) i.e. if I could do that I
would have working 3D... the CP crashes on startup...
I assume that you have a version of PCIGART working, right ? You can test this
using MMIO by doing bitblt from GART memory to video memory, for example.
nope
nope a working PCIEGART isn't the same as a working PCIGART, I have
all the information I think I need (though an R42x 2D programmers guide as
opposed to the R42x regref would help a bit), I just can't connect the
dots... I also suffer from the fact that fglrx doesn't work on my PCIE
My understanding of bus operation is that it's sole function is to
provide memory mapped IO, IO ports, and interrupt control, after these
features are configured -- by the BIOS -- software only has to worry
about the device at the other end... After this initial configuration,
so I thought,
I found why my G5 was crashing when using the linux-2.6 version of the
DRM + git-drm.patch from 2.6.13-rc6-mm1, but not with the CVS DRM.
The reason was that dev-agp-cant_use_aperture wasn't getting set,
and the reason for that was that linux/version.h no longer gets
included and the #if
the allocation failures when the kernel
needs to back up the data. If the memory isn't pinned, it can get paged
out, and, apparently, the kernel can page-in user pages in the way that
we want. Dave Airlie made some comments about that, but I don't
remember exactly what he said.
I've thought
. Dave Airlie was working on it at one point however.
I've put it on hold for modularisation and memory manager work as it would
be much easier to get this done with some sort of memory management..
I don't really like the idea of reserving chunks of VRAM on the off chance
someone might use it..
I have
At current count we need 6 ioctls for the memory manager. However,
there are only 5 available ioctl numbers available below 0x40. Is it
possible to use numbers above 0x79?
I count 0x08-0x0f, 0x1e-0x1f, 0x2d-0x2f, 0x3b-0x3f, or 18. While it
should be doable to use numbers 0x80 and up,
With the root only/master split the flags looked ugly
Any objections to a cleanup along the lines of this patch?
Index: bsd-core/drmP.h
===
RCS file: /cvs/dri/drm/bsd-core/drmP.h,v
retrieving revision 1.68
diff -u -r1.68 drmP.h
Support for ATI_fs will be enabled automatically if texture_units is set
to 6 (there is simply no useful way to expose this with less units).
Are these really related? My understanding is that texture_units is
about the number of 'traditional' GL texture units exposed, and that
this is
If other people has got to compile it, the problem should be in my
computer. Where could be the problem? hardware? compiler? kernel? a
corrupted file in my CVS tree? which one?
try this patch (works for me):
I've just checked this in to X.org tree..
Thanks,
Dave.
--
David Airlie,
On Thu, 8 Sep 2005, Daniel Estévezz wrote:
El Jueves, 8 de Septiembre de 2005 00:38, escribió:
You should use David Airlie kernel DRM (which is in current Linus
git top of tree) along with the following patch in case it didn't
make it yet:
OK. I have downloaded the project
Okay I've completed the PCIE support for the r3xx and r4xx radeon cards,
It needs a new DRM and DDX, as I've had to move the PCI GART table into
framebuffer RAM, so the DDX needed an update.
Also for normal non-PCIE radeons, this code should work to move the GART
table into FB as well which
I'm hoping I didn't break standard PCI GART on r128...
Can it be checked on plain AGP r128 card (with Option BusType PCI)?
Yes BusType on r128 should be good enough to check I didn't break it...
I didn't implement table in FB for r128... I've no idea if it would work
or not...
Table in
Hi!
Where can we get the new code?
Thanks!
X.org CVS and DRM CVS, the Mesa driver needed no work.
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
I should have some time next month.
Well, you get the idea - there is still much fun to be had with this
driver :)
Sure, much fun would come from a proper memory manager *if* it never gets
done.
I'm hoping to get s3tc/texrect support for r300 over the next while, the
texture
I was going to suggest that this might be related to Paul MacKerras'
texture upload fixes for r300 on big endian machines, but they don't
seem to be in DRM CVS yet. Are they only in the kernel yet? Which DRM
are you using?
They should be in DRM CVS, they came along with the r300 import,
It doesn't have the intimate knowledge needed to properly configure
MTRR's and fails in many cases.
I don't think we can really just nuke support for them, maybe we should
fix the support if we can... the problem I have is removing them will
signiciantly slow down a lot of working systems..
Not sure what to do there.. have to ask the fb devel guys..
Ben ?
I'm not sure if Antonio Daplas is on this list.. they are all on
[EMAIL PROTECTED]
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
But the *fb drivers do provide a nomtrr option in many cases. (But I'd
like to remove it from them too :-) or at least default those to off)
Sounds sane. Nvidia posted some patches a while ago that seem to be
getting kicked around a bit again to add support for PAT (per page
attributes)
drivers/char/drm/drmP.h defines a macro DRM_ARRAY_SIZE(x) for
determining the size of an array. kernel.h already provides one.
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Nak.
We have DRM_ for cross platform reasons in DRM, I could in theory get rid
of all of them in the kernel, but it
On Sun, 25 Sep 2005, Dieter Nützell wrote:
Worked for ages.
What shall I do, since I have a brand new Radeon 9550?
Yes, my system would be updated to SuSE 10.0 (2.6.13+), soon.
Can you try it now , I added __ATTR to the backwards compat header file...
it should build I think..
Dave.
--
Can you try it now , I added __ATTR to the backwards compat header file...
Where?
Sorry it should be in drm_compat.h now.. I hadn't noticed the commit
failed because my tree wasn't up to date..
Dave.
---
SF.Net email is sponsored by:
ok so this brings the question: how does naming it DRM_ARRAY_SIZE make
it more portable than naming it ARRAY_SIZE?
If *BSD doesn't have ARRAY_SIZE, then surely naming it ARRAY_SIZE is
easy for them to provide (after all they need to provide it already just
called DRM_ARRAY_SIZE); if they
I was talking to Ben on IRC about this and I realised I wasn't really sure
about this..
At the moment we allow the DRI client full r/w access to the framebuffer
if I'm not mistaken (for software fallbacks and the like)..
If I put the PCIE GART table into fb memory (which I've no choice in), the
I think the single most important point is to explicitly disallow
vendor-supplied libGL binaries in the LSB. Every other LSB componenet
relies on a single backing implementation for a reason, and in practice
the Nvidia libGL just causes endless pain where people acceidentally
link against
is loaded before the radeon kernel module.
I get this error with linux-2.6.13 and 2.6.9 both with agpgart and
uninorth driver built in. The drm module is from cvs, and I've tried
with xorg-6.8.99.15 and cvs. I'm running on a powebook5,2 with r300
card. You can find some logs and
DXT apears very stable (does not crash/lockup) but I experience corruption
(dansing colored tiles) when (semi)transparency is used in a DXT game
Neverwinter Night.
http://megahurts.dk/rune/stuff/image_DXT_transparency_err.jpg
Yeah I've got NWN here.. must put in on my laptop at some
I plan to release Mesa 6.4 fairly soon. That'll get imported into
the
X.org tree.
On http://dri.freedesktop.org/wiki/Building is write The Mesa drivers
now require libdrm to be installed.
This is correct for Mesa 6.4 or libdrm will stay only on Mesa HEAD ?
No both of them need
Thanks! I downloaded and compiled xorg and mesa from cvs today. Now if
I try to start X with dri active the computer locks up, and it's a
hard lock-up -- I can't ssh into the machine. Nothing special appears
in the syslog, and the xorg log does still say that dri is disabled
for some reason
Hi Roland,
Just to reconfirm what I said on IRC, I put my M7 back into my
machine and my internal application is defintely broken with the latest
radeon texrect changes...
I'll leave the M7 in for a few days and I'll have a look at the code if I
get a chance..
Dave.
--
David Airlie,
Does this patch help? It's somehwat overkill I guess always updating the
texture matrix when the _NEW_TEXTURE flag is set (though the r200 driver does
exactly that, not quite sure yet why), but I think currently the
update_texturematrix function may not get triggered if a texrect texture
I've been thinking a bit about this, and while I think Ian's work on the
memory manager has merit I'm starting to think we are really putting the
cart before the horse in some ways
My thinking on this is that the memory manager needs to live in libdrm,
not like the current bits in Xorg DDX,
I guess I don't see a problem with putting it in libdrm. I had just
assumed that the user-mode portion would end up living in
src/mesa/driver/dri/common or some place similar. There are some
advantages to putting it in libdrm, though (e.g., easier for EXA to use it).
Well the X server (EXA
The current CVS has changed the whole way this is called.. I'll be putting
that patch into git for 2.6.15 soon..
Dave.
On Fri, 28 Oct 2005, Jean Delvare wrote:
Hi David, all,
Looks like the PCI names database removal was done in a rush on the
drm front. I propose the following cleanup.
I got a warning and while going to fix it, I discovered some issues with the
code (including raciness).
While compiling 2.6.14 for x86_64, I got:
CC [M] drivers/char/drm/drm_bufs.o
/home/paolo/Admin/kernel/6/VCS/linux-2.6.14/drivers/char/drm/drm_bufs.c: In
function `drm_addmap_ioctl':
As a side note, I wonder it it wouldn't be worth defining a dedicated
macro for this one DRM_INFO() call, as you seem to be willing to have
the very same format for all drivers.
You should really look at DRM CVS, where this code is cut down
considerably and is going to be pushed into the
Log message:
Fix cpu_to_le32 same as kernel not sure it is correct for ppc
Looks correct, but as the PCIe GART table is in the framebuffer, the
card's byte swapping needs to be disabled for this.
Yes thats what I wanted paulus/benh to check out, I was unsure how the
swappers were
Looks good.. but dude diff -u plz
I can't read context diffs to save my life...
Dave.
On Wed, 23 Nov 2005, vehemens wrote:
I appear to of eliminated my remaining lockups by also idling the 2D engine in
radeon_cp_indirect which is being called from the xserver. Here is my latest
patch.
I made a fix to the locking code in main drm a couple of months ago.
The X server tries to get the DRM_QUIESCENT lock, but when the wait was
interrupted by a signal (like when you move a window around), the locking
function returned without error. This made the X server release other
I like to upgrade mach64 driver for inclusion in kernel and
desire a datasheet.
You'll need to get ATI to give you it, off late ATI have been ignoring
most requests from individual developers
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Current cvs does not build as part of kernel. There are
major changes since in-kernel version. I want to
build in kernel space by kernel make together with other
drivers.
Get current CVS, don't worry about the kernel, you don't want to bother
20050718 snapshot is close and builds after
I'm a bit rusty on the DRM but it looks like the changes are minor so
I may do the updates unless someone beats me to it, or indicates
there's a reason for things as they are.
I'm still catching up on email from the holiday weekend, but I plan to import
a new libdrm into the monolith
No ctx-FragmentProgram._Current!!
drmRadeonCmdBuffer: -22 (exiting)
dmesg shows:
[drm] Loading R300 Microcode
[drm:r300_emit_carefully_checked_packet0] *ERROR* Register 4500 failed check
as flag=00
[drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
My bad, texrect needs a newer
If you take a look at
http://www.skynet.ie/~airlied/butns.png
you'll see the same texture being drawn in two places, however the second
one is corrupt along the triangle join line...
the only difference between the two is the glTranslate called before them
moves the centre point to a different
As long as the texcoords at all four corners are being translated the same
amount, I wouldn't expect any differences in interpolation along the shared
edge for the two triangles.
If you've got a simple test program, perhaps some of us can test w/ different
hardware.
Still looking at small
Still looking at small test program.. but changing the GL_QUADS to two
GL_TRIANGLES seems to solve the problems.. mayve the M7 has some
degnerating problems..
Or maybe it doesn't support HW quads as ajax pointed out, and the sw quads
have some problems..
Dave.
--
David Airlie, Software
I was just getting Xglx GLX support working again, Xglx builds it GLcore
using the USE_MGL_NAMESPACE, however my r300 driver was calling the GLcore
version of a the glapi functions and variables..
The patch below is required, the glapi.h changes are probably okay, the
glapi.c changes I'm not
On a quick glance (though I'm not familiar with that driver), it looks to me
like introducing texture rectangle caused mipmaps to be disabled for
compressed textures.
oops, my bad.. I've checked in the fix.. thanks,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied /
501 - 600 of 1423 matches
Mail list logo
