On Fri, 2010-11-26 at 13:00 +, Peter Clifton wrote:
> On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote:
> > Peter Clifton wrote:
>
> > Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full
> > polygons and with poly_thin_draw. Hardware is my day job desktop, nvidi
On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote:
> Peter Clifton wrote:
>
> > So.. please fetch git HEAD PCB and play with things.
> current HEAD:
> full poly: 15 FPS
> thin draw: 25 FPS
>
> version 20091103 as it is distributed in debian/squeeze
> full poly: 31 FPS
> thin draw: 25 FPS
On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote:
> Peter Clifton wrote:
> Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full
> polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia
> quadro, closed source driver.
>
> current HEAD:
> full poly:
On Fri, 2010-11-26 at 01:56 +0100, kai-martin knaak wrote:
>
> I tried multiple glxgears with closed source nvidia driver on my day
> job desktop and with the free radeon on my private desktop. Result:
> The FPS are roughly proportional to 1/n with n beeing the the number of
> instances. Looks
Peter Clifton wrote:
> I wonder if I'm holding onto a resource of which the card only has a
> limited supply. Did this happen with the "before_pours" branch, or just
> the "local_customisation_no_pours" one?
With "before_pours".
Something changed over night: Now I can run two instances of pcb-GL
Peter Clifton wrote:
> So.. please fetch git HEAD PCB and play with things.
Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full
polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia
quadro, closed source driver.
current HEAD:
full poly: 15 FPS
thin draw
On Tue, 2010-11-23 at 23:37 +, Peter Clifton wrote:
> Hi geda-users, Kai-Martin,
>
> Since I know some people have expressed an interest in why PCB+GL hasn't
> hit stable yet, I realised earlier that there was another step which is
> necessary... (besides cleaning up the hacks I made on top of
On Fri, 2010-11-26 at 01:56 +0100, kai-martin knaak wrote:
> With pcb-GL I loose two orders of magnitude for two instances.
I wonder if I'm holding onto a resource of which the card only has a
limited supply. Did this happen with the "before_pours" branch, or just
the "local_customisation_no_pour
Kai-Martin Knaak wrote:
>> On my fairly
>> recent desktops(*) your openGL branch is consistently faster than
HEAD.
>
> One exception: If I start PCB-GL twice, both of them get very slow.
> benchmark() returns 0.2 FPS. Shut down of one of the instances
> immediately rectifies the situation.
Stefan Salewski wrote:
> If I start PCB-GL twice, both of them get very slow.
>> benchmark() returns 0.2 FPS.
>>
>
> I have seen that behavior for glxgears with closed source
> nvidia driver too. For one instance processor load was only
> 50% for dual core AMD64, so my first guess was getting
On Wed, 2010-11-24 at 22:59 +0100, Kai-Martin Knaak wrote:
> Kai-Martin Knaak wrote:
>
> > On my fairly
> > recent desktops(*) your openGL branch is consistently faster than HEAD.
>
> One exception: If I start PCB-GL twice, both of them get very slow.
> benchmark() returns 0.2 FPS. Shut down of
On Wed, 2010-11-24 at 22:59 +0100, Kai-Martin Knaak wrote:
> Kai-Martin Knaak wrote:
>
> > On my fairly
> > recent desktops(*) your openGL branch is consistently faster than HEAD.
>
> One exception: If I start PCB-GL twice, both of them get very slow.
> benchmark() returns 0.2 FPS. Shut down of
On Wed, 2010-11-24 at 22:05 +0100, Kai-Martin Knaak wrote:
> Peter Clifton wrote:
>
> > The "polygon_speedup" branch should mostly be a success, but I'm fairly
> > sure it does increase CPU cycles for some operations. I've not had a
> > chance to test it very scientifically, and I'm hesitant to pu
Kai-Martin Knaak wrote:
> On my fairly
> recent desktops(*) your openGL branch is consistently faster than HEAD.
One exception: If I start PCB-GL twice, both of them get very slow.
benchmark() returns 0.2 FPS. Shut down of one of the instances immediately
rectifies the situation. Maybe some ki
Peter Clifton wrote:
> The "polygon_speedup" branch should mostly be a success, but I'm fairly
> sure it does increase CPU cycles for some operations. I've not had a
> chance to test it very scientifically, and I'm hesitant to push it to
> git HEAD without having at least made a few checks to see
Hi geda-users, Kai-Martin,
Since I know some people have expressed an interest in why PCB+GL hasn't
hit stable yet, I realised earlier that there was another step which is
necessary... (besides cleaning up the hacks I made on top of the code I
took from cairo).
The "polygon_speedup" branch on whi
16 matches
Mail list logo
