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
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
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
> > >
> > > 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
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
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
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
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
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.
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
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
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'
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
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
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, 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
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 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
--- [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
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
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
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
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
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
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
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
> > 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 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
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.
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
> 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
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
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
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
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
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
36 matches
Mail list logo
