romangg has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
gruetzkopf has joined #dri-devel
romangg has joined #dri-devel
shadeslayer has joined #dri-devel
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
alatiera is now known as Guest102
xp4ns3 has joined #dri-devel
lemonzest has quit [Quit: Quitting]
jcdutton has joined #dri-devel
ubitux has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<danvet>
airlied, I'm going to backmerge -rc3 to pull in 293837b9ac8d3021657f44c9d7a14948ec01c5d0
<danvet>
i915 is extremely on fire without that one :-(
ppascher has joined #dri-devel
robert_mader has joined #dri-devel
robert_mader has left #dri-devel [#dri-devel]
<jani>
danvet: yeah, it's in fixes and thus drm-tip, but not drm-intel-{gt-,}next
<danvet>
jani, drm-next with backmerge is building here, I'll ping you when it's done
<danvet>
apparently not all things mmap are fixed with that, but it's at least somewhat useable
FireBurn has joined #dri-devel
Sumera has quit [Ping timeout: 480 seconds]
iokill has quit []
iokill has joined #dri-devel
<danvet>
jani, drm-next now at -rc3, din/dign want to backmerge I think
<danvet>
mripard, mlankhorst I think backmerge for drm-misc-next might be good too?
<danvet>
-rc2 is quite broken on i915
iokill has quit [Quit: leaving]
iokill has joined #dri-devel
iokill has quit []
iokill has joined #dri-devel
gpoo has joined #dri-devel
iokill has quit []
xp4ns3 has quit [Quit: Konversation terminated!]
iokill has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
<jani>
danvet: I think dolphin and vivijim decided on getting the next pull request to drm-next, and backmerging after that, to get them in sync with each other
<jani>
pull request*s*
Lightkey has joined #dri-devel
<mripard>
danvet: done
lemonzest has joined #dri-devel
<karolherbst>
HdkR: yeah....
<karolherbst>
but that's something for vavle to fix :D
<karolherbst>
*valve
xp4ns3 has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
<danvet>
jani, yeah if there's no backmerge yet of -rc1/2 then waiting more is ok
<danvet>
mripard, thx
<jani>
danvet: I think there is
<danvet>
if there is a backmerge then backmerging sooner is probably better
<danvet>
since atm there's not a hole lot of testing you can do with rc1/2 :-(
Danct12 has joined #dri-devel
Sumera has joined #dri-devel
<karolherbst>
mhhh, I might want to group a bunch of issues. Would people prefer using milestones for that? It's just to have a quick list for a certain general bug (e.g. multithreading issues in nouveau)
dianders has joined #dri-devel
mbrost has joined #dri-devel
<MrCooper>
a milestone seems appropriate for that
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
<pepp>
dri2/glamor/glx question: if an application does "glDrawXXX(); glXSwapBuffers(); glReadBuffer(GL_FRONT); glReadPixels(...);" Can I expect to read exactly what was drawn by the glDrawXXX() operation?
<pepp>
AFAICT the swapbuffer causes a blit from the back buffer to the front buffer in X. But I don't understand if it means that I need to use a sync primitive (glXWaitX?) before glReadPixels or if it's handled by someone else (who?)
FireBurn has quit [Quit: Konversation terminated!]
jcdutton has quit []
_whitelogger has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
lynxeye has quit []
lynxeye has joined #dri-devel
<lynxeye>
pepp: glReadPixels waits for the outstanding GPU operations to finish before returning any data.
<alyssa>
Is it legal to have multiple screens concurrently? :|
<pepp>
lynxeye: even GPU operations in another process? (the back->front copy happens in X process)
<imirkin>
alyssa: pretty sure i'm not in any legal peril due to my dual-screen setup...
<alyssa>
imirkin: pipe_screens
<imirkin>
alyssa: Bad Idea (tm)
<alyssa>
Apparently "yes, because piglit does it???"
<imirkin>
alyssa: the shared helpers all make sure that never happens
* alyssa
wonders why screen_create is being called multiple times then
<alyssa>
like I should refactor away these global variables anyway but uh
<imirkin>
note how there's logic to cache the screen per fd(ish)
<imirkin>
except that the interesting logic got refactored somewhere far away where you can't see it, but it's cleverer than just per-fd
<alyssa>
I see
<alyssa>
maybe kmsro doesn't do that?
<imirkin>
that'd be unfortunate.
<lynxeye>
pepp: iirc there is no blit. The client app just sends the new frontbuffer to the X server for presentation. Both back and front are client buffers.
<imirkin>
basically if you end up with multiple screens, it just causes lots of sadness all over
<imirkin>
and yeah, doesn't look like all the drivers are using it
<pepp>
lynxeye: that's not what I'm observing :/ What you describe sounds like dri3 to me
<HdkR>
imirkin: Oh hey, a hash table to de-dup FDs? That's what I do as well :)
<MrCooper>
pepp: you might need to wait for the buffer swap to complete, e.g. with glXWaitForSbcOML
<MrCooper>
though I think that's a DRI2 implementation quirk if so
jekstrand has joined #dri-devel
iive has joined #dri-devel
ds- is now known as ds`
<pepp>
MrCooper: when using glamor the back->front copy is done using GL. So I'm wondering if the "wait for the buffer swap to complete" op should use glamor_finish
<MrCooper>
pepp: my point is that a back->front copy will only be executed once the target MSC is reached
<pepp>
but even if the copy is done later; to get the correct pixels values when reading from GL_FRONT the GPU copy has to be finished.
<MrCooper>
k, then I think it's expected to work as is
<MrCooper>
due to implicit sync
<pepp>
implicit sync is: the kernel will schedule my "gl_front -> staging texture" copy after the "gl_back -> gl_front" copy, right?
<MrCooper>
yeah; note that glReadBuffer(GL_FRONT) doesn't use the window's real draw buffer but a fake front buffer; there's also a copy from the real front buffer to the fake one
<MrCooper>
with DRI2CopyRegion
<pepp>
MrCooper: yes the fake front buffer thing is still unclear. But for implicit sync to work, X must have submitted the copy job to the kernel before the app submits its copy
<MrCooper>
right, the Xorg driver flushes as needed IIRC
ds` has quit [Quit: ...]
ds` has joined #dri-devel
<bl4ckb0ne>
is `VK_ICD_FILENAMES` also used to load instance extensions?
<pendingchaos>
no
<jekstrand>
bl4ckb0ne: No, it has nothing to do with instance extensions
<pendingchaos>
that's VK_LAYER_PATH IIRC
<pepp>
MrCooper lynxeye: thanks for your help :)
<bl4ckb0ne>
isnt that handled by the vulkan loader?
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<MrCooper>
pepp: out of curiosity, why do you care about DRI2? :)
<bl4ckb0ne>
got it with `VK_LOADER_DISABLE_INST_EXT_FILTER=1`
lemonzest has quit [Quit: Quitting]
ngcortes has joined #dri-devel
<pepp>
MrCooper: because I have to... note that I only see flushes in X in 2 cases: amdgpu_scanout_flip and in WaitForSomething/_glamor_block_handler
<MrCooper>
hmm, maybe it currently requires getting lucky and hitting glamor_block_handler before the client flushes its dependent GPU work
<pepp>
in my test case glReadPixels works most of the time. And sometimes I get the values from the previous frame.
<MrCooper>
I suspect the latter is when you get unlucky and glamor_block_handler didn't get hit in time
ubitux has quit [Remote host closed the connection]
ubitux has joined #dri-devel
mlankhorst has left #dri-devel [Konversation terminated!]
Natherul has joined #dri-devel
frieder has quit [Remote host closed the connection]
<Natherul>
Hey all, Im trying to bisect to help with https://gitlab.freedesktop.org/mesa/mesa/-/issues/4725 but I cant ninja install as it keeps just getting failed because of AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 'getchildren'. What should I do?
<jenatali>
Natherul: IIRC that's a function that was removed in a newer version of Python
<jenatali>
You'll either need to pick the patch that fixes Mesa's scripts on top of your bisect, or use an older Python
* alyssa
pretends to be a driver dev
<alyssa>
*kernel
<lynxeye>
Natherul: cherry-pick 7a68045b5d3ca52ea9db6f4c2606ae16546187ea on top of each bisect step where it applies
<Natherul>
thank you
Natherul has quit [Quit: Konversation terminated!]
<jekstrand>
alyssa: Me too!
<alyssa>
jekstrand: It's just like userspace, but with more rules!
<jekstrand>
And no C++, so that's a win.
<alyssa>
heh
Sumera has quit [Ping timeout: 480 seconds]
berylline has joined #dri-devel
pekkari has quit []
jernej_ has joined #dri-devel
jernej_ has quit []
<berylline>
are there any resources for writing a graphics driver? just asking because i'm thinking of doing a project
hch12907_ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
abhinav__ has joined #dri-devel
haagch has joined #dri-devel
hch12907_ is now known as hch12907
Sumera has joined #dri-devel
<jekstrand>
berylline: Not in nice documentation form, no. But there are lots of drivers to look at and steal ideas from.
<jekstrand>
berylline: What HW are you planning to drive?
<berylline>
jekstrand: you might think it's a bold step for me to take, but i had the older PowerVR SGX GPUs in mind
<HdkR>
Well, someone has to eventually break down and give it a try :)
<berylline>
HdkR: haha, yeah, something's got to give
<danvet>
berylline, I guess you're aiming for some gles driver? or more kernel?
<berylline>
danvet: both, like the other FOSS drivers
<danvet>
yeah I think for that looking at some of the arm drivers in kernel and mesa3d is a good start
<danvet>
like panfrost, v3d, msm, etnaviv
<danvet>
there's a bunch of them
<danvet>
hm maybe not msm kernel, because you'll get confused by all the display code :-)
<danvet>
oh and apple m1 for watching a r/e'd gpu driver in the incubator, life
<alyssa>
danvet: while on the subject, ptrs for kernel drm stuff?
<alyssa>
Is "just do whatever v3d does" sound advice in kernel like it is in mesa?
<berylline>
i've started looking at the code of some of the drivers a while ago, although that's for something unrelated to what i'm talking about right now
<danvet>
alyssa, yeah
<alyssa>
cool :+1:
<HdkR>
alyssa: Make sure all your structs match cross-arch :)
<danvet>
I've just done a fairly full audit and v3d is pretty ok I think
<danvet>
two things that aren't awesome
<danvet>
1) hand-rolling per-bo lock instead of just using dma_resv_lock, but shmem helpers aren't there yet either :-(
<danvet>
2) no NO_IMPLICIT flag in execbuf/CS, but that's easy to add once a vulkan driver exists
<danvet>
it might be a good idea to have that if your gpu is multi-engine even for gl
<alyssa>
danvet: implicit fencing on panfrost has put us in a huge local minimum
<danvet>
yeah that wasn't the smartest move I think
<alyssa>
yeah..
<danvet>
but it's also easy to fix
<danvet>
you need the write flag (well make it a readonly flag since you don't have the write flag right now)
<danvet>
and the no_implicit flag
<danvet>
and a getparam or whatever
<danvet>
and convert userspace over
<danvet>
if the kernel is too old, no problem, you'll just keep oversyncing (and not set the flags to avoid EINVAL)
<danvet>
I've seen worse, like amdgpu trying to handle the oversync in a way that's incompatible to what all the other drivers are doing
<alyssa>
"easy"
<danvet>
and now we're in a game of "are there any options left to get us out of this corner" :-(
<danvet>
well I'm just standing back in awe about all the r/e you do, but even not adjusted for that shouldn't be too tricky to pull off :-P
<berylline>
thanks for the advice, so far :)
<alyssa>
danvet: I've written almost no kernel code in my life though
<danvet>
also I dropped some panfrost patches and with those it uses the same helpers as all the others, so boils down to copypasta
<alyssa>
Would like to change that, so spending some time today piping in a low hanging fruit
<alyssa>
well, this morning i was. since then i've been struggling to get mainline running
<danvet>
alyssa, it's just painful, even after 10 years of doing it pretty much exclusively
<alyssa>
i hope that's not supposed to be motivational
<Sumera>
danvet: thanks for the pointers, I have been wondering about how to write a very basic graphics driver as well :)
<danvet>
I mean, it's not harder than userspace programming, just more painful
<alyssa>
oh ffs git sha changed ===> whole new set of modules
<danvet>
you screw up, your machine is dead and you get to reboot and watch birds meanwhile
<danvet>
yeah
<HdkR>
"Linux Kernel development: It never gets easier"
<alyssa>
that would explain why i no has gpu
<danvet>
changed one header/.config symbol, recompile the world
<alyssa>
..on a chromebook no less
<danvet>
it's mostly an exercise in more patience
<alyssa>
i swear once the M1 has linux support upstream.....
<danvet>
best part is having no idea where the bug is, so you sprinkle some debug output around
<danvet>
reboot
<danvet>
and right when you've hit ^M you realize what you should have done
<alyssa>
do you regret your career choice? asking for a friend
<danvet>
best part if you hang at boot
<danvet>
well the glorious vindication of your own ego when you figure it out is also correspondingly bigger
<alyssa>
ok, have my custom mainline running and now things seem to work
<alyssa>
now back to testing the feature I was trying to implement in the first place ....
<berylline>
also, i was about to say that from what i've read about the AGX GPU so far, the IP was licensed from Imagination Technologies
<alyssa>
[citation needed]
<danvet>
and there's also neat stuff like trying to untangle lock/dependency design messes
<danvet>
which you generally don't have much of in userspace
<danvet>
also guaranteed job security of trying to write safety critical code in C
<alyssa>
loool
<danvet>
that's probably the dumbest part of it all
<berylline>
alyssa: i read it somewhere, but i would have to look it up again :P
<alyssa>
Phoronix comments are not a reliable source
<berylline>
alyssa: oh, it definitely wasn't from Phoronix
<alyssa>
:)
<berylline>
alyssa: not even the comments section, i assure you, haha
<alyssa>
There's really no good evidence that AGX itself isn't Apple IP
<alyssa>
although it's certainly inspired by IMG
<alyssa>
Of course, without public docs on either GPU it's hard to say
<lynxeye>
Apple hired a lot of guys from outside the IMG bubble, e.g. one of the Vivante GPU chief architects a few years back...
<danvet>
oh vivante is also img bubble?
<lynxeye>
danvet: outside of IMG bubble. Vivante is pretty much the antidote of IMG design. Much fixed function, no firmware, immediate renderer.
<danvet>
oh I can't read
<lynxeye>
One of the IMG guys I've met at a conference a few years back almost couldn't believe that you can build a GPU without firmware.
<alyssa>
Mali held out for a decade.
<airlied>
once you have vram and ram clocks to control fw is mostly imevitablr
heat has joined #dri-devel
<airlied>
but also once you have companies and patents
<danvet>
I think it's really the latter that's the big push
<daniels>
alyssa: btw CONFIG_EXTRAVERSION_AUTO=n will stop the SHA from getting into your kernel version
<alyssa>
daniels: ack, thanks :+1:
<alyssa>
probably too late now but good to know for future
<berylline>
i admit i can't exactly remember what i've read, so *shrug*
<berylline>
and this might give a few hints, although i might be wrong about that:
<jekstrand>
The people I know suspect that the M1 is an IMG derivative but, at this point, it may be no more similar than VEGA is from Arduino. They both came from r600, sort-of, but they're totally different GPUs at this point.
<berylline>
and even if it was based on Imagination Technologies' IP, it would probably be closer to Furian than it is to Series5 or Rogue
<flto>
Arduino or Adreno? ;-)
<daniels>
jekstrand: ... Arduino?
<lynxeye>
airlied: RAM clocks could be done without FW, at least the Tegra also manages to do without. It just has a set of shadow timings in the controller where you stage stuff for the next clock rate, then it interlocks with the PLL and loads the shadow registers when the PLL changes rate.
<HdkR>
Agreement could also just be so Apple can keep using PVRTC for all we know :P
<lynxeye>
But yeah, autonomous device power state management is something that lots of people like to stash away in firmware
<alyssa>
jekstrand: Mali needs to know if cycle counters are read in a shader
<alyssa>
should I add a shader_info or just do it in the backends?
<alyssa>
(I have a myopic view of hw that forbids me from knowing if that's useful info to other drivers :P)
<berylline>
or hell, probably the A-Series, for all i know
<jekstrand>
daniels: Maybe I spelled it wrong. Qualcomm
<jekstrand>
alyssa: I tend to put stuff in our HW-specific prog_data by default and only throw it in shader_info if it's really useful to others.
<alyssa>
jekstrand: Ack :+1:
<daniels>
jekstrand: Adreno ... Arduino is the microcontroller thing
<jekstrand>
alyssa: Also, in our drivers, the shader_info isn't accessible at command emit time.
<jekstrand>
daniels: Right. Sorry
<jekstrand>
alyssa: So everything goes in prog_data.
<daniels>
and I assume that M1 and Furian are more related than Vega and an 8-bit MCU :P
<jekstrand>
:P
<jekstrand>
You never know!
<berylline>
it's just a guess of mine, haha
<berylline>
just take what i'm guessing with a grain of salt
<berylline>
anyway, i'm going to be AFK for a bit
Sumera has quit [Quit: leaving]
<alyssa>
hey cool the piglit passes
<alyssa>
maybe I can be a kernel dev :p
<jekstrand>
\o/
<jekstrand>
vulkaninfo doesn't work. Clearly, I can't. :-P
<alyssa>
:P
mwalle has joined #dri-devel
mbrost has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
<mwalle>
hi, i'm new to the dri/drm stuff, so please bear with me. I have a soc (nxp ls1028a) with a vivante gpu and a mali-dp, latest linux-next and trying to get glmark2 to run
<mwalle>
i have two /dev/dri/card0 (mali-dp) and /dev/dri/card1 (etnaviv) devices
<danvet>
alyssa, if it works at first, you just booted the wrong kernel
<alyssa>
danvet: yep
<alyssa>
mwalle: There are devices with mali-dp? :'o
<imirkin>
danvet: so sad how true that is...
<mwalle>
glmark2 seems to try to open /dev/dri/card0 which is mali-dp and doesn't have 3d hw acceleration. so far so good
<mwalle>
alyssa: apparently :)
<mwalle>
if i hardcode /dev/dri/card1 the modesetting will fail.. because well. i guess that is the duty of mali-dp, right?
<mwalle>
so somehow both device must be used, no?
<imirkin>
yes.
<anarsoul>
mwalle: apparently you need to add mali-dp to kmsro?
<imirkin>
they are generally bound together with "kmsro"
<mwalle>
I do have a working mali-dp, at least the kernel framebuffer works correctly
<jekstrand>
alyssa: noob tip: When doing kernel hacking, disable any boot-to-desktop stuff. Otherwise, it may burn its quota of blowing up before you ever get to run your test. :)
<jekstrand>
Guess who just learned this again?
<mwalle>
ahh, now what is kmsro?
<alyssa>
jekstrand: Ah, yep
<mwalle>
kernel component or mesa or libdrm?
<imirkin>
(ro = renderonly, not readonly as one might guess)
<imirkin>
mwalle: it's a mesa meta-driver
<jekstrand>
alyssa: Also, when debugging kernel segfaults. Remember how many cores you have. You have N-1 tries before your kernel is dead. :D
<alyssa>
lolol
<mwalle>
imirkin: thanks for the pointer, i'll have a look
<alyssa>
marcan made that joke on a stream a little while back, when the code was hanging the CPU and requiring a reboot to fix
<jekstrand>
If the machine is in another room/office/state/country, that's especially important to remember. :D
<alyssa>
"it's not that bad, I have 8 tries"
<imirkin>
mwalle: basically you need to generate a mali_dp_dri.so from mesa
<danvet>
jekstrand, not if you died holding an important lock
<jekstrand>
danvet: Well, yeah.....
<mwalle>
imirkin: ahh, yes, glmark2 tries to open that
<alyssa>
jekstrand: Actually I have all my linux machines boot to TTY since I'm so used to updates to { kernel, mesa, gnome } breaking everything
<danvet>
the really annoying thing is that once you got stuck in a module, you can't unload it anymore
<imirkin>
on rare occasions i do want something fancy and have to read the help. but that happens ... like twice thus far :)
<mwalle>
why are you guys so suprised that some uses mali-dp?
<alyssa>
I didn't know it taped out into real silicon
<imirkin>
alyssa: fwiw i find that the key to send-email is to not use it to send stuff "directly". instead i use format-patch to make the things to send, edit them to my heart's content, and then just use git send-email to transfer those over SMTP
<alyssa>
yeah, same
<jekstrand>
<alyssa>
I more meant "will I remember how to not have mutt collapse"
<jekstrand>
If you're going to send more than about 50 patches or so, remember to split it into multiple git-send-email invocations. SMTP servers tend to choke above a certain threshold.
<alyssa>
unless it does SMTP itself
<alyssa>
i guess that's the idea ok
<imirkin>
send-email does SMTP directly
<imirkin>
and supports various auth things, which are slightly annoying to set up properly. i think the page bl4ckb0ne mentioned has configs for the common email services out there
<alyssa>
Ok, I think there it goes, into the aether
<imirkin>
mwalle: what's that 1920x1200 doing there?
<imirkin>
you should mark modes you can't do as 'bad'
<imirkin>
(when i say 'you', i mean 'the mali-dp driver'
<mwalle>
imirkin: probbaly.. but that drm_bridge driver is work in progress ;)
<imirkin>
oh boo
<imirkin>
that's all so complicated :(
<imirkin>
so yeah, glmark probably tries to set native resolution
<mwalle>
(by me)
<imirkin>
dunno if there's an optino to tell it what resolution to use
<imirkin>
you mentioned -s, but didn't sound like it helped?
<mwalle>
do you happen to know if you can tell the supported resultions in the device tree?
<imirkin>
that might affect just the rendered image size
<imirkin>
i do not know.
<imirkin>
i do know you can make your own EDID and override the real one with it :)
<mwalle>
haha ;)
<imirkin>
definitely not cheating at all
<mwalle>
i could just hack the mode_valid callback
<imirkin>
in fact there are some baked edid's you can use
<imirkin>
which expose just one thing
<imirkin>
tools/edid/1920x1080.S
<imirkin>
coz, you know, gnu as is the most logical way to allow EDID's to be specified
<imirkin>
(this is in a kernel tree)
<mwalle>
which begs the question. how do i specify it on the cmdline *g
<imirkin>
drm.edid_firmware=DP-1:path/to/edid
<mwalle>
did I mention I'm a real noob in the drm subsys *g
<imirkin>
you seem to be doing fine
<imirkin>
i don't recognize your name, but it seems like you have experience making your way around these things
<imirkin>
which gets you out of the "noob" category
<mwalle>
it seems like I'm crossing all subsys in the kernel
ngcortes has quit [Remote host closed the connection]
<imirkin>
yeah, coz you're working on a SoC
<imirkin>
i got defeated when trying to grok PCIe
<mwalle>
I'm just trying to get upstream support of our board ;)
<imirkin>
decided to cut my losses and go back to what i know :)
<imirkin>
that's great to hear
<mwalle>
FPS: 3 FrameTime: 333.333 ms
<mwalle>
uhm *g
<mwalle>
but I see exaclty a black picture ;)
<imirkin>
are you still seeing gpu hangs?
<mwalle>
nope
<imirkin>
how did you get past all that so quick?
<imirkin>
anyways, if this is a "everything works but i see a black picture" situation, i can't really help. 3 fps sounds really slow for glmark, so i'd guess there are still outstanding issues.
<mwalle>
yeah, something for tomorrow
<imirkin>
you may be able to get more directed help in #etnaviv
<mwalle>
ok thanks :) this is a nice channel i have to say
<mwalle>
yay, "glmark score: 2". this is astonishing ;))
<imirkin>
for a black picture?
<imirkin>
i feel like it could draw all black a *lot* faster :)
<imirkin>
although in reality, it may just be missing the "final copy" or whatever
<imirkin>
so still does all the work
<imirkin>
conceivable you missed a step with the kmsro enablement, although i dunno what it'd be
<mwalle>
kmscube (whatever that is) has 3.6fps
<imirkin>
it's a cube which spins
<imirkin>
using kms
<imirkin>
you should be able to do 60fps on that easy
<imirkin>
so you have some bigger problems
<mwalle>
ahh.. doh I still got that gpu hang. I had turned off the kernel console (because drm.debug=0x1ff..)
<mwalle>
which tells me.. I really need to stop now ;)
<imirkin>
yea that makes more sense
rpigott has quit [Ping timeout: 480 seconds]
rpigott has joined #dri-devel
idr has joined #dri-devel
<idr>
anholt: The Portal 2 trace actually is a flake??? I was only kidding in that message.
<alyssa>
idr: This wasn't triumph? I'm making a note here :-(
rpigott has quit [Remote host closed the connection]
<jekstrand>
Why would dma_resv_get_list return NULL?
<mwalle>
btw, after looking into drm_bridges it seems that most drm devices have an associated encoder, except mali-dp.. I needed to create my own shim drm_encoder. It seems that the only real drm_bridge for the mali dp is drivers/gpu/drm/i2c/tda998x_drv.c, which also creates a drm_encoder. But I don't know if its correct for a bridge to also create an encoder
<imirkin>
tagr is the expert in that area afaik... maybe robclark --^
rpigott has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
ppascher has quit [Ping timeout: 480 seconds]
hanetzer has joined #dri-devel
<hanetzer>
I hear there is a bar here?
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
thelounge26 has joined #dri-devel
<Corbin>
Yeah, this is the place.
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
Guest102 has quit [Ping timeout: 480 seconds]
berylline has joined #dri-devel
<berylline>
sorry, i was afk for a bit longer than expected. did i miss any kind of valuable advice for developing graphics drivers while i was gone?
<hanetzer>
no, we were about to discuss mixed drinks. I personally quite enjoy a moscow mule :)
thelounge260 has joined #dri-devel
thelounge260 is now known as alatiera
thelounge26 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
mbrost has joined #dri-devel
hikiko has quit [Ping timeout: 480 seconds]
berylline has left #dri-devel [#dri-devel]
FireBurn has joined #dri-devel
<FireBurn>
Is anongit.freedesktop.org down just now?
mdnavare has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
pcercuei has quit [Quit: dodo]
iive has quit []
FLHerne has quit [Quit: There's a real world out here!]
<imirkin>
zmike: hey ... so if i understand correctly (re 11049): you're selecting between the "loaded" value and a "default" value. i think the default value for the 4th position can always be 1, irrespective of the number of components in the format.
FLHerne has joined #dri-devel
<zmike>
imirkin: that's not accurate as far as I'm aware and as far as tests require
<imirkin>
zmike: huh, ok. can you point me to a time when that doesn't work out?
<imirkin>
e.g. what tests would fail?
<zmike>
the test that the MR is fixing
<imirkin>
the old code defaulted it to 0
<imirkin>
i think if you always default to 1 (for the 3rd component), that test should pass. are you saying it doesn't?
<zmike>
that's what I'm saying
<imirkin>
very surprising.
<imirkin>
thanks for the info. i'll play with it on my own time
FLHerne has quit [Quit: There's a real world out here!]