ytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/648a8335/attachment.pgp>
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>
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121201/1fb07074/attachment.html>
ost1x 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
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
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
;,
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
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
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
re 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>
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>
L:
<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
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
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>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121201/35e62e98/attachment-0001.html>
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
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
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.
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
> >> 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,
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>
ists.freedesktop.org/archives/dri-devel/attachments/20121201/c4e07d8f/attachment-0001.html>
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:
+
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
On Sat, Dec 1, 2012 at 12:30 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Dec 1, 2012 at 3:26 AM, Inki Dae inki@samsung.com 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
On Sat, Dec 1, 2012 at 1:11 PM, Daniel Vetter dan...@ffwll.ch 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
On Sat, Dec 1, 2012 at 3:26 AM, Inki Dae inki@samsung.com 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
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:
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
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:
+
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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #38 from Michael Dressel mdrs...@t-online.de ---
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
On Sat, Dec 1, 2012 at 12:31 PM, Terje Bergström tbergst...@nvidia.com 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
2012/12/1 Daniel Vetter dan...@ffwll.ch
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
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #1 from Alex Deucher ag...@yahoo.com ---
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.
___
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #39 from Alex Deucher ag...@yahoo.com ---
(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
2012/12/1 Daniel Vetter dan...@ffwll.ch
On Sat, Dec 1, 2012 at 1:11 PM, Daniel Vetter dan...@ffwll.ch 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
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 libdrm
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
submitted
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 also
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 state
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 using an
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
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
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 downstream.
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #2 from Tomasz P. son_of_the_osi...@interia.pl ---
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 !
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #3 from Tomasz P. son_of_the_osi...@interia.pl ---
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.
On Thu, Nov 29, 2012 at 9:45 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
I was unable to build test with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
https://bugs.freedesktop.org/show_bug.cgi?id=57763
--- Comment #4 from Piero Finizio andabat...@yahoo.it ---
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=57763
Marek Olšák mar...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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
https://bugs.freedesktop.org/show_bug.cgi?id=33077
Marek Olšák mar...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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 for any
https://bugs.freedesktop.org/show_bug.cgi?id=33648
Marek Olšák mar...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=37724
Marek Olšák mar...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=35095
--- Comment #13 from Marek Olšák mar...@gmail.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=37485
Marek Olšák mar...@gmail.com changed:
What|Removed |Added
Component|Drivers/DRI/r300|Drivers/Gallium/r300
---
67 matches
Mail list logo
