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
http://www.opengl.org/dev
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 q
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 1
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 combin
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 ar
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 i
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 w
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 i
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 (
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=detail&atid=100387&aid=735997&group_id=387
There was a patch floating around som
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: Ope
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
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 ROUN
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 j
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 sidetracked
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 t
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
> 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 t
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 hav
I realize I should have sent this out earlier, but on Thursday I
committed a change to the manner that DRM devices are probed. Ideally
it won't have any effect on people, but there may have been problems.
Basically, the DRM only attaches now when it finds a device ID it knows
of. I think the PCI
On Mon, 2003-10-20 at 14:52, Jon Smirl wrote:
> 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 bu
23 matches
Mail list logo