Re: new radeon tiling patch
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 server, it becomes hard if not
impossible to introduce such an allocator, at least for the surfaces
touched directly by the X server...
Ok, I'm late, but here it is.
Also attached is the small patch for the ddx.
It is supposed to be used with the drmCommand interface, btw :
drmRadeonSurfaceAlloc drmalloc_front;
drmalloc_front.lower=(info->frontOffset) &~0x3ff ;
drmalloc_front.size=bufferSize -1 ;
drmalloc_front.flags=pitch | RADEON_SURF_TILE_COLOR_MACRO;
drmCommandWrite(info->drmFD, DRM_RADEON_SURF_ALLOC,
&drmalloc_front,sizeof(drmalloc_front));
Stephane
Index: shared/radeon.h
===
RCS file: /cvs/dri/drm/shared/radeon.h,v
retrieving revision 1.34
diff -u -r1.34 radeon.h
--- shared/radeon.h 8 Dec 2004 16:43:00 - 1.34
+++ shared/radeon.h 20 Jan 2005 01:43:05 -
@@ -84,6 +84,8 @@
* (No 3D support yet - just microcode loading).
* 1.13- Add packet R200_EMIT_TCL_POINT_SPRITE_CNTL for ARB_point_parameters
* - Add hyperz support, add hyperz flags to clear ioctl.
+ * 1.14- Add support for color tiling
+ * - Add R100/R200 surface allocation/free support
*/
#define DRIVER_IOCTLS \
[DRM_IOCTL_NR(DRM_IOCTL_DMA)] = { radeon_cp_buffers, 1, 0 }, \
@@ -112,5 +114,7 @@
[DRM_IOCTL_NR(DRM_IOCTL_RADEON_IRQ_EMIT)] = { radeon_irq_emit,1, 0 }, \
[DRM_IOCTL_NR(DRM_IOCTL_RADEON_IRQ_WAIT)] = { radeon_irq_wait,1, 0 }, \
[DRM_IOCTL_NR(DRM_IOCTL_RADEON_SETPARAM)] = { radeon_cp_setparam, 1, 0 }, \
+ [DRM_IOCTL_NR(DRM_IOCTL_RADEON_SURF_ALLOC)] = { radeon_surface_alloc,1, 0 }, \
+ [DRM_IOCTL_NR(DRM_IOCTL_RADEON_SURF_FREE)] = { radeon_surface_free ,1, 0 }, \
#endif
Index: shared/radeon_cp.c
===
RCS file: /cvs/dri/drm/shared/radeon_cp.c,v
retrieving revision 1.46
diff -u -r1.46 radeon_cp.c
--- shared/radeon_cp.c 8 Dec 2004 16:43:00 - 1.46
+++ shared/radeon_cp.c 20 Jan 2005 01:43:05 -
@@ -1267,6 +1267,7 @@
static int radeon_do_init_cp( drm_device_t *dev, drm_radeon_init_t *init )
{
+ int i;
drm_radeon_private_t *dev_priv = dev->dev_private;
DRM_DEBUG( "\n" );
@@ -1520,6 +1521,11 @@
dev_priv->last_buf = 0;
+ for(i=0;isurfaces[i].refcount = 0;
+ for(i=0;i<2*RADEON_MAX_SURFACES;i++)
+ dev_priv->virt_surfaces[i].filp = 0;
+
radeon_do_engine_reset( dev );
return 0;
Index: shared/radeon_drm.h
===
RCS file: /cvs/dri/drm/shared/radeon_drm.h,v
retrieving revision 1.25
diff -u -r1.25 radeon_drm.h
--- shared/radeon_drm.h 8 Dec 2004 16:43:00 - 1.25
+++ shared/radeon_drm.h 20 Jan 2005 01:43:06 -
@@ -231,6 +231,8 @@
#define RADEON_MAX_TEXTURE_LEVELS 12
#define RADEON_MAX_TEXTURE_UNITS 3
+#define RADEON_MAX_SURFACES8
+
/* Blits have strict offset rules. All blit offset must be aligned on
* a 1K-byte boundary.
*/
@@ -403,6 +405,8 @@
#define DRM_RADEON_IRQ_WAIT 0x17
#define DRM_RADEON_CP_RESUME 0x18
#define DRM_RADEON_SETPARAM 0x19
+#define DRM_RADEON_SURF_ALLOC 0x1a
+#define DRM_RADEON_SURF_FREE 0x1b
#define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_CP_INIT, drm_radeon_init_t)
#define DRM_IOCTL_RADEON_CP_START DRM_IO( DRM_COMMAND_BASE +
DRM_RADEON_CP_START)
@@ -429,6 +433,8 @@
#define DRM_IOCTL_RADEON_IRQ_WAIT DRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_IRQ_WAIT, drm_radeon_irq_wait_t)
#define DRM_IOCTL_RADEON_CP_RESUME DRM_IO( DRM_COMMAND_BASE +
DRM_RADEON_CP_RESUME)
#define DRM_IOCTL_RADEON_SETPARAM DRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_SETPARAM, drm_radeon_setparam_t)
+#define DRM_IOCTL_RADEON_SURF_ALLOC DRM_IOW(DRM_COMMAND_BASE +
DRM_RADEON_SURF_ALLOC, drm_radeon_surface_alloc_t)
+#define DRM_IOCTL_RADEON_SURF_FREE DRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_SURF_FREE, drm_radeon_surface_free_t)
typedef struct drm_radeon_init {
enum {
@@ -630,5 +636,19 @@
#define RADEON_SETPARAM_FB_LOCATION1 /* determined framebuffer location */
+/* 1.14: Clients can allocate/free a surface
+ */
+
+typedef struct drm_radeon_surface_alloc {
+ unsigned int lower;
+ unsigned int size;
+ unsigned int flags;
+} drm_radeon_surface_alloc_t;
+
+typedef struct drm_radeon_surface_free {
+ unsigned int lower;
+} drm_radeon_surface_free_t;
+
+
#endif
Index: shared/radeon_drv.h
===
RCS file: /cvs/dri/drm/shared/radeon_drv.h,v
retrieving revision 1.38
diff -u -r1.38
RE: DRI and Composite
> > On Wed, 2005-01-19 at 23:49 +0100, Amir Bukhari wrote: > > > > > On Wednesday 19 January 2005 17:29, Amir Bukhari wrote: > > > > Hallo, > > > > Our users of Looking Glass 3D Desktop have a problem getting DRI to > work > > > > with LG3D. DRI is disabled when Composite Extension enabled. Is > There > > > any > > > > way to enable DRI when composite enabled? > > > > Nvidia driver has an Option in xorg.conf which let also GLX > initialized > > > > when Composite is enabled! > > And do people like the incorrect results of that? > > > > There is no code in Xorg HEAD to disable DRI when Composite is > enabled. I > > > would assume something in the lg3d code is turning DRI off. > > > > To be more exactly, our users have complain with the latest ATI driver, > > which I think uses DRI structure! May be it only with ATI binary driver! > > Indeed, it's our driver that disables the DRI if Composite is enabled, > not the DRI in general. I expect that to stay the same until the two are > properly integrated with each other (but it's not my decision to make). > Many thanks for your answer! I can understand that, but it also good to give others users to experiment with it. For example lg3d don't redirect opengl application to off-screen, we only redirect normal X application to off-screen at this moment! If some could point us to the code which disable DRI when composite is enable we could experiment with it and build for our users binaries for use with lg3d! Thanks again, -Amir --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: DRI and Composite
On Wed, 2005-01-19 at 23:49 +0100, Amir Bukhari wrote: > > > On Wednesday 19 January 2005 17:29, Amir Bukhari wrote: > > > Hallo, > > > Our users of Looking Glass 3D Desktop have a problem getting DRI to work > > > with LG3D. DRI is disabled when Composite Extension enabled. Is There > > any > > > way to enable DRI when composite enabled? > > > Nvidia driver has an Option in xorg.conf which let also GLX initialized > > > when Composite is enabled! And do people like the incorrect results of that? > > There is no code in Xorg HEAD to disable DRI when Composite is enabled. I > > would assume something in the lg3d code is turning DRI off. > > To be more exactly, our users have complain with the latest ATI driver, > which I think uses DRI structure! May be it only with ATI binary driver! Indeed, it's our driver that disables the DRI if Composite is enabled, not the DRI in general. I expect that to stay the same until the two are properly integrated with each other (but it's not my decision to make). > Is there different between the two drivers (ATI binary & DRI project)? Sure, there are many, the most obvious one being that the former is proprietary. If you have any issues with it, please use the existing feedback channel for it instead of bringing them up to the libre software community that can't do anything about it. Thanks. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: DRI and Composite
> -Original Message- > From: Adam Jackson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 19, 2005 11:30 PM > To: dri-devel@lists.sourceforge.net > Cc: Amir Bukhari > Subject: Re: DRI and Composite > > On Wednesday 19 January 2005 17:29, Amir Bukhari wrote: > > Hallo, > > Our users of Looking Glass 3D Desktop have a problem getting DRI to work > > with LG3D. DRI is disabled when Composite Extension enabled. Is There > any > > way to enable DRI when composite enabled? > > Nvidia driver has an Option in xorg.conf which let also GLX initialized > > when Composite is enabled! > > There is no code in Xorg HEAD to disable DRI when Composite is enabled. I > would assume something in the lg3d code is turning DRI off. > To be more exactly, our users have complain with the latest ATI driver, which I think uses DRI structure! May be it only with ATI binary driver! Is there different between the two drivers (ATI binary & DRI project)? --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DOOM3 with dri/r200 drivers: first impression
> Almost certainly. Last time I glossed over it, there definitely seemed to be > some registers missing which would need to be emitted. Though it might be > easier to just put everything in one single big block and emit that instead, > since it looks like everything fragment shader related has consecutive > register addresses? Yes all the first pass registers are missing from the r200 docs I have, lucky enough it doesn't take much effort to figure out they are the exact same registers as the second pass ones starting at 0x2f80 instead of 0x2f00, and I think I can work out anything else using the r300 stuff.. Yes they are all consecutive registers, they are the same ones used for the pixshader stage, I could probably just overload the pixshader stage with the new registers.. and emit it instead.. I'm thinking a bit about it but have a few other (read paying ...) things to hack on in the DRI.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and Composite
On Wednesday 19 January 2005 17:29, Amir Bukhari wrote: > Hallo, > Our users of Looking Glass 3D Desktop have a problem getting DRI to work > with LG3D. DRI is disabled when Composite Extension enabled. Is There any > way to enable DRI when composite enabled? > Nvidia driver has an Option in xorg.conf which let also GLX initialized > when Composite is enabled! There is no code in Xorg HEAD to disable DRI when Composite is enabled. I would assume something in the lg3d code is turning DRI off. - ajax pgpzuOEBo3yog.pgp Description: PGP signature
DRI and Composite
Hallo, Our users of Looking Glass 3D Desktop have a problem getting DRI to work with LG3D. DRI is disabled when Composite Extension enabled. Is There any way to enable DRI when composite enabled? Nvidia driver has an Option in xorg.conf which let also GLX initialized when Composite is enabled! Amir Bukhari E-Mail: [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exit(-1) vs abort in dri drivers..
Am Mittwoch, den 19.01.2005, 11:28 -0500 schrieb Adam Jackson: > On Wednesday 19 January 2005 03:56, Keith Whitwell wrote: > > Dave Airlie wrote: > > > Hi all, > > > On error a lot of DRI drivers do an exit and just leave, this > > > means you have to setup a break on exit to debug these cases which can be > > > a bit of a pain if you forget.. I wonder how to people feel about > > > changing these exits to aborts so the app gets a signal and then can be > > > backtraced... it might make debugging apps under gdb locally slightly > > > more dangerous but that is already a very dangerous process... > > > > I think it's been pretty much flip a coin to decide what to do with the > > sorts of fatal errors you're probably looking at. If there's an > > argument for one over the other I'm happy to see the usage standardized > > across the drivers. > > We already have quite a few assert()s, which calls abort() on failure, so I'd > be happy to see that standardised. assert() reads cleaner IMO, and can be > compiled out with -NDEBUG, so if I had a preference it'd be for switching all > the way to assert(). I can't speak for all drivers, but my impression is that assert is used for checking internal assumptions of the driver and should never be hit by most users. Exit is usually used when an ioctl returns failure. Are there any other failure cases that drivers need to handle? So the proposal would mean that you abort instead of exit(1) if an ioctl fails. This would have the advantage that you can get a backtrace from a core dump (unless you have a super clever application that catches the signal (cursing the SDL parachute ...)). In any case, you should _always_ check the return value of ioctls, so using assert is not a good idea. > > - ajax -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DOOM3 with dri/r200 drivers: first impression
Dave Airlie wrote: This is not a driver bug. Doom3 with r_renderer arb simply does look that awful. At least I've tried it with some other OS, and it looked exactly the same. AFAIK noone has the required documentation to implement the ati fragment shader extensions, which are required to enable other r_renderer modes. I don't have the docs but I do have the info now, I use r300 software to figure out the basics I'm just not sure how to hook it all into the r200 pipelining and state atom stuff.. I think I need a new state atom for it but I'm not sure... Almost certainly. Last time I glossed over it, there definitely seemed to be some registers missing which would need to be emitted. Though it might be easier to just put everything in one single big block and emit that instead, since it looks like everything fragment shader related has consecutive register addresses? Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exit(-1) vs abort in dri drivers..
On Wednesday 19 January 2005 10:27, Vladimir Dergachev wrote: > On Wed, 19 Jan 2005, Dave Airlie wrote: > > Hi all, > > On error a lot of DRI drivers do an exit and just leave, this > > means you have to setup a break on exit to debug these cases which can be > > a bit of a pain if you forget.. I wonder how to people feel about > > changing these exits to aborts so the app gets a signal and then can be > > backtraced... it might make debugging apps under gdb locally slightly > > more dangerous but that is already a very dangerous process... > > I've been wondering about this as well, as it appears that exit(-1) will > not give the chance to the application to save data. $ man atexit The app gets a chance to clean up either way, either through atexit handlers or SIGABRT handlers. It's just that the debugger traps on SIGABRT by default. - ajax pgpY9q52h9MJp.pgp Description: PGP signature
Re: new radeon tiling patch
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 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 the calculation is that big an issue... it'll never happen more than a couple thousand times per second anyway. ;) Well, both CRTC_OFFSET and CRTC_OFFSET_CNTL. The latter shouldn't matter if the writes are synchronized to the refresh anyway? Unless the update triggers at the same time the interrupt is generated without FLIP_CNTL... I'm not 100% sure this will work. If you update the offset_cntl in the ddx, the crtc might take the new value before drm had a chance to update the offset register (if the vblank would just happen when you write the offset_cntl, and thus the drm might need to wait for a full frame). It's not really the time which the calculation uses, but I just don't like additional ugly code. Well, you could always hide it in a function or something. ;) It's not THAT much code ;-). Well, the most important issue with that is that RADEON_WAIT_CRTC_PFLIP doesn't actually wait for a pageflip! It made absolutely no difference. Maybe with FLIP_CNTL set, it now considers it as a pageflip whenever it hits a new line, dunno. Sure. There's a way to wait for a certain scanline instead, if you want to explore that... Hmm, that might be interesting. But I'll leave it for now I think. I was able to get rid of the new setparam + sarea variable for pageflip + mergedfb/tiling. Instead of double wrapping, I just got rid of DRIAdjustFrame altogether (you can simply override the default wrap.AdjustFrame with 0). This will probably break the fullscreen stuff, so I'm wondering should I care about that or is this fullscreen stuff (deprecated for ages afaik) just never used anyway and could be removed? I could of course write something like RadeonDriAdjustFrame which would fix that up, but I'm not sure it's worth the hassle. Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exit(-1) vs abort in dri drivers..
On Wednesday 19 January 2005 03:56, Keith Whitwell wrote: > Dave Airlie wrote: > > Hi all, > > On error a lot of DRI drivers do an exit and just leave, this > > means you have to setup a break on exit to debug these cases which can be > > a bit of a pain if you forget.. I wonder how to people feel about > > changing these exits to aborts so the app gets a signal and then can be > > backtraced... it might make debugging apps under gdb locally slightly > > more dangerous but that is already a very dangerous process... > > I think it's been pretty much flip a coin to decide what to do with the > sorts of fatal errors you're probably looking at. If there's an > argument for one over the other I'm happy to see the usage standardized > across the drivers. We already have quite a few assert()s, which calls abort() on failure, so I'd be happy to see that standardised. assert() reads cleaner IMO, and can be compiled out with -NDEBUG, so if I had a preference it'd be for switching all the way to assert(). - ajax pgpWXZHnwtf71.pgp Description: PGP signature
Re: exit(-1) vs abort in dri drivers..
On Wed, 19 Jan 2005, Vladimir Dergachev wrote: On Wed, 19 Jan 2005, Dave Airlie wrote: Hi all, On error a lot of DRI drivers do an exit and just leave, this means you have to setup a break on exit to debug these cases which can be a bit of a pain if you forget.. I wonder how to people feel about changing these exits to aborts so the app gets a signal and then can be backtraced... it might make debugging apps under gdb locally slightly more dangerous but that is already a very dangerous process... I've been wondering about this as well, as it appears that exit(-1) will not give the chance to the application to save data. Whoops. sorry, I guess I have not woken up yet - the application can install an exit hook, of course. best Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exit(-1) vs abort in dri drivers..
On Wed, 19 Jan 2005, Dave Airlie wrote: Hi all, On error a lot of DRI drivers do an exit and just leave, this means you have to setup a break on exit to debug these cases which can be a bit of a pain if you forget.. I wonder how to people feel about changing these exits to aborts so the app gets a signal and then can be backtraced... it might make debugging apps under gdb locally slightly more dangerous but that is already a very dangerous process... I've been wondering about this as well, as it appears that exit(-1) will not give the chance to the application to save data. best Vladimir Dergachev Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: new radeon tiling patch
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-kernel? There is vblank interrupt related > >> stuff (radeon_driver_vblank_wait for instance), but that only is > >> called when a user has requested a wait for vblank, as far as I can > >> see (which is all the time with dri clients). > > > > > > You'd have to do it in radeon_driver_irq_handler() or a bottom half > > (but I don't know if these will meet the timing requirements either, > > in particular the latter...). > What about the 2nd head? I guess it would be necessary to update its > offset at a different time, is there something like a > RADEON_CRTC2_VBLANK_STAT bit? Yeah. BTW, how to do sync-to-vblank correctly for MergedFB is a whole other issue... > Also, this looks like it would get really ugly. Use an ioctl to tell drm > it needs to update the offsets, then it will update them in the irq > handler? That would mean we need something different for dispatch_flip > (since more flips can happen while waiting for vblanks, in that time the > old offsets have to be used), Or you could say that if the flips aren't synchronized to the refresh, it might not matter for panning either... > 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. :) > >> 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 the calculation is that big an > > issue... it'll never happen more than a couple thousand times per > > second anyway. ;) > Well, both CRTC_OFFSET and CRTC_OFFSET_CNTL. The latter shouldn't matter if the writes are synchronized to the refresh anyway? Unless the update triggers at the same time the interrupt is generated without FLIP_CNTL... > It's not really the time which the calculation uses, but I just don't > like additional ugly code. Well, you could always hide it in a function or something. ;) > Well, the most important issue with that is that RADEON_WAIT_CRTC_PFLIP > doesn't actually wait for a pageflip! It made absolutely no difference. > Maybe with FLIP_CNTL set, it now considers it as a pageflip whenever it > hits a new line, dunno. Sure. There's a way to wait for a certain scanline instead, if you want to explore that... -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New render-to-texture extension: GL_EXT_framebuffer_object
On Tue, Jan 18, 2005 at 01:23:24PM -0800, Ian Romanick wrote: > Pasi Kärkkäinen wrote: > > >http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt > > > >Has finally been posted.. hopefully it will be implemented in Mesa soon :) > > The superbuffers working group worked on that extension for just over 2 > years, and we're glad to be done! :) > Congratulations! This extensions looks very good. > Getting this implemented in software Mesa shouldn't be too painful, but > it isn't something that will happen over night. Of course, patches are > always welcomed. ;) > Yep. 107 revisions of the spec tells something about the work needed :) > Getting it implemented in the hardware accelerated drivers will likely > be a lot more painful. I honestly don't expect to see ANY non-beta > drivers supporting it for at least a couple months. > Hmm.. does this require any bigger / architechtural changes to DRI and/or X? memory management? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears is blank on savage
Am Dienstag, den 18.01.2005, 20:04 -0800 schrieb Mark Cass: > savage driver team, > > when i run glxgears a window appears but nothing is displayed. the > shell from which glxgears was run displays the usual frames per second > and no other information. i checked glxinfo and dri is enabled. also > found nothing unusual in the X log file. i have two options set > "APGMode" to "4" and "AGPSize" to "32". i tried without using these > options with the same result. the system is using the savage twister > with 32 MB and AGP 4X. it is detected and reported as such in the X > log file. the X server is running at 1280x1024 and using 16 bit color. I had such a problem once too with a Savage4 AGP. A reboot fixed it. I never found out what was wrong. :-/ > > what is strange is that this same code (no recompile, code was > compiled on a intel based machine) works on another system i have. > this other system is an AMD Athlon processor using a 32MB AGP 4X > savage 4 video card. glxgears runs properly (i see gears spinning). i > use the same settings for the x server and savage options as mentioned > above. i have had dri working correctly in the past on the twister but > it was way back in march of 2004. at that time it worked fine. Can you track down at which change it broke exactly (using cvs update -D)? Mailing list archives of dri-patches and mesa-cvs may be helpful. > > the code i am using is from an earlier version (before the kernel 2.6, > X org change over). i have to use the old driver that works for the > linux 2.4 kernel (no choice, blame it on management). i think the > version dates back to about May of 2004. I can't offer any support for this old stuff. Sorry. > > if you have any ideas please let me know. > > thanks in advance, > mark > > ps. > > some time ago i worked out the details for texture compression. i did > not go as far as to include the 'on the fly' compression stuff. i have > tested the loading of compressed textures and sub textures and both > perform as expected. if you would like to include this in your latest > stuff just let me know and i will post the source code files. all the > files are commented quite clearly concerning the changes made. Definitely. You can send it to me personally or to the dri-devel list, whatever you prefer. I might integrate it into the current driver one of the next weekends. Regards, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: new radeon tiling patch
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 when a user has requested a wait for vblank, as far as I can see (which is all the time with dri clients). You'd have to do it in radeon_driver_irq_handler() or a bottom half (but I don't know if these will meet the timing requirements either, in particular the latter...). What about the 2nd head? I guess it would be necessary to update its offset at a different time, is there something like a RADEON_CRTC2_VBLANK_STAT bit? Also, this looks like it would get really ugly. Use an ioctl to tell drm it needs to update the offsets, then it will update them in the irq handler? That would mean we need something different for dispatch_flip (since more flips can happen while waiting for vblanks, in that time the old offsets have to be used), 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. 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 the calculation is that big an issue... it'll never happen more than a couple thousand times per second anyway. ;) Well, both CRTC_OFFSET and CRTC_OFFSET_CNTL. It's not really the time which the calculation uses, but I just don't like additional ugly code. I also figured maybe RADEON_WAIT_CRTC_PFLIP would stop the cp so you could just put the offset_cntl and offset values in the ring buffer after that wait command, so I tried hacking in some out_ring commands in the DoAdjustFrame code, but that didn't work neither. Curious, what happened? I think AdjustFrame can be called asynchronously? I even tried to hack it into the drm in dispatch_flip (so new offsets now _only_ were written when pageflip was enabled and a 3d client was running...). Well, the most important issue with that is that RADEON_WAIT_CRTC_PFLIP doesn't actually wait for a pageflip! It made absolutely no difference. Maybe with FLIP_CNTL set, it now considers it as a pageflip whenever it hits a new line, dunno. Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exit(-1) vs abort in dri drivers..
Dave Airlie wrote: Hi all, On error a lot of DRI drivers do an exit and just leave, this means you have to setup a break on exit to debug these cases which can be a bit of a pain if you forget.. I wonder how to people feel about changing these exits to aborts so the app gets a signal and then can be backtraced... it might make debugging apps under gdb locally slightly more dangerous but that is already a very dangerous process... I think it's been pretty much flip a coin to decide what to do with the sorts of fatal errors you're probably looking at. If there's an argument for one over the other I'm happy to see the usage standardized across the drivers. Keith --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
