ignature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/648a8335/attachment.pgp>
eer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/39ba3cde/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=37485
Marek Olšák changed:
What|Removed |Added
Component|Drivers/DRI/r300|Drivers/Gallium/r300
--- Comment #1 from M
https://bugs.freedesktop.org/show_bug.cgi?id=35095
--- Comment #13 from Marek Olšák ---
Is this still an issue with current Mesa git?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=37724
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=33648
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
hives/dri-devel/attachments/20121201/265752a7/attachment.html>
On 01.12.2012 19:34, Lucas Stach wrote:
> This would certainly make life easier, but personally I don't think it's
> the right thing to do. The separation of the Linux kernel into different
> subsystems was done for a reason and just because the specific hardware
> at hands happens to work a bit di
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121201/1fb07074/attachment.html>
a number of things and we can always move code
between the various components of the whole stack.
> The host1x command stream generation would still remain in libdrm. That
> seems to be the pattern with other hardware.
Yes, I fully agree.
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/20121201/9237719b/attachment.pgp>
On 01.12.2012 16:58, Thierry Reding wrote:
> I don't know where you see politics in what I said. All I'm saying is
> that we shouldn't be making things needlessly complex. In my experience
> the technically cleanest solution is usually the one with the least
> complexity.
Let me come up with a pro
On Thu, Nov 29, 2012 at 9:45 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> spinlock_t should always be used.
>
> I was unable to build test with allmodconfig:
>
> mcgrof at frijol ~/linux-next (git::(no branch))$ make C=1
> M=drivers/crypto/ux500/
>
> WARNING: Symbol version du
On 01.12.2012 16:45, Thierry Reding wrote:
> I did some prototyping on how a libdrm API could look like a few weeks
> back. I should clean the patches up some and push them to a public
> repository or to the mailing lists for review.
Ok. Sorry about the delay - I recently learned I need separate
p
On 01.12.2012 17:10, Thierry Reding wrote:
> On Sat, Dec 01, 2012 at 01:44:41PM +0200, Terje Bergstr?m wrote:
>> host1x module being in DRM directory hinders using nvhost from anywhere
>> outside DRM in both upstream and downstream.
>
> That's not true. Nothing keeps the rest of the kernel from us
",
perhaps?
--
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/20121201/87adf0e6/attachment.html>
Am Samstag, den 01.12.2012, 18:55 +0200 schrieb Terje Bergstr?m:
> On 01.12.2012 17:10, Thierry Reding wrote:
> > On Sat, Dec 01, 2012 at 01:44:41PM +0200, Terje Bergstr?m wrote:
> >> host1x module being in DRM directory hinders using nvhost from anywhere
> >> outside DRM in both upstream and downs
On 01.12.2012 15:42, Daniel Vetter wrote:
> Out of sheer curiosity: What are you using the coverage data of these
> register definitions for? When I looked into coverage analysis the
> resulting data seemed rather useless to me, since the important thing
> is how well we cover the entire dynamic st
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/aae91917/attachment-0001.html>
,webgl enabled), just scroll down any page and it
hangs.
--
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/20121201/16c4e
a need
for discussion I'm not sure if rushing this is the best way. In that
case there may be justification for putting it in a separate location
from the start.
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/20121201/e7e29a7a/attachment-0001.pgp>
> fence, taking wrapping into account. In these cases user space can f.ex.
> leave a host1x wait out from a command stream.
But you already have extra code in the kernel to patch out expired sync-
points. Is it really worth the added effort to burden userspace with
this? If so I still think some kind of generic IOCTL to retrieve
information about a syncpoint would be better than a sysfs interface.
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/20121201/5c932596/attachment.pgp>
p-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/aac4d117/attachment.pgp>
On Sat, Dec 1, 2012 at 12:31 PM, Terje Bergstr?m
wrote:
> We must've talked about a bit different things. For pure register defs,
> I can accommodate changing to #defines. We'd lose the code coverage
> analysis, though, but if the parentheses are a make-or-break question to
> upstreaming, I can c
Thanks, the path works.
J?rg
2012/11/27 Chris Wilson :
> On Tue, 27 Nov 2012 17:29:36 +0100, J?rg Otte wrote:
>> At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see
>> following on the bootup-display:
>>
>> 3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting
>
On Sun, Dec 02, 2012 at 07:42:06AM +1000, Dave Airlie wrote:
> Guys I think you guys might be overthniking things here.
>
> I know you have some sort of upstream/downstream split, but really in
> the upstream kernel, we don't care about that, so don't make it our
> problem.
>
> There is no need f
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/20121201/03cb3159/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/35e62e98/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=33077
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 30.11.2012 10:50, Lucas Stach wrote:
> I'm with Thierry here. I think there is a fair chance that we won't get
> the API right from the start, even when trying to come up with something
> that sounds sane to everyone. It's also not desirable to delay gr2d
> going into mainline until we are all c
Guys I think you guys might be overthniking things here.
I know you have some sort of upstream/downstream split, but really in
the upstream kernel, we don't care about that, so don't make it our
problem.
There is no need for any sort of stable API between host1x and the sub
drivers, we change API
On 30.11.2012 12:38, Thierry Reding wrote:
> * PGP Signed by an unknown key
> The above implies that when you submit code it shouldn't contain pieces
> that prepare for possible future extensions which may or may not be
> submitted (the exception being if such changes are part of a series
> where s
On Sat, Dec 1, 2012 at 1:11 PM, Daniel Vetter wrote:
> I've quickly implemented a testcase for what I believe is your
> use-case (i.e. sharing between 3 different open drm files, where we
> close the gem handle in the first fd before we open the flink name
> again using the 3rd drm fd handle). It
On Sat, Dec 1, 2012 at 12:30 PM, Daniel Vetter wrote:
> On Sat, Dec 1, 2012 at 3:26 AM, Inki Dae wrote:
>> As you know, when the handle is closed, the flink name is also released even
>> though another process opened the flink name to get its own handle.
>> So the flink name becomes invalid. This
https://bugs.freedesktop.org/show_bug.cgi?id=57763
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sat, Dec 1, 2012 at 3:26 AM, Inki Dae wrote:
> As you know, when the handle is closed, the flink name is also released even
> though another process opened the flink name to get its own handle.
> So the flink name becomes invalid. This is the issue I pointed out and this
> is the fixup this pat
> >> I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The
> >> computer last ran 3.6.0 without any warnings. Second reboot showed the
> >> same warning plus a couple of EDID warnings (also below).
> >
> > Still there with 3.7.0-rc7-00113-gcc19528 and 100% reproducible:
>
> Hm, can
On 01.12.2012 19:34, Lucas Stach wrote:
> This would certainly make life easier, but personally I don't think it's
> the right thing to do. The separation of the Linux kernel into different
> subsystems was done for a reason and just because the specific hardware
> at hands happens to work a bit di
On Sat, Dec 01, 2012 at 07:08:12PM +0200, Terje Bergström wrote:
> On 01.12.2012 16:45, Thierry Reding wrote:
> > I did some prototyping on how a libdrm API could look like a few weeks
> > back. I should clean the patches up some and push them to a public
> > repository or to the mailing lists for
nclude/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -628,6 +628,18 @@ struct drm_gem_object {
> > /** Handle count of this object. Each handle also holds a
> reference */
> > atomic_t handle_count; /* number of handles on this object */
> >
> > + /*
> > +* Name count of this object.
> > +*
> > +* This count is initialized as 0 with drm_gem_object_init or
> > +* drm_gem_private_object_init call. After that, this count is
> > +* increased if the name of this object exists already
> > +* otherwise is set to 1 at flink. And finally, the name of
> > +* this object will be released when this count reaches 0
> > +* by gem close.
> > +*/
> > + atomic_t obj_name_count;
> > +
> > /** Related drm device */
> > struct drm_device *dev;
> >
> > --
> > 1.7.4.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/01f01dd5/attachment.html>
valid command stream !
--
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/20121201/3d18850e/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #4 from Piero Finizio ---
My kernel is 3.6.8-1.fc17.i686
If I don't use HyperZ all is right... as well with graphics drivers from
(git-e7177e3).
Is it inherent in the commit "r300g: fix comparison of hyperz flush time",
perhaps?
--
On Thu, Nov 29, 2012 at 9:45 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> spinlock_t should always be used.
>
> I was unable to build test with allmodconfig:
>
> mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
> M=drivers/crypto/ux500/
>
> WARNING: Symbol version dump
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #3 from Tomasz P. ---
I just check that even glxgears display static picture and it hangs also.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #2 from Tomasz P. ---
Simlilar issue with radeon 9600 agp.
I use kernel 3.6.8
In logs:
dmesg: Forbidden register 0x4F34 in cs at 40 (val=0640)
radeon_cs_ib_chunk] *ERROR* Invalid command stream !
triggered by opera-next (HA,webg
ists.freedesktop.org/archives/dri-devel/attachments/20121201/c4e07d8f/attachment-0001.html>
Am Samstag, den 01.12.2012, 18:55 +0200 schrieb Terje Bergström:
> On 01.12.2012 17:10, Thierry Reding wrote:
> > On Sat, Dec 01, 2012 at 01:44:41PM +0200, Terje Bergström wrote:
> >> host1x module being in DRM directory hinders using nvhost from anywhere
> >> outside DRM in both upstream and downs
On 01.12.2012 16:58, Thierry Reding wrote:
> I don't know where you see politics in what I said. All I'm saying is
> that we shouldn't be making things needlessly complex. In my experience
> the technically cleanest solution is usually the one with the least
> complexity.
Let me come up with a pro
On 01.12.2012 16:45, Thierry Reding wrote:
> I did some prototyping on how a libdrm API could look like a few weeks
> back. I should clean the patches up some and push them to a public
> repository or to the mailing lists for review.
Ok. Sorry about the delay - I recently learned I need separate
p
On 01.12.2012 17:10, Thierry Reding wrote:
> On Sat, Dec 01, 2012 at 01:44:41PM +0200, Terje Bergström wrote:
>> host1x module being in DRM directory hinders using nvhost from anywhere
>> outside DRM in both upstream and downstream.
>
> That's not true. Nothing keeps the rest of the kernel from us
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: 42dcedd4f2e715dc0313e359c8288e6397843fff
commit: 960e3564bfa464f92549383d41659f2aaeee1420 [70/75] drm/i915: Support
readback of stolen objects upon error
sparse warnings:
+ drivers/gpu/drm/i915/i915_irq.c:9
On 01.12.2012 15:42, Daniel Vetter wrote:
> Out of sheer curiosity: What are you using the coverage data of these
> register definitions for? When I looked into coverage analysis the
> resulting data seemed rather useless to me, since the important thing
> is how well we cover the entire dynamic st
On Sat, Dec 01, 2012 at 01:44:41PM +0200, Terje Bergström wrote:
> On 30.11.2012 10:50, Lucas Stach wrote:
> > I'm with Thierry here. I think there is a fair chance that we won't get
> > the API right from the start, even when trying to come up with something
> > that sounds sane to everyone. It's
On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
> On 30.11.2012 12:38, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > The above implies that when you submit code it shouldn't contain pieces
> > that prepare for possible future extensions which may or may not be
> > su
On Mon, Nov 26, 2012 at 03:19:06PM +0200, Terje Bergstrom wrote:
[...]
> The patch set also adds user space API to tegradrm for accessing
> host1d and 2D. We are preparing also patches to libdrm, but they are
> not yet in condition that they could be sent out.
I did some prototyping on how a libdr
2012/12/1 Daniel Vetter
> On Sat, Dec 1, 2012 at 1:11 PM, Daniel Vetter wrote:
> > I've quickly implemented a testcase for what I believe is your
> > use-case (i.e. sharing between 3 different open drm files, where we
> > close the gem handle in the first fd before we open the flink name
> > aga
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #39 from Alex Deucher ---
(In reply to comment #38)
> The distorted graphics problem disappears when setting the option
> Option "NoAccel" "on".
> (This may be obvious to the experts.)
>
> In this mode a new phenomenon appears: When
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #1 from Alex Deucher ---
What kernel are you using? A newer kernel should fix the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing li
2012/12/1 Daniel Vetter
> Hi,
>
> tbh I don't follow what exactly you're trying to fix, but the rules is:
>
> The flink name stays around as long as there's a userspace handle, and
> will be deleted once the last userspace handle is closed.
>
> Which means that for process->process gem passing t
On Sat, Dec 1, 2012 at 12:31 PM, Terje Bergström wrote:
> We must've talked about a bit different things. For pure register defs,
> I can accommodate changing to #defines. We'd lose the code coverage
> analysis, though, but if the parentheses are a make-or-break question to
> upstreaming, I can ch
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #38 from Michael Dressel ---
The distorted graphics problem disappears when setting the option
Option "NoAccel" "on".
(This may be obvious to the experts.)
In this mode a new phenomenon appears: When moving th mouse to the Activitie
On 30.11.2012 10:50, Lucas Stach wrote:
> I'm with Thierry here. I think there is a fair chance that we won't get
> the API right from the start, even when trying to come up with something
> that sounds sane to everyone. It's also not desirable to delay gr2d
> going into mainline until we are all c
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: 42dcedd4f2e715dc0313e359c8288e6397843fff
commit: 960e3564bfa464f92549383d41659f2aaeee1420 [70/75] drm/i915: Support
readback of stolen objects upon error
sparse warnings:
+ drivers/gpu/drm/i915/i915_irq.c:9
On 30.11.2012 12:38, Thierry Reding wrote:
> * PGP Signed by an unknown key
> The above implies that when you submit code it shouldn't contain pieces
> that prepare for possible future extensions which may or may not be
> submitted (the exception being if such changes are part of a series
> where s
https://bugs.freedesktop.org/show_bug.cgi?id=57763
Priority: medium
Bug ID: 57763
Assignee: dri-devel@lists.freedesktop.org
Summary: 3D applications have blank screen with "export
RADEON_HYPERZ=1" and git-da7029d
Severity: no
On Sat, Dec 1, 2012 at 3:26 AM, Inki Dae wrote:
> As you know, when the handle is closed, the flink name is also released even
> though another process opened the flink name to get its own handle.
> So the flink name becomes invalid. This is the issue I pointed out and this
> is the fixup this pat
On Sat, Dec 1, 2012 at 1:11 PM, Daniel Vetter wrote:
> I've quickly implemented a testcase for what I believe is your
> use-case (i.e. sharing between 3 different open drm files, where we
> close the gem handle in the first fd before we open the flink name
> again using the 3rd drm fd handle). It
On Sat, Dec 1, 2012 at 12:30 PM, Daniel Vetter wrote:
> On Sat, Dec 1, 2012 at 3:26 AM, Inki Dae wrote:
>> As you know, when the handle is closed, the flink name is also released even
>> though another process opened the flink name to get its own handle.
>> So the flink name becomes invalid. This
On Fri, 2012-09-28 at 23:51 +0200, Luc Verhaegen wrote:
> We still have, i hope (depends on what the FOSDEM organizers have left
> for us), 6 slots fully open: first come first serve, and the earlier
> bird gets the nicer slot!
>
> Thanks all, especially those who stepped up already.
What's the
68 matches
Mail list logo
