On Thu, Apr 8, 2010 at 16:37, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 8 Apr 2010 18:38:03 -0400
Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul bri...@vmware.com wrote:
Unless there's some objection I'm going to subscribe everyone to the
On Thu, Mar 4, 2010 at 23:44, Ingo Molnar mi...@elte.hu wrote:
* Pekka Enberg penb...@cs.helsinki.fi wrote:
On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote:
The conclusion is crystal clear, breaking an ABI via a flag day
cleanup/feature/etc is:
?- wrong
?- harmful
On Thu, Mar 4, 2010 at 12:07, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, 4 Mar 2010, Matthew Garrett wrote:
IOW, we have a real technical problem here. Are you just going to continue
to make excuses about it?
I'm not questioning the fact that it would be preferable to
On Thu, Mar 4, 2010 at 15:03, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, 4 Mar 2010, Adam Jackson wrote:
On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote:
On Thu, 4 Mar 2010, Matthew Garrett wrote:
If you'd made it clear that you wanted the interface to be stable
On Thu, Mar 4, 2010 at 15:09, Brian Paul bri...@vmware.com wrote:
Jesse Barnes wrote:
Would anyone have objections if these lists moved to freedesktop.org?
The recent thread with Linus about the drm pull request highlights the
post lag and non-subscriber aspect of the current lists, and that
On Sat, Feb 6, 2010 at 11:47, Émeric Maschino emeric.masch...@gmail.com wrote:
2010/2/4 Jerome Glisse gli...@freedesktop.org:
IIRC old radeon drm doesn't have any thing to dump GPU command stream.
Look at http://www.x.org/docs/AMD/R5xx_Acceleration_v1.4.pdf to see
what radeon GPU stream
On Mon, Feb 1, 2010 at 13:17, Émeric Maschino emeric.masch...@gmail.com wrote:
2010/1/31 Jerome Glisse gli...@freedesktop.org:
snip
Eventually, strace log is flooded with
ioctl(4, 0xc0106451, 0x6fd530f8) = 0
roughly at the time the CPU charge increases. This is consistent with
what
On Fri, Dec 11, 2009 at 00:58, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
But not only is Fedora not following the rules,
You changed the rules. You require a Signed-off-by:. Fedora can no more
add a signed off by than you can. It's not their code nor Red Hat's code
any more than they own the
2009/12/12 Dave Airlie airl...@gmail.com:
2009/12/12 Stephane Marchesin stephane.marche...@gmail.com:
I did git log on the nouveau kernel tree nouveau dir with sort and uniq,
I'm not sure where else I needed to trawl to get anymore ppl who have
contributed to
the KMS driver. I'm sure ppl
On Sat, Dec 12, 2009 at 00:27, Stephane Marchesin
stephane.marche...@gmail.com wrote:
2009/12/12 Dave Airlie airl...@gmail.com:
2009/12/12 Stephane Marchesin stephane.marche...@gmail.com:
I did git log on the nouveau kernel tree nouveau dir with sort and uniq,
I'm not sure where else I needed
along with project founder Stephane Marchesin marche...@icps.u-strasbg.fr
Btw could we get proper developer credit here? I think 3/4 of the
people who wrote the code are missing here.
Stephane
--
Return on Information
On Thu, Dec 10, 2009 at 19:42, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, 10 Dec 2009, Maarten Maathuis wrote:
You assume that Red Hat has full control over the project, which i
don't think is the case. The reason it isn't in staging yet (as far as
i know) is because of
2009/12/10 Alan Cox a...@lxorguk.ukuu.org.uk:
The big question is what we call ctxprogs: binary blobs that are
clearly executable, running somewhere in the GPU. No-one seems
to know, if those are copyrightable, or if they can be redistributed.
In their current form, they have been recorded
2009/11/17 Kristian Høgsberg k...@bitplanet.net:
2009/11/6 Kristian Høgsberg k...@bitplanet.net:
Hi,
This has come up a few time and it's something I think makes a lot of
sense. Since all driver development (afaik) now happens in linux
kernel tree, it makes sense to drop the driver bits
[oops, with reply-all this time]
On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 9 Nov 2009 17:46:44 +0100
Stephane Marchesin marche...@icps.u-strasbg.fr wrote:
And how do I get releases of libdrm out outside of kernel releases?
We're doing libdrms
On Mon, Nov 9, 2009 at 11:51, Rémi Cardona r...@gentoo.org wrote:
Le 09/11/2009 00:14, Robert Noland a écrit :
There are any number of changes that may occur in libdrm that do not
impact the KBI and users should be able to get those features/bug fixes
without needing a new kernel.
On Mon, Nov 9, 2009 at 17:42, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote:
On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote:
On Sun, Nov 8, 2009 at 20:02, Eric
2009/11/6 Kristian Høgsberg k...@bitplanet.net:
Hi,
This has come up a few time and it's something I think makes a lot of
sense. Since all driver development (afaik) now happens in linux
kernel tree, it makes sense to drop the driver bits from the drm.git
repo. I've put up a repo under
On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
2009/11/6 Kristian Høgsberg k...@bitplanet.net:
Hi,
This has come up a few time and it's something I think makes a lot of
sense. Since all driver development
On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
2009/11/6 Kristian Høgsberg k
On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote:
On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote:
On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
On Sun, Nov 8, 2009 at 19:18, Eric
2009/9/1 Keith Whitwell kei...@vmware.com:
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset. But I don't really
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to communicate the constrains to userspace. This is either
to generic or not suitable for everything.
You obviously got all this completely wrong.
I avoid writing closed source drivers whenever I can, I'm not whining and
I'm not trying to push any of them. The code VIA is trying to submit has not
been written by me nor anybody I know. All VIA code I and the companies I've
worked for has
2009/7/20 Thomas Hellström tho...@shipmail.org:
Stephane,
Some comments on how these things has been handled / could be handled.
I would like to raise a couple of real-life issues I have in mind:
* First example, let's say VIA gets their Chrome9 DRM merged into the
kernel. Now let's say I
On Fri, Jul 17, 2009 at 15:23, Keith Whitwellkei...@vmware.com wrote:
Maybe VIA can provide some userspace code without putting together an
entire driver.
A handful of standalone programs that exercise the interface would help
evaluate the interfaces and might be sufficient to serve as
On Thu, Jun 25, 2009 at 09:46, Jerome Glissegli...@freedesktop.org wrote:
On Wed, 2009-06-24 at 22:32 +0200, Roland Scheidegger wrote:
On 24.06.2009 20:17, Jerome Glisse wrote:
I think we should let user ask at gem map ioctl time if userspace wants
an surface backed mapping or not, and gem
On Mon, May 18, 2009 at 03:11, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Currently, userspace fails to obtain the SAREA mapping on some platforms
because they pass SAREA_MAX to drmAddMap without aligning it to the page
size. This breaks for example on PowerPC with 64K pages.
The
Hi,
This mga patch replaces a firmware that was split in pieces by
functionality and that had comments with a single blob. So IMO it's
actually decreasing the quality of the code.
Stephane
--
Open Source Business
On Thu, Feb 19, 2009 at 15:46, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
srol...@tungstengraphics.com wrote:
On 19.02.2009 12:23, Arkadi Shishlov wrote:
Roland Scheidegger wrote:
I suspect you're hitting a r200 asic bug, which isn't present
On Thu, Jan 29, 2009 at 09:40, Thomas Hellström tho...@shipmail.org wrote:
Owain Ainsworth wrote:
On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote:
Hi,
If no one objects, I'll prune the nv kernel module from drm git
sometime next week.
Please do.
Done.
I'm wondering
On Wed, Feb 4, 2009 at 11:14, Thomas Hellström tho...@shipmail.org wrote:
Stephane Marchesin wrote:
On Thu, Jan 29, 2009 at 09:40, Thomas Hellström tho...@shipmail.org wrote:
Owain Ainsworth wrote:
On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote:
Hi,
If no one objects
Hi,
If no one objects, I'll prune the nv kernel module from drm git
sometime next week.
Stephane
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
On Thu, Jan 29, 2009 at 02:29, Owain Ainsworth zer...@googlemail.com wrote:
On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote:
Hi,
If no one objects, I'll prune the nv kernel module from drm git
sometime next week.
Please do.
I'm wondering if we should prune i915 now
Hi,
As you might have noticed, nouveau's gallium work has been merged into
mesa's gallium-0.2 (yeah I slacked long enough on that). So now
nouveau development should happen there (mesa/gallium-0.2). Mesa also
gains g3dvl, which is Younes's summer of code work on implementing
video decoding on top
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
The DRM design includes ioctls to allow a userland driver to tell the kernel
driver when to register its interrupt handler and on what IRQ. This is a
really bad idea for several reasons, and fortunately I don't think any
On Tue, Aug 26, 2008 at 9:36 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel driver
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model... Things are actually worse than I
thought. There are some fairly large differences between linux-core and
upstream, some
On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
I am outlining the fact that you confuse a problem and its solution.
Problem: merging stuff upstream takes time to Dave
Your solution: have lots
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote:
I might be totaly wrong so feel free to ignore these. I got the feeling
that the user test base on linux kernel is far bigger than ours. Also
i think that our test user base are people wanting lastest things with
old kernel, while i
On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti [EMAIL PROTECTED] wrote:
Hi Jakob,
Jakob Bornecrantz escreveu:
The only thing that should be in the kernel is the:
- touch the gfx registers.
and in some regards
- takes care of the cursor limits.
Anything else is the client
If the new driver won't be an incremental change to the existing radeon
drivers, I'd recommend basing it on Gallium.
Hi Brian,
It seems like people are mostly concerned about gallium stability
right now. How stable wioll the interfaces be in the future ? Maybe if
you could tell us, that'd
On 5/16/08, Pekka Paalanen [EMAIL PROTECTED] wrote:
On Fri, 16 May 2008 10:05:18 +0200
Jerome Glisse [EMAIL PROTECTED] wrote:
My current understanding is that on newer GPU each client got its
own memory address space on the GPU. I can manage this space
transparently based on hint from
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote:
Yes, that was really my point. If the memory manager we use (whatever
it is) does not allow this kind of behaviour, that'll force all cards
to use a kernel-validated command submission model, which might not be
too fast, and more
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote:
What you fail to notice here is that I think most people intend to
have only one memory manager in the kernel.
How on earth can you draw that conclusion from the above statement?
Well, Dave has been saying this to me all along...
On 5/14/08, Dave Airlie [EMAIL PROTECTED] wrote:
I was hoping that by now, one of the radeon or nouveau drivers would have
adopted TTM, or at least demoed something working using it, this hasn't
happened which worries me, perhaps glisse or darktama could fill in on
what limited them from
So, we should really fix this. The two options are :
- Keep a different calling convention under linux (cdecl by default,
which requires saving esi by hand in the shader) and apply Victor's
patch which saves restores this register
- Use the same calling convention on all platforms, that is change
Ok, the DRI application for summer of code just went in (at the very
last minute). Thanks to those who joined in and filled our project
page, and hopefully talk to you when discussing projects :)
Stephane
-
This SF.net email
Ok, anyone else interested (ATM it's Jerome - Idr - Alex - me) ?
The deadline for project applications is wednesday so we'll have to
write the proposal for DRI quick now. Hopefully it works out.
Stephane
-
This SF.net email
On 3/11/08, Ian Romanick [EMAIL PROTECTED] wrote:
Link missing in previous post:
http://dri.freedesktop.org/wiki/GSoC_2008
I added a couple of ideas to the page. Who's next ? :)
Stephane
-
This SF.net email is
Hi,
I often hear DRI developers talking about how we lack contributors.
Well, this is the occasion, I think we could get together and try to
propose DRI as a separate organization for the google summer of code
(it's also good to have DRI seen as a separate project from the
outside, and not just
On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote:
So I've been thinking about this stuff a lot lately wrt to getting the
DRM into a state that enables fast-user-switching, GPGPU apps,
different users on a per head one a single card..
http://dri.freedesktop.org/wiki/DRMRedesign
has a nice
On 2/13/08, Jesse Barnes [EMAIL PROTECTED] wrote:
On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin wrote:
On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote:
So I've been thinking about this stuff a lot lately wrt to getting the
DRM into a state that enables fast-user-switching
On 2/14/08, Jesse Barnes [EMAIL PROTECTED] wrote:
On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
You don't want any application to be able to change CRTC-output
mappings, or bind BOs to CRTCs. Ideally you'd just have one app that
could do that on a given system
On 2/14/08, Stephane Marchesin [EMAIL PROTECTED] wrote:
I don't know if it interferes, but I also can't see how your proposal deals
with this case. Can you provide more details? Just saying a BO has scanout
permission isn't sufficient either, since CRTC-output mappings are
important too
On 28 Nov 2007 06:19:39 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote:
Stephane Marchesin [EMAIL PROTECTED] writes:
I fail to see how this works with a lockless design. How do you ensure
the X
server doesn't change cliprects between the time it has written those in
the
shared ring
On 11/28/07, Keith Packard [EMAIL PROTECTED] wrote:
On Wed, 2007-11-28 at 00:52 +0100, Stephane Marchesin wrote:
The third case obviously will never require any kind of state
re-emitting.
Unless you run out of hardware contexts.
Well, in that case we (plan to) bang the state registers
On 11/28/07, Keith Whitwell [EMAIL PROTECTED] wrote:
In my ideal world, the entity which knows and cares about cliprects
should be the one that does the swapbuffers, or at least is in control
of the process. That entity is the X server.
Instead of tying ourselves into knots trying to
On 11/28/07, Keith Whitwell [EMAIL PROTECTED] wrote:
Stephane Marchesin wrote:
On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Stephane Marchesin [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] writes:
I fail to see
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
On 11/27/07, Kristian Høgsberg [EMAIL PROTECTED] wrote:
On Nov 27, 2007 11:48 AM, Stephane Marchesin
[EMAIL PROTECTED] wrote:
On 11/22/07, Kristian Høgsberg [EMAIL PROTECTED] wrote:
...
It's all delightfully simple, but I'm starting to reconsider whether
the lockless bullet point
On 11/27/07, Kristian Høgsberg [EMAIL PROTECTED] wrote:
Yeah - I'm trying to limit the scope of DRI2 so that we can have
redirected direct rendering and GLX1.4 in the tree sooner rather than
later (before the end of the year). Maybe the best way to do that is
to keep the lock around for now
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
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
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
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
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
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:
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
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
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
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
[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
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
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.
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
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
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.
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
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 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
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
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
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:
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
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
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
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
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)
1 - 100 of 162 matches
Mail list logo
