Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
On Mon, 18 Jul 2011 19:20:56 -0500 Rob Clark wrote: > In the process of adding GEM support for OMAP DRM driver, I noticed that > I was adding code for creating/freeing mmap offsets which was virtually > identical to what was already duplicated in i915 and gma500 drivers. The gma500 one was taken from i915 and I'd reach the same conclusion as you - the current GMA500 driver (see staging git) has the mmap offset patches broken out in gem_glue.c ready to do what you are proposing. > Rather than duplicating the code a 3rd time, it seemed like a good idea > to move it to the GEM core. Agreed entirely. > Note that I don't actually have a way to test psb or i915, but the > changes seem straightforward enough. Your patch doesn't apply versus gma500 but its trivial to remove it from gem_glue.c once it goes into the mainstream GEM. (The other bits in the gma500 glue are to allow for GEM objects backed by things other than shmfs) Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote: > In the process of adding GEM support for OMAP DRM driver, I noticed that > I was adding code for creating/freeing mmap offsets which was virtually > identical to what was already duplicated in i915 and gma500 drivers. > > Rather than duplicating the code a 3rd time, it seemed like a good idea > to move it to the GEM core. > > Note that I don't actually have a way to test psb or i915, but the > changes seem straightforward enough. My only concern is that for the common functions the mmap_offset to create should be passed in a parameter, so that we could support more than one mapping for an object. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36762] broken minimap on 0ad alpha5
https://bugs.freedesktop.org/show_bug.cgi?id=36762 --- Comment #1 from Fabio Pedretti 2011-07-19 05:24:47 PDT --- Bug confirmed on 0 A.D. alpha 6 with current mesa master. It also looks like an Intel i3 user is having the same problem: http://www.wildfiregames.com/forum/index.php?showtopic=14813&view=findpost&p=220813 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39.3 radeon crash when firmware loading fails
When booting 2.6.39.3 with radeon and KMS enabled the boot messages stop at some point (clocksource switching to TSC or something) and about 60 seconds later the screen turns into a noise pattern with some irregularities on top (i.e. crash). This happens when the radeon driver is built-in. This can be triggered too when it is a module by "insmod radeon.ko" when there is no provision to automatically load firmware (e.g via /sbin/hotplug). The insmod hangs for `cat /sys/class/firmware/timeout` seconds (default 60) and after that it crashes with identical symptoms. When /sbin/hotplug is present for loading firmware (radeon/RV620_pfp.bin, radeon/RV620_me.bin, radeon/R600_rlc.bin in this case) then all goes well. Because of this it is not possible to use a built-in radeon driver with KMS enabled. lspci -vv: 01:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon HD 3450] (prog-if 00 [VGA controller]) Subsystem: Dell Device 0342 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: radeon -- Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
On Tue, Jul 19, 2011 at 3:57 AM, Alan Cox wrote: > On Mon, 18 Jul 2011 19:20:56 -0500 > Rob Clark wrote: > >> In the process of adding GEM support for OMAP DRM driver, I noticed that >> I was adding code for creating/freeing mmap offsets which was virtually >> identical to what was already duplicated in i915 and gma500 drivers. > > The gma500 one was taken from i915 and I'd reach the same conclusion as > you - the current GMA500 driver (see staging git) has the mmap offset > patches broken out in gem_glue.c ready to do what you are proposing. ahh, ok.. I should check this out (although I'm not entirely sure where your gma500 staging tree is) I'm already using your patch to add drm_gem_private_object_init() for scanout buffers (which need to be physically contiguous). But perhaps you have some other useful "gems" BR, -R >> Rather than duplicating the code a 3rd time, it seemed like a good idea >> to move it to the GEM core. > > Agreed entirely. > >> Note that I don't actually have a way to test psb or i915, but the >> changes seem straightforward enough. > > Your patch doesn't apply versus gma500 but its trivial to remove it from > gem_glue.c once it goes into the mainstream GEM. > > (The other bits in the gma500 glue are to allow for GEM objects backed by > things other than shmfs) > > Alan > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #2 from Michal Suchanek 2011-07-19 06:09:04 PDT --- Can't. The trace file is 6.7M gzipped and the attachment limit is 3000k. It is trace from the start of the application to the point where it finishes initialization, tries to render the first scene and triggers the assert. glretrace complains that the last call is incomplete whatever that means: warning: incomplete call glDrawElementsBaseVertex 27826 glDrawElementsBaseVertex(mode = GL_TRIANGLE_STRIP, count = 110, type = GL_UNSIGNED_SHORT, indices = blob(220), basevertex = 54) Tried taking glretrace snapshots with -s. They are all small black squares. With -sb and -s I get errors about GL_BACK being invalid but every other snapshot contains the application loading screen (upside down). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson wrote: > On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote: >> In the process of adding GEM support for OMAP DRM driver, I noticed that >> I was adding code for creating/freeing mmap offsets which was virtually >> identical to what was already duplicated in i915 and gma500 drivers. >> >> Rather than duplicating the code a 3rd time, it seemed like a good idea >> to move it to the GEM core. >> >> Note that I don't actually have a way to test psb or i915, but the >> changes seem straightforward enough. > > My only concern is that for the common functions the mmap_offset to create > should be passed in a parameter, so that we could support more than one > mapping for an object. I admit I've not got quite as far as dealing with this yet.. I'm just starting on the dri2 part in xorg driver. (Previous pvr xorg driver has some non-GEM way of sharing buffers.) So I'm figuring out some of this stuff as I go. For me I think it isn't the end of the world to have same offset in all processes, although I'm interested if there is a better way. There is just one 'struct drm_local_map' in 'struct drm_gem_object', so I admit that I'm not quite sure how this was intended to work. BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
> ahh, ok.. I should check this out (although I'm not entirely sure > where your gma500 staging tree is) Its in GregKH's staging tree or linux-next. It's basically what you've done so if your patch is submitted it'll take me 2 minutes to fix the gma500 tree. > I'm already using your patch to add drm_gem_private_object_init() for > scanout buffers (which need to be physically contiguous). But perhaps > you have some other useful "gems" No I think that one and the offset patch is it. I do need to attack the fb console code next because I need a GEM object as console in some cases and don't have enough virtual address space to vremap it to look linear. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Status of Radeon power management / laptop overheating
On Mon, Jul 11, 2011 at 11:26:32PM +0300, Pasi Kärkkäinen wrote: > Hello, > > Does someone know the current status of radeon power management in Linux? > and also the roadmap/todo? > > I have a laptop than runs *very* hot in Linux, while it's cool in Windows, > and the difference seems to be mostly about radeon graphics driver. > > The default power_profile makes the laptop run *very* hot, > and Linux does "thermal emergency shutdowns" pretty often. > > When I change the default radeon power_profile to "mid" or "low" the > temperature > goes down by 10-20 degrees celsius, but it's still more hot in Linux compared > to Windows. > > Some bugzillas from Fedora: > > "Computer becomes very hot (2011 27inch iMac)": > https://bugzilla.redhat.com/show_bug.cgi?id=702953 > > "radeon driver default power profile causes laptop overheating": > https://bugzilla.redhat.com/show_bug.cgi?id=714474 > > > My testing is done with Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38). > > Thanks, > Any thoughts about this? -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39612] New: radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 Summary: radeon blocks with new style fencing Product: Drivers Version: 2.5 Kernel Version: >= 2.6.37 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: linas...@ymail.com CC: alexdeuc...@gmail.com Regression: Yes I am using a Radeon HD 3600 in kernel 2.6.36 with xf86-video-ati (KMS). Since 2.6.37 when starting the X server the screen goes black and never shows the desktop. kernel 2.6.36 startx -> Screen goes black -> The wallpaper appears -> The DE loads kernel >= 2.6.37 startx -> Screen goes black -> You can't switch virtual terminals -> REISUB -> Downgrade kernel Reproducible: Always Bisecting shows that it started failing at d0f8a854c340986359a3b0a97e380c71def7a440: drm/radeon/kms/r6xx+: use new style fencing (v3) http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=commit;h=d0f8a854c340986359a3b0a97e380c71def7a440 Downstream bug https://bugs.archlinux.org/task/23422 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Pierre-Eric Pelloux-Prayer changed: What|Removed |Added Attachment #46083|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Pierre-Eric Pelloux-Prayer changed: What|Removed |Added Attachment #46281|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #9 from Pierre-Eric Pelloux-Prayer 2011-07-19 12:42:53 PDT --- I've marked previously attached patches as obsolete because the ones hosted here : http://people.freedesktop.org/~agd5f/htile/ are the most up to date. All the patches are needed (kernel + mesa ones) to enable HiZ. They are now mainly in need of testing to see how far from completion we are, so feedbacks are more than welcome :-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39.3 radeon crash when firmware loading fails
On Tue, 19 Jul 2011 at 14:41:07 +0200, Frank van Maarseveen wrote: > When booting 2.6.39.3 with radeon and KMS enabled the boot messages > stop at some point (clocksource switching to TSC or something) and > about 60 seconds later the screen turns into a noise pattern with some > irregularities on top (i.e. crash). > > This happens when the radeon driver is built-in. > > This can be triggered too when it is a module by "insmod radeon.ko" > when there is no provision to automatically load firmware (e.g via > /sbin/hotplug). The insmod hangs for `cat /sys/class/firmware/timeout` > seconds (default 60) and after that it crashes with identical > symptoms. When /sbin/hotplug is present for loading firmware > (radeon/RV620_pfp.bin, radeon/RV620_me.bin, radeon/R600_rlc.bin in this > case) then all goes well. I think you want to have CONFIG_FIRMWARE_IN_KERNEL set to not depend on userspace to load firmware. Can you provide dmesg of this crash? > Because of this it is not possible to use a built-in radeon driver with > KMS enabled. > > > lspci -vv: > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon HD > 3450] (prog-if 00 [VGA controller]) > Subsystem: Dell Device 0342 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at e000 (64-bit, prefetchable) [size=256M] > Region 2: Memory at f7df (64-bit, non-prefetchable) [size=64K] > Region 4: I/O ports at dc00 [size=256] > Expansion ROM at f7e0 [disabled] [size=128K] > Capabilities: [50] Power Management version 3 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, > L1 unlimited > ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ > Unsupported- > RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 128 bytes, MaxReadReq 128 bytes > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- > TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, > Latency L0 <64ns, L1 <1us > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis- > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- > SpeedDis-, Selectable De-emphasis: -6dB > Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- > Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB > Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ > Address: Data: > Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 > Len=010 > Kernel driver in use: radeon > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: > +#define SHADER_DEBUG_SOCKET "/tmp/gen_debug" Not sure what this is used for, but does it really need to be in /tmp? Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Sven Arvidsson changed: What|Removed |Added CC||s...@whiz.se --- Comment #10 from Sven Arvidsson 2011-07-19 15:02:37 PDT --- It might be a good idea to refresh those patches first, to ease testing. These two no longer apply cleanly to current git master: 0003-r600g-check-bo-size-before-enabling-HiZ.patch 0004-r600g-evergreen-htile-fixes-update-comments.patch The second part of this one (the changes to radeon_drm.h) seems to be already in 2.6.39? 0001-drm-radeon-kms-add-info-query-for-tile-pipes.patch This one also seems to already be in 2.6.39? 0003-drm-radeon-kms-add-missing-safe-regs-for-6xx-7xx.patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gem: RFC: add support for private objects
On Tue, Jun 7, 2011 at 8:17 AM, Alan Cox wrote: > These small changes should allow GEM to be used with non shmem objects as > well as shmem objects. In the GMA500 case it allows the base framebuffer to > appear as a GEM object and thus acquire a handle and work with KMS. > > For i915 it ought to be trivial to get back the wasted memory but putting the > system fb back into stolen RAM and in general I can imagine it allowing the > use of GEM and thus KMS with all the older cards that have their framebuffer > firmly placed in video RAM. > > Signed-off-by: Alan Cox Tested-by: Rob Clark ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34969] [nouveau] Card lockup on openarena
https://bugs.freedesktop.org/show_bug.cgi?id=34969 --- Comment #6 from Andrew Randrianasulu 2011-07-19 20:27:50 PDT --- Sorry, in my case aux. power was NOT connected to card. Now fastest perflevel works for Q3/demo001 (up to 78.0 fps for 1280x1024x32@60, but GPU temp raised to 92 C). But unmodified vertexrate demo still freezes card even with default boot clocks :[ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39612] radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 --- Comment #1 from Alex Deucher 2011-07-20 04:19:06 --- Please attach your xorg log and dmesg output. Does booting with radeon.no_wb=1 on the kernel command line in grub help? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] RFC: Common functions for GEM offset creation
On Mon, 18 Jul 2011 19:20:56 -0500 Rob Clark wrote: > In the process of adding GEM support for OMAP DRM driver, I noticed that > I was adding code for creating/freeing mmap offsets which was virtually > identical to what was already duplicated in i915 and gma500 drivers. The gma500 one was taken from i915 and I'd reach the same conclusion as you - the current GMA500 driver (see staging git) has the mmap offset patches broken out in gem_glue.c ready to do what you are proposing. > Rather than duplicating the code a 3rd time, it seemed like a good idea > to move it to the GEM core. Agreed entirely. > Note that I don't actually have a way to test psb or i915, but the > changes seem straightforward enough. Your patch doesn't apply versus gma500 but its trivial to remove it from gem_glue.c once it goes into the mainstream GEM. (The other bits in the gma500 glue are to allow for GEM objects backed by things other than shmfs) Alan
[PATCH 0/3] RFC: Common functions for GEM offset creation
On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote: > In the process of adding GEM support for OMAP DRM driver, I noticed that > I was adding code for creating/freeing mmap offsets which was virtually > identical to what was already duplicated in i915 and gma500 drivers. > > Rather than duplicating the code a 3rd time, it seemed like a good idea > to move it to the GEM core. > > Note that I don't actually have a way to test psb or i915, but the > changes seem straightforward enough. My only concern is that for the common functions the mmap_offset to create should be passed in a parameter, so that we could support more than one mapping for an object. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 36762] broken minimap on 0ad alpha5
https://bugs.freedesktop.org/show_bug.cgi?id=36762 --- Comment #1 from Fabio Pedretti 2011-07-19 05:24:47 PDT --- Bug confirmed on 0 A.D. alpha 6 with current mesa master. It also looks like an Intel i3 user is having the same problem: http://www.wildfiregames.com/forum/index.php?showtopic=14813&view=findpost&p=220813 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
2.6.39.3 radeon crash when firmware loading fails
When booting 2.6.39.3 with radeon and KMS enabled the boot messages stop at some point (clocksource switching to TSC or something) and about 60 seconds later the screen turns into a noise pattern with some irregularities on top (i.e. crash). This happens when the radeon driver is built-in. This can be triggered too when it is a module by "insmod radeon.ko" when there is no provision to automatically load firmware (e.g via /sbin/hotplug). The insmod hangs for `cat /sys/class/firmware/timeout` seconds (default 60) and after that it crashes with identical symptoms. When /sbin/hotplug is present for loading firmware (radeon/RV620_pfp.bin, radeon/RV620_me.bin, radeon/R600_rlc.bin in this case) then all goes well. Because of this it is not possible to use a built-in radeon driver with KMS enabled. lspci -vv: 01:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon HD 3450] (prog-if 00 [VGA controller]) Subsystem: Dell Device 0342 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: radeon -- Frank
[PATCH 0/3] RFC: Common functions for GEM offset creation
On Tue, Jul 19, 2011 at 3:57 AM, Alan Cox wrote: > On Mon, 18 Jul 2011 19:20:56 -0500 > Rob Clark wrote: > >> In the process of adding GEM support for OMAP DRM driver, I noticed that >> I was adding code for creating/freeing mmap offsets which was virtually >> identical to what was already duplicated in i915 and gma500 drivers. > > The gma500 one was taken from i915 and I'd reach the same conclusion as > you - the current GMA500 driver (see staging git) has the mmap offset > patches broken out in gem_glue.c ready to do what you are proposing. ahh, ok.. I should check this out (although I'm not entirely sure where your gma500 staging tree is) I'm already using your patch to add drm_gem_private_object_init() for scanout buffers (which need to be physically contiguous). But perhaps you have some other useful "gems" BR, -R >> Rather than duplicating the code a 3rd time, it seemed like a good idea >> to move it to the GEM core. > > Agreed entirely. > >> Note that I don't actually have a way to test psb or i915, but the >> changes seem straightforward enough. > > Your patch doesn't apply versus gma500 but its trivial to remove it from > gem_glue.c once it goes into the mainstream GEM. > > (The other bits in the gma500 glue are to allow for GEM objects backed by > things other than shmfs) > > Alan > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #2 from Michal Suchanek 2011-07-19 06:09:04 PDT --- Can't. The trace file is 6.7M gzipped and the attachment limit is 3000k. It is trace from the start of the application to the point where it finishes initialization, tries to render the first scene and triggers the assert. glretrace complains that the last call is incomplete whatever that means: warning: incomplete call glDrawElementsBaseVertex 27826 glDrawElementsBaseVertex(mode = GL_TRIANGLE_STRIP, count = 110, type = GL_UNSIGNED_SHORT, indices = blob(220), basevertex = 54) Tried taking glretrace snapshots with -s. They are all small black squares. With -sb and -s I get errors about GL_BACK being invalid but every other snapshot contains the application loading screen (upside down). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/3] RFC: Common functions for GEM offset creation
On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson wrote: > On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote: >> In the process of adding GEM support for OMAP DRM driver, I noticed that >> I was adding code for creating/freeing mmap offsets which was virtually >> identical to what was already duplicated in i915 and gma500 drivers. >> >> Rather than duplicating the code a 3rd time, it seemed like a good idea >> to move it to the GEM core. >> >> Note that I don't actually have a way to test psb or i915, but the >> changes seem straightforward enough. > > My only concern is that for the common functions the mmap_offset to create > should be passed in a parameter, so that we could support more than one > mapping for an object. I admit I've not got quite as far as dealing with this yet.. I'm just starting on the dri2 part in xorg driver. (Previous pvr xorg driver has some non-GEM way of sharing buffers.) So I'm figuring out some of this stuff as I go. For me I think it isn't the end of the world to have same offset in all processes, although I'm interested if there is a better way. There is just one 'struct drm_local_map' in 'struct drm_gem_object', so I admit that I'm not quite sure how this was intended to work. BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 0/3] RFC: Common functions for GEM offset creation
> ahh, ok.. I should check this out (although I'm not entirely sure > where your gma500 staging tree is) Its in GregKH's staging tree or linux-next. It's basically what you've done so if your patch is submitted it'll take me 2 minutes to fix the gma500 tree. > I'm already using your patch to add drm_gem_private_object_init() for > scanout buffers (which need to be physically contiguous). But perhaps > you have some other useful "gems" No I think that one and the offset patch is it. I do need to attack the fb console code next because I need a GEM object as console in some cases and don't have enough virtual address space to vremap it to look linear. Alan
Status of Radeon power management / laptop overheating
On Mon, Jul 11, 2011 at 11:26:32PM +0300, Pasi K?rkk?inen wrote: > Hello, > > Does someone know the current status of radeon power management in Linux? > and also the roadmap/todo? > > I have a laptop than runs *very* hot in Linux, while it's cool in Windows, > and the difference seems to be mostly about radeon graphics driver. > > The default power_profile makes the laptop run *very* hot, > and Linux does "thermal emergency shutdowns" pretty often. > > When I change the default radeon power_profile to "mid" or "low" the > temperature > goes down by 10-20 degrees celsius, but it's still more hot in Linux compared > to Windows. > > Some bugzillas from Fedora: > > "Computer becomes very hot (2011 27inch iMac)": > https://bugzilla.redhat.com/show_bug.cgi?id=702953 > > "radeon driver default power profile causes laptop overheating": > https://bugzilla.redhat.com/show_bug.cgi?id=714474 > > > My testing is done with Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38). > > Thanks, > Any thoughts about this? -- Pasi
[Bug 39612] New: radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 Summary: radeon blocks with new style fencing Product: Drivers Version: 2.5 Kernel Version: >= 2.6.37 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: linas_fi at ymail.com CC: alexdeucher at gmail.com Regression: Yes I am using a Radeon HD 3600 in kernel 2.6.36 with xf86-video-ati (KMS). Since 2.6.37 when starting the X server the screen goes black and never shows the desktop. kernel 2.6.36 startx -> Screen goes black -> The wallpaper appears -> The DE loads kernel >= 2.6.37 startx -> Screen goes black -> You can't switch virtual terminals -> REISUB -> Downgrade kernel Reproducible: Always Bisecting shows that it started failing at d0f8a854c340986359a3b0a97e380c71def7a440: drm/radeon/kms/r6xx+: use new style fencing (v3) http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=commit;h=d0f8a854c340986359a3b0a97e380c71def7a440 Downstream bug https://bugs.archlinux.org/task/23422 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Pierre-Eric Pelloux-Prayer changed: What|Removed |Added Attachment #46083|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Pierre-Eric Pelloux-Prayer changed: What|Removed |Added Attachment #46281|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #9 from Pierre-Eric Pelloux-Prayer 2011-07-19 12:42:53 PDT --- I've marked previously attached patches as obsolete because the ones hosted here : http://people.freedesktop.org/~agd5f/htile/ are the most up to date. All the patches are needed (kernel + mesa ones) to enable HiZ. They are now mainly in need of testing to see how far from completion we are, so feedbacks are more than welcome :-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
2.6.39.3 radeon crash when firmware loading fails
On Tue, 19 Jul 2011 at 14:41:07 +0200, Frank van Maarseveen wrote: > When booting 2.6.39.3 with radeon and KMS enabled the boot messages > stop at some point (clocksource switching to TSC or something) and > about 60 seconds later the screen turns into a noise pattern with some > irregularities on top (i.e. crash). > > This happens when the radeon driver is built-in. > > This can be triggered too when it is a module by "insmod radeon.ko" > when there is no provision to automatically load firmware (e.g via > /sbin/hotplug). The insmod hangs for `cat /sys/class/firmware/timeout` > seconds (default 60) and after that it crashes with identical > symptoms. When /sbin/hotplug is present for loading firmware > (radeon/RV620_pfp.bin, radeon/RV620_me.bin, radeon/R600_rlc.bin in this > case) then all goes well. I think you want to have CONFIG_FIRMWARE_IN_KERNEL set to not depend on userspace to load firmware. Can you provide dmesg of this crash? > Because of this it is not possible to use a built-in radeon driver with > KMS enabled. > > > lspci -vv: > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon HD > 3450] (prog-if 00 [VGA controller]) > Subsystem: Dell Device 0342 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at e000 (64-bit, prefetchable) [size=256M] > Region 2: Memory at f7df (64-bit, non-prefetchable) [size=64K] > Region 4: I/O ports at dc00 [size=256] > Expansion ROM at f7e0 [disabled] [size=128K] > Capabilities: [50] Power Management version 3 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, > L1 unlimited > ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ > Unsupported- > RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 128 bytes, MaxReadReq 128 bytes > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- > TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, > Latency L0 <64ns, L1 <1us > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis- > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- > SpeedDis-, Selectable De-emphasis: -6dB > Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- > Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB > Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ > Address: Data: > Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 > Len=010 > Kernel driver in use: radeon >
[Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: > +#define SHADER_DEBUG_SOCKET "/tmp/gen_debug" Not sure what this is used for, but does it really need to be in /tmp? Cheers, Julien
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #10 from Sven Arvidsson 2011-07-19 15:02:37 PDT --- It might be a good idea to refresh those patches first, to ease testing. These two no longer apply cleanly to current git master: 0003-r600g-check-bo-size-before-enabling-HiZ.patch 0004-r600g-evergreen-htile-fixes-update-comments.patch The second part of this one (the changes to radeon_drm.h) seems to be already in 2.6.39? 0001-drm-radeon-kms-add-info-query-for-tile-pipes.patch This one also seems to already be in 2.6.39? 0003-drm-radeon-kms-add-missing-safe-regs-for-6xx-7xx.patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] gem: RFC: add support for private objects
On Tue, Jun 7, 2011 at 8:17 AM, Alan Cox wrote: > These small changes should allow GEM to be used with non shmem objects as > well as shmem objects. In the GMA500 case it allows the base framebuffer to > appear as a GEM object and thus acquire a handle and work with KMS. > > For i915 it ought to be trivial to get back the wasted memory but putting the > system fb back into stolen RAM and in general I can imagine it allowing the > use of GEM and thus KMS with all the older cards that have their framebuffer > firmly placed in video RAM. > > Signed-off-by: Alan Cox Tested-by: Rob Clark
[Bug 34969] [nouveau] Card lockup on openarena
https://bugs.freedesktop.org/show_bug.cgi?id=34969 --- Comment #6 from Andrew Randrianasulu 2011-07-19 20:27:50 PDT --- Sorry, in my case aux. power was NOT connected to card. Now fastest perflevel works for Q3/demo001 (up to 78.0 fps for 1280x1024x32 at 60, but GPU temp raised to 92 C). But unmodified vertexrate demo still freezes card even with default boot clocks :[ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
