Chris Ison wrote:
I have found a possable bug in the dri implementation of glPointSize()
... it doesn't seem to work at all. I'm using the radeon.o drm and the
r200 mesa drivers.
The source I was trying (and works perfectly in windows) is located at
the bottom of this page
Roland Scheidegger wrote:
Slightly OT, but here's an article comparing XiG Summit, dri cvs and the
ATI driver on a radeon 9000pro.
http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html
And to get this fully on-topic, is there a specific reason why the dri
driver is
Felix Kühling wrote:
I looked through the Imakefiles in order to resolve this. I found that
hwlog.o is not needed at all any more. vblank.o and xmlconfig.o are only
needed by mga, r128, r200 and radeon so far. The other objects (mm.o,
texmem.o and utils.o) seem to be used by all drivers. I'm not
Ville Syrjälä wrote:
Now I need to change the ddx driver to tell the 3D driver if the chipset
is a G550. But this causes some compatibility problems. The 3D driver
doesn't have a version number so the ddx doesn't know if the 3D driver can
handle the new G550 chipset type. Which means that a
just if thas a pending duty...
if the monitor refreshes at 75 Hz
then the grafics adapter has no need
for producing more then 75 frames per second.
having images updated before the cathode ray
has finished one image leads to showing two
images in a single refresh cycle which looks bad.
if you
Ian Romanick wrote:
Roland Scheidegger wrote:
Slightly OT, but here's an article comparing XiG Summit, dri cvs and
the ATI driver on a radeon 9000pro.
http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html
And to get this fully on-topic, is there a specific reason why
Chris Ison wrote:
On Mon, 2003-10-20 at 17:46, Keith Whitwell wrote:
Chris Ison wrote:
I have found a possable bug in the dri implementation of glPointSize()
... it doesn't seem to work at all. I'm using the radeon.o drm and the
r200 mesa drivers.
The source I was trying (and works perfectly in
On Mon, 2003-10-20 at 17:46, Keith Whitwell wrote:
Chris Ison wrote:
I have found a possable bug in the dri implementation of glPointSize()
... it doesn't seem to work at all. I'm using the radeon.o drm and the
r200 mesa drivers.
The source I was trying (and works perfectly in windows)
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unless
Chris Ison wrote:
I have found a possable bug in the dri implementation of glPointSize()
... it doesn't seem to work at all. I'm using the radeon.o drm and the
r200 mesa drivers.
https://sourceforge.net/tracker/?func=detailatid=100387aid=735997group_id=387
There was a patch floating around
Am I the only one who sees an undefined _gl_context_modes_destroy()
symbol with the current DRI tree on i830? LIBGL_DEBUG gives this:
libGL: XF86DRIGetClientDriverName: 1.3.0 i830 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/tls/i830_dri.so
libGL:
On Mon, 20 Oct 2003 02:39:00 +0300
Ville Syrjälä [EMAIL PROTECTED] wrote:
On Sun, Oct 19, 2003 at 11:30:08PM +0200, Felix Kühling wrote:
On Sun, 19 Oct 2003 20:12:59 +0300
Ville Syrjälä [EMAIL PROTECTED] wrote:
But I don't really like the fact that the driver forces the texture bpp
Hi,
I attached a patch that adds color dithering and rounding options to the
radeon and r200 drivers. I'd like to hear some comments about the
semantics of the options I chose before I commit anything and I'm not
sure I added the roundEnable flag in the right place. It is needed
because a set
On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
I do like the patch.
Cool.
Few questions/comments:
1) Did you check that it works with non-zero fbLocation ?
In particular, not all offsets need to have fbLocation added,
however, the code appears to be correct - I just
I do like the patch. Few questions/comments:
1) Did you check that it works with non-zero fbLocation ?
In particular, not all offsets need to have fbLocation added,
however, the code appears to be correct - I just worry that
it may add (or not add) fbLocation in the wrong place.
Keith Whitwell wrote:
The problem is (probably) due to excessive flushing introduced by the
changes Ian referenced. I had time to put together a patch, but at that
point was having real issues getting CVS to compile. These are probably
at my end, but before they were resolved I got
Eric Anholt is in the middle of doing a generic fix for this problem. See the
Adding hardware detection to DRI drivers thread. The current DRM drivers now
do PCI ID detection on both Linux and BSD. He is also adding an enum for chip
family but I'm not sure what the status is. There is supposed to
On Mon, 2003-10-20 at 18:14, Michel Dänzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least
There was a thread a few months ago concerning writing a useful fallback path
(ie not swrast) that generated larger points with various primitives. I don't
think it actually reached a point where I saw a patch ready for inclusion in
CVS, however.
Keith
Found the thread you were
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
I do like the patch.
Cool.
Few questions/comments:
1) Did you check that it works with non-zero fbLocation ?
In particular, not all offsets need to have fbLocation
20 matches
Mail list logo
