Re: new userspace API approaches atomic *
On Sun, Dec 16, 2012 at 7:04 AM, Dave Airlie wrote: > The "I can't test it" argument doesn't fly with me, you are creating a > new API that adds a useful feature, it should be possible to get a few > other driver maintainers interested, but also I'd hope that most of > the ideas for converting to a new API would be mechanical in a lot of > ways. Atomic semantics aren't hw specific from what i can see, if they > are then the API is obviously wrong. For actual semantics I think we need to split the discussion into the modeset and the pageflip part: - For modeset it shouldn't be hard to whip up some helpers which use the current crtc helpers to do modeset changes accross multiple crtcs. Like currently, drivers might refuse a modeset in one of their callbacks, and that might only happen once the hw touching has started already. Which means we can't efficiently implement a check flag mode for those drivers. But otoh if they have global constraints they might want to implement their own magic like i915. Or we could add a new global ->check_modeset callback which checks for these (after crtc/encoders have done the respective checking). - For pageflip things are a bit messier, since we really should aim for all changes to be applied on the same vblank. But luckily the set of drivers which support more than one of cursors/pageflips/plane is manageable, and most are just cursosrs+pageflip. Since I've just read through them all I think it shouldn't be too hard to whip up a (totally broken) patch for each of them to guide driver maintainers. So imo to really exploit atomic modeset/pageflip we need special support from each driver to check a given configuration before committing it (this also seems to be the only sane way for userspace to figure out what works and what doesn't without causing tons of flickering). And doing that for each driver is obviously out of the question. But reworking internal interfaces and converting drivers in a simplistic fashion which assume that no global state checking is required (assuming e.g. for modesets the current crtc/encoder checks are good enough) is a requirement I agree with. Which is why I think we should aim first for something much more restricted than the current "every possible feature for kms" approach, for example just pageflips on one crtc ... >From an i915 perspective I'm leaning towards pageflips because things are much simpler there (similar to all other drivers). It's much more immediately useful for us and for atomic modeset our driver-internal code is simple not yet ready to do global state-checking up-front before we start touching hw - we need to move around quite a bit of code until that's doable. So atomic modeset won't really help us yet to for 3-pipe pll sharing and similar shared global resources issues and how to correctly expose them to userspace. Yours, Daniel PS: My totally broken exynos patch, which Inki Dae fixed up for me, and the 3 radeon patches are already merged. It's really not rocket science afaict ... just requires pinging relevant people early so that they can check your patches quickly and know what you're up to. -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On Fri, Dec 14, 2012 at 09:59:11PM +0200, Terje Bergström wrote: > On 14.12.2012 18:21, Stephen Warren wrote: > > On 12/13/2012 11:09 PM, Terje Bergström wrote: > >> They want to get the global data by getting drvdata of their parent. > > > > There's no reason that /has/ to be so; they can get any information from > > wherever it is, rather than trying to require it to be somewhere it isn't. > > Exactly, this was also my solution. > > >> The dummy device is not their parent - host1x is. There's no > >> connection between the dummy and the real client devices. > > > > It's quite possible for the client devices to ask their actual parent > > (host1x) for the tegradrm struct device *, by calling a host1x API, and > > have host1x implement that API by returning the dummy/virtual device > > that it created. That should be just 1-2 lines of code to implement in > > host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED > > when appropriate. > > My solution was to just have one global, and an getter for the global. > Instead of drvdata, the pointer is retrieved with the getter. No need > for dummy device, or passing points between host1x and tegradrm. Okay, so we're back on the topic of using globals. I need to assert again that this is not an option. If we were to use globals, then we could just as well leave out the dummy device and just do all of that in the tegra-drm driver's initialization function. The whole point of all this is to link the host1x and it's particular tegra-drm instance. I will see if I can find the time to implement this in the existing driver, so that the host1x code that you want to remove registers the tegra-drm dummy device and the tegra-drm devices use the accessors as discussed previously to access host1x and the dummy device. Once that is implemented, removing the original host1x implementation should be much easier since you will only have to keep the dummy device instantiation along with the one or two accessor functions. Thierry pgpGKpIiYTTTM.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 16.12.2012 14:16, Thierry Reding wrote: > Okay, so we're back on the topic of using globals. I need to assert > again that this is not an option. If we were to use globals, then we > could just as well leave out the dummy device and just do all of that in > the tegra-drm driver's initialization function. > The whole point of all this is to link the host1x and it's particular > tegra-drm instance. I will see if I can find the time to implement this > in the existing driver, so that the host1x code that you want to remove > registers the tegra-drm dummy device and the tegra-drm devices use the > accessors as discussed previously to access host1x and the dummy device. > Once that is implemented, removing the original host1x implementation > should be much easier since you will only have to keep the dummy device > instantiation along with the one or two accessor functions. I'm not sure what you have discussed with Stephen, so I might be missing the reason why this is a problem that needs to be solved with new dependency between tegradrm and host1x instead of locally in tegradrm driver itself. As far I remember, we had two reasons for discussing the dummy device. First reason is for DC, HDMI probe calls to find the global data. Second is giving something to DRM framework's drm_platform_init(). The easiest way to solve the probe problem is just to have a tegradrm accessor for the global data in the way I proposed in the patchset. Dummy device doesn't help there, as the dummy device is in no relationship to DC and HDMI. Sure we could tell DC to ask its parent (host1x), and call host1x driver with platform_device pointer found that way, and host1x would return a pointer to tegradrm's data. Hanging the data onto host1x driver is just a more complicated way of implementing global data, and it's breaking the responsibility split between host1x driver and tegradrm. To me, host1x driver is responsible of host1x, and tegradrm is responsible of the DRM interface and everything related to that. All other parts of code use drm_device->dev_private for getting the global data, so the access problem is only for the probe calls. drm_platform_init() needing a device is another problem. drm_platform_init() leads to a call to the CMA FB helper. That again needed the coherent_dma_mask set for the device give to it. I guess that problem can be solved by just setting the mask to 0x. But that is still something that can be handled inside tegradrm without involving the host1x driver. Terje ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57670] segfault with etqw.demo
https://bugs.freedesktop.org/show_bug.cgi?id=57670 --- Comment #1 from Laurent carlier --- Created attachment 71589 --> https://bugs.freedesktop.org/attachment.cgi?id=71589&action=edit patch to fix segfault Apply this patch to s2tc library to fix segfault with etqw and quake4 -- 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 58354] [bisected] r600g locks up in Unigine Tropics with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58354 Alexandre Demers changed: What|Removed |Added Summary|r600g locks up in Unigine |[bisected] r600g locks up |Tropics with drm-next |in Unigine Tropics with ||drm-next --- Comment #1 from Alexandre Demers --- 33e5467871b3007c4e6deea95b2cac38a55ff9f5 is the first bad commit commit 33e5467871b3007c4e6deea95b2cac38a55ff9f5 Author: Alex Deucher Date: Mon Oct 22 12:22:39 2012 -0400 drm/radeon: use DMA engine for VM page table updates on cayman/TN DMA engine has special packets to facilitate this and it also keeps the 3D engine free for other things. Signed-off-by: Alex Deucher -- 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 58354] [bisected] r600g locks up in Unigine Tropics with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #2 from Alexandre Demers --- Obviously, this is on a 6950 Cayman. -- 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
[PATCH] drm: Only evict the blocks required to create the requested hole
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas implicitly
which swaps the end address for size (with a potential overflow) and
effectively causes the eviction code to clobber almost all earlier
buffers above the evictee.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 58 +-
include/drm/drm_mm.h |2 +-
2 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 7103aa3..c93729c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -421,6 +421,25 @@ static int check_free_hole(unsigned long start, unsigned
long end,
return end >= start + size;
}
+static int adjust_free_hole(unsigned long *start, unsigned long *end,
+ unsigned long size, unsigned alignment)
+{
+ if (*end - *start < size)
+ return 0;
+
+ if (alignment) {
+ unsigned tmp = *start % alignment;
+ if (tmp)
+ *start += alignment - tmp;
+ }
+
+ if (*end - *start < size)
+ return 0;
+
+ *end = *start + size;
+ return 1;
+}
+
struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm *mm,
unsigned long size,
unsigned alignment,
@@ -545,7 +564,7 @@ void drm_mm_init_scan(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_check_range = 0;
mm->prev_scanned_node = NULL;
}
@@ -572,7 +591,7 @@ void drm_mm_init_scan_with_range(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_start = start;
mm->scan_end = end;
mm->scan_check_range = 1;
@@ -591,8 +610,6 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
struct drm_mm *mm = node->mm;
struct drm_mm_node *prev_node;
unsigned long hole_start, hole_end;
- unsigned long adj_start;
- unsigned long adj_end;
mm->scanned_blocks++;
@@ -612,24 +629,21 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
hole_start = drm_mm_hole_node_start(prev_node);
hole_end = drm_mm_hole_node_end(prev_node);
- adj_start = hole_start;
- adj_end = hole_end;
-
if (mm->color_adjust)
- mm->color_adjust(prev_node, mm->scan_color, &adj_start,
&adj_end);
+ mm->color_adjust(prev_node, mm->scan_color,
+&hole_start, &hole_end);
if (mm->scan_check_range) {
- if (adj_start < mm->scan_start)
- adj_start = mm->scan_start;
- if (adj_end > mm->scan_end)
- adj_end = mm->scan_end;
+ if (hole_start < mm->scan_start)
+ hole_start = mm->scan_start;
+ if (hole_end > mm->scan_end)
+ hole_end = mm->scan_end;
}
- if (check_free_hole(adj_start, adj_end,
- mm->scan_size, mm->scan_alignment)) {
+ if (adjust_free_hole(&hole_start, &hole_end,
+mm->scan_size, mm->scan_alignment)) {
mm->scan_hit_start = hole_start;
- mm->scan_hit_size = hole_end;
-
+ mm->scan_hit_end = hole_end;
return 1;
}
@@ -668,16 +682,8 @@ int drm_mm_scan_remove_block(struct drm_mm_node *node)
INIT_LIST_HEAD(&node->node_list);
list_add(&node->node_list, &prev_node->node_list);
- /* Only need to check for containement because start&size for the
-* complete resulting free block (not just the desired part) is
-* stored. */
- if (node->start >= mm->scan_hit_start &&
- node->start + node->size
- <= mm->scan_hit_start + mm->scan_hit_size) {
- return 1;
- }
-
- return 0;
+ return (node->start + node->size >= mm->scan_hit_start &&
+ node->start <= mm->scan_hit_end);
}
EXPORT_SYMBOL(drm_mm_scan_remove_block);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 9a08a45..9e06ca1 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -70,7 +70,7 @@ struct drm_mm {
unsigned long scan_color;
unsigned long scan_size;
unsigned long scan_hit_start;
- unsigned scan_hit_size;
+ unsigned long scan_hit_end;
unsigned scann
[Bug 58372] New: [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 Priority: medium Bug ID: 58372 Assignee: dri-devel@lists.freedesktop.org Summary: [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next Severity: normal Classification: Unclassified OS: All Reporter: ser...@hosca.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 71594 --> https://bugs.freedesktop.org/attachment.cgi?id=71594&action=edit dmesg with drm-next Using linus + airlied's drm-next produces garbled screen and gpu crashes after login. Using mesa git and xf86-ati git. -- 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 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #1 from Serkan Hosca --- Created attachment 71595 --> https://bugs.freedesktop.org/attachment.cgi?id=71595&action=edit dmesg with linus git -- 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 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #2 from Serkan Hosca --- Forgot to add, using lightdm + cinnamon on arch -- 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: new userspace API approaches atomic *
On Sun, Dec 16, 2012 at 12:11:13PM +0100, Daniel Vetter wrote: > On Sun, Dec 16, 2012 at 7:04 AM, Dave Airlie wrote: > > The "I can't test it" argument doesn't fly with me, you are creating a > > new API that adds a useful feature, it should be possible to get a few > > other driver maintainers interested, but also I'd hope that most of > > the ideas for converting to a new API would be mechanical in a lot of > > ways. Atomic semantics aren't hw specific from what i can see, if they > > are then the API is obviously wrong. > > For actual semantics I think we need to split the discussion into the > modeset and the pageflip part: > > - For modeset it shouldn't be hard to whip up some helpers which use > the current crtc helpers to do modeset changes accross multiple crtcs. > Like currently, drivers might refuse a modeset in one of their > callbacks, and that might only happen once the hw touching has started > already. Which means we can't efficiently implement a check flag mode > for those drivers. But otoh if they have global constraints they might > want to implement their own magic like i915. Or we could add a new > global ->check_modeset callback which checks for these (after > crtc/encoders have done the respective checking). Like I said, my initial version was based on drm_crtc_helper, so it would work as a starting point. > - For pageflip things are a bit messier, since we really should aim > for all changes to be applied on the same vblank. But luckily the set > of drivers which support more than one of cursors/pageflips/plane is > manageable, and most are just cursosrs+pageflip. Since I've just read > through them all I think it shouldn't be too hard to whip up a > (totally broken) patch for each of them to guide driver maintainers. OK so finally a volunteer to help. Great ;) > So imo to really exploit atomic modeset/pageflip we need special > support from each driver to check a given configuration before > committing it (this also seems to be the only sane way for userspace > to figure out what works and what doesn't without causing tons of > flickering). And doing that for each driver is obviously out of the > question. > > But reworking internal interfaces and converting drivers in a > simplistic fashion which assume that no global state checking is > required (assuming e.g. for modesets the current crtc/encoder checks > are good enough) is a requirement I agree with. Which is why I think > we should aim first for something much more restricted than the > current "every possible feature for kms" approach, for example just > pageflips on one crtc ... Such a restricted feature is useless for any real world usage. At the very least you need to enable/disable planes as well as do pageflips. And you probably want to move/resize active planes too. Since we already know that there are a lot more properties we want to manipulate atomically, adding a "pageflip only" restrictions to the API itself is simply counter productive. We will have to replace the API immediately anyway, and then we need another year or so of bikeshedding to get the replacement API in. Let's just get it in from the start. In many cases once you've implemented the basic atomic semantics, adding other properties to be included in the atomic update is trivial. Often it's just a matter of setting some extra bits, or including some extra registers in the atomic commit. I have in mind several plane properties I want to add to i915, which I could do trivially. But doing that before the basic feature is merged would bloat the patchset further. If you want to restrict which properties you allow to be changed in one atomic operation, you can do that trivially in the driver itself. > From an i915 perspective I'm leaning towards pageflips because things > are much simpler there (similar to all other drivers). It's much more > immediately useful for us and for atomic modeset our driver-internal > code is simple not yet ready to do global state-checking up-front > before we start touching hw - we need to move around quite a bit of > code until that's doable. So atomic modeset won't really help us yet > to for 3-pipe pll sharing and similar shared global resources issues > and how to correctly expose them to userspace. It does make life for userspace more complex because userspace can't setup planes as a part of a modeset. Also all scanout duties should be moved over to drm_plane at some point, so planes will have to be part of the modeset eventually. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: new userspace API approaches atomic *
On Sun, Dec 16, 2012 at 04:04:01PM +1000, Dave Airlie wrote: > > There are several problems with this: > > > > - I can't test other drivers > > > > - I don't have the knowledge or inclination to implement atomic semantics > > for everyone's favorite hardware, and without that there's little > > point in doing the work. Some of my initial code was layered on top of > > drm_crtc_helper though, so it might be possible to use that as a basis > > for an atomic helper, but there would actually be no benefit from > > using it apart from allowing those drivers to respond to the atomic > > ioctl. But we wouldn't use any of that w/ i915, so it would be better is > > someone else does that part. > > The "I can't test it" argument doesn't fly with me, you are creating a > new API that adds a useful feature, it should be possible to get a few > other driver maintainers interested, but also I'd hope that most of > the ideas for converting to a new API would be mechanical in a lot of > ways. Atomic semantics aren't hw specific from what i can see, if they > are then the API is obviously wrong. How/when the hardware state needs to be updated to guarantee atomic behaviour _is_ hardware specific. I suppose eventually you could distill it down to a handful of models that could cover most hardware. But note that on some hardware even different scanout engines on the same chip behave differently, so to update them atomically with each other is going be a delicate dance. > > - Replacing all the legacy codepaths with new code in one go increases the > > chance that we get a regression, and then we have no choice but to > > back out the whole thing. Also it seems that no-one apart from Rob has > > even looked at the code, so it seems likely that there would be heavy > > opposition to replacing the current code with something new. > > I never said one go, I said before pushing the new API. This means you > get everything internally converted in the drm/driver interface, drop > the old drm/driver interface, and the new userspace API. At least > regressions should be a lot more obvious and we can port a driver at a > time if needed. We can also block new drivers from using the old > interfaces from being merged. Now you're confusing me. How can we port one driver at a time if we can't merge the feature before all drivers are ported? Or do you mean porting one driver at a time in some staging tree, and then once all are ported merge the whole thing? Doable, but painful due to code flux. > > - These are the reasons I would like to merge the thing without touching > > the legcay codepaths too much. Then each driver author could move their > > code over the new APIs. I'm willing to help of course, but the driver > > authors are in a much better position to make something that actually > > works for their hardware. > > Yup thats what you want, but you don't want to bring in the new API > before this happens, since only once you've ported a bunch of drivers > will you know the API actually works. You mean the external API? I know it works. It makes no assumptions about the hardware behaviour. It even resembles OpenWF Display quite decently, which should reassure some people. It's entirely property based, so if it wouldn't work then the current property API would be totally broken as well. If you mean the internal API, then it will also work because it makes no assumptions either. It's a transaction type of thing, which just builds the state, and finally commits it. How you do that commit part is hardware specific, but the input for the commit will be just the new device state, so each driver has full freedom to handle it as best they see fit. > >> f) get b merged standalone, transition phase is fine, but every driver > >> needs to be ported before the API > >> goes in. > > > > Why? The current drivers are not using the same APIs internally anyway. > > i915 doesn't use drm_crtc_helper for example. You didn't demand that > > Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other > > drivers, did you? > > > > helpers are not APIs. The API from drm_crtc.c to driver is the main > modesetting API, for instance Daniel is trying to stop taking locks in > the drm_crtc side of things, to do this he is going and reimplementing > lots of bits in lots of drivers at the same time. I know. But none of that requires writing a lot of hardware specific logic. > > Right, so either I rewrite the modeset and pageflip code for all drivers, > > or I wait until all the driver authors decide to help me. The first one > > will take approximately five years given that I don't know the hardware > > and I have other tasks on my plate, and based on the past interest the > > second one doesn't seem likely to happen anytime soon > > > > All this make me think I should just try to push it as an i915 private > > feature. Damn the other drivers. That should make the management happy too > > since everyone that needs
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #35 from Myckel Habets --- (In reply to comment #30) > make distclean > git clean -dfx > git reset --hard fa58644855e44830e0b91dc627703c236fa6712a Ok, did this and rebuild everything, but problem stays in my case. -- 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 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #27 from Alexandre Demers ---
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > So about this locking piglit test (depthstencil-render-miplevels 146
> > > s=z24_s8_d=z32f_s8), I've been able to track it down to:
> > > line 218: piglit_report_result(PIGLIT_SKIP);
> >
> > How did you determine that? It's weird, I wouldn't expect a skipped test to
> > produce any actual GPU rendering.
>
> I used gdb and step into the code until it locked. It gets out at level 0,
> after going through:
>
> /**
> * Attach the proper miplevel of each texture to the framebuffer
> */
> void
> set_up_framebuffer_for_miplevel(int level)...
>
> Before this call, there is a framebuffer initialization:
> GLuint fbo;
> glGenFramebuffers(1, &fbo);
> glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
> glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
>
> for (int level = 0; level <= max_miplevel; ++level) {
> set_up_framebuffer_for_miplevel(level);
It seems that with latest mesa, drm, xf86 and kernel 3.7.0-rc7-71633-g3b6b59b
from drm-next, it doesn't fail on this test anymore. It does lock however on a
different one. I'll debug it and see where it locks.
--
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 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #3 from Alexandre Demers --- If you can, could you bisect? -- 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 58033] [r300g] Black gap artifacts when playing WoW
https://bugs.freedesktop.org/show_bug.cgi?id=58033 --- Comment #5 from Chris Rankin --- (In reply to comment #4) > Can you bisect? Apparently, this is the bad commit: 39737e17e7a61535a35669756161005a7a5c887b is the first bad commit commit 39737e17e7a61535a35669756161005a7a5c887b Author: Marek Olšák Date: Mon Dec 3 01:26:22 2012 +0100 st/dri: always allocate private depth-stencil buffers This disables DRI2 sharing of zbuffers. The window zbuffer is allocated just like any other texture - through resource_create. The idea of allocating a zbuffer through DRI2 isn't very useful with MSAA, where a single-sample zbuffer is useless. IIRC, the Intel driver does the same thing. Reviewed-by: Brian Paul :04 04 e8045e2d2c7e9a1ebd6eb1f22c93b97b9c3e8ce7 4deb5755e011d592366e6140bf385bfefe157f3f Msrc -- 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 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #14 from Andre 2012-12-16 23:22:54 --- I have tried the new kernel 3.7 and have the same behavior as described in the initial bug report. /var/log/messages http://pastebin.com/a4EN1kmL I will recompile the kernel with debugging enabled to maybe get a more detailed kernel.log. -- 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 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors
https://bugs.freedesktop.org/show_bug.cgi?id=57350 --- Comment #2 from Rui Salvaterra --- Created attachment 71608 --> https://bugs.freedesktop.org/attachment.cgi?id=71608&action=edit dmesg -- 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 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #4 from Serkan Hosca --- bisect result: 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d is the first bad commit commit 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d Author: Jerome Glisse Date: Wed Nov 28 13:47:55 2012 -0500 drm/radeon: use cached memory when evicting for vram on non agp Force the use of cached memory when evicting from vram on non agp hardware. Also force write combine on agp hw. This is to insure the minimum cache type change when allocating memory and improving memory eviction especialy on pci/pcie hw. Signed-off-by: Jerome Glisse :04 04 c917ebaa086f5efea9928e707d97bdb90ef6919935d6eaaa7b1115d9e3696c200da139695c19ad15 M drivers -- 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 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors
https://bugs.freedesktop.org/show_bug.cgi?id=57350 --- Comment #3 from Rui Salvaterra --- This also happens on my nVIDIA ION (MCP79) system, Unity Dash graphics become severely corrupted. I'm currently running Ubuntu 12.10 with the xorg edgers ppa. My dmesg is attached. -- 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 58378] New: Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 Priority: medium Bug ID: 58378 Assignee: dri-devel@lists.freedesktop.org Summary: Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version Severity: critical Classification: Unclassified OS: Linux (All) Reporter: henrique.ribeiro.d...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/other Product: DRI Created attachment 71610 --> https://bugs.freedesktop.org/attachment.cgi?id=71610&action=edit stack trace I have a NVIDIA GeForce 8400M G graphics card. I've been using nouveau drive for a long time without any kind of problems. After upgrade the kernel to 3.7.0 version I have a lot of issues. After login in to the system and after having spent some time using the system the graphics are corrupted. The graphics show up with mixed colors. -- 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 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #1 from Henrique Dias --- Created attachment 71612 --> https://bugs.freedesktop.org/attachment.cgi?id=71612&action=edit Screenshot Screenshot showing the problem. -- 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 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #5 from Alex Deucher --- Does your kernel tree have this patch? http://cgit.freedesktop.org/~airlied/linux/commit/drivers/gpu/drm/radeon/radeon_object.c?h=drm-next&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb -- 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 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #15 from Alex Deucher 2012-12-17 00:34:33 --- Does this patch fix the issue? http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a -- 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 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors
https://bugs.freedesktop.org/show_bug.cgi?id=57350 --- Comment #4 from David Herrmann --- I can provoke this bug with a simple drmModeSetCursor() or drmModeMoveCursor(). The cursor images have a horizontal black stripe (not always). Position varies on my machine. Using 3D acceleration without cursors works perfectly well (although starting mplayer caused a deadlock on my machine). It's also a nv50 card. I tried bisecting it and it turns out the memory-manager rewrite caused it (as reported on IRC). I was unable to revert the commit on top of 3.7 as it is quite complex. -- 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
[RFC] Complete experimental render node implementation
Hi, Following to my shared talk with krh, danvet and Timothée Ravier @ XDC2012, I have actually taken the time to start fixing some security holes found in the graphics stack. Today, I would like to request your comments on the render node patchset. Keep in mind that I am not asking for inclusion. However, I know this patchset works on my nvidia card and I would like to know if anyone has anything against this architecture. ## DRM If I'm not mistaken, the idea originated from airlied which got simplified later by krh. Both only provided drm patches. Here is what I did: - I took krh's patchset - rebased it on top on drm 3.7-rc8 - added support for Nouveau - fixed a few bugs along the way (as stated in the commit logs) The kernel can be found here: https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes The patches will also be sent in reply, to let you comment on specific parts of the patches. ## Libdrm Here are the two main goals of this patchset: - Add a new symbol called drmOpenType that allows to open a specific type of device (usual node, render node) - Add a new symbol called drmGetSameDeviceButType to get the path to the same drm_device but with a different type The patches are available here: http://cgit.freedesktop.org/~mperes/drm/ ## DRI2Proto What we want here is to let the ddx send the render node instead of the usual one. However, authentication is not necessary and not shouldn't be done on a render node. This modification to DRI2Proto adds a boolean in the Connection response to tell the dri2 client that no authentication is required. The patches are available here: http://cgit.freedesktop.org/~mperes/dri2proto/ ## XServer The X-Server is responsible for collecting the DRI2 informations from the ddx. In this patch, we provide the way for the ddx to specify whether the DRI2 client should authenticate or not. The patches are available here: http://cgit.freedesktop.org/~mperes/xserver/ ## xf86-video-nouveau In this patch, we simply tell the DRI2 extension to use the render node if available (using drmGetSameDeviceButType), and if it is the case, we set the "require_authentication" attribute to 0. The patches are available here: http://cgit.freedesktop.org/~mperes/xf86-video-nouveau/ ## Mesa In this patch, I simply check whether I should authenticate or not using the information from the DRI2 protocol. The patches are available here: http://cgit.freedesktop.org/~mperes/mesa/ Cheers, Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fan control in nouveau driver with geforce 9600gt
On 13/12/2012 11:02, Ozan Çağlayan wrote: Hi, I have a geforce 9600gt (nv94) display adapter which has its fan running at 100% speed. Yesterday I've compiled and booted with the latest nouveau-2.6 tree. sensors from lm_sensors can correctly acquire GPU temperature and PWM speed but as far as I understood setting the speed is still not supported, am I right? dmesg lists 3 performance levels with 100% fanspeed all of them. Are there any other things that I can try? I saw a prlvl_wr module parameter which enables setting performance level but it is indicated that it is dangerous. Anyway, anything that I can try and help you? Thanks. Hi Ozan, Please have a look at this documentation: http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal It will tell you how to use fan management on your card :) Please report back! I am interested in your results! Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Fix DRM_MINOR limits for control and render nodes
From: Kristian Høgsberg
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
v2: fix a off-by-one overlap as suggested by ihad...@research.bell-labs.com
Signed-off-by: Martin Peres
---
drivers/gpu/drm/drm_stub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c236fd2..b56e977 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -107,10 +107,10 @@ static int drm_minor_get_id(struct drm_device *dev, int
type)
if (type == DRM_MINOR_CONTROL) {
base += 64;
-limit = base + 127;
+limit = base + 63;
} else if (type == DRM_MINOR_RENDER) {
base += 128;
-limit = base + 255;
+limit = base + 63;
}
again:
--
1.8.0.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/i915: Support render nodes
From: Kristian Høgsberg
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 61ae104..d0554b0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1851,7 +1851,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
@@ -1864,34 +1864,34 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer,
DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CO
[PATCH 4/4] drm/nouveau: Support render nodes
From: Martin Peres
Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index fdd8813..30def9b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -586,18 +586,18 @@ nouveau_drm_postclose(struct drm_device *dev, struct
drm_file *fpriv)
static struct drm_ioctl_desc
nouveau_ioctls[] = {
- DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam,
DRM_UNLOCKED|DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, nouveau_abi16_ioctl_setparam,
DRM_UNLOCKED|DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC,
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE,
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc,
DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC,
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free,
DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new,
DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf,
DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep,
DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini,
DRM_UNLOCKED|DRM_AUTH),
- DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_UNLOCKED|DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC,
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE,
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC,
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
};
static const struct file_operations
@@ -621,7 +621,7 @@ driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
- DRIVER_MODESET | DRIVER_PRIME,
+ DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,
.load = nouveau_drm_load,
.unload = nouveau_drm_unload,
--
1.8.0.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: Add support for render nodes
From: Kristian Høgsberg
This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering. The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only supports rendering
and limited buffer sharing. A render node can either export a buffer using
the gem flink mechanism, or it can import and export buffers using the
prime fd passing mechanism.
A render node is not associated with any drm master and does not require
the legacy authentication step. Render nodes can be used without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.
v2: Martin Peres
- Allow render nodes to access DRM_UNLOCKED IOCTLs)
Signed-off-by: Kristian Høgsberg
Signed-off-by: Martin Peres
---
drivers/gpu/drm/drm_drv.c | 13 +++--
drivers/gpu/drm/drm_fops.c | 9 ++---
drivers/gpu/drm/drm_pci.c | 9 +
include/drm/drmP.h | 3 +++
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index be174ca..7c74959 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -131,14 +131,14 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -427,9 +427,10 @@ long drm_ioctl(struct file *filp,
DRM_DEBUG("no function\n");
retcode = -EINVAL;
} else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))
||
- ((ioctl->flags & DRM_AUTH) && !file_priv->authenticated) ||
+ ((ioctl->flags & DRM_AUTH) && (file_priv->minor->type !=
DRM_MINOR_RENDER) && !file_priv->authenticated) ||
((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
- (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_CONTROL))) {
+ (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_CONTROL)) ||
+ (!(ioctl->flags & (DRM_RENDER_ALLOW | DRM_UNLOCKED)) &&
(file_priv->minor->type == DRM_MINOR_RENDER))) {
retcode = -EACCES;
} else {
if (cmd & (IOC_IN | IOC_OUT)) {
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..a27e8a4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -295,7 +295,7 @@ static int drm_open_helper(struct inode *inode, struct file
*filp,
/* if there is no current master make this fd it */
mutex_lock(&dev->struct_mutex);
- if (!priv->minor->master) {
+ if (!priv->minor->master && priv->minor->type != DRM_MINOR_RENDER) {
/* create a new master */
priv->minor->master = drm_master_create(priv->minor);
if (!priv->minor->master) {
@@ -334,10 +334,12 @@ static int drm_open_helper(struct inode *inode, struct
file *filp,
}
}
mutex_unlock(&dev->struct_mutex);
- } else {
+ } else if (priv->minor->type != DRM_MINOR_RENDER) {
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
mutex_unlock(&dev->struct_mutex);
+ } else {
+ mutex_unlock(&dev->struct_mutex);
}
mutex_lock(&dev->struct_mutex);
@@ -529,7 +531,8 @@ int drm_release(struct inode *inode, struct file *filp)
iput(container_of(dev->dev_mapping, struct inode, i_data));
/* drop the reference held my the file priv */
- drm_master_put(&fi
[PATCH 2/5] drm: generate the path of a different device type for the same drm device
From: Martin Peres
Signed-off-by: Martin Peres
---
.gitignore | 1 +
tests/Makefile.am| 1 +
tests/same_device_but_type.c | 52
xf86drm.c| 44 +
xf86drm.h| 1 +
5 files changed, 99 insertions(+)
create mode 100644 tests/same_device_but_type.c
diff --git a/.gitignore b/.gitignore
index 28c77c5..318e129 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@ tests/gem_readwrite
tests/openclose
tests/setversion
tests/updatedraw
+tests/same_device_but_type
tests/modeprint/modeprint
tests/modetest/modetest
tests/kmstest/kmstest
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a3a59bd..ddc73ca 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -46,6 +46,7 @@ TESTS = \
setversion \
updatedraw \
name_from_fd\
+ same_device_but_type\
$(NULL)
SUBDIRS += vbltest $(NULL)
diff --git a/tests/same_device_but_type.c b/tests/same_device_but_type.c
new file mode 100644
index 000..f35951f
--- /dev/null
+++ b/tests/same_device_but_type.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright © 2012
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Martin Peres
+ *
+ */
+
+#include
+#include
+#include
+#include "drmtest.h"
+
+/**
+ * Checks drmGetSameDeviceButType
+ */
+int main(int argc, char **argv)
+{
+ int fd, ret;
+ drm_set_version_t sv, version;
+ const char *name = "/dev/dri/card0";
+ char *render;
+ int i;
+
+ render = drmGetSameDeviceButType(name, DRM_NODE_RENDER);
+ assert(strcmp(render, name) == 0);
+ drmFree(render);
+
+ render = drmGetSameDeviceButType("/no_device", DRM_NODE_RENDER);
+ assert(render == NULL);
+
+ return 0;
+}
diff --git a/xf86drm.c b/xf86drm.c
index eb0549d..cca8d8a 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2602,6 +2602,50 @@ char *drmGetDeviceNameFromFd(int fd)
return NULL;
}
+/**
+ * Generate the path to a different type (render node, control node, etc...)
+ * but for the same actual drm device.
+ *
+ * \param device a path to an existing drm device type.
+ * \param type the new type that should be returned.
+ *
+ * \return the path to the same drm device but to a different type if success.
+ * NULL otherwise.
+ */
+char *drmGetSameDeviceButType(const char *device, int type)
+{
+ char base_path[64], name[64], *path, *device_name;
+ struct stat sbuf;
+ int i;
+
+ /* get the device name (ie /card0) */
+ device_name=strrchr(device, '/');
+ if (!device_name)
+ return NULL;
+
+ /* get the device's drm folder (ie /sys/class/drm/card0/device/drm */
+ snprintf(base_path, sizeof(base_path), "/sys/class/drm/%s/device/drm",
+device_name + 1);
+
+ /* search for the type in the base path */
+ device_name = NULL;
+ for (i = 0; i < DRM_MAX_MINOR; i++) {
+ drmDevicePath(name, sizeof(name), base_path, type, i);
+ if (stat(name, &sbuf) == 0) {
+ device_name = strrchr(name, '/');
+ break;
+ }
+ }
+ if (!device_name)
+ return NULL;
+
+ /* create a more appropriate path for the device (/dev/dri/card0) */
+ path = malloc(64);
+ snprintf(path, 64, "%s/%s", DRM_DIR_NAME, device_name + 1);
+
+ return path;
+}
+
int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int *prime_fd)
{
struct drm_prime_handle args;
diff --git a/xf86drm.h b/xf86drm.h
index d727ce1..658dfd7 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -733,6 +733,7
[PATCH 3/5] nouveau: Allow opening a specific type of drm device
From: Martin Peres
Signed-off-by: Martin Peres
---
nouveau/nouveau.c | 11 +--
nouveau/nouveau.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 940d933..1402852 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -128,9 +128,10 @@ nouveau_device_wrap(int fd, int close, struct
nouveau_device **pdev)
}
int
-nouveau_device_open(const char *busid, struct nouveau_device **pdev)
+nouveau_device_open_type(const char *busid, struct nouveau_device **pdev,
+int type)
{
- int ret = -ENODEV, fd = drmOpen("nouveau", busid);
+ int ret = -ENODEV, fd = drmOpenType("nouveau", busid, type);
if (fd >= 0) {
ret = nouveau_device_wrap(fd, 1, pdev);
if (ret)
@@ -139,6 +140,12 @@ nouveau_device_open(const char *busid, struct
nouveau_device **pdev)
return ret;
}
+int
+nouveau_device_open(const char *busid, struct nouveau_device **pdev)
+{
+ return nouveau_device_open_type(busid, pdev, DRM_NODE_RENDER);
+}
+
void
nouveau_device_del(struct nouveau_device **pdev)
{
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index c42eea7..cbc0dc9 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -66,6 +66,8 @@ struct nouveau_device {
};
int nouveau_device_wrap(int fd, int close, struct nouveau_device **);
+int nouveau_device_open_type(const char *busid, struct nouveau_device **pdev,
+ int type);
int nouveau_device_open(const char *busid, struct nouveau_device **);
void nouveau_device_del(struct nouveau_device **);
int nouveau_getparam(struct nouveau_device *, uint64_t param, uint64_t
*value);
--
1.8.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: allow opening the drm device by type (control, render or render_only)
From: Martin Peres
Signed-off-by: Martin Peres
---
tests/name_from_fd.c | 19 ++
xf86drm.c| 105 ---
xf86drm.h| 7
3 files changed, 100 insertions(+), 31 deletions(-)
diff --git a/tests/name_from_fd.c b/tests/name_from_fd.c
index 330c8ff..8e1a197 100644
--- a/tests/name_from_fd.c
+++ b/tests/name_from_fd.c
@@ -41,17 +41,20 @@ int main(int argc, char **argv)
{
int fd, ret;
drm_set_version_t sv, version;
- const char *name = "/dev/dri/card0";
+ const char *name[2] = { "/dev/dri/card0", "/dev/dri/renderD128" };
char *v;
+ int i;
- fd = open("/dev/dri/card0", O_RDWR);
- if (fd == -1)
- return 0;
+ for (i = 0; i < 2; i++) {
+ fd = open(name[i], O_RDWR);
+ if (fd > 0) {
+ v = drmGetDeviceNameFromFd(fd);
+ close(fd);
+ assert(v != NULL);
+ assert(strcmp(name[i], v) == 0);
+ }
+ }
- v = drmGetDeviceNameFromFd(fd);
- close(fd);
-
- assert(strcmp(name, v) == 0);
drmFree(v);
return 0;
diff --git a/xf86drm.c b/xf86drm.c
index 2a74c80..eb0549d 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -85,9 +85,6 @@
#define DRM_MSG_VERBOSITY 3
-#define DRM_NODE_CONTROL 0
-#define DRM_NODE_RENDER 1
-
static drmServerInfoPtr drm_server_info;
void drmSetServerInfo(drmServerInfoPtr info)
@@ -286,10 +283,51 @@ static int chown_check_return(const char *path, uid_t
owner, gid_t group)
}
/**
+ * Generate the device name according to its type.
+ *
+ * \param buf buffer that will hold the device path after the call.
+ * \param len length of the buffer.
+ * \param base_dir base directory used to generate the path. If NULL, it
+ *defaults to DRM_DIR_NAME ("/dev/dri").
+ * \param type the type of device (control, render or render_only).
+ * \param minor number of the device.
+ */
+static void drmDevicePath(char *buf, size_t len, const char *base_dir, int
type,
+ int minor)
+{
+ const char *dev_name = NULL;
+
+ switch (type)
+ {
+ case DRM_NODE_CONTROL:
+ dev_name = DRM_CONTROL_DEV_NAME;
+ /* we do not increase minor by 64 not to change the current
+* behaviour even though I couldn't find who uses this type!
+*/
+ break;
+ case DRM_NODE_RENDER_ONLY:
+ dev_name = DRM_RENDER_ONLY_DEV_NAME;
+ minor += 128;
+ break;
+ default:
+ drmMsg("drmDevicePath: unknown type %d, default to render.\n",
type);
+ case DRM_NODE_RENDER:
+ dev_name = DRM_DEV_NAME;
+ break;
+ }
+
+ if (!base_dir)
+ base_dir = DRM_DIR_NAME;
+
+ snprintf(buf, len, dev_name, base_dir, minor);
+}
+
+/**
* Open the DRM device, creating it if necessary.
*
* \param dev major and minor numbers of the device.
* \param minor minor number of the device.
+ * \param type the type of device we want to open (control, render or
render_only).
*
* \return a file descriptor on success, or a negative value on error.
*
@@ -308,7 +346,7 @@ static int drmOpenDevice(long dev, int minor, int type)
uid_t user= DRM_DEV_UID;
gid_t group = DRM_DEV_GID, serv_group;
-sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
minor);
+drmDevicePath(buf, sizeof(buf), NULL, type, minor);
drmMsg("drmOpenDevice: node name is %s\n", buf);
if (drm_server_info) {
@@ -417,7 +455,7 @@ static int drmOpenMinor(int minor, int create, int type)
if (create)
return drmOpenDevice(makedev(DRM_MAJOR, minor), minor, type);
-sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
minor);
+drmDevicePath(buf, sizeof(buf), NULL, type, minor);
if ((fd = open(buf, O_RDWR, 0)) >= 0)
return fd;
return -errno;
@@ -472,7 +510,7 @@ int drmAvailable(void)
*
* \sa drmOpenMinor() and drmGetBusid().
*/
-static int drmOpenByBusid(const char *busid)
+static int drmOpenByBusid(const char *busid, int type)
{
inti, pci_domain_ok = 1;
intfd;
@@ -481,7 +519,7 @@ static int drmOpenByBusid(const char *busid)
drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
for (i = 0; i < DRM_MAX_MINOR; i++) {
- fd = drmOpenMinor(i, 1, DRM_NODE_RENDER);
+ fd = drmOpenMinor(i, 1, type);
drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
if (fd >= 0) {
/* We need to try for 1.4 first for proper PCI domain support
@@ -531,7 +569,7 @@ static int drmOpenByBusid(const char *busid)
*
* \sa drmOpenMinor(), drmGetVersion() and drmGetBusid().
*/
-static int drmOpenByName(const char *name)
+static int drmO
[PATCH 4/5] nouveau: bump version to 2.4.34 for release
From: Martin Peres
Signed-off-by: Martin Peres
---
nouveau/libdrm_nouveau.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 6170613..f3b99cf 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@
Name: libdrm_nouveau
Description: Userspace interface to nouveau kernel DRM services
-Version: 2.4.33
+Version: 2.4.34
Libs: -L${libdir} -ldrm_nouveau
Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/nouveau
Requires.private: libdrm
--
1.8.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] configure.ac: bump version to 2.4.41 for release
From: Martin Peres
Signed-off-by: Martin Peres
---
configure.ac | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0c19929..df56066 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([libdrm],
-[2.4.40],
+[2.4.41],
[https://bugs.freedesktop.org/enter_bug.cgi?product=DRI],
[libdrm])
@@ -68,10 +68,6 @@ LT_PREREQ([2.2])
LT_INIT([disable-static])
-PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)
-AC_SUBST(PTHREADSTUBS_CFLAGS)
-AC_SUBST(PTHREADSTUBS_LIBS)
-
pkgconfigdir=${libdir}/pkgconfig
AC_SUBST(pkgconfigdir)
AC_ARG_ENABLE([udev],
--
1.8.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dri2proto: add device_requires_auth in xDRI2ConnectReply to support render nodes
From: Martin Peres
Signed-off-by: Martin Peres
---
dri2proto.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/dri2proto.h b/dri2proto.h
index 128b807..4d11ba7 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -35,7 +35,7 @@
#define DRI2_NAME "DRI2"
#define DRI2_MAJOR 1
-#define DRI2_MINOR 4
+#define DRI2_MINOR 5
#define DRI2NumberErrors 0
#define DRI2NumberEvents 2
@@ -109,10 +109,12 @@ typedef struct {
CARD32 length B32;
CARD32 driverNameLength B32;
CARD32 deviceNameLength B32;
-CARD32 pad2 B32;
-CARD32 pad3 B32;
+BYTEdeviceRequiresAuth;
+BYTEpad2;
+CARD16 pad3 B16;
CARD32 pad4 B32;
CARD32 pad5 B32;
+CARD32 pad6 B32;
} xDRI2ConnectReply;
#define sz_xDRI2ConnectReply 32
--
1.8.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dri2: add support for render nodes
From: Martin Peres
Signed-off-by: Martin Peres
---
glx/glxdri2.c | 3 ++-
hw/xfree86/dri2/dri2.c| 11 ++-
hw/xfree86/dri2/dri2.h| 8 ++--
hw/xfree86/dri2/dri2ext.c | 8 ++--
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index bce1bfa..ead24bc 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -929,6 +929,7 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
__GLXDRIscreen *screen;
size_t buffer_size;
ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+unsigned char devReqAuth;
screen = calloc(1, sizeof *screen);
if (screen == NULL)
@@ -936,7 +937,7 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
if (!xf86LoaderCheckSymbol("DRI2Connect") ||
!DRI2Connect(serverClient, pScreen, DRI2DriverDRI,
- &screen->fd, &driverName, &deviceName)) {
+ &screen->fd, &driverName, &deviceName, &devReqAuth)) {
LogMessage(X_INFO,
"AIGLX: Screen %d is not DRI2 capable\n", pScreen->myNum);
return NULL;
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 40963c3..6238caa 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -115,6 +115,7 @@ typedef struct _DRI2Screen {
int fd;
unsigned int lastSequence;
int prime_id;
+unsigned int device_requires_auth;
DRI2CreateBufferProcPtr CreateBuffer;
DRI2DestroyBufferProcPtr DestroyBuffer;
@@ -1317,7 +1318,8 @@ DRI2HasSwapControl(ScreenPtr pScreen)
Bool
DRI2Connect(ClientPtr client, ScreenPtr pScreen,
unsigned int driverType, int *fd,
-const char **driverName, const char **deviceName)
+const char **driverName, const char **deviceName,
+ unsigned char *deviceRequiresAuth)
{
DRI2ScreenPtr ds;
uint32_t prime_id = DRI2DriverPrimeId(driverType);
@@ -1503,6 +1505,13 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
ds->DestroyBuffer2 = info->DestroyBuffer2;
ds->CopyRegion2 = info->CopyRegion2;
}
+
+if (info->version >= 10) {
+ds->device_requires_auth = info->device_requires_auth;
+xf86DrvMsg(pScreen->myNum, X_INFO,
+ "[DRI2] The device %s authentication\n",
+ info->device_requires_auth?"requires":"doesn't require");
+}
/*
* if the driver doesn't provide an AuthMagic function or the info struct
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1e7afdd..f855565 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -205,7 +205,7 @@ typedef int (*DRI2GetParamProcPtr) (ClientPtr client,
/**
* Version of the DRI2InfoRec structure defined in this header
*/
-#define DRI2INFOREC_VERSION 9
+#define DRI2INFOREC_VERSION 10
typedef struct {
unsigned int version; /**< Version of this struct */
@@ -252,6 +252,9 @@ typedef struct {
DRI2CreateBuffer2ProcPtr CreateBuffer2;
DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
DRI2CopyRegion2ProcPtr CopyRegion2;
+
+ /* added in version 10 */
+ unsigned char device_requires_auth;
} DRI2InfoRec, *DRI2InfoPtr;
extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
@@ -264,7 +267,8 @@ extern _X_EXPORT Bool DRI2Connect(ClientPtr client,
ScreenPtr pScreen,
unsigned int driverType,
int *fd,
const char **driverName,
- const char **deviceName);
+ const char **deviceName,
+ unsigned char *deviceRequiresAuth);
extern _X_EXPORT Bool DRI2Authenticate(ClientPtr client, ScreenPtr pScreen,
uint32_t magic);
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index e1decec..1a78916 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -107,12 +107,14 @@ ProcDRI2Connect(ClientPtr client)
.sequenceNumber = client->sequence,
.length = 0,
.driverNameLength = 0,
-.deviceNameLength = 0
+.deviceNameLength = 0,
+.deviceRequiresAuth = 1
};
DrawablePtr pDraw;
int fd, status;
const char *driverName;
const char *deviceName;
+unsigned char deviceRequiresAuth;
REQUEST_SIZE_MATCH(xDRI2ConnectReq);
if (!validDrawable(client, stuff->window, DixGetAttrAccess,
@@ -120,11 +122,13 @@ ProcDRI2Connect(ClientPtr client)
return status;
if (!DRI2Connect(client, pDraw->pScreen,
- stuff->driverType, &fd, &driverName, &deviceName))
+ stuff->driverType, &fd, &driverName, &deviceName,
+&deviceRequiresAuth))
goto fail;
rep.driverNameLength = strlen(driverName);
rep.deviceNameLength = strlen(deviceName);
+rep.deviceRequiresAuth = deviceRequiresAuth;
rep.length = (rep.driverNameLength
[PATCH] add support for render nodes
From: Martin Peres
Signed-off-by: Martin Peres
---
configure.ac | 2 +-
src/nouveau_dri2.c | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ff9c337..61dfb01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,7 +67,7 @@ XORG_DRIVER_CHECK_EXT(XV, videoproto)
XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
# Checks for pkg-config packages
-PKG_CHECK_MODULES(LIBDRM_NOUVEAU, [libdrm_nouveau >= 2.4.25])
+PKG_CHECK_MODULES(LIBDRM_NOUVEAU, [libdrm_nouveau >= 2.4.34])
AC_SUBST(LIBDRM_NOUVEAU_CFLAGS)
AC_SUBST(LIBDRM_NOUVEAU_LIBS)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 036bcff..f852d8e 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -754,6 +754,7 @@ nouveau_dri2_init(ScreenPtr pScreen)
{ "nouveau", "nouveau" },
{ "nouveau_vieux", "nouveau_vieux" }
};
+ char *device_name = NULL;
if (pNv->Architecture >= NV_ARCH_30)
dri2.driverNames = drivernames[0];
@@ -788,6 +789,16 @@ nouveau_dri2_init(ScreenPtr pScreen)
dri2.DestroyBuffer2 = nouveau_dri2_destroy_buffer2;
dri2.CopyRegion2 = nouveau_dri2_copy_region2;
#endif
+
+#if DRI2INFOREC_VERSION >= 10
+ dri2.version = 10;
+
+ /* try to use the render node if available */
+ device_name = drmGetSameDeviceButType(pNv->drm_device_name,
DRM_NODE_RENDER_ONLY);
+ if (device_name)
+ dri2.deviceName = device_name;
+ dri2.device_requires_auth = (device_name == NULL);
+#endif
return DRI2ScreenInit(pScreen, &dri2);
}
--
1.8.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dri2: add support for render nodes
From: Martin Peres
Signed-off-by: Martin Peres
---
src/gallium/state_trackers/egl/x11/x11_screen.c | 2 +-
src/glx/dri2.c | 6 +-
src/glx/dri2.h | 3 ++-
src/glx/dri2_glx.c | 20 +++-
src/glx/dri_glx.c | 3 ++-
5 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/src/gallium/state_trackers/egl/x11/x11_screen.c
b/src/gallium/state_trackers/egl/x11/x11_screen.c
index effac0e..f648e91 100644
--- a/src/gallium/state_trackers/egl/x11/x11_screen.c
+++ b/src/gallium/state_trackers/egl/x11/x11_screen.c
@@ -234,7 +234,7 @@ x11_screen_probe_dri2(struct x11_screen *xscr, int *major,
int *minor)
/* get the driver name and the device name */
if (!xscr->dri_driver) {
if (!DRI2Connect(xscr->dpy, RootWindow(xscr->dpy, xscr->number),
- &xscr->dri_driver, &xscr->dri_device))
+ &xscr->dri_driver, &xscr->dri_device, NULL))
xscr->dri_driver = xscr->dri_device = NULL;
}
if (major)
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index bcd1f9c..1c2c91f 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -264,7 +264,8 @@ DRI2QueryVersion(Display * dpy, int *major, int *minor)
}
Bool
-DRI2Connect(Display * dpy, XID window, char **driverName, char **deviceName)
+DRI2Connect(Display * dpy, XID window, char **driverName, char **deviceName,
+unsigned char *deviceRequiresAuth)
{
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
xDRI2ConnectReply rep;
@@ -327,6 +328,9 @@ DRI2Connect(Display * dpy, XID window, char **driverName,
char **deviceName)
}
_XReadPad(dpy, *deviceName, rep.deviceNameLength);
(*deviceName)[rep.deviceNameLength] = '\0';
+
+ if (deviceRequiresAuth)
+ *deviceRequiresAuth = rep.deviceRequiresAuth;
UnlockDisplay(dpy);
SyncHandle();
diff --git a/src/glx/dri2.h b/src/glx/dri2.h
index a6fe66e..798cba1 100644
--- a/src/glx/dri2.h
+++ b/src/glx/dri2.h
@@ -53,7 +53,8 @@ DRI2QueryVersion(Display * display, int *major, int *minor);
extern Bool
DRI2Connect(Display * display, XID window,
-char **driverName, char **deviceName);
+char **driverName, char **deviceName,
+unsigned char *deviceRequiresAuth);
extern Bool
DRI2Authenticate(Display * display, XID window, drm_magic_t magic);
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 1b3cf2b..e6354ef 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1119,6 +1119,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
__GLXDRIscreen *psp;
struct glx_config *configs = NULL, *visuals = NULL;
char *driverName, *deviceName, *tmp;
+ unsigned char deviceRequiresAuth;
drm_magic_t magic;
int i;
@@ -1134,7 +1135,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
}
if (!DRI2Connect(priv->dpy, RootWindow(priv->dpy, screen),
- &driverName, &deviceName)) {
+ &driverName, &deviceName, &deviceRequiresAuth)) {
glx_screen_cleanup(&psc->base);
free(psc);
InfoMessageF("screen %d does not appear to be DRI2 capable\n", screen);
@@ -1179,16 +1180,17 @@ dri2CreateScreen(int screen, struct glx_display * priv)
goto handle_error;
}
- if (drmGetMagic(psc->fd, &magic)) {
- ErrorMessageF("failed to get magic\n");
- goto handle_error;
- }
+ if (deviceRequiresAuth) {
+ if (drmGetMagic(psc->fd, &magic)) {
+ ErrorMessageF("failed to get magic\n");
+ goto handle_error;
+ }
- if (!DRI2Authenticate(priv->dpy, RootWindow(priv->dpy, screen), magic)) {
- ErrorMessageF("failed to authenticate magic %d\n", magic);
- goto handle_error;
+ if (!DRI2Authenticate(priv->dpy, RootWindow(priv->dpy, screen), magic)) {
+ ErrorMessageF("failed to authenticate magic %d\n", magic);
+ goto handle_error;
+ }
}
-
/* If the server does not support the protocol for
* DRI2GetBuffersWithFormat, don't supply that interface to the driver.
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index ba8fda2..2a03c57 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -133,7 +133,8 @@ driGetDriverName(Display * dpy, int scrNum, char
**driverName)
}
else if (DRI2QueryExtension(dpy, &event, &error)) { /* DRI2 */
char *dev;
- Bool ret = DRI2Connect(dpy, RootWindow(dpy, scrNum), driverName, &dev);
+ Bool ret = DRI2Connect(dpy, RootWindow(dpy, scrNum), driverName, &dev,
+ NULL);
if (ret)
free(dev);
--
1.8.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Request for nv40-c0 testing thermal/fan management
Hi Nouveau enthusiasts, One week ago was merged the thermal/fan management code for most nvidia cards. So far, no major issue arose but we would like to have more testing as soon as possible to deliver a nice and solid support when Linux 3.8 is released. Thermal management is split into two parts: - Temperature monitoring: Making sure your card doesn't overheat - Fan management: Driving the fan speed according to the temperature Thermal monitoring should be working on all chipsets that support it (nv43+). However, some cards use an external (i2c) monitoring chip. Because of the limitations of the hwmon interface, we cannot access this information and thus, cannot monitor the temperature of your card ourselves. However, we should be able to load the right kernel module so as you can monitor it for us. As for fan management, the situation is the same as thermal mangement with the additional limitation that nvc0+ (Fermi+) chipsets are not supported for fan management. The reason is that nvc0+ chipset use an internal engine (PDAEMON) that is already set up by the vbios to do fan management and we didn't feel like getting rid of it just yet even though some experimental code for its replacement is already available. What we are trying to avoid is: VERY IMPORTANT: - No temperature at all while the blob reports one! - Inaccurate temperature (we already have a bug report for that on nv4x) IMPORTANT: - The fan/card makes a strange noise while driving the fan - You manage to stop the fan without fiddling with pwm_min - Non-linear fan speed with PWM value Please report if one of these issues occur. If you experience something strange that isn't on the list, please inform us too :) Complete documentation for thermal management is available at /Documentation/thermal/nouveau_thermal (http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal). Looking forward to your feedback! Cheers, Martin (AKA mupuf) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #6 from Serkan Hosca --- (In reply to comment #5) > Does your kernel tree have this patch? > http://cgit.freedesktop.org/~airlied/linux/commit/drivers/gpu/drm/radeon/ > radeon_object.c?h=drm-next&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb Yea i have that commit. -- 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 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 Tom Wijsman changed: What|Removed |Added CC||tom...@live.com URL||https://bugs.gentoo.org/sho ||w_bug.cgi?id=447528 -- 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
new userspace API approaches atomic *
> There are several problems with this: > > - I can't test other drivers > > - I don't have the knowledge or inclination to implement atomic semantics > for everyone's favorite hardware, and without that there's little > point in doing the work. Some of my initial code was layered on top of > drm_crtc_helper though, so it might be possible to use that as a basis > for an atomic helper, but there would actually be no benefit from > using it apart from allowing those drivers to respond to the atomic > ioctl. But we wouldn't use any of that w/ i915, so it would be better is > someone else does that part. The "I can't test it" argument doesn't fly with me, you are creating a new API that adds a useful feature, it should be possible to get a few other driver maintainers interested, but also I'd hope that most of the ideas for converting to a new API would be mechanical in a lot of ways. Atomic semantics aren't hw specific from what i can see, if they are then the API is obviously wrong. > - Replacing all the legacy codepaths with new code in one go increases the > chance that we get a regression, and then we have no choice but to > back out the whole thing. Also it seems that no-one apart from Rob has > even looked at the code, so it seems likely that there would be heavy > opposition to replacing the current code with something new. I never said one go, I said before pushing the new API. This means you get everything internally converted in the drm/driver interface, drop the old drm/driver interface, and the new userspace API. At least regressions should be a lot more obvious and we can port a driver at a time if needed. We can also block new drivers from using the old interfaces from being merged. > - These are the reasons I would like to merge the thing without touching > the legcay codepaths too much. Then each driver author could move their > code over the new APIs. I'm willing to help of course, but the driver > authors are in a much better position to make something that actually > works for their hardware. Yup thats what you want, but you don't want to bring in the new API before this happens, since only once you've ported a bunch of drivers will you know the API actually works. >> f) get b merged standalone, transition phase is fine, but every driver >> needs to be ported before the API >> goes in. > > Why? The current drivers are not using the same APIs internally anyway. > i915 doesn't use drm_crtc_helper for example. You didn't demand that > Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other > drivers, did you? > helpers are not APIs. The API from drm_crtc.c to driver is the main modesetting API, for instance Daniel is trying to stop taking locks in the drm_crtc side of things, to do this he is going and reimplementing lots of bits in lots of drivers at the same time. > > Right, so either I rewrite the modeset and pageflip code for all drivers, > or I wait until all the driver authors decide to help me. The first one > will take approximately five years given that I don't know the hardware > and I have other tasks on my plate, and based on the past interest the > second one doesn't seem likely to happen anytime soon > > All this make me think I should just try to push it as an i915 private > feature. Damn the other drivers. That should make the management happy too > since everyone that needs atomic display updates on Linux will need to buy > Intel hardware. > > Oh well, the world is supposedly ending in a few days anyway, so perhaps > I can just relax and stop caring :) Well start by converting Intel to a new internal API without the external, kick a few driver authors to start porting other drivers to the new internal API. The API seems like it should be pretty much hw independent. But I expect getting other maintainers interested might involve actually going out and actually writing crappy patches and sending them to them to pick up. I can also help kick heads in the right direction. I just don't want to implement any userspace APIs on only one driver, and this and atomic modeset are things that are definitely heading in that direction. Dave.
[Bug 58354] New: r600g locks up in Unigine Tropics with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58354 Priority: medium Bug ID: 58354 Assignee: dri-devel at lists.freedesktop.org Summary: r600g locks up in Unigine Tropics with drm-next Severity: critical Classification: Unclassified OS: All Reporter: alexandre.f.demers at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Testing with drm-next with latest mesa, ddx and drm, Unigine Tropics locks up when launching the demo. The problem appears somewhere between a636a9829175987e74ddd28a2e87ed17ff7adfdc (locks) and 1a1494def7eacbd25db05185aa2e81ef90892460 (OK). I'll pinpoint it tomorrow. -- 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/20121216/93f898a2/attachment.html>
new userspace API approaches atomic *
On Sun, Dec 16, 2012 at 7:04 AM, Dave Airlie wrote: > The "I can't test it" argument doesn't fly with me, you are creating a > new API that adds a useful feature, it should be possible to get a few > other driver maintainers interested, but also I'd hope that most of > the ideas for converting to a new API would be mechanical in a lot of > ways. Atomic semantics aren't hw specific from what i can see, if they > are then the API is obviously wrong. For actual semantics I think we need to split the discussion into the modeset and the pageflip part: - For modeset it shouldn't be hard to whip up some helpers which use the current crtc helpers to do modeset changes accross multiple crtcs. Like currently, drivers might refuse a modeset in one of their callbacks, and that might only happen once the hw touching has started already. Which means we can't efficiently implement a check flag mode for those drivers. But otoh if they have global constraints they might want to implement their own magic like i915. Or we could add a new global ->check_modeset callback which checks for these (after crtc/encoders have done the respective checking). - For pageflip things are a bit messier, since we really should aim for all changes to be applied on the same vblank. But luckily the set of drivers which support more than one of cursors/pageflips/plane is manageable, and most are just cursosrs+pageflip. Since I've just read through them all I think it shouldn't be too hard to whip up a (totally broken) patch for each of them to guide driver maintainers. So imo to really exploit atomic modeset/pageflip we need special support from each driver to check a given configuration before committing it (this also seems to be the only sane way for userspace to figure out what works and what doesn't without causing tons of flickering). And doing that for each driver is obviously out of the question. But reworking internal interfaces and converting drivers in a simplistic fashion which assume that no global state checking is required (assuming e.g. for modesets the current crtc/encoder checks are good enough) is a requirement I agree with. Which is why I think we should aim first for something much more restricted than the current "every possible feature for kms" approach, for example just pageflips on one crtc ... >From an i915 perspective I'm leaning towards pageflips because things are much simpler there (similar to all other drivers). It's much more immediately useful for us and for atomic modeset our driver-internal code is simple not yet ready to do global state-checking up-front before we start touching hw - we need to move around quite a bit of code until that's doable. So atomic modeset won't really help us yet to for 3-pipe pll sharing and similar shared global resources issues and how to correctly expose them to userspace. Yours, Daniel PS: My totally broken exynos patch, which Inki Dae fixed up for me, and the 3 radeon patches are already merged. It's really not rocket science afaict ... just requires pinging relevant people early so that they can check your patches quickly and know what you're up to. -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On Fri, Dec 14, 2012 at 09:59:11PM +0200, Terje Bergstr?m wrote: > On 14.12.2012 18:21, Stephen Warren wrote: > > On 12/13/2012 11:09 PM, Terje Bergstr?m wrote: > >> They want to get the global data by getting drvdata of their parent. > > > > There's no reason that /has/ to be so; they can get any information from > > wherever it is, rather than trying to require it to be somewhere it isn't. > > Exactly, this was also my solution. > > >> The dummy device is not their parent - host1x is. There's no > >> connection between the dummy and the real client devices. > > > > It's quite possible for the client devices to ask their actual parent > > (host1x) for the tegradrm struct device *, by calling a host1x API, and > > have host1x implement that API by returning the dummy/virtual device > > that it created. That should be just 1-2 lines of code to implement in > > host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED > > when appropriate. > > My solution was to just have one global, and an getter for the global. > Instead of drvdata, the pointer is retrieved with the getter. No need > for dummy device, or passing points between host1x and tegradrm. Okay, so we're back on the topic of using globals. I need to assert again that this is not an option. If we were to use globals, then we could just as well leave out the dummy device and just do all of that in the tegra-drm driver's initialization function. The whole point of all this is to link the host1x and it's particular tegra-drm instance. I will see if I can find the time to implement this in the existing driver, so that the host1x code that you want to remove registers the tegra-drm dummy device and the tegra-drm devices use the accessors as discussed previously to access host1x and the dummy device. Once that is implemented, removing the original host1x implementation should be much easier since you will only have to keep the dummy device instantiation along with the one or two accessor functions. 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/20121216/7b6a9dd3/attachment.pgp>
[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 16.12.2012 14:16, Thierry Reding wrote: > Okay, so we're back on the topic of using globals. I need to assert > again that this is not an option. If we were to use globals, then we > could just as well leave out the dummy device and just do all of that in > the tegra-drm driver's initialization function. > The whole point of all this is to link the host1x and it's particular > tegra-drm instance. I will see if I can find the time to implement this > in the existing driver, so that the host1x code that you want to remove > registers the tegra-drm dummy device and the tegra-drm devices use the > accessors as discussed previously to access host1x and the dummy device. > Once that is implemented, removing the original host1x implementation > should be much easier since you will only have to keep the dummy device > instantiation along with the one or two accessor functions. I'm not sure what you have discussed with Stephen, so I might be missing the reason why this is a problem that needs to be solved with new dependency between tegradrm and host1x instead of locally in tegradrm driver itself. As far I remember, we had two reasons for discussing the dummy device. First reason is for DC, HDMI probe calls to find the global data. Second is giving something to DRM framework's drm_platform_init(). The easiest way to solve the probe problem is just to have a tegradrm accessor for the global data in the way I proposed in the patchset. Dummy device doesn't help there, as the dummy device is in no relationship to DC and HDMI. Sure we could tell DC to ask its parent (host1x), and call host1x driver with platform_device pointer found that way, and host1x would return a pointer to tegradrm's data. Hanging the data onto host1x driver is just a more complicated way of implementing global data, and it's breaking the responsibility split between host1x driver and tegradrm. To me, host1x driver is responsible of host1x, and tegradrm is responsible of the DRM interface and everything related to that. All other parts of code use drm_device->dev_private for getting the global data, so the access problem is only for the probe calls. drm_platform_init() needing a device is another problem. drm_platform_init() leads to a call to the CMA FB helper. That again needed the coherent_dma_mask set for the device give to it. I guess that problem can be solved by just setting the mask to 0x. But that is still something that can be handled inside tegradrm without involving the host1x driver. Terje
[Bug 57670] segfault with etqw.demo
https://bugs.freedesktop.org/show_bug.cgi?id=57670 --- Comment #1 from Laurent carlier --- Created attachment 71589 --> https://bugs.freedesktop.org/attachment.cgi?id=71589&action=edit patch to fix segfault Apply this patch to s2tc library to fix segfault with etqw and quake4 -- 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/20121216/a22792fd/attachment.html>
[Bug 58354] [bisected] r600g locks up in Unigine Tropics with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58354 Alexandre Demers changed: What|Removed |Added Summary|r600g locks up in Unigine |[bisected] r600g locks up |Tropics with drm-next |in Unigine Tropics with ||drm-next --- Comment #1 from Alexandre Demers --- 33e5467871b3007c4e6deea95b2cac38a55ff9f5 is the first bad commit commit 33e5467871b3007c4e6deea95b2cac38a55ff9f5 Author: Alex Deucher Date: Mon Oct 22 12:22:39 2012 -0400 drm/radeon: use DMA engine for VM page table updates on cayman/TN DMA engine has special packets to facilitate this and it also keeps the 3D engine free for other things. Signed-off-by: Alex Deucher -- 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/20121216/7b4a1ffb/attachment.html>
[Bug 58354] [bisected] r600g locks up in Unigine Tropics with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #2 from Alexandre Demers --- Obviously, this is on a 6950 Cayman. -- 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/20121216/741115d8/attachment.html>
[PATCH] drm: Only evict the blocks required to create the requested hole
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas implicitly
which swaps the end address for size (with a potential overflow) and
effectively causes the eviction code to clobber almost all earlier
buffers above the evictee.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 58 +-
include/drm/drm_mm.h |2 +-
2 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 7103aa3..c93729c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -421,6 +421,25 @@ static int check_free_hole(unsigned long start, unsigned
long end,
return end >= start + size;
}
+static int adjust_free_hole(unsigned long *start, unsigned long *end,
+ unsigned long size, unsigned alignment)
+{
+ if (*end - *start < size)
+ return 0;
+
+ if (alignment) {
+ unsigned tmp = *start % alignment;
+ if (tmp)
+ *start += alignment - tmp;
+ }
+
+ if (*end - *start < size)
+ return 0;
+
+ *end = *start + size;
+ return 1;
+}
+
struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm *mm,
unsigned long size,
unsigned alignment,
@@ -545,7 +564,7 @@ void drm_mm_init_scan(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_check_range = 0;
mm->prev_scanned_node = NULL;
}
@@ -572,7 +591,7 @@ void drm_mm_init_scan_with_range(struct drm_mm *mm,
mm->scan_size = size;
mm->scanned_blocks = 0;
mm->scan_hit_start = 0;
- mm->scan_hit_size = 0;
+ mm->scan_hit_end = 0;
mm->scan_start = start;
mm->scan_end = end;
mm->scan_check_range = 1;
@@ -591,8 +610,6 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
struct drm_mm *mm = node->mm;
struct drm_mm_node *prev_node;
unsigned long hole_start, hole_end;
- unsigned long adj_start;
- unsigned long adj_end;
mm->scanned_blocks++;
@@ -612,24 +629,21 @@ int drm_mm_scan_add_block(struct drm_mm_node *node)
hole_start = drm_mm_hole_node_start(prev_node);
hole_end = drm_mm_hole_node_end(prev_node);
- adj_start = hole_start;
- adj_end = hole_end;
-
if (mm->color_adjust)
- mm->color_adjust(prev_node, mm->scan_color, &adj_start,
&adj_end);
+ mm->color_adjust(prev_node, mm->scan_color,
+&hole_start, &hole_end);
if (mm->scan_check_range) {
- if (adj_start < mm->scan_start)
- adj_start = mm->scan_start;
- if (adj_end > mm->scan_end)
- adj_end = mm->scan_end;
+ if (hole_start < mm->scan_start)
+ hole_start = mm->scan_start;
+ if (hole_end > mm->scan_end)
+ hole_end = mm->scan_end;
}
- if (check_free_hole(adj_start, adj_end,
- mm->scan_size, mm->scan_alignment)) {
+ if (adjust_free_hole(&hole_start, &hole_end,
+mm->scan_size, mm->scan_alignment)) {
mm->scan_hit_start = hole_start;
- mm->scan_hit_size = hole_end;
-
+ mm->scan_hit_end = hole_end;
return 1;
}
@@ -668,16 +682,8 @@ int drm_mm_scan_remove_block(struct drm_mm_node *node)
INIT_LIST_HEAD(&node->node_list);
list_add(&node->node_list, &prev_node->node_list);
- /* Only need to check for containement because start&size for the
-* complete resulting free block (not just the desired part) is
-* stored. */
- if (node->start >= mm->scan_hit_start &&
- node->start + node->size
- <= mm->scan_hit_start + mm->scan_hit_size) {
- return 1;
- }
-
- return 0;
+ return (node->start + node->size >= mm->scan_hit_start &&
+ node->start <= mm->scan_hit_end);
}
EXPORT_SYMBOL(drm_mm_scan_remove_block);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 9a08a45..9e06ca1 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -70,7 +70,7 @@ struct drm_mm {
unsigned long scan_color;
unsigned long scan_size;
unsigned long scan_hit_start;
- unsigned scan_hit_size;
+ unsigned long scan_hit_end;
unsigned scanned_blocks
[Bug 58372] New: [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 Priority: medium Bug ID: 58372 Assignee: dri-devel at lists.freedesktop.org Summary: [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next Severity: normal Classification: Unclassified OS: All Reporter: serkan at hosca.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 71594 --> https://bugs.freedesktop.org/attachment.cgi?id=71594&action=edit dmesg with drm-next Using linus + airlied's drm-next produces garbled screen and gpu crashes after login. Using mesa git and xf86-ati git. -- 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/20121216/b180240f/attachment.html>
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #1 from Serkan Hosca --- Created attachment 71595 --> https://bugs.freedesktop.org/attachment.cgi?id=71595&action=edit dmesg with linus git -- 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/20121216/60ac1f24/attachment.html>
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #2 from Serkan Hosca --- Forgot to add, using lightdm + cinnamon on arch -- 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/20121216/aa75fbd9/attachment-0001.html>
new userspace API approaches atomic *
On Sun, Dec 16, 2012 at 12:11:13PM +0100, Daniel Vetter wrote: > On Sun, Dec 16, 2012 at 7:04 AM, Dave Airlie wrote: > > The "I can't test it" argument doesn't fly with me, you are creating a > > new API that adds a useful feature, it should be possible to get a few > > other driver maintainers interested, but also I'd hope that most of > > the ideas for converting to a new API would be mechanical in a lot of > > ways. Atomic semantics aren't hw specific from what i can see, if they > > are then the API is obviously wrong. > > For actual semantics I think we need to split the discussion into the > modeset and the pageflip part: > > - For modeset it shouldn't be hard to whip up some helpers which use > the current crtc helpers to do modeset changes accross multiple crtcs. > Like currently, drivers might refuse a modeset in one of their > callbacks, and that might only happen once the hw touching has started > already. Which means we can't efficiently implement a check flag mode > for those drivers. But otoh if they have global constraints they might > want to implement their own magic like i915. Or we could add a new > global ->check_modeset callback which checks for these (after > crtc/encoders have done the respective checking). Like I said, my initial version was based on drm_crtc_helper, so it would work as a starting point. > - For pageflip things are a bit messier, since we really should aim > for all changes to be applied on the same vblank. But luckily the set > of drivers which support more than one of cursors/pageflips/plane is > manageable, and most are just cursosrs+pageflip. Since I've just read > through them all I think it shouldn't be too hard to whip up a > (totally broken) patch for each of them to guide driver maintainers. OK so finally a volunteer to help. Great ;) > So imo to really exploit atomic modeset/pageflip we need special > support from each driver to check a given configuration before > committing it (this also seems to be the only sane way for userspace > to figure out what works and what doesn't without causing tons of > flickering). And doing that for each driver is obviously out of the > question. > > But reworking internal interfaces and converting drivers in a > simplistic fashion which assume that no global state checking is > required (assuming e.g. for modesets the current crtc/encoder checks > are good enough) is a requirement I agree with. Which is why I think > we should aim first for something much more restricted than the > current "every possible feature for kms" approach, for example just > pageflips on one crtc ... Such a restricted feature is useless for any real world usage. At the very least you need to enable/disable planes as well as do pageflips. And you probably want to move/resize active planes too. Since we already know that there are a lot more properties we want to manipulate atomically, adding a "pageflip only" restrictions to the API itself is simply counter productive. We will have to replace the API immediately anyway, and then we need another year or so of bikeshedding to get the replacement API in. Let's just get it in from the start. In many cases once you've implemented the basic atomic semantics, adding other properties to be included in the atomic update is trivial. Often it's just a matter of setting some extra bits, or including some extra registers in the atomic commit. I have in mind several plane properties I want to add to i915, which I could do trivially. But doing that before the basic feature is merged would bloat the patchset further. If you want to restrict which properties you allow to be changed in one atomic operation, you can do that trivially in the driver itself. > From an i915 perspective I'm leaning towards pageflips because things > are much simpler there (similar to all other drivers). It's much more > immediately useful for us and for atomic modeset our driver-internal > code is simple not yet ready to do global state-checking up-front > before we start touching hw - we need to move around quite a bit of > code until that's doable. So atomic modeset won't really help us yet > to for 3-pipe pll sharing and similar shared global resources issues > and how to correctly expose them to userspace. It does make life for userspace more complex because userspace can't setup planes as a part of a modeset. Also all scanout duties should be moved over to drm_plane at some point, so planes will have to be part of the modeset eventually. -- Ville Syrj?l? syrjala at sci.fi http://www.sci.fi/~syrjala/
new userspace API approaches atomic *
On Sun, Dec 16, 2012 at 04:04:01PM +1000, Dave Airlie wrote: > > There are several problems with this: > > > > - I can't test other drivers > > > > - I don't have the knowledge or inclination to implement atomic semantics > > for everyone's favorite hardware, and without that there's little > > point in doing the work. Some of my initial code was layered on top of > > drm_crtc_helper though, so it might be possible to use that as a basis > > for an atomic helper, but there would actually be no benefit from > > using it apart from allowing those drivers to respond to the atomic > > ioctl. But we wouldn't use any of that w/ i915, so it would be better is > > someone else does that part. > > The "I can't test it" argument doesn't fly with me, you are creating a > new API that adds a useful feature, it should be possible to get a few > other driver maintainers interested, but also I'd hope that most of > the ideas for converting to a new API would be mechanical in a lot of > ways. Atomic semantics aren't hw specific from what i can see, if they > are then the API is obviously wrong. How/when the hardware state needs to be updated to guarantee atomic behaviour _is_ hardware specific. I suppose eventually you could distill it down to a handful of models that could cover most hardware. But note that on some hardware even different scanout engines on the same chip behave differently, so to update them atomically with each other is going be a delicate dance. > > - Replacing all the legacy codepaths with new code in one go increases the > > chance that we get a regression, and then we have no choice but to > > back out the whole thing. Also it seems that no-one apart from Rob has > > even looked at the code, so it seems likely that there would be heavy > > opposition to replacing the current code with something new. > > I never said one go, I said before pushing the new API. This means you > get everything internally converted in the drm/driver interface, drop > the old drm/driver interface, and the new userspace API. At least > regressions should be a lot more obvious and we can port a driver at a > time if needed. We can also block new drivers from using the old > interfaces from being merged. Now you're confusing me. How can we port one driver at a time if we can't merge the feature before all drivers are ported? Or do you mean porting one driver at a time in some staging tree, and then once all are ported merge the whole thing? Doable, but painful due to code flux. > > - These are the reasons I would like to merge the thing without touching > > the legcay codepaths too much. Then each driver author could move their > > code over the new APIs. I'm willing to help of course, but the driver > > authors are in a much better position to make something that actually > > works for their hardware. > > Yup thats what you want, but you don't want to bring in the new API > before this happens, since only once you've ported a bunch of drivers > will you know the API actually works. You mean the external API? I know it works. It makes no assumptions about the hardware behaviour. It even resembles OpenWF Display quite decently, which should reassure some people. It's entirely property based, so if it wouldn't work then the current property API would be totally broken as well. If you mean the internal API, then it will also work because it makes no assumptions either. It's a transaction type of thing, which just builds the state, and finally commits it. How you do that commit part is hardware specific, but the input for the commit will be just the new device state, so each driver has full freedom to handle it as best they see fit. > >> f) get b merged standalone, transition phase is fine, but every driver > >> needs to be ported before the API > >> goes in. > > > > Why? The current drivers are not using the same APIs internally anyway. > > i915 doesn't use drm_crtc_helper for example. You didn't demand that > > Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other > > drivers, did you? > > > > helpers are not APIs. The API from drm_crtc.c to driver is the main > modesetting API, for instance Daniel is trying to stop taking locks in > the drm_crtc side of things, to do this he is going and reimplementing > lots of bits in lots of drivers at the same time. I know. But none of that requires writing a lot of hardware specific logic. > > Right, so either I rewrite the modeset and pageflip code for all drivers, > > or I wait until all the driver authors decide to help me. The first one > > will take approximately five years given that I don't know the hardware > > and I have other tasks on my plate, and based on the past interest the > > second one doesn't seem likely to happen anytime soon > > > > All this make me think I should just try to push it as an i915 private > > feature. Damn the other drivers. That should make the management happy too > > since everyone that needs
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #35 from Myckel Habets --- (In reply to comment #30) > make distclean > git clean -dfx > git reset --hard fa58644855e44830e0b91dc627703c236fa6712a Ok, did this and rebuild everything, but problem stays in my case. -- 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/20121216/c8399c53/attachment.html>
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #27 from Alexandre Demers ---
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > So about this locking piglit test (depthstencil-render-miplevels 146
> > > s=z24_s8_d=z32f_s8), I've been able to track it down to:
> > > line 218: piglit_report_result(PIGLIT_SKIP);
> >
> > How did you determine that? It's weird, I wouldn't expect a skipped test to
> > produce any actual GPU rendering.
>
> I used gdb and step into the code until it locked. It gets out at level 0,
> after going through:
>
> /**
> * Attach the proper miplevel of each texture to the framebuffer
> */
> void
> set_up_framebuffer_for_miplevel(int level)...
>
> Before this call, there is a framebuffer initialization:
> GLuint fbo;
> glGenFramebuffers(1, &fbo);
> glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
> glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
>
> for (int level = 0; level <= max_miplevel; ++level) {
> set_up_framebuffer_for_miplevel(level);
It seems that with latest mesa, drm, xf86 and kernel 3.7.0-rc7-71633-g3b6b59b
from drm-next, it doesn't fail on this test anymore. It does lock however on a
different one. I'll debug it and see where it locks.
--
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/20121216/6a56ce0b/attachment.html>
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #3 from Alexandre Demers --- If you can, could you bisect? -- 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/20121216/669e552c/attachment.html>
[Bug 58033] [r300g] Black gap artifacts when playing WoW
https://bugs.freedesktop.org/show_bug.cgi?id=58033 --- Comment #5 from Chris Rankin --- (In reply to comment #4) > Can you bisect? Apparently, this is the bad commit: 39737e17e7a61535a35669756161005a7a5c887b is the first bad commit commit 39737e17e7a61535a35669756161005a7a5c887b Author: Marek Ol??k Date: Mon Dec 3 01:26:22 2012 +0100 st/dri: always allocate private depth-stencil buffers This disables DRI2 sharing of zbuffers. The window zbuffer is allocated just like any other texture - through resource_create. The idea of allocating a zbuffer through DRI2 isn't very useful with MSAA, where a single-sample zbuffer is useless. IIRC, the Intel driver does the same thing. Reviewed-by: Brian Paul :04 04 e8045e2d2c7e9a1ebd6eb1f22c93b97b9c3e8ce7 4deb5755e011d592366e6140bf385bfefe157f3f Msrc -- 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/20121216/8308f7fc/attachment.html>
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #14 from Andre 2012-12-16 23:22:54 --- I have tried the new kernel 3.7 and have the same behavior as described in the initial bug report. /var/log/messages http://pastebin.com/a4EN1kmL I will recompile the kernel with debugging enabled to maybe get a more detailed kernel.log. -- 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 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors
https://bugs.freedesktop.org/show_bug.cgi?id=57350 --- Comment #2 from Rui Salvaterra --- Created attachment 71608 --> https://bugs.freedesktop.org/attachment.cgi?id=71608&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/20121216/769f8b40/attachment.html>
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #4 from Serkan Hosca --- bisect result: 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d is the first bad commit commit 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d Author: Jerome Glisse Date: Wed Nov 28 13:47:55 2012 -0500 drm/radeon: use cached memory when evicting for vram on non agp Force the use of cached memory when evicting from vram on non agp hardware. Also force write combine on agp hw. This is to insure the minimum cache type change when allocating memory and improving memory eviction especialy on pci/pcie hw. Signed-off-by: Jerome Glisse :04 04 c917ebaa086f5efea9928e707d97bdb90ef6919935d6eaaa7b1115d9e3696c200da139695c19ad15 M drivers -- 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/20121216/ed8fb8cd/attachment-0001.html>
[Bug 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors
https://bugs.freedesktop.org/show_bug.cgi?id=57350 --- Comment #3 from Rui Salvaterra --- This also happens on my nVIDIA ION (MCP79) system, Unity Dash graphics become severely corrupted. I'm currently running Ubuntu 12.10 with the xorg edgers ppa. My dmesg is attached. -- 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/20121216/5cfbf516/attachment.html>
[Bug 58378] New: Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 Priority: medium Bug ID: 58378 Assignee: dri-devel at lists.freedesktop.org Summary: Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version Severity: critical Classification: Unclassified OS: Linux (All) Reporter: henrique.ribeiro.dias at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/other Product: DRI Created attachment 71610 --> https://bugs.freedesktop.org/attachment.cgi?id=71610&action=edit stack trace I have a NVIDIA GeForce 8400M G graphics card. I've been using nouveau drive for a long time without any kind of problems. After upgrade the kernel to 3.7.0 version I have a lot of issues. After login in to the system and after having spent some time using the system the graphics are corrupted. The graphics show up with mixed colors. -- 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/20121216/989f76fd/attachment.html>
[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #1 from Henrique Dias --- Created attachment 71612 --> https://bugs.freedesktop.org/attachment.cgi?id=71612&action=edit Screenshot Screenshot showing the problem. -- 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/20121216/49e7a53f/attachment.html>
[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
Hi,
On 12/14/2012 10:36 AM, sumit.semwal at ti.com wrote:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal
> ---
> drivers/base/dma-buf.c | 149
> +++
> include/linux/dma-buf.h |6 +-
> 2 files changed, 154 insertions(+), 1 deletion(-)
[...]
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index bd2e52c..160453f 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -112,6 +112,7 @@ struct dma_buf_ops {
> * @file: file pointer used for sharing buffers across, and for refcounting.
> * @attachments: list of dma_buf_attachment that denotes all devices
> attached.
> * @ops: dma_buf_ops associated with this buffer object.
> + * @list_node: node for dma_buf accounting and debugging.
> * @priv: exporter specific private data for this buffer object.
> */
> struct dma_buf {
> @@ -121,6 +122,8 @@ struct dma_buf {
> const struct dma_buf_ops *ops;
> /* mutex to serialize list manipulation and attach/detach */
> struct mutex lock;
> +
> + struct list_head list_node;
> void *priv;
> };
>
> @@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
> *,
>unsigned long);
> void *dma_buf_vmap(struct dma_buf *);
> void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> -
> +int dma_buf_debugfs_create_file(const char *name,
> + int (*write)(struct seq_file *));
Why is this function declared in the public header file?
--
Francesco
