Ballmerpeak devblog

Software development, related stuff and others

Debugging HyperZ and fixing a radeon drm linux kernel module

June 19, 2019 — Richárd Thier

It was only a few days ago I have finished debugging a really heavy bug making as big of a mesa performance hit in the userland radeon driver that it became a news article on Phoronix. Back then while still on the heavy journey for getting my performance back I saw HyperZ was also not enabled for me, but if I enable it I gain 10-15% more performance - and an unplayable 3D screen.

On the original blog post I have also written about how to troubleshoot a performance issue generally, but what to do if you know about a performance increasing functionality - just you see it destroys the 3D picture?

Read on if you are interested in linux graphics internals once again ;-)

Read more...

Tags: drm, hyperz, r300, radeon, linux, kernel, mesa, arch, 32bit, linux, debug, glitches, fix, contribute, open-source, graphics, stack, analysis, 3D, optimization, tutorial, system, internals, hackerman, opengl, zbuffer, hiz, zmask, documentation

Debugging mesa and the linux 3D graphics stack

June 11, 2019 — Richárd Thier

Have you ever wanted to troubleshoot or even contribute to the linux graphics stack? Were you ever interested in doing a deep dive? Read on if you dare, but do not fear - I was rookie on the topic myself before I went for my hunt on a 50-1000% slowdown after some updates and a distro change.

I wanted to document the process of delving deep into open source drivers. I just wanted to put things together as it might be valuable for others wanting to do similar things - I was and still is a rookie for these things after all.

The power of open source: We can fix a more than decade old hardware getting a slowdown as easily as a new one! Fuck you planned obsolesence haha!

Read more...

Tags: mesa, arch, 32bit, linux, debug, slowdown, contribute, open-source, graphics, stack, analysis, 3D, optimization, tutorial, system, internals

Threads: Why you should hate and love them 1

July 12, 2015 — Richárd Thier

I think most software developers already (think that they) know much about threads. People know the problem of the dining philosophers, they heard how hard is to ensure correctness and know about tales of various threading related catastrophes. Despite this, however I still feel that there are many (not even poor) practical-only developers out there who still underestimate the various problems threading issues can introduce: The kind of people who always argue (sometimes with understandable arguments) that "patterns and rules are good, but in practice you can break them 'for the real life'" or "in theory there are these or those problems, but 'reality is different' and you can live without this or that rule if the software is written according to the business demands (and you should focus that)" also tend to think about threading issues with the same mindset... This however just doesn't work in the case of concurrency - if you break it, it is utterly broken in many ways you are not aware of, and what is worse is that these problems cannot be found out by testing!

Because I want to spread some of the wisdom on this hard topic, I've choosen to write down some of my suggestions and some examples that I have found in real-life. I hope it makes sense and helps the readers.

As an addendum, I have chosen to use a nice little diagramming tool that I have found while lurking around the internet to make my illustrations readable from a console. I think this is something that I will try to do for the future too, as I want this blog to be enjoyable from elinks too (of course there will be exceptions I think, but it is better to minimize them in my opinion)

Read more...

Tags: threads, concurrency, java, OSGi, development, lock ordering, deadlock, dump analysis, asciiflow, bug, analysis

Threads: Why you should hate and love them 1

July 12, 2015 — Richárd Thier

I think most software developers already (think that they) know much about threads. People know the problem of the dining philosophers, they heard how hard is to ensure correctness and know about tales of various threading related catastrophes. Despite this, however I still feel that there are many (not even poor) practical-only developers out there who still underestimate the various problems threading issues can introduce: The kind of people who always argue (sometimes with understandable arguments) that "patterns and rules are good, but in practice you can break them 'for the real life'" or "in theory there are these or those problems, but 'reality is different' and you can live without this or that rule if the software is written according to the business demands (and you should focus that)" also tend to think about threading issues with the same mindset... This however just doesn't work in the case of concurrency - if you break it, it is utterly broken in many ways you are not aware of, and what is worse is that these problems cannot be found out by testing!

Because I want to spread some of the wisdom on this hard topic, I've choosen to write down some of my suggestions and some examples that I have found in real-life. I hope it makes sense and helps the readers.

As an addendum, I have chosen to use a nice little diagramming tool that I have found while lurking around the internet to make my illustrations readable from a console. I think this is something that I will try to do for the future too, as I want this blog to be enjoyable from elinks too (of course there will be exceptions I think, but it is better to minimize them in my opinion)

Read more...

Tags: threads, concurrency, java, OSGi, development, lock ordering, deadlock, dump analysis, asciiflow, bug, analysis