Chris Ison wrote:
>
> Michel Dänzer wrote:
> >
> > On Sam, 2003-02-08 at 23:17, Chris Ison wrote:
>
> >
> > Does Option "XaaNoScanlineCPUToScreenColorExpandFill" work around it?
> >
>
> um, no ...
>
> >
> > Well, glxgears and the X server do completely different things. You're
> > saying it als
On Sat, 2003-02-08 at 17:46, Eric Anholt wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/lib/GL/dri/drm/
> Changes by: anholt@sc8-pr-cvs1. 03/02/08 17:46:32
>
> Log message:
> Use the right subdirs for NetBSD.
>
> Modified files:
> xc/xc/lib/GL/dri/drm/:
On Son, 2003-02-09 at 02:24, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Sam, 2003-02-08 at 18:56, Michel Dänzer wrote:
> >
> > Hmm, moving this to mesa-4-0-4-branch is trickier than I thought. Here's
> > a quick'n'dirty merge, but maybe we want to move over more of Keith's
> > recent work
Michel Dänzer wrote:
On Sam, 2003-02-08 at 18:56, Michel Dänzer wrote:
On Sam, 2003-02-08 at 18:45, Charl P. Botha wrote:
On Sat, Feb 08, 2003 at 06:24:28PM +0100, Felix Kühling wrote:
Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
as the drm_drv.h template seems to
On Sam, 2003-02-08 at 23:17, Chris Ison wrote:
> Chris Ison wrote:
> >
> > here is the log as requested ... also pcigart is enabled in the source
> > ...
> >
> > as for x11perf, I may have miss understood the option, but its atleast 3
> > *text* ones (after the 3rd I gave up), but the dots and li
On 8 Feb 2003, Michel Dänzer wrote:
>> > Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
>> > as the drm_drv.h template seems to expect DRIVER_RELEASE to handle this.
>> > DRIVER_RELEASE in i810.h does this too. The (1 line) patch is attached.
>>
>> Thanks for fixing yet a
Learn To Save $1,000's A Year... Starting Now!Get FOUR Free Quotes & Save 70% Today!
Health
Life
Auto
Group Health
Home/Renters
Save up to 70% on insurance!
FREE, no obligation service!
Complete easy on-line form in just minutes!
Multiple agents and carrier
On Sun, Feb 09, 2003 at 01:31:19AM +0200, Arkadi Shishlov wrote:
> It tries to draw a smoke cloud particle effect. Internally it use 64x64
Me bad. It is actually a polygon from explosion cause I had particles
turned off at these screenshots. Anyway Alpha channel doesn't work in all
places it is us
On Sat, Feb 08, 2003 at 02:45:20PM -0800, Ian Romanick wrote:
> That's very odd. I don't much, if anything, has changed in the texture
> management code in the trunk for that driver in quite some time. Do the
> rainbows persist or do they disappear after the dynamic lighting is
> gone? I migh
>
> You say "the system locks." Is it a total-death hard lock? Do you have
> another box that could SSH in? It might be intereting to run the app in
> gdb to see where it's wedged.
>
I think it could be an app lock, but as with GL unless the screen is
reset, you can't tell just by looking at
Chris Ison wrote:
Chris Ison wrote:
here is the log as requested ... also pcigart is enabled in the source
...
as for x11perf, I may have miss understood the option, but its atleast 3
*text* ones (after the 3rd I gave up), but the dots and lines ones
worked.
glxgears works fine, so its obvious
Arkadi Shishlov wrote:
Current mga driver, both from mesa and trunk branches, has a problem
which 4.2.1 driver doesn't have. Look at this screenshots (QuakeForge):
http://idea.hosting.lv/a/tmp/mga-shots/1.jpg
http://idea.hosting.lv/a/tmp/mga-shots/2.jpg
http://idea.hosting.lv/a/tmp/mga-shots/3.jp
Chris Ison wrote:
>
> here is the log as requested ... also pcigart is enabled in the source
> ...
>
> as for x11perf, I may have miss understood the option, but its atleast 3
> *text* ones (after the 3rd I gave up), but the dots and lines ones
> worked.
>
> glxgears works fine, so its obviously
Current mga driver, both from mesa and trunk branches, has a problem
which 4.2.1 driver doesn't have. Look at this screenshots (QuakeForge):
http://idea.hosting.lv/a/tmp/mga-shots/1.jpg
http://idea.hosting.lv/a/tmp/mga-shots/2.jpg
http://idea.hosting.lv/a/tmp/mga-shots/3.jpg
This visual artifact
On Sam, 2003-02-08 at 18:56, Michel Dänzer wrote:
> On Sam, 2003-02-08 at 18:45, Charl P. Botha wrote:
> > On Sat, Feb 08, 2003 at 06:24:28PM +0100, Felix Kühling wrote:
> > > Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
> > > as the drm_drv.h template seems to expect DRI
On Sam, 2003-02-08 at 18:45, Charl P. Botha wrote:
> On Sat, Feb 08, 2003 at 06:24:28PM +0100, Felix Kühling wrote:
> > Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
> > as the drm_drv.h template seems to expect DRIVER_RELEASE to handle this.
> > DRIVER_RELEASE in i810.h d
On Sat, Feb 08, 2003 at 06:24:28PM +0100, Felix Kühling wrote:
> Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
> as the drm_drv.h template seems to expect DRIVER_RELEASE to handle this.
> DRIVER_RELEASE in i810.h does this too. The (1 line) patch is attached.
Thanks for f
Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
as the drm_drv.h template seems to expect DRIVER_RELEASE to handle this.
DRIVER_RELEASE in i810.h does this too. The (1 line) patch is attached.
Felix
On Sat, 8 Feb 2003 17:49:15 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
Hi,
There were some seemingly random lockups with with my Radeon 7500. Now I
found out that they are actually reproducable. Run for instance the
gflux xscreensaver hack repeatedly. Short after starting it the 32nd
time X locks up. RADEON_DEBUG_DMA=1 output indicates that this is
another DMA buffer
VP-RX
Will Enlarge Your Penis 3+ Inches
100% GUARANTEED TO WORK!
Hi, my name is Doctor A J Andrews
M.D, We have just recently created the only pill in the world the works
on enlarging the male penis.
Our tests show that out of the 17,000
Men from around the world who participated in our survey, th
I would like to request a fundamental change, to a minor part of the DRM
API.
I believe that the current semantics of
ioctl(DRM_IOCTL_SET_UNIQUE) and ioctl(DRM_IOCTL_GET_UNIQUE), violate POSIX/SUS
understanding of the ioctl command.
To quote from the single unix specification version 2 (1997)
htt
On Fri, 7 Feb 2003, Ian Romanick wrote:
Attached is the initial rough-draft of the design document for the next
generation memory manager. It is currently plain-text. When I polled
people on #dri-devel the consensus was that plain-text would be the most
useful format. I suspect at some point I
I've been poking around the xfree86 server side of dri a bit ...
eg: hw/xfree86/drivers/ati/radeon_dri.c
and it occurs to me... why is this stuff in the core server?
Why isnt it in the dri "module", rather than hacked into the main server?
I've scanned through most of it, and it all looks like st
23 matches
Mail list logo
