ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
airlied has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
thaytan has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
columbarius has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
ghishadow has left #dri-devel [#dri-devel]
Daanct12 has joined #dri-devel
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
iive has quit [Quit: They came for me...]
simon-perretta-img has quit [Remote host closed the connection]
asrivats has quit [Remote host closed the connection]
yyds has joined #dri-devel
yuq825 has joined #dri-devel
simon-perretta-img has joined #dri-devel
flynnjiang has joined #dri-devel
ghishadow has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Calandracas has joined #dri-devel
Calandracas_ has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
glennk has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
agd5f_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
agd5f has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Duke`` has joined #dri-devel
fab has joined #dri-devel
bgs has joined #dri-devel
Dark-Show has quit [Quit: Leaving]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
zxrom has quit []
itoral_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
itoral has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Sid127 is now known as tiredchiku
itoral__ has joined #dri-devel
itoral_ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
sima has joined #dri-devel
kts has joined #dri-devel
pjakobsson_ has quit [Remote host closed the connection]
kts has quit []
itoral_ has joined #dri-devel
kts has joined #dri-devel
itoral__ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
bgs has quit [Remote host closed the connection]
rasterman has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
itoral__ has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
karolherbst has quit [Quit: Konversation terminated!]
itoral_ has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #dri-devel
likelyso has joined #dri-devel
kts has joined #dri-devel
frieder has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has joined #dri-devel
mvlad has joined #dri-devel
mbrost_ has joined #dri-devel
kj2 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
carbonfiber has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
airlied_ is now known as airlied
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<likelyso>
Not a lot of complexity is there to spot, only intermediate results, some kind of dependency tree needs to be hashed, cause offsets are generated in the hash for dependent instructions, so to get output results of pcX, it needs operands loaded before to be performed the async ones as well as dependent ones generated in hash, but UpTo only pcX not to deeper, so to blacklist a deeper intermediate result, it needs to remove their offset, but
<likelyso>
those are based of dependency graph, but there's an SSA or where that's natural, out of SSA would leave the users after the write. So intermediate results fetching need to be fast, need to decide over the mapping there, Linus has been giving critics for dwarf too, SSA dwarf otherwise would be fast way to there likely. So pc is defined by its writes virtual registers index, and reusing dwarf structures it's possible to fetch where c variabl
<likelyso>
e a is in SSA. That should of course do it, unless I develop something thinner but at the moment nothing clever has hit me as of yet.
glennk has quit [Ping timeout: 480 seconds]
kts_ has quit []
<MrCooper>
columbarius: gbm_bo_map only really works with single-plane formats
Daanct12 has quit [Ping timeout: 480 seconds]
<columbarius>
would the implicit api prevent me from creating a buffer with a multiplane format, or would it just return me a bo with a single fd, which I could import with gl, but not map manually (at least via a public api)?
jsa has joined #dri-devel
lynxeye has joined #dri-devel
kts has joined #dri-devel
kj2 has quit [Remote host closed the connection]
likelyso has quit [Read error: Connection reset by peer]
kj2 has joined #dri-devel
<MrCooper>
columbarius: the GBM YCbCr formats were added long before modifiers were a thing, presumably it was possible to use them somehow
davispuh has joined #dri-devel
sgruszka has quit [Quit: Leaving]
Company has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Daanct12 has joined #dri-devel
Daanct12 has quit []
Daanct12 has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<tzimmermann>
jfalempe, hi. about the recent mgag200 patchset: thanks for testing. do you know which chip version the iDrac console uses?
heftig has quit [Quit: Bridge terminating on SIGTERM]
Newbyte has quit []
valida-69[m] has quit []
gnustomp[m] has quit []
YaLTeR[m] has quit []
aradhya7[m] has quit []
doraskayo has quit []
tuxayo has quit []
nyorain[m] has quit []
DemiMarie has quit [Quit: Bridge terminating on SIGTERM]
zzoon[m] has quit [Quit: Bridge terminating on SIGTERM]
cmeissl[m] has quit [Quit: Bridge terminating on SIGTERM]
halfline[m] has quit []
Tooniis[m] has quit []
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
Hazematman has quit [Quit: Bridge terminating on SIGTERM]
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
tleydxdy has quit [Quit: Bridge terminating on SIGTERM]
Hi-Angel has quit []
M839ty9[m] has quit []
raambm[m] has quit []
Anson[m] has quit []
tomba has quit [Quit: Bridge terminating on SIGTERM]
samueldr has quit []
exp80[m] has quit []
T_UNIX has quit []
treeq[m] has quit []
pankart[m] has quit []
reactormonk[m] has quit []
gegoxaren[m] has quit [Quit: Bridge terminating on SIGTERM]
Targetball[m] has quit []
ella-0[m] has quit []
MotiH[m] has quit []
devarsht[m] has quit []
naheemsays[m] has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
kos_tom has quit [Quit: Bridge terminating on SIGTERM]
moben[m] has quit []
Eighth_Doctor has quit []
nick1343[m] has quit []
ids1024[m] has quit []
znullptr[m] has quit []
kallisti5[m] has quit []
fkassabri[m] has quit []
x512[m] has quit []
sigmoidfunc[m] has quit []
ohadsharabi[m] has quit []
Guest1740 has quit []
dhirschfeld2[m] has quit []
EricCurtin[m] has quit []
chema has quit [Quit: Bridge terminating on SIGTERM]
egalli has quit []
robertmader[m] has quit []
gdevi has quit []
tintou has quit [Quit: Bridge terminating on SIGTERM]
yshui` has quit [Quit: Bridge terminating on SIGTERM]
enunes[m] has quit [Quit: Bridge terminating on SIGTERM]
onox[m] has quit []
kunal_10185[m] has quit []
Coelacanthus[m]1 has quit []
jasuarez has quit [Quit: Bridge terminating on SIGTERM]
viciouss[m] has quit []
dabrain34vulkanised2024[m] has quit [Remote host closed the connection]
ram15[m] has quit [Remote host closed the connection]
tomeu has quit [Write error: connection closed]
QiuWenbo[m] has quit [Remote host closed the connection]
bubblethink[m] has quit [Remote host closed the connection]
FL4SHK[m] has quit [Remote host closed the connection]
hax0kartik[m] has quit [Write error: connection closed]
daniliberman[m] has quit [Remote host closed the connection]
fililip[m] has quit [Write error: connection closed]
m00nlit[m] has quit [Remote host closed the connection]
tak2hu[m] has quit [Remote host closed the connection]
siddh has quit [Remote host closed the connection]
pedrohlc[m] has quit [Remote host closed the connection]
koki23[m] has quit [Remote host closed the connection]
Guest3304 has quit [Write error: connection closed]
YHNdnzj[moz] has quit [Remote host closed the connection]
aura[m] has quit [Remote host closed the connection]
valentine1 has quit [Remote host closed the connection]
Mis012[m] has quit [Write error: connection closed]
KunalAgarwal[m][m] has quit [Remote host closed the connection]
joantolo[m] has quit [Write error: connection closed]
K0bin[m] has quit [Write error: connection closed]
healfdanex[m] has quit [Remote host closed the connection]
AlexisHernndezGuzmn[m] has quit [Remote host closed the connection]
devnull[m] has quit [Remote host closed the connection]
Alex[m]1234567 has quit [Remote host closed the connection]
kusma has quit [Remote host closed the connection]
cwfitzgerald[m] has quit [Remote host closed the connection]
wv[m] has quit [Remote host closed the connection]
ofirbitt[m] has quit [Remote host closed the connection]
kerel has quit [Remote host closed the connection]
Mershl[m] has quit [Remote host closed the connection]
dcbaker has quit [Remote host closed the connection]
Wallbraker has quit [Remote host closed the connection]
mbrost_ has quit [Ping timeout: 480 seconds]
swick[m] has quit [Ping timeout: 480 seconds]
gallo[m] has quit [Ping timeout: 480 seconds]
vdavid003[m] has quit [Ping timeout: 480 seconds]
marmarek[m] has quit [Ping timeout: 480 seconds]
PiGLDN[m] has quit [Ping timeout: 480 seconds]
michael5050[m] has quit [Ping timeout: 480 seconds]
<tzimmermann>
there are only two chips that actively use the bmc clock
<tzimmermann>
ew3 and wb
<tzimmermann>
this appears to be an ew3
<tzimmermann>
i'll add bmc functionality for those two chips
kts has joined #dri-devel
Mangix has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
apinheiro has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
benjaminl has joined #dri-devel
glennk has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
kts has joined #dri-devel
cmichael has joined #dri-devel
<jfalempe>
tzimmermann: ok these are the two models using mgag200_bmc_enable_vidrst(). But even for other models, I'm wondering what the userspace does if the connector is unconnected and mode is empty.
<tzimmermann>
jfalempe, the connector is then disconnected and userspace wouldn't use it
<tzimmermann>
i assume that chip models without vidrst support don't have bmcs connected
<tzimmermann>
otherwise, the driver should use vidrst during modesettings
<jfalempe>
hum, I think all mgag200 have bmc connected
<tzimmermann>
that's why i asked about the model
<jfalempe>
at least I used bmc on all mgag200 variant, when I tested DMA
<tzimmermann>
i also have to check my local test system
ghishadow has quit [Remote host closed the connection]
<tzimmermann>
but then, mgag200 should program the vidrst bits for those models as well
<tzimmermann>
there's also plain g200 support, which likely doesn't have a bmc. it's the desktop chip
<jfalempe>
yes, but I'm not sure there still user of plain g200 around.
<tzimmermann>
but the bmc support will be trivial once implemented. like in ast
<tzimmermann>
jfalempe, not many. but it's helpful to use a desktop sometimes
<jfalempe>
there is probably the same issue than ast, that you can't really know if there is a bmc connected or not.
<tzimmermann>
indeed. there's no bit to test for a bmc
<jfalempe>
so apart from the PCI G200, others may have a bmc, and we should add a virtual bmc connector for them ?
<tzimmermann>
so far i assumed that only wb and ew3 have bmcs. they are the only ones with vidrst code. for the others, i have to investigate.
kts has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
M839ty9[m] has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
hansg has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
yyds has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
itoral__ has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
robmur01 has quit [Remote host closed the connection]
frickefresh has joined #dri-devel
frickefresh_ has joined #dri-devel
frickefresh_ has quit []
frickefresh_ has joined #dri-devel
frickefresh_ has quit []
robmur01 has joined #dri-devel
nctcf^ has quit [Ping timeout: 480 seconds]
nctcf^ has joined #dri-devel
frickefresh_ has joined #dri-devel
frickefresh_ has quit []
frickefresh has quit []
frickefresh has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
frickefresh has quit []
frickefresh_ has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
kts has joined #dri-devel
ghishadow has joined #dri-devel
jsa has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.2.2]
cascardo has joined #dri-devel
fab has quit [Quit: fab]
kts has quit [Ping timeout: 480 seconds]
vliaskov_ has quit [Read error: No route to host]
Namarrgon has quit [Quit: WeeChat 4.2.1]
<mattst88>
with the massive increase in the number of tests (and therefore skipped tests) in dEQP-VK, I tested what would happen if we trimmed the caselist by removing known-to-skip tests
<mattst88>
on a 14-thread Intel system, the runtime dropped from 1h52 to 1h
<mattst88>
has anyone done any investigation of improving dEQP-VK runtimes?
<mattst88>
e.g. is it possible to speed up test skipping somehow?
rasterman has quit [Quit: Gettin' stinky!]
<zmike>
there was some work done on this last year
<zmike>
because after shader object tests landed the test skipping took literal hours
<zmike>
I'm not sure if skipping could be improved further? probably worth opening a ticket
<mattst88>
wow
<mattst88>
I saw some patches land upstream that reduced the number of useless/duplicated tests after the shader object tests landed, but even still... on the most capable Intel GPU we're passing ~1.2 million tests and skipping ~2.5 million /o\
<mattst88>
guess the first thing I'll do is run deqp-vk under perf with a caselist that is only known-to-skip tests and see what it's doing
<rg3igalia>
my guess is that most time will be spent on two steps: (a) generating the caselist hierarchy and (b) running the support check methods to see if the test is supported
<rg3igalia>
i.e. implementations of ::checkSupport for the TestCase class
<mattst88>
thanks
hansg has joined #dri-devel
<mattst88>
might require too long of an answer for IRC, but what is the purpose of generating the caselist hierarchy?
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<rg3igalia>
assigning each case a test name, basically, organizing them in a tree
hansg has quit []
tlwoerner has quit [Quit: Leaving]
<rg3igalia>
i.e. when you run dEQP-VK.pipeline.shader_object_whatever.blah, there's a "pipeline" test group, followed by a "shader_object_whatever" test group, etc etc
<rg3igalia>
and each of those has a subcase, and that's generated on runtime
tlwoerner has joined #dri-devel
hansg has joined #dri-devel
<rg3igalia>
it takes a few seconds to generate the full hierarchy, which is annoying when you want to run a single case, but not a very long time if you want to run millions
<mattst88>
okay. and the resulting data structure is used to determine all the tests that should be run?
<rg3igalia>
yes
<rg3igalia>
for example, if you run deqp-vk --deqp-runmode=stdout-caselist >/dev/null you can measure the time it takes to generate the full list of cases
<mattst88>
ah, cool
<mattst88>
I wonder if deqp-runner magnifies that cost when it divides the deqp invocations into groups of e.g. 500?
<rg3igalia>
depends on how much time it takes to run those 500 tests
<rg3igalia>
for example, I know a few test groups where each test runs in milliseconds, so running 500 tests or skipping 500 tests fakes a fraction of a second, so generating the test hierarchy may take comparatively long
kts has joined #dri-devel
<rg3igalia>
while others are slower, so 500 tests is not too bad
cmichael has quit [Remote host closed the connection]
<rg3igalia>
taking a look at the checkSupport code, I think we could throw in a couple of optimizations to make skipping shader object tests much faster
<rg3igalia>
for example, isCoreDeviceExtension is super slow because it doesn't cache the extension list per api version, so we could do that
<rg3igalia>
and then we could cache the results for a given extension in a hash or set
<mattst88>
interesting, yeah. I will take a look at that and see what improvements I can get
<rg3igalia>
do you have access to khronos stuff?
<mattst88>
just a quick 2-minute deqp-vk run shows 5% of time spent in tcu::(anonymous namespace)::channelToFloat
<mattst88>
yeah
<rg3igalia>
could you open an issue in the tracker explaining your shader object case? the 1h vs 1h 52m
<mattst88>
yeah, will do
<rg3igalia>
someone from my team could take a look at this in the coming days/weeks and improve the situation, thanks!
simon-perretta-img has quit [Ping timeout: 480 seconds]
<robclark>
mattst88: at least depending on the test, deqp spends a lot of time in it's reference sw rasterizer.. but I think the problem here is just (re)initializing all the tests for each invocation of deqp-vk. Ie. if you have that many skips, odds are you have a bunch of invocations that end up running few or no tests
<robclark>
mattst88: it would be cleaver if there could be a "zygote" deqp process which forks instances for each batch of tests, perhaps?
<mattst88>
yeah, I suspect so
<robclark>
I suppose you should mention this is parallel deqp-runner in the krhonos issue.. I guess the issues are different if you are running deqp the "official" way (ie. less startup overhead, but single threaded)
simon-perretta-img has joined #dri-devel
<mattst88>
oh, very true
simon-perretta-img has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
bgs has joined #dri-devel
Namarrgon has joined #dri-devel
simon-perretta-img has joined #dri-devel
<willy>
does anyone have suggestions for how i might go about testing changes to fb_defio? I don't think I have any of the hardware that uses it
kj2 has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
<javierm>
willy: the DRM fbdev emulation layer uses it IIRC? So you could test it by enabling DRM_FBDEV_EMULATION and using the emulated /dev/fb? dev
* willy
nods. I can grep, I just have no idea how all the graphics stuff fits together
<willy>
I come to you from MM land; I need to stop fb_defio from touching struct page
<javierm>
willy: sorry, I didn't imply that you can't grep :) But was mostly mean to confirm that the generic fbdev emulation did use defio
<javierm>
because I could be misremembering
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
frieder has quit [Remote host closed the connection]
mbrost has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
hir0pro has joined #dri-devel
zxrom has joined #dri-devel
mbrost has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
amarsh04 has quit []
amarsh04 has joined #dri-devel
rasterman has joined #dri-devel
hir0pro has quit []
lynxeye has quit [Quit: Leaving.]
jhli has joined #dri-devel
<mattst88>
rg3igalia: I might be misreading the perf report, but is seems to me that for any invocation of deqp-vk by deqp-runner, if any of the 500 tests is e.g. created by ::createExtendedDynamicStateTests, then all extended dynamic state tests will be instantiated
<mattst88>
does that seem correct?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<mattst88>
if so, I wonder what would happen if we modified deqp-runner to run groups of related tests together
simon-perretta-img has joined #dri-devel
bgs has quit [Ping timeout: 480 seconds]
<zmike>
on one hand sorting might be beneficial for runtimes, but on the other hand it would eliminate some cases where weird caselist ordering finds driver bugs
<mattst88>
yeah, definitely true
kts has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Surkow|laptop has joined #dri-devel
fab has quit [Quit: fab]
hir0pro has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
<zmike>
that's probably more an issue on the GL side though
simon-perretta-img has joined #dri-devel
<Sachiel>
but the tests already run sorted
mvlad has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
<tzimmermann>
willy, how does defio still use struct page?
<tzimmermann>
it doesn't really modify it
<tzimmermann>
it only holds a reference
<willy>
it sets page->mapping, it sets PageDirty(), it calls page_mkclean()
<tzimmermann>
willy, can/will you replace that code?
<willy>
that's the plan, once i can test that i've not broken it
<willy>
i've just got the dusty old laptop into a state where it can boot a -next kernel. the iwlwifi driver is bitching, but ignore that ...
<tzimmermann>
i've done most of that stuff in recent releases. can i help you somehow?
<willy>
that would be nice! i have a sketch of a design, but haven't coded it up. wanted to get this laptop to a point where i could prove it was actually running the fb_defio code first
<willy>
lsmod says i don't even have any fb modules loaded (wayland is running, but i guess it's not using fbdev)
<airlied>
tzimmermann: can/do any of the virtual gpu drivers use fb_defio?
<tzimmermann>
you can boot most modern test systems with DRM and enable simpledrm
<tzimmermann>
airlied, anything with generic fbdev uses defio.
<airlied>
willy: so you could use a vm to test
<willy>
qemu?
<tzimmermann>
willy, booting with the kernel's nomodeset parameter should only load simpledrm
<tzimmermann>
qemu + bochs
kts has quit [Ping timeout: 480 seconds]
<tzimmermann>
fbdev-generic emulates fbdev support for bochs. it uses fb_defio
<tzimmermann>
if you grep the DRM directory for 'drm_fbdev_generic' you can see the drivers that use fbdev-generic
<mattst88>
Sachiel: when run from deqp-runner, they run sorted?
<willy>
hm, i get a blank screen on dustylaptop when passing "nomodeset"
<tzimmermann>
willy, that might be worth a bug report on its own
<tzimmermann>
what HW is it?
<Sachiel>
mattst88: iirc, deqp-runner will call deqp-vk once for each caselist, deqp-vk runs the tests in that caselist sorted by the order they are defined in the framework
<willy>
Sunrise Point -- 2016 era
<willy>
Intel HD Graphics 620
<mattst88>
Sachiel: right, but each caselist of 500 tests given to an invocation of deqp-vk won't be 500 consecutive tests from a plain deqp-vk run, right?
<willy>
i say blank screen, it's actually black with a flashing text cursor
<Sachiel>
mattst88: no, it'll be those 500 tests, just not in the order the caselist shows them
<tzimmermann>
do you have CONFIG_DRM=y CONFIG_DRM_SIMPLEDRM=y and CONFIG_SYSFB_SIMPLEFB=y ?
<mattst88>
right. I'm suggesting that deqp-runner could group tests together that are created by the same function (like ::createExtendedDynamicStateTests) and feed a group of 500 of those to deqp-vk
sarnex has quit [Ping timeout: 480 seconds]
<willy>
i have the Debian config; let me just verify those ...
<Sachiel>
mattst88: ah, yeah, that would lose coverage that has found real issues
<willy>
argh, no, Debian didn't enable SIMPLEDRM
<mattst88>
Sachiel: right
<tzimmermann>
willy, when you rebuild the kernel with the config options i mentioned, you should also set CONFIG_DRM_I915=n and CONFIG_XE=n. that will disable any intel driver for the HD 620
<tzimmermann>
and your system should be fb_defio-only :)
<tzimmermann>
you should also set CONFIG_FB_DEVICE=y so that you get a device file for the fbdev code under /dev/fb0
<tzimmermann>
you can trigger fb_defio simply by writing to /dev/fb0
<tzimmermann>
fb_defio will track the modified pages
<tzimmermann>
no wait... you need to do an mmap and write to the mmap'ed range
<tzimmermann>
the regular I/O writes won't go through fb_defio
sarnex has joined #dri-devel
<willy>
hm. now with those two config options enabled, adding "nomodeset" to the command line results in freezing after "Loading initial ramdisk ..."
<willy>
the cursor isn't blinking
<tzimmermann>
willy, you can boot the kernel with fb.lockless_register_fb=1 to maybe get some more information out of the console code
<tzimmermann>
but IDK what the debian kernel does
<willy>
well, i'm booting next-20240408 just using the Debian config file as a start
gouchi has joined #dri-devel
<airlied>
willy: is that thing booting using bios?
<willy>
grub from efi, I believe
<airlied>
ah at least there is some hope, maybe check you get efifb on a normal boot before the gpu driver loads
<willy>
i think i do, let me reboot without nomodeset
<willy>
oh! journalctl shows it did boot last time! i had a hunch that it might be fine, just waiting at the dm-crypt prompt, so i entered my drive passphrase
sima has quit [Ping timeout: 480 seconds]
<willy>
it never displayed anything, but it did boot