On Fri, Nov 12, 2010 at 10:50 PM, Francisco Jerez wrote:
> Jerome Glisse writes:
>
>> Hi,
>>
>>[...]
>> In order to find out which part of the stack is underperforming in
>> front of state changes I slowly disabled layer starting by the bottom
>> (which is the only way to do this ;o)). Thus i dis
Jerome Glisse writes:
> Hi,
>
>[...]
> optimized further). Also it seems that we are suffering from call
> overhead (likely TLS or others similar optimization in our GL
> dispatching stuff), nvidia is a lot better at facing millions of call.
>
Yeah, the nvidia binary blob is really good at immedi
Hello Zack,
Saturday, November 13, 2010, 12:18:30 AM, you wrote:
> On Friday 12 November 2010 14:55:08 Jerome Glisse wrote:
> Hi Jerome,
> It's a bit tough to answer your email because it's composed of several quite
> distinct parts (benchmarking, gallium, new state trackers, ttm...). If
> anyt
On Fri, Nov 12, 2010 at 7:18 PM, Zack Rusin wrote:
> On Friday 12 November 2010 14:55:08 Jerome Glisse wrote:
>
> Hi Jerome,
>
> It's a bit tough to answer your email because it's composed of several quite
> distinct parts (benchmarking, gallium, new state trackers, ttm...). If
> anything it'd be
On Fri, Nov 12, 2010 at 7:46 PM, Marek Olšák wrote:
> Hi Jerome,
>
> Concerning rewriting mesa etc. I am not a fan of complete rewriting. It's
> like throwing years of hard work and ideas and testing and fixing away.
> Sometimes this can get really crazy, resulting in endless rewrites with
> nothi
Hi Jerome,
Concerning rewriting mesa etc. I am not a fan of complete rewriting. It's
like throwing years of hard work and ideas and testing and fixing away.
Sometimes this can get really crazy, resulting in endless rewrites with
nothing being stable or usable for end users. I think I have seen thi
On Friday 12 November 2010 14:55:08 Jerome Glisse wrote:
Hi Jerome,
It's a bit tough to answer your email because it's composed of several quite
distinct parts (benchmarking, gallium, new state trackers, ttm...). If
anything it'd be good to seperate those into seperate threads.
> Drawoverhead
2010/11/12 Christian König :
> Am Freitag, den 12.11.2010, 12:48 -0500 schrieb Alex Deucher:
>> 2010/11/12 Christian König :
>> > Hi Alex,
>> >
>> > by the way I am playing around with iDCT and while doing so I have tried
>> > to allocate an 8x8 texture through r600g, resulting in this error
>> > m
Am Freitag, den 12.11.2010, 12:48 -0500 schrieb Alex Deucher:
> 2010/11/12 Christian König :
> > Hi Alex,
> >
> > by the way I am playing around with iDCT and while doing so I have tried
> > to allocate an 8x8 texture through r600g, resulting in this error
> > message:
> > radeon :01:00.0: text
Hi,
I have been doing some benchmarking lately to try to identify
bottleneck in the Mesa/Gallium/R600 driver. I fear results are not
ones i expected. I would have liked GPU being the bottleneck and thus
additions of new features such as texture tiling or hyper-z would
immediatly boost performance.
https://bugs.freedesktop.org/show_bug.cgi?id=31544
--- Comment #20 from Norbert Papke 2010-11-12
11:24:11 PST ---
The command stream error also happens with git master.
Taking a slightly different tack, I have tried to narrow down which desktop
effects cause the failure. Many work just fine, e
https://bugs.freedesktop.org/show_bug.cgi?id=31587
Summary: strange segfault in vgFinish
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: O
2010/11/12 Christian König :
> Hi Alex,
>
> by the way I am playing around with iDCT and while doing so I have tried
> to allocate an 8x8 texture through r600g, resulting in this error
> message:
> radeon :01:00.0: texture bo too small (64 1024 2 0 -> 8126464 have
> 4194304)
>
> Google shows up
https://bugs.freedesktop.org/show_bug.cgi?id=31544
--- Comment #19 from Brian Paul 2010-11-12 09:22:07 PST ---
Hmmm, I don't know what's going on there. Maybe one of the r600 developers can
take a look. In the mean time, can you try the r600SetTexBuffer2() patch on
Mesa/master from git?
--
Co
Hi Alex,
by the way I am playing around with iDCT and while doing so I have tried
to allocate an 8x8 texture through r600g, resulting in this error
message:
radeon :01:00.0: texture bo too small (64 1024 2 0 -> 8126464 have
4194304)
Google shows up an patch with your name in it, do I need a k
https://bugs.freedesktop.org/show_bug.cgi?id=31544
--- Comment #18 from Norbert Papke 2010-11-12
08:06:10 PST ---
With the r600 patch, kwin aborts when compositing is enabled:
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See
dmesg for more info.
>From dmesg:
[8
2010/11/12 Younes Manton :
> 2010/11/12 Christian König :
>> What I need for both the ycrcb texture and vertex uploads is a buffer in
>> system memory, where the cpu access is fast and a function to tell the
>> gpu to upload this buffer to vram, so the cpu doesn't need to pump the
>> data over the
2010/11/12 Christian König :
> What I need for both the ycrcb texture and vertex uploads is a buffer in
> system memory, where the cpu access is fast and a function to tell the
> gpu to upload this buffer to vram, so the cpu doesn't need to pump the
> data over the system bus, wait for an "in use"
https://bugs.freedesktop.org/show_bug.cgi?id=31579
Thomas changed:
What|Removed |Added
Attachment #40234|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=31579
Thomas changed:
What|Removed |Added
Attachment #40235|Archlinux PKGBULD (forwith |Archlinux PKGBULD (for
description|confi
https://bugs.freedesktop.org/show_bug.cgi?id=31579
--- Comment #3 from Thomas 2010-11-12 06:34:27 PST ---
Created an attachment (id=40236)
--> (https://bugs.freedesktop.org/attachment.cgi?id=40236)
Biesceted commit that cause the issue.
--
Configure bugmail: https://bugs.freedesktop.org/userpr
https://bugs.freedesktop.org/show_bug.cgi?id=31579
--- Comment #2 from Thomas 2010-11-12 06:33:06 PST ---
Created an attachment (id=40235)
--> (https://bugs.freedesktop.org/attachment.cgi?id=40235)
Archlinux PKGBULD (forwith configure options).
--
Configure bugmail: https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=31579
--- Comment #1 from Thomas 2010-11-12 06:32:20 PST ---
Created an attachment (id=40234)
--> (https://bugs.freedesktop.org/attachment.cgi?id=40234)
Xorg.0.log that show the segfault.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.
https://bugs.freedesktop.org/show_bug.cgi?id=31579
Summary: [swrast] segfault when login with kdm
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: blocker
Priority: m
https://bugs.freedesktop.org/show_bug.cgi?id=31544
--- Comment #17 from Brian Paul 2010-11-12 06:25:08 PST ---
Created an attachment (id=40233)
View: https://bugs.freedesktop.org/attachment.cgi?id=40233
Review: https://bugs.freedesktop.org/review?bug=31544&attachment=40233
set texImage->TexFor
Am Donnerstag, den 11.11.2010, 17:59 -0500 schrieb Jerome Glisse:
> I am not sure on how gallium texture upload was ever supposed to be or
> done, but from memory management point of view the idea i had was to
> create all bo in GTT and let migrate them to VRAM once they are use,
> eliminating any
On Thu, 2010-11-11 at 14:59 -0800, Jerome Glisse wrote:
> 2010/11/11 Keith Whitwell :
> > There is still more to do there. Currently r600g treats buffer and texture
> > uploads separately, and I've only attempted to improve texture uploads.
> > Buffer is just as important however.
> >
> > The c
27 matches
Mail list logo
