This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
wayland patches so it should work as soon as these wayland patches are
merged and PPA is updated.
Perhaps someday I'll make it more fancy to detect hotplug, support
multiple displays, configurable resolution, overlay planes, etc.
> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr > wayland patches so it should work as soon as these wayland patches are > merged and PPA is updated.
> Perhaps someday I'll make it more fancy to detect hotplug, support > multiple displays, configurable resolution, overlay planes, etc.
> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
> wayland patches so it should work as soon as these wayland patches are
> merged and PPA is updated.
You talk about wayland here, but this doesn't seem to really depend on
it. What patches do you mean for wayland that are a requirement for
this demo? It would appear that this is only dependant on libdrm, and
mesagl.
On Mon, Sep 3, 2012 at 8:18 PM, Andre Renaud <an...@bluewatersys.com> wrote:
> Hi Rob,
>> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
>> wayland patches so it should work as soon as these wayland patches are
>> merged and PPA is updated.
> You talk about wayland here, but this doesn't seem to really depend on
> it. What patches do you mean for wayland that are a requirement for
> this demo? It would appear that this is only dependant on libdrm, and
> mesagl.
well, the dependency is on gbm support in the gl driver, which is part
of the wayland patches (since weston compositor also uses gbm+kms, in
a similar way to this test app)
> well, the dependency is on gbm support in the gl driver, which is part
> of the wayland patches (since weston compositor also uses gbm+kms, in
> a similar way to this test app)
Right, I think I understand - can you point me to where those patches
are sitting at the moment?
On Mon, Sep 3, 2012 at 8:34 PM, Andre Renaud <an...@bluewatersys.com> wrote:
>> well, the dependency is on gbm support in the gl driver, which is part
>> of the wayland patches (since weston compositor also uses gbm+kms, in
>> a similar way to this test app)
> Right, I think I understand - can you point me to where those patches
> are sitting at the moment?
unfortunately, no.. they are patches on the closed src pvr driver
code, so they probably wouldn't do you much good. But I'll work with
the folks who maintain the OMAP PPA to try to get the updated drivers
released soon
> unfortunately, no.. they are patches on the closed src pvr driver
> code, so they probably wouldn't do you much good. But I'll work with
> the folks who maintain the OMAP PPA to try to get the updated drivers
> released soon
Ah, sorry, I hadn't thought that all the way through. I was thinking
of the MesaGL stuff, not the SGX/PVR stuff.
I've been wondering about all your PVR patches - how does it work? Do
(some/most/a few) of your patches make it upstream? If so, do you
retain any ownership or do IMG repay you/TI or do they automatically
gain the rights or what?
Although I'm as excited about seeing the follow up to Pandaboard as
anyone I'm worried that if it gets released too soon the bulk of the
OMAP teams attention will go on that when we don't have a stable DDX
driver for Panda Precise yet although I expect the follow up to Panda
will just be using a faster version of the PVR so it will be largely
the same driver if not the same?
I filed a few bug reports about the current precise driver on the PPA
a month or so ago and not one of them has had any reply yet - I should
hope someone has at least read them?
> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
> wayland patches so it should work as soon as these wayland patches are
> merged and PPA is updated.
> Perhaps someday I'll make it more fancy to detect hotplug, support
> multiple displays, configurable resolution, overlay planes, etc.
On Tue, Sep 4, 2012 at 8:46 AM, Dan MacDonald <allc...@gmail.com> wrote:
> I filed a few bug reports about the current precise driver on the PPA
> a month or so ago and not one of them has had any reply yet - I should
> hope someone has at least read them?
hmm... we all see them... we are just fighting against the clock...
can you please highlight the one which are really critical to you
which you opened?
On Tue, Sep 4, 2012 at 9:55 AM, Nicolas Dechesne <nde...@gmail.com> wrote:
> On Tue, Sep 4, 2012 at 8:46 AM, Dan MacDonald <allc...@gmail.com> wrote:
>> I filed a few bug reports about the current precise driver on the PPA
>> a month or so ago and not one of them has had any reply yet - I should
>> hope someone has at least read them?
> hmm... we all see them... we are just fighting against the clock...
> can you please highlight the one which are really critical to you
> which you opened?
Hehe! I'd held out chasing you up on my bug reports as I was expecting
a PPA update soon and then a few hours after I do the update arrives
so I'll report back to you when I've tried the latest which prob won't
be until the weekend now.
All of the bugs I've reported for the OMAP PPA are pretty much equally
important but seeing as there seems to be an increasing demand for
OpenGLES on here the bug that causes a black screen when starting a
full-screen OGLES/EGL app is likely the most visible but hopefully
thats no longer the case now.
On Mon, Sep 3, 2012 at 8:48 PM, Andre Renaud <an...@bluewatersys.com> wrote:
>> unfortunately, no.. they are patches on the closed src pvr driver
>> code, so they probably wouldn't do you much good. But I'll work with
>> the folks who maintain the OMAP PPA to try to get the updated drivers
>> released soon
> Ah, sorry, I hadn't thought that all the way through. I was thinking
> of the MesaGL stuff, not the SGX/PVR stuff.
> git://github.com/robclark/kmscube.git > cd kmscube > ./autogen.sh && make && ./kmscube
> You should be able to run kmscube as your normal user (not root) > assuming your user is in 'video' group. Of course, stop x11 first if > it was running.
> Weston itself isn't in the PPA, but you can build latest from git if > you want to try that too
> BR, > -R
> On Mon, Sep 3, 2012 at 8:48 PM, Andre Renaud <an...@bluewatersys.com<javascript:>> > wrote: > >> unfortunately, no.. they are patches on the closed src pvr driver > >> code, so they probably wouldn't do you much good. But I'll work with > >> the folks who maintain the OMAP PPA to try to get the updated drivers > >> released soon
> > Ah, sorry, I hadn't thought that all the way through. I was thinking > > of the MesaGL stuff, not the SGX/PVR stuff.
Oh, sorry, I left out one important step.. if you didn't start x11
first, you need to run 'pvrsrvinit' (xf86-video-omap-pvr normally does
this)..
And I just noticed, it seems like pvrsrvinit is maybe not added to the
pvr package. So I guess the temporary workaround is start and kill
x11.
All the init code is actually in /usr/lib/libsrv_init.so, so you might
be able to make a simple program that links against that and just
calls SrvInit(void), and run this as root.
>> git://github.com/robclark/kmscube.git
>> cd kmscube
>> ./autogen.sh && make && ./kmscube
>> You should be able to run kmscube as your normal user (not root)
>> assuming your user is in 'video' group. Of course, stop x11 first if
>> it was running.
>> Weston itself isn't in the PPA, but you can build latest from git if
>> you want to try that too
>> BR,
>> -R
>> On Mon, Sep 3, 2012 at 8:48 PM, Andre Renaud <an...@bluewatersys.com>
>> wrote:
>> >> unfortunately, no.. they are patches on the closed src pvr driver
>> >> code, so they probably wouldn't do you much good. But I'll work with
>> >> the folks who maintain the OMAP PPA to try to get the updated drivers
>> >> released soon
>> > Ah, sorry, I hadn't thought that all the way through. I was thinking
>> > of the MesaGL stuff, not the SGX/PVR stuff.
On Sat, Sep 15, 2012 at 5:31 AM, Rob Clark <robdcl...@gmail.com> wrote:
> Oh, sorry, I left out one important step.. if you didn't start x11
> first, you need to run 'pvrsrvinit' (xf86-video-omap-pvr normally does
> this)..
> And I just noticed, it seems like pvrsrvinit is maybe not added to the
> pvr package. So I guess the temporary workaround is start and kill
> x11.
> All the init code is actually in /usr/lib/libsrv_init.so, so you might
> be able to make a simple program that links against that and just
> calls SrvInit(void), and run this as root.
> BR,
> -R
> On Fri, Sep 14, 2012 at 11:52 PM, ChuckMcM <chuck.mcma...@gmail.com> wrote:
>> No joy, what I've got:
>>> git://github.com/robclark/kmscube.git
>>> cd kmscube
>>> ./autogen.sh && make && ./kmscube
>>> You should be able to run kmscube as your normal user (not root)
>>> assuming your user is in 'video' group. Of course, stop x11 first if
>>> it was running.
>>> Weston itself isn't in the PPA, but you can build latest from git if
>>> you want to try that too
>>> BR,
>>> -R
>>> On Mon, Sep 3, 2012 at 8:48 PM, Andre Renaud <an...@bluewatersys.com>
>>> wrote:
>>> >> unfortunately, no.. they are patches on the closed src pvr driver
>>> >> code, so they probably wouldn't do you much good. But I'll work with
>>> >> the folks who maintain the OMAP PPA to try to get the updated drivers
>>> >> released soon
>>> > Ah, sorry, I hadn't thought that all the way through. I was thinking
>>> > of the MesaGL stuff, not the SGX/PVR stuff.
I'm using pandaboard es with linaro 12.09 ubuntu, and I rewrite our game to run my opengl es 2.0 app without x11 just like the kmscube sample.
The FPS at pandaboard is lower than my test board. ( pandaboard 45 fps vs my device 75fps up) Our test device is single core arm1176@900mhz with ddr3@800mhz and mali-200@400mhz.
I think pandaboard is better than our device (cpu performance, memory bandwidth, 3D graphic chip). Is the mali-200@400mhz better than powervr sgx540? How can I improve our game's performance at pandaboard?
I have another question. When our game is running, we get a lot of message just like the following.
> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr > wayland patches so it should work as soon as these wayland patches are > merged and PPA is updated.
> Perhaps someday I'll make it more fancy to detect hotplug, support > multiple displays, configurable resolution, overlay planes, etc.
On Wed, Oct 3, 2012 at 9:03 AM, He-Jie Shih <bignose1...@gmail.com> wrote:
> I'm using pandaboard es with linaro 12.09 ubuntu,
> and I rewrite our game to run my opengl es 2.0 app without x11 just like the
> kmscube sample.
> The FPS at pandaboard is lower than my test board. ( pandaboard 45 fps vs my
> device 75fps up)
I expect the difference is your test board is not vsync locked but
pandaboard/kms is. Also, currently kms/gbm winsys is only double
buffered. Possibly with triple buffered you would hit 60fps (or
whatever your monitor refresh rate is).
An EGL extension needs to be invented so that weston can figure out
the # of buffers. Until then, we can enable triple buffering without
screwing up weston's dirty region tracking.
If you need triple buffering, you should use x11 fullscreen for now.
> Our test device is single core arm1176@900mhz with ddr3@800mhz and
> mali-200@400mhz.
> I think pandaboard is better than our device (cpu performance, memory
> bandwidth, 3D graphic chip).
> Is the mali-200@400mhz better than powervr sgx540?
> How can I improve our game's performance at pandaboard?
> I have another question.
> When our game is running, we get a lot of message just like the following.
There are still a lot of debug traces that are enabled for the gbm
code.. these will be removed later, but for now we left them in case
there are any issues to debug
>> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
>> wayland patches so it should work as soon as these wayland patches are
>> merged and PPA is updated.
>> Perhaps someday I'll make it more fancy to detect hotplug, support
>> multiple displays, configurable resolution, overlay planes, etc.
On Wednesday, October 3, 2012 3:16:04 PM UTC+8, rob wrote:
> On Wed, Oct 3, 2012 at 9:03 AM, He-Jie Shih <bigno...@gmail.com<javascript:>> > wrote:
I expect the difference is your test board is not vsync locked but
> pandaboard/kms is. Also, currently kms/gbm winsys is only double > buffered. Possibly with triple buffered you would hit 60fps (or > whatever your monitor refresh rate is).
> I remove the "waiting_for_flip" mechanism as in kmscube sample, and then
I get 63~7x fps. I don't know that the "waiting_for_flip" mechanism is necessary or not.
I found some hardware spec.
Mali-200 fill rate: 275M pixels/s at 275hmz (from arm mali website) Our device: perhaps 400M pixels/s at 400mhz
powervr sgx 540 fill rate: 1G pixels/s at 200mhz pandaboard: 1G up pixels/s at 384mhz
I think the pandaboard should do better. (1xx fps up)
> An EGL extension needs to be invented so that weston can figure out > the # of buffers. Until then, we can enable triple buffering without > screwing up weston's dirty region tracking.
> If you need triple buffering, you should use x11 fullscreen for now.
I found some sample to trigger full screen in x11. The code is just like:
X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0x0 Serial number of failed request: 14 Current serial number in output stream: 18
Can I get some sample to create full screen in x11 with powervr?
> X Error of failed request: BadAtom (invalid Atom parameter)
> Major opcode of failed request: 18 (X_ChangeProperty)
> Atom id in failed request: 0x0
> Serial number of failed request: 14
> Current serial number in output stream: 18
> Can I get some sample to create full screen in x11 with powervr?
> Thanks!
NeHe has some very simple code to setup a X window to use with OpenGL. I guess the window setup part can be reused.
Hello, I am having difficulties doing triple buffering with the new kms/gbm gles mode. AFAIK, the EGL driver only does double buffering in this mode so instead of using eglSwapBuffers, I tried allocating renderbuffers or textures backed by gbm buffer objects, using eglCreateImageKHR, and attaching them to a FBO. That works but the EGL driver seems to do extra copying around internally when I do that, costing 3ms per frame looking at pvrtune traces, and the result is vertically flipped. The flipping is probably manageable but the extra rendering time is a problem for me. Any ideas? Thanks.
On Mon, Oct 15, 2012 at 12:49 PM, Philippe H <phars...@sta.samsung.com> wrote:
> Hello,
> I am having difficulties doing triple buffering with the new kms/gbm gles
> mode. AFAIK, the EGL driver only does double buffering in this mode so
yes.. the problem is that using triple buffering will confuse weston's
dirty-region tracking, as it needs to know how frequently a buffer is
reused. (Basically, it takes the union of the current damage region
and the damage of the previous frame, to figure out what the minimal
area to re-render is. Which breaks down when you add a 3rd buffer.)
> instead of using eglSwapBuffers, I tried allocating renderbuffers or
> textures backed by gbm buffer objects, using eglCreateImageKHR, and
> attaching them to a FBO. That works but the EGL driver seems to do extra
> copying around internally when I do that, costing 3ms per frame looking at
> pvrtune traces, and the result is vertically flipped. The flipping is
> probably manageable but the extra rendering time is a problem for me.
well, if it is an option, the easiest way to get triple buffering
right now would be to use X11. For a fullscreen app (especially if
you don't have a silly window manager in the way), there really is no
fps overhead. Although it is extra stuff to have in your filesystem..
With gbm, you might be able to hack around this by alternating between
two difference surfaces? For each surface you'll get a flipchain of
two buffers. KMS doesn't really care if you are passing fb's from
different surfaces to drmModePageFlip().
Thanks Rob. One reason I am looking at using gbm is so that I can render OpenGL into overlay planes, which doesn't seem possible with X11? I thought of using 2 surfaces but didn't want to have 4 buffers but in fact it can still be made to behave like 3 (timing wise). I tried and it's working well:-) --Philippe
On Monday, October 15, 2012 3:16:30 PM UTC-7, rob wrote:
> On Mon, Oct 15, 2012 at 12:49 PM, Philippe H <phar...@sta.samsung.com<javascript:>> > wrote:
> > Hello, > > I am having difficulties doing triple buffering with the new kms/gbm > gles > > mode. AFAIK, the EGL driver only does double buffering in this mode so
> yes.. the problem is that using triple buffering will confuse weston's > dirty-region tracking, as it needs to know how frequently a buffer is > reused. (Basically, it takes the union of the current damage region > and the damage of the previous frame, to figure out what the minimal > area to re-render is. Which breaks down when you add a 3rd buffer.)
> > instead of using eglSwapBuffers, I tried allocating renderbuffers or > > textures backed by gbm buffer objects, using eglCreateImageKHR, and > > attaching them to a FBO. That works but the EGL driver seems to do extra > > copying around internally when I do that, costing 3ms per frame looking > at > > pvrtune traces, and the result is vertically flipped. The flipping is > > probably manageable but the extra rendering time is a problem for me.
> well, if it is an option, the easiest way to get triple buffering > right now would be to use X11. For a fullscreen app (especially if > you don't have a silly window manager in the way), there really is no > fps overhead. Although it is extra stuff to have in your filesystem..
> With gbm, you might be able to hack around this by alternating between > two difference surfaces? For each surface you'll get a flipchain of > two buffers. KMS doesn't really care if you are passing fb's from > different surfaces to drmModePageFlip().
