On Thu, Mar 03, 2005 at 04:48:58AM +0100, Roland Scheidegger wrote:
here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could not
read back alpha values (always 0xff) and I don't think there
On Thu, Mar 03, 2005 at 10:04:02AM +0200, Ville Syrjälä wrote:
On Thu, Mar 03, 2005 at 04:48:58AM +0100, Roland Scheidegger wrote:
here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could
Jerome Glisse writes:
If you find the guilty commit let me know :)
It appears to be this code in r300_state.c (line 1625):
#if 0
/* textures enabled ? */
if(rmesa-state.texture.tc_count0){
rmesa-state.vertex_shader=SINGLE_TEXTURE_VERTEX_SHADER;
}
On Thu, Mar 03, 2005 at 04:48:58AM +0100, Roland Scheidegger wrote:
here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could not
read back alpha values (always 0xff) and I don't think there
I now have the radeon DRI going on my G5 under a 64-bit kernel. I
have split out the parts of the changes that I have made that relate
to implementing ioctl compatibility for 32-bit processes. The patch
is at:
http://ozlabs.org/~paulus/drm-64b.patch
The patch is against a 2.6.11 kernel tree.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=943
--- Additional Comments From [EMAIL PROTECTED] 2005-03-03 01:21 ---
Vladimir Dergachev wrote:
On Wed, 2 Mar 2005, Vladimir Dergachev wrote:
On Thu, 3 Mar 2005, Boris Peterbarg wrote:
athlon xp 2500+, kernel 2.6.10, xorg cvs from 27/02/05
Yes, I compiled the drivers. xorg loaded them.
I'm using udev. With the drm before the changes, /dev/dri/card0 is
1) Try updating r300_driver (or checking out a fresh copy - maybe
SourceForge lags a little.
2) Check which version of the driver is loading. Did it initialize ok ?
My dmesg looks like this:
I updated again, but I get only this line on the new drm initialization:
[drm]
Brian Paul wrote:
I'll assume people are familiar with GL_EXT_framebuffer_object. If not,
read the spec.
If you still have questions after reading the spec, you can ask me on
#dri-devel on freenode. I try to be on there as often as I can.
The gl_renderbuffer's
BaseFormat and DataType will
On Thursday 03 March 2005 10:42, Brian Paul wrote:
The stencil, depth, accum, aux, etc. buffer pointers in GLframebuffer
will go away, replaced by gl_renderbuffer_attachment members.
Each of the logical buffers (such as color, depth, stencil, etc) which
form the overall framebuffer will be
Adam Jackson wrote:
On Thursday 03 March 2005 10:42, Brian Paul wrote:
The stencil, depth, accum, aux, etc. buffer pointers in GLframebuffer
will go away, replaced by gl_renderbuffer_attachment members.
Each of the logical buffers (such as color, depth, stencil, etc) which
form the overall
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not read back alpha values (always
0xff) and I don't think there was
On Thu, 03 Mar 2005 17:45:15 +0100, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not
Paul Mackerras wrote:
Jerome Glisse writes:
If you find the guilty commit let me know :)
It appears to be this code in r300_state.c (line 1625):
#if 0
/* textures enabled ? */
if(rmesa-state.texture.tc_count0){
On Thu, Mar 03, 2005 at 05:45:15PM +0100, Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not read back alpha
Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not read back alpha values (always
0xff) and I
Ville Syrjälä wrote:
Like I said before only the RGB components are blended. You can
choose to write 0, 1, As, 1-As, Ad or 1-Ad to the destination
alpha ([EMAIL PROTECTED] register). Currently the
driver seems to write 0. It would probably be a better idea to
write 1 instead.
Sorry, but I just
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you
can see that there are problems with light reflection in those places
where
Dieter Nützel wrote:
You'll even get a newer version, Alan pointed out some subtle issues
with the macro expansion (one of the reasons I don't particularly like
macros...). Instead of fixing all GET_SRC/DST_PTR macros, I got rid of
them too, since they were identical again in all drivers which use
Roland Scheidegger wrote:
You're right. I really wanted to do a cvs diff to include new files, but
I guess it's not possible, and hacking together the diffs manually is
just asking for such errors :-).
If you've done a 'cvs add' (or 'cvs rm') on the files, you can do 'cvs
diff -Nud'.
With the latest changes to drm in r300_driver I was reminded of a few
problems with R420 cards and the r300 driver.
1) the Xorg driver defaults to R200 for R420 cards.
RADEONDRIKernelInit() in radeon_dri.c
2) RADEONInitDispBandwidth() is disabled for r420 cards.
I have no problem enabling this.
Roland Scheidegger wrote:
Michel Dnzer wrote:
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI
Ben Skeggs writes:
Do you still see the same breakage with vertex buffer mode? The textures in
neverball are broken for me in immediate mode with the latest cvs.
No, I don't in fact, with vertex buffer mode it is mostly as good as
before. The one difference I have noticed is that the first
On Fri, 4 Mar 2005, Paul Mackerras wrote:
Vladimir Dergachev writes:
The new call is an attempt to get multitexturing working, at least partly.
Does your program use multitexturing ? (Also where can I download it for
testing ? ) Thank you !
The screenshots I posted were from Emilia pinball from
On Thu, 2005-03-03 at 10:12 -0500, Vladimir Dergachev wrote:
With which part ? ;)
On having a small stub module that does just IRQs ... I think the base
module should be the fbdev (mode setting etc...)
Oh, but I was not suggesting that. I just meant that interrupt handling
code is
On Thu, 3 Mar 2005, Rune Petersen wrote:
Adam K Kirchhoff wrote:
Any idea why the PCI IDs for the radeon 9800 were removed from the DRM?
AFIK most/all IDs added were lost when the DRM was updated.
No special reason.
My fault - there was probably a reject that I overlooked.
Thank you for putting
Vladimir Dergachev wrote:
On Thu, 3 Mar 2005, Rune Petersen wrote:
1) the Xorg driver defaults to R200 for R420 cards.
RADEONDRIKernelInit() in radeon_dri.c
Could you test that your patch works with regular freedesktop.org DRM
driver as far as 2d is concerned ? It should print a message in the
Vladimir Dergachev writes:
Does everything work with vb mode ? (you can switch to it in the end of
r300_driver/r300/r300_render.c, search for #else)
Most things seem to work, except bzflag segfaults. I could try to
track down where tonight if that would help.
Paul.
28 matches
Mail list logo
