;> Well, usually we use { 0 } in mesa, try to grep and you will see. :-)
>> There is only 3 occurrences of { 0, }, but I think they are quite old.
>
> Of course, I'm not really against this ",", but I just want consistency
> with the other parts.
>
In C++ '{}&
Ilia Mirkin writes:
> mesa_texstore expects pixel data, not compressed data. For compressed
> textures, we want to just copy the bits in without any conversion.
>
Any reason we cannot use _mesa_store_compressed_*image for this instead
of rolling our own?
> Signed-off-by: Ilia Mirkin
> ---
> s
Dirk Thierbach writes:
>[...]
>> The stuff about overscan/etc are exposed as KMS properties (which in
>> turn appear in xrandr) and not specific to the BT869.
>
> The problem is that there's no good way to just say "I want this
> overscan" and then get a valid set of register values, because of
y: John F. Godfrey
> Signed-off-by: Ilia Mirkin
> ---
>
> I guess I didn't have to change the >= 0x11 checks, but seemed nicer for
> consistency.
Looks good to me,
Reviewed-by: Francisco Jerez
>
> src/mesa/drivers/dri/nouveau/nv10_context.c | 8 ---
this more like what you had in mind?
> Interesting that nv10/nv20 support different-bitness color/depth -- that
> requirement came back for nv30/nv40.
>
Looks good to me,
Reviewed-by: Francisco Jerez
Thanks.
> src/mesa/drivers/dri/nouveau/nouveau_context.c | 1 +
> src/mesa/
Ilia Mirkin writes:
> Fixes assertions when trying to attach textures to fbs with formats not
> supported by the render engines.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=73459
>
> Signed-off-by: Ilia Mirkin
> ---
Hi Ilia,
>
> In a perfect world I'd have separate callbacks for depth
Ilia Mirkin writes:
> This fixes issues where get_rt_format would see a 0 format because the
> nouveau_surface had not been properly initialized. Fixes crash on
> supertuxkart startup (which still fails due to out-of-vram issues).
>
> Signed-off-by: Ilia Mirkin
Thanks, pushed.
> src/mesa/dri
Pauli Nieminen writes:
> ARB_sampler_object is very simple software only extension to support.
> I want to make it mandator extension for Mesa drivers to allow meta
> module to use it.
>
> This patch add support for the extension to nouveau. It is completely
> untested search and replace patch. I
Marcin Slusarz writes:
> On Thu, May 03, 2012 at 03:15:51PM +0200, Francisco Jerez wrote:
>> Marcin Slusarz writes:
>>
>> > Port of commit ae45d7e6d8e6844cd4586c9ee97c21b257fa788f in xf86-video-ati.
>> >
>> > Fixes https://bugs.freedesktop.org/sho
Marcin Slusarz writes:
> Port of commit ae45d7e6d8e6844cd4586c9ee97c21b257fa788f in xf86-video-ati.
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=49351
>
> (Additionally, don't try to pageflip if user disabled it in xorg.conf.
> Currently this change is a no-op, because can_exchange retu
Viktor Novotný writes:
> Hi,
>
> thanks for feedback, I finally got to get through your comments - I hope it's
> OK now.
Hey, thanks, both patches pushed.
> BTW if you are going to test this, it seems to me that 784dd51198 have broken
> piglit's
> fbo-generatemipmap-formats and s3tc-teximage
Lucas Stach writes:
> Am Montag, den 30.04.2012, 20:08 +0200 schrieb Francisco Jerez:
>> Lucas Stach writes:
>>[...]
>> > + /* only advertise supported texture formats */
>> > + memset(&ctx->TextureFormatSupported, 0,
>> > +
Lucas Stach writes:
> Fixes an assertion seen by users.
>
> Signed-off-by: Lucas Stach
> Tested-by: JohnDoe_71Rus on irc
> ---
> src/mesa/drivers/dri/nouveau/nouveau_context.c |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c
>
Ben Skeggs writes:
> On Fri, 2012-04-06 at 17:40 +0200, Viktor Novotný wrote:
>> ---
>> Hi,
> Hey Viktor!
>
> Thanks for the patch!
>
Hey,
>>
>> this is still WIP, but already passes piglit's s3tc-teximage,
>> s3tc-texsubimage and fbo-generatemipmap-formats(s3tc tests)
>> and even Wolfenstein:
Patrick Baggett writes:
> Hi all!
>
Hi,
> I read that the older Nvidia hardware (maybe < GF8) is in a different driver
> and no longer maintained. Is that the case?
Yes and no. If you're talking about the 3d drivers, I've done pretty
much nothing as maintainer of the nv04-nv20 driver in the la
emory limit of this kind, both when you have a <32MB card with small
enough render buffers or a >32MB card with huge render buffers that
would otherwise hit the same bug.
> This should fix https://bugs.freedesktop.org/show_bug.cgi?id=42384
>
> Signed-off-by: Marcin Slusarz
> Cc:
Francisco Jerez writes:
> Mario Kleiner writes:
>
>> On 09/09/2011 11:14 PM, Francisco Jerez wrote:
>>> Mario Kleiner writes:
>>>
>>>>[...]
>>>> Is the blip operation started at leading edge of the vblank interval?
>>>>
Mario Kleiner writes:
> On 09/09/2011 11:14 PM, Francisco Jerez wrote:
>> Mario Kleiner writes:
>>
>>>[...]
>>> But the current implementation under a compositor is not great. You
>>> get glxgears reporting that "vsync is on and the redraw rate
Mario Kleiner writes:
> On 09/09/2011 11:05 PM, Francisco Jerez wrote:
>> Mario Kleiner writes:
>>
>>>[...]
>>>
>>> Hi, thanks for the comments.
>>
>> Thank you for looking into this :)
>>>
>
> Sorry for the late reply.
Mario Kleiner writes:
> On Sep 8, 2011, at 1:00 AM, Francisco Jerez wrote:
>
> Thanks for your review. See comments below.
>
>> Mario Kleiner writes:
>>
>>> Treats vblank event scheduling for the non-pageflip swap
>>> case correctly. Allows vblank c
Mario Kleiner writes:
> On Sep 8, 2011, at 12:45 AM, Francisco Jerez wrote:
>
>> Mario Kleiner writes:
>>
>>> Requests pageflip completion events from the kernel.
>>> Implements pageflip completion handler to finalize
>>> and timestamp swaps.
>
Mario Kleiner writes:
> Treats vblank event scheduling for the non-pageflip swap
> case correctly. Allows vblank controlled swaps for redirected
> windows. Fixes some corner-cases in OML_sync_control scheduling
> when divisor and remainder parameters are used.
>
> Signed-off-by: Mario Kleiner
>
Mario Kleiner writes:
> Requests pageflip completion events from the kernel.
> Implements pageflip completion handler to finalize
> and timestamp swaps.
>
> Completion handler includes a consistency check, and
> disambiguation if multiple crtc's are involved in a
> pageflip (e.g., clone mode, ext
Pekka Paalanen writes:
> On Mon, 18 Jul 2011 08:09:17 -0600
> Brian Paul wrote:
>
>> On 07/15/2011 02:59 PM, Pekka Paalanen wrote:
>> > On Fri, 15 Jul 2011 12:22:41 -0600
>> > Brian Paul wrote:
>> >
>> >> On 07/15/2011 10:07 AM, Dave Airlie wrote:
>> >>> On Fri, Jul 15, 2011 at 4:10 AM, Brian
>
Emil Velikov writes:
> Fix the following message
> 'ERROR: trailing statements should be on next line'
>
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 20 +++--
> drivers/gpu/drm/nouveau/nouveau_mem.c | 12 --
> drivers/gpu/drm/nouveau/nouveau
Marcin Slusarz writes:
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35135
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> IP: [] nv04_dfp_restore+0x7f/0xd0 [nouveau]
> (...)
> Call Trace:
> [] nv04_display_destroy+0xa8/0x140 [nouveau]
> [] nouveau_unload+0x2a/0x16
Marcin Slusarz writes:
> On Tue, Mar 08, 2011 at 05:22:52PM +0100, Francisco Jerez wrote:
>> Marcin Slusarz writes:
>>
>> > On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote:
>> >> Marcin Slusarz writes:
>> >>
>> >>
Marcin Slusarz writes:
> On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote:
>> Marcin Slusarz writes:
>>
>> > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote:
>> >> On Mon, 2011-03-07 at 18:18 +, Maarten Maathuis wrote:
&g
Marcin Slusarz writes:
> On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote:
>> On Mon, 2011-03-07 at 18:18 +, Maarten Maathuis wrote:
>> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz
>> > wrote:
>> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote:
>> > >> Combi
Edgar Fuß writes:
> So my problem continues.
>
>> They're based on what the nvidia proprietary driver itself refuses to do,
> I see, thanks.
>
>> though, I'm not 100% sure that I had nv44 in my sample when I made that
>> change.
> Looks like it limits to 155M in the nv44 case too, so your change
Edgar Fuß writes:
> I'm curious what the TDMS bandwidth limit values in get_tmds_link_bandwidth()
> are based on.
They're based on what the nvidia proprietary driver itself refuses to
do, though, I'm not 100% sure that I had nv44 in my sample when I made
that change.
> We're using chipset == 4
Marcin Slusarz writes:
> add new relocation flag which allows to halving number of relocation
> entries on >= nv50 cards
>
I suspect that this change is unnecessary. If you're actually seeing a
performance improvement (I guess you are?), it's very likely to be
masking the actual root of the probl
Martin Peres writes:
> Hi,
>
> I'm still working on getting the reclocking work done right. There are
> several parts I identify:
> - Pausing PFIFO (with its caches), pause PGRAPH and wait for idle
> - Stop some PLL (I guess it is more, physically disconnect them from
> the engines) using the 0xc
Marcin Slusarz writes:
> ---
> nouveau/nouveau_pushbuf.h | 17 -
> 1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/nouveau/nouveau_pushbuf.h b/nouveau/nouveau_pushbuf.h
> index 2a98789..70d0f28 100644
> --- a/nouveau/nouveau_pushbuf.h
> +++ b/nouveau/nouveau_
Lucas Stach writes:
> The attached patch deletes some defaults which are not really defaults
> and changes the standard values to calculation neutral ones.
>
> I discussed the matter with mupuf on irc and we agreed on this solution.
>
Hi, I'm attaching the BIOS dump from an nv4a card that needs t
Mario Kleiner writes:
> On 12/29/2010 10:44 AM, Ben Skeggs wrote:
>> On Wed, 2010-12-29 at 10:37 +0100, Maarten Maathuis wrote:
>>[...]
>>>
>>> In my infinite wisdom i swapped the vertical and horizontal regs,
>>> these are the right ones:
>>>
>>> 0x616340: CRTC0 horizontal scanline (lower 16 bit
riginal one for all practical purposes.
> Also looking at include/drm/nouveau_drm.h, I see some inconsistant
> type for channel in ioctls structures ?
>
Right, explicitly sized integers are usually the preferred choice in the
IOCTL API.
> 2010/12/25 Francisco Jerez :
>> Michel H
Michel Hermier writes:
> Second try ^^ I'm not used at all at preparing patch for kernel
Thanks. I've pushed it with a couple of minor fixes.
pgp0EnbcRf0wZ.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://l
Xavier Chantry writes:
> ---
> src/nv04_exa.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/src/nv04_exa.c b/src/nv04_exa.c
> index 2760d4b..bc20ca3 100644
> --- a/src/nv04_exa.c
> +++ b/src/nv04_exa.c
> @@ -148,7 +148,6 @@ NV04EXASolid (PixmapPtr pPixmap, int x1
Michel Hermier writes:
> Hi,
> While hacking libdrm I triggered a kernel oups due to a non checked
> argument from user land.
> In nouveau_ioctl_notifier_alloc, nouveau_channel_get is invoked, but
> it doesn't validate the na->channel input argument. The attached patch
> validates the channel ind
Lucas Stach writes:
> Hi all,
>
> I want to bring up this issue again on the mailing list, since it got
> lost in some irc chat a few days ago.
>
> Deadwood came to the channel and noted that
> 25ee1f0e25195729f28b15f33d74db9ec6afd696 removes support for
> NOUVEAU_GEM_CPU_PREP_NOBLOCK in the kern
Roger writes:
> I think I've found the problem.
>
> # echo "option nouveau noagp=1" >> /etc/modprobe.d/nouveau.conf
>
> So far, it looks like things have stopped freezing.
>
>
> Another tip for people trouble shooting freezes with nouveau:
>
> # echo "blacklist nouveau" >> /etc/modprobe.d/blackli
Xavier Chantry writes:
> If nvfx_framebuffer prepare and validate were called successively with
> fb->zsbuf not NULL and then NULL, nvfx->hw_zeta would contain garbage and
> this would cause failures in nvfx_framebuffer_relocate/OUT_RELOC(hw_zeta).
>
> This was triggered by piglit/texwrap 2D GL_D
Viktor Novotný writes:
> From: Viktor Novotný
>
> Signed-off-by: Viktor Novotný
> ---
> Hi,
>
> since the switch to rnn headers was pushed(thank you, curro), here is a patch
> that I inteded to submit first, but somehow ended making the switch.
> It is just a small clean up.
>
> Regards
>
Anders Eriksson writes:
> I recently discovered $subject in my xorg logs. Any idea what it means and
> how
> to get rid of it? Google suggests changing BIOS parameters but my bios has no
> agp related options (this is a P-II machine from ca 2000).
>
Can you boot with "drm.debug=3 log_buf_len=5
Francisco Jerez writes:
> Viktor Novotný writes:
>>
>> Hi,
>>
>> following patches make the dri driver use rules-ng-ng(rnn) generated
>> register definitions instead of renouveau generated ones.
>> First set of 5 patches is for mesa repository, sec
Viktor Novotný writes:
>
> Hi,
>
> following patches make the dri driver use rules-ng-ng(rnn) generated register
> definitions instead of renouveau generated ones.
> First set of 5 patches is for mesa repository, second set of 4 patches is for
> rnn and consists of changes ported from renouveau.
Marcin Slusarz writes:
> On Sun, Nov 14, 2010 at 10:18:10AM +, Paolo Milani wrote:
>> --- Dom 14/11/10, Marcin Slusarz wrote:
>> > It should work. Please post your kernel logs from a failed
>> > boot (they are somewhere in /var/log).
>>
>> when boot fails (and system crashes), it write noth
Lucas Stach writes:
> Attached a trivial fix for mesa/nvfx to shut up warnings about unknown
> pipe caps.
>
Thanks, pushed.
> -- Lucas
pgpCytYRefZa2.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.fr
Viktor Novotný writes:
> From: Viktor Novotný
>
> Hi,
>
> following patches make the dri driver use rules-ng-ng(rnn) generated
> register definitions instead of renouveau generated ones. First set
> of 5 patches is for mesa repository, second set of 4 patches is for
> rnn and consists of change
Delan Azabani writes:
> The latest git version of freedesktop/mesa/mesa (building for gallium
> driver according to nouveau wiki/GalliumHowto) does not compile. The
> messages shown are:
>
> nouveau_screen.c: In function ‘nouveau_screen_init’:
> nouveau_screen.c:239: warning: passing argument 4 o
Jesse Adkins writes:
> Signed-off-by: Jesse Adkins
> ---
> src/nv_const.h |2 --
> src/nv_include.h |2 --
> 2 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/src/nv_const.h b/src/nv_const.h
> index 0df25b6..20984ae 100644
> --- a/src/nv_const.h
> +++ b/src/nv_const.h
Stephan Raue writes:
> Hi all,
>
> running a NV46 card with latest git from
> http://cgit.freedesktop.org/nouveau/linux-2.6/, mesa, libdrm and
> xf86-video-nouveau fails with an kernel oops. let me know if you need
> more informations.
>
> [ 11.127274] BUG: unable to handle kernel NULL pointer
Lucas Stach writes:
> Oh, yes. It seems my email client had some good lunch with the tabs.
>
> I added the patch as an attachment. Hope it works this time.
>
> -- Lucas
>
Thanks, pushed.
> Am Montag, den 18.10.2010, 15:47 +0200 schrieb Francisco Jerez:
>> Lucas Stac
Lucas Stach writes:
> Nouveau sets GART size to 64MiB for all cards before nv50, but nv40 has
> enough RAMIN space to support 512MiB GART size. This patch fixes this
> value to make use of this hardware capability.
>
> Signed-off-by: Lucas Stach
> ---
The patch doesn't seem to apply, I guess it'
Grzesiek Sójka writes:
> Hi there,
>
> I have a question. I have a dual DVI NV34 adapter and at the moment
> the Xserver works fine. Two separated displays configured as follows:
>
> Section "Monitor"
> Identifier "Monitor0"
> Option "Primary""True"
> EndSection
> Section "Mon
Grzesiek Sójka writes:
> On 10/05/10 14:55, Francisco Jerez wrote:
>>> PS. I'm afraid that my system is not very stable when the AGP support
>>> is turned on both using the nouveau kernel source tree and the PLD
>>> patched 2.6.35-5 version with an extra amd
Grzesiek Sójka writes:
> On 10/02/10 15:31, Francisco Jerez wrote:
>> Ah, I think you're hitting the bandwidth limitation of the nv34
>> integrated TMDS transmitter. The attached patch should help with the
>> console modesetting problem, but you'll still need t
Grzesiek Sójka writes:
> On 10/01/10 01:29, Francisco Jerez wrote:
>> Grzesiek Sójka writes:
>>
>>> On 09/30/10 18:05, Francisco Jerez wrote:
>>>> Does the following command help?
>>>> $ xrandr --output DVI-I-2 --set "scaling mode" &qu
Grzesiek Sójka writes:
> On 09/30/10 18:05, Francisco Jerez wrote:
>> Does the following command help?
>> $ xrandr --output DVI-I-2 --set "scaling mode" "None"
> Yes! Now I have:
> xrandr --output DVI-I-1 --set "scaling mode" "None&quo
Grzesiek Sójka writes:
> I did download new sources and applied the amd-agp patch but no change.
> I get the some problems. Here is the dmesg without modeset:
> http://yen.ipipan.waw.pl/~gs159090/tmp/txt.gz
> Then I added following modeline to the file drm_edid_modes.h
>
> /* 1600x1...@50hz */
>
Pekka Paalanen writes:
> On Tue, 28 Sep 2010 18:17:25 +0200
> Grzesiek Sójka wrote:
>
>> I'm completely lost at the moment so let me start from the
>> beginning. First thing is that everything works fine with Nvidia
>> binary drivers, which means that hardware is rather OK. After
>> loading of t
Grzesiek Sójka writes:
> Hi there,
>
> Im using ASUS A7M266-D mainboard based on AMD768 chipset and Nvidia
> GeForce FX5200 dual DVI graphics adapter. I'm forced to switch from
> binary Nvidia drivers to nouveau but the problem is that nouveau.ko
> would not load with AGP support turned on.
au patches if you need it.
> Thanks,
>
> - Chris.
>
>
> From: Chris Ball
> Subject: [PATCH] drm/nouveau/kms: Avoid a hang entering KDB with VT accel on.
>
> Francisco Jerez advises that pre-nv20 cards would hang if we entered
> kdb with accel on and IRQs disabled, so
Marcin Slusarz writes:
> On Wed, Aug 25, 2010 at 06:15:53PM +0200, Francisco Jerez wrote:
>> Dragos Delcea writes:
>>
>> > Hi,
>> >
>> > I noticed that loading nouveau doesn't load fbcon automatically; and
>> > without fbcon, when loa
Marcin Slusarz writes:
> handle very early errors in pipe_screen creation (failure of
> nouveau_screen_init in nv50_screen_create)
> ---
> src/gallium/drivers/nouveau/nouveau_screen.c |3 ++-
> .../winsys/nouveau/drm/nouveau_drm_winsys.c|3 ++-
> 2 files changed, 4 insertio
Dragos Delcea writes:
> Hi,
>
> I noticed that loading nouveau doesn't load fbcon automatically; and without
> fbcon, when loading nouveau the
> console turns blank. I spent a few good hours until I was able to figure out
> that I had to manually modprobe
> fbcon to get the console back after l
Chris Ball writes:
> Hi,
>
> Here's a patch to add support for KMS debugging to Nouveau, along the
> style of the previous patches for Intel¹ and Radeon². I'm only able
> to test on nv50 here, so a test on nv04 would be much appreciated,
> and I've published instructions on how to test here³. T
Kārlis Repsons writes:
> On Monday 02 August 2010 14:07:19 Francisco Jerez wrote:
>> Kārlis Repsons writes:
>> > On Monday 02 August 2010 11:33:14 Francisco Jerez wrote:
>> >> > But now I'm at the "next level of trouble":
>> >> > 1.
Marcin Slusarz writes:
> On Fri, Jul 30, 2010 at 05:04:32PM +0200, Dan Carpenter wrote:
>> nuveau_load() just returned directly if there was an error instead of
>>
> ^^ typo
>
>> releasing resources.
yaiba.kurog...@interia.pl writes:
> Hi. I have a problem with current kernel 2.6.35 and nouveau module
> compiled from git (today).From xorg.0.log I got information that no
> output was found.And here is some nasty kernel logs:
>
> [...]
> What is going on?
>
Your BIOS lacks some information we n
Kārlis Repsons writes:
> On Monday 02 August 2010 11:33:14 Francisco Jerez wrote:
>> > But now I'm at the "next level of trouble":
>> > 1. when two Xservers are running, after some minutes video output of the
>> > primary card ceases (loggin
Kārlis Repsons writes:
> On Sunday 01 August 2010 10:30:02 Marcin Slusarz wrote:
>> On Sun, Aug 01, 2010 at 08:59:28AM +, Kārlis Repsons wrote:
>> > On Sunday 01 August 2010 08:41:04 Pekka Paalanen wrote:
>> > > On Sat, 31 Jul 2010 22:08:23 +
>> > >
>> > > Kārlis Repsons wrote:
>> > > >
Kārlis Repsons writes:
> On Sunday 01 August 2010 08:41:04 Pekka Paalanen wrote:
>> On Sat, 31 Jul 2010 22:08:23 +
>>
>> Kārlis Repsons wrote:
>> > Hi list,
>> > my thanks to developers of nouveau first: I wonder how you put it
>> > together this far, where there's quite enough to appreciat
Tomas Carnecky writes:
> The control flow was:
>
> if (!y) {
> ppix = ...
> }
>
> if (y) {
> ...
> } else if (x) {
> use ppix for something
> } else {
> use ppix for something
> }
>
> Merge the if(!y) block with the two else branches. This avoids
> a false-positive in the clang static ana
Marcin Slusarz writes:
> On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote:
>> On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
>> > Hi
>> >
>> > Patch "drm/nouveau: use drm_mm in preference to custom code doing the same
>> > thing"
>> > in nouveau tree introduced new deadlock
The INIT_COMPUTE_MEM opcode was one of the missing pieces for pre-nv40
card cold-booting (i.e. multicard), it's supposed to detect the right
setting for several of the memory config variables a given GPU supports
(memory type, bus width, amount of installed RAM chips).
The implementation I'm attac
d (it works for
them because they don't use MMIO), OTOH the blob leaves FW untouched.
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/nouveau/nouveau_bios.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/no
Hi,
Adrian Popa writes:
> Hello,
>
> I've checked and i have a GeForce 4 MX 440, and i do see a TV-1 in xrandr but
> I didn't manage to configure it
> with xrandr.
>
> I've looked over [2] and by using xrandr --output TV-1 --right-of VGA-1 i
> managed to extend my desktop to my
> TV. Also, i s
Adrian Popa writes:
> Hello everyone,
>
> First of all - congratulations on the success of your project. It was
> about time the community did something about the nvidia drivers! :)
>
> Now, I'm still experimenting with nouveau and I have enabled it on a
> test system that has a rather old Nvidia
Renato Caldas writes:
> Hello,
>
> Since I've updated to F13 I keep getting blank screens at "cold" boot
> with this card:
> 00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce
> 6150] (rev a2)
>
> When I say "cold" boot I mean the first couple of times I turn on my
> computer in
Rico Tzschichholz writes:
> A patch is attached to fix this problem.
>
> It removes the deprecated reference to README.NV1 and properly adds
> src/nv_rop.h
>
Thanks, pushed.
> Thanks,
> Rico Tzschichholz
>
> ___
> Nouveau mailing list
> Nouveau@lists.f
Previously we were filling it the same as "placements", but in some
cases there're valid alternatives that we were ignoring completely.
Keeping a back-up memory type helps on several low-mem situations.
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/nouveau/nouve
e
have to move something out of it.
Additionally, allowing VRAM->system behaves badly under heavy memory
pressure because once we run out of TT, stuff starts to be moved back
and forth between VRAM and system, and the TT contents are hardly
renewed.
Signed-off-by: Francisco Jerez
---
driver
Luca Barbieri writes:
> On Mon, Mar 1, 2010 at 2:34 AM, Francisco Jerez wrote:
>> Luca Barbieri writes:
>>
>>> NV10TCL defines the vertex buffer registers both as arrays and as
>>> individual named registers.
>>>
>>> This causes duplicat
AU_BO_VRAM)))
> + nvbo->flags |= (flags & (NOUVEAU_BO_GART | NOUVEAU_BO_VRAM));
> +
> rpbbo = nouveau_bo_emit_buffer(chan, reloc_bo);
> if (!rpbbo)
> return -ENOMEM;
Looks good to me:
Acked-by: Francisco Jerez
pgpX4oYFsUZ9k.pgp
Description: PGP sig
Luca Barbieri writes:
> NV10TCL defines the vertex buffer registers both as arrays and as
> individual named registers.
>
> This causes duplicate register definitions and the individual registers
> are not used either by the DDX or by the Mesa driver.
>
> Francisco Jerez sa
Hi,
Frank Schaefer writes:
> Hi,
>
> today I tested kernel 2.6.33 and it seems that nouveau doesn't detect
> the DVI-connector of my GeForce 6150SE (Asus M2N-VM DH).
> The screen turns black during boot-process immediately after the "[drm]
> nouveau ..." messages appeared.
>
It looks like your I
Luca Barbieri writes:
> Found by sparse.
>
> Signed-off-by: Luca Barbieri
> ---
> drivers/gpu/drm/nouveau/nouveau_gem.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 03d8935
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/nouveau/nouveau_gem.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ec6da5c..173d5e2 100644
--- a/drivers/gpu/drm/nouveau
If you're especially unlucky BOs would move around and their kmaps
would end up pointing to something else in GART, then ioctl_pushbuf()
would use the kmaps again corrupting textures or other pushbufs (the
most noticeable symptom was a PFIFO_DMA_PUSHER from time to time).
Signed-off-by: Fran
Marcin Slusarz writes:
> On Mon, Feb 15, 2010 at 03:40:56PM +0300, Dan Carpenter wrote:
>> This is the results from:
>> make C=1 CHECK="/path/to/smatch -p=kernel" bzImage modules | tee
>> warns.txt
>> grep -w overflow warns.txt | uniq -f 3 | tee err-list
>>
>> I hacked on the buffer ove
Marcin Kościelnicki writes:
> ---
> src/nv_driver.c | 32 +---
> 1 files changed, 1 insertions(+), 31 deletions(-)
>
> diff --git a/src/nv_driver.c b/src/nv_driver.c
> index 248a151..9606d97 100644
> --- a/src/nv_driver.c
> +++ b/src/nv_driver.c
> @@ -315,8 +315,6 @
This reverts commit 98c9e4edb58374f18249e5c9c53b392fb8b4a1d1. AFAIK
it's no longer needed.
Signed-off-by: Francisco Jerez
---
src/drmmode_display.c |3 ---
src/nv_driver.c |2 --
src/nv_type.h |1 -
3 files changed, 0 insertions(+), 6 deletions(-)
diff --git
For a long time the gallium pipe drivers for nvidia fixed function cards
(nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and
godforsaken -- especially nv0x and nv1x had seen almost no progress
since their creation.
They've recently grown a classic mesa driver which implements man
Luca Barbieri writes:
>> Sounds like premature optimization to me. I'm just stating my personal
>> view here, but I have a feeling a patch with 60% of lines could do very
>> well the same for most realistic cases.
>
> Perhaps, but really, the only thing you would probably save by using
> spinlock
Luca Barbieri writes:
>> How often do we expect cross-channel sync to kick in? Maybe 2-3 times
>> per frame? I suspect contentions will be rare enough to make spinlocks
>> as fast as atomics for all real-life cases, and they don't have such a
>> high maintainability cost. What do you guys think?
Luca Barbieri writes:
> This patch adds code to allocate semaphores in a dynamic way using
> an algorithm with a lockless fast path.
>
> 1. Semaphore BOs
>
> Semaphore BOs are BOs containing semaphores. Each is 4KB large and
> contains 1024 4-byte semaphores. They are pinned.
>
> Semaphore BOs ar
Luca Barbieri writes:
> nouveau_bo_wait will make the GPU channel wait for fence if possible,
> otherwise falling back to waiting with the CPU using ttm_bo_wait.
>
> The nouveau_fence_sync function currently returns -ENOSYS, and is
> the focus of the next patch.
>
> Signed-off-by: Luca Barbieri
Luca Barbieri writes:
> Please apply or state objections to this patch.
>
> Thanks.
Thanks, pushed.
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
pgpBVw1pLElgT.pgp
Description: P
1 - 100 of 226 matches
Mail list logo
