Ian Romanick wrote:
Forge wrote:
I think a detail is being overlooked here.
R200 does not have 3 TMUs per pipe. R200 is 4 pipes, 2 TMUs each. Only
R100 (Radeon) and RV200 (Radeon 7500) and their derivatives use the
2*3 pipes/TMUs layout.
Does anyone have any evidence to the contrary?
No. It
Forge wrote:
I think a detail is being overlooked here.
R200 does not have 3 TMUs per pipe. R200 is 4 pipes, 2 TMUs each. Only
R100 (Radeon) and RV200 (Radeon 7500) and their derivatives use the 2*3
pipes/TMUs layout.
Does anyone have any evidence to the contrary?
No. It has 2 TMUs per pipe an
Jos? Fonseca <[EMAIL PROTECTED]> wrote:
> If not then the solution would imply moving the CVS repository to a new
> machine, but where would that be? XFree86.org? Some SF look-a-like?
As far as I know BerliOS is hosting quite a few OpenSource projects. This is
intended to be some SF alternative.
On Mon, 2003-06-23 at 16:30, Andreas Stenglein wrote:
> Am 2003.06.23 19:12:01 +0200 schrieb(en) Keith Whitwell:
> On my 64MB Radeon7500 the max texture size is 2048 with 2TMU and
> 1024 with 3TMUs. It shouldnt be a problem for 32MB versions as long es
> the max texture size is as big as opengl re
I think a detail is being overlooked here.
R200 does not have 3 TMUs per pipe. R200 is 4 pipes, 2 TMUs each. Only
R100 (Radeon) and RV200 (Radeon 7500) and their derivatives use the 2*3
pipes/TMUs layout.
Does anyone have any evidence to the contrary?
- Rich 'Forge' Mingin
-
Keith Whitwell wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository: xc/xc/lib/GL/mesa/src/drv/i830/
Changes by: [EMAIL PROTECTED] 03/06/13 03:49:05
Log message:
Restore texture age waiting when swapping in new textures.
Modified files:
xc/xc/lib/GL/mesa/src/drv/i
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IR
I have a t20 I can test on as well. I also plan to re-attempt dualhead
support using the new code as a base.
Alex
--- Alan Hourihane <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 23, 2003 at 10:21:30AM -0700, Ian Romanick wrote:
> > Alan Hourihane wrote:
> > >On Mon, Jun 23, 2003 at 01:50:02PM +0100,
Andreas Stenglein wrote:
Am 2003.06.23 19:12:01 +0200 schrieb(en) Keith Whitwell:
Ian Romanick wrote:
As another data point, I have attached my very old patch to enable the
3rd TMU on Radeon. IIRC, it worked w/HW TCL, vtxfmt, & codegen. It is
now quite outdated. There were a couple of reason
Am 2003.06.23 19:12:01 +0200 schrieb(en) Keith Whitwell:
> Ian Romanick wrote:
> > Andreas Stenglein wrote:
> >
> >> I tried to get the 3rd TMU working on radeon,
> >> and with this patch it works at least
> >> without hw-TCL for multiarb.c from Mesa/demos.
> >> (RADEON_TCL_FORCE_DISABLE=1)
> >>
>
Am Montag, 23. Juni 2003 20:24 schrieb José Fonseca:
> On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote:
> > These sourceforge "backup" server move is very annoying.
> > It's hindering open source so much.
> >
> > Do we have other options?
>
> I've never tried but isn't possible for no
On Mon, Jun 23, 2003 at 10:21:30AM -0700, Ian Romanick wrote:
> Alan Hourihane wrote:
> >On Mon, Jun 23, 2003 at 01:50:02PM +0100, Alan Cox wrote:
> >
> >>http://www.linux.org.uk/~alan/S3.zip
> >>http://www.linux.org.uk/~alan/CLE266.zip
> >>
> >>The CLE266 has some fairly complicated Linux kernel e
On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote:
> These sourceforge "backup" server move is very annoying.
> It's hindering open source so much.
>
> Do we have other options?
I've never tried but isn't possible for non-developers also access the
SF CVS repository via SSH (read-only
On Mon, Jun 23, 2003 at 10:21:30AM -0700, Ian Romanick wrote:
> Alan Hourihane wrote:
> >On Mon, Jun 23, 2003 at 01:50:02PM +0100, Alan Cox wrote:
> >
> >>http://www.linux.org.uk/~alan/S3.zip
> >>http://www.linux.org.uk/~alan/CLE266.zip
> >>
> >>The CLE266 has some fairly complicated Linux kernel e
I don't know about the 3D stuff, but the 2D driver seems cleaner and
easier to follow than the current one (which this new one seems to be
based on) at first glance anyway...
Alex
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Alan Hourihane wrote:
> > On Mon, Jun 23, 2003 at 01:50:02PM +0100, Ala
[This e-mail has been automatically generated.]
Please do not reply to this email. if you want to comment on the bug, go to the
URL shown below and enter your comments there.
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=120
[EMAIL PROTECTED] changed:
What
Jacek Popławski wrote:
On Mon, Jun 23, 2003 at 07:59:56AM -0700, Ian Romanick wrote:
There are a couple levels of indirection that you're not seeing here.
There is a set of "stub" functions for each GL call that redirect to
either direct rendering functions (supplied by the DRI driver) or the
i
Alan Hourihane wrote:
On Mon, Jun 23, 2003 at 01:50:02PM +0100, Alan Cox wrote:
http://www.linux.org.uk/~alan/S3.zip
http://www.linux.org.uk/~alan/CLE266.zip
The CLE266 has some fairly complicated Linux kernel entanglements to
resolve for the hardware mpeg engine stuff.
O.k. I'm gonna start a bran
Ian Romanick wrote:
Andreas Stenglein wrote:
I tried to get the 3rd TMU working on radeon,
and with this patch it works at least
without hw-TCL for multiarb.c from Mesa/demos.
(RADEON_TCL_FORCE_DISABLE=1)
With hw-TCL the 3rd texture is visible, but
isnt rotating.
The patch also includes some code
Andreas Stenglein wrote:
I tried to get the 3rd TMU working on radeon,
and with this patch it works at least
without hw-TCL for multiarb.c from Mesa/demos.
(RADEON_TCL_FORCE_DISABLE=1)
With hw-TCL the 3rd texture is visible, but
isnt rotating.
The patch also includes some code for the
kernelmodule
These sourceforge "backup" server move is very annoying.
It's hindering open source so much.
Do we have other options?
Regards,
Dieter
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INet
Andreas Stenglein wrote:
thanks a lot!
btw, I got the 3rd TMU working with hw-tcl and codegen, too.
(at least multiarb.c works)
I'm going to clean the patch up a bit, so that it only contains
things related to 3rd TMU support.
Am 2003.06.23 12:17:26 +0200 schrieb(en) Michel Dänzer:
On Sat, 2003-0
Gareth Hughes wrote:
Brian Paul wrote:
The GLX 1.4 spec seems to be missing from www.opengl.org but the only
thing added since GLX 1.3 is glXGetProcAddress().
Was there actually an official 1.4 spec? Most recent version I've ever
seen is 1.3.
I don't think that there was. IIRC, GLX version c
thanks a lot!
btw, I got the 3rd TMU working with hw-tcl and codegen, too.
(at least multiarb.c works)
I'm going to clean the patch up a bit, so that it only contains
things related to 3rd TMU support.
Am 2003.06.23 12:17:26 +0200 schrieb(en) Michel Dänzer:
> On Sat, 2003-06-21 at 14:14, Andreas
Felix Kühling wrote:
The infrastructure is more or less complete. The only thing missing in
the branch is the user-space programme xdriinfo as I havn't found a good
place in the tree to commit it :-/. While the Mese tree reorganization
is still going on that will probably not change. However, the c
Jon Smirl wrote:
I just checked out the DRI CVS head and Pbuffers don't
appear to be implemented. What is the status of
PBuffer support for ATI Radeons?
The status is that it isn't supported by any of the open-source drivers.
We don't have all of the required infrastructure, but it is being
work
Thanks,
Dieter
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hostin
Jacek Popławski wrote:
I am trying to understand DRI source, now from start, i.e. from OpenGL calls.
I was analizing file: lib/GL/glx/g_render.c, if I understand correctly there is
stream build there, but where it's readed?
For example in glColor3f there is identifier: X_GLrop_Color3fv. I grep who
On Llu, 2003-06-23 at 15:20, José Fonseca wrote:
> Another thing I noticed is that the Savage DRM is just a stub doesn't
> touch the hardware - the DMA is fired directly by the userspace 3D
> driver. I may be wrong but this can compromise the system security.
This is stuff that needs to be looked
Jacek Popławski wrote:
I was testing following code on DRI r200:
http://www.gametutorials.com/download/Ports/OpenGL/RenderToTexture_SDL.zip
It renders one cube to 2D Texture, then renders one quad with that texture.
I wrote simple fps counter, and noticed, that results on Radeon 9100 with DRI
ar
Plus XvMC!
--- José Fonseca <[EMAIL PROTECTED]> wrote:
> > Savage: Savage MX/IX/ SuperSavage/ ProSavage/ Twister/K
>
> It seams that at the moment DRI is only enabled for the Twister and
> ProSavage:
>
> if ((psav->Chipset == S3_TWISTER)
> || (psav->Chipset == S3_PROSAVAGE)) {
>
On Mon, Jun 23, 2003 at 01:11:12PM +0100, Alan Cox wrote:
> On Llu, 2003-06-23 at 13:01, José Fonseca wrote:
> > I see. Well it really doesn't trouble me to rewrite the gamma driver
> > since I'll be changing all other drivers. Also the work I'm doing will
> > move a big chunk of each driver into c
On Llu, 2003-06-23 at 14:43, Alex Deucher wrote:
> Alan,
>
> I don't suppose they released any code or docs for duoview support
> for the old savage chips? I tried to add support for that a while
> back, but never was able to get it to work.
I don't.
Alan,
I don't suppose they released any code or docs for duoview support
for the old savage chips? I tried to add support for that a while
back, but never was able to get it to work.
Alex
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> On Llu, 2003-06-23 at 13:33, Alan Hourihane wrote:
> > > No sec
On Mon, Jun 23, 2003 at 01:50:02PM +0100, Alan Cox wrote:
> On Llu, 2003-06-23 at 13:33, Alan Hourihane wrote:
> > > No secrets/non disclosures. The VIA/S3G guys just want to get them into
> > > XFree86 proper and the code appears to already have all the right X
> > > Licenses attached.
> >
> > Gr
On Mon, Jun 23, 2003 at 01:50:02PM +0100, Alan Cox wrote:
> On Llu, 2003-06-23 at 13:33, Alan Hourihane wrote:
> > > No secrets/non disclosures. The VIA/S3G guys just want to get them into
> > > XFree86 proper and the code appears to already have all the right X
> > > Licenses attached.
> >
> > Gr
On Llu, 2003-06-23 at 13:33, Alan Hourihane wrote:
> > No secrets/non disclosures. The VIA/S3G guys just want to get them into
> > XFree86 proper and the code appears to already have all the right X
> > Licenses attached.
>
> Great. I can test the Savage MX/IX support with my IBM T20 laptop :)
>
В сообщении от 23 Июнь 2003 18:11 Alan Cox написал:
> > > BTW in the good news department, I received vendor contributed VIA and
> > > S3 DRI/DRM drivers yesterday. The kernel side needs some work yet but
> > > nothing major (except when it hits FreeBSD I guess).
> >
> > That's awesome news! Exactl
On Mon, Jun 23, 2003 at 01:11:12PM +0100, Alan Cox wrote:
> On Llu, 2003-06-23 at 13:01, José Fonseca wrote:
> > I see. Well it really doesn't trouble me to rewrite the gamma driver
> > since I'll be changing all other drivers. Also the work I'm doing will
> > move a big chunk of each driver into c
On Llu, 2003-06-23 at 13:03, Alan Hourihane wrote:
> The Delta was never supported for 3D. What make of board is it Alan, that
> your Delta is broken for 2D ? And can you send me the XFree86 log file.
Email me an address off list and I'll send you the delta card. Its just
gathering dust in a cupbo
On Llu, 2003-06-23 at 13:01, José Fonseca wrote:
> I see. Well it really doesn't trouble me to rewrite the gamma driver
> since I'll be changing all other drivers. Also the work I'm doing will
> move a big chunk of each driver into common code (all the buffer
> management), so there will be little
On Mon, Jun 23, 2003 at 10:41:00AM +0100, Keith Whitwell wrote:
> José Fonseca wrote:
> >On Mon, Jun 23, 2003 at 08:20:31AM +0100, Keith Whitwell wrote:
> >
> >>José Fonseca wrote:
> >>
> >>>The Gamma DRM driver is quite peculiar in several aspects. I'd like to
> >>>know if those differences are re
On Mon, Jun 23, 2003 at 12:41:45PM +0100, Alan Cox wrote:
> On Llu, 2003-06-23 at 10:41, Keith Whitwell wrote:
> > > BTW, do we have a owner of such card among the subscribers which can do
> > > some testing when the time comes?
> >
> > I think Alan Cox. Alan Hourihane had one, but I think it die
On Mon, Jun 23, 2003 at 12:41:45PM +0100, Alan Cox wrote:
> On Llu, 2003-06-23 at 10:41, Keith Whitwell wrote:
> > > BTW, do we have a owner of such card among the subscribers which can do
> > > some testing when the time comes?
> >
> > I think Alan Cox. Alan Hourihane had one, but I think it die
On Llu, 2003-06-23 at 10:41, Keith Whitwell wrote:
> > BTW, do we have a owner of such card among the subscribers which can do
> > some testing when the time comes?
>
> I think Alan Cox. Alan Hourihane had one, but I think it died -- I find it
> very hard to keep gamma details in my head for som
On 23 Jun 2003 12:17:26 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-06-21 at 14:14, Andreas Stenglein wrote:
[snip]
>
> > + /* question: shouldn't the following be controlled by the
> > kernelmodule */
> > + /* and/or Xserver-configuration if it can crash the card? */
> >
[This e-mail has been automatically generated.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
attention.
All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at th
On Sat, 2003-06-21 at 14:14, Andreas Stenglein wrote:
>
> [...] some comments where I dont know what to do.
I'll try to address some of them:
> + if( (sPriv->drmMinor < 3) || (getenv( "RADEON_NO_3RD_TMU")) ) /*
> question: is the check for drmMinor necessary? */
> + ctx->Const.MaxTextureU
José Fonseca wrote:
On Mon, Jun 23, 2003 at 08:20:31AM +0100, Keith Whitwell wrote:
José Fonseca wrote:
The Gamma DRM driver is quite peculiar in several aspects. I'd like to
know if those differences are result of experiments which might be worth
to generalise to other drivers or if instead it's
On Mon, Jun 23, 2003 at 08:20:31AM +0100, Keith Whitwell wrote:
> José Fonseca wrote:
> >The Gamma DRM driver is quite peculiar in several aspects. I'd like to
> >know if those differences are result of experiments which might be worth
> >to generalise to other drivers or if instead it's mostly dep
José Fonseca wrote:
The Gamma DRM driver is quite peculiar in several aspects. I'd like to
know if those differences are result of experiments which might be worth
to generalise to other drivers or if instead it's mostly deprecated and
should be made more equal to the others.
It is mostly deprecate
51 matches
Mail list logo
