[Bug 2188] New: q-coord texgen causes an unnecessary fallback
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2188
Summary: q-coord texgen causes an unnecessary fallback
Product: Mesa
Version: CVS
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Drivers/DRI/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
in radeon_texstate.c
radeon_validate_texgen()
keithw made a note while implementing tcl.
...
else if (texUnit->TexGenEnabled & Q_BIT) {
/* Very easy to do this, in fact would remove a fallback case
* elsewhere, but I haven't done it yet... Fallback:
*/
fprintf(stderr, "fallback Q_BIT\n");
return GL_FALSE;
}
...
keith: any hints what needs to be done?
which add. fallback could get removed?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
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: drm CVS state...
Am So, den 02.01.2005 schrieb Sergio Monteiro Basto um 2:42: > On Fri, 2004-12-31 at 16:02 +0100, Felix Kühling wrote: > > > I was going to change mesa/src/mesa/drivers/dri/Makefile.template to use > > the share-core directory for DRM includes. This will be needed for the > > new Savage DRM as it lives in linux-core/shared-core only. With your > > assessment of the status of the 2.4 DRM it looks like it will never be > > backported to Linux 2.4. > > with this all applied, just left us > checkout drm and mesa cvs and apply > http://freedesktop.org/~fxkuehl/savage/savage_xorg_20041229.diff > on xorg tree to test it ? You don't need any of my previous patches. Just cvs update Xorg HEAD and recompile the Savage driver from there. Actually the patches are incompatible with the versions that I finally committed to CVS. So be sure you don't mix them or you will get unpredictable behavior. From now on I will keep the binary interfaces compatible though. > > I just check-out mesa and drm and compile with > make linux-dri-x86 > and > cp lib/savage_dri.so /usr/X11R6/lib/modules/dri/savage_dri.so > and recompile drm for my kernel 2.4.29-pre1, after reboot (to be sure > that savage kernel module is loaded again), all works normally. The new Savage driver lives in drm/shared-core and drm/linux-core. This means it can only be compiled for Linux 2.6.x kernels. I'm not planning a backport to 2.4. > > thanks, -- | 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: [R300] noisy_cube snapshot
glxgeas and lesson06 works ok - no more lockups here. This is big improvement :-) x11perf still locks (and x server crash sometimes) even without using 3D. Where can be problem ??? Peter Zubaj http://www.logofun.pobox.sk - urobte radost svojmu telefonu --- 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: [R300] noisy_cube snapshot
Peter Zubaj wrote: glxgeas and lesson06 works ok - no more lockups here. This is big improvement :-) x11perf still locks (and x server crash sometimes) even without using 3D. Where can be problem ??? When the xserver crashes, do you see "WaitForSomething(): select: errno=22" on the console? I get this error sometimes, and programs randomly die. There's a bug report on the freedesktop bugzilla, but no resolution yet. IIRC it has something to do with the new DRM. Ben Skeggs. Peter Zubaj http://www.logofun.pobox.sk - urobte radost svojmu telefonu --- 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
amd64 + r300.sf.net drivers
Hi! I already posted this on the dri-users list a while ago...sorry for that...but i noticed that dri-users was probably the wrong mailinglist. I am having problems using the r300 drivers. Somehow dri won't work. /dev/dri just stays empty. My Setup: AMD64 Athlon 3200+ Asus K8V Radeon 9800Pro debian pure64 vanilla kernel 2.6.9 I followed the instructions of the README. xorg CVS Mesa CVS patches have been applied finally i compiled the drm driver and insmodded it. Relevant sections of my xorg.cnf: Section "Module" # This loads the DBE extension module. Load"dbe" # Double buffer extension # This loads the miscellaneous extensions module, and disables # initialisation of the XFree86-DGA extension within that module. SubSection "extmod" Option"omit xfree86-dga" # don't initialise the DGA extension EndSubSection # This loads the font modules Load"type1" Load"speedo" Load"freetype" Load"xtt" # This loads the GLX module Load "glx" # This loads the DRI module Load "dri" EndSection Section "Device" Identifier "Radeon" Option "AGPMode" "4" Driver "radeon" Option "RenderAccel" "On" Option "AGPFastWrite" "On" Option "BusType" "AGP" #Option "NoRenderExtension" "Off" # Option "NoLogo" "On" Option "Accel" "On" Option "CIOverlay" "On" Option "OverlayDefaultVisual" "On" Option "TransparentIndex" "yes" Option "CursorShadow" "yes" Option "HWCrusor" "On" #VideoRam 65536 VideoRam131072 BusID "AGP:01:00:0" # Insert Clocks lines here if appropriate EndSection I collected most of these options while googling. Many of them don't work but a plain Device section doesn't help either. agpgart etc are enabled in the kernel: CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_DRM=y CONFIG_DRM_RADEON=m xorg-log: (II) Primary Device is: PCI 01:00:0 (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (--) Chipset ATI Radeon 9800PRO NH (AGP) found [...] (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x (II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (**) RADEON(0): Option "accel" "On" (**) RADEON(0): Option "BusType" "AGP" (**) RADEON(0): Option "AGPMode" "4" (**) RADEON(0): Option "AGPFastWrite" "On" (**) RADEON(0): Option "RenderAccel" "On" (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [...] (II) RADEON(0): initializing int10 (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (--) RADEON(0): Chipset: "ATI Radeon 9800PRO NH (AGP)" (ChipID = 0x4e48) (--) RADEON(0): Linear framebuffer at 0xe800 (--) RADEON(0): BIOS at 0xfd10 (II) RADEON(0): Video RAM override, using 131072 kB instead of 131072 kB (**) RADEON(0): VideoRAM: 131072 kByte (256 bit DDR SDRAM) (II) RADEON(0): AGP card detected (**) RADEON(0): Forced into AGP mode [..] (II) RADEON(0): I2C bus "DDC" initialized. (II) RADEON(0): Legacy BIOS detected (II) RADEON(0): Connector0: DDCType-2, DACType-1, TMDSType-0, ConnectorType-3 (II) RADEON(0): Connector1: DDCType-3, DACType-0, TMDSType--1, ConnectorType-2 (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Type: 0 (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): DDC Type: 3, Detected Type: 0 (II) RADEON(0): (II) RADEON(0): Primary: Monitor -- CRT Connector -- VGA DAC Type -- Primary TMDS Type -- NONE DDC Type -- VGA_DDC (II) RADEON(0): Secondary: Monitor -- NONE Connector -- DVI-I DAC Type -- TVDAC/ExtDAC TMDS Type -- Internal DDC Type -- DVI_DDC (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=2 max=4; xclk=33800 (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEON(0): Validating modes on Primary head - (II) RADEON(0): EIZO: Using hsync range of 27.00-65.00 kHz (II) RADEON(0): EIZO: Using vrefresh range of 55.00-90.00 Hz (II) RADEON(0): Clock range: 20.00 to 400.00 MHz [...] (==) RADEON(0): Write-combining range (0xe800,0x800) (WW) RADEON(0): Enabling DRM support *** Direct rendering support is highly experimental for Radeon 9
RE: amd64 + r300.sf.net drivers
Hi, You need drm kernel module too. It is in r300_driver/drm - you need drm and radeon kernel module. Look in readme in r300_driver/drm to info how to compile. Peter Zubaj RAMMSTEIN, 22.02.2005 o 20,00, Bratislava Incheba, Info: 0904 666 363, http://www.xl.sk --- 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
Fwd: Re: amd64 + r300.sf.net drivers
bah...thought that was a maillinglist post and simply pressed replysorry for breaking threading... -- Forwarded Message -- Subject: Re: amd64 + r300.sf.net drivers Date: Sunday 02 January 2005 14:22 From: Andreas Streichardt <[EMAIL PROTECTED]> To: Peter Zubaj <[EMAIL PROTECTED]> On Sunday 02 January 2005 14:20, Peter Zubaj wrote: > Hi, Hi! > You need drm kernel module too. > It is in r300_driver/drm - you need drm and radeon kernel module. Look > in readme in r300_driver/drm to info how to compile. > > Peter Zubaj yes...i know...i am using that... insmod drm.o debug=1 insmod radeon.o that's what i have done before starting X (in the linux-core dir). But somehow this message still appears... Regards, Andreas Streichardt --- --- 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: amd64 + r300.sf.net drivers
On Sunday 02 January 2005 14:25, Peter Zubaj wrote: > And have you > /dev/dri/card0 device file ??? > > I use udev and this device file is created automatically. > > Peter Zubaj that's the problem. /dev/dri is empty. and i have no idea why. Regards, Andreas Streichardt --- 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: amd64 + r300.sf.net drivers
On Sunday 02 January 2005 14:28, Andreas Streichardt wrote: > On Sunday 02 January 2005 14:25, Peter Zubaj wrote: > > And have you > > /dev/dri/card0 device file ??? > > > > I use udev and this device file is created automatically. > > > > Peter Zubaj > > that's the problem. /dev/dri is empty. and i have no idea why. > > Regards, > > Andreas Streichardt ok...thanks for the hint with udev. the problem was that CONFIG_HOTPLUG wasn't set and so udev didn't work. I am getting a black screen now but that's a start ;). Regards, Andreas Streichardt --- 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: amd64 + r300.sf.net drivers
On Sunday 02 January 2005 14:58, Andreas Streichardt wrote: Hi, > ok...thanks for the hint with udev. the problem was that CONFIG_HOTPLUG > wasn't set and so udev didn't work. > I am getting a black screen now but that's a start ;). I experimented a bit but i won't work. as soon as i enable dri and startx it crashes: The screen gets black and i can't do anything. If i try it on 640x480 i can see parts of what i see after powerup (bios stuff. Ram, AMI Logo etc). Any idea? Regards, Andreas Streichardt --- 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: Dramatic improvement of depth buffer quality
Felix Kühling wrote: Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00: Felix Kühling wrote: [snip] I'm a bit sceptical that this really improves depth buffer quality in general. With D3D it is (if the hw supports it) possible to use a w buffer instead of a z buffer, which has the same precision for far and near objects. However, the loss of precision for near objects was often considered unacceptable. (Radeon R100 and R200 support this, but R300 and up no longer do, or at least the driver doesn't expose it, so it looks like it wasn't that useful after all, and not many applications afaik requested w buffers). [... following up to my other reply ...] Another problem with W buffers is that linear depth interpolation doesn't give the correct results with intersecting surfaces. This is only achieved by the perspective division which is not applied to W (in fact the perspective division divides x, y and z by W). This makes W-buffers unsuitable for OpenGL. But this is not what I am proposing, just in case I was misunderstood. Reversing the depth range and using floating point numbers just changes the encoding of depth values in the depth buffer, it does not change the semantics, like a W-buffer would do. Understood. I was just using w buffers as an example because they cause a similar (or less, actually?) loss of accuracy at near range as your scheme, compared to a "normal" z buffer. And this was considered problematic. That's at least what I got from some discussions... Though it's probably correct that it really depends on the application if it is an improvement or not. 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: [R300] Glossary
On Sat, 1 Jan 2005, Vladimir Dergachev wrote: > The command processor is a part of the graphics chip. You might think of > it as a sophisticated DMA engine. > > However, it is, indeed, accessed via MMIO interface. Thanks for the info. > Take a look at http://gatos.sourceforge.net/dri-debug.php . Thanks again! > As for wiki feel free to put links there.. I thought it was restricted access... developer only? Best regards Peter K -- We Can Put an End to Word Attachments: http://www.fsf.org/philosophy/no-word-attachments.html --- 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: [R300] noisy_cube snapshot
On Sun, 2 Jan 2005, Peter Zubaj wrote: glxgeas and lesson06 works ok - no more lockups here. This is big improvement :-) x11perf still locks (and x server crash sometimes) even without using 3D. Where can be problem ??? Try changing drm/linux-core/radeon_cp.c::radeon_do_cp_idle to have this sequence reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); reg_start(0x4f18,0); e32(0x0003); instead of whatever it has for R300. It could be that half the code there is redundant, or worse - triggers bits it should not touch. thank you ! Vladimir Dergachev Peter Zubaj http://www.logofun.pobox.sk - urobte radost svojmu telefonu --- 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: [R300] noisy_cube snapshot
On Sun, 2 Jan 2005, Ben Skeggs wrote: Peter Zubaj wrote: glxgeas and lesson06 works ok - no more lockups here. This is big improvement :-) x11perf still locks (and x server crash sometimes) even without using 3D. Where can be problem ??? When the xserver crashes, do you see "WaitForSomething(): select: errno=22" on the console? I get this error sometimes, and programs randomly die. There's a bug report on the freedesktop bugzilla, but no resolution yet. IIRC it has something to do with the new DRM. I don't think I do - once X is locked up it just spins there. On the other hand maybe I'll see them if I start X by sshing from another computer. Also, I seem to have lost the ability to trigger lockups with x11perf. Strange, as it used to be I can do it repeatedly after a clean boot.. Could you try to do this: In X.org 2d driver, find file radeon_dri.c, function RADEONEnterServer and try disabling the R300 piece with the long comment. I am curious to know whether a) You still see lockups with this disabled b) I would expect the 3d driver use to cause lockups without it - but it might not, if not it would be a very useful piece to the puzzle. thank you Vladimir Dergachev Ben Skeggs. Peter Zubaj http://www.logofun.pobox.sk - urobte radost svojmu telefonu --- 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: amd64 + r300.sf.net drivers
On Sun, 2 Jan 2005, Andreas Streichardt wrote: On Sunday 02 January 2005 14:58, Andreas Streichardt wrote: Hi, ok...thanks for the hint with udev. the problem was that CONFIG_HOTPLUG wasn't set and so udev didn't work. I am getting a black screen now but that's a start ;). I experimented a bit but i won't work. as soon as i enable dri and startx it crashes: The screen gets black and i can't do anything. If i try it on 640x480 i can see parts of what i see after powerup (bios stuff. Ram, AMI Logo etc). Any idea? Hi Andreas, are you running 64 bit or 32 bit ? If the latter, then try the following: 1. Check the AGP settings in BIOS.. Maybe you need to enable or disable something 2. Check the agpgart module - is it being loaded before DRM module ? is it the right agpgart for your chipset ? Have there been any updates for it ? (Check 2.6.10 changelog) best Vladimir Dergachev Regards, Andreas Streichardt --- 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
[Bug 969] DRM Kernel Modules Fail to compile
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=969 --- Additional Comments From [EMAIL PROTECTED] 2005-01-02 12:19 --- http://bugs.gentoo.org/show_bug.cgi?id=61975 is the bug, caused by Gentoo's Java maintainers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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
problems compiling xorg cvs Re: drm CVS state...
savage_xmesa.c: In function `savageInitDriver': savage_xmesa.c:111: error: structure has no member named `frontPitch' savage_xmesa.c:113: error: structure has no member named `frontBitmapDesc' savage_xmesa.c:121: error: structure has no member named `backBitmapDesc' savage_xmesa.c:123: error: structure has no member named `depthBitmapDesc' savage_xmesa.c:136: error: structure has no member named `agpTextures' savage_xmesa.c:138: error: structure has no member named `agpTextures' savage_xmesa.c:142: error: structure has no member named `backbuffer' savage_xmesa.c:147: error: structure has no member named `depthbuffer' savage_xmesa.c: In function `savageCreateContext': savage_xmesa.c:313: error: structure has no member named `registers' savage_xmesa.c:314: error: structure has no member named `registers' savage_xmesa.c:315: error: structure has no member named `registers' savage_xmesa.c:323: error: structure has no member named `agpTextures' savage_xmesa.c:324: error: structure has no member named `agpTextures' savage_xmesa.c:325: error: structure has no member named `agpTextures' savage_xmesa.c:334: error: structure has no member named `agpTextures' savage_xmesa.c:338: error: structure has no member named `BCIcmdBuf' savage_xmesa.c:339: error: structure has no member named `registers' savage_xmesa.c:341: error: structure has no member named `registers' savage_xmesa.c:342: error: structure has no member named `BCIcmdBuf' savage_xmesa.c:344: error: structure has no member named `aperture' savage_xmesa.c:345: error: structure has no member named `aperture' make[6]: *** [savage_xmesa.o] Error 1 make[6]: Leaving directory `/usr/src/opt/xorgcvs2/build/lib/GL/mesa/drivers/dri/savage' make[5]: *** [all] Error 2 make[5]: Leaving directory `/usr/src/opt/xorgcvs2/build/lib/GL/mesa/drivers/dri' make[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/src/opt/xorgcvs2/build/lib/GL' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/opt/xorgcvs2/build/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/opt/xorgcvs2/build' make[1]: *** [World] Error 2 make[1]: Leaving directory `/usr/src/opt/xorgcvs2/build' make: *** [World] Error 2 any help ? On Sun, 2005-01-02 at 12:16 +0100, Felix Kühling wrote: > Am So, den 02.01.2005 schrieb Sergio Monteiro Basto um 2:42: > > On Fri, 2004-12-31 at 16:02 +0100, Felix Kühling wrote: > > > > > I was going to change mesa/src/mesa/drivers/dri/Makefile.template to use > > > the share-core directory for DRM includes. This will be needed for the > > > new Savage DRM as it lives in linux-core/shared-core only. With your > > > assessment of the status of the 2.4 DRM it looks like it will never be > > > backported to Linux 2.4. > > > > with this all applied, just left us > > checkout drm and mesa cvs and apply > > http://freedesktop.org/~fxkuehl/savage/savage_xorg_20041229.diff > > on xorg tree to test it ? > > You don't need any of my previous patches. Just cvs update Xorg HEAD and > recompile the Savage driver from there. Actually the patches are > incompatible with the versions that I finally committed to CVS. So be > sure you don't mix them or you will get unpredictable behavior. From now > on I will keep the binary interfaces compatible though. > > > > > I just check-out mesa and drm and compile with > > make linux-dri-x86 > > and > > cp lib/savage_dri.so /usr/X11R6/lib/modules/dri/savage_dri.so > > and recompile drm for my kernel 2.4.29-pre1, after reboot (to be sure > > that savage kernel module is loaded again), all works normally. > > The new Savage driver lives in drm/shared-core and drm/linux-core. This > means it can only be compiled for Linux 2.6.x kernels. I'm not planning > a backport to 2.4. > > > > > thanks, > -- Sérgio M.B. --- 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: libdrm issues blocking accelerated indirect GL
Jon Smirl 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 multicore-friendly > > is cheap and easy; if libglx is redone such that both in-process and > > out-of-process indirect GL are possible, then the rendering is probably > > pretty close to being properly encapsulated. > > > > Not disagreeing with you, just saying that discussion is quite a bit down > > the > > line ;). > > Why is this so different that what a local process does right now? For > the remote GLX user split off a new process, it uses DRI to do all of > it's drawing and then calls back into the server for GLX. A more > efficient scheme would be for the server to directly run GLX calls > when received from the remote user and then ship all of the GL call > off to the second process. The idea of forking a complete new process worries me a lot... why is it neccesary to use a new process here and no new thread ? A thread could communicate much easier with the main Xserver thread than a fully-blown new process and would even share the same memory mappings... > Has anyone ever considered a model where the X server process forks > off another process for each remote user, and the that process listens > on the remote net connection and makes X/GL/GLX calls just like a > local process, forwarding GLX/X requests to the server process as > needed? This may be the best model for the X on GL world. 1. Doesn't this mean we will have multiple process switches just to process the traffic ? 2. How will such a model handle applications which render in the same window but run under different UIDs ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) --- 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: problems compiling xorg cvs Re: drm CVS state...
Am So, den 02.01.2005 schrieb Sergio Monteiro Basto um 23:18: > savage_xmesa.c: In function `savageInitDriver': > savage_xmesa.c:111: error: structure has no member named `frontPitch' > savage_xmesa.c:113: error: structure has no member named > `frontBitmapDesc' > savage_xmesa.c:121: error: structure has no member named > `backBitmapDesc' > savage_xmesa.c:123: error: structure has no member named > `depthBitmapDesc' > savage_xmesa.c:136: error: structure has no member named `agpTextures' > savage_xmesa.c:138: error: structure has no member named `agpTextures' > savage_xmesa.c:142: error: structure has no member named `backbuffer' > savage_xmesa.c:147: error: structure has no member named `depthbuffer' > savage_xmesa.c: In function `savageCreateContext': > savage_xmesa.c:313: error: structure has no member named `registers' > savage_xmesa.c:314: error: structure has no member named `registers' > savage_xmesa.c:315: error: structure has no member named `registers' > savage_xmesa.c:323: error: structure has no member named `agpTextures' > savage_xmesa.c:324: error: structure has no member named `agpTextures' > savage_xmesa.c:325: error: structure has no member named `agpTextures' > savage_xmesa.c:334: error: structure has no member named `agpTextures' > savage_xmesa.c:338: error: structure has no member named `BCIcmdBuf' > savage_xmesa.c:339: error: structure has no member named `registers' > savage_xmesa.c:341: error: structure has no member named `registers' > savage_xmesa.c:342: error: structure has no member named `BCIcmdBuf' > savage_xmesa.c:344: error: structure has no member named `aperture' > savage_xmesa.c:345: error: structure has no member named `aperture' > make[6]: *** [savage_xmesa.o] Error 1 > make[6]: Leaving directory > `/usr/src/opt/xorgcvs2/build/lib/GL/mesa/drivers/dri/savage' > make[5]: *** [all] Error 2 > make[5]: Leaving directory > `/usr/src/opt/xorgcvs2/build/lib/GL/mesa/drivers/dri' > make[4]: *** [all] Error 2 > make[4]: Leaving directory `/usr/src/opt/xorgcvs2/build/lib/GL' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/usr/src/opt/xorgcvs2/build/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/src/opt/xorgcvs2/build' > make[1]: *** [World] Error 2 > make[1]: Leaving directory `/usr/src/opt/xorgcvs2/build' > make: *** [World] Error 2 > > > > any help ? Looks like this was caused by my update of the Savage DDX driver in the X.org tree without also upating the Mesa driver in the X.org tree. At the moment the Mesa driver in X.org's extras/Mesa can't be compiled with the current Savage DDX. It is my understanding that this will be cleaned up when X.org imports Mesa sources the next time, which will happen at least once before the next major release. Since the Savage driver is being worked on you don't want to work with constantly outdated sources in extras/Mesa anyway. The recommended way to proceed is to disable the build of the Savage DRI driver in the X.org tree (it should be disabled by default, since Savage is a DevelDRIDriver) and build the Savage DRI driver directly from Mesa CVS. The instructions at http://dri.freedesktop.org/wiki/Building should work for you. [snip] 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
[Bug 2195] New: switch radeon driver to t_vertex interface
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2195 Summary: switch radeon driver to t_vertex interface Product: Mesa Version: CVS Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] as most (all?) other drivers are already converted -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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
[Bug 2195] switch radeon driver to t_vertex interface
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2195 --- Additional Comments From [EMAIL PROTECTED] 2005-01-02 15:41 --- Created an attachment (id=1614) --> (https://bugs.freedesktop.org/attachment.cgi?id=1614&action=view) this works for me please test. feel free to commit after removing the remainig questions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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: drm CVS state...
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, Are some changes underway that might make 2.4 hard to maintain ? If someone sends patches for the 2.4 branch, would they be accepted ? Stephane --- 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: drm CVS state...
On Mon, 03 Jan 2005 01:10:37 +0100, Stephane Marchesin <[EMAIL PROTECTED]> wrote: > 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, > > > Are some changes underway that might make 2.4 hard to maintain ? We are adding things like sysfs support that don't exist under 2.4. Also, the internal kernel API is starting to diverge from the 2.4 one due to changes in the VM system. Look at drm_compat.h to get an idea of how things are changing. Another area of change is module initialization parameters. > If someone sends patches for the 2.4 branch, would they be accepted ? I don't see why not. But they won't appear in 2.4 kernel releases because the 2.4 kernel maintainer is no longer accepting anything but bug patches. We have had 2.6 for three years now and it is many times better than 2.4. 2.4 should just become a stable, unchanging platform. The support that is there should continue work. No other device support for new hardware (for example many new USB devices) is being back ported to 2.4 either. If you want support for current hardware you need to be on 2.6. > > Stephane > > -- Jon Smirl [EMAIL PROTECTED] --- 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: [R300] noisy_cube snapshot
Also, I seem to have lost the ability to trigger lockups with x11perf. Strange, as it used to be I can do it repeatedly after a clean boot.. I cannot cause the x11perf lockups anymore either. Could you try to do this: In X.org 2d driver, find file radeon_dri.c, function RADEONEnterServer and try disabling the R300 piece with the long comment. I am curious to know whether a) You still see lockups with this disabled When the code is commented out glxgears locks up after a second or two for me. Ben Skeggs --- 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: problems compiling xorg cvs Re: drm CVS state...
On Mon, 2005-01-03 at 00:18 +0100, Felix Kühling wrote: > Looks like this was caused by my update of the Savage DDX driver in the > X.org tree without also upating the Mesa driver in the X.org tree. At > the moment the Mesa driver in X.org's extras/Mesa can't be compiled with > the current Savage DDX. It is my understanding that this will be cleaned > up when X.org imports Mesa sources the next time, which will happen at > least once before the next major release. Since the Savage driver is > being worked on you don't want to work with constantly outdated sources > in extras/Mesa anyway. > > The recommended way to proceed is to disable the build of the Savage DRI > driver in the X.org tree (it should be disabled by default, since Savage > is a DevelDRIDriver) and build the Savage DRI driver directly from Mesa > CVS. The instructions at http://dri.freedesktop.org/wiki/Building should > work for you. > now glxinfo | grep dire direct rendering: No OpenGL renderer string: Mesa GLX Indirect > [snip] > > Regards, > Felix > -- Sérgio M.B. --- 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
[R300] red_tinted_cube snapshot
Hi all, New tag in R300 CVS: red_tinted_cube Changes: * ported over R200 texture allocation (and management, partly) code * hooked it up so lesson06 from nehe.gamedev.net displayes red textured (instead of blue) rotating cube. Issues: * What is red should be blue * A few fields don't quite match up, in particular format field - needs research and ideas.. Enjoy ! 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: libdrm issues blocking accelerated indirect GL
--- Roland Mainz <[EMAIL PROTECTED]> wrote: > Jon Smirl 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 > multicore-friendly > > > is cheap and easy; if libglx is redone such that both in-process and > > > out-of-process indirect GL are possible, then the rendering is > probably > > > pretty close to being properly encapsulated. > > > > > > Not disagreeing with you, just saying that discussion is quite a bit > down the > > > line ;). > > > > Why is this so different that what a local process does right now? For > > the remote GLX user split off a new process, it uses DRI to do all of > > it's drawing and then calls back into the server for GLX. A more > > efficient scheme would be for the server to directly run GLX calls > > when received from the remote user and then ship all of the GL call > > off to the second process. > > The idea of forking a complete new process worries me a lot... why is it What's the problem, if it's only done at client connect(read as once in a while)? > neccesary to use a new process here and no new thread ? A thread could > communicate much easier with the main Xserver thread than a fully-blown > new process and would even share the same memory mappings... What about root privs? I'm talking in terms of exploit prevention. > > > Has anyone ever considered a model where the X server process forks Many times, in history it has been an exepted idea. Would you like to actualy code this? > > off another process for each remote user, and the that process listens > > on the remote net connection and makes X/GL/GLX calls just like a > > local process, forwarding GLX/X requests to the server process as > > needed? This may be the best model for the X on GL world. > > 1. Doesn't this mean we will have multiple process switches just to > process the traffic ? No, you close the handel in the parent process and release/logout on SIGCHILD. Connection 'back' the the X server could be done prefork so there is 'NO' chance of the process not being able to connect. > 2. How will such a model handle applications which render in the same > window but run under different UIDs ? > Why would [EMAIL PROTECTED] have a UID on host foo? For a local connection this whole thread dose not apply. > > > Bye, > Roland > > -- > __ . . __ > (o.\ \/ /.o) [EMAIL PROTECTED] > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 7950090 > (;O/ \/ \O;) > > > --- > 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 > __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com --- 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
