On Mon, May 6, 2019 at 11:19 AM Emil Velikov
wrote:
> On Sat, 4 May 2019 at 04:18, Marek Olšák wrote:
> >
> > On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich <
> mathias.froehl...@gmx.net> wrote:
> >>
> >> Good Morning,
> >>
> >> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
> >> > B
On Sat, 4 May 2019 at 04:18, Marek Olšák wrote:
>
> On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich
> wrote:
>>
>> Good Morning,
>>
>> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
>> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me
>> > to have no swrast o
On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich
wrote:
> Good Morning,
>
> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me
> > to have no swrast on my development system.
>
> Ok. I see. I use swrast regularly
Good Morning,
On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
> BTW, swrast doesn't have to exist on the system. It's not uncommon for me
> to have no swrast on my development system.
Ok. I see. I use swrast regularly to test changes with different backend
drivers.
Also especially clas
BTW, swrast doesn't have to exist on the system. It's not uncommon for me
to have no swrast on my development system.
Marek
On Wed, May 1, 2019 at 4:30 AM Mathias Fröhlich
wrote:
> Hi Marek, Emil,
>
> On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote:
> > On Mon, 29 Apr 2019 at 22:50,
Hi Marek, Emil,
On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote:
> On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote:
> >
> > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote:
> >>
> >> On Sat, 27 Apr 2019 09:38:27 -0400
> >> Marek Olšák wrote:
> >>
> >> > Those are all valid reaso
On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote:
>
> On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote:
>>
>> On Sat, 27 Apr 2019 09:38:27 -0400
>> Marek Olšák wrote:
>>
>> > Those are all valid reasons, but I don't wanna expose swrast for AMD's
>> > customers.
>>
>> Hi Marek,
>>
>> is you ob
On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote:
> On Sat, 27 Apr 2019 09:38:27 -0400
> Marek Olšák wrote:
>
> > Those are all valid reasons, but I don't wanna expose swrast for AMD's
> > customers.
>
> Hi Marek,
>
> is you objection that you will never want to see any software renderer
> i
On Sat, 27 Apr 2019 09:38:27 -0400
Marek Olšák wrote:
> Those are all valid reasons, but I don't wanna expose swrast for AMD's
> customers.
Hi Marek,
is you objection that you will never want to see any software renderer
in the list, or that you don't want to see a software renderer only as
lon
Those are all valid reasons, but I don't wanna expose swrast for AMD's
customers.
Marek
On Sat, Apr 27, 2019, 5:45 AM Mathias Fröhlich
wrote:
> Hi Marek,
>
> On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote:
> > Adam, did you notice my original suggestion "If there is at least 1 drm
Hi Marek,
On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote:
> Adam, did you notice my original suggestion "If there is at least 1 drm
> device, swrast won't be in the list."? which means swrast would be in the
> list for your "dumb" GPUs.
Imagine a box with a low end drm capable hardwa
Adam, did you notice my original suggestion "If there is at least 1 drm
device, swrast won't be in the list."? which means swrast would be in the
list for your "dumb" GPUs.
Marek
On Tue, Apr 23, 2019 at 7:52 PM Adam Jackson wrote:
> On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote:
>
> > Th
On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote:
> Then I think a separate EGL extension that exposes swrast would be
> better. The thing with the device extensions is that swrast is not a
> device.
Enh. I've got dumb GPUs I need to support, they need to run OpenGL, and
if they were running
On Tue, Apr 23, 2019 at 6:30 PM Eric Anholt wrote:
> Marek Olšák writes:
>
> > On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich <
> mathias.froehl...@gmx.net>
> > wrote:
> >
> >> Hi,
> >>
> >> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
> >> > On Tue, Apr 23, 2019 at 4:05 PM Mathi
Marek Olšák writes:
> On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich
> wrote:
>
>> Hi,
>>
>> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
>> > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich <
>> mathias.froehl...@gmx.net>
>> > wrote:
>> >
>> > > Hi Marek,
>> > >
>> > > On Tuesd
On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich
wrote:
> Hi,
>
> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
> > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich <
> mathias.froehl...@gmx.net>
> > wrote:
> >
> > > Hi Marek,
> > >
> > > On Tuesday, 23 April 2019 20:22:15 CEST Marek
Hi,
On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
> On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich
> wrote:
>
> > Hi Marek,
> >
> > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote:
> > > I'd like to remove swrast from devices. It doesn't work (eglInitialize
> > > fails)
On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich
wrote:
> Hi Marek,
>
> On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote:
> > I'd like to remove swrast from devices. It doesn't work (eglInitialize
> > fails) and I don't think I like swrast there. Any objections?
>
> Yes, how do you guara
Hi Marek,
On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote:
> I'd like to remove swrast from devices. It doesn't work (eglInitialize
> fails) and I don't think I like swrast there. Any objections?
Yes, how do you guarantee that at least one device can be returned
in any case? Even if no
I'd like to remove swrast from devices. It doesn't work (eglInitialize
fails) and I don't think I like swrast there. Any objections?
Marek
On Wed, Apr 17, 2019 at 12:38 AM Mathias Fröhlich
wrote:
>
> Hi,
>
> On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote:
> > On Wed, Apr 10, 2019 at
Hi,
On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote:
> On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich
> wrote:
>
> > Hi Emil,
> >
> > On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote:
> > > > Now that I have been putting together a test case for the the actual
> > use
> > >
On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich
wrote:
> Hi Emil,
>
> On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote:
> > > Now that I have been putting together a test case for the the actual
> use
> > > I do see some issues with the pbuffer code path. Well - still
> investigating
> >
Hi Emil,
On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote:
> > Now that I have been putting together a test case for the the actual use
> > I do see some issues with the pbuffer code path. Well - still investigating
> > if the test is wrong or the result.
> >
> Actually I do recall some is
On Fri, 5 Apr 2019 at 14:57, Mathias Fröhlich wrote:
>
> Hi Emil,
>
> Now that I have been putting together a test case for the the actual use
> I do see some issues with the pbuffer code path. Well - still investigating
> if the test is wrong or the result.
>
Actually I do recall some issues with
Hi Emil,
Now that I have been putting together a test case for the the actual use
I do see some issues with the pbuffer code path. Well - still investigating
if the test is wrong or the result.
In the mean time some small comments inline below ...
Mathias
On Thursday, 4 April 2019 17:25:28 CEST
This new 'platform' is added by default with no guards.
It is effectively a copy of the surfaceless one, with updated function
names and brand new probe function.
Due to the reuse, some of the ifdef HAVE_SURFACELESS_PLATFORM guards
have been dropped.
A worthy mention are the changes in _egFindDi
26 matches
Mail list logo
