On Thu, 2005-01-20 at 03:03 +0100, Stephane Marchesin wrote:
> Michel DÃnzer wrote:
>
> >What happened to Stephane's surface allocator, BTW? If you just whack
> >the surface registers directly from the X server, it becomes hard if not
> >impossible to introduce such an allocator, at least for the
On Wed, 2005-01-19 at 17:30 +0100, Roland Scheidegger wrote:
> Michel DÃnzer wrote:
> >
> Also, if doing that in the drm, we'd need to mess with
> OFFSET_CNTL there too (i.e. messy calculation or another field
> in the sarea).
> >>>
> >>>
> >>> You mean CRTC_OFFSET? I'm not sure t
Michel DÃnzer wrote:
fixed a copy & paste error in the non-core drm version, and it actually
auto-refreshes the screen when switching between a tiled and untiled resolution...
Nice.
What happened to Stephane's surface allocator, BTW? If you just whack
the surface registers directly from the X ser
Michel DÃnzer wrote:
and furthermore there needs to be some code to deal with disabled
irqs. Is this such a big issue? I'm happy to leave it broken.
I don't know, you brought it up, I just brainstormed how it could be
done. :)
Ok. I leave it broken then at least for now.
Also, if doing that in t
On Wed, 2005-01-19 at 13:32 +0100, Roland Scheidegger wrote:
> Michel DÃnzer wrote:
> > On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote:
> >
> The DRM could update the register in the vblank interrupt
> handler?
> >
> >
> > [...]
> >
> >
> >> How would you do that in-kern
Michel DÃnzer wrote:
On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote:
The DRM could update the register in the vblank interrupt
handler?
[...]
How would you do that in-kernel? There is vblank interrupt related
stuff (radeon_driver_vblank_wait for instance), but that only is
called whe
On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote:
>
> >> The DRM could update the register in the vblank interrupt handler?
[...]
> How would you do that in-kernel? There is vblank interrupt related stuff
> (radeon_driver_vblank_wait for instance), but that only is called when a
> use
Michel DÃnzer wrote:
On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote:
Michel DÃnzer wrote:
Speaking of mergedfb and page flipping: Is it really necessary to
add a new private SAREA field and a corresponding setparam?
Isn't it possible to set the generic SAREA fields as the DRM
expects
On Tue, 2005-01-18 at 16:31 +0100, Roland Scheidegger wrote:
> Alex Deucher wrote:
> > Actually DRIAdjustframe() and friends in dri.c may still be the
> > problem. it does some wrapping of the adjustframe() functions and
> > calls them, perhaps incorrectly for mergedfb. I could be wrong though
>
On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote:
> Michel DÃnzer wrote:
> >
> > Speaking of mergedfb and page flipping: Is it really necessary to add
> > a new private SAREA field and a corresponding setparam? Isn't it
> > possible to set the generic SAREA fields as the DRM expects t
Michel DÃnzer wrote:
On Tue, 2005-01-18 at 16:31 +0100, Roland Scheidegger wrote:
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be wrong th
Roland Scheidegger wrote:
The DRM could update the register in the vblank interrupt handler?
That sounds right (didn't know there was such a handler, but there it
is...). I can't see how to do that though. Looks complicated :-(.
Hmm, played around with waiting on vblank a bit. Tried both
RADEONWai
On Tue, 18 Jan 2005 16:31:48 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> > Actually DRIAdjustframe() and friends in dri.c may still be the
> > problem. it does some wrapping of the adjustframe() functions and
> > calls them, perhaps incorrectly for mergedfb. I cou
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be wrong though
I haven't really traced all that is going on there. Something is
causing the
Michel DÃnzer wrote:
I've uploaded a new version here:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx8.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri8.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm8.diff
On Tue, 18 Jan 2005 15:43:23 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Michel Dänzer wrote:
> >> I've uploaded a new version here:
> >> http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx8.diff
> >> http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_
On Mon, 2005-01-17 at 21:34 +0100, Roland Scheidegger wrote:
> Michel DÃnzer wrote:
> > On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
> >
> > The location of the framebuffer as seen by the
> > GPU needs is defined by MC_FB_LOCATION. All current components have
> > fields named along
Alex Deucher wrote:
I'll give this a test on mergedfb in the next day or so. I quickly
perused the DDX changes and I noticed this:
+if (info->allowColorTiling && (pScrn->virtualY > 2048)) {
+ xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+ "Color tiling not supported with virt
Michel DÃnzer wrote:
On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
One question I still have though is regarding to the surface setup, I'm
actually not convinced the addresses are correct in all cases, because I
don't understand how all that address translation stuff works. So
cur
On Mon, 17 Jan 2005 21:34:40 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Michel Dänzer wrote:
> > On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
> >
> >>One question I still have though is regarding to the surface setup, I'm
> >>actually not convinced the addresses are corr
On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
>
> One question I still have though is regarding to the surface setup, I'm
> actually not convinced the addresses are correct in all cases, because I
> don't understand how all that address translation stuff works. So
> currently the
On Thu, 13 Jan 2005 15:25:46 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Ok, here's a new version. It also contains a supposed patch for
> mergedfb-pageflip (untested, but I need that for color tiling, otherwise
> I'd need to redo the crtc address calculation in the drm).
>
> http://hom
Alex Deucher wrote:
On Thu, 13 Jan 2005 15:25:46 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
Ok, here's a new version. It also contains a supposed patch for
mergedfb-pageflip (untested, but I need that for color tiling, otherwise
I'd need to redo the crtc address calculation in the drm).
h
On Thu, 13 Jan 2005 22:23:31 + (GMT), Dave Airlie <[EMAIL PROTECTED]> wrote:
> This looks great, just an aside question, how much work would it be to get
> this working with solo considering solo uses radeonfb to set the screen
> mode not the X DDX...
>
> I might be able to make some time to h
Dave Airlie wrote:
On Thu, 13 Jan 2005, Roland Scheidegger wrote:
Ok, here's a new version. It also contains a supposed patch for
mergedfb-pageflip (untested, but I need that for color tiling,
otherwise I'd need to redo the crtc address calculation in the
drm).
This looks great, just an aside qu
On Thu, 13 Jan 2005, Roland Scheidegger wrote:
> Ok, here's a new version. It also contains a supposed patch for
> mergedfb-pageflip (untested, but I need that for color tiling, otherwise I'd
> need to redo the crtc address calculation in the drm).
This looks great, just an aside question, how mu
Roland Scheidegger wrote:
This scheme could potentially have a slight performance impact for 2d
use (will do some measurements later today) but I don't expect anything
noticeable.
Ok did some testing (x11perf -all -time 1 -repeat 3), with unpatched,
patched but tiling disabled, and with tiling.
On Thu, 13 Jan 2005 15:25:46 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Ok, here's a new version. It also contains a supposed patch for
> mergedfb-pageflip (untested, but I need that for color tiling, otherwise
> I'd need to redo the crtc address calculation in the drm).
>
> http://hom
Ok, here's a new version. It also contains a supposed patch for
mergedfb-pageflip (untested, but I need that for color tiling, otherwise
I'd need to redo the crtc address calculation in the drm).
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm7.diff
http://homepage.his
29 matches
Mail list logo
