I think I saw a document on how to build a bare Mesa driver, but I don't
seem to find it anymore - could someone e-mail me a link ?
I vaguely remember it talking about needing a Context function and at
least two functions to read and write pixel.
I think you're talking about this wiki
Hi,
I've been trying to get {read,draw}pixels acceleration for the r100 driver by adapting
existing code from the r200 and adding a temporary dma buffer. So I've made this
little patch to the r200 driver that's supposed to accelerate drawpixels using dma.
However a similar patch doesn't work
Dieter Nützel wrote:
I get this with current Mesa CVS and DRI CVS for r200:
[snip errors]
Sorry, a correct patch is attached. Note that to try it, you need :
- to draw less than 64KB of pixels (that is ~16000 RGBA8 pixels)
- to specify glPixelZoom(1.F,-1.F);
- to use the correct pixel format :
Hi,
The attached patch adds pci init code for mesa solo with the radeon
driver thanks to a new configuration option in miniglx.conf.
Stephane
Index: src/glx/mini/driver.h
===
RCS file: /cvs/mesa/Mesa/src/glx/mini/driver.h,v
Stephane Marchesin wrote:
Hi,
The attached patch adds pci init code for mesa solo with the radeon
driver thanks to a new configuration option in miniglx.conf.
And of course, you're not interested in my debugging printf's. A patch
without my printfs is attached.
Sorry for the noise.
Stephane
Jon Smirl wrote:
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look quit
right. When one is used in context-gl.get_program_iv_arb() it segfaults. I'm
using an R128 which does not have hardware shaders.
Should these calls be returning values as
Ian Romanick wrote:
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int
in those places. Is it safe to assume sizeof(int) == sizeof(size_t)?
Well, on ia64, sizeof(size_t)==8, while sizeof(int)==4
Stephane
Ian Romanick wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns
a pointer to a dispatch function. If you request an unknown function,
it will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const GLubyte*)glThisFunctionDoesntExist);.
Alex Deucher wrote:
On 23 Aug 2004 18:30:01 -, Ian Romanick [EMAIL PROTECTED] wrote:
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
Hi,
I've enabled color tiling on the radeon. However, since you have to put
the crtc in tiling mode to compensate the effect, this can only be used
in fullscreen (or you're screwing everything around the 3D window).
Thus my question : how can I reliably detect fullscreen operation from
the
Alex Deucher wrote:
On Fri, 27 Aug 2004 01:01:23 +0200, Stephane Marchesin
[EMAIL PROTECTED] wrote:
Hi,
I've enabled color tiling on the radeon. However, since you have to put
the crtc in tiling mode to compensate the effect, this can only be used
in fullscreen (or you're screwing everything
Dieter Nützel wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with. Any
thoughts on this? If people think it's a good idea, I'll do it for
Eric Anholt wrote:
Same thing as for r200, but for r100. Effects are even better,
according to ipers. Anyone want to do some testing before I commit?
It breaks the textures for me under quake3 with a radeon 7000. Maybe
that's the culprit for the texture problems on r200, too.
Stephane
Hi,
It seems this change breaks the build (at least removing it makes it
compile again for me) :
http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/tnl_dd/t_dd_vbtmp.h?r1=1.3r2=1.4
While making linux-dri-x86 :
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
Hi,
The attached patches enable HyperZ on radeon (RV100 only for now).
People always ask me for an HyperZ benchmark, so :
HyperZ gets me 45% more fps (48 fps - 70 fps) in Quake3 four.dm68
(Radeon 7000, athlon XP 2600).
It also speeds up glxgears from 450 fps to 1300 fps, which shows how
useless
Keith Whitwell wrote:
Stephane,
Very impressive! I take it this has been derived from
reverse-engineering the ati driver?
How stable is this code now how much testing has it had?
I've been using it for one month with different OpenGL apps (mostly
Quake 3 friends, also tried most things in
Dave Airlie wrote:
I've quickly patched this into my devel tree for an in-house app, and it
don't look to work so well... the card is a mobility M7 7500 so it should
work..
Radeon 7500 is RV200, and I have a RV100. Maybe we've found one
difference between RV200 and R100 after all :)
I see a lot
Michel Dnzer wrote:
Can this really be a per-context option, considering that the depth
buffer is shared by all contexts?
No. Where do you put global options ?
Stephane
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition -
Dieter Nützel wrote:
Am Dienstag, 2. November 2004 02:11 schrieb Stephane Marchesin:
Hi,
The attached patches enable HyperZ on radeon (RV100 only for now).
People always ask me for an HyperZ benchmark, so :
HyperZ gets me 45% more fps (48 fps - 70 fps) in Quake3 four.dm68
(Radeon 7000, athlon XP
Dieter Nützel wrote:
Am Donnerstag, 4. November 2004 23:09 schrieb Roland Scheidegger:
(sorry for sending this first to the wrong list. replies should be in
dri-devel, not mesa3d-dev.)
Here's an updated version of the patch, which should work on more cards.
Specifically, it works on my rv250,
Hi,
The attached patch adds readpixel acceleration to the r100 based on
what's done for the r200.
This speeds-up readpix by a factor of 2 on x86, and much more on non-x86
systems which don't benefit from Ian's patch (like 8 times on itanium 2).
Stephane
diff -Naur radeon.old/Makefile
Brian Paul wrote:
I'll be checking in a fix for this soon.
I've replaced the _swrast_clip_pixelrect() functions with two new
functions: _mesa_clip_readpixels() and _mesa_clip_drawpixels(). The
main difference is the later one obeys the scissor rectangle.
The DRI drivers might use
Roland Scheidegger wrote:
Roland Scheidegger wrote:
In fact, that was already discussed briefly at irc. For now it just
seemed more important to get it working on more cards and fix the
rendering problems than to worry about minor issues like multiple
rendering apps :). I did get clearing only
Brian Paul wrote:
I guess I'd like to see the clipping issues resolved before checking
in the patch.
Ok, I'm not sure I understood what you expect, but here is what I did :
I used the mesa window space clipping routines and then added a
dri/common/clip.h file that does the screen clipping.
Brian Paul wrote:
I guess I'd like to see the clipping issues resolved before checking
in the patch.
Ok, I'm not sure I understood what you expect, but here is what I did :
I used the mesa window space clipping routines and then added a
dri/common/clip.h file that does the screen clipping.
Ok, here is a new patch.
Stephane
diff -x CVS -Naur ../../../../../Mesa.orig/src/mesa/drivers/dri/common/clip.h
./common/clip.h
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/common/clip.h 1970-01-01
01:00:00.0 +0100
+++ ./common/clip.h 2004-11-16 01:01:55.0 +0100
@@ -0,0
Rogier Stam wrote:
Hi guys,
I tried testing the HyperZ patch, but I ran into some problems. First
of all, my configuration is Xorg 6.8.0 pulled out of CVS on
20/10/2004, with the HyperZ patch installed (found at the following
links :
Jacek Popawski wrote:
On Thu, Dec 02, 2004 at 08:49:56AM -0500, Alex Deucher wrote:
Radeon 9000 PCI
Radeon 9200se AGP
these two chips are already fully supported by xorg and the DRI.
Fully? Was HyperZ only missing feature?
There are at least 2 other features :
- pixel shaders
Brian Paul wrote:
We probably need Mesa driver hooks for BeginQuery() and EndQuery(). I
could implement that pretty quickly. Let me know.
Well, I have that done already. My current problems are :
- fix the XXX revisit when we have a hardware implementation!. i.e.
how to get the query status
Dieter Ntzel wrote:
Hmmm. It works, but there is a bit that we'll probably leave aside on
the R200 (hierarchical Z) because neither Roland nor me have an R200.
What do you need (apart from the hardware, at the moment ;-)?
Basically, the problem is that hierarchical z stores z values using 8
bits.
Hi,
The small attached patch adds a new drm ioctl to do surface
allocation/deallocation on the radeon.
The reason to add a new ioctl is the following : since there are only 8
surfaces someone has to arbitrate between allocations by the ddx (color
buffers) and from the dri (depth buffers).
Hi,
Attached is a patch that adds pci init code for mesa solo on radeon.
It's been tested on an itanium 2 with a radeon 7000 and it works here.
The patch adds a new field in the miniglx.conf config file, to choose
between pci and agp.
Stephane
Index: src/glx/mini/driver.h
Stephane Marchesin wrote:
Fully? Was HyperZ only missing feature?
There are at least 2 other features :
- pixel shaders (ATI_fragment_shader). It's R200 only.
- occlusion culling (ARB_occlusion_query and friends). Same on R100
and R200. I started working on this one and know the registers numbers
Michel Dnzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
+
+ if ( DRM_COPY_TO_USER( alloc.surface, i,
+ sizeof(int) ) ) {
+ DRM_ERROR( copy_to_user\n );
+
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback
(both on the idea and the implementation) before I build anything upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a better idea with some card
Keith Whitwell wrote:
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback
(both on the idea and the implementation) before I build anything
upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a
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
Hi,
In the drm, I found that the memory allocator can handle both gart
(RADEON_MEM_REGION_GART) and fb (RADEON_MEM_REGION_FB) memory.
However, the second type is never used. Is there a reason for that ?
Stephane
---
The SF.Net email is
[from the SDL maling list]
Jesse Barnes wrote:
I noticed that on my ia64 machine when SDL_Quit was called, the machine would
hang in weird ways. It turned out to be caused by a machine check in the
memset() call near the top of FB_VideoQuit. Generally memset shouldn't be
used on I/O regions
Hi,
When fixing depth reads on rv100, I found that my zbuffer wasn't tiled
by default.
Is this a known fact ? Is there a way to enable/disable depth tiling on
this card ?
Stephane
---
The SF.Net email is sponsored by: Beat the post-holiday
Jesse Barnes wrote:
I figured other projects might have similar problems, thanks for checking dri.
Please note that I didn't actually check the dri. I just happened to get
an MCA from time to time at mesa solo startup and your post on the SDL
list showed a possible reason to me.
I already
Michel Dnzer 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
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each block line starts
with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will
have set
Jacek Rosik wrote:
Hi
Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisa(a):
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each
Jacek Rosik wrote:
Dnia 29-01-2005, sob o godzinie 21:38 +0100, Stephane Marchesin
napisa(a):
Jacek Rosik wrote:
Would 7000 PCI be a rv100? I think I have one somewhere. Without depth
tiling my Idea should be simpler to implement.
Yes. But, I'd like to have hyperz enabled by default soon, so
Jesse Barnes wrote:
On Saturday, January 29, 2005 4:38 pm, [EMAIL PROTECTED] wrote:
When I use solo on ia64, it sometimes causes an MCA upon startup. That's
because a memset is done on the framebuffer memory during init.
Please refer to this message from Jesse Barnes to know why this is bad :
Jesse Barnes wrote:
On Monday, January 31, 2005 12:00 pm, Stephane Marchesin wrote:
Yes, other drivers suffer from that too (at least r128, i810 and mga as
far as I can see). However, as I said previously I don't understand them
enough to touch them.
Oh, I must have missed that message, sorry
Roland Scheidegger wrote:
I suspect that quite the contrary, almost noone has crashes. This is
probably part of the problem, if they happen only for few people with
very specific configurations, none of the developers can reproduce it
and it will just remain unfixed.
For reference, I never get
Roland Scheidegger wrote:
Ok, I was FINALLY able to come up with something for texture tiling
which seems to work - this was very very annoying, it _almost_ worked
literally within minutes, but I needed a lot of time until it finally
did really work.
I needed to convert back the drivers to use
Hi,
I suspace zcache flushing before fast zclears is not needed on r100 (and
removing it adds a couple of q3 frames :).
This patch removes it for these chips. It works fine on rv100, but I
wonder if it does on r100/rv200 too.
So, testing is welcome !
Stephane
Index: shared/radeon_state.c
Hi,
Attached is a straight port of Eric's fix for the drm race to non-core drm.
Stephane
Index: shared/radeon_drv.h
===
RCS file: /cvs/dri/drm/shared/radeon_drv.h,v
retrieving revision 1.40
diff -u -r1.40 radeon_drv.h
---
Dieter Ntzel wrote:
r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)
I'm ran with both.
Should they merged?
I surely hope to get my readpixels patch merged. However, I found a
serious flaw in it (not related to the readpixe segfault) which I have
to fix before this happens.
Dario Laera wrote:
Ben Skeggs wrote:
Hello,
I've attached a patch with a port of the r200 vertex buffer code for
the r300 driver.
The performance of the vertex buffer codepath is now roughly the same
as the
immediate path, and tuxracer now seems to be rendered almost correctly.
I've tried it on
Roland Scheidegger wrote:
Since people have asked for it, I decided I'd give it a try...
So here it is, a unified radeon driver (no not r300, only r100 and r200).
http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_radeon.tar.bz2
exectuable generated will be called radeon_dri.so, for
Roland Scheidegger wrote:
Wasn't the limit 2560x2560 with the r300 based chips? That's at least
what fglrx will do on r300.
The limit seems to be 2560 on r300 (high end) cards, but 2048 on rv300
cards (these cards really look like they have exactly the same tiling
regs as r200).
Stephane
Vladimir Dergachev wrote:
fglrx will do on r300. I'm wondering about that though a bit, that
would be 11.3 bit for coords or so ;-). It would also mean the tiling
regs need to be different a bit on r300 compared to r100/r200.
I looked through the register manual for Radeons and it looks like
[EMAIL PROTECTED] wrote:
Thank you for the advice. The problem I had before with the DRM
modules (drm.ko and radeon.ko) from the r300 CVS was that drm.ko would
load fine but loading radeon.ko was causing my computer to lock up
after a kernel panic. I had tried it rebuilding both it and the
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the
module I get :
[drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory!
[drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART!
That's
Stephane Marchesin wrote:
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting
the module I get :
[drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory!
[drm:radeon_do_cleanup_cp] *ERROR* failed
Jesse Barnes wrote:
On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote:
Stephane Marchesin wrote:
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting
the module I get :
[drm:radeon_ati_pcigart_cleanup
Jesse Barnes wrote:
Ok, so I've got everything built and the sample server starts (after applying
the attached patch):
[EMAIL PROTECTED] miniglx]# ./sample_server
[miniglx] probed chipset 0x4e4b
got MMIOAddress 0x20001090 offset 268435456
[drm] added 65536 byte SAREA at
Jerome Glisse wrote:
Hi,
My Machine
Powerbook G4
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB
Ubuntu Hoary (kernel 2.6.10)
The drm module doesn't seem to work any longer for me. Drm loads without
error but I don't get the normal microcode message. r300_demo now seg
faults when it
Felix Khling a crit :
I haven't changed anything in the Savage DRM in a while. Must be some
change in the generic drm module. I won't be able to look into this.
Does the oops below ring a bell, anyone?
I think that's the same issue I have
(https://bugs.freedesktop.org/show_bug.cgi?id=2418)
Ian Romanick a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There's been quite a bit of discussion about this on #dri-devel the past
few days. I thought I'd write up a quick summary and post it to the
list. I know that there are a lot of interested parties that are on the
list, but
Stephane Marchesin wrote:
Now, there is one question that sounds to me like it will have
implications over the whole memory manager design : do we want to
enforce video memory ownership ?
Ok, here is what came out of the irc meeting :
- we don't need to enforce video memory ownership
Michel Dänzer wrote:
You'd need the same stuff that you need to protect system memory. You'd
need a hardware MMU that could block the accesses. It might be possible
to do it in software by looking at the command stream, but I suspect
that would be pretty expensive. It would be worth a try, I
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't enable direct rendering.
Thats a very poor answer to the problem. DRI needs to be
Michel Dänzer wrote:
Security is more than just the memory manager. To enforce video memory
protection, we'd have to audit the code and add memory protection to
existing drm modules. That is quite a lot of work, and requires
extensive knowledge of each card. So I don't think it's worth the
Philipp Klaus Krause wrote:
I hvae removed GL_EXT_cull_vertex from my patch, since Brian wants to
remove it from Mesa, too.
Since the r128 doesn't have hardware tcl all interesting features of
Mesa's software tcl should be exposed.
This patch adds support for
GL_ARB_vertex_buffer_object,
Philipp Klaus Krause wrote:
Stephane Marchesin schrieb:
What is the point of advertising GL_MESA_pack_invert if it's not
implemented ?
Stephane
According to extensions specification this extension's main purpose
seems to be making application developers life a little bit easier, just
khaqq wrote:
On Tue, 06 Dec 2005 13:13:35 +0100
Roland Scheidegger [EMAIL PROTECTED] wrote:
vehemens wrote:
Posting my latest DRM and Mesa patches in case they should prove useful to
anyone else. They are to head as of early Saturday.
I moved the CP idle outside the while loop in
Philipp Klaus Krause wrote:
Adam K Kirchhoff schrieb:
I'm sure this confirms what are already known issues with the r300
driver, but felt it'd be worth posting anyway. There's definitely
something bizarre going on with textures. They're much crisper with the
fglrx driver.
To me
Hi,
I was considering how complicated it can be to implement a texture
replacement policy, and then I had the following idea : we could make
use of hardware cocclusion queries on cards that support them to
determine actual texture usage and thus have a good texture replacement
policy. Here
Dawid Gajownik wrote:
Hi!
Hi,
I was told on fedora-devel-list about nouveau project and I would
like to help somehow ;) Although I don't have good programming skills,
renouveau tool is quite easy to use so I could try to guess how some
OpenGL commands work (examples in doc directory are
Paul Wise wrote:
Hi all,
[I'm not subscribed, please CC me]
I'm wondering how nouveau relates to this free nvidia 3D driver for
beos. Perhaps you could use code from it? I think it is utah-glx
related.
http://be-hold.blogspot.com/
Hi,
Yes, we know about that 3D driver. I'm in contact
Michael Schreckenbauer wrote:
Hello,
Am Mittwoch, 26. April 2006 17:02 schrieb Stephane Marchesin:
Paul Wise wrote:
Hi all,
I'm wondering how nouveau relates to this free nvidia 3D driver for
beos. Perhaps you could use code from it? I think it is utah-glx
related.
http
Dawid Gajownik wrote:
Hi!
Hi,
I have finished documenting glViewport() and glScissor() functions
→ http://fedora.pl/~gajownik/nouveau/glViewport_and_Scissor_NV17
Very nice !
Output of glViewport depends on 13 variables (I still haven't figured
out three of them) so it took me some
Dawid Gajownik wrote:
Dnia 04/30/2006 02:47 PM, Użytkownik Stephane Marchesin napisał:
What do you think about renaming NV10_SET_VIEWPORT_DIMS to
NV10_SCISSOR? If you execute glEnable(GL_SCISSOR_TEST) function,
NV10_SET_VIEWPORT_DIMS changes dimensions of scissor box (not
viewport ones
James C Georgas wrote:
There are black grid lines between some terrain tiles in various games I
have.
It seems to happen in both software and direct rendering.
I'm using this morning's cvs HEAD for mesa and dri.
System is dual Opteron.
Video card is FireGL X1-128
OS is Gentoo amd64.
Stephane Marchesin wrote:
Hello,
The drm addmap code got broken with the recent switch to the hash table
implementation. Specifically, when two maps have the same adress on 32
bits, they end up with the same key and nothing is done to resolve the
collision, which results in a failind addmap
Hello,
Before explaining the issue, let me first introduce the context a bit.
We are working on hardware that supports multiple contexts. By
allocating one context to each application, we can achieve full graphics
command submission from user space (each context is actually simply a
command
Thomas Hellström wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
But this should be the same problem encountered by the agpgart driver?
x86 and x86-64 calls change_page_attr() to take care of this.
On powerpc it is simply a noop.
Anna Lissa Cruz wrote:
Hi all,
I just signed onto the list. I'm working with Rudi Cilibrasi and
wondering where's the best place to start contributing. We're both C
programmers, with some OpenGL experience, and have NV35 and NV36 cards
to play with. We have checked out the feature
Rudi Cilibrasi wrote:
Hi everybody,
I have just started trying to contribute to this project and got as
far as identifying chip family for the two cards I have access to
here: NV35 and NV36. I added a column for NV35 assuming that the
protocol would be different than NV30 in the TODO
[EMAIL PROTECTED] wrote:
Hello,
I'm Dee Sharpe and I have been working on the Syllable port
of Mesa3d. Now it is time to move on to hardware acceleration. What
would it take to port the DRI to another windowing system? The glue
code that I have to write will be in C++. If anyone has
Michael Buesch wrote:
On Friday 15 December 2006 16:53, Michel Dänzer wrote: On Fri, 2006-12-15 at
15:17 +0100, Michael Buesch wrote: I just tried to load the nouveau driver
on my Apple G5 Quad machine. The kernel module loaded fine, but an
attempt to start the x-server resulted in a
Simen Thoresen wrote:
Hi Nouveau- (and other cheap PCI and PCIe -graphics users)
I have several PCI and PCIe tracers available through my employer, and
will be able to purchase low-end versions of modern video-cards
(preferably PCI versions, but possibly PCIe versions as well) for
Phillip Ezolt wrote:
Stephane,
What tools do you use for tracing? I know that you have the
renouveau tool and libsegfault.
I'm hacking on the ATI stuff, and it would be handy to have code which
can just out what MMIO writes the kernel driver is doing. Do you guys
have anything to do
Alexy Khrabrov wrote:
Greetings -- compiled drm and nouveau yesterday from git and tried to
run X -- hangs at the loading stage. Xorg.0.log attached. I've
followed the following checks:
-- kernel compiled with DRM disabled
-- binary nvidia module not loaded
The drm installed libdrm.so in
David Nielsen wrote:
Dear Nouveau developers
It is my pride and honor on behalf of myself and 1247 other pledgers (as
of current writing) to formally offer up the sum of ~10.000$ in the form
of 1248 pledges of at least 10$ each.
It is entirely up to you, the nouveau developers, if you want
Alexy Khrabrov wrote:
[forwarding to the list as well]
Here it is, below. I manually modprobe agpgart to make drm.ko happy.
Do I have to recompile something else -- it complains about drm? The
screen goes blank and doesn't come back, but ctrl-alt-del still
reboots.
Cheers,
Alexy
Alexy Khrabrov wrote:
Philipp, Mark --
Thanks for the concise and extremely useful explanation! This is
worthy of being on the front page of a wiki.
Also, there is that :
http://people.freedesktop.org/~ajax/dri-explanation.txt
Stephane
Keith Whitwell wrote:
configs/linux-dri-debug | 16
1 files changed, 16 insertions(+)
New commits:
diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from
747c9129c0b592941b14c290ff3d8ab22ad66acb)
Author: Keith Whitwell [EMAIL PROTECTED]
Date: Wed Jan 17 08:44:13
Keith Whitwell wrote:
Stephane Marchesin wrote:
Keith Whitwell wrote:
configs/linux-dri-debug | 16
1 files changed, 16 insertions(+)
New commits:
diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from
747c9129c0b592941b14c290ff3d8ab22ad66acb)
Author
Svante Signell wrote:
Dear Noveau developers,
Some years ago, around 2000-2002 there was a guy in New Zealand, David,
working on Nvidia drivers, see the message at the Utah-GLX mailing list
archive from April 2002:
http://sourceforge.net/mailarchive/forum.php?thread_id=612267forum_id=3646
Dave Brown wrote:
Hi there,
I've recently become interested in the Nouveau project. Specifically
I'm considering looking at porting it to a relatively unknown
operating system called RISC OS that is based on the ARM processor.
The platform I would be targeting currently has uses
On 10/24/07, Adrian Bunk [EMAIL PROTECTED] wrote:
drm_sg_alloc() can now become static.
FWIW there is at least one consumer of it in drm git.
Stephane
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping
On 11/27/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Kristian Høgsberg wrote:
On Nov 22, 2007 4:03 AM, Thomas Hellström [EMAIL PROTECTED]
wrote:
...
There are probably various ways to do this, which is another argument
for keeping super-ioctls device-specific.
For i915-type
On 11/27/07, Keith Packard [EMAIL PROTECTED] wrote:
On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote:
-full state
I assume you'll deal with hardware which supports multiple contexts and
avoid the need to include full state with each buffer?
That's what we do already for
On 11/22/07, Kristian Høgsberg [EMAIL PROTECTED] wrote:
Hi all,
I've been working on the DRI2 implementation recently and I'm starting
to get a little confused, so I figured I'd throw a couple of questions
out to the list. First of, I wrote up this summary shortly after XD
1 - 100 of 162 matches
Mail list logo
