Do you still see the artifacts with debugging and non-redirected output ?
If not it must be that R300 and later hardware requires delays in
command stream. This would be new - and difficult to debug without
specifications.
Yes, they are still there, but I think that they occur less often,
thoug
On Sat, 1 Jan 2005, Ben Skeggs wrote:
The gears seem to look normal now.
Without drm debugging I was able to resize the glxgears window without
lockups, but only while the r300_dri debug output wasn't redirected. With
glxgears 2>/dev/null, resizing the window caused a lockup.
The interesting t
The gears seem to look normal now.
Without drm debugging I was able to resize the glxgears window without
lockups, but only while the r300_dri debug output wasn't redirected.
With glxgears 2>/dev/null, resizing the window caused a lockup.
The interesting thing is that the artifacts still appear
On Thursday 30 December 2004 14:20, Adam Jackson wrote:
> - Option 4: Link libdrm into the DRI drivers dynamically instead.
> Pros: Doesn't change libGL/driver ABI.
> Cons: Requires server control over runtime link path, sketchy. DDX also
> calls into libdrm, so DRI driver would need to be loaded
Hi all,
I have retagged rotating_gears snapshot - both drm and r300 driver were
changed.
Turns out that the magic 20b0 register is similar to R200_SE_VTE_CNTL
and setting it to disable Z scaling and offset in viewport fixes glxgears
display. I am not sure why this is so, perhaps the bits ha
Felix Kühling wrote:
>
> Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> > The goal: Load DRI drivers from the server's libglx, rather than the
> > software-based libGLcore.
> >
> > Currently there are four server-side modules: dri, drm, glx, and GLcore.
> > There are also three client-side
Adam Jackson wrote:
> > I have a seventh option for you. Feel free to flame me if it sounds
> > stupid ...
> >
> > - Option 7: Run the GLX server as a separate process forked by the
> > Xserver. This way you get rid of the problem with the same library
> > linked into the same process multiple time
r300_demo runs with or without this code (and without code in
radeon_state.c too)
>One more thing: try this code instead:
>
>if (IS_FAMILY_R300(dev_priv)) {
>BEGIN_RING( 6 );
>
>OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x0002);
>OUT_RING_REG(0x4F18, 0x0001); /*
On Fri, 31 Dec 2004 14:16:57 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> glxProxy effectively would put the GL rendering in its own thread. And
> nothing necessarily prevents us from creating a new thread for in-server DRI.
>
> If the rendering is properly encapsulated, then making it multic
On Friday 31 December 2004 13:41, Roland Mainz wrote:
> Felix Kühling wrote:
> > - Option 7: Run the GLX server as a separate process forked by the
> > Xserver. This way you get rid of the problem with the same library
> > linked into the same process multiple times.
> >
> > Pros: No existing ABIs
On Friday 31 December 2004 06:04, Michel DÃnzer wrote:
> On Thu, 2004-12-30 at 14:20 -0500, Adam Jackson wrote:
> > - Option 3: Move libdrm from the DRI drivers into libGL (dlopen linkage)
> > Pros: Minimal server impact. New libdrm could be shared between client
> > and server. With a little cle
On Fri, 31 Dec 2004 13:17:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Friday 31 December 2004 09:56, Felix Kühling wrote:
> > I have a seventh option for you. Feel free to flame me if it sounds
> > stupid ...
> >
> > - Option 7: Run the GLX server as a separate process forked by the
> >
On Friday 31 December 2004 09:56, Felix KÃhling wrote:
> I have a seventh option for you. Feel free to flame me if it sounds
> stupid ...
>
> - Option 7: Run the GLX server as a separate process forked by the
> Xserver. This way you get rid of the problem with the same library
> linked into the sam
Hi Felix - nice method :)
It would be nice to have this configurable on a per-application basis.
I imagine applications with a lot of detail in near scenes (autocad like
perhaps ?) would work better with the old way of doing things.
On the other hand, flight simulators are probably a prime candidat
One more thing: try this code instead:
if (IS_FAMILY_R300(dev_priv)) {
BEGIN_RING( 6 );
OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x0002);
OUT_RING_REG(0x4F18, 0x0001); /* Z cache? */
/* It seems a delay is needed */
On Fri, 31 Dec 2004, Peter Zubaj wrote:
Hi,
I played with it yesterday.
I have x11perf lockups too. And X sometimes crash (simply exits) to
login screen. I use FC3 and then when I do ctrl+alt+F1 (to get to
console) system freezes (few uppers rows are redrawn (maybe by console
text)), but no switch
On Fri, 31 Dec 2004, Boris Peterbarg wrote:
Hi Vladimir,
Just one question - are these the debugging messages that are supposed to
show if I don't add '2>/dev/null'?
Yes - they note the type of primitive and the amount of vertices being
sent to the hardware.
These message come from r300_render.
On Fri, 31 Dec 2004 11:34:52 -0500, Owen Taylor <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-12-31 at 10:45 -0500, Jon Smirl wrote:
> I don't know if an incremental approach would be easier; there's clearly
> a lot of refactoring to do to get to a point where rendering through
> GL is clean. But the i
On Fri, 2004-12-31 at 10:45 -0500, Jon Smirl wrote:
> [...] Some kind of
> fbdev/drm merge is a requirement of getting X on GL working.
[ straying off-topic for this list... ]
I would argue that this isn't necessarily true. As soon as you can get
dri
drivers running within the X server, it woul
On Fri, 31 Dec 2004 15:49:50 +0100, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
>
> I was wondering what is going on with drm & fbdev merging ?
> Still planed ? Is the drm-core is a first move in that direction ?
I have two new babies in the house that were born two months
prema
Am Fr, den 31.12.2004 schrieb Dave Airlie um 7:28:
> Okay some people have commented on the DRM CVS of late, and are unsure of
> what is happening with it,
>
> I'm very willing to drop the shared and linux directories into an archived
> area but that will stop all support for Linux 2.4,
>
> but a
Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> The goal: Load DRI drivers from the server's libglx, rather than the
> software-based libGLcore.
>
> Currently there are four server-side modules: dri, drm, glx, and GLcore.
> There are also three client-side pieces: libGL, *_dri.so, and (u
Dave Airlie wrote:
Okay some people have commented on the DRM CVS of late, and are unsure of
what is happening with it,
I'm very willing to drop the shared and linux directories into an archived
area but that will stop all support for Linux 2.4,
but at the moment I'm getting the impression more peo
Hi,
I want to share an idea that I had, which drastically improves the depth
buffer quality on Savage4 hardware. Maybe the same can be applied to
different hardware too.
Short version: reverse the depth range (z' = 1 - z) such that far
coordinates map to z'=0 and near coordinates to z'=1. Then us
Dave Airlie wrote:
There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally
imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical
on both sides, modulo wrapping some things like malloc to u
Hi!
Dave Airlie wrote:
Okay I've rebuilt the via drm tree (bk://drm.bkbits.net/drm-via)
It should work but I've no way to test it, I think the drm is close to
secure now if not already, and if I get the nod from the people who know
these things (Thomas, Erdi and Keith - consider yourselves the peop
On Thu, 2004-12-30 at 12:33 -0800, Mike Mestnik wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
>
> I'm talking about 2d Xdrivers, where current MergedFB is built. I think
> these can be built with the Mesa/lib/r200_dri.so files that live in
> X11R6/lib/modules/dri/r200_dri.so?
Nope, compl
Adam Jackson wrote:
On Thursday 30 December 2004 21:44, Jon Smirl wrote:
I've been out of the DRI loop for a while since all I do is help feed
and change two crying babies, but we also need think about the GL
standalone case. libdrm is linked into the dri.so's so that they can
be u
Hi,
I played with it yesterday.
I have x11perf lockups too. And X sometimes crash (simply exits) to
login screen. I use FC3 and then when I do ctrl+alt+F1 (to get to
console) system freezes (few uppers rows are redrawn (maybe by console
text)), but no switch to text mode.
When I uncomment these r
29 matches
Mail list logo
