66 replies to this topic

[pieterg]

Please guys, try to disable alpha blending acceleration instead. Increasing the acceleration threshold is not a real fix, it just reduces the number of times you will notice the issue.

In OpenViX Dags machines had alpha blending disabled, but still had the issue prior to this fix: https://github.com/O...nfigure.ac#L347

How did you disable alpha blending acceleration?

This should have worked (in your machine.conf):

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=always

[pieterg]

https://github.com/O...nfigure.ac#L347

ah I see.
Indeed, that should have worked as well (though my advise would be to use machine.conf, and keep e2's configure.ac clean of box-specific stuff)

If things are still broken with alphablending acceleration disabled, that probably means blit acceleration itself is broken on this hardware.
Perhaps only 8bpp acceleration has been implemented (and 32bpp is broken)?

You can avoid using acceleration alltogether by increasing the threshold back to the value which was previously used for 32bpp surfaces:

EXTRA_OECONF_append_pn-enigma2 += " --with-blitaccelerationthreshold=192000"

[Frenske]

Might this be related?
Both the et4000 and et5000 halt on this point with today’s image.

root@et5x00:~# init 4
root@et5x00:~# ENIGMA_DEBUG_LVL=4 enigma2
PYTHONPATH: /usr/lib/enigma2/python
DVB_API_VERSION 5 DVB_API_VERSION_MINOR 10
ENIGMA_DEBUG_LVL=4
[Avahi] avahi_timeout_new
[Avahi] avahi_watch_new(3 0x1)
[Avahi] avahi_timeout_update
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[Avahi] client state: 2
[Avahi] avahi_timeout_new
[Avahi] avahi_timeout_free
[eInit] + (1) Background File Eraser
[eInit] + (5) Tuxtxt
[eInit] + (8) graphics acceleration manager

[prl]

gpixmap.cpp horrible bug starting with this commit.
https://github.com/O...05a1b244172a087

 

That change assumes that surface->stride is measured in pixels, but it's measured in bytes. For example, 8-bit to 8-bit surfaces:

		if ((surface->bpp == 8) && (src.surface->bpp == 8))
		{
			uint8_t *srcptr=(uint8_t*)src.surface->data;
			uint8_t *dstptr=(uint8_t*)surface->data;
			...
				for (int y = area.height(); y != 0; --y)
				{
					...
					srcptr += src.surface->stride;
					dstptr += surface->stride;
				}

And for 32-bit to 32-bit surfaces, srcptr and dstptr are converted to byte pointers before adding the strides:

		else if ((surface->bpp == 32) && (src.surface->bpp==32))
		{
			uint32_t *srcptr=(uint32_t*)src.surface->data;
			uint32_t *dstptr=(uint32_t*)surface->data;
			...
			for (int y = area.height(); y != 0; --y)
			{
				...
				srcptr = (uint32_t*)((uint8_t*)srcptr + src.surface->stride);
				dstptr = (uint32_t*)((uint8_t*)dstptr + surface->stride);
			}

So, what's needed is to answer whether the threshold measure is bytes or pixels, and to do the arithmetic accordingly. A comment somewhere to say what the threshold units are would probably be a good idea, too.

 

For blitAlphaTest and particularly blitAlphaBlend, it's not at all clear a priori whether the measure should be bytes or pixels.

 

In the case of the software implementation of blitAlphaTest, there is an if/then/else in the inner loop, and for the case of blitAlphaBlend, there are 4 multiplies, 8 add/subtracts and 4 shifts in the inner loop. There can also be a colour lookup table access in the inner loop for 8-bit source -> 32-bit dest operations.

 

The blit acceleration threshold and its units probably need to be set by experimentation.

 

One of the changes in the Beyonwiz firmware in this area was to completely avoid acceleration for blitAlphaTest for the Beyonwiz U4 (--with-boxtype=et1300), because its blit hardware acceleration implements blitAlphaBlend when blitAlphaTest is requested.

[Huevos]

 

 

Please guys, try to disable alpha blending acceleration instead. Increasing the acceleration threshold is not a real fix, it just reduces the number of times you will notice the issue.

In OpenViX Dags machines had alpha blending disabled, but still had the issue prior to this fix: https://github.com/O...nfigure.ac#L347

 

How did you disable alpha blending acceleration?

This should have worked (in your machine.conf):

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=always

 

 

In this thread you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=always

On github you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=never"

Which did you intend?

[pieterg]

gpixmap.cpp horrible bug starting with this commit.
https://github.com/O...05a1b244172a087

 
That change assumes that surface->stride is measured in pixels, but it's measured in bytes.

indeed, stride is in bytes, by definition.
My mistake, I'll make a fix for that.
(as a result, the acceleration thresholds would have been 4 times lower than intended, for 32bpp pixmaps)

So, what's needed is to answer whether the threshold measure is bytes or pixels, and to do the arithmetic accordingly. A comment somewhere to say what the threshold units are would probably be a good idea, too.

I intended to use a threshold in bytes, and I intend to keep it that way after I fixed the issue with the stride.
The threshold defines have a comment which says the values are in bytes.

For blitAlphaTest and particularly blitAlphaBlend, it's not at all clear a priori whether the measure should be bytes or pixels.

Still, they are more likely to be proportional to the number of bytes (being compared and copied) than to the number of pixels.
To be more exact, we should have used a formula which uses the number of rows and columns, my tests have shown a huge difference between, say, a blit with 10x100 vs a 100x10 surface.
But I decided not to make things too complicated, the gains are too small. A single threshold works fine on average.

The blit acceleration threshold and its units probably need to be set by experimentation.

indeed, for the threshold values: use the GPIXMAP_CHECK_THRESHOLD define

[pieterg]

In this thread you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=always

On github you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=never"

Which did you intend?

to disable it: use 'never'.
I seem to have made a copy/paste error in this thread.

[WanWizard]

Do we know for which boxes this is an issue?

 

It now surfaces in our own Xtrend builds (confirmed on the ET8000, issue not present on the ET10000), so the manufacturer needs to update the BSP, but I assume more BSP's are affected?

[Huevos]

 

In this thread you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=always

On github you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=never"

Which did you intend?

 

to disable it: use 'never'.
I seem to have made a copy/paste error in this thread.

 

Ok. In machine.conf I have "never". Bumped enigma2 and built. Still the bug is present. What else should I try?

[Huevos]

Do we know for which boxes this is an issue?

 

It now surfaces in our own Xtrend builds (confirmed on the ET8000, issue not present on the ET10000), so the manufacturer needs to update the BSP, but I assume more BSP's are affected?

Hard to know. The spinner images are so small in PLi that the bug is not immediately obvious.

[WanWizard]

It doesn't seem to happen only with the spinner, but appearently everywhere this is used. For example in the media player, to place the coverart image of an MP3 file on screen.

 

The complaint is that it works fine in 6.1-release, it doesn't work in 6.2-rc, and the behaviour is that you very briefly see the coverart image flash, before the old/original image reappears. Seen on an ET8000. I can't reproduce it on an ET10000.

[Sicilian]

Do we know for which boxes this is an issue?

 

It now surfaces in our own Xtrend builds (confirmed on the ET8000, issue not present on the ET10000), so the manufacturer needs to update the BSP, but I assume more BSP's are affected?

I've confirmed on ET-8500 and dags 7362 boxes.

[Sicilian]

I'm actually surprised the issue has been on confirmed on ET8000.

 

In OpenViX for machines that have blending issues we force on or off alphablending via configure.ac. ET8000 never had issues.

 

ET-8500 had alphablending forced on, got issues with these changes.

 

VU+ No issues, our configure.ac has blending forced off. No issues with these changes

 

Dags has blending forced off, got issues with these changes.

 

Our configure.ac here: https://github.com/O...er/configure.ac

 

You'll see which machines had forced on and which off, ET8000 needed none forced on or off.

[WanWizard]

OpenPLi ET8000 doesn't have the issue with 6.1-release, but it does with the current develop.

[pieterg]

If you're referring to the clipart issue, I don't think that's related to alpha blending.

[Huevos]

 

 

In this thread you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=always

On github you say:

EXTRA_OECONF_append_pn-enigma2 += " --with-alphablendingacceleration=never"

Which did you intend?

 

to disable it: use 'never'.
I seem to have made a copy/paste error in this thread.

 

Ok. In machine.conf I have "never". Bumped enigma2 and built. Still the bug is present. What else should I try?

 

So now I've done that, now what?

[pieterg]

since this commit https://github.com/O...63e0d67681d133e the threshold should be 4 times higher, like it was intended...
Perhaps that 'fixes' your issues.

If you still see issues, that means your hardware not only has problems with alphablending, but with accelerated blits in general.
In that case try increasing the acceleration threshold like I suggested before:
 

If things are still broken with alphablending acceleration disabled, that probably means blit acceleration itself is broken on this hardware.
Perhaps only 8bpp acceleration has been implemented (and 32bpp is broken)?

You can avoid using acceleration alltogether by increasing the threshold back to the value which was previously used for 32bpp surfaces:

EXTRA_OECONF_append_pn-enigma2 += " --with-blitaccelerationthreshold=192000"

Edited by pieterg, 18 April 2018 - 09:15.

[WanWizard]

Is there a relation between the acceleration code and FPU?

 

The current images (develop and rc) for the ET4000 and 5000 don't start, in mean Enigma starts but hangs when it inits the acceleration (I mentioned that yesterday).

 

I reverted your commit in a homebuild for these two boxes, and now they start again. I haven't tested other mipsel32-nf boxes, but I assume they have the same issue?

[pieterg]

I'm not aware of any relation.
Which commit did you revert?

[Sicilian]

Is there a relation between the acceleration code and FPU?

 

The current images (develop and rc) for the ET4000 and 5000 don't start, in mean Enigma starts but hangs when it inits the acceleration (I mentioned that yesterday).

 

I reverted your commit in a homebuild for these two boxes, and now they start again. I haven't tested other mipsel32-nf boxes, but I assume they have the same issue?

 

ET8500 and DAGS 7362 booted fine, even with the issue.