Dave Airlie wrote:
Hmm... CVS HEAD advertises 20021108:
http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13&view=
auto Look for #define DRIVER_DATE.
Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said
to try an updated driver from dri.sf.net. :)
not su
Mike Mestnik wrote:
Currently every inst that referances a register(this is most of them)
needs a global .register setting?? As far as making the build system use
the C vs the asm I could also not find where this is soposed to happen. I
got as far as stoping the asm from being built, but then I c
I know I posted the exact errmsg but esecaly it's missing a global
.register deffinition and it's just the sam code (.S).
I build it in 64bit (not using sparc32 to fake a 32bit system). I needed
this cause DRI is knowen to not work with mixed user/kernel bitdepths and
I have a 64bit kernel. glib
Currently every inst that referances a register(this is most of them)
needs a global .register setting?? As far as making the build system use
the C vs the asm I could also not find where this is soposed to happen. I
got as far as stoping the asm from being built, but then I coulden't find
what C
These seem to be good requierments of any conclusion that is reached.
1. On the fly context switching.
1a. Even if the GART is %100 full for the new/old context.
1b. Even if the VideoRam is %100 full for the new/old context.
1c. Even if the Card(s) are locked for exlusive use.
1d. Even if add
> I haven't followed DRI closely, so this may be a FAQ or just a stupid
> question, but why is the DRI module in the 2.6.6 kernel almost two years old?
there are 3 components to a 3d driver, DRM, DRI and DDX :-),
DRM - lives in kernel - the i830 DRM hasn't needed any major changes in
the two yea
Dave Airlie wrote:
Hmm... CVS HEAD advertises 20021108:
http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13&view=
auto Look for #define DRIVER_DATE.
Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said
to try an updated driver from dri.sf.net. :)
not su
Ian Romanick <[EMAIL PROTECTED]> writes:
> Yes, the driver in the freedesktop.org tree is *ancient*. That's why
> he said to try an updated driver from dri.sf.net. :)
i am confused. if i go to dri.sf.net, under cvs downloads it says:
The DRI project has moved its CVS services to
http://dri.
>
> I have one question though, how is RGB_DXT1 and RGBA_DXT1 going to work?
> As far as I can see, there's no difference at all between these two
> formats as far as the driver is concerned, which can't be correct
> (pixels which need to get decompressed as black, fully opaque for
> RGB_DXT1 need
> > Hmm... CVS HEAD advertises 20021108:
> >
> > http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13&view=
> > auto Look for #define DRIVER_DATE.
>
> Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said
> to try an updated driver from dri.sf.net. :)
no
I think I've noticed a problem in i830_tris.c, in i830RenderStart.
Let's say you've got fog turned on but not specular. Then v0 has
VRTX_HAS_SPEC set, and you're emitting the fog factor and a 3-byte pad.
If you then turn on specular, v0 still has VRTX_HAS_SPEC set, so the
test at the end won't d
Kristian HÃgsberg wrote:
Keith Whitwell wrote:
The '2002' part of the date should be a hint -- please download a
recent snapshot from dri.sf.net & try with that.
Hmm... CVS HEAD advertises 20021108:
http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13&view=auto
Look for #def
Keith Whitwell wrote:
Andrà Ventura Lemos wrote:
On Mon, 2004-05-24 at 11:15, Dave Airlie wrote:
doesn't happen for me,
00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated
Graphics
Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (re
Ian Romanick wrote:
Here's an updated version of that patch. There are some significant
differences.
I hate it when I do that
Index: src/mesa/glapi/gl_procs.py
===
RCS file: /cvs/mesa/Mesa/src/mesa/glapi/gl_procs.py,v
retrieving
Ian Romanick wrote:
Alan Hourihane wrote:
Is there someone looking to integrate the TLS patches for libGL ??
We should certainly take a look soon and comment upon the patches used.
Here is a patch that covers part of what's in the Redhat patch. This
convert the static_functions table to a list of
On Mon, 2004-05-24 at 03:25, Mike Mestnik wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
> > > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> >
> I mean what about in places where this should have allready been done,
> deep inside the drive
André Ventura Lemos wrote:
On Mon, 2004-05-24 at 11:15, Dave Airlie wrote:
doesn't happen for me,
00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
[drm] Initializ
--- [EMAIL PROTECTED] wrote:
> Hi all.
> I've tested the code on my SAVAGE MX an discovered that:
> - Opengl acceleration works fine, with a colour depth of only 16 bit
> due
> to lack of video ram (only 8192 k)
> - Xvidinfo says NO ADAPTORS FOUND, and it is almost impossible to run
> a
> dvd and
On Sun, 2004-05-23 at 22:52, Dieter NÃtzel wrote:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
> 1143 for (p = 0 ; p < MAX_LIGHTS; p++) {
That doesn't make much sense, I don't see a pointer being dereferenced
h
Hi all.
I've tested the code on my SAVAGE MX an discovered that:
- Opengl acceleration works fine, with a colour depth of only 16 bit due
to lack of video ram (only 8192 k)
- Xvidinfo says NO ADAPTORS FOUND, and it is almost impossible to run a
dvd and so on.
I used to see dvd and Xvid with Tim Rob
On Mon, 2004-05-24 at 11:15, Dave Airlie wrote:
> doesn't happen for me,
> 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
> Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
> [drm] Initialized i830 1.3.2 20021
Mike Mestnik wrote:
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can all-ready run X on multiple VTs and with DRI-reini
On Mon, 24 May 2004, Ian Romanick wrote:
> Andy Ritger wrote:
>
> > The other concern (how to make sure direct rendering has completed
> > by the time the drawable is used as a source in a composite
> > operation) conceptually would be solved as you describe, but I
> > expect the implementation
I'm getting:
tar: Read 2380 bytes from gradients.tar.tar
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors
Could you please send me over the tarball? Thanks
On Sun, 2004-05-23 at 18:57, Kristian Høgsberg wrote:
> I'm getting the
Dave Airlie wrote:
The attached patch provides s3tc (and broken fxt) texture compression
support on the i8xx (x>30) chipsets,
You need to apply the radeon/r200 patch from Roland first, Roland do
you want to merge this patch into yours?
Yes, I've merged it. New version can be found here (so I don'
Dave Airlie wrote:
This only happens with 2.6 kernels. Prior do the lockup, everything
works (I can see it through ssh), but the display gets blank, and never
comes back.
>
> doesn't happen for me,
> 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
> Device (rev
Sorry for taking so long to reply. In some cultures, taking 9 days to
reply to an e-mail means that much thought was put into the reply. ;)
Felix Kühling wrote:
=== Header files in the DRM ===
drm.h: driver-independent types and definitions for the 3D driver to
communicate with the DRM.
Driver-i
Andy Ritger wrote:
The other concern (how to make sure direct rendering has completed
by the time the drawable is used as a source in a composite
operation) conceptually would be solved as you describe, but I
expect the implementation would be buried deeper
I guess I don't see what the problem is.
Ian Romanick wrote:
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It
looks like the #if test in dispatch.c is wrong, so that stubs don't
even get used on SPARC. In any case, Jakub's patch did modify the
x86 assembl
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
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version
Maurice van der Pot wrote:
I have just started looking into DRI development and I have been experiencing
some difficulties using gdb. For example, I cannot currently step into
functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is
set correctly). Another thing is that the symb
> > >
> > > This only happens with 2.6 kernels. Prior do the lockup, everything
> > > works (I can see it through ssh), but the display gets blank, and never
> > > comes back.
doesn't happen for me,
00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
Device (rev 02)
[drm] In
No problem, here it is.
Kristian
Andrà Ventura Lemos wrote:
I'm getting:
tar: Read 2380 bytes from gradients.tar.tar
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors
Could you please send me over the tarball? Thanks
On Sun, 2004-05
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATC
36 matches
Mail list logo
