On Wed, 28 Jun 2017 15:06:48 +0100 Mick <michaelkintz...@gmail.com> said:
> On Wednesday 28 Jun 2017 18:10:33 Carsten Haitzler wrote: > > On Wed, 28 Jun 2017 08:52:56 +0100 Mick <michaelkintz...@gmail.com> said: > > > > Styles: haven't changed this. > > > Fast Effects: Enabled only fast composite effects for windows. > > > Disable Effects: none selected. > > > Rendering Behavior: Don't composite fullscreen windows, > > > Engine: OpenGL, > > > > > > OpenGL options: > > > Tear-free updates (VSynced), > > > > btw... vsync/tear-free ... is a good thing to have :) > > > Yes, I've made a note about this from you mentioning it in some previous > thread. ;-) :) > I started a Fluxbox session and tried to cause the same crash, but failed to > make it happen. Perhaps because Fluxbox does not use compositing. Anyway,I yes. doesn't composite. so rendering takes a very different path (drawing from clients never involves the windowmanager at all. just client + x). > built mesa with debug flags and captured another crash. Can you please scan > through the backtrace below and confirm if the verdict is still the same and > if anything mesa related in particular stands out which I enter in a bug > report? sure. but keep in mind that just because e shows a bug doesnt mean other compositors will. there will be a absolute boatload of permutations and combinations of order, state etc. all of which are valid but only some produce the bug. some compositors might hit it, others may not. e's rendering code will likely be significantly more complex than 99% of compositors (if not every single one) because it not only renders some "simple rectangles (2 triangles) with bound glxpixmaps/eglimages" like many compositors... it renders tonnes of detailed stuff with opengl - the titlebars are gl rendered (every letter in them is a pair of triangles with texture coords). the titelbars themselves will consist of many more triangles with layers and textures, as will the shadows, the shelf content will be a whole bevvy of triangle content. where most compositors will maybe render dozens of triangles with very large textures, e will render 1000's of triangles with many many many texture sources etc. actually e itself doesn't have the rendering code... evas does. it's the same code that can be used by client apps that are written with efl to use opengl to accelerate rendering. it's far more complex overall than most compositors. we do this because we recycle the rendering code everywhere thanks to evas... it makes e an immensely powerful wm/compositor inside of itself as it's fully capable of everything client apps are directly itself... but it does mean we put a completely different workload on the drivers etc. > https://pastebin.com/Y6SxaKGF now to this... it doesn't tell me more than it did before... it's a fence sync within the driver layer. it's a problem between the driver and itself across process boundaries. if you want i can explain what fences are and their purpose (in general) and why this would be the case and i can probably narrow down where the issues are being caused in the x 2d + dri driver stack... but it'll be a long explanation. i do not know the DETAILS of the fence implementations down at the dri level... but i do know what fences are, what they in general do and why this tells me the issue is not something we can solve in efl... if you want the details - let me know. otherwise know that this is a bug you likely have to file with the dri3/mesa/xorg 2d/radeon driver people... :/ > Thanks again. > -- > Regards, > Mick -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
