[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #229 from Francisco Pina Martins --- Just wanted to add that after I started using linux-3.14.x my issues with DPM are gone when using my Mobility Radeon 3650 (rv635/M86). Everything is just working fine. Once again, thanks for all the hard work. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/b008932e/attachment.html>
[PATCH 2/2] drm/tegra: Enable HDMI_5V_CON regulator
On Sat, May 17, 2014 at 11:21:21AM -0700, Dylan Reid wrote: > The DDC bus uses this for it's supply, enable it so EDID can be read. > This eliminates I2C read timeouts on Venice2 and EDID can be verified > with i2cdump. > > Signed-off-by: Dylan Reid > --- > drivers/gpu/drm/tegra/hdmi.c | 15 +++ > 1 file changed, 15 insertions(+) Like I said in reply to 1/2, this should be fixed by: 0d6696438d2c drm/tegra: hdmi - Add connector supply support Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/1b4883bf/attachment.sig>
[PATCH 1/2] ARM: tegra: Mark Tegra124 HDMI compatible with Tegra114
On Sat, May 17, 2014 at 11:21:20AM -0700, Dylan Reid wrote: > The HDMI driver that handles Tegra114 can handle Tegra124 as well, > mark Tegra124 as compatible. This makes HDMI output work on Venice2. > > Signed-off-by: Dylan Reid > --- > arch/arm/boot/dts/tegra124.dtsi | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) These patches don't seem to be based on linux-next. There are a couple of patches in linux-next (queued for 3.16) that should fix these, in particular: 4b9701e02b3b drm/tegra: hdmi - Add Tegra124 support 0d6696438d2c drm/tegra: hdmi - Add connector supply support Could you try a recent linux-next to see if that fixes the issues you are seeing? Note that Tegra doesn't boot on linux-next from the last few days because of some cgroup regressions, but a fix was merged and should be in Monday's linux-next, so unless new regressions are introduced that would be a good candidate to test. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/9f5c0b36/attachment.sig>
[Bug 66880] R600_DEBUG=sb hangs system after playing xonotic, spring
https://bugs.freedesktop.org/show_bug.cgi?id=66880 --- Comment #1 from David Heidelberger (okias) --- these days is R600_DEBUG=sb default, could you retest? Also 3.12 should be stable enough :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/008358cd/attachment.html>
[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
On Thu, May 15, 2014 at 05:10:16PM +0530, Ajay kumar wrote: > On Thu, May 15, 2014 at 1:43 PM, Thierry Reding > wrote: [...] > > I still don't see how controlling the enable GPIO from the panel will be > > in any way better, or different for that matter, from simply enabling > > the backlight and let the backlight driver handle the enable GPIO. Have > > you tried to do that and found that it doesn't work? > It works, but it gives me glitch when I try to configure video. > This is because backlight_on(pwm-backlight) happens much before > I configure video(inside drm), and while configuring video there would > be a glitch, > and that glitch would be visible to the user since backlight is already > enabled. Okay, so this means that your backlight is turned on too early. Instead of working around that problem by moving control of the backlight enable GPIO from the backlight driver into the panel driver, the correct way to fix it is to make sure the backlight stays off until video is ready. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/8e90171a/attachment.sig>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #31 from vincent --- No luck with libdrm-2.4.48 either (roughly when hawaii pciid was added). I'm using llvm bdbcffa4af01cda413690276d8e81b3ab5cea9b6, mesa 469b42ee21d6bc530200c76cb0e73b0b461ab6e8 (+ MD patch) and kernel 8d0a2215931f1ffd77aef65cae2c0becc3f5d560 with radeon.dpm=0 and radeon.runpm=0. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/4edb41ef/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #30 from vincent --- With llvm at bdbcffa4af01cda413690276d8e81b3ab5cea9b6 (R600/SI: Add processor type for Hawaii) gpu still hangs. The remaining component I didn't test is libdrm, is it likely to change something ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/8058edb9/attachment-0001.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 --- Comment #6 from David Heidelberger (okias) --- Unigine Heaven 4.0 tested on 6550D with and without R600_DEBUG=hyperz. I didn't noticed performance boost, but no glitches, crashes or anything. Worked well. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/90f22c5b/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #29 from vincent --- piglit/bin/glinfo and gbm platforms also hang the gpu. Sometimes when I run ./egltri_screen I have a shaded triangle, that doesnt move, it looks like the first frame is correctly processed. I'm trying to check if llvm may have introduced a regression, although it doesnt seem likely as the isa is shared with bonnaire. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/ea423b94/attachment.html>
[Bug 75917] backlight switches of when starting X since kernel-3.13
https://bugs.freedesktop.org/show_bug.cgi?id=75917 nl at gnuffy.net changed: What|Removed |Added Severity|normal |blocker Priority|medium |high --- Comment #2 from nl at gnuffy.net --- As the problem still exists and prevents me from using any kernel 3.13+ I changed the priority of this bug. When I did the git bisect I hoped it would help to find a solution soon. Is there anything I can do to help fixing this problem? I don't want to get stuck on kernel 3.12.20 :( -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/523021cc/attachment.html>
Question about radeon runpm dmesg logs
Hello, I have laptop with hybrid graphics solution (intel+radeon). Radeon runpm option working (when using DRI_PRIME), however every time when radeon card is powering on kernel write lot of lines to dmesg: [ 1075.055132] ACPI: \_SB_.PCI0.PEG0: ACPI_NOTIFY_BUS_CHECK event [ 1075.055164] ACPI: \_SB_.PCI0.PEG0: Bus check in hotplug_event() [ 1075.064446] switching from power state: [ 1075.064449] ui class: none [ 1075.064450] internal class: boot [ 1075.064451] caps: [ 1075.064452] uvdvclk: 0 dclk: 0 [ 1075.064453] power level 0sclk: 3 mclk: 14900 vddc: 900 vddci: 0 pcie gen: 3 [ 1075.064454] status: c b [ 1075.064455] switching to power state: [ 1075.064455] ui class: performance [ 1075.064456] internal class: none [ 1075.064457] caps: [ 1075.064457] uvdvclk: 0 dclk: 0 [ 1075.064458] power level 0sclk: 3 mclk: 15000 vddc: 800 vddci: 0 pcie gen: 3 [ 1075.064459] power level 1sclk: 4 mclk: 10 vddc: 875 vddci: 0 pcie gen: 3 [ 1075.064460] power level 2sclk: 75000 mclk: 10 vddc: 1025 vddci: 0 pcie gen: 3 [ 1075.064461] power level 3sclk: 9 mclk: 10 vddc: 1025 vddci: 0 pcie gen: 3 [ 1075.064461] power level 4sclk: 97500 mclk: 10 vddc: 1075 vddci: 0 pcie gen: 3 [ 1075.064462] status: r [ 1075.065584] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e [ 1075.065586] [drm] PCIE gen 3 link speeds already enabled [ 1075.067609] [drm] PCIE GART of 1024M enabled (table at 0x0004). [ 1075.067722] radeon :01:00.0: WB enabled [ 1075.067724] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x880036d8cc00 [ 1075.067725] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x880036d8cc04 [ 1075.067726] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x880036d8cc08 [ 1075.067727] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x880036d8cc0c [ 1075.067728] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x880036d8cc10 [ 1075.209399] [drm] ring test on 0 succeeded in 2 usecs [ 1075.209403] [drm] ring test on 1 succeeded in 1 usecs [ 1075.209406] [drm] ring test on 2 succeeded in 1 usecs [ 1075.209464] [drm] ring test on 3 succeeded in 2 usecs [ 1075.209470] [drm] ring test on 4 succeeded in 1 usecs [ 1075.209528] [drm] ib test on ring 0 succeeded in 0 usecs [ 1075.209577] [drm] ib test on ring 1 succeeded in 0 usecs [ 1075.209621] [drm] ib test on ring 2 succeeded in 0 usecs [ 1075.209646] [drm] ib test on ring 3 succeeded in 0 usecs [ 1075.209663] [drm] ib test on ring 4 succeeded in 0 usecs And when radeon card is automatically powered off by runpm in dmesg I see these lines: [ 1081.923248] ACPI: \_SB_.PCI0.PEG0: ACPI_NOTIFY_BUS_CHECK event [ 1081.923267] ACPI: \_SB_.PCI0.PEG0: Bus check in hotplug_event() Is it OK? Are there any errors? For me lines marked with drm and radeon strings look like test/verbose/debug info. But I really do not know what that ACPI lines are and what it means. It is something important? I just want to be sure if there are some errors or not - as seeing couple of lines every time when card is turned on does not look like pretty. -- Pali Roh?r pali.rohar at gmail.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/10a43631/attachment.sig>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #28 from vincent --- Created attachment 99246 --> https://bugs.freedesktop.org/attachment.cgi?id=99246&action=edit Dmesg with kernel 32f79a8 radeon.dpm/runpm = 0 It doesnt work with egltri_screen (or eglgears_screen FWIW) I have attached dmesg. It looks like disabling dpm and runpm generates a more complete dmesg log. What does "sa_manager is not empty, clearing anyway" mean ? Can it create gpu lock up ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/070ea81a/attachment.html>
[PATCH 1/2] ARM: tegra: Mark Tegra124 HDMI compatible with Tegra114
On Sat, May 17, 2014 at 2:33 PM, Thierry Reding wrote: > On Sat, May 17, 2014 at 11:21:20AM -0700, Dylan Reid wrote: >> The HDMI driver that handles Tegra114 can handle Tegra124 as well, >> mark Tegra124 as compatible. This makes HDMI output work on Venice2. >> >> Signed-off-by: Dylan Reid >> --- >> arch/arm/boot/dts/tegra124.dtsi | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > These patches don't seem to be based on linux-next. There are a couple > of patches in linux-next (queued for 3.16) that should fix these, in > particular: > > 4b9701e02b3b drm/tegra: hdmi - Add Tegra124 support > 0d6696438d2c drm/tegra: hdmi - Add connector supply support > > Could you try a recent linux-next to see if that fixes the issues you > are seeing? Note that Tegra doesn't boot on linux-next from the last few > days because of some cgroup regressions, but a fix was merged and should > be in Monday's linux-next, so unless new regressions are introduced that > would be a good candidate to test. Those look like they'll do the trick. I'll give it a try on Monday. Thanks Thierry. > > Thierry
[Bug 76321] Incorrect hwmon temperature when radeon card is turned off
https://bugzilla.kernel.org/show_bug.cgi?id=76321 --- Comment #4 from Pali Roh?r --- With v2 patch now sensors does not report any error (when card is turned off): $ sensors radeon-pci-0100 Adapter: PCI adapter temp1:N/A (crit = +120.0?C, hyst = +90.0?C) This looks ok. And for power_dpm_state & power_dpm_force_performance_level: I understand that it cannot be changed when card is turned off (I see that it also disappear from PCI bus space), but I would like to see option to set "initial" dpm state/level which will be used when card is turned om again. This can be usefull for scripts which setting powersave options depending on hostplugging AC adapter. What do you think about using same sysfs entries for it? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #19 from farmboy0+freedesktop at googlemail.com --- Created attachment 99236 --> https://bugs.freedesktop.org/attachment.cgi?id=99236&action=edit antichamber log with r600_debug -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/ff1c8d59/attachment-0001.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #18 from Tom Stellard --- (In reply to comment #14) > The v3 patch doesnt fix Antichamber's crash to desktop. > But with this patch it actually shows the VGPR messages: > With the patch applied can you run the game with R600_DEBUG=ps,vs,gs and post the output? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/70153ca3/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #17 from Tom Stellard --- (In reply to comment #15) > Tesseract does still crash with si-spill-fixes-v4 if I set "Shadow > resolution" to "Ultra" or "Global Illumination" to "High" or "Morphological > AA" to "Ultra". Have you tested with the patch attached to this bug? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/70320e02/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #17 from smoki --- Actually AirStrike3D is also fixed by not exposing XRGB :). I didn't mention that game also needs to be running under MESA_EXTENSION_MAX_YEAR=2003 env ;). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/427300c1/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #16 from darkbasic --- If someone is interested here is my rebased si-spill-fixes-v4: https://github.com/darkbasic/llvm/tree/master-si-spill-fixes-v4 I will try to rebase it from time to time, you cal also find the matching compiler-rt, clang and clang-tools-extra: https://github.com/darkbasic -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/5faee227/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #16 from smoki --- Disabling XRGB it in following files fixes an issue in supertuxkart non FBO case :) src/gallium/state_trackers/dri/common/dri_screen.c src/mesa/drivers/dri/radeon/radeon_screen.c But this is another problem, unsolvable by this :(. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/0fcafa73/attachment.html>
[Nouveau] [PATCH] clk: allow config option to enable reclocking
On Sat, May 17, 2014 at 2:06 PM, Ilia Mirkin wrote: > On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs wrote: >> On 17 May 2014 13:39, "Ilia Mirkin" wrote: >>> >>> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs wrote: >>> > On 17 May 2014 02:43, "Ilia Mirkin" wrote: >>> >> >>> >> Adds a NvReclock boolean option to allow the user to enable (or >>> >> disable) >>> >> reclocking. All chipsets default to off, except NVAA/NVAC, which are >>> >> reportedly complete. >>> > Hey Ilia, >>> > >>> > I think I've expressed my thoughts on this previously via IRC, but let >>> > me >>> > stick them here too so there's a record of the current state... >>> > >>> > For nvaa/nvac, yes, let's enable it by default. It should, apparently, >>> > be >>> > good enough that it has a decent chance of working. It's not like we're >>> > attempting anything automatic yet, so, this won't break anything for >>> > people >>> > who aren't trying.. >>> > >>> > I'm on the fence about Kepler. It actually might work to some extent in >>> > a >>> > decent number of cases already, there's potentially some severe issues >>> > even >>> > with engine clocks on some boards that I'm aware of, so it's not just a >>> > memory reclocking worry here. >>> > >>> > That said, it has a good chance of working for some people. So. >>> > Thoughts? >>> > I'm also talking making "NvMemExec" default on here too. Again, causing >>> > a >>> > fuck-up will still require direct user action. >>> > >>> > For the rest (Hm, except maybe nv40, a lot will probably be ok..) >>> > There's >>> > *very* little chance memory reclocking will work, even on the systems >>> > where >>> > it used to. The code is far less complete, as it was broken in general, >>> > and >>> > I haven't yet had the time to *properly* reverse engineer the sequence >>> > needed to stably reclock memory. Kepler is the only implementation >>> > where >>> > that's even been started. Tl;dr - unless you're working on the code for >>> > Tesla/Fermi, there's zero point even trying it. So, the block should >>> > stay. >>> >>> Meh. It works on my G98, for one of the perf levels. I'm sure there >>> are lots of tesla's where it totally wouldn't work, but as long as it >>> works on some of them, why not let people try? >> Because we don't even *try* to handle timing changes, which, for the vast >> majority perflvl changes, will not end well. >> >> This is more than a "mere" bug or slight bit of missing handling. It's a >> *very* important chunk of the process that's simply missing. >> >> This is the difference between the Kepler code. Kepler might work, this >> probably will not, unless you're very very lucky. >> >>> >>> > >>> > Personally, as you know, I'm more comfortable leaving it developer-only >>> > still (except nvaa/nvac) until it at least works on all our own boards >>> > without any major known missing bits.. But yeah, for the ones mentioned >>> > above, I guess it's a possibility if people *really* want... >>> >>> I'm of the opposite opinion... if it works on _some_ of our boards, we >>> should let people play with it. Why lock it away? Unless there's a >>> real danger of it bricking the card. I've never heard of our code >>> doing that, and given the way that you were RE'ing this stuff, I doubt >>> that there's anything we can do (within reason) to brick the card. >> This is why I'm "Hmm, maybe" on Kepler's code. Again, the rest isn't even >> expected to work at all yet. I'm surprised it did for you.. Were the clocks >> you chose close to the boot clocks by chance? > > Yep, they were. ;) > >> >>> >>> > >>> > I can only envision that if we allow this even just in the places it's >>> > known >>> > to be partially broken, certain sensationalist, er, people, will feel >>> > the >>> > need to test and complain about how broken it all really is... And then >>> > retest on a regular basis, despite there having been *zero* work done >>> > because no-one has the time, and then complain about the exact same >>> > thing >>> > AGAIN! (WHOA.. I'm done ranting now :p) >>> >>> I would prefer to avoid our decisions being directed by a small number >>> of loud complaining users, and instead to try to do things that will >>> serve the real users. Those complaints are only as loud as you think >>> they are -- you can also think of them as an automated tester that >>> puts its results into prose. >> Yes, this was more of a rant than an argument against the idea. >> >> Prior to 3.13, we allowed people to try >>> reclocking on nv40 and nv50, and I didn't see some huge quantity of >>> complaints about how it didn't work perfectly. Perhaps you saw those >>> at first, but I think the expectation by now is that it won't work. >>> Especially if it's behind a config option. >> Yes, but now, the code is lacking the huge chunk of functionality and >> probably won't work. Nv40 is probably in a similar state to before, >> however. So, again with the "maybe" there too. >> >>> >>> I have no idea what NvMemExec _really_ is doing,
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #15 from smoki --- Not sure how to not effectively not expose that format for radeonsi: http://lists.freedesktop.org/archives/mesa-dev/2013-January/033029.html In dri2.c, dri_screen.c, dri_drawable.c... :) ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/d5698b41/attachment.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 --- Comment #18 from David Heidelberger (okias) --- At this moment only Unigine Sanctuary (it work as expected), now downloading Unigine Heaven. Some of games I'm not able to test, but I tested piglit quick set and no regression showed up. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/b73c23a5/attachment-0001.html>
[Bug 78832] New: libvdpau_r600.so.1 crash/error for small video
https://bugs.freedesktop.org/show_bug.cgi?id=78832 Priority: medium Bug ID: 78832 Assignee: dri-devel at lists.freedesktop.org Summary: libvdpau_r600.so.1 crash/error for small video Severity: normal Classification: Unclassified OS: All Reporter: pierre-bugzilla at ossman.eu Hardware: Other Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 99222 --> https://bugs.freedesktop.org/attachment.cgi?id=99222&action=edit 8x8 test movie Feeding libvdpau_r600.so.1 the attached video makes it misbehave. With mplayer I get this: [vdpau] Error when calling vdp_video_mixer_render: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. With xbmc I get a crash: Thread 1 (Thread 0x7fa8d0eff700 (LWP 2039)): #0 0x7fa8d8e562d1 in ?? () from /usr/lib64/vdpau/libvdpau_r600.so.1 #1 0x7fa8d8ee0302 in vlVdpVideoMixerDestroy () from /usr/lib64/vdpau/libvdpau_r600.so.1 #2 0x008953f9 in VDPAU::CMixer::Process() () #3 0x011d0a58 in CThread::Action() () #4 0x011d1179 in CThread::staticThread(void*) () #5 0x003948007f33 in start_thread () from /lib64/libpthread.so.0 #6 0x0039478f4ded in clone () from /lib64/libc.so.6 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/6ed2600a/attachment.html>
[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=72685 --- Comment #15 from David Heidelberger (okias) --- I forgot mention, GPU model: Gallium 0.4 on AMD SUMO 3.0 Mesa 10.3.0-devel (git-3a1da0a) 256Mb -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/52d090af/attachment.html>
[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=72685 --- Comment #14 from David Heidelberger (okias) --- Unigine Sanctuary work perfectly on HD 6550D with 3.14.4 kernel R600_DEBUG=hyperz ./1024x768_windowed.sh Performace without HyperZ: FPS:28.1 Scores:1193 Min FPS:20.0 Max FPS:30.2 With HyperZ: FPS:30.1 Scores:1278 Min FPS:23.8 Max FPS:40.0 Can you retest guys? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/a2903bcb/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #27 from Marek Ol??k --- You can also use piglit without X using: $ piglit/piglit-run.py -p gbm OR $ PIGLIT_PLATFORM=gbm piglit/bin/test -auto Alternative to glxinfo without X: $ PIGLIT_PLATFORM=gbm piglit/bin/glinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/1a49177f/attachment.html>
[Nouveau] [PATCH] clk: allow config option to enable reclocking
nality and probably won't work. Nv40 is probably in a similar state to before, however. So, again with the "maybe" there too. > > I have no idea what NvMemExec _really_ is doing, so I left it alone. I > assume that the majority of what my patch enables is actually engine > reclocking, not memory reclocking. So to get both, people would have > to flip both flags? Or is there more to it? I use it during development to allow independent testing or engine clock code without the more faulty memory code causing problems. The option prevents the memory recording scripts from being executed. Ben. > > -ilia -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/e623893a/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #14 from smoki --- It is XRGB, MESA_FORMAT_B8G8R8X8_UNORM but need to checked it out in real situations... a think intel disable support for this "memory saver" format in screen, but radeon in classic and gallium leave it enabled :). Does that format need to be supported anymore? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/f6d15c6d/attachment.html>
[Nouveau] [PATCH] clk: allow config option to enable reclocking
100644 > --- a/nvkm/subdev/clock/nvc0.c > +++ b/nvkm/subdev/clock/nvc0.c > @@ -437,7 +437,8 @@ nvc0_clock_ctor(struct nouveau_object *parent, struct nouveau_object *engine, > struct nvc0_clock_priv *priv; > int ret; > > - ret = nouveau_clock_create(parent, engine, oclass, nvc0_domain, &priv); > + ret = nouveau_clock_create(parent, engine, oclass, nvc0_domain, false, > + &priv); > *pobject = nv_object(priv); > if (ret) > return ret; > diff --git a/nvkm/subdev/clock/nve0.c b/nvkm/subdev/clock/nve0.c > index d3c37c9..860aa73 100644 > --- a/nvkm/subdev/clock/nve0.c > +++ b/nvkm/subdev/clock/nve0.c > @@ -473,7 +473,8 @@ nve0_clock_ctor(struct nouveau_object *parent, struct nouveau_object *engine, > struct nve0_clock_priv *priv; > int ret; > > - ret = nouveau_clock_create(parent, engine, oclass, nve0_domain, &priv); > + ret = nouveau_clock_create(parent, engine, oclass, nve0_domain, false, > + &priv); > *pobject = nv_object(priv); > if (ret) > return ret; > -- > 1.8.5.5 > > ___ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/8cefe9be/attachment-0001.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 smoki changed: What|Removed |Added Attachment #99217|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/30b5dfcd/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #13 from smoki --- Created attachment 99217 --> https://bugs.freedesktop.org/attachment.cgi?id=99217&action=edit STK-black Nah, i found now another blackiness in another game case now when FBO is not used :D. Maybe this is problem only with some formats used, i think i will checkeout this :). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/f1bf6128/attachment-0001.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #15 from darkbasic --- Tesseract does still crash with si-spill-fixes-v4 if I set "Shadow resolution" to "Ultra" or "Global Illumination" to "High" or "Morphological AA" to "Ultra". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/30765b95/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #12 from smoki --- And of course then i came to the that AirStrike3D game case, simple OpenGL 1.2 game i think which does not use any of these but show the same bug :). That game can i think can work without extensions at all, but it enable some like multitexture, vertex arrays, texture env add and texture combine when available. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/d5b911ad/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #11 from smoki --- Maybe i need to explain that :). What i am talking there is that PTTM game supports different reder paths: GL1X, ARB, NV1X, NV2X, R2XX and ARB2. When you started that game it query for extensions, select the best but in settings also let you choose some different if available. Of course NV1X, NV2X and R2XX paths are not supported by radeonsi and thase are not listed. So i have there so called ARB2 by default which shows a bug, so i tried ARB and GL1X these also shows a bug. Now i tried next game in the series 18 Wheels of Steel American Long Haul, that supports these and some more NV3X and NV4X, but that is for nvidia so not listed. That game shows the same bug with ARB, ARB1 paths but now works with ARB2 :) - that is the only render path which does not have this bug. And why, in PTTM ARB2 query only for fragment program extension, but in ALH it query for both vertex and fragment program extension. So what i am saying there is, bug is not there when game use both, but bug is there in any different situation when both are not used :). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/86702aaf/attachment.html>
[PATCH 2/2] drm/tegra: Enable HDMI_5V_CON regulator
The DDC bus uses this for it's supply, enable it so EDID can be read.
This eliminates I2C read timeouts on Venice2 and EDID can be verified
with i2cdump.
Signed-off-by: Dylan Reid
---
drivers/gpu/drm/tegra/hdmi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 6928015..3d3cd7e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -44,6 +44,7 @@ struct tegra_hdmi {
struct regulator *vdd;
struct regulator *pll;
+ struct regulator *hdmi_5v;
void __iomem *regs;
unsigned int irq;
@@ -1263,6 +1264,13 @@ static int tegra_hdmi_init(struct host1x_client *client)
return err;
}
+ err = regulator_enable(hdmi->hdmi_5v);
+ if (err < 0) {
+ dev_err(client->dev, "failed to enable HDMI 5V regulator: %d\n",
+ err);
+ return err;
+ }
+
hdmi->output.type = TEGRA_OUTPUT_HDMI;
hdmi->output.dev = client->dev;
hdmi->output.ops = &hdmi_ops;
@@ -1307,6 +1315,7 @@ static int tegra_hdmi_exit(struct host1x_client *client)
}
regulator_disable(hdmi->vdd);
+ regulator_disable(hdmi->hdmi_5v);
return 0;
}
@@ -1411,6 +1420,12 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->pll);
}
+ hdmi->hdmi_5v = devm_regulator_get(&pdev->dev, "hdmi");
+ if (IS_ERR(hdmi->hdmi_5v)) {
+ dev_err(&pdev->dev, "failed to get HDMI 5V regulator\n");
+ return PTR_ERR(hdmi->hdmi_5v);
+ }
+
hdmi->output.dev = &pdev->dev;
err = tegra_output_probe(&hdmi->output);
--
1.8.1.3.605.g02339dd
[PATCH 1/2] ARM: tegra: Mark Tegra124 HDMI compatible with Tegra114
The HDMI driver that handles Tegra114 can handle Tegra124 as well,
mark Tegra124 as compatible. This makes HDMI output work on Venice2.
Signed-off-by: Dylan Reid
---
arch/arm/boot/dts/tegra124.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 197e848..fbaf985 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -52,7 +52,8 @@
};
hdmi at 0,5428 {
- compatible = "nvidia,tegra124-hdmi";
+ compatible = "nvidia,tegra124-hdmi",
+"nvidia,tegra114-hdmi";
reg = <0x0 0x5428 0x0 0x0004>;
interrupts = ;
clocks = <&tegra_car TEGRA124_CLK_HDMI>,
--
1.8.1.3.605.g02339dd
[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control
On Fri, May 16, 2014 at 8:15 PM, Rafa? Mi?ecki wrote: > On 17 May 2014 02:14, Rafa? Mi?ecki wrote: >> So it's the fact: >> DCE2 uses 0x74dc >> DCE2 uses 0x740c > > I meant: > DCE2 uses 0x74dc > DCE3 uses 0x740c Yeah, I just double checked DCE2 and you are correct. So the patch is fine as is. Alex
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #14 from farmboy0+freedesktop at googlemail.com --- The v3 patch doesnt fix Antichamber's crash to desktop. But with this patch it actually shows the VGPR messages: LLVM triggered Diagnostic Handler: SIInstrInfo::storeRegToStackSlot - Can't spill VGPR! LLVM triggered Diagnostic Handler: SIInstrInfo::loadRegToStackSlot - Can't retrieve spilled VGPR! Here's the start of the backtrace for reference: Program received signal SIGSEGV, Segmentation fault. 0xf504f671 in std::pair::operator= (this=0x450d2ff4, __p=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_pair.h:153 153 second = __p.second; (gdb) bt #0 0xf504f671 in std::pair::operator= (this=0x450d2ff4, __p=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_pair.h:153 #1 0xf505e8c5 in llvm::IntervalMapImpl::NodeBase, llvm::LiveInterval*, 16u>::copy<16u> ( this=0x44ee9644, Other=..., i=250679, j=250678, Count=4294967295) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:231 #2 0xf505f3ad in llvm::IntervalMapImpl::NodeBase, llvm::LiveInterval*, 16u>::moveLeft ( this=0x44ee9644, i=1, j=0, Count=4294967295) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:242 #3 0xf505ec81 in llvm::IntervalMapImpl::NodeBase, llvm::LiveInterval*, 16u>::erase ( this=0x44ee9644, i=0, j=1, Size=0) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:263 #4 0xf505e175 in llvm::IntervalMapImpl::NodeBase, llvm::LiveInterval*, 16u>::erase ( this=0x44ee9644, i=0, Size=0) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:270 #5 0xf505d1ee in llvm::IntervalMap >::iterator::erase ( this=0x6348) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:1876 #6 0xf505c846 in llvm::LiveIntervalUnion::extract (this=0x44ee9640, VirtReg=...) at LiveIntervalUnion.cpp:68 #7 0xf50655ef in llvm::LiveRegMatrix::unassign (this=0x44d26e60, VirtReg=...) at LiveRegMatrix.cpp:96 #8 0xf511e81f in (anonymous namespace)::RAGreedy::tryLastChanceRecoloring (this=0x44243000, VirtReg=..., Order=..., NewVRegs=..., FixedRegisters=..., Depth=0) at RegAllocGreedy.cpp:2067 #9 0xf511f224 in (anonymous namespace)::RAGreedy::selectOrSplitImpl (this=0x44243000, VirtReg=..., NewVRegs=..., FixedRegisters=..., Depth=0) at RegAllocGreedy.cpp:2285 #10 0xf511eb60 in (anonymous namespace)::RAGreedy::selectOrSplit (this=0x44243000, VirtReg=..., NewVRegs=...) at RegAllocGreedy.cpp:2144 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/b06399f7/attachment.html>
[Bug 78788] [Radeon\VCE] Performance regression after using VCE
https://bugs.freedesktop.org/show_bug.cgi?id=78788 --- Comment #3 from Iaroslav --- Created attachment 99201 --> https://bugs.freedesktop.org/attachment.cgi?id=99201&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/69ec1e17/attachment.html>
[Bug 78788] [Radeon\VCE] Performance regression after using VCE
https://bugs.freedesktop.org/show_bug.cgi?id=78788 --- Comment #2 from Iaroslav --- Created attachment 99200 --> https://bugs.freedesktop.org/attachment.cgi?id=99200&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/b5a45b61/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #26 from Michel D?nzer --- (In reply to comment #23) FWIW, for the initial radeonsi bringup, I used mesa/demos/src/egl/opengl/egltri_screen. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/6eb0fa11/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Tom Stellard changed: What|Removed |Added Attachment #99186|0 |1 is obsolete|| --- Comment #13 from Tom Stellard --- Created attachment 99187 --> https://bugs.freedesktop.org/attachment.cgi?id=99187&action=edit VGPR Spill Work Around v3 with possible antichamber crash fix Here is an updated version of the patch, which may fix the antichamber crash. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/65dafaa8/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Tom Stellard changed: What|Removed |Added Attachment #99169|0 |1 is obsolete|| --- Comment #12 from Tom Stellard --- Created attachment 99186 --> https://bugs.freedesktop.org/attachment.cgi?id=99186&action=edit VGPR Spill Work Around v2 This patch should build. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/02ff44cb/attachment.html>
[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation
https://bugs.freedesktop.org/show_bug.cgi?id=73320 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #51 from Tom Stellard --- *** This bug has been marked as a duplicate of bug 75276 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/423f1cc9/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Tom Stellard changed: What|Removed |Added CC||freedesktop.org at inequation. ||org --- Comment #11 from Tom Stellard --- *** Bug 73320 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/68f14170/attachment-0001.html>
[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #15 from Tom Stellard --- *** This bug has been marked as a duplicate of bug 75276 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/e03ddf77/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Tom Stellard changed: What|Removed |Added CC||haagch.christoph at googlemail ||.com --- Comment #10 from Tom Stellard --- *** Bug 75211 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/3ad433aa/attachment.html>
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #27 from Tom Stellard --- *** This bug has been marked as a duplicate of bug 75276 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/bc57d3b9/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Tom Stellard changed: What|Removed |Added CC||idd997733t at gmail.com --- Comment #9 from Tom Stellard --- *** Bug 75361 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/0fa947c3/attachment.html>
[Bug 78790] Game Tesseract: Crash on shaders and out of registers LLVM errors
https://bugs.freedesktop.org/show_bug.cgi?id=78790 --- Comment #1 from Michel D?nzer --- The patches referenced on bug 75276 seem to help for Tesseract. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/8432daba/attachment.html>
[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control
On 17 May 2014 02:14, Rafa? Mi?ecki wrote: > So it's the fact: > DCE2 uses 0x74dc > DCE2 uses 0x740c I meant: DCE2 uses 0x74dc DCE3 uses 0x740c
[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control
On 17 May 2014 01:34, Rafa? Mi?ecki wrote: > On 17 May 2014 00:00, Alex Deucher wrote: >> On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki wrote: >>> +#define DCE3_HDMI0_AUDIO_CRC_CONTROL 0x74dc >> >> They aren't swapped in hw, the register defines were just accidentally >> swapped in the header (probably a copy paste typo). Just swap the >> defines. No need to keep the old values. > > Are you sure about this? I've doubts because fglrx indeed uses > 0x74dc for DCE2 > 0x740c for DCE3 > > Previously you wrote: "On DCE3, they should be ...". > > I suspect we may still need old defines to support DCE2. I was right. I've just compiled radeon with: acr_ctl = 0x740c; and tested it on DCE2. Audio didn't work. Some debugging: # avivotool regsrange 0x740c 0x740c 740c 1100 (4352) # avivotool regsrange 0x74dc 0x74dc 74dc (0) As expected, audio was fixed by exeuting: # avivotool regset 0x74dc 0x1100 So it's the fact: DCE2 uses 0x74dc DCE2 uses 0x740c So I believe my patch is OK. -- Rafa?
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #10 from Michel D?nzer --- smoki, your comments on Phoronix don't make much sense I'm afraid. First of all, there's no such thing as no vertex or pixel shader for a Gallium driver. The state tracker always provides both shaders to the driver, even if they don't do anything but pass through values. I don't think there's anything particularly special about this bug; someone will just have to track down and fix it. Your apitraces will be useful for that, thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140517/8f65eec1/attachment.html>
[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control
On 17 May 2014 00:00, Alex Deucher wrote: > On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki wrote: >> +#define DCE3_HDMI0_AUDIO_CRC_CONTROL 0x74dc > > They aren't swapped in hw, the register defines were just accidentally > swapped in the header (probably a copy paste typo). Just swap the > defines. No need to keep the old values. Are you sure about this? I've doubts because fglrx indeed uses 0x74dc for DCE2 0x740c for DCE3 Previously you wrote: "On DCE3, they should be ...". I suspect we may still need old defines to support DCE2.
[Intel-gfx] [PATCH 1/4] drm: Support legacy cursor ioctls via universal planes when possible (v2)
On Sat, May 17, 2014 at 12:38 AM, Matt Roper
wrote:
> + if (ret) {
> + if (req->flags & DRM_MODE_CURSOR_BO)
> + drm_mode_rmfb(dev, &fb->base.id, file_priv);
> + return ret;
> + }
With the new refcount logic an unconditional
drm_framebuffer_unreference should be here instead of this. I think,
but please double-check since it's late here ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Nouveau] [PATCH] clk: allow config option to enable reclocking
On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs wrote: > On 17 May 2014 13:39, "Ilia Mirkin" wrote: >> >> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs wrote: >> > On 17 May 2014 02:43, "Ilia Mirkin" wrote: >> >> >> >> Adds a NvReclock boolean option to allow the user to enable (or >> >> disable) >> >> reclocking. All chipsets default to off, except NVAA/NVAC, which are >> >> reportedly complete. >> > Hey Ilia, >> > >> > I think I've expressed my thoughts on this previously via IRC, but let >> > me >> > stick them here too so there's a record of the current state... >> > >> > For nvaa/nvac, yes, let's enable it by default. It should, apparently, >> > be >> > good enough that it has a decent chance of working. It's not like we're >> > attempting anything automatic yet, so, this won't break anything for >> > people >> > who aren't trying.. >> > >> > I'm on the fence about Kepler. It actually might work to some extent in >> > a >> > decent number of cases already, there's potentially some severe issues >> > even >> > with engine clocks on some boards that I'm aware of, so it's not just a >> > memory reclocking worry here. >> > >> > That said, it has a good chance of working for some people. So. >> > Thoughts? >> > I'm also talking making "NvMemExec" default on here too. Again, causing >> > a >> > fuck-up will still require direct user action. >> > >> > For the rest (Hm, except maybe nv40, a lot will probably be ok..) >> > There's >> > *very* little chance memory reclocking will work, even on the systems >> > where >> > it used to. The code is far less complete, as it was broken in general, >> > and >> > I haven't yet had the time to *properly* reverse engineer the sequence >> > needed to stably reclock memory. Kepler is the only implementation >> > where >> > that's even been started. Tl;dr - unless you're working on the code for >> > Tesla/Fermi, there's zero point even trying it. So, the block should >> > stay. >> >> Meh. It works on my G98, for one of the perf levels. I'm sure there >> are lots of tesla's where it totally wouldn't work, but as long as it >> works on some of them, why not let people try? > Because we don't even *try* to handle timing changes, which, for the vast > majority perflvl changes, will not end well. > > This is more than a "mere" bug or slight bit of missing handling. It's a > *very* important chunk of the process that's simply missing. > > This is the difference between the Kepler code. Kepler might work, this > probably will not, unless you're very very lucky. > >> >> > >> > Personally, as you know, I'm more comfortable leaving it developer-only >> > still (except nvaa/nvac) until it at least works on all our own boards >> > without any major known missing bits.. But yeah, for the ones mentioned >> > above, I guess it's a possibility if people *really* want... >> >> I'm of the opposite opinion... if it works on _some_ of our boards, we >> should let people play with it. Why lock it away? Unless there's a >> real danger of it bricking the card. I've never heard of our code >> doing that, and given the way that you were RE'ing this stuff, I doubt >> that there's anything we can do (within reason) to brick the card. > This is why I'm "Hmm, maybe" on Kepler's code. Again, the rest isn't even > expected to work at all yet. I'm surprised it did for you.. Were the clocks > you chose close to the boot clocks by chance? Yep, they were. > >> >> > >> > I can only envision that if we allow this even just in the places it's >> > known >> > to be partially broken, certain sensationalist, er, people, will feel >> > the >> > need to test and complain about how broken it all really is... And then >> > retest on a regular basis, despite there having been *zero* work done >> > because no-one has the time, and then complain about the exact same >> > thing >> > AGAIN! (WHOA.. I'm done ranting now :p) >> >> I would prefer to avoid our decisions being directed by a small number >> of loud complaining users, and instead to try to do things that will >> serve the real users. Those complaints are only as loud as you think >> they are -- you can also think of them as an automated tester that >> puts its results into prose. > Yes, this was more of a rant than an argument against the idea. > > Prior to 3.13, we allowed people to try >> reclocking on nv40 and nv50, and I didn't see some huge quantity of >> complaints about how it didn't work perfectly. Perhaps you saw those >> at first, but I think the expectation by now is that it won't work. >> Especially if it's behind a config option. > Yes, but now, the code is lacking the huge chunk of functionality and > probably won't work. Nv40 is probably in a similar state to before, > however. So, again with the "maybe" there too. > >> >> I have no idea what NvMemExec _really_ is doing, so I left it alone. I >> assume that the majority of what my patch enables is actually engine >> reclocking, not memory reclocking. So to get both, people would have >>
